Hello trid users,
Some days ago i handled some MZ executables. Some have the file name
extension MUN. All my inspected samples are found i sub directory
SystemResources (probably linked) or somewhere (probably the original) in
sub directory WinSxS inside Windows folder on newer Windows systems (10 and
11).
So i run trid utility on my MUN examples. All are described in principal
correctly as "Win32 Executable (generic)" by exe-win.trid.xml with generic
mime type application/octet-stream and wrong extension EXE (See appended
output/trid-v-old.txt). But some are described with high rate as "Microsoft
Resource Library (x86)" by rll.trid.xml (See appended
mun_rll/output/trid-v-old.txt).
For comparison reason i also run file command (newest official version 5.43)
on such samples. Here these are described as "PE32 executable" with sub
classification as "(DLL)" and "Intel 80386" (See appended
output/file-5.43.txt) but with wrong mime type application/x-dosexec (See
appended output/file-i-5.43.txt) and wrong extensions
dll/cpl/tlb/ocx/acm/ax/ime (See appended output/file-ext.txt). The newest
file command (msdos,v 1.161 2022/11/21) now describes the MUN samples with
an additional phrase "2 sections" (See appended output/file.txt). It now
shows another more suited application/vnd.microsoft.portable-executable mime
type (See appended output/file-i.txt).
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). Here all samples are
described at least as "Windows Portable Executable" with mime type
application/vnd.microsoft.portable-executable and version phrase "32 bit" by
PUID fmt/899.
Unfortunately i found no page about MUN file format and especially from
Microsoft. Luckily a little bit of information is found on pages about file
name extension. This is expressed by line like:
<RefURL>
https://fileinfo.com/extension/mun</RefURL>
Apparently the MUN examples are just used as containers for Windows
resources like icons. That can be seen when you open such files for examples
by tools like Resource Hacker. So the library format is abused as container.
For the MUN format exist no own mime type. So MUN examples should get mime
type of container format. That is done by DROID and newest file command. So
this is now expressed by line like:
<Mime>application/vnd.microsoft.portable-executable</Mime>
So run tridscan on my dozens of MUN examples and generate a definition
mun.trid.xml. In definition inside front block exist a XML pattern like:
<Bytes>528C00000000000000000000000000000000504500004C010200</Bytes>
<ASCII> R . . . . . . . . . . . . . . . . . P E . . L</ASCII>
<Pos>166</Pos>
If a XML construct contains such a string like pattern then inside global
strings an equivalent line occur like:
<String>PE''L</String>
So the byte sequence PE\0\0 means sub classification as PE32 executable or
library .
So that means new exe header starts at offset 184 (hexadecimal B8). The
offset to new exe header is stored at offset 60 (hexadecimal 3C) as 4 byte
little endian integer variable e_lfanew. According to Microsoft
documentation after the PE magic comes the machine type as 2 byte little
endian integer. For Intel 386 as shown by file command this value is 014c
(in little endian or 4C01 as byte sequence or L\001 as string). If there
exist variant for x64 marked by phrase "x86-64" via file command that value
would be 8664 (in little endian or 6486 as byte sequence or d\x86 as
string).
After the machine type the number of sections is stored as 2 byte little
endian integer. Reported by newest file command is for MUN examples is here
the value 2. For real PE executables or libraries this value is
higher. Three is a typical value for sections of code, data and
resources. With help of PE dump tools like pelook we can see these two
sections. Apparently the resources are stored inside a section with name
.rsrc. And the other section for debugging has name .rdata. So these facts
are expressed inside global strings sections by lines like:
<String>.RDATA$ZZZDBG</String>
<String>.RSRC$01</String>
<String>.RSRC$02</String>
And apparently these 2 section seem to be stored at fixed positions. That is
expressed inside Front Block section by XML constructs like:
<Bytes>00000000 72646174610000</Bytes>
<ASCII> . . . . r d a t a</ASCII>
<Pos>357</Pos>
<Bytes>000000001000000002000000020000000000000000000000000000400000402E72737263
<ASCII> . . . . . . . . . . . . . . . . . . . . . . . . . . . @ . . @ . r s r c
<Pos>441</Pos>
For MUN examples the Windows library format (normally DLL) is used. To avoid
running such samples on DOS it contains a DOS executable stub to avoid this
action. The default compiler option is to add an DOS executable that display
a message text "This program cannot be run in DOS mode". That is expressed
inside global strings section by line like:
<String>THIS PROGRAM CANNOT BE RUN IN DOS MODE.</String>
And in front block this is expressed by XML construct like:
<ASCII> M Z . . . L . ! T h i s p r o g r a m c a n n o t b e r u n i n D O S m o d e . . . . $</ASCII>
<Pos>0</Pos>
But i do not know if this always true.
The library contain a not official documented MS Rich header. PE dump tools
( like pelook with rh option) can show this. This contain information about
used linker version. In my examples this start at offset 80 ( hexadecimal or
128 decimal ) with a size of 40 bytes til 168 offset. So this is expressed
inside global strings section by line like:
<String>RICH</String>
And inside front block this is expressed by XML constructs like:
<Pattern>
<Bytes>3CDF</Bytes>
<Pos>130</Pos>
</Pattern>
<Pattern>
<Bytes>528C</Bytes>
<ASCII> R</ASCII>
<Pos>134</Pos>
</Pattern>
<Pattern>
<Bytes>528C</Bytes>
<ASCII> R</ASCII>
<Pos>138</Pos>
</Pattern>
<Pattern>
<Bytes>528C</Bytes>
<ASCII> R</ASCII>
<Pos>142</Pos>
</Pattern>
<Pattern>
<Bytes>AD8C</Bytes>
<Pos>146</Pos>
</Pattern>
<Pattern>
<Bytes>528C</Bytes>
<ASCII> R</ASCII>
<Pos>150</Pos>
</Pattern>
<Pattern>
<Bytes>508D</Bytes>
<ASCII> P</ASCII>
<Pos>154</Pos>
</Pattern>
<Pattern>
<Bytes>528C52696368</Bytes>
<ASCII> R . R i c h</ASCII>
<Pos>158</Pos>
</Pattern>
But i do not know if this is always true.
Because generated definition is based on only a few dozen examples so i
assume i get some short patterns. That are probably expressed by XML
constructs like:
<Pattern>
<Bytes>0000000000</Bytes>
<Pos>212</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>1178</Pos>
</Pattern>
So i assume these will vanish when running tridscan with more examples. But
i do not know for sure. So i keep them at the moment and hope that other
users will refine that definition.
The library contain a version part. PE dump tools (like pelook with -v
option) can show this. These facts are expressed inside global strings
section by lines like:
<String>O'R'I'G'I'N'A'L'F'I'L'E'N'A'M'E</String>
<String>F'I'L'E'D'E'S'C'R'I'P'T'I'O'N</String>
<String>P'R'O'D'U'C'T'V'E'R'S'I'O'N</String>
<String>L'E'G'A'L'C'O'P'Y'R'I'G'H'T</String>
<String>I'N'T'E'R'N'A'L'N'A'M'E</String>
<String>F'I'L'E'V'E'R'S'I'O'N</String>
<String>P'R'O'D'U'C'T'N'A'M'E</String>
<String>C'O'M'P'A'N'Y'N'A'M'E'''''M'I'C'R'O'S'O'F'T' 'C'O'R'P'O'R'A'T'I'O'N</String>
<String>M'I'C'R'O'S'O'F'T' 'C'O'R'P'O'R'A'T'I'O'N'.' 'A'L'L' 'R'I'G'H'T'S' 'R'E'S'E'R'V'E'D'.</String>
Apparently all MUN samples are produced by Microsoft and no other company.
Unfortunately there exist no file format specification for MUN files and it
also not explained what is the difference to RLL libraries.
With the new trid definition now my MUN examples are more precisely
described (see appended output/trid-v-news.txt). TrID definitions and output
are stored in archive mun_.zip. I hope that my definition can be used in
future version of triddefs.
With best wishes
Jörg Jenderek
