Hello trid users,
Some weeks ago i looked at medium of my last Linux installation. It was a
SUSE LEAP. So i looked at files in boot/x86_64/loader directory. There was a
file named kroete.dat. Some hints on the net say that kroete.dat is used
for animation staff added by SUSE for their modifications of the boot
loader.
This example is described as wrong "5View capture" with file name extension
5vw by 5vw.trid.xml like real capture examples like
CAP-LINK_ETH-20030618-150138.5VW (See appended output/trid-v-old.txt). TrID
list with -v option the related URL pointing to used file information, but
no mime type.
I installed wireshark on window and a Linux system. Afterwards the examples
are called "Wireshark capture file" on Windows system and "Packet Capture
(Accellent/InfoVista 5view)" on Linux. There the information is based or
correlates with description of shared MIME-info database. This information
can for example be found on reposcope.com. That is what is shown by newest
file command. So that information is now inside 5vw.trid.xml expressed by line
like:
<Mime>application/x-5view</Mime>
In that only 1 short pattern is used. That is expressed by XML construct
like:
<Bytes>AAAAAAAA</Bytes>
<Pos>0</Pos>
Unfortunately this is not unique enough. So the kroete.dat example is
misidentified. So i run tridscan on examples generated on little endian
machines to create 5vw-le.trid.xml.
After running tridscan to create definition i looked what construct appear
and why. The first construct looked like
<Bytes>AAAAAAAA200000000000010018000000001000180000000000000000000000000700008004000100
<Pos>0</Pos>
When looking in wireshark source 5views.c and file command Magdir/sniffer we
can start to interpret this pattern.
According to source this is the 4 byte 0xAAAAAAAA is the signature of the
structure t_5VW_Info_Header.
Next comes size of header in bytes (included signature and reserved
fields). For kroete.dat i get high nonsense value whereas for real 5VW
example i get here value 20 hexadecimal. That is the size of structure (32=
8 * 4 byte integers). So this probably is always true. That is shown by file
command for unusual values by phrase ", header size ".
Next comes the version of header record. When i tried to open kroete.dat
with wireshark this fails with error message The file "kroete-dat" contains
record data that Wireshark doesn't support. (5views: header version
2863311530 unsupported). So here value is also AAAAAAAAh. But according to
source version for 5view must always be the constant
CST_5VW_INFO_RECORD_VERSION with given value 0x00010000U. That is used by
newest file command as second test.
Next comes the DataSize. That is the total size of data without header. For
real examples i get value like 18h. So that information is now shown by file
command by phrase ", record size ".
Afterwards comes file type. This is the type of the capture file. In my
good examples i get value like 18001000h. So file command show this
information by phrase like ", file type ".
Afterwards come 3 integers, which are described as reserved for future
use. So these seems to be zero. If not nil these are shown by phrase ",
Reserved". So ignoring bytes after reserved field the first construct now
becomes like:
<Bytes>AAAAAAAA20000000000001001800000000100018000000000000000000000000</Bytes>
Second construct look like
<Bytes>0000002004000100</Bytes>
<Pos>44</Pos>
I do not know what this is and if this always true. So i delete that pattern.
Third construct looked like:
<Bytes>0000EEEE3333240000400000008000000000</Bytes>
<ASCII> . . . . 3 3 $ . . @</ASCII>
<Pos>54</Pos>
I also look for a record with t_5VW_TimeStamped_Header structure type which
starts with constant CST_5VW_RECORDS_HEADER_KEY (that is 0x3333EEEEU). That
is done by file command via phrase "; record"
Afterwards comes HeaderSize. This is actual size of this header in bytes as
2 byte integer. In my examples this was 24h and this is shown by file
command after phrase "size".
Afterwards comes HeaderType as 2 byte integer. This is the exact type of
this header. In my examples this was 0x4000. This is shown by file command
for other values after phrase ", header type".
Afterwards comes RecType. This is type of record stored as 4 byte
integer. In my examples this was 80000000h. This is shown by file command
after phrase ", record type".
Afterwards comes RecSubType. This is sub type of record stored as 4 byte
integer. In my examples this was 0. This is shown by file command for other
values after phrase ", subtype"
So apparently this structure always start at offset 56 in my examples. But i
do not know if this is always true. So this structure now becomes expressed
by XML construct like:
<Bytes>EEEE3333240000400000008000000000</Bytes>
<ASCII> . . 3 3 $ . . @</ASCII>
<Pos>56</Pos>
At relative offset 16 (that is absolute 72=56+16) the RecSize is stored as 4
byte integer. That is the size of one record. In my examples i get "low"
values( like 0x42 0x5c 0xd2 0x10b). So the 2 upper byte are nil. This is
shown by file command after phrase ", RecSize". Afterwards comes
RecNb. This is the number of records stored as 4 byte integer. In my
examples this was 1. This is shown by file command for other values before
phrase " records". These 2 facts are described by XML construct like:
<Bytes>000001000000</Bytes>
<Pos>74</Pos>
So assuming structure appears as offset 56 and greater RecSize is possible
this now becomes like:
<Bytes>01000000</Bytes>
<Pos>76</Pos>
The last construct is a short nil pattern like:
<Bytes>000000</Bytes>
<Pos>89</Pos>
I assume that this is triggered by lucky circumstances. So i delete it.
According to wireshark source there may exist capture variants using big
endian order. My inspected examples are in little endian order. So i create
big endian variant 5vw-be.trid.xml by just byte swapping the fields of
little endian variant.
With the little endian variant trid definition now my 5VW examples are still
described but misidentfication vanish (see appended
output/trid-v-new.txt). TrID definition and output are stored in archive
5vw_.zip. I hope that my updated XML file and the variants can be used in
future version of triddefs. If the variants are working OK then the generic
5vw.trid.xml can be deleted to avoid misidentifications.
With best wishes
Jörg Jenderek
