DOS ain't dead - [BUG] PE has a bug (and a "nonstandard" stub)

DOS386

25.10.2007, 06:54

[BUG] PE has a bug (and a "nonstandard" stub) (DOSX)

Hi

NCC.ZIP

Seems I found a bug in Japheth's PE tool - it crashes when attempting to list the relocs of this file :-|

Besides of this, it seems to have a "special" $240 bytes stub - but works with both this stub as well as the standard $200 bytes one when I PESTUB it - any reson for this stub around ? ;-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
26.10.2007, 09:38
(edited by Japheth, 26.10.2007, 11:49)

@ DOS386

[BUG] PE has a bug (and a "nonstandard" stub)

Post reply

> Seems I found a bug in Japheth's PE tool - it crashes when
> attempting to list the relocs of this file :-|

Thank you very much indeed for the bug report! I will look at it ASAP.

[edit]it is fixed in v1.9[/edit]

> Besides of this, it seems to have a "special" $240 bytes stub - but works
> with both this stub as well as the standard $200 bytes one when I PESTUB
> it - any reson for this stub around ? ;-)

This is not "special", it's just the stub the MS linker I used has added. This tool adds some - encrypted? - stuff behind the 200h byte header. If you love conspiracy theories you will be able to imagine what evil things MS has hidden there.

---
MS-DOS forever!

DOS386

28.10.2007, 04:08
(edited by DOS386, 28.10.2007, 04:40)

@ Japheth

[BUG] PE 1.9 has one more bug (and a "nonstandard" stub)

Post reply

> I will look at it ASAP.
> [edit]it is fixed in v1.9[/edit]

COOL :clap: Bug is fixed ... no relocs displayed at all :lol3:

Finally, not really surprising ... GT2 reports the same and they probably got suppressed (always useless in EXE ?) already when ASSpacking - thus ASSpackASSassin has nothing to recover :-|

Anyway, this executable seems to be good rather to test PE tools and loaders for uncrashability than to serve as an example of a 100% "clean" compliant PE.

Well, there is one more bug plus some additional issues:

- [BUG] "out of memory" when trying to display the "symbols" of this file ... not new, already present in 1.8 :no:

- [minor] The /V verbose option seems to have almost no effect - remove and assume as always true ?

- [minor] If no symbols are present, nothing is displayed on most files

mov ecx, [esi].FileHeader.NumberOfSymbols mov edi, [esi].FileHeader.PointerToSymbolTable .if ((!edi) || (!ecx)) invoke printf, CStr(<"Symbols: none present",lf>) ; Highly suspicious experimental "patch" jmp exit .endif mov eax, sizeof IMAGE_SYMBOL mul ecx mov dwSize, eax invoke malloc, eax .if (!eax) invoke printf, CStr(<"out of memory",lf>) ; BUG "occurs" here ??? jmp exit .endif mov ebx, eax

- [minor] | (!eax) | eax == 0 | (eax == 0) | 3 "different" ways to do the same (?) thing ?

test eax,eax ; .if (!eax) jnz @f invoke printf, CStr(<"out of memory",lf>) ; BUG "occurs" here ??? jmp exit @@: ; .endif

> This is not "special", it's just the stub the MS linker I used has added.
> This tool adds some - encrypted? - stuff behind the 200h byte header. If
> you love conspiracy theories you will be able to imagine what evil things
> MS has hidden there.

YES. :clap: Confirming my famous offensive claim: Linkers tend to include garbage into my executables

Anyway, most "MS" executables seem to have some amount of encrypted garbage (cca 0 ... $80 bytes) between end of the stub and "PE" ... and even worse, they set the MZ size to $490, far above PE position :no:

FASM sets both correctly to $80

PESTUB sets both correctly to $200 - and does no longer include any garbage into the paddings :-)

VALX sets MZ size to $6C and PE position to $100 ... also OK

It might be a good idea not to point MS linker to DPMIST32.BIN and instead invoke PESTUB after ... or use VALX ... of course unless there are arguments against I'm not aware of ;-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
28.10.2007, 09:50
(edited by Japheth, 28.10.2007, 10:04)

@ DOS386

[BUG] PE 1.9 has one more bug (and a "nonstandard" stub)

Post reply

> COOL :clap: Bug is fixed ... no relocs displayed at all :lol3:
>
> Finally, not really surprising ... GT2 reports the same and they probably
> got suppressed (always useless in EXE ?) already when ASSpacking -
> thus ASSpackASSassin has nothing to recover :-|

the relocs section is 8 bytes long. But since each reloc array has a 8 byte header, there are indeed no relocs at all in this binary. Strange.

> Well, there is one more bug plus some additional issues:
>
> - [BUG] "out of memory" when trying to display the "symbols" of this file
> ... not new, already present in 1.8 :no:

The MS DUMPBIN tool also tries to display the symbols and fails (when trying to position the file pointer to the symbol table). So this is not a bug. There are no symbols present in the binary, the fields in the header concerning symbols are misused.

> - [minor] | (!eax) | eax == 0 | (eax == 0) | 3 "different" ways to do the
> same (?) thing ?

The purpose is to confuse potential readers. A very common way to defend from unexperienced coders. :wink:

> It might be a good idea not to point MS linker to DPMIST32.BIN and
> instead invoke PESTUB after ... or use VALX ... of course unless there are
> arguments against I'm not aware of ;-)

POLINK could be used. It's mostly MS link compatible (understands the same arguments) and doesn't include additional bytes. But I'm not paranoid about using MS binaries.

---
MS-DOS forever!