DOS ain't dead

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

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

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

COOL Bug is fixed ... no relocs displayed at all

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

- [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. 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

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

Complete thread:

• [BUG] PE has a bug (and a "nonstandard" stub) - DOS386, 25.10.2007, 06:54 (DOSX)
  • [BUG] PE has a bug (and a "nonstandard" stub) - Japheth, 26.10.2007, 09:38
    • [BUG] PE 1.9 has one more bug (and a "nonstandard" stub) - DOS386, 28.10.2007, 04:08
      • [BUG] PE 1.9 has one more bug (and a "nonstandard" stub) - Japheth, 28.10.2007, 09:50