maybe somebody can help to guess how byte 9 CRC (f1, 83, 97) is caclutaed here:
55 0с 00 ff 00 0a 01 05 f1 0a 82 01 80 09 0c
55 0c 00 03 05 81 01 05 83 01 82 01 64 e6 0c
55 0c 00 03 00 90 01 05 97 01 82 01 64 e6 0c
55 0c 00 03 01 90 01 05 96 01 82 01 64 e6 0c
55 0c 01 03 01 90 01 05 97 01 82 01 64 e6 0c
55 0c 01 04 01 90 01 05 90 01 82 01 64 e6 0c
55 0c 02 04 02 90 01 05 90 01 82 01 64 e6 0c
55 0c 00 01 00 81 01 05 84 01 82 01 64 e6 0c
55 0c 00 02 00 81 01 05 87 01 82 01 64 e6 0c
55 0c 00 03 00 81 01 05 86 01 82 01 64 e6 0c
55 0c 00 04 00 81 01 05 81 01 82 01 64 e6 0c
55 0c 00 05 00 81 01 05 80 01 82 01 64 e6 0c
55 0c 00 06 00 81 01 05 83 01 82 01 64 e6 0c
each line does the same command if I send to device, just need to understand how byte 9 calulated here.
def get_chksum(packet):
chksum = 0
for i in packet:
chksum ^= ord(i)
return hex(chksum)
print(get_chksum('\x00\xff\x00\x0a\x01\x05')) # 0xF1
print(get_chksum('\x00\x03\x05\x81\x01\x05')) # 0x83
print(get_chksum('\x00\x03\x00\x90\x01\x05')) # 0x97
Related
I use Nginx 1.19.6 and OpenSSL 1.1.1i.
But I checked my server support client-initiated secure renegotiation... (https://www.immuniweb.com/ssl/?id=Ek4FSF6C)
I don't know why my server supports client-initiated secure renegotiation.
Check Code:
openssl s_client -connect gjan.info:443 -msg -tls1_2
Result:
---
R
RENEGOTIATING
>>> ??? [length 0005]
16 03 03 00 f6
>>> TLS 1.2, Handshake [length 00de], ClientHello
01 00 00 da 03 03 cb bf ab b8 6f a1 31 14 2d fb
ad 63 aa d2 15 c6 5d fc 8c 19 fc db 4c 7f 5b d8
f1 f1 fd f3 29 fa 00 00 36 c0 2c c0 30 00 9f cc
a9 cc a8 cc aa c0 2b c0 2f 00 9e c0 24 c0 28 00
6b c0 23 c0 27 00 67 c0 0a c0 14 00 39 c0 09 c0
13 00 33 00 9d 00 9c 00 3d 00 3c 00 35 00 2f 01
00 00 7b ff 01 00 0d 0c 1b a5 84 2c 92 28 da 6e
0c 84 5f c4 00 00 00 0e 00 0c 00 00 09 67 6a 61
6e 2e 69 6e 66 6f 00 0b 00 04 03 00 01 02 00 0a
00 0c 00 0a 00 1d 00 17 00 1e 00 19 00 18 00 23
00 00 00 16 00 00 00 17 00 00 00 0d 00 30 00 2e
04 03 05 03 06 03 08 07 08 08 08 09 08 0a 08 0b
08 04 08 05 08 06 04 01 05 01 06 01 03 03 02 03
03 01 02 01 03 02 02 02 04 02 05 02 06 02
<<< ??? [length 0005]
15 03 03 00 1a
<<< TLS 1.2, Alert [length 0002], warning no_renegotiation
01 64
>>> ??? [length 0005]
15 03 03 00 1a
>>> TLS 1.2, Alert [length 0002], fatal handshake_failure
02 28
547636304368:error:14094153:SSL routines:ssl3_read_bytes:no renegotiation:../ssl/record/rec_layer_s3.c:1560:
Is just ImmuniWeb error or really my web server supported? If supported how can I disable?
It's just immuniweb. Qualys/ssllabs correctly shows
Secure Renegotiation Supported
Secure Client-Initiated Renegotiation No
Insecure Client-Initiated Renegotiation No
The first means the RFC5746 negotiation during handshake works; the second and third mean actual renegotiation initiated by the client fails.
PS: this isn't really a programming question or problem, but as long as others haven't voted to close I won't bother.
It might not be possible to use a setting in nginx to solve this security issue. However, you might refer nginx developers to this answer so they can make proper changes in their codebase. This is NOT just immuniweb as the other answer indicates.
The SSL_OP_NO_RENEGOTIATION option were added in OpenSSL 1.1.1. To make immuniweb give you the same score as we have (A+) you need to set SSL_OP_NO_RENEGOTIATION in order to disable all renegotiation in TLSv1.2 and earlier. This needs to be set where the SSL_CTX is created. You might also need to make additional changes in order to get the wanted scoring.
SSL_CTX *ssl_ctx = SSL_CTX_new(TLS_method());
...
SSL_CTX_set_options(ssl_ctx, SSL_OP_NO_RENEGOTIATION);
Source: SSL_CTX_set_options man 1.1.1
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
Here follows the hex dump of the MPEG2VideoDescriptor:
06 0e 2b 34 02 53 01 01 0d 01 01 01 01 01 51 00
83 00 00 f3 3c 0a 00 10 a3 be 51 b2 00 05 e7 11
bf 82 21 97 f7 a0 14 ed 30 06 00 04 00 00 00 02
30 01 00 08 00 00 ea 60 00 00 03 e9 80 00 00 04
01 c9 c3 80 30 04 00 10 06 0e 2b 34 04 01 01 02
0d 01 03 01 02 04 61 01 32 15 00 01 05 32 0e 00
08 00 00 00 10 00 00 00 09 32 0d 00 10 00 00 00
02 00 00 00 04 00 00 00 1a 00 00 00 00 32 0c 00
01 00 32 08 00 04 00 00 02 d0 32 09 00 04 00 00
05 00 32 02 00 04 00 00 02 d0 32 03 00 04 00 00
05 00 32 01 00 10 06 0e 2b 34 04 01 01 03 04 01
02 02 01 04 03 00 33 02 00 04 00 00 00 02 33 08
00 04 00 00 00 01 33 03 00 01 04 33 01 00 04 00
00 00 08 33 0b 00 01 00 33 07 00 02 00 00 33 04
The first 16 bytes:
06 0e 2b 34 02 53 01 01 0d 01 01 01 01 01 51 00 (UID)
Next 4 bytes is the BER size:
83 00 00 f3 (0xf3 bytes long)
Next 4 bytes:
3c 0a 00 10 (0x3c0a means Instance UUID and 0x0010 is the size)
Then follows the UUID:
a3 be 51 b2 00 05 e7 11 bf 82 21 97 f7 a0 14 ed
Next 4 bytes:
30 06 00 04 (0x3006 means Linked Track ID and 0x0004 is the size)
Next 4 bytes is the Linked Track ID: 00 00 00 02
Next 4 bytes: 30 01 00 08 (0x3001 means Sample Rate and 0x0008 is the size)
The following 8 bytes are actually frame rate numerator and denominator:
0000ea60 == 60000 and 000003e9 == 1001.
Now we have the bold part: 80 00 00 04
.
Can somebody please explain what does it mean?
The next four bytes are 01 c9 c3 80 and it is definitely the bitrate (30000000), but how can I know that for sure?
Edit:
Does 80 00 00 04 mean the following:
0x8000 is a dynamic tag. According to SMPTE 337, tags 0x8000-0xFFFF are dynamically allocated. The 0x0004 is the size (4 bytes). If that's true, how can I tell that the following 4 bytes 01 c9 c3 80 are actually the bitrate? It could be anything, or?
First you have to understand how local tags work.
Local tags 0x8000 and above are user defined.
You have to look at the primer pack of the header partition.
The primer pack translates the local tag to a global UL which may or may not be vendor specific.
Consider the primer pack being a translation table between the 2 byte local tag and the 16 byte UL.
I'm trying to filter duplicated/lost packets from TCP sniffing (using pcap), but I stopped at the understanding of seq/ack. Here are my logs with relative seq/ack:
CLIENT->SERVER/Seq=0;Ack=0/SYN/P.size:0; No data in TCP. Size: 66/66 -> 20 E7 1E 61 15 5B 4E 1D 00 00 00 00 80 02 F7 D3 4D 03 00 00 02 04 05 B4 01 03 03 06 01 01 04 02 | No payload
SERVER->CLIENT/Seq=0;Ack=1/ACK+SYN/P.size:0; No data in TCP. Size: 58/58 -> 1E 61 20 E7 C4 9D 5B 6B 15 5B 4E 1E 60 12 20 00 2D D1 00 00 02 04 05 B4 | No payload
CLIENT->SERVER/Seq=1;Ack=1/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4E 1E C4 9D 5B 6C 50 10 01 6D 64 21 00 00 | No payload
SERVER->CLIENT/Seq=1;Ack=268/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 10 5B 40 09 43 00 00 | No payload
CLIENT->SERVER/Seq=1;Ack=1/ACK+PSH/P.size:267; 20 E7 1E 61 15 5B 4E 1E C4 9D 5B 6C 50 18 01 6D AF 0B 00 00 | 0B 01 00 EA 02 00 00 09 07 54 56 03 09 0B 01 07 02 54 54 56 07 00 02 55 56 00 51 00 53 57 04 07 55 08 54 01 07 01 53 00 56 55 56 01 06 05 04 51 03 08 51 08 51 56 04 54 06 55 08 02 09 51 56 01 53 06 55 04 53 00 56 56 53 01 09 02 09 01 51 54 51 09 55 56 09 03 04 07 05 55 04 06 55 04 06 09 04 51 01 08 08 06 05 52 06 04 01 07 54 03 06 52 55 06 55 55 51 01 02 04 54 03 55 54 01 57 51 55 05 52 05 54 07 51 51 55 07 02 53 53 00 52 05 52 07 01 54 00 03 05 05 08 06 05 05 06 03 00 0D 08 01 07 09 03 51 03 07 53 09 51 06 07 54 0A 50 56 02 52 04 05 55 51 02 53 00 08 54 04 52 56 06 02 09 00 08 03 53 56 01 05 00 55 06 08 56 04 0D 06 07 52 06 07 04 0A 06 01 04 54 04 00 05 02 04 54 00 09 52 53 05 04 01 04 05 05 01 52 51 52 0D 06 51 08 09 54 53 00 0D 01 02 03 54 53 01 05 03 08 56 54 07 02 54 0B 06 DC 4F 61 4F
CLIENT->SERVER/Seq=267;Ack=1/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 28 C4 9D 5B 6C 50 10 01 6D 63 17 00 00 | No payload
SERVER->CLIENT/Seq=1;Ack=268/ACK+PSH/P.size:20; 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 18 5B 40 3A C6 00 00 | 14 00 00 01 E0 41 9A F0 98 F5 A4 37 01 00 00 00 01 00 00 00
CLIENT->SERVER/Seq=268;Ack=21/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 29 C4 9D 5B 80 50 10 01 6D 63 02 00 00 | No payload
SERVER->CLIENT/Seq=21;Ack=305/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 80 15 5B 4F 4E 50 10 5B 40 09 0A 00 00 | No payload
CLIENT->SERVER/Seq=268;Ack=21/ACK+PSH/P.size:37; 20 E7 1E 61 15 5B 4F 29 C4 9D 5B 80 50 18 01 84 6B AF 00 00 | 25 00 32 DF 4C C6 2A 51 18 85 82 AC 27 D8 7A 06 44 DF F7 27 BD FC 59 43 3B E7 19 53 33 37 78 7B 93 81 38 51 CB
CLIENT->SERVER/Seq=304;Ack=21/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4D C4 9D 5B 80 50 10 01 84 62 C7 00 00 | No payload
SERVER->CLIENT/Seq=21;Ack=305/ACK+PSH/P.size:328; 1E 61 20 E7 C4 9D 5B 80 15 5B 4F 4E 50 18 5B 40 AD 89 00 00 | 48 01 F3 B3 29 D9 41 E1 45 1B D3 98 0B 6E CF CC FD 18 F8 B9 23 3B 66 93 37 62 AA E9 7A 43 E2 B9 88 1F FF 77 80 70 E8 1D B9 8E 46 61 F2 F3 52 3E 0F 98 78 3B A1 51 C9 1E BA 8D 45 63 F0 F1 50 F9 F1 67 87 9E 3A C8 50 9D CB 03 34 63 CD C6 B0 FF 7A 4D ED 9F 36 F5 5E 98 43 FC 74 5A 8D 9E 3F 07 BC 10 F3 B2 28 D8 40 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 A2 06 31 F9 DE 4D 4C ED 81 B0 27 C7 86 1C EC 74 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 A2 06 31 F9 DE 4D 4C ED 81 B0 27 C7 86 1C EC 74 81 25 12 DA FD 6E 6F CE A2 93 04 E4 A5 3F CF 57 33 86 71 B9 8A 17 C7 66 1E 21 67 87 7A 95 B4 2C D9 7D 4A 82 A5 36 37 96 8B DB 85 65 24 BE 4E D6 23 87 B0 78 5F CC CD 6C 00 31 A6 46 07 9D 6D F5 00 A4 93 5B 7C EF EE 4F 23 12 85 65 24 BE 4E D6 23 87 B0 78 3F AE AF 0E 5E 6F F8 18 65 FF 0F 97 22 86 B1 79 5E CD CC 6D 01 30 A7 47 F3 76 86 1E EB 4F 78 B0 93 00 01 A0 CC FD 6A 8A C9 53 A3 3B B...
CLIENT->SERVER/Seq=305;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4E C4 9D 5C C8 50 10 01 84 61 7E 00 00 | No payload
CLIENT->SERVER/Seq=305;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4E C4 9D 5C C8 50 10 01 9B 61 67 00 00 | No payload
CLIENT->SERVER/Seq=304;Ack=349/ACK/P.size:0; No data in TCP. Size: 54/54 -> 20 E7 1E 61 15 5B 4F 4D C4 9D 5C C8 50 10 01 B2 61 51 00 00 | No payload
SERVER->CLIENT/Seq=349;Ack=305/ACK+PSH/P.size:7; 1E 61 20 E7 C4 9D 5C C8 15 5B 4F 4E 50 18 5B 40 05 3F 00 00 | 07 00 67 24 BE 4E D6
On the line 5
SERVER->CLIENT/Seq=1;Ack=268/ACK/P.size:0; No data in TCP. Size: 54/54 -> 1E 61 20 E7 C4 9D 5B 6C 15 5B 4F 29 50 10 5B 40 09 43 00 00 | No payload
server sends ACK with 268, while client sends those 267-length size data only on the next line. Why order is broken here??
As I understand, fisrt client should send seq1/ack1/L=267, and then server should resp with seq1/Ack268.
Or does it mean, that I have to implement whole logic for packet exchange in TCP protocol (including selective ACKs?)
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)