[File] [PATCH] Magdir/sniffer 5View capture file *.5vw misidentifies kroete.dat
Christos Zoulas
christos at zoulas.com
Sun Mar 20 23:28:11 UTC 2022
committed thanks!
christos
> On Mar 19, 2022, at 6:01 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello,
>
> some days 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.
>
> When running file command version 5.41 on this example and related
> files i get an output like:
>
> CAP-LINK_ETH-20030618-150138.5VW: 5View capture file
> kroete.dat: 5View capture file
>
> Furthermore with -i option only generic application/octet-stream is
> shown. With option --extension only 3 byte sequence ??? is shown
> instead of 5vw.
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). These examples are
> described as "5View capture" with file name extension 5vw by
> 5vw.trid.xml (See appended 5vw_trid-v.txt). This list with -v option
> the related URL pointing to used file information.
>
> I do not know any more where i get the right hint, but the step for
> further inspection was the tip that wireshark can can handle such
> capture files. So 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. Finally i look in c-source 5views.c
> for this capture format inside wireshark source tree. That
> informations are expressed by comment lines inside Magdir/sniffer lik
> e:
> # URL: http://www.infovista.com
> # Reference: http://mark0.net/download/triddefs_xml.7z
> # defs/0/5vw.trid.xml
> # https://2.na.dl.wireshark.org/
> # src/wireshark-3.6.2.tar.xz
> # wireshark-3.6.2/wiretap/5views.c
>
> The description happens by lines like:
> 0 string \xaa\xaa\xaa\xaa 5View capture file
>
> According to source this is the 4 byte 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 now shown by additional line like:
>> 4 ulelong !0x00000020 \b, header size %#x
>
> 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. So that information is shown by line like:
>> 8 ulelong !0x00010000 \b, record version %#x
> 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 line like:
>> 12 ulelong x \b, record size %#x
>
> Afterwards comes file type. This is the type of the capture file.
> In my good example i get value like 18001000h. So show this
> information by line like:
>> 16 ulelong x \b, file type %#8.8x
>
> Afterwards come 3 integers, which are described as reserved for
> future use. So these seems to be zero. So show this info by line like
> :
>> 20 quad !0 \b, Reserved %#llx
>
> 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 line like:
>> 0x20 search/0xB8/b \xEE\xEE\x33\x33 \b; record
> Interesting is the last entry of this structure, which is called
> utc inside the source. So i also show this value by lines like:
> #>>&20 ulelong x \b, RAW TIME %#8.8x
>>> &20 date x \b, Time-stamp %s
> So i get time-stamp of record. That information can be verified by
> running a command like:
> ls -lad CAP-LINK_ETH-20030618-150138.5VW
>
> According to wireshark source there may exist capture variants
> using big endian order. My inspected example is in little endian
> order. I put displaying part inside sub routine 5view-le. So if big
> endian variants must be handled in the future then just call this
> sub routine with inverted logic. Furthermore i can easily
> add/change test lines before calling sub routine. To skip "bad"
> kroete.dat i add as second test line that checks the correct record
> version. So the starting lines now becomes like:
>
> 0 string \xaa\xaa\xaa\xaa
>> 8 ulelong =0x00010000
>>> 0 use 5view-le
> 0 name 5view-le
>> 0 ulelong x 5View capture file
> !:mime application/x-5view
> !:ext 5vw
>
> After applying the above mentioned modifications by patch then all
> my inspected examples are now described as before but with more
> details. This now looks like:
>
> CAP-LINK_ETH-20030618-150138.5VW: 5View capture file,
> record size 0x18,
> file type 0x18001000;
> next record size 0x24,
> record type 0x80000000,
> RecSize 0x5c,
> Time-stamp Wed Jun 18 13:01:40 2003
> kroete.dat: 5View capture file,
> header size 0xaaaaaaea,
> record version 0xaaaaaaaa,
> record size 0x969656aa,
> file type 0xaaaaaaaa,
> Reserved 0x56555555555595aa
>
> With additional more test line done by file-5.41-sniffer-5vw.diff
> patch misidentification of kroete.dat vanished and this now looks lik
> e:
>
> CAP-LINK_ETH-20030618-150138.5VW: 5View capture file,
> record size 0x18,
> file type 0x18001000;
> record size 0x24,
> record type 0x80000000,
> RecSize 0x5c,
> Time-stamp Wed Jun 18 13:01:40 2003
> kroete.dat: data
>
> I hope my diff file can be applied in future version of file
> utility. Then some hints on the net say that kroete.dat is used for
> animation staff added by SUSE for their modifications of the boot
> loader.
>
> With best wishes
> Jörg Jenderek
> - --
> Jörg Jenderek
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCYjZStQAKCRCv8rHJQhrU
> 1nwsAJ9l4DpCYYoaYdiQDLS+aeLrD+3AXgCfYAzhwNos9d844G/6E5DMUqXcEfY=
> =eh6k
> -----END PGP SIGNATURE-----
> <Nachrichtenteil als Anhang.DEFANGED-28><5vw_trid-v.txt.gz><file-5_41-sniffer-5vw_diff.DEFANGED-29><file-5_41-sniffer-5vw_diff_sig.DEFANGED-30>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20220320/bde72478/attachment.asc>
More information about the File
mailing list