DOS ain't dead

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

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

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

> 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

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

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.

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