Hello trid users,
some days ago i installed a new Linux system on my PC. For security reasons
i tried variants with encrypted partitions. One method is called LUKS.
So i run trid utility on my encrypted examples (some taken from cryptsetup
sources). All are described with lower rate generic correctly as "LUKS
encrypted" by luks.trid.xml. Some are described as "LUKS2 encrypted" by
luks2.trid.xml (See appended output/trid-v-old.txt)
For comparison reason i check these examples by file command utility. When
running file command (version 5.42) here all examples are also described
generic as "LUKS encrypted file". The examples described by luks2.trid.xml
are characterized as version 2 by phrase ", ver 2". The examples only
described by luks.trid.xml are characterized as version 1 by phrase ", ver
1". For version 2 variant some information in output are missing. When
running newest file command (version 5.42 with luks v 1.5 2022/09/07) here
more details shown (See appended output/file.txt). Furthermore with -i
option now mime type application/x-raw-disk-image is shown (See appended
output/file-i.txt) And with --extension option now 4 file name extensions
are listed (See appended output/file-ext.txt)
For comparison reason i also run the file format identification utility
DROID ( See
https://sourceforge.net/projects/droid/). This dos not
identifies the examples.
In first step i update luks2.trid.xml. No patterns have changed. Only some
meta information is added.
I myself would prefer a user defined mime type like
application/x-luks-volume but according to FreeDesktop.org shared MIME
database for LUKS encrypted there exist already one. That information can be
found for example on web site reposcope.com. So that information is now
shown by line like:
<Mime>application/x-raw-disk-image</Mime>
The file name extension is there listed but not exactly explained. The
obviously "natural" file name suffix is luks for such encrypted files. These
files are often handled by image writer or mounters like gnome-disk. Such
utility can also handle other disk images. So apparently these use as
generic suffix for disc image 3 byte suffix img. When handling partitions
like /dev/sda3 then of course we have no file name extension. The mentioned
extension TC is used for Truecrypt containers. The mentioned extension VC is
used for Veracrypt containers. The header of such encrypted LUKS files can
be saved for backup reasons separately. These headers of course look at
first glance like the whole file or partition. This work for example can be
done by tool like zuluCrypt. This use an own file name suffix for that
reason. That is luksVolumeHeaderBackUp. So mention this information about
file suffix in remark line. And the file name extensions are now shown by
line like:
<Ext>IMG/LUKS/LUKSVOLUMEHEADERBACKUP</Ext>
After updating the version 2 variant i generate variant luks-v1.trid.xml for
handling the version 1 variant.
The first XML construct looks like:
<Pattern>
<Bytes>4C554B53BABE00016165730000000000000000000000000000000000000000000000000000000000</Bytes>
<ASCII> L U K S . . . . a e s</ASCII>
<Pos>0</Pos>
</Pattern>
After the starting 6 byte magic comes 2 byte sequence 0001 for version
1. That is followed by 32 byte cipher name. In my examples this was aes, but
according to documentation other cipher are possible (like aes twofish
serpent cast5 cast6). Assuming that there may exist cipher with 32 byte long
names this construct now becomes like:
<Pattern>
<Bytes>4C554B53BABE0001</Bytes>
<ASCII> L U K S . . . .</ASCII>
<Pos>0</Pos>
</Pattern>
According to documentation at offset 40 the cipher Mode is stored as 32 byte
string. In my few examples this was cbc-essiv, cbc-plain or xts-plain64.
That was expressed by XML constructs like:
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>43</Pos>
</Pattern>
<Pattern>
<Bytes>69</Bytes>
<ASCII> i</ASCII>
<Pos>47</Pos>
</Pattern>
<Pattern>
<Bytes>00000000000000000000000000000000
<ASCII> . . . . . . . . . . . . . . . .
<Pos>56</Pos>
</Pattern>
According to documentation there exist other cipher modes (like ecb
cbc-plain cbc-essiv:sha256 xts-plain64). Assuming that there may exist
cipher modes with 32 byte long names these constructs becomes shorter now
vanish.
According to documentation at offset 72 the hash specification is stored as
32 byte string. In my few examples this was sha256 or sha1. This together
with "short" cipher mode names this was expressed by XML construct like:
<Pattern>
<Bytes>00000000000000000000000000000000736861</Bytes>
<ASCII> . . . . . . . . . . . . . . . . s h a</ASCII>
<Pos>56</Pos>
</Pattern>
<Pattern>
<Bytes>00000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>78</Pos>
</Pattern>
According to documentation other hash specification are possible (like sha1
sha256 sha512 ripemd160). Assuming that there may exist hashes with 32 byte
long names these constructs now becomes shorter and vanish.
At offset 108 number of key bytes is stored as 4 byte big endian integer. In
my examples i have only "low" values 16 or 64. So the 3 upper bytes are
nil. That was expressed by XML construct like:
<Pattern>
<Bytes>000000</Bytes>
<Pos>108</Pos>
</Pattern>
Assuming that higher values are possible this construct vanish.
At offset 164 iterations parameter for master key PBKDF2 is stored as 4 byte
big endian integer. In my examples i have only "low" values 10, 1000 or
35656. So the 2 upper bytes are nil. That was expressed by XML construct
like:
<Pattern>
<Bytes>0000</Bytes>
<Pos>164</Pos>
</Pattern>
Assuming that higher values are possible that construct vanish.
At offset 168 40 byte UIID string is stored. For my examples this was
expressed by XML constructs like:
<Pattern>
<Bytes>32</Bytes>
<ASCII> 2</ASCII>
<Pos>173</Pos>
</Pattern>
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>176</Pos>
</Pattern>
<Pattern>
<Bytes>2D34</Bytes>
<ASCII> - 4</ASCII>
<Pos>181</Pos>
</Pattern>
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>186</Pos>
</Pattern>
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>191</Pos>
</Pattern>
<Pattern>
<Bytes>0000000000AC71F300</Bytes>
<ASCII> . . . . . . q</ASCII>
<Pos>204</Pos>
</Pattern>
Assuming that there exist other UIID values, then only the four hyphen
characters survived. That is now expressed by expressed by 4 constructs
like:
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>176</Pos>
</Pattern>
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>181</Pos>
</Pattern>
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>186</Pos>
</Pattern>
<Pattern>
<Bytes>2D</Bytes>
<ASCII> -</ASCII>
<Pos>191</Pos>
</Pattern>
At offset 208 8 key slots with 48 bytes are stored. At the beginning of a
slot is stored if slot is enabled or active by 4 byte sequence 00AC71F3. If
slot is disabled then this is marked by 0000DEAD sequence. In my examples
first slot is active and the other seven are disabled. This was expressed ed
by constructs like:
<Pattern>
<Bytes>0000000000AC71F300</Bytes>
<ASCII> . . . . . . q</ASCII>
<Pos>204</Pos>
</Pattern>
<Pattern>
<Bytes>00000FA00000DEAD0000000000000000000000000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>252</Pos>
</Pattern>
<Pattern>
<Bytes>00000FA00000DEAD0000000000000000000000000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>300</Pos>
</Pattern>
<Pattern>
<Bytes>00000FA00000DEAD0000000000000000000000000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>348</Pos>
</Pattern>
<Pattern>
<Bytes>00000FA00000DEAD0000000000000000000000000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>396</Pos>
</Pattern>
<Pattern>
<Bytes>00000FA00000DEAD0000000000000000000000000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>444</Pos>
</Pattern>
<Pattern>
<Bytes>00000FA00000DEAD0000000000000000000000000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>492</Pos>
</Pattern>
<Pattern>
<Bytes>00000FA00000DEAD0000000000000000000000000000000000000000000000000000000000000000000000000000</Bytes>
<Pos>540</Pos>
</Pattern>
Assuming that other slot are disabled or active these construct vanish.
At higher offset i get nil sequences like:
<Pattern>
<Bytes>00</Bytes>
<Pos>1079</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>1775</Pos>
</Pattern>
I assume that these are triggered by lucky circumstances. So i delete such
constructs.
With the updated and new trid definition now all my LUKS examples are
described more precisely and with more details (see appended
output/trid-v-new.txt). TrID definition and output are stored in archive
luks_.zip. I hope that my XML files can be used in future version of
triddefs.
There exist only version 1 and 2. So luks.trid.xml is not really needed any
more. If there exist other versions it could make sense to act as a generic
definition.
With best wishes
Jörg Jenderek
