[File] [PATCH] of Magdir/msdos PE32 executable some missed or wrong *.EFI *.HXS
Christos Zoulas
christos at zoulas.com
Mon Nov 21 22:27:29 UTC 2022
Committed, thanks!
christos
> On Nov 21, 2022, at 3:45 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hello,
>
> some days ago i inspect files on my EFI partition. For files starting
> with 2 byte MZ magic i get unexpected recognitions.
> When running file command version 5.43 on such examples and other
> related files i get an output like:
>
> EXCEL.HXS: MS-DOS executable
> PE32 executable
> (DLL)
> Intel 80386, for MS Windows
> Fat.efi: MS-DOS executable
> PE32 executable
> (DLL) (EFI boot service driver)
> EFI byte code, for MS Windows
> MCS9900Ce50.dll: PE32 executable
> (DLL) (Windows CE)
> Intel 80386, for MS Windows
> PAX.EXE: PE32 executable
> (POSIX)
> MIPS R4000
> (stripped to external PDB),
> for MS Windows
> PSXDLL.DLL: PE32 executable
> (DLL)
> (POSIX)
> MIPS R4000
> (stripped to external PDB),
> for MS Windows
> Shell_Full.efi: MS-DOS executable
> PE32+ executable
> (DLL) (EFI application)
> x86-64, for MS Windows
> WINWORD.HXS: MS-DOS executable
> PE32 executable
> (DLL)
> Intel 80386, for MS Windows
> bootmgfw.efi: PE32+ executable
> (DLL)
> (EFI application)
> x86-64, for MS Windows
> bootmgr.efi: PE32 executable
> Intel 80386, for MS Windows
> bootvhd.dll: PE32 executable
> (DLL)
> Intel 80386, for MS Windows
> ext4_x64_signed.efi: MS-DOS executable
> PE32+ executable
> (EFI boot service driver)
> x86-64, for MS Windows
> joy.cpl: PE32 executable
> (DLL) Intel 80386, for MS Windows
> memtest.efi: PE32 executable
> Intel 80386, for MS Windows
> navigator.exe: PE32 executable
> (Windows CE)
> ARM, for MS Windows
> winresume.exe: PE32+ executable
> x86-64, for MS Windows
> x-fmt-409-signature-id-196.exe: ASCII text
> x-fmt-411-signature-id-198.exe: MS-DOS executable
>
> With --extension option the wrong file name extensions are displayed.
> This looks like:
>
> EXCEL.HXS: exe/com/vlm
> Fat.efi: exe/com/vlm
> MCS9900Ce50.dll: ???
> PAX.EXE: ???
> PSXDLL.DLL: ???
> Shell_Full.efi: exe/com/vlm
> WINWORD.HXS: exe/com/vlm
> bootmgfw.efi: ???
> bootmgr.efi: ???
> bootvhd.dll: ???
> ext4_x64_signed.efi: exe/com/vlm
> joy.cpl: ???
> memtest.efi: ???
> navigator.exe: ???
> winresume.exe: ???
> x-fmt-409-signature-id-196.exe: ???
> x-fmt-411-signature-id-198.exe: exe/com/vlm
>
> Furthermore with -i option for all samples only generic mime types
> like application/x-dosexec are shown.
>
> With the newest version of Magdir/msdos (msdos,v 1.160 2022/11/18
> 16:15:16) containing my patch for 16-bit ICL the misidentification as
> "MS-DOS executable" vanished and also the DROID samples (x-fmt*.exe)
> are not described any more as "MS-DOS executable". And other mime
> type is shown and also number of sections is shown. That looks like:
>
> EXCEL.HXS: PE32 executable
> (DLL)
> Intel 80386, for MS Windows
> , 2 sections
> Fat.efi: PE32 executable
> (DLL) (EFI boot service driver)
> EFI byte code, for MS Windows
> , 4 sections
> MCS9900Ce50.dll: PE32 executable
> (DLL) (Windows CE)
> Intel 80386, for MS Windows
> , 3 sections
> PAX.EXE: PE32 executable
> (POSIX)
> MIPS R4000
> (stripped to external PDB),
> for MS Windows
> , 10 sections
> PSXDLL.DLL: PE32 executable
> (DLL)
> (POSIX)
> MIPS R4000
> (stripped to external PDB),
> for MS Windows
> , 10 sections
> Shell_Full.efi: PE32+ executable
> (DLL) (EFI application)
> x86-64, for MS Windows
> , 5 sections
> WINWORD.HXS: PE32 executable
> (DLL)
> Intel 80386, for MS Windows
> , 2 sections
> bootmgfw.efi: PE32+ executable
> (DLL) (EFI application)
> x86-64, for MS Windows
> , 5 sections
> bootmgr.efi: PE32 executable
> Intel 80386, for MS Windows
> , 8 sections
> bootvhd.dll: PE32 executable
> (DLL)
> Intel 80386, for MS Windows
> , 5 sections
> ext4_x64_signed.efi: PE32+ executable
> (EFI boot service driver)
> x86-64, for MS Windows
> , 3 sections
> joy.cpl: PE32 executable
> (DLL)
> Intel 80386, for MS Windows
> , 3 sections
> memtest.efi: PE32 executable
> Intel 80386, for MS Windows
> , 8 sections
> navigator.exe: PE32 executable
> (Windows CE)
> ARM, for MS Windows
> , 6 sections
> winresume.exe: PE32+ executable
> x86-64, for MS Windows
> , 9 sections
> x-fmt-409-signature-id-196.exe: ASCII text
> x-fmt-411-signature-id-198.exe: ISO-8859 text
>
> 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. There the HXS samples are
> described correctly as "Microsoft compiled help format 2.0" by
> hxs.trid.xml. This identifies only 2 EFI samples (Shell_Full.efi
> bootmgfw.efi) correctly as "Extensible Firmware Interface x86-64
> application" by efi-app-x86_64.trid.xml ( See appended
> trid-v-efi_hxs.txt). The file command recognize more EFI samples but
> here some (like bootmgr.efi memtest.efi ) are not recognized.
>
> For comparison reason i also run the file format identification
> utility DROID ( See https://sourceforge.net/projects/droid/).
> Here all real samples are described at least as "Windows Portable
> Executable" with mime type
> application/vnd.microsoft.portable-executable. This accepts the EXE
> extension but not the EFI and HXS extension (EXTENSION_MISMATCH true)
> .
> The samples, which are described by file command with phrase
> "PE32+ executable" are described as 64 bit version variant
> via additional test for byte sequence 0B02 by PUID fmt/900.
> The samples, which are detected by file command and described with
> phrase "PE32 executable" are described as 32 bit version variant
> via additional test for byte sequence 0B01 by PUID fmt/899.
> The samples not detected by file command are described as
> "Windows Portable Executable" without any version field by
> by PUID x-fmt/411 (See appended droid-efi_hxs.csv.gz).
>
> First i have done the obliviously items. Inside current Magdir/msdos
> the detected EFI samples are done by lines like:
>>> (0x3c.l+92) leshort 10 (EFI application)
>>> (0x3c.l+92) leshort 11 (EFI boot service driver)
>>> (0x3c.l+92) leshort 12 (EFI runtime driver)
>>> (0x3c.l+92) leshort 13 (EFI ROM)
>
> So i add after such entries a line to show correct file name suffix.
> As application variant are described samples like bootmgfw.efi
> grub.efi gdisk_x64.efi Shell_Full.efi shim.efi syslinux.efi.
> As boot driver variant are described samples like ext2_x64_signed.efi
> Fat_x64.efi iso9660_x64_signed.efi. For run time driver and ROM
> entries i found no examples, but i assume that here also EFI is used
> as suffix. So these lines now becomes like:
>>> (0x3c.l+92) leshort 10 (EFI application)
> !:ext efi
>>> (0x3c.l+92) leshort 11 (EFI boot service driver)
> !:ext efi
>>> (0x3c.l+92) leshort 12 (EFI runtime driver)
> !:ext efi
>>> (0x3c.l+92) leshort 13 (EFI ROM)
> !:ext efi
>
> Now comes the next part. The description as PE executable happens by
> line like:
>> (0x3c.l) string PE\0\0 PE
> !:mime application/vnd.microsoft.portable-executable
>>> (0x3c.l+24) leshort 0x010b \b32 executable
>>> (0x3c.l+24) leshort 0x020b \b32+ executable
>
> For debugging purpose i add/changed some lines. So this looks like:
>> (0x3c.l) string PE\0\0 PE
> !:mime application/vnd.microsoft.portable-executable
>>> (0x3c.l+24) leshort 0x010b \b32 executable
>>>> (0x3c.l+92) leshort x \b, SUBSYSTEM %u
>>> (0x3c.l+24) leshort 0x020b \b32+ executable
>>>> (0x3c.l+92) leshort x \b, SUBSYSTEM %u
>
> So we see that the undetected EFI samples have sub system value 16,
> but in current magic there does not exist a branch for that value.
> Now comes again a very subtilise error, because undetected cases shod
> be handled by 2 following lines:
>>> (0x3c.l+92) default x (Unknown subsystem
>>>> &0 leshort x %#x)
> But these are never executed. According to Microsoft page about
> PE Format on sub page about Windows Subsystem a dozen items are
> listed. These have "low" values. The highest mentioned value is 16.
> But not for every number below there exist an entry. So for non
> existing entries i create dummy entries and the undetected values are
> now handled correctly. So this now becomes like:
>>> (0x3c.l+92) leshort 4 (Unknown subsystem 4)
>>> (0x3c.l+92) leshort 6 (Unknown subsystem 6)
>>> (0x3c.l+92) leshort 15 (Unknown subsystem 15)
>>> (0x3c.l+92) leshort >16 (Unknown subsystem
>>>> &0 leshort x %#x)
>
> Now it becomes visible why some EFI samples are not described
> correctly. The current magic contains a line like:
>>> (0x3c.l+92) leshort 15 (Windows boot application)
> But according to documentation there does not exist an subsystem with
> value 15. Correct is value 16 for this entry. So this is now becomes
> like:
>>> (0x3c.l+92) leshort 16 (Windows boot application)
> !:ext efi/exe
> So samples like bootmgr.efi memtest.efi shellx64.efi memtest.exe
> winload.exe winresume.exe are now described correctly.
>
> Furthermore in documentation are some subsystems mentioned where no
> entry exist in current magic. So i add such cases like:
>>> (0x3c.l+92) leshort 5 (OS/2)
>>> (0x3c.l+92) leshort 8 (Win9x)
> Unfortunately i do not found such a samples. So i do not know which
> suffix is used for such samples.
>
> The case with sub system IMAGE_SUBSYSTEM_UNKNOWN=0 is also not
> considered. Normal Windows DLL libraries or executables have a few
> sections for code, data and resource for example. Sometimes the PE
> format is only used as container like for Microsoft compiled help
> format 2.0 (*.hxs). Such PE container have less sections. So i use
> this additional information to distinguish in more detail such PE
> samples. This are matched by Microsoft compiled help format 2.0
> (*.hxs) and some Control Panel Item like joy.cpl found in WINE
> 1.7.28. The CPL have more sections like (.text, .reloc, .rsrc)
> whereas the HXS only have 2 sections (.rsrc, .its). That can be
> verified by PE dump utility like for example:
> pelook.exe -d WINWORD.HXS & pelook.exe -h WINWORD.HXS
> So show that information by new entry with lines like:
>>> (0x3c.l+92) leshort 0 (
>>>> (0x3c.l+6) uleshort =2 \bMicrosoft compiled help format 2.0)
> !:ext hxs
>>>> (0x3c.l+6) uleshort !2 \bControl Panel Item)
> !:ext cpl
> Information about HXS can be found for example on Wikipedia. So i add
> this information by comment lines like:
> # URL: https://en.wikipedia.org/wiki/Microsoft_Help_2
> # Reference: http://www.russotto.net/chm/itolitlsformat.html
> # https://mark0.net/download/triddefs_xml.7z
> # defs/h/hxs.trid.xml
>
> After applying the above mentioned modifications by patch
> file-msdos-efi_hxs.diff then i get a more precise output like:
>
> EXCEL.HXS: PE32 executable
> (DLL)
> (Microsoft compiled help format 2.0)
> Intel 80386, for MS Window
> , 2 sections
> Fat.efi: PE32 executable
> (DLL) (EFI boot service driver)
> EFI byte code, for MS Windows
> , 4 sections
> MCS9900Ce50.dll: PE32 executable
> (DLL) (Windows CE)
> Intel 80386, for MS Windows
> , 3 sections
> PAX.EXE: PE32 executable
> (POSIX)
> MIPS R4000
> (stripped to external PDB),
> for MS Windows
> , 10 sections
> PSXDLL.DLL: PE32 executable
> (DLL)
> (POSIX)
> MIPS R4000
> (stripped to external PDB),
> for MS Windows
> , 10 sections
> Shell_Full.efi: PE32+ executable
> (DLL) (EFI application)
> x86-64, for MS Windows
> , 5 sections
> WINWORD.HXS: PE32 executable
> (DLL)
> (Microsoft compiled help format 2.0)
> Intel 80386, for MS Windows
> , 2 sections
> bootmgfw.efi: PE32+ executable
> (DLL) (EFI application)
> x86-64, for MS Windows
> , 5 sections
> bootmgr.efi: PE32 executable
> (Windows boot application)
> Intel 80386, for MS Windows
> , 8 sections
> bootvhd.dll: PE32 executable (DLL)
> (Windows boot application)
> Intel 80386, for MS Windows
> , 5 sections
> ext4_x64_signed.efi: PE32+ executable
> (EFI boot service driver)
> x86-64, for MS Windows
> , 3 sections
> joy.cpl: PE32 executable
> (DLL)
> (Control Panel Item)
> Intel 80386, for MS Windows
> , 3 sections
> memtest.efi: PE32 executable
> (Windows boot application)
> Intel 80386, for MS Windows
> , 8 sections
> navigator.exe: PE32 executable
> (Windows CE)
> ARM, for MS Windows
> , 6 sections
> winresume.exe: PE32+ executable
> (Windows boot application)
> x86-64, for MS Windows
> , 9 sections
> x-fmt-409-signature-id-196.exe: ASCII text
> x-fmt-411-signature-id-198.exe: ISO-8859 text
>
> With --extension option for inspected real examples the correct file
> name extensions are now shown like:
>
> EXCEL.HXS: hxs
> Fat.efi: efi
> MCS9900Ce50.dll: dll
> PAX.EXE: exe
> PSXDLL.DLL: dll
> Shell_Full.efi: efi
> WINWORD.HXS: hxs
> bootmgfw.efi: efi
> bootmgr.efi: efi/exe
> bootvhd.dll: dll
> ext4_x64_signed.efi: efi
> joy.cpl: cpl
> memtest.efi: efi/exe
> navigator.exe: exe
> winresume.exe: efi/exe
> x-fmt-409-signature-id-196.exe: ???
> x-fmt-411-signature-id-198.exe: ???
>
> I hope my diff file can be applied in future version of
> file utility.
>
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
>
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCY3vjWgAKCRCv8rHJQhrU
> 1ra1AJ9DnJwO6rxXnFKN+IqHWFwYUtnmpwCeK+hcvSCrd06qAL0pJbBiU2a2cIo=
> =ujQ7
> -----END PGP SIGNATURE-----
> <file-msdos-efi_hsx_diff.DEFANGED-338><file-msdos-efi_hsx_diff_sig.DEFANGED-339><trid-v-efi_hxs.txt.gz><droid-efi_hsx.csv.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/20221121/f3e27e46/attachment.asc>
More information about the File
mailing list