I'm trying to merge multiple plain text packets into one large pcap file. I have been using text2pcap on each individual text file, then using mergecap on all the pcaps to create my final output. However, that's really slow, as it involves writing out that each pcap file, merging them all together, and then deleting all the single pcaps. I'm looking to speed that up by sending multiple text files into text2pcap at once.
Unfortunately, from what I understand, text2pcap requires the ofsets on the text file to be correct, and since I'm merging multiple different packets, I'm starting over at 0000 multiple times, and I think that's causing my errors.
So, assuming I have a packet that looks like this:
0000 30 00 20
0010 59 23 00
and another packet that looks like this:
0000 23 50 2c
0010 a4 23 f1
How would I best convert the two of them into a single pcap file?
You can also use PDD - Packet Dump Decode.
You can find an example in my article at LoveMyTool.
Related
I take copy bytes dump using my Ubuntu os(MBR sector) following command.
dc3dd if=/dev/sda of=x cnt=1 ssz=512 hash=sha256 mlog=hashes
And I convert it to hexdump using following command.
hexdump x > hex_x
I receive out put like this .
I have some experts hep to analysis this hex_dump. I need to know what are the benefit of getting MBR hex dump and what kind of thing can be do using it ? (Eg: can I tell my system os like information analyzing this ? )
Need to know ,are there any commands or tools to more deep analyzing and convert this hexdump to human readable way ?
Q. what are the benefit of getting MBR hex dump and what kind of thing can be done using it?
A. Microsoft says:
The MBR contains a small amount of executable code called the master boot code, the disk signature, and the partition table for the disk.
The master boot code and disk signatures aren't very useful for someone (investigator). However the partition table gives a lot of information, and it can be used to extract information, in scenarios, where OS is corrupted or not booting and MBR can be used to investigate disk drive and operating system.
Sample Partition Table Record: (taken from an MBR, using HEX editor)
80 20 21 00 07 7E 25 19 00 08 00 00 00 38 06 00
Each hexadecimal value has some specific meaning, for instance:
80 => Partition type, Active
20 21 00 => Partition’s starting sector, Cylinder-Head-Sector (CHS)
07 => File System, NTFS
7E 25 19 => Partition’s ending sector, CHS
00 08 00 00 => Starting sector
00 38 06 00 => Size of the partition, 199 MiB
You can read them in detail in Table 1.2 Partition Table Fields, at official site.
Q. are there any commands or tools to more deep analyzing and convert this hexdump to human readable way?
A. You can use any HEX editor, like Hex Editor Neo or Active Disk Editor. These editors will help you in understanding MBR, but there is no magic tool available to to convert hexdump into human readable format (based on my knowledge).
PS: The question is pretty old, I wasn't available earlier so please accept late answer... :)
The format of the file is:
header - like 0001datetime|number of records
0010 some data
0012 Roll number (eg)
0020 some data
.
.
.
0070 some data
0010 some data
0012 Roll number (eg)
0020 some data
.
.
.
0070 some data
trailer - like 0099datetime|numberof records
Requirement - A list of Roll numbers will be given and the the records (0010-0070) needs to be removed for those numbers. There might be any number of fields between 0010 and 0070 but roll number is always at 0012.
Each record always starts with 0010 and end with 0070.
Could anyone please help with this?
Aside of header and trailer line, your file consists of blocks. Each block starts with a 0010 line and ends with a 0070 line.
One straightforward algorithm would be to always read one whole block into memory, and write it out only if the 0012 line (denoting the roll number) is not one of the roll numbers to be deleted.
You are tagging this question by "shell". However, while a solution using just, i.e., bash or zsh is technically possible, I think it's much easier to use a more flexible language for this - Ruby, Perl, Python etc. Maybe you can tag the problem with the language of your choice?
If you are not familiar yet with one of those languages, my personal recommendation would be Ruby, because I find it quick to learn; but all of them are equally well suitable for this problem.
My problem is losing Data over my TCP Data transfer.
I've built a homemade AVR based web-server (or at least trying to).
I'm able to communicate with the client PC (my PC), and I'm able to send a few HTML lines (total data <100 bytes), no problem there.
But when I want to sent my basic home page (~1KB), I'm only getting in WireShark 181bytes of data.
I suspect the problem lies in the construction of the TCP.
data below are in hex format
From client(my PC):
sequence number: de db c7 b1
ack number: 00 0a 00 0b
From server(AVR):
sequence number: 00 0a 00 0b
ack number: de b6 c9 18
Total TCP Length: 935byte, IP and TCP header 20-20 byte
What settings did I set wrong?
TCP is a stream and there is no guarantee that each send will result in exactly one recv. You need to call send repeatedly until all bytes are sent, and on the other end you need to recv repeatedly as well, appending new data to the end of a buffer on each subsequent successful recv... You cannot ignore the return codes from the send/recv calls, you must use it to know how much data is sent/recvd.
Problem Solved!
ENC28J60_CS();
ENC28J60_CMD(WCR,ETXNDL);
SPIWR(package_length);
SPIWR(16+(package_length>>8));
ENC28J60_DS();
package_length is a integer, so is the ETXNDL(register).
Until now the second SPIWR() function sent only the value 16: SPIWR(16);
So the problem was, I never added the high-byte of the package_length to the 16, so the chip always sended 1-255 byte long packages.
why 16?
RX buffer starts at 0x0000, and ends at 0x0fff.
TX buffer starts at 0x1000, and ends at 0x1fff.
Using TeraTerm and a Serial port adapter I ran a Macro with this line on it:
send $55 $0B $00 $00 $00 $BB $42 $AA
The $BB was sent out as two different bytes instead of just one. I forget which ones they were specifically but the result on the O-scope looked like this:
55 0B 00 00 00 C8 E9 42 AA
Does anyone know why this is?
I looked in the Manual and verified that Send8Ctrl is set to off and so is the Debug option.
Did the research, tested and verified that the answer to the question is that TeraTerm is using UTF-8 instead of English under the general settings menu. There are two options present that may be confusing so the two options are 'English' and 'Default'.
With tinyos there is SerialForwarder which forwards the data to a socket.
I have tried to open socket with host:"localhost",,port="9001" ,, but this will always return two bytes ="T!" !!
Then I try to open a TCP connection with same properties but I got this warning :
warning unsuccessful read a timeout occurred before the terminator was reached
How to read the data from SerialForwarder?
You have to read thoroughly the serial stack...its not very easy but its do able.
You can directly read from serial port. You don't need serial forwarder in this case. There are few things to take care of.
For example if you want to read a serial message that is being send to serial port of your PC (usb sensorboards just work like serial, since they are using usb to serial converters lik FTDI chip).
in C# (same for Java, etc...) you can read byte streams that are coming in the serial port. You can parse this byte streams to extract a standard serial message of tinyos.
This is somehow explained in TEP #113 although it has some problems, but you should be able to find those problems and make your program work.
As it stated in TEP 113, a standard serial packet is something like:
7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e
That means, a packet starts with hex 7E ( I believe its 126 or 127) and ends also with 7E. The last 2 bytes are CRC of the packet. So you can in your c# program start reading from serial port when you encounter 7E and stop reading when you reach the next 7E in the stream. Everything in between will be your packet.
You have to be careful of escaping that is if a 7E is part of your packet content, to be not be confused with start and end dilimeters, it will be escaped to something else...that's also is explained in that TEP 113.
I believe there were some C++ code fro calculating the CRC that you can easily convert it to C# or Java code.
Also check the source code of Serial.h which contains some details about how a serial packet is being formed in TinyOS.