Hello trid users,
some days ago i run TrID on hundreds of Mac OS X Mach-O universal
objects (*.o). All are also described in general by exe-ub.trid.xml
as "Mac OS X Universal Binary executable" (see appended
output/trid-v-old.txt).
The file command {See
https://en.wikipedia.org/wiki/File_(command)}describes my inspected examples correctly like "Mach-O universal
binary" with sub type classification "object" (See appended
output/file-5.39.txt), because the file command use another method to
detect such libraries archives.
So i run tridscan on such bundle files to create o-cafe.trid.xml
definition file.
I add here again web page about Mach-O file format on Wikipedia. That is now
expressed by line like:
<RefURL>
https://en.wikipedia.org/wiki/Mach-O</RefURL>
Instead generic application/octet-stream the file command shows a user
defined type (See appended output/file-i-5.39.txt). So i changed in trid
definition file mime type. This is now shown by updated line like:
<Mime>application/x-mach-binary</Mime>
When looking in o-cafe.trid.xml i see in global string section lines,
which maybe are generated by lucky circumstances like:
<String>___DSO_HANDLE</String>
I was not able to remove such strings, because definition file is based
on only 8 object files.
All my inspected samples are binary with 2 architectures with i386 CPU binary
as first. This together with the CAFEBABE magic is expressed by pattern
like:
<Bytes>CAFEBABE000000020000000700000003000010000000</Bytes>
So i hope that other users can improve the definition file by running
tridscan on bundles with other and more CPU architectures.
With the new trid definition file now my Mac OS X Mach-O universal bundle
are described correctly ( see appended output/trid-new.txt). TrID
definition, some examples and output are stored in archive o.zip. I
hope that the new XML file can be used in future version of triddefs.
Value 1 is declared as MH_OBJECT inside macho header file loader.h,
which is used for relocatable object files. That method for
recognition is used by file command. For my few samples the offset to
first mach_header was 0x1000 (4096). There i found MH_MAGIC. For
little endian this is MH_CIGAM or 0xcefaedfe in hexadecimal. Relative
at offset 12 the file type is stored as long integer. For relocatable
object file this value is 1 declared via MH_OBJECT constant. I do not
know why tridscan does not recognize that structure. So i create a
variant o-cafe-id1.trid.xml where i check for that file type value by
additional construct like:
<Bytes>01000000</Bytes>
<Pos>4108</Pos>
For dylib often the offset to first mach was also 0x1000 in many case
but not always. So maybe there exist samples with other offsets,
which of course are not recognized by variant.
With best wishes
Jörg Jenderek
