[File] [PATCH] of Magdir/msdos PE32 executable some missed or wrong *.EFI *.HXS

Jörg Jenderek joerg.jen.der.ek at gmx.net
Mon Nov 21 20:45:15 UTC 2022


-----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-----
-------------- next part --------------
--- file-master/magic/Magdir/msdos.old	2022-11-18 22:28:46.574436600 +0100
+++ file-master/magic/Magdir/msdos	2022-11-21 18:20:07.381476000 +0100
@@ -97,3 +97,5 @@
 # no examples found for ZM DL MP P2 P3
-#>(0x3c.l)	string		x	\b, at 0x3c %.2s
+#>(0x3c.l)	string		x	\b, at [0x3c] %.2s
+#>(0x3c.l)	ubelong		x	\b, at [0x3c] %#8.8x
+#>(0x3c.l+4)	ubelong		x	\b, at [0x3c+4] %#8.8x
 #
@@ -141,3 +143,3 @@
 # DLL Characteristics
-#>>(0x3c.l+22)	leshort		x	\b, CHARACTERISTICS 0x%x
+#>>(0x3c.l+22)	uleshort	x	\b, CHARACTERISTICS %#4.4x,
 # 0x0200~IMAGE_FILE_DEBUG_STRIPPED Debugging information is removed from the image file
@@ -145,5 +147,7 @@
 # 0x2000~IMAGE_FILE_DLL The image file is a dynamic-link library (DLL)
-#>>(0x3c.l+92)	leshort		x	\b, SUBSYSTEM %u
 >>(0x3c.l+24)	leshort		0x010b	\b32 executable
+# https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#windows-subsystem
+#>>>(0x3c.l+92)	leshort		x	\b, SUBSYSTEM %u
 >>(0x3c.l+24)	leshort		0x020b	\b32+ executable
+#>>>(0x3c.l+92)	leshort		x	\b, SUBSYSTEM %u
 >>(0x3c.l+24)	leshort		0x0107	ROM image
@@ -152,2 +156,17 @@
 >>(0x3c.l+22)	leshort&0x2000	>0	(DLL)
+# 0~IMAGE_SUBSYSTEM_UNKNOWN An unknown subsystem
+>>(0x3c.l+92)	leshort		0	(
+# Summary:	Microsoft compiled help *.HXS format 2.0
+# 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
+# Note:		2 PE sections (.rsrc, .its) implies Microsoft compiled help format; the .its section contains the help content ITOLITLS
+#		verified by command like `pelook.exe -d WINWORD.HXS & pelook.exe -h WINWORD.HXS`
+>>>(0x3c.l+6)	uleshort	=2	\bMicrosoft compiled help format 2.0)
+!:ext	hxs
+# 3 PE sections (.text, .reloc, .rsrc) implies some Control Panel Item like: 
+# CPL:	Control Panel item for WINE 1.7.28	https://www.winehq.org/
+>>>(0x3c.l+6)	uleshort	!2	\bControl Panel Item)
+!:ext	cpl
+# 1~IMAGE_SUBSYSTEM_NATIVE device drivers and native Windows processes 
 >>(0x3c.l+92)	leshort		1
@@ -159,2 +178,3 @@
 !:ext	exe/sys
+# 2~IMAGE_SUBSYSTEM_WINDOWS_GUI	The Windows graphical user interface (GUI) subsystem 
 >>(0x3c.l+92)	leshort		2
@@ -174,2 +194,3 @@
 !:ext	exe/scr
+# 3~IMAGE_SUBSYSTEM_WINDOWS_CUI	The Windows character subsystem 
 >>(0x3c.l+92)	leshort		3
@@ -179,12 +200,62 @@
 !:ext	exe/com
-# https://docs.microsoft.com/en-us/windows/win32/debug/pe-format
->>(0x3c.l+92)	leshort		7	(POSIX)
->>(0x3c.l+92)	leshort		9	(Windows CE)
+# NO Windows Subsystem number 4!
+>>(0x3c.l+92)	leshort		4	(Unknown subsystem 4)
+# 5~IMAGE_SUBSYSTEM_OS2_CUI The OS/2 character subsystem 
+>>(0x3c.l+92)	leshort		5	(OS/2)
+# GRR: No examples found by Joerg Jenderek
+#!:ext	foo-exe-os2
+# NO Windows Subsystem number 6!
+>>(0x3c.l+92)	leshort		6	(Unknown subsystem 6)
+# 7~IMAGE_SUBSYSTEM_POSIX_CUI The Posix character subsystem 
+>>(0x3c.l+92)	leshort		7	(POSIX
+>>>(0x3c.l+22)	leshort&0x2000	>0	\b)
+# like: PSXDLL.DLL
+!:ext	dll
+>>>(0x3c.l+22)	leshort&0x2000	0	\b)
+# like: PAX.EXE
+!:ext	exe
+# 8~IMAGE_SUBSYSTEM_NATIVE_WINDOWS Native Win9x driver 
+>>(0x3c.l+92)	leshort		8	(Win9x)
+# GRR: No examples found by Joerg Jenderek
+#!:ext	foo-exe-win98
+# 9~IMAGE_SUBSYSTEM_WINDOWS_CE_GUI Windows CE
+>>(0x3c.l+92)	leshort		9	(Windows CE
+>>>(0x3c.l+22)	leshort&0x2000	>0	\b)
+# like: MCS9900Ce50.dll Mosiisr99x.dll TMCGPS.DLL
+!:ext	dll
+>>>(0x3c.l+22)	leshort&0x2000	0	\b)
+# like: NNGStart.exe navigator.exe
+!:ext	exe
+# 10~IMAGE_SUBSYSTEM_EFI_APPLICATION An Extensible Firmware Interface (EFI) application 
 >>(0x3c.l+92)	leshort		10	(EFI application)
+# like: bootmgfw.efi grub.efi gdisk_x64.efi Shell_Full.efi shim.efi syslinux.efi
+!:ext	efi
+# 11~IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_DRIVER An EFI driver with boot services 
 >>(0x3c.l+92)	leshort		11	(EFI boot service driver)
+# like: ext2_x64_signed.efi Fat_x64.efi iso9660_x64_signed.efi
+!:ext	efi
 >>(0x3c.l+92)	leshort		12	(EFI runtime driver)
+# no sample found
+!:ext	efi
+# 13~IMAGE_SUBSYSTEM_EFI_ROM An EFI ROM image
 >>(0x3c.l+92)	leshort		13	(EFI ROM)
+# no sample found
+!:ext	efi
+# 14~IMAGE_SUBSYSTEM_XBOX XBOX 
 >>(0x3c.l+92)	leshort		14	(XBOX)
->>(0x3c.l+92)	leshort		15	(Windows boot application)
->>(0x3c.l+92)	default		x	(Unknown subsystem
+#!:ext	foo-xbox
+# NO Windows Subsystem number 15!
+>>(0x3c.l+92)	leshort		15	(Unknown subsystem 15)
+# 16~IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION Windows boot application
+>>(0x3c.l+92)	leshort		16	(Windows boot application
+>>>(0x3c.l+22)	leshort&0x2000	>0	\b)
+# like: bootvhd.dll bootuwf.dll hvloader.dll tcbloader.dll bootspaces.dll
+!:ext	dll
+>>>(0x3c.l+22)	leshort&0x2000	0	\b)
+# like: bootmgr.efi memtest.efi shellx64.efi memtest.exe winload.exe winresume.exe bootvhd.dll hvloader.dll
+!:ext	efi/exe
+# GRR: the next 2 lines are not executed!
+#>>(0x3c.l+92)	default		x	(Unknown subsystem
+#>>>&0		leshort		x	%#x)
+>>(0x3c.l+92)	leshort		>16	(Unknown subsystem
 >>>&0		leshort		x	%#x)
@@ -259,2 +330,4 @@
 >>(0x3c.l+6)	leshort			>1	\b, %u sections
+# do not display for 1 section to get output like in version 5.43 and to keep output columns low
+#>>(0x3c.l+6)	leshort			=1	\b, %u section
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-msdos-efi_hsx.diff.sig
Type: application/octet-stream
Size: 2085 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20221121/74a7e2d6/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trid-v-efi_hxs.txt.gz
Type: application/x-gzip
Size: 1889 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20221121/74a7e2d6/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: droid-efi_hsx.csv.gz
Type: application/x-gzip
Size: 879 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20221121/74a7e2d6/attachment-0003.bin>


More information about the File mailing list