[File] [PATCH] of Magdir/msdos executables W3 W4 NE with unknown OS

Tue Nov 29 23:20:00 UTC 2022

Wow, what a mess. Committed, thanks!

christos

> On Nov 26, 2022, at 6:11 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> some months ago i inspect files on my EFI partition. For files
> starting with 2 byte MZ magic i get unexpected recognitions.
> There are change of errors. So i will split it after work of month.
> Now i will handle "MZ-executables" with "NE" new header.
> 
> When running file command version 5.43 on such examples and other
> related files i get an output like:
> 
> CREATEDD.EXE: MS-DOS executable, NE
> 	      (unknown OS 0) (EXE)
> CVP7.EXE:     MS-DOS executable, NE
> 	      (unknown OS ffffff82) (EXE)
> DOSMEM.EXE:   MS-DOS executable, NE
> 	      (unknown OS ffffff81)
> 	      for MS-DOS, Phar Lap DOS extender (EXE)
> DPMILD32.EXE: MS-DOS executable, NE
> 	      (unknown OS 6) (DLL or font)
> DTM.DLL:      MS-DOS executable, NE
> 	      (unknown OS 0) (DLL or font)
> HELPMSG.EXE:  MS-DOS executable, NE
> 	      (unknown OS 0) (EXE)
> KALENDER.EXE: MS-DOS executable, NE
> 	      (unknown OS 0) (EXE)
> MSDOSD.EXE:   MS-DOS executable, NE
> 	      (unknown OS 0) (DLL or font)
> VMM32-98.VXD: MS-DOS executable
> WIN386.EXE:   MS-DOS executable, W3 for MS Windows
> vmm32.vxd:    MS-DOS executable, W3 for MS Windows
> 
> With --extension option some times the wrong file name extensions are
> displayed. This looks like:
> 
> CREATEDD.EXE: exe/scr
> CVP7.EXE:     exe/scr
> DOSMEM.EXE:   exe/scr
> DPMILD32.EXE: dll/drv/3gr/cpl/vbx/fon/fot
> DTM.DLL:      dll/drv/3gr/cpl/vbx/fon/fot
> HELPMSG.EXE:  exe/scr
> KALENDER.EXE: exe/scr
> MSDOSD.EXE:   dll/drv/3gr/cpl/vbx/fon/fot
> VMM32-98.VXD: ???
> WIN386.EXE:   ???
> vmm32.vxd:    ???
> 
> Furthermore with -i option for all samples only generic DOS
> executable mime type application/x-dosexec is shown.
> 
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). This list the used
> file name extension and often with -v option the related URL
> pointing to used file format information ( See appended
> trid-v-NE-W4.txt).
> 
> For comparison reason i also run the file format identification
> utility DROID ( See https://sourceforge.net/projects/droid/).
> Here all samples are described as "Windows New Executable" via PUID
> x-fmt/410. This accepts the EXE extension but not the DLL and DRV
> extension (EXTENSION_MISMATCH true).
> 
> For some samples i get message text with "unknown OS"
> followed by values ffffff82 ffffff81 6). When i look inside
> Magdir/msdos the responsible lines look like:
> 
>>> (0x3c.l)		string	NE \b, NE
> !:mime	application/x-dosexec
>>>> (0x3c.l+0x36) byte	1 for OS/2 1.x (0x3c.l+0x36) byte	2 for
>>>> MS Windows 3.x (0x3c.l+0x36) byte	3 for MS-DOS (0x3c.l+0x36)
>>>> byte	4 for Windows 386 (0x3c.l+0x36) byte	5 for Borland
>>>> Operating System Services (0x3c.l+0x36) default	x
>>>>> (0x3c.l+0x36) byte	x (unknown OS %x)
>>>> (0x3c.l+0x36) byte	0x81 for MS-DOS, Phar Lap DOS extender
> 
> For samples like BIG.EXE DOSMEM.EXE GRMEM.EXE MEMTEST2.EXE
> TELLPROT.EXE TRYDLL.EXE string "(unknown OS ffffff81)" is displayed
> for target OS byte. So the six f characters vanish if test use
> unsigned variant ubyte instead of byte. Furthermore the default
> clause is not the last one. So such samples are described first as
> "unknown OS" then for value 81h the phrase with "Phar Lap DOS
> extender" is shown.
> So i changed the order that default clause comes last. Then i found
> an example CVP7.EXE with target value 82h. Luckily i found a page
> about "Int 21/AH=4Bh" and "DOS 2+ - EXEC - LOAD AND/OR EXECUTE
> PROGRAM" where these values are explained. According to that side
> value 82h is used for "PharLap 286|DOS-Extender, Windows" whereas 81h
> is used for "PharLap 286|DOS-Extender, OS/2".
> Then i find example DPMILD32.EXE where target 6 is displayed, but i
> do not know what OS this is. The sample was found in FREEDOS sub
> directory of dosbox GUI D-Fend-Reloaded.
> 
> Some samples like DTM.DLL, SHELL11F.EXE, HELPMSG.EXE and CREATEDD.EXE
> are found inside directory of OS/2 1.0 system. Some samples like
> MSDOSD.EXE KARTEI.EXE KALENDER.EXE are found in directory of Windows
> 1.03 or 2.1. So i assume that target OS byte value 0 value applies
> to such very old OS/2 and Windows systems. So that code block now
> becomes like:
>>> (0x3c.l)	string		NE \b, NE
> !:mime	application/x-ne-executable
>>>> (0x3c.l+0x36) byte	0 for OS/2 1.0 or MS Windows 1-2
>>>> (0x3c.l+0x36) byte	1 for OS/2 1.x
>>>> (0x3c.l+0x36) byte	2 for MS Windows 3.x
>>>> (0x3c.l+0x36) byte	3 for MS-DOS
>>>> (0x3c.l+0x36) byte	4 for Windows 386
>>>> (0x3c.l+0x36) byte	5 for Borland Operating System Services
> #>>>(0x3c.l+0x36) byte	6 for TARGET SIX
>>>> (0x3c.l+0x36) byte	0x81 for MS-DOS, Phar Lap DOS extender, OS/2
>>>> (0x3c.l+0x36) byte	0x82 for MS-DOS, Phar Lap DOS extender, Win.
>>>> (0x3c.l+0x36) default	x
>>>>> (0x3c.l+0x36)	byte	x (unknown OS %#x)
> 
> The new exe header beginning is shown by debugging line like:
> #>(0x3c.l)	string		x	\b, at 0x3c %.2s
> For most 32-bit and higher Windows we get here PE. For 16-bit Windows
> we get here NE and for OS/2 we often get LX or LE. But according to
> documentation there exist other magic strings. So i look for such
> examples. Some examples like like vmm32.vxd has W3 new header magic.
> This case is described by lines like:
>>> (0x3c.l)		string		W3 \b, W3 for MS Windows
> !:mime	application/x-dosexec
> Because file suffix displaying is missing and it is not a DOS
> executable i changes lines. So this now becomes like:
>>> (0x3c.l)		string		W3 \b, W3 for MS Windows
> !:mime	application/x-ms-w3-executable
> !:ext	vxd/exe
> Furthermore i found on windows 98 a sample with same name, but there
> the magic was W4. So this example is now described by lines like:
>>> (0x3c.l)		string		W4 \b, W4 for MS Windows
> !:mime	application/x-ms-w4-executable
> !:ext	vxd
> 
> After applying the above mentioned changes by patch
> file-NE_W4.diff the output now looks like:
> 
> CREATEDD.EXE: MS-DOS executable, NE
> 	      for OS/2 1.0 or MS Windows 1-2
> 	      (0.0) (EXE)
> CVP7.EXE:     MS-DOS executable, NE
> 	      for MS-DOS, Phar Lap DOS extender, Windows
> 	      (3.10) (EXE)
> DOSMEM.EXE:   MS-DOS executable, NE
> 	      for MS-DOS, Phar Lap DOS extender, OS/2
> 	      (0.0) (EXE)
> DPMILD32.EXE: MS-DOS executable, NE
> 	      (unknown OS 0x6)
> 	      (0.0) (DLL or font)
> DTM.DLL:      MS-DOS executable, NE
> 	      for OS/2 1.0 or MS Windows 1-2
> 	      (0.0) (DLL or font)
> HELPMSG.EXE:  MS-DOS executable, NE
> 	      for OS/2 1.0 or MS Windows 1-2
> 	      (0.0) (EXE)
> KALENDER.EXE: MS-DOS executable, NE
> 	      for OS/2 1.0 or MS Windows 1-2
> 	      (0.0) (EXE)
> MSDOSD.EXE:   MS-DOS executable, NE
> 	      for OS/2 1.0 or MS Windows 1-2
> 	      (0.0) (DLL or font)
> VMM32-98.VXD: MS-DOS executable, W4 for MS Windows
> WIN386.EXE:   MS-DOS executable, W3 for MS Windows
> vmm32.vxd:    MS-DOS executable, W3 for MS Windows
> 
> Now with --extension option for inspected samples often the correct
> file name extensions are shown like:
> 
> CREATEDD.EXE: exe/scr
> CVP7.EXE:     exe/scr
> DOSMEM.EXE:   exe/scr
> DPMILD32.EXE: dll/drv/3gr/cpl/vbx/fon/fot
> DTM.DLL:      dll/drv/3gr/cpl/vbx/fon/fot
> HELPMSG.EXE:  exe/scr
> KALENDER.EXE: exe/scr
> MSDOSD.EXE:   dll/drv/3gr/cpl/vbx/fon/fot
> VMM32-98.VXD: vxd
> WIN386.EXE:   vxd/exe
> vmm32.vxd:    vxd/exe
> 
> I hope my diff file can be applied in future version of
> file utility.
> 
> The sub classification for NE is not 100%. To do is distinguish
> Font FON FOT resources from DLL libraries. To do is distinguish
> Computer Based Training CBT from pure EXE executables. To do is
> distinguish Microsoft Word text conversion CNV program from pure
> EXE executables.
> To do is distinguish screensaver SCR from pure EXE executables.
> But this is complicated. So i will try to do this in future
> session. In order to do that i add some DEBUGGING lines at the
> beginning of NE section like:
> #>>>(0x3c.l+0x0C)byte		x	\b, ProgFlags 0x%2.2x
> #>>>(0x3c.l+0x0D) ubyte		x	\b, ApplFlags 0x%2.2x
> #>>>(0x3c.l+0x37) byte		!0	\b, OS2EXEFlags 0x%x
> #>>>(0x3c.l+0x14) ulelong	!0 	\b, EntryPoint 0x%x
> #>>>(0x3c.l+0x38) uleshort	!0	\b, retThunkOffset 0x%x
> #>>>(0x3c.l+0x30) uleshort	!0	\b, MovEntryCount %u
> 
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCY4KdGwAKCRCv8rHJQhrU
> 1u0oAKChlrh0aeqFaFhwtS2D+bGI32ZfzwCfbyId3YtFcDjLs08Inc2hAJKbPWc=
> =o0xB
> -----END PGP SIGNATURE-----
> <file-NE_W4_diff.DEFANGED-583><file-NE_W4_diff_sig.DEFANGED-584><trid-v-NE_W4.txt.gz>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20221129/57b3f222/attachment.asc>