91
TrID File Identifier / Re: Typo in p/pfs-pub.trid.xml
« Last post by Mark0 on May 16, 2024, 05:50:03 PM »Thanks, will fix!
Recent Posts
92
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on May 16, 2024, 01:51:17 PM »Updated:
- Ableton Max Patch (AMXD)
- LZEXE compressed DOS executable (mod) (EXE)
- ArcGIS Map project (MXD)
- Xcode Scheme (XCSCHEME)
- ReqAttack Image ()
- Es.pectrum snapshot (ESP)
- LZEXE compressed DOS executable (v0.90) (EXE)
- LZEXE compressed DOS executable (v0.91) (EXE)
- Es.pectrum snapshot (FSU)
- Joy2Key settings (J2K/CFG/INI)
- Max Project (MAXPROJ)
- Flanker 2.0 Mission data (MIS/TRK)
- DosCapture video card Modes info (MOD)
- Sound library / container (SFX)
- Serial Vector Format (SVF)
- Serial Vector Format (with rem) (SVF)
- Code::Blocks Workspace (WORKSPACE)
- Proteus Workspace (WORKSPACE)
93
TrID File Identifier / Typo in p/pfs-pub.trid.xml
« Last post by Sembiance on May 13, 2024, 08:42:35 PM »Appears to be a typo: <FileType>First Choice Pubblication</FileType>
Probably should be: <FileType>First Choice Publication</FileType>
Probably should be: <FileType>First Choice Publication</FileType>
94
TrID File Identifier / Bug in j/journal-sysd-empty.trid.xml
« Last post by Sembiance on May 13, 2024, 08:15:39 PM »In the defs file j/journal-sysd-empty.trid.xml there is a bug on line 45:
</Pattern>256
That 256 shouldn't be there
</Pattern>256
That 256 shouldn't be there
95
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on May 12, 2024, 05:47:31 PM »Updated:
- Polytron VCS logfile ()
- DIGIPAK audio driver (COM)
- Autodesk Alias 2017 model (WIRE)
- Silverlight Application Package (XAP)
- Silverlight Application Package (encrypted) (XAP)
- Chuck E. Cheese data (CEC)
- Maxon Cinema 4D Coffee shader (COF)
- Maxon Cinema 4D Coffee shader (with rem) (COF)
- MAGGI data (HHH)
- Simulmondo localized game strings (KFR/KGR/KIT/KSP/KUK)
- lDEBUG Extension (ELD/XLD)
- American Laser Games MM video (MM)
- Maxon Cinema 4D 2D Shader (SHV)
- Maxon Cinema 4D 3D Shader (SHV)
- Autodesk STereoLithography (SLA-1 triangle, binary) (STL)
- Autodesk Alias 2011 model (WIRE)
- Autodesk Alias 2012 model (WIRE)
- Autodesk Alias 2015 model (WIRE)
- Autodesk Alias 2018 model (WIRE)
- Autodesk Alias 2019 model (WIRE)
- Autodesk Alias 2020 model (WIRE)
- Autodesk Alias 2021 model (WIRE)
- Autodesk Alias 2022 model (WIRE)
- Autodesk Alias 2023 model (WIRE)
- Autodesk Alias 2024 model (WIRE)
- Autodesk Alias model (generic) (WIRE)
96
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on May 09, 2024, 02:53:22 AM »Added:
97
TrID File Identifier / Re: csv-sbat.trid.xml for SBAT (Secure Boot Advanced Targeting) metadata
« Last post by Mark0 on May 07, 2024, 01:57:59 PM »Thanks!
98
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on May 05, 2024, 02:28:20 PM »Updated:
- Boost serialization archive (binary, 32bit) ()
- Fold compressed archive (ARK)
- OvationPro document (DPD)
- 16bit DOS EXE Fold sfx compressed (v1.x) (EXE)
- Fold compressed (FOL)
- XPK compressed data (XPKF/XPK)
- Boost serialization archive (binary, 64bit) ()
- YAS serialized data (binary) ()
- BootX BootBlocks Library (BBLIB)
- BootX learned bootblocks (BRAIN)
- Dir Logo Maker bitmap (DLM)
- 16bit DOS EXE Fold SFX compressed archive (v1.16e) (EXE)
- STALCRAFT Model (MCSA/MCVD)
- STALCRAFT texture (OL)
- Pack List Archive (PKA)
- BootX bootblock Recognition data (RECOG)
- TommySoftware CAD/Draw Library (v2) (T2L)
- MediaWiki XML export (v1.x) (XML)
99
TrID File Identifier / csv-sbat.trid.xml for SBAT (Secure Boot Advanced Targeting) metadata
« Last post by jenderek on May 02, 2024, 02:48:24 AM »Hello trid users,
some days ago i had trouble with booting UEFI system with GRUB and secure
boot. So i first look at files on EFI partition mounted on /boot/efi. In sub
directory with name like ubuntu i found files like BOOTX64.CSV with file name
suffix CSV.
So i run trid utility on my CSV samples. Most of the samples are not
recognized. Some "artificial" samples with BOM (byte order mark) are described
as "Text - UTF-16 (LE) encoded" by txt-utf-16-le.trid.xml with mime type
text/plain and file name suffix (.TXT) (see appended trid-old.txt
trid-v-old.txt in output).
For comparison reason i also run the file format identification utility DROID
(See https://sourceforge.net/projects/droid/). Here all samples are
recognized. These are described as "Comma Separated Values" by PUID x-fmt/18
with mime type text/csv. But the recognition is here only based on the file
name suffix (see appended droid-sbat.csv in output).
For comparison reason i also run file command (version 5.45) on such
samples. Here most CSV samples especially all real world examples are not
recognized and are described as "data". A few like sbat.csv are described as
"CSV Unicode text" with UTF-16, little-endian encoding. A few are described as
"Unicode text" with UTF-16, little-endian encoding (see appended file-5.45.txt
in output). For the "recognized " samples here mime type text/csv or
text/plain is shown (see appended file-i-5.45.txt in output). Here no file
name suffix is shown (see appended file-ext-5.45.txt in output).
Luckily i found page about UEFI shim boot loader on github web site. So i use
this. So the reference URL in new definition is expressed by line like:
<RefURL>https://github.com/rhboot/shim/blob/main/SBAT.md</RefURL>
Unfortunately there no precisely file format for this CSV is listed here.
Some more details can be found at Rod Smith page about managing EFI boot
loaders for Linux and fallback. See:
https://www.rodsbooks.com/efi-bootloaders/fallback.html
The CSV samples contain comma-separated values (CSV). One line contains 4 data
elements separated by commas (filename, label, options,description).
Unfortunately the exact encoding is not mentioned, but apparently for real
world examples this is UTF-16 (little endian) without BOM (Byte Order
Mark). But i do not know if this always true. So i mention my observations in
the remark line. Because in samples ASCII like strings are stored as UTF-16 LE
i got at odd offset nil bytes. That is expressed by XML constructs like:
<Pattern>
<Bytes>00</Bytes>
<Pos>1</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>3</Pos>
</Pattern>
...
<Pattern>
<Bytes>00</Bytes>
<Pos>107</Pos>
</Pattern>
Maybe that there exist samples with label or description field in
Chinese. Then 16 bits for characters are used and nil bytes at higher offset
will vanish. At the beginning the file name of UEFI bootable is stored. For
system files all operating system i know used English based names. So the nil
bytes at lower offset will probably always be true.
At the beginning the file name of bootable executables is stored. In real
world examples i found here similar strings (shimx64.efi, shimia32.efi,
refind_x64.efi). The UEFI staff is mainly pushed by Intel and Microsoft. The
standard bootable on such systems is like BOOTX64.EFI or bootia32.efi. So i
assume that other partners use the Windows convention to characterize such
bootable executables by 4 byte .efi sting at the end of file name. That is
expressed inside global strings section by line like:
<String>.'E'F'I</String>
So this probably always true.
The description field in my inspected real world samples start with phrase
"This is the boot entry for " followed by Linux distribution name (like redhat
ubuntu). That is expressed inside global strings section by line like:
<String>T'H'I'S' 'I'S' 'T'H'E' 'B'O'O'T' 'E'N'T'R'Y' 'F'O'R</String>
Maybe that there exist some exotic samples with Chinese text. Then the above
construct would be not true any more.
Most Linux (and Windows and macOS) text editors create ASCII files by default
for CSV samples. Or because of nil bytes does not handle the SBAT samples as
text when opening. But as "Text - UTF-16 (LE) encoded" instead of
application/octet-stream get mime type text/plain here we got a similar mime
type. So i choose what is shown by file command and DROID. So this expressed
by line like:
<Mime>text/csv</Mime>
With the new definition such CSV samples are now recognized and described (see
appended trid-v-new.txt trid-new.txt in output).
TrID definitions, some samples and output are stored in archive CSV_.zip. I
hope that my definition can be used in future version of triddefs.
With best wishes
J?rg Jenderek
some days ago i had trouble with booting UEFI system with GRUB and secure
boot. So i first look at files on EFI partition mounted on /boot/efi. In sub
directory with name like ubuntu i found files like BOOTX64.CSV with file name
suffix CSV.
So i run trid utility on my CSV samples. Most of the samples are not
recognized. Some "artificial" samples with BOM (byte order mark) are described
as "Text - UTF-16 (LE) encoded" by txt-utf-16-le.trid.xml with mime type
text/plain and file name suffix (.TXT) (see appended trid-old.txt
trid-v-old.txt in output).
For comparison reason i also run the file format identification utility DROID
(See https://sourceforge.net/projects/droid/). Here all samples are
recognized. These are described as "Comma Separated Values" by PUID x-fmt/18
with mime type text/csv. But the recognition is here only based on the file
name suffix (see appended droid-sbat.csv in output).
For comparison reason i also run file command (version 5.45) on such
samples. Here most CSV samples especially all real world examples are not
recognized and are described as "data". A few like sbat.csv are described as
"CSV Unicode text" with UTF-16, little-endian encoding. A few are described as
"Unicode text" with UTF-16, little-endian encoding (see appended file-5.45.txt
in output). For the "recognized " samples here mime type text/csv or
text/plain is shown (see appended file-i-5.45.txt in output). Here no file
name suffix is shown (see appended file-ext-5.45.txt in output).
Luckily i found page about UEFI shim boot loader on github web site. So i use
this. So the reference URL in new definition is expressed by line like:
<RefURL>https://github.com/rhboot/shim/blob/main/SBAT.md</RefURL>
Unfortunately there no precisely file format for this CSV is listed here.
Some more details can be found at Rod Smith page about managing EFI boot
loaders for Linux and fallback. See:
https://www.rodsbooks.com/efi-bootloaders/fallback.html
The CSV samples contain comma-separated values (CSV). One line contains 4 data
elements separated by commas (filename, label, options,description).
Unfortunately the exact encoding is not mentioned, but apparently for real
world examples this is UTF-16 (little endian) without BOM (Byte Order
Mark). But i do not know if this always true. So i mention my observations in
the remark line. Because in samples ASCII like strings are stored as UTF-16 LE
i got at odd offset nil bytes. That is expressed by XML constructs like:
<Pattern>
<Bytes>00</Bytes>
<Pos>1</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>3</Pos>
</Pattern>
...
<Pattern>
<Bytes>00</Bytes>
<Pos>107</Pos>
</Pattern>
Maybe that there exist samples with label or description field in
Chinese. Then 16 bits for characters are used and nil bytes at higher offset
will vanish. At the beginning the file name of UEFI bootable is stored. For
system files all operating system i know used English based names. So the nil
bytes at lower offset will probably always be true.
At the beginning the file name of bootable executables is stored. In real
world examples i found here similar strings (shimx64.efi, shimia32.efi,
refind_x64.efi). The UEFI staff is mainly pushed by Intel and Microsoft. The
standard bootable on such systems is like BOOTX64.EFI or bootia32.efi. So i
assume that other partners use the Windows convention to characterize such
bootable executables by 4 byte .efi sting at the end of file name. That is
expressed inside global strings section by line like:
<String>.'E'F'I</String>
So this probably always true.
The description field in my inspected real world samples start with phrase
"This is the boot entry for " followed by Linux distribution name (like redhat
ubuntu). That is expressed inside global strings section by line like:
<String>T'H'I'S' 'I'S' 'T'H'E' 'B'O'O'T' 'E'N'T'R'Y' 'F'O'R</String>
Maybe that there exist some exotic samples with Chinese text. Then the above
construct would be not true any more.
Most Linux (and Windows and macOS) text editors create ASCII files by default
for CSV samples. Or because of nil bytes does not handle the SBAT samples as
text when opening. But as "Text - UTF-16 (LE) encoded" instead of
application/octet-stream get mime type text/plain here we got a similar mime
type. So i choose what is shown by file command and DROID. So this expressed
by line like:
<Mime>text/csv</Mime>
With the new definition such CSV samples are now recognized and described (see
appended trid-v-new.txt trid-new.txt in output).
TrID definitions, some samples and output are stored in archive CSV_.zip. I
hope that my definition can be used in future version of triddefs.
With best wishes
J?rg Jenderek
100
Definitions DB change log / Re: Current - Year 2024
« Last post by Mark0 on May 01, 2024, 08:06:13 PM »Updated:
- Krita resource Bundle (BUNDLE)
- GDSII stream format layout (binary) (GDS)
- Open Virtualization Format descriptor (OVF)
- Open Virtualization Format descriptor (UTF-8) (OVF)
- GDSII stream format layout (text format) (TXT)
- Krita layer/tile ()
- Krita Action collection (ACTION)
- 7th Level game data (BIN)
- Krita Color scheme (COLORS)
- Fontconfig Configuration (CONF)
- GFA BASIC Win 3.x compiled Executable (EXE)
- Krita Gamut Mask (KGM)
- Krita SeExpr script (KSE)
- Krita Window Layouts (KWL)
- Krita Workspace (KWS)
- Library Exchange Format (v5.x) (LEF)
- Library Exchange Format (v5.x, with rem) (LEF)
- PC-Label Label (LBL)
- PC-File mail-merge Letter (LTR)
- OASIS stream (OAS)
- Krita input Profile (PROFILE)
- PC-File Report (REP)
- Krita Shorcuts (SHORTCUTS)