Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
DOS386(R)

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(R)

Homepage

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)

> 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(R)

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)

> 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(R)

Homepage

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)

> 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!

Back to index page
Thread view  Board view
15108 Postings in 1358 Threads, 246 registered users, 13 users online (0 registered, 13 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum