sniffing/tcpdump payload mods

[Didier Stevens]

I don't really like it when packet captures are written to a single file, unless I know the capture file will be kept small.

A network capture can create very big files, that take a long time to read and display with Wireshark.

And with the PS, you run the risk that the PS is improperly shutdown (e.g. loss of power) and that the capture file on the USB stick gets corrupted.

That's why I prefer to configure tcpdump (or dumpcap) to rotate files and create files with a size limit.

I changed the sniffing/tcpdump payload as such (bold):

Quote

tcpdump -i br-lan -w /mnt/loot/tcpdump/dump_$(date +%Y-%m-%d-%H%M%S).pcap -C 10 -z sync &>/dev/null &

-C 10 sets the maximum pcap file size to 10.000.000 bytes. When that size would be exceeded, a new file capture file is created and the old one is closed.

-z sync executes the sync command each time a capture file is rotated. This should guarantee that the rotated capture file is actually flushed to the USB disk.

 

I will use my PS with this mod for a couple of weeks, and report back here.

 

[Dave-ee Jones]

You may notice that on the payload.txt there's a 'monitor_space' function. This function kills the program if the length of the file is more than '10000' units. Not sure what the units are, sadly.

Anyway, monitor_space runs in the background and when the length of the file gets too big it cuts the tcpdump program. However, you could potentially do this anyway by doing something along these lines:

tcpdump -i br-lan -w /mnt/loot/tcpdump/dump_$(date +%Y-%m-%d-%H%M%S).pcap -C 10 -z "kill $1" &>/dev/null &

That could theoretically kill itself when it's filesize is more than 10,000,000 bytes (or should I say, 10MB which equals 10485760 bytes in binary, because of the 1028 factor).

[Didier Stevens]

Quote

or should I say, 10MB which equals 10485760 bytes in binary, because of the 1028 factor

No, it's actually 10,000,000 bytes and not 1,048,760 bytes.

From the tcpdump man page:

http://www.tcpdump.org/tcpdump_man.html

Quote

The units of file_size are millions of bytes (1,000,000 bytes, not 1,048,576 bytes).

 

And it's 1024 :-)

[Dave-ee Jones]

55 minutes ago, Didier Stevens said:

No, it's actually 10,000,000 bytes and not 1,048,760 bytes.

From the tcpdump man page:

http://www.tcpdump.org/tcpdump_man.html

 

And it's 1024 :-)

Yep, it's funny because I was only reading that man page 10m after I posted my comment :)

Technically you're incorrect as well because it's not 1,048,760 bytes, it's 10,485,760 bytes. :P

Anyway, it still doesn't make my comment incorrect because it is 10,485,760 bytes in binary, haha. I hate it when scripts and other programs do this because they make it so confusing. It's supposed to be a factor of 1024, not 1000, so when they make it a factor of 1000 it just makes it super confusing for everyone who has the binary background, and confusing for those who have the decimal background and don't know that it is actually based on binary which is 1024. It's feeding them lies. :(

And yes, my bad, it is 1024. No idea why I said 1028...

[Fester]

On 11/16/2017 at 11:47 PM, Dave-ee Jones said:

on the payload.txt there's a 'monitor_space' function. This function kills the program if the length of the file is more than '10000' units

Actually, that function kills the program if the remaining free space gets under 10000 blocks.

Blocksize can be found with 

df | grep Filesystem | awk '{print $2}'

but will probably be 1KB.

What on its turn results in a 10.240.000 bytes of free space. This is however, only checked every 5 seconds with the 'sleep 5' command