I am trying to decode TCP data from an application, I know the data is not encrypted but a clue suggested that "manipulating the bytes and bits" does the work, I can't figure it out myself.
The raw TCP data is: 8b5d002e7e5200048f100040
Hex Dump:
00000000 8b 5d 00 2e 7e 52 00 04 8f 10 00 40 .]..~R.. ...#
CArray:
char peer1_0[] = { /* Packet 51 */
0x8b, 0x5d, 0x00, 0x2e, 0x7e, 0x52, 0x00, 0x04,
0x8f, 0x10, 0x00, 0x40 };
Here is the Hex dump for the entire packet, maybe there is something that I am missing?
0000 0c 9d 92 11 14 f5 e0 ce c3 89 f6 6a 08 00 45 00 ...........j..E.
0010 00 34 79 62 40 00 6f 06 0a d6 c7 e5 fd ee c0 a8 .4yb#.o.........
0020 01 0f 59 d9 f9 7a 64 6a c5 50 70 48 f0 65 50 18 ..Y..zdj.PpH.eP.
0030 7f 62 31 e2 00 00 8b 5d 00 2e 7e 52 00 04 8f 10 .b1....]..~R....
0040 00 40 .#
Related
Has anyone seen (fixed?) a problem with strings of zeroes in audio data captured with the AL5645 codec microphone input on the Coral dev board? It's happening for me with default settings using arecord, as well as my python code using PyAudio. 16 bit (mono) samples, sample rates 16000Hz and 44100Hz. e.g. 83 ce 34 0b 09 3f 00 00 00 00 00 00 2b 0e 2b 0e b0 d0 5a b9 ee d9 00 00 00 00 75 44 75 44 75 44 ba 38 8a ff e6 c6 00 00 00 00 00 e7 00 e7 00 e7 85 26 f4 46 bc 2e
?
Cheers,
Mark
I have the following process to calculate the tcp checksum
static inline uint32_t
csum_part(const void *buf, size_t len, uint32_t sum)
{
uintptr_t p = (uintptr_t)buf;
while (len > 1)
{
sum += *(uint16_t *)p;
len -= 2;
p += 2;
}
if (len)
sum += *(uint8_t *)p;
return sum;
}
and the following function to pack it
uint16_t calc(uint32_t x)
{
while((x >> 16) != 0)
x = (x & 0xffff) + (x>>16);
return ~x;
}
When I calculate the checksum for the header I use the following code
uint32_t calc_tcp_checksum(char * pkt, int hdrlen, int pktlen) {
struct ip * ih = (struct ip *)
(pkt+ hdrlen - sizeof(struct tcphdr) - sizeof(struct ip));
struct tcphdr * th = (struct tcphdr *)
(pkt + hdrlen - sizeof(struct tcphdr));
#ifndef __FAVOR_BSD
th->check = 0;
#else
th->th_sum = 0;
#endif
//th->
uint32_t header_chksum = csum_part(th, sizeof(struct tcphdr), 0);
uint32_t pseudo = (uint32_t)ih->ip_src.s_addr + ih->ip_dst.s_addr +
htons(IPPROTO_TCP) + htons(pktlen);
header_chksum += pseudo;
return header_chksum;
}
I have a packet which is the following
0000 58 f3 9c 81 2b bc 00 1c 73 13 1f 94 08 00 45 00
0010 00 dc 00 00 40 00 40 06 40 19 0a e6 35 90 ac 13
0020 0d 7a b9 be 2a 44 63 36 c2 98 c7 82 d0 1e 50 18
0030 10 00 eb 15 00 00 00 b4 00 00 09 cd 1c fb 66 40
0040 ec c7 0d 30 cb 0b e4 cb 88 74 13 3d 4e 20 00 00
0050 9a d6 00 00 00 00 9f db 4f 50 54 49 44 58 42 41
0060 4e 4b 4e 49 46 54 59 20 4d 03 8a e8 00 2d ed d0
0070 43 45 46 4e 45 30 30 30 37 20 20 20 00 01 00 02
0080 00 00 00 00 00 00 00 4b 00 00 a7 7b 00 00 00 00
0090 02 00 00 02 00 00 9a d6 39 30 30 35 39 4f 49 43
00a0 49 43 49 30 30 30 30 35 32 30 00 01 02 00 b0 6d
00b0 c8 04 42 f6 bd f9 52 7c 42 80 41 41 45 43 45 32
00c0 34 31 33 51 00 00 a1 e4 00 00 00 00 00 00 00 00
00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00e0 00 00 00 00 00 00 00 00 00 00 72 dd 89 69
In the example above,
pktlen = 180
hdrlen = 54
I get the checksum to be 0xeb15, wireshark says it's 0xea15. What am I doing wrong? Note that it always is not incorrect, just sometimes.
Section 4.1 of RFC 1071 - Computing the Internet Checksum provides implementation example in "C", which seems to be the method you're basing your implementation from. Except that the RFC 1071 example combines the folding part within the same function that computes the checksum, whereas your implementation does not. RFC 1071 obviously assumes that the pseudo-header is already included in the buffer pointed to by addr, but again, yours does not. This would all be OK, except that you never actually fold the final result by calling your calc() function, at least not that I can see.
So for your implementation, it would seem that any computed TCP checksum that doesn't have any bits set in the upper 16-bits of the 32-bit accumulator will be correct, but any computed checksum that does have at least 1 bit set in the upper 16-bits of the accumulator will result in an incorrect TCP calculation. I believe this would explain why some checksums your code computes are correct and some are wrong.
And in case you're interested, you can have a look at Wireshark's implementation of Internet checksums in in_cksum.c as well as how it's called from the TCP dissector.
I am implementing a server and have an issue with the handshaking. When I get the arp request the response is given ok, then I get the SYN. I respond to the SYN with a SYN ACK but I don't get an ACK back.
The sequence numbers and ack's seem to be in order as well as the id's, the checksums add up aswell to. Any ideas why the SYN ACK is not getting recieved?
Arp Request:
0000 ff ff ff ff ff ff e0 3f 49 b7 8e 39 08 06 00 01
0010 08 00 06 04 00 01 e0 3f 49 b7 8e 39 c0 a8 00 01
0020 00 00 00 00 00 00 c0 a8 00 0c
Arp reply:
0000 ff ff ff ff ff ff 00 14 a5 76 19 3f 08 06 00 01
0010 08 00 06 04 00 02 00 14 a5 76 19 3f c0 a8 00 0c
0020 e0 3f 49 b7 8e 39 e0 3f 49 b7 00 00 00 00 00 00
0030 00 00 00 00 00 00 00 00 00 00 00 00
SYN:
0000 00 14 a5 76 19 3f e0 3f 49 b7 8e 39 08 00 45 00
0010 00 34 1e d2 40 00 80 06 5a 94 c0 a8 00 01 c0 a8
0020 00 0c 13 79 00 50 95 01 61 8e 00 00 00 00 80 02
0030 20 00 c3 59 00 00 02 04 05 b4 01 03 03 08 01 01
0040 04 02
SYN ACK:
0000 e0 3f 49 b7 8e 39 00 14 a5 76 19 3f 08 00 45 00
0010 00 2c 1e d2 40 00 80 06 5a 9c c0 a8 00 0c c0 a8
0020 00 01 00 50 13 79 d6 a2 5f 1b 95 01 61 8f 60 12
0030 05 ee d0 e6 00 00 02 04 05 78 00 00
I am trying to gain access to in game chat information from dota2 packets. I knew this used to possible since there were multiple projects that intercepted dota2 network traffic and translated chat text to print out on an overlay over dota2. Right now I am using wireshark with protobuf addon installed. I can see a few packets here and there to valve servers outside the USA and can see the protobuf addon for wireshark working on these packets but I get an unknown wiretype error for 95% of the packets I believe to be related to dota. In almost all of these packets the UDP data payload starts off with 56 53 30 31
here is an example hex dump from wireshark. Are these 4 bytes some sort of header and then the proto messages start?
0000 c8 a7 0a a4 63 ed 6c fd b9 4b 6e 16 08 00 45 00
0010 00 70 58 db 40 00 40 11 85 1a c0 a8 01 f5 d0 40
0020 c9 a9 9e 96 69 89 00 5c 72 7c **56 53 30 31** 30 00
0030 06 00 00 02 00 00 00 1d fe 11 11 10 00 00 d7 0a
0040 00 00 01 00 00 00 11 10 00 00 30 00 00 00 24 fd
0050 37 3c b4 30 a5 48 fa 3d ea 30 1a 1f d8 a9 41 e0
0060 e0 6c 44 ba bb 4e ba fc e7 ac ed f9 40 19 86 20
0070 84 71 52 5d b3 1f da 36 40 d9 b6 2e e1 e5
That is ascii code for "VS01", so yes, it might be some kind of version identifier.
I'm trying to read public transport cards and I've figured out the data format mostly but the record dates and times are a mystery. Some data:
e1 a2 00 00 ce 04 05 b1 7e 00 68 22 0a 10 00 ce - 01.03.2014 23:36
e4 a2 00 00 ce 04 e5 7b 7e 00 e4 2e 0a 10 00 e9 - 04.03.2014 16:31
e4 a2 00 00 4c 04 43 8c d0 07 30 00 01 00 00 72 - 04.03.2014 18:42
e4 a2 00 00 ce 04 65 8d 7e 00 7c 17 0a 10 00 a2 - 04.03.2014 18:51
ea a2 00 00 ce 04 25 63 7e 00 70 09 0a 10 00 f1 - 10.03.2014 13:13
ec a2 00 00 ce 04 25 63 7e 00 70 09 0a 10 00 da - 12.03.2014 13:13
f3 a2 00 00 ce 04 85 69 7e 00 64 3b 0a 10 00 9d - 19.03.2014 14:04
f5 a2 00 00 ce 04 e5 89 7e 00 70 22 0a 10 00 ba - 21.03.2014 18:23
f6 a2 00 00 ce 04 6a 00 82 01 68 22 2a 10 00 df - 22.03.2014 00:03
fb a2 00 00 ce 04 85 75 7e 00 84 17 0a 10 00 2a - 27.03.2014 15:40
fb a2 00 00 ce 04 a5 91 7e 00 78 17 0a 10 00 a6 - 27.03.2014 19:25
c1 a2 28 00 ce 04 0b 6b 00 00 74 17 08 10 04 94 - 28.01.2014 14:16
c7 a2 00 00 ce 04 a5 5d 7e 00 6c 09 0a 10 00 1b - 03.02.2014 12:29
c7 a2 00 00 ce 04 25 6c 7e 00 68 2d 0a 10 00 68 - 03.02.2014 14:25
c7 a2 0e 00 ce 04 eb 6d 00 00 88 17 08 10 04 45 - 03.02.2014 14:39
ce a2 00 00 ce 04 85 52 7e 00 68 09 0a 10 00 77 - 10.02.2014 11:00
ce a2 00 00 ce 04 e5 5c 7e 00 64 09 0a 10 00 58 - 10.02.2014 12:23
eb a2 00 00 ce 04 85 41 7e 00 80 22 0a 10 00 dd - 11.03.2014 08:44
eb a2 00 00 ce 04 85 6a 7e 00 a4 28 0a 10 00 66 - 11.03.2014 14:12
eb a2 20 00 ce 04 8b 6e 00 00 7c 17 08 10 04 e0 - 11.03.2014 14:44
|| || || || ** ** ** ** **
Date? Time?
Stars represent known data (as in I know what those mean and they aren't relevant to date and time)
Provided dates are correct, because they're from usage history printout.
I've tried converting values to unix timestamps, seconds, milliseconds and much more, but I can't determine the format. Also the data might be in little endian.
I'm not sure about possible timezone, data might be in UTC, UTC+2 or UTC+3.
I appreciate any help.
I figured out the format, it goes like this:
All data is in little endian.
To get the time in minutes, the value must be bitsifted to right five times.
For example:
6e8b >> 5 = 884
884 minutes = 14 hours, 44 minutes (14:44)
Date is days from 1.1.1900. For example:
a2eb = 41707 (11.03.2014)