Recent Posts

Pages: 1 ... 8 9 [10]
91
TrID File Identifier / Re: gkb.trid.xml for GRUB keyboard *.GKB
« Last post by Mark0 on November 26, 2023, 05:45:47 PM »
Thanks!
92
TrID File Identifier / Re: mml-fm.trid.xml for FrameMaker Maker Markup Language file
« Last post by Mark0 on November 26, 2023, 05:41:48 PM »
Thanks for the new def!
93
TrID File Identifier / Re: updated bfont.trid.xml for FrameMaker Bitmapped screen Font
« Last post by Mark0 on November 26, 2023, 05:38:45 PM »
Thanks for the update!
94
TrID File Identifier / gkb.trid.xml for GRUB keyboard *.GKB
« Last post by jenderek on November 23, 2023, 07:26:21 PM »
Hello trid users,

some days ago i installed a new Linux system on my PC.  For security reasons i
wanted some complicated password with special characters. Unfortunately this
does not work out of the box for my system with German keyboard. After a
nightmare session i find that i myself must create keyboard modules (*.GKB)
for GRUB boot loader and insert instruction inside configuration grub.cfg to
use this.

GRUB is the GRand Unified Boot loader of/for GNU found on their website. That
is expressed by line like:

   <RefURL>https://www.gnu.org/software/grub</RefURL>

When i run TrID on such examples these are described wrong like
"PrintFox/Pagefox bitmap (640x400" by definition bitmap-printfox-g.trid.xml
(see appended output/trid-v-old.txt).

For comparison reason i also run the file utility (version 5.42). This
describes the examples as data" (see appended output/file-5.42.txt). I also
run a file command (version 5.42). Now my samples are described as "GRUB
Keyboard" with some additional information about keys like q and z which are
different on non English keyboards like German and french (see appended
output/file-5.45). Now as file name suffix gkb is shown (see appended
output/file-ext-5.45.txt). As mime type now application/x-grub-keyboard is
shown (see appended output/file-i-5.45.txt).

So i run tridscan on my examples to generate gkb.trid.xml for GRUB Keyboard
(*.GKB )

In source of GRUB there exist header file keyboard_layouts.h and c-source
keylayouts.c with needed information about file format.  So it is possible to
interpret first XML construct. This looks like:

   <Bytes>475255424C41594F0A00000000000000000000000000000000000000</Bytes>
   <ASCII> G R U B L A Y O</ASCII>
   <Pos>0</Pos>

According to that documentation samples start with 8 byte magic string named
GRUB_KEYBOARD_LAYOUTS_FILEMAGIC. Afterward the version is stored as 4 byte
integer, which is in current version value 10.

I am not a c programmer, but if i under stand source right afterwards comes
four keyboard layout with 160 elements, where every element has a size of 32
bit. First comes the normal keyboard. This is followed by the "shift" variant
and so on. So with 4 such structures i get file size 2572 { 8 (magic) + 4
(version) + 4*160*4 (keyboard structures) }.

By lucky circumstances my few keyboard layouts look similar. So the structures
grub_keyboard_layout look the same.

Assuming that other more exotic keyboard layouts exist the first XML construct
now becomes like:
   <Pattern>
      <Bytes>475255424C41594F0A0000000</Bytes>
      <ASCII> G R U B L A Y O</ASCII>
      <Pos>0</Pos>
   </Pattern>

In the structure an element is stored as 32 bit type. If something like pure
letter q press is stored in map then 3 byte are unused. This situation happen
many times. So this give many short nil sequences like:
   <Pattern>
      <Bytes>000000</Bytes>
      <Pos>29</Pos>
   </Pattern>
   <Pattern>
      <Bytes>000000</Bytes>
      <Pos>33</Pos>
   </Pattern>
But it may be possible to store exotic characters in the map. So i delete such
patterns.

There exist also some longer non nil patterns like:
   <Pattern>
      <Bytes>0000000A0000001B0000000800000009000000</Bytes>
      <Pos>169</Pos>
   </Pattern>
I assume that this also triggered by lucky circumstances (often same keys on
European keyboards). So i also delete such constructs.

With the new definition now all my GRUB keyboards are described more precisely
( see appended output/trid-v-new.txt). TrID definition and output are stored
in archive gkb-2.zip. I hope that the XML file can be used in future version
of triddefs.

With best wishes
Jörg Jenderek
95
TrID File Identifier / mml-fm.trid.xml for FrameMaker Maker Markup Language file
« Last post by jenderek on November 22, 2023, 08:35:47 PM »
Hello trid users,

some days ago i handled files with suffix HLP. Unfortunately these extension
is used by different programs for their internal help documentation. Some of
such files are used in context of Adobe FrameMaker.

But before handling the concerned HLP files i must identify some companion
files. In this session i will handle samples with file name suffix MML.

So i run trid utility on such MML examples. All samples are not recognized and
are described as "Unknown!" (see appended 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 not
recognized.

For comparison reason i also run file command (version 5.45) on such
samples. Here such samples are recognized and described here as "FrameMaker
MML file" (see appended output/file-5.45.txt). The mime type here is
application/x-mif (see appended file-i-5.45.txt in output). The file name
suffix is also not recognized (see appended file-ext-5.45.txt in output).

On Linux according to shared MIME-info database such samples are called "Adobe
FrameMaker document" or "Adobe-FrameMaker-Dokument" with German language. The
samples are recognized by looking for less character followed by phrase MML at
the beginning.

That is in principal the same as i got when running tridscan on my samples.
There this is expressed inside front block by XML construct like:
   <Pattern>
      <Bytes>3C4D4D4C</Bytes>
      <ASCII> . M M L</ASCII>
      <Pos>0</Pos>
   </Pattern>

That information can be found in source freedesktop.org.xml.in found for
examples on gitlab.freedesktop.org. Here only suffix is FM listed. I believe
this is triggered because for usual FrameMaker Documents this is the file name
suffix.
 
Instead of generic mime type text/plain i choose the type used for "usual"
FrameMaker Documents and also used by shared mime database.  So this expressed
in definition by line like:
    <Mime>application/vnd.framemaker</Mime>

I do not like the description o file command, because it contains abbreviation
MML. So i look how others call such files by following URL:
       https://file-extension.net/seeker/file_extension_mml
So i choose name which seems to describe such samples best. This is expressed
by line like:
   <FileType>FrameMaker Maker Markup Language file</FileType>

Unfortunately i found no file format for Adobe FrameMaker MML. So i choose the
page about Adobe FrameMaker on Wikipedia. So that is now expressed by line
like:
   <RefURL>https://en.wikipedia.org/wiki/Adobe_FrameMaker</RefURL>

Inside global strings i get lines with phrase fragments like:
      <String>E FO</String>
      <String>TION</String>
I guess that these are triggered by lucky circumstances (too few examples). So
i delete such lines.

With this new trid definition mml-fm.trid.xml my FrameMaker MML samples are
now recognized and described (see appended trid-v-new.txt in output).

TrID definition and output are stored in archive MML.zip. I hope that my
definition can be used in future version of triddefs.

With best wishes
Jörg Jenderek
96
TrID File Identifier / updated bfont.trid.xml for FrameMaker Bitmapped screen Font
« Last post by jenderek on November 22, 2023, 06:57:33 PM »
Hello trid users,

some days ago i handled files with suffix HLP. Unfortunately these extension
is used by different programs for their internal help documentation. Some of
such files are used in context of Adobe FrameMaker.

But before handling the concerned HLP files i must identify some companion
files. In this session i will handle samples with suffix BFONT.

So i run trid utility on such BFONT examples. All samples are recognized and
are described as "FrameMaker Bitmapped screen Font". As mime type only generic
application/octet-stream is shown and as file name suffix BFONT is shown see
appended 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 not
recognized.

For comparison reason i also run file command (version 5.45) on such
samples. Here such samples are also recognized and described here as
"FrameMaker Font file" with additional version number string(see appended
output/file-5.45.txt). The mime type here is application/x-mif (see appended
file-i-5.45.txt in output). The file name suffix is also not recognized (see
appended file-ext-5.45.txt in output).

On Linux according to shared MIME-info database such samples are called "Adobe
FrameMaker font" or "Adobe-FrameMaker-Schrift" with German language. The
samples are recognized by looking for less character followed by phrase
MakerScreenFont at the beginning. That is in principal the same as in trid
definition. There this is expressed inside front block by XML construct like:
   <Bytes>3C4D616B657253637265656E466F6E7420312E</Bytes>
   <ASCII> . M a k e r S c r e e n F o n t   1</ASCII>
   <Pos>0</Pos>
   
 That information can be found in source freedesktop.org.xml.in found for
 examples on gitlab.freedesktop.org. Here no suffix is listed, but a user
 defined mime is listed. So this now expressed in updated definition by line like:
   <Mime>application/x-font-framemaker</Mime>

In current definition no reference is listed. So i choose the page about Adobe
FrameMaker on Wikipedia. So that is now expressed by line like:
   <RefURL>https://en.wikipedia.org/wiki/Adobe_FrameMaker</RefURL>

With this updated trid definition my BFONT samples are described as before but
with more details. TrID definition and output are stored in archive
fontdir.zip. I hope that my updated definition can be used in future version
of triddefs.

With best wishes
Jörg Jenderek
97
Definitions DB change log / Re: Current - Year 2023
« Last post by Mark0 on November 21, 2023, 05:56:04 PM »
Updated:
  • askSam data base (ASK)
  • askSam for Windows data base (v1.x) (ASK)
Added:
  • Amoeba Data (v1.x) (AMB)
  • askSam for Windows data base (v2.x) (ASK)
  • Windows NT Registry Hive (Boot Configuration Data) (BCD)
  • Windows NT Registry Hive (Boot Configuration Data, empty) (BCD)
  • Quartus Conversion setup File (COF)
  • SCI Driver (generic) (DRV)
  • Genius Menu Maker Menu (GMK)
  • CompuServe Information Manager for DOS Help (HLP)
  • QANTIM Itinerary (ITN)
  • CompuServe Information Manager for DOS messages container (PLX)
  • Quartus Setting File (by Terasic System Builder) (QSF)
  • Quartus Setting File (generic, with rem) (QSF)
  • Visual CADD Drawing (v1.x) (VCD)
  • Visual CADD Symbol (VCS)
  • Xerox Presents clipart (XPP)
98
Many thanks!
99
Hello trid users,

some months ago i send definitions to do sub classification of Windows NT
Registry Hive. In this session i will handle Boot Configuration Data variant.

Such files have name suffix BCD (like NeoSmart.bcd or "EasyBCD Backup
(2014-06-30).bcd"). Or the file name is BCD. Such samples can be typically
found in directory EFI\Microsoft\BOOT on the EFI partition.

Unfortunately as usual you do not find information about file format from
Microsoft. Either you get samples with accessing files via API (BCD.docx) or
low level information like click on foo to get bar. Luckily there exist an
unofficial page about Windows registry file format on GitHub. This describe
some technical aspects. So i use this as reference in one definition. That is
expressed by line like:
 <RefURL>
 https://github.com/msuhanov/regf/blob/master/
 Windows%20registry%20file%20format%20specification.md
 </RefURL>
There exist on Wikipedia a page about Boot Configuration (BCD)
Data. Unfortunately this page exist only in language for German, french and
Spanish but not for English language. There is described what is BCD
about. Also tools to handle such files are described. That is expressed in
other definition by line like:
 <RefURL>
 https://de.wikipedia.org/wiki/Boot_Configuration_Data
 </RefURL>

So i run trid utility on such BCD examples. All samples are recognized and are
described in principal OK as "Windows NT Registry Hive (generic)" by
hiv.trid.xml. But file name suffix is wrong. It is not HIV/DAT (see appended
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 the samples are not
recognized.

For comparison reason i also run file command (version 5.45) on such
samples. Here such samples are recognized and described generic as "MS Windows
registry file, NT/2000 or above" (see appended file-5.45.txt in output). The
mime type is here generic application/octet-stream (see appended
file-i-5.45.txt in output). The file name suffix is also not recognized (see
appended file-ext-5.45.txt in output).

Instead of generic application/octet-stream mime type i choose the type used
for generic Windows NT Registry Hive. That is expressed by line like:
   <Mime>application/x-ms-registry</Mime>

Because of missing complete information i first create TrID definition
hiv-bcd.trid.xml.~ by running tridscan on many (87) samples. Apparently i get
definition that is the average of variants. In global string sections i get 3
lines:
   <String>H'''X</String>
   <String>HBIN</String>
   <String>REGF</String>
According to documentation the second is triggered by 4 byte signature hbin of
Hive bins header. The third is triggered by 4 byte signature regf of Base
block, also known as a file header. All these lines are apparently
characteristics for Windows Registry Hive, but no is specif for BCD. In
examples the first is triggered by second hbin cell but i do not know what
this exactly means. So i delete it because it does not seems to be specific
for BCD.

In Front Block section the same problem occur. There exist some nil sequences.
Obviously these are triggered by lucky circumstances (too few samples with
fields not reaching maximum filling or padding bytes). The first is
characteristic for all hive. That is expressed by XML construct like:
   <Pattern>
      <Bytes>72656766</Bytes>
      <ASCII> r e g f</ASCII>
      <Pos>0</Pos>
   </Pattern>

Then there are 2 non nil sequences. These look like:
   <Pattern>
      <Bytes>01010000000300000000000000010000002000000000</Bytes>
      <Pos>19</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0001000000</Bytes>
      <Pos>43</Pos>
   </Pattern>
Apparently here are some fields constant, but none are specific for BCD.

So i looked in output of patched file command according to documentation (see
file.tmp in output). 6 of my samples look "strange" (like "EasyBCD Backup
(2019-04-15).bcd" "EasyBCD Backup (2019-04-21).bcd"). These are "empty"
without content. This becomes visible when you load such samples with
Microsoft registry editor regedit.exe. Or you can use the Forensic Registry
EDitor (fred). The advantage of this program is that there exist ports for
Windows and Linux. The disadvantage is that is does not work on all registry
examples, because file format is not officially revealed. So maybe the
function of some fields are not known and lead to program crashes. This tool
can be found at
https://www.pinguin.lu/fred .

I do not remember under which circumstances such samples appear. I guess that
these probably occur when you create a new BCD store. So probably at the
beginning of existence it contains no entries and is "empty". Now i found how
i can create such short samples. For examples by command like:
   bcdedit /createstore MyStore.bcd

So i create hiv-bcd-empty.trid.xml by running tridscan on such samples. Here i
get only few samples, but the advantages is the file size is "low". So i got
not so much patterns in definition (So no needle in haystack problem).
When i look inside Global Strings section i see only 2 additional lines:
   <String>NEWSTOREROOT</String>
   <String>RMTM</String>

According to documentation the second is triggered by 4 byte signature rmtm of
GUID. According to documentation this field exist in Windows 10. So maybe if
other users have samples from older Windows version like Vista, Windows 7 or 8
this line will vanish. My samples are from Windows 10 and Windows 8, but such
samples are maybe "reorganized" by newer Windows version. So i keep this line
at the moment. Interesting is the first additional line. This is triggered by
string NewStoreRoot. This seems to be one specific tag for BCD. In my samples
the GUID signature appears as expected at fixed offset. This is expressed
inside front block section by XML construct like:
   <Pattern>
      <Bytes>00224DB08107726D746D0000000000000000000000000
      <ASCII> . " M . . . r m t m</ASCII>
      <Pos>158</Pos>
   </Pattern>
According to documentation before that 16 byte GUID is stored. So apparently
in my samples 6 bytes are the same by lucky circumstance. So i remove bytes
before signature. After the signature 8 byte last reorganized timestamp is
stored. So in my samples value zero obviously means not reorganized. This make
sense for me and this is probably always true for such samples. So this
construct becomes like:
   <Pattern>
      <Bytes>726D746D0000000000000000000000000
      <ASCII> r m t m</ASCII>
      <Pos>154</Pos>
   </Pattern>

The pattern before looks like:
   <Pattern>
      <Bytes>E91182</Bytes>
      <Pos>154</Pos>
   </Pattern>
According to documentation at offset 148 16 byte GUID TmId is stored. So
apparently by lucky circumstances 3 bytes are the same.  Assuming that other
GUID values can occur this construct vanish.

The pattern before looks like:
   <Pattern>
      <Bytes>00224DB0810700000000</Bytes>
      <ASCII> . " M</ASCII>
      <Pos>138</Pos>
   </Pattern>
The same thoughts must be applied here. According to documentation at offset
128 16 byte GUID LogId is stored and at offset 144 4 byte flags are stored. In
some other registry samples i also found values like 8760c578 D5501C4E
FFFFFF90. But in my samples flags are zero which means not locked and
fragmented. So apparently by luckily circumstances the last 6 bytes of LogId
in my samples are the same. Assuming that other GUID values can occur this
construct shrink and becomes like:
   <Pattern>
      <Bytes>00000000</Bytes>
      <Pos>144</Pos>
   </Pattern>

The pattern before look like:
   <Pattern>
      <Bytes>E91182</Bytes>
      <Pos>134</Pos>
   </Pattern>
So same middle bytes in GUID LogId are the same by lucky circumstances.
Assuming that other GUID values can occur this construct vanish.

The pattern before look like:
   <Pattern>
      <Bytes>00224D B0 81 07</Bytes>
      <ASCII> . " M</ASCII>
      <Pos>122</Pos>
   </Pattern>
The same thoughts must be applied here. According to documentation at offset
112 16 byte GUID RmId is stored. Here in my samples the last 6 bytes of that
GUID are same. Assuming that other GUID values can occur this construct
vanish.

The pattern before look like:
   <Pattern>
      <Bytes>E91182</Bytes>
      <Pos>118</Pos>
   </Pattern>
According to documentation 3 middle bytes of GUID RmId are the same in my
samples. Assuming that other GUID values can occur this construct vanish.

At that point only 2 constructs are not inspected. The first XML construct
looks like:
   <Pattern>
      <Bytes>726567660100000001000000</Bytes>
      <ASCII> r e g f</ASCII>
      <Pos>0</Pos>
   </Pattern>
According to documentation after regf signature 4 byte primary sequence number
is stored followed by secondary sequence number.  The first number is
incremented by 1 in the beginning of a write operation on the primary
file. And the second is incremented by 1 at the end of a write operation on
the primary file and numbers should be equal after a successful write
operation. So apparently for such samples the sequence numbers are always be
1. So the above construct is probably always true. So i keep it.

So only second XML construct must be inspected. This looks like:

 <Bytes>D401010000000300000000000000010000002000000000100000010000000
 <Pos>18</Pos>

According to documentation at offset 12 8 byte last written timestamp is
stored. So by lucky circumstances (sames year range) the 2 last bytes
are the same in my examples. At offset 20 major version is stored. The
value in all NT Windows is 1. At offset 24 minor version is stored. In
my examples i get value 3. This is the values mostly found in my other
registry samples. Value 0 means "pre" version, 1 means NT 3.1, 2 means NT 3.5
and higher values 3,4,5,6 means NT 4 til Windows 11. At offset 28 file
type is stored. 0 means primary file and other values are used for
transaction variants (*.LOG*). So this is always true here. At offset
32 file format is stored. 1 means direct memory load; This is what i
also found in my other registry samples. At offset 36 root cell
offset is stored. In all my registry samples i get value 20h. At
offset 40 Hive bins data size is stored. Here for my examples i get
value 1000h. That is apparently the minimal possible value. Together
with same size 4096 for base block the summed size is 8192. So this
is the file size. So apparently this is true for such empty samples.
At offset 44 the clustering factor is stored. In all my registry
samples i get here value 1. That means 512 block size. At offset 48
the partial file path is stored. These 64 bytes contain UTF-16 LE
encoded name. In the empty samples this string is not used So it is
filled with nil bytes. So assuming that other modified time-stamps are
possibles. The first 2 bytes in that pattern ( last 2 byte of
modification time stamp ) vanish and this becomes like:
 <Bytes>010000000300000000000000010000002000000000100000010000000
 <Pos>20</Pos>

So i create hiv-bcd.trid.xml by running tridscan on non empty samples.

The last XML construct is like in other definition. At offset 200h comes 600h
padding nil bytes. This is expressed by XML construct like:
   <Bytes>0000000000000000000000000000000000000000000000000000000
   <Pos>512</Pos>

In other definition after rmtm signature comes long nil sequence til about 512
limit. Here in this area i get short nil byte sequences like:
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>177</Pos>
   </Pattern>
   ...
   <Pattern>
      <Bytes>00000000</Bytes>
      <Pos>504</Pos>
   </Pattern>
Assuming that fields in this area are not relevant for BCD i delete such
patterns.

At offset 144 4 byte flags are stored. In 2 samples (like BCD) i get here
value 0x310034 whereas for the other value is zero, but documents mention only
value value 1 and 2 for locked and defragmented. So i do not know if this was
an accident. This is expressed by XML constructs like:
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>145</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>147</Pos>
   </Pattern>

After running tridscan on short but not empty sample many items vanish. So in
global strings section only 7 lines survived. Three of them we already
know. These look like:
   <String>H'''X</String>
   <String>HBIN</String>
   <String>REGF</String>
These apparently are characteristics of registry samples. I do not know the
meaning of the first one. It is part of a hive bin cell. I am quite sure that
it is not relevant for BCD. So i delete that line. The other 4 lines look
like:
   <String>B'C'D'0'0'0'0'0'0'0</String>
   <String>DESCRIPTION</String>
   <String>KEYNAME</String>
   <String>OBJECTS</String>
Apparently the first seem to be characteristic for all non empty BCDs. When
you look in exported output of regedit you see 2 key-branches Description and
Objects. The first branch contains a string combination like
KeyName=BCD00000001 ( See appended MyStore2.reg in output). In most examples i
get that combination, but in some (5) samples instead of 1 another digit
character like 0 is used. I guess that this something like a counter. So i
mention my observations in the remark line.

At offset 48 the partial file path is stored. These 64 bytes contain UTF-16 LE
encoded name whereas in other definition these are nil. These names parts look
like:
EasyBCD Backup (2014-06-30).bcd
fb50349}\EFI\Microsoft\Boot\BCD
Device\HarddiskVolume1\Boot\BCD
Because name part are ASCII like stored as UTF16-LE on odd offsets i get a nil
byte. That is expressed by XML constructs like:
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>49</Pos>
   </Pattern>
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>51</Pos>
   </Pattern>
   ...
   <Pattern>
      <Bytes>00</Bytes>
      <Pos>107</Pos>
   </Pattern>
   <Pattern>
      <Bytes>000000</Bytes>
      <Pos>109</Pos>
   </Pattern>
I do not know if it possible to create BCD on file system with directory names
with exotic languages like Chinese. When this is true then the nil bytes will
vanish and only the terminating nil character for UTF-16 will survive. So the
above mentioned patterns vanish and the last one becomes like:
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>110</Pos>
   </Pattern>

The pattern before looks like:
   <Pattern>
      <Bytes>0001000000</Bytes>
      <Pos>43</Pos>
   </Pattern>
At offset 40 Hive bins data size is stored. Summed up with 4096 for base block
size i get file sizes about 28672, 36864 or 69632.  At offset 44 the
clustering factor is stored. In all my registry samples i get here value
1. That means 512 block size. So when Hive bins size is reaching 32-bit high
limit and clustering factor is always 1 this now becomes like:
   <Pattern>
      <Bytes>01000000</Bytes>
      <Pos>44</Pos>
   </Pattern>

After the first XML construct characteristic for registry samples the next 2
constructs look like:
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>6</Pos>
   </Pattern>
   <Pattern>
      <Bytes>0000</Bytes>
      <Pos>10</Pos>
   </Pattern>
According to documentation after regf signature 4 byte primary sequence number
is stored followed by secondary sequence number. In my samples i got sequence
numbers like 1, 2, 341 or 776. So the 2 upper bytes of these numbers were
nil. Assuming that sequence numbers can reach 32-bit high limit these 2
constructs will vanish. So i delete these 2 constructs.

Then only 1 XML construct is left for inspection. That looks like:
   <Bytes>01010000000300000000000000010000002000000000</Bytes>
   <Pos>19</Pos>
According to documentation at offset 12 8 byte last written timestamp is
stored. So by lucky circumstances (same year range) the last byte is the same
in my examples. At offset 20 major version is stored. The value in all NT
Windows is 1. At offset 24 minor version is stored. In my examples i get value
3. So that means version 1.3 for my examples.  At offset 28 file type is
stored. 0 means primary file and other values are used for transaction
variants (*.LOG*). At offset 32 file format is stored. 1 means direct memory
load. At offset 36 root cell offset is stored. In all my registry samples i
get value 20h. This is probably always true because that means cell directly
start after 32 byte hbin header.  At offset 40 Hive bins data size is
stored. Here for my examples i get values corresponding -4096 size is about
file size in bytes. A hive bin size is multiple of 4096 bytes (=1000h) So
lowest byte of that size is always nil. So assuming that other modified
time-stamps are possible. The first bytes in that pattern ( last 1 byte of
modification time stamp) vanish and this becomes like:
   <Bytes>010000000300000000000000010000002000000000</Bytes>
   <Pos>20</Pos>

With these 2 new trid definition now all my BCD samples are described. TrID
definition and output are stored in archive BCD.zip. I hope that my
definitions can be used in future version of triddefs.

With best wishes
Jörg Jenderek
100
Definitions DB change log / Re: Current - Year 2023
« Last post by Mark0 on November 18, 2023, 06:19:43 PM »
Updated:
  • RetroPlatform Player archive (RP9)
  • RetroPlatform Player RP9 manifest (XML)
Added:
  • DiskSalv backup streaming format ()
  • Standard Word printer control Codes (COD)
  • Rama SpellCheck Professional Configuration (v2.x) (CFG)
  • 4DOS Help (HLP)
  • 4DOS Help (v2) (HLP)
  • 4DOS Help (v4) (HLP)
  • Microsoft Project settings (v1.0) (INI)
  • Microsoft Project Project (v1.0) (MPP)
  • Microsoft Project View (v1.0) (MPV)
  • Microsoft Project Workspace (v1.0) (MPW)
  • RetroPlatform Library (RP-LIB)
  • RetroPlatform Skin (RP-SKIN)
  • Standard Word Printer Definition (PDF)
Pages: 1 ... 8 9 [10]