11
Recent Posts
12
TrID File Identifier / Re: vstsound.trid.xml for Steinberg VST Sound archive *.vstsound
« Last post by Mark0 on September 02, 2020, 10:58:13 AM »Thanks as usual!
13
TrID File Identifier / vstsound.trid.xml for Steinberg VST Sound archive *.vstsound
« Last post by jenderek on August 31, 2020, 10:35:51 PM »Hello trid users,
some days ago i handled some Steinberg Cubase files with vstsound file name
extension. This are described by TrID as "Unknown!" (See appended
output/trid.txt)
The samples are found as part of a Steinberg Cubase software installation.
So i add Wikipedia page about Steinberg Cubase as reference URL. This is
expressed line like:
<RefURL>
http://en.wikipedia.org/wiki/Steinberg_Cubase
</RefURL>
The samples with vstsound are listed then in the registry. This is expressed by
line like:
<FileType>Steinberg VST Sound archive</FileType>
So i run tridscan on these samples and i get a trid definition file
vstsound.trid.xml.
Characteristic for such Steinberg files is a typical ASCII phrase as first
line. That is expressed by XML construct like:
<Bytes>537465696E62657267205265736F757263652046696C650D0A</Bytes>
<ASCII> S t e i n b e r g R e s o u r c e F i l e</ASCII>
<Pos>0</Pos>
Furthermore the phrase Content occurs in all samples. That is expressed in
global string section by line like:
<String>CONTENT</String>
With the new definition the undetected Steinberg VSTSOUND samples are now
described (see appended output/trid-new-v.txt). TrID definition, some
examples and output are stored in archive vstsound.zip. I hope that my XML
file can be used in future version of triddefs.
With best wishes
Jörg Jenderek
some days ago i handled some Steinberg Cubase files with vstsound file name
extension. This are described by TrID as "Unknown!" (See appended
output/trid.txt)
The samples are found as part of a Steinberg Cubase software installation.
So i add Wikipedia page about Steinberg Cubase as reference URL. This is
expressed line like:
<RefURL>
http://en.wikipedia.org/wiki/Steinberg_Cubase
</RefURL>
The samples with vstsound are listed then in the registry. This is expressed by
line like:
<FileType>Steinberg VST Sound archive</FileType>
So i run tridscan on these samples and i get a trid definition file
vstsound.trid.xml.
Characteristic for such Steinberg files is a typical ASCII phrase as first
line. That is expressed by XML construct like:
<Bytes>537465696E62657267205265736F757263652046696C650D0A</Bytes>
<ASCII> S t e i n b e r g R e s o u r c e F i l e</ASCII>
<Pos>0</Pos>
Furthermore the phrase Content occurs in all samples. That is expressed in
global string section by line like:
<String>CONTENT</String>
With the new definition the undetected Steinberg VSTSOUND samples are now
described (see appended output/trid-new-v.txt). TrID definition, some
examples and output are stored in archive vstsound.zip. I hope that my XML
file can be used in future version of triddefs.
With best wishes
Jörg Jenderek
14
Definitions DB change log / Re: Current
« Last post by Mark0 on August 30, 2020, 06:06:08 PM »Updated:
Added:
Added:
15
TrID File Identifier / Re: exe-cafe.trid.xml for Mac OS X Mach-O universal executables with CAFEBABE magic
« Last post by Mark0 on August 28, 2020, 10:15:14 PM »TrID/TrIDScan looks for patterns in the first 2KB, so that's why the one at offset 4096 isn't detected.
I'll definitely have to find a bigger sample set of this filetype.
Thanks!
I'll definitely have to find a bigger sample set of this filetype.
Thanks!
16
TrID File Identifier / exe-cafe.trid.xml for Mac OS X Mach-O universal executables with CAFEBABE magic
« Last post by jenderek on August 27, 2020, 09:09:38 PM »Hello trid users,
some days ago i run TrID on about hundreds of Mac OS X Mach-O
universal executables found in /sbin, /sbin and /usr/bin directory on
a Mac OS X system.
Many are misidentified as Mac OS X Mach-O universal Dynamically linked
shared Library (*.dylib) by dylib-cafe.trid.xml and a few like
db_codegen are misidentified by java-class.trid.xml as Java byte code
(*.class). 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) because all such files start with CAFEBABE
magic string.
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 "executable" (See appended
output/file-5.39.txt), because the file command use another method to
detect such executables.
So i run tridscan on such executables to create exe-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>
As on other UNIX like systems the executables normally have no file
extension. But in my /usr/bin directory different versions of perl
executable exist (perl5.18 perl5.16 perl). There version string is
appended to main name. This becomes in trid definition a line like:
<Ext>16/18</Ext>
When looking in exe-cafe.trid.xml i see in global string section lines,
which maybe are generated by lucky circumstances like:
<String>060425214036Z</String>
Apparently all executables are digitally signed by Apple. This is
expressed by lines like:
<String>*APPLE CODE SIGNING CERTIFICATION AUTHORITY0</String>
<String>CRL.APPLE.COM</String>
<String>APPLE CERTIFICATION AUTHORITY1301</String>
I am no Apple expert, so i do not know if there can exist examples
which are not digitally signed or signed by others. If other users
know such things, then please inform me or run tridscan with such
samples to improve TrID definition file.
All my inspected samples are binary with 2 architectures. This
together with the CAFEBABE magic is expressed by pattern like:
<Bytes>CAFEBABE00000002</Bytes>
<Pos>0</Pos>
All my samples start with x86 (i396 or x86_64 like in uuidgen) CPU
binary as first at offset 0x1000. This is expressed by patterns like:
<Pattern>
<Bytes>000007</Bytes>
<Pos>9</Pos>
</Pattern>
<Pattern>
<Bytes>0000030000100000</Bytes>
<Pos>13</Pos>
</Pattern>
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 executables
are described correctly ( see appended output/trid-new.txt). TrID
definition, some examples and output are stored in archive exe-macho.zip. I
hope that the new XML file can be used in future version of triddefs.
When comparing that new definition file with others like o-cafe.trid.xml
or dylib-cafe.trid.xml, these look much the same. The only difference
i see is expressed by 1 line like:
<String>__MH_EXECUTE_HEADER'_</String>
Value 2 is declared as MH_EXECUTE inside macho header file loader.h,
which is used for demand paged executables. That method for
recognition is used by file command. For my 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 demand paged
executables this value is 2 declared via MH_EXECUTE constant. I do not
know why tridscan does not recognize that structure. So i create a
variant exe-cafe-id1.trid.xml where i check for that magic and file
type value by additional constructs like:
<Bytes>CEFAEDFE</Bytes>
<Pos>4096</Pos>
<Bytes>02000000</Bytes>
<Pos>4108</Pos>
For dylib often the offset to first mach binary 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.
According to header file there seems to exist about a dozen of
different file types. Highest value is 0xb by constant MH_KEXT_BUNDLE
for x86_64 kexts. At the moment only for 4 different file types
(MH_OBJECT=0x1, MH_EXECUTE=0x2, MH_DYLIB=0x6 and MH_BUNDLE=0x8) are
described by dedicated TriD definitions.
With best wishes
Jörg Jenderek
some days ago i run TrID on about hundreds of Mac OS X Mach-O
universal executables found in /sbin, /sbin and /usr/bin directory on
a Mac OS X system.
Many are misidentified as Mac OS X Mach-O universal Dynamically linked
shared Library (*.dylib) by dylib-cafe.trid.xml and a few like
db_codegen are misidentified by java-class.trid.xml as Java byte code
(*.class). 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) because all such files start with CAFEBABE
magic string.
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 "executable" (See appended
output/file-5.39.txt), because the file command use another method to
detect such executables.
So i run tridscan on such executables to create exe-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>
As on other UNIX like systems the executables normally have no file
extension. But in my /usr/bin directory different versions of perl
executable exist (perl5.18 perl5.16 perl). There version string is
appended to main name. This becomes in trid definition a line like:
<Ext>16/18</Ext>
When looking in exe-cafe.trid.xml i see in global string section lines,
which maybe are generated by lucky circumstances like:
<String>060425214036Z</String>
Apparently all executables are digitally signed by Apple. This is
expressed by lines like:
<String>*APPLE CODE SIGNING CERTIFICATION AUTHORITY0</String>
<String>CRL.APPLE.COM</String>
<String>APPLE CERTIFICATION AUTHORITY1301</String>
I am no Apple expert, so i do not know if there can exist examples
which are not digitally signed or signed by others. If other users
know such things, then please inform me or run tridscan with such
samples to improve TrID definition file.
All my inspected samples are binary with 2 architectures. This
together with the CAFEBABE magic is expressed by pattern like:
<Bytes>CAFEBABE00000002</Bytes>
<Pos>0</Pos>
All my samples start with x86 (i396 or x86_64 like in uuidgen) CPU
binary as first at offset 0x1000. This is expressed by patterns like:
<Pattern>
<Bytes>000007</Bytes>
<Pos>9</Pos>
</Pattern>
<Pattern>
<Bytes>0000030000100000</Bytes>
<Pos>13</Pos>
</Pattern>
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 executables
are described correctly ( see appended output/trid-new.txt). TrID
definition, some examples and output are stored in archive exe-macho.zip. I
hope that the new XML file can be used in future version of triddefs.
When comparing that new definition file with others like o-cafe.trid.xml
or dylib-cafe.trid.xml, these look much the same. The only difference
i see is expressed by 1 line like:
<String>__MH_EXECUTE_HEADER'_</String>
Value 2 is declared as MH_EXECUTE inside macho header file loader.h,
which is used for demand paged executables. That method for
recognition is used by file command. For my 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 demand paged
executables this value is 2 declared via MH_EXECUTE constant. I do not
know why tridscan does not recognize that structure. So i create a
variant exe-cafe-id1.trid.xml where i check for that magic and file
type value by additional constructs like:
<Bytes>CEFAEDFE</Bytes>
<Pos>4096</Pos>
<Bytes>02000000</Bytes>
<Pos>4108</Pos>
For dylib often the offset to first mach binary 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.
According to header file there seems to exist about a dozen of
different file types. Highest value is 0xb by constant MH_KEXT_BUNDLE
for x86_64 kexts. At the moment only for 4 different file types
(MH_OBJECT=0x1, MH_EXECUTE=0x2, MH_DYLIB=0x6 and MH_BUNDLE=0x8) are
described by dedicated TriD definitions.
With best wishes
Jörg Jenderek
17
Definitions DB change log / Re: Current
« Last post by Mark0 on August 27, 2020, 03:21:15 AM »Updated:
Added:
Added:
18
TrID File Identifier / Re: o-cafe.trid.xml for Mac OS X Mach-O universal object (*.o)
« Last post by Mark0 on August 26, 2020, 01:36:07 PM »The pattern at offset 4108 is not detected because TrID/TrIDScan check the first 2KB.
Thanks for the new def!
Thanks for the new def!
19
TrID File Identifier / o-cafe.trid.xml for Mac OS X Mach-O universal object (*.o)
« Last post by jenderek on August 25, 2020, 11:04:41 PM »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
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
20
TrID File Identifier / Re: replacement for java-class.trid.xml, exe-ub.trid.xml; CAFEBABE magic
« Last post by Mark0 on August 25, 2020, 09:44:49 PM »Will check, thanks!