Is this EXE "malformed"? A question about PE header structure

[Mark0]

This is about an issue that come out various times in the past on PowerBASIC's forum, and briefly resurfaced recently. Specifically, some (me included) believe there is something strange on the majority of EXEs produced with PB compilers previous to version 4.x and 8.x (Console and Windows versions respectively). Nothing dramatic, off course, but worth noting, IMHO.
Here's a sample output from my simple PEDu tool, analyzing the compiled EXE of one of the PB Console Compiler samples:

C:\Tools>pedu \PBCC\Samples\COM\Excel\ExcelAp2.exe

PEDu - PE Entry point Dumper v1.40b - (C) 2003-07 Marco Pontello

Binary type: Win32 Console - Target machine: Intel 386

Alignment: Section 1000h - File 200h - Base of code 1000h

Data directories            Size
 1 Import Table             2020
 5 Base Reloc. Table         464

Section   V.Offset   V.Size   R.Offset   R.Size
.text        1000h    4969h       400h    4A00h
.data        6000h     724h      4E00h     400h
.link        7000h     7E4h      5000h     800h
* Real address overlap with previous section by 512 bytes!
.rloc        8000h     1D0h      5800h     200h

Entry Point RVA: 16D0h
Code dump      : 55 8B EC 53 56 57 BB 00 60 40 00 66 2E F7 05 00
                 1F 40 00 04 00 0F 85 08 01 00 00 6A 00 FF 15 64
Comp/Enc/Pack  : PowerBASIC PB/CC 3.0x

As you can see, the link & data section overlap by 512 bytes.
This is detected as strange enough by UPX, for example, that stop with:
CantPackException: superfluous data between sections.

Also, a tool like PE Explorer say this, when analysing the EXE:
Warning! Section <.data> extends beyond the raw file offset of section <.link>.

Note that, if I manually edit the EXE and set the data section to the correct (non overlapping) size, the EXE work correctly, and UPX is able to pack it without any problem.

PB basically maintain that there's no a problem at all, since the Microsoft specs don't explicitely say that there can't be any overlapping (?!), and more than that because of the evidence that Windows can, in facts, load & execute the EXE without any problem. Recently they asked for an "adequate demonstration" of this "alleged problem", but then my posts with this findings have been silently ignored. Off course, like some of you may be aware of, things like this are... a bit difficult to be calmly discussed on PB forum.

But I'm not convinced of the previous "explanations". IMHO, the docs can reasonably omit to say that, because it's obviously a strange / erroneously situation. And Windows can load it without complaining because, as it's usual for us coders to do some sanity checks on input, and correct where possible, I believe that the Win loader can be simply clamping the section header to the correct / reasonable size, for example.
Also, the fact that newer major versions of the compilers don't sport this quirks, make me tend to believe it was some sort of oversight on the compiler's part.

So, I'm asking the opinion of anyone who have the necessary knowledge of the PE header structure & Windows loading process inner workings, to shed some light on the subject. What do you think?

If you need some EXEs to analyze, you can find many, obtained from various versions of the compilers, here (just search for "compiled executables"):
http://www.powerbasi...oads/all%20files.htm

Thanks,
Bye!

[f0dder]

Good luck ever getting the PowerBASIC people admitting any kind of failure - they're friggin' zealots.

That said, the PE format specifications are pretty loose, which is the cause of a great deal of headaches (I'm sure Jeremy Collake is going to agree ).

Anyway, this particular case does look pretty ugly to me, and it's probably an error on their side. Would be interesting to see how various windows versions handle such an executable, I'd recommend creating a little app that launches a process in SUSPENDED mode and dumps the {imagebase, imagebase+peheader.SizeOfImage} range of memory, and then test that on 95,98,Me,NT4,2k,XP since there's tiny differences in the PE loader...

[Mark0]

Thanks for the tip f0dder!