[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!


> On Mar 19, 2022, at 6:01 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
> 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
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 1nwsAJ9l4DpCYYoaYdiQDLS+aeLrD+3AXgCfYAzhwNos9d844G/6E5DMUqXcEfY=
> =eh6k
> <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