Hello trid users,
Some days ago i send definition for 5View capture with extension 5VW. Such
examples are created by wireshark tool. This can open and save captures
also in other file formats.
One format start with file name extension TRC. These samples are described
as "Unknown!" by TrID (See appended output/trid-old.txt).
For comparison reason i also run file command on such samples. Here most are
described as "HP/UX nettl capture file" (See appended output/file-5.43.txt).
I installed wireshark on window and a Linux system. Afterwards the examples
are called "HP-UX nettl trace" on Windows system and on Linux. There the
information is based or correlates with description of shared MIME-info
database. There it is called "Packet Capture (HP-UX nettl)". This
information can for example be found on web site reposcope.com. So that
information is now inside trc0-hp.trid.xml expressed by lines like:
<FileType>HP-UX nettl capture</FileType>
<Mime>application/x-nettl</Mime>
Some information can be found on wireshark web site. So that page is used as
reference URL. This is expressed by line like:
<RefURL>
https://wiki.wireshark.org/nettl.md</RefURL>
My examples are all uncompressed and have file name extension TRC0, but
according to mime database also TRC1 can occur. So this is expressed by line
like:
<Ext>TRC0/TRC1</Ext>
In the hp nettl(1m) man page the mentioned extension contains 3 digit number
like TRC000. There it is also written that this sequence number is increased
by one when file is full until the limit is reached. This is given by -n
option with default value 2. So there may exist also samples with with more
and higher digits in file suffix.
After running tridscan to create definition i looked what construct appear
and why. Except for first XML construct inside front block section the next
six are short and often nil patterns like:
<Pattern>
<Bytes>0000</Bytes>
<Pos>164</Pos>
</Pattern>
<Pattern>
<Bytes>63</Bytes>
<ASCII> c</ASCII>
<Pos>168</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>172</Pos>
</Pattern>
<Pattern>
<Bytes>FFFFFFFF0000000000000000</Bytes>
<Pos>176</Pos>
</Pattern>
<Pattern>
<Bytes>00000000</Bytes>
<Pos>192</Pos>
</Pattern>
<Pattern>
<Bytes>0000</Bytes>
<Pos>248</Pos>
</Pattern>
I assume that these are triggered by lucky circumstances. So i delete these.
In my examples the first 162 bytes are the same. That was expressed inside
front block by line like:
<Bytes>5452006400000000000000802F746D702F77697265736861726B2E54524330303000000000000
<ASCII> T R . d . . . . . . . . / t m p / w i r e s h a r k . T R C 0 0 0
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
U T C . . . . . . . . . . . . . . . . . . . . . . . . . .
B . 1 1 . 1 1 . . U . . . . . . . .
9 0 0 0 / 8 0 0 . . . . . . D</ASCII>
<Pos>0</Pos>
And in global strings sections by 2 lines like:
<String>WIRESHARK.TRC000'''''''''''''''''''''''''''''''''''
UTC''''''''''''''''''''''''''B.11.11''U''''''''9000</String>
<String>TR'D</String>
According to wireshark source file nettl.c i began to interpret these bytes.
When saving the captures in HP format i can choose any main name, but inside
at offset 12 56 bytes with file name is stored. For the wireshark (version
1.12.1 3.6.8 4.0.1 ) generated examples this was always nil padded
/tmp/wireshark.TRC000. At offset 68 12 byte "time zone structure" is stored.
In my examples this was nil padded UTC string. At offset 97 9 bytes "os
version" and 1 byte os_v is stored. In my wireshark examples this was nil
padded B.11.11 string followed by value 55h. At offset 115 model name is
stored as 11 bytes. In my examples this was nil padded 9000/800. At offset
88 9 byte host name is stored. Here in my examples i get always nil
bytes. The last 2 padding bytes of 128 bytes header are always 0406h in my
examples. So apparently wireshark fills this "meta information fields" just
with "dummy" values to generate valid HP nettl captures. When i look in HP
man page i expect for "real" HP captures i expect there other values. So i
delete all string lines in global string section. And in front block only 12
bytes of starting magic called nettl_magic_hpux10 in source survived. So the
remaining XML construct look like:
<Bytes>545200640000000000000080</Bytes>
<ASCII> T R . d . . . . . . . .</ASCII>
<Pos>0</Pos>
In the source is written that this 12 byte magic is only found in HP-UX 10.x
and 11.x, whereas in HP-UX 9.x another 12 byte magic called nettl_magic_hpux
is used. So i mention this in remark line.
With the new trid definition now my HP example captures generated by
wireshark are now described (see appended output/trid-v-new.txt). TrID
definition and output are stored in archive hp_.zip. I hope that my XML file
can be used in future version of triddefs.
With best wishes
Jörg Jenderek
With best wishes
Jörg Jenderek
