Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:BUG: soft lockup - CPU#30 stuck for 61s! [events/30:161]
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Process events/30 (pid: 161, ti=f4ea4000 task=f4e5faa0 task.ti=f4ea4000)
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Stack:
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Call Trace:
Message from syslogd#saskappcu at Mar 18 13:24:54 ...
kernel:Code: 00 89 51 04 89 0a 89 43 20 89 43 24 8b 43 08 39 d8 74 23 83 40 7c 01 31 c9 8b 7b 0c 8b 15 58 09 ac c0 8b 02 39 c2 75 09 eb 31 90 <8b> 00 39 d0 74 2a 3b 78 0c 75 f5 89 d8 ba 00 00 04 00 e8 b9 a0
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:BUG: soft lockup - CPU#8 stuck for 61s! [buildop:2223]
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Process buildop (pid: 2223, ti=e9724000 task=f3ba0aa0 task.ti=e9724000)
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Stack:
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Call Trace:
Message from syslogd#saskappcu at Mar 18 13:24:58 ...
kernel:Code: 26 00 89 c8 f0 81 28 00 00 00 01 74 05 e8 2c fe ff ff c3 8d b4 26 00 00 00 00 66 ba 00 01 f0 66 0f c1 10 38 f2 74 0e f3 90 8a 10 <eb> f6 66 83 38 00 75 f4 eb e5 c3 8d 74 26 00 f0 81 28 00 00 00
A softlockup is defined as a bug that causes the kernel to loop in
kernel mode for more than 20 seconds without giving other tasks a chance to run.
The log
kernel:BUG: soft lockup - CPU#30 stuck for 61s! [events/30:161]
is generated by the following line in kernel/kernel/watchdog.c
pr_emerg("BUG: soft lockup - CPU#%d stuck for %us! [%s:%d]\n",
smp_processor_id(),
duration,
current->comm,
task_pid_nr(current));
It means that
The CPU core 30 in the system,
has been busy executing kernel code for the past 61 seconds.
The current thread on the system being events/30,
whose process-id is 161.
For more details, checkout kernel/Documentation/lockup-watchdogs.txt.
Related
im trying to reverse one app, and wanted to ask, maybe some one can help with fresh idea, or already know what is used here.
So the case, i have client and server, now i have written mitm app, and i can see the packets.
Tha packets order is
s2c: sending rsa key
c2s: sending some always static data, encrypted with rsa
s2c: sending some response, seems like an packet without body (im here)
c2s: sending data, and here is problem, that this packet is not encrypted as packet 2
c2s: sending response
this is packet header
50 50 00 00 40 00 50 00 00 00 00 00 ... rest is body
lets divide it
50 50 - this is always same
00 00 - this is some packet flag, cause always after packet 3, it becomes x04 00
40 00 - this is length 100%
50 00 - packet code i think
00 00 00 00 - i dont know what i this
body - is not readable, but also is not encrypted with rsa
here is example of stream
**s2c packet 1**
2023/01/24 21:32:56 Received: 176
00000000 *50 50 00 00 a4 00 01 00 00 00 00 00* a2 00 2d 2d |PP............--|
00000010 2d 2d 2d 42 45 47 49 4e 20 52 53 41 20 50 55 42 |---BEGIN RSA PUB|
00000020 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a 4d 45 63 |LIC KEY-----.MEc|
00000030 43 51 51 43 71 49 4e 36 37 76 45 52 47 37 34 49 |CQQCqIN67vERG74I|
00000040 64 77 38 6d 76 6c 66 6d 45 31 38 31 31 56 74 2b |dw8mvlfmE1811Vt+|
00000050 53 76 66 67 73 36 43 68 59 51 78 4e 5a 52 57 74 |Svfgs6ChYQxNZRWt|
00000060 7a 31 6f 62 50 53 69 34 62 75 78 72 41 0a 5a 6d |z1obPSi4buxrA.Zm|
00000070 6d 77 32 4e 69 38 44 59 74 67 6d 77 54 74 48 51 |mw2Ni8DYtgmwTtHQ|
00000080 66 6b 6d 35 65 59 2f 76 63 54 41 67 49 44 43 51 |fkm5eY/vcTAgIDCQ|
00000090 3d 3d 0a 2d 2d 2d 2d 2d 45 4e 44 20 52 53 41 20 |==.-----END RSA |
000000a0 50 55 42 4c 49 43 20 4b 45 59 2d 2d 2d 2d 2d 0a |PUBLIC KEY-----.|
2023/01/24 21:32:56 RSA Key chaged - here i changed key to my
**c2s packet 2**
2023/01/24 21:32:56 Received: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* 97 4a 85 34 |PP..#.P......J.4|
00000010 e6 e0 f8 56 d6 5b 12 a4 4b 3f e2 f3 c7 b4 a1 fc |...V.[..K?......|
00000020 c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 09 7b 52 4a |.............{RJ|
00000030 23 be a4 47 eb b8 02 f5 0a 62 9a 88 15 13 12 de |#..G.....b......|
00000040 a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |..,:.4G..o..|
2023/01/24 21:32:56 Header: 76
00000000 *50 50 00 00 40 00 50 00 00 00 00 00* |PP..#.P.....|
2023/01/24 21:32:56 Encoded with my key
00000000 *97 4a 85 34 e6 e0 f8 56 d6 5b 12 a4* 4b 3f e2 f3 |.J.4...V.[..K?..|
00000010 c7 b4 a1 fc c7 fe b8 88 bc b7 8b 93 89 c2 7f 02 |................|
00000020 09 7b 52 4a 23 be a4 47 eb b8 02 f5 0a 62 9a 88 |.{RJ#..G.....b..|
00000030 15 13 12 de a4 94 2c 3a 0a 34 47 bb 13 6f d4 ae |......,:.4G..o..|
2023/01/24 21:32:56 Decoded body
00000000 29 00 00 00 23 48 00 00 be 18 00 00 84 67 00 00 |)...#H.......g..|
2023/01/24 21:32:56 Encoded with original key
00000000 0a cb d2 7f f6 a3 8b 57 2c 6b e8 6d ed f0 c1 36 |.......W,k.m...6|
00000010 e4 c8 00 9d ca 55 41 62 ef 4b 72 91 7c fc 7b 1d |.....UAb.Kr.|.{.|
00000020 e4 5c f0 2b ce 86 01 79 ae b8 13 dd 51 a0 30 c5 |.\.+...y....Q.0.|
00000030 6f 77 fa 11 ed 03 7b 2c 77 7c 5b 7e 61 6f 86 9d |ow....{,w|[~ao..|
**s2c packet 3**
2023/01/24 21:32:56 Received: 12
00000000 *50 50 00 00 00 00 02 00 00 00 00 00* |PP..........|
**c2s packet 4**
2023/01/24 21:32:56 Not decoding next packet
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 30 00 00 00 00* 00 9f 53 ab |PP.....0......S.|
00000010 c8 58 49 ea 4d fa 18 f4 f1 fc 9a 3c 04 ca 11 94 |.XI.M......<....|
00000020 ab ec ba 1d c6 f0 5d e0 1f d6 87 2d de 0c 97 eb |......]....-....|
00000030 29 b7 d1 dc 48 38 f4 63 74 29 e2 ea 9f 81 a8 59 |)...H8.ct).....Y|
00000040 47 75 32 0d 53 0e 55 3e cd 7b 89 d9 c3 22 d5 39 |Gu2.S.U>.{...".9|
00000050 c4 18 a5 c7 e2 eb 3a 9e 72 13 36 c3 52 f5 e6 7d |......:.r.6.R..}|
00000060 9b bf 37 06 e5 e9 4c 74 ac 85 37 85 94 81 37 67 |..7...Lt..7...7g|
00000070 f9 28 60 c7 0a ca 4c 5a 57 20 d6 ce 7c 91 58 6b |.(`...LZW ..|.Xk|
00000080 56 af 96 a8 e4 b5 8c 19 2e 9a 8c fa a6 c2 08 24 |V..............$|
00000090 ab 97 5d be 74 c2 19 d2 bd f1 93 5f a5 65 c5 7c |..].t......_.e.||
000000a0 fa bb 46 07 80 fd b6 79 5c 19 6f 65 54 35 |..F....y\.oeT5|
**s2c packet 5**
2023/01/24 21:32:56 Received: 174
00000000 *50 50 04 00 a2 00 01 40 00 00 00 00* 00 9e e7 03 |PP.....#........|
00000010 1b aa 67 36 1e 6f 34 20 c3 7c a9 85 93 74 b7 53 |..g6.o4 .|...t.S|
00000020 cc 10 68 90 ec 41 54 68 bb 9e 3d 41 c9 3f db 41 |..h..ATh..=A.?.A|
00000030 09 b9 ae 6a 9b f9 5c 0f 47 c6 4b bd 94 08 20 b0 |...j..\.G.K... .|
00000040 2e f2 6e 40 11 b6 14 8b e0 51 89 db 0c e0 c8 5b |..n#.....Q.....[|
00000050 92 1f a3 08 90 05 5c b5 bb bb 50 c0 3e f6 ee e8 |......\...P.>...|
00000060 63 bd 23 74 53 24 8f a3 0b 4e 72 12 a0 0e ac 96 |c.#tS$...Nr.....|
00000070 03 2c e8 31 6a 34 10 84 63 7a e1 32 42 d3 69 17 |.,.1j4..cz.2B.i.|
00000080 73 df a4 89 35 90 0f 92 06 d7 3b 2e 3c 3d 6e 7e |s...5.....;.<=n~|
00000090 db 73 cb f0 96 95 df 84 af 20 b7 7b 7c 64 61 a9 |.s....... .{|da.|
000000a0 b2 0e 9d 1e bc 57 73 5f f0 bc a5 aa b8 36 |.....Ws_.....6|
Maybe some one can identify protocol by packet header, cause i havent seen something similar before.
Thank you
i know that only packet 2 is encrypted, cause i changed rsa key to my key, and decoded data, its not work with other packets.
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.
There are lots of questions about Desfire EV1 cards here on Stackoverflow.
But if you search for some example data the only place where you will find a few bytes is in Ridrix Blog. But this is quite incomplete.
A lot of people wrote their problems there while developing code for Desfire cards. But mostly when they solved their problem they were too lazy to post the solution. So you find many questions but very few answers with data examples.
Even if you have the Desfire EV1 documentation (I dont have it, I studied easypay code), you will need more than that. A documentation is only theory. But what is the reason that your card returns an Authentication Error or an Integrity Error or an unexpected CMAC?
Is the Session key OK ?
Is CBC working in the correct mode ?
Is the CMAC calculated correctly ?
Is the CRC32 correct ?
Is the IV of the session key correct before / after a function call ?
Without examples you are completely lost.
After spending several weeks with Desfire EV1 development I decided to post some examples for all those who need input data to feed their complex cryprographic functions and compare the output with the expected data. I know that this is EXTREMELY helpfull.
Here you find some Debug output from the most important Desfire EV1 operations.
Currently you cannot find this information in internet.
If I would have had these examples I would have saved a LOT of time developing my code.
Pitfalls for ISO and AES authenticated sessions
In ISO and AES mode EVERY encryption/decryption goes through CBC.
The IV of the session key is reset to zero only ONCE when the key is created after authentication.
The IV of the authentication key is reset only ONCE when authentication starts.
During authentication:
Random B is received from the card with RECEIVE + DECIPHER
Random AB is sent to the card with SEND + ENCIPHER
Random A is received with RECEIVE + DECIPHER
The CMAC is a copy of the IV of the session key.
The CMAC must mostly be calculated for data sent to the card and for data returned from the card.
But all commands that do a CBC encryption (e.g. ChangeKeySettings) differ from that scheme.
Commands that send/receive multiple frames (e.g. GetApplicationIDs) must calculate the CMAC over the data of all frames that have been sent/received (not including the 0xAF status byte).
For TX data the CMAC is calculated over the command byte + all parameter bytes.
For RX data the CMAC is calculated over all response bytes + the last status byte (always 00 = Success) that must be appended at the end!
The authentication is invalidated:
when an error occures (status != 00 and != AF),
when SelectApplication is executed,
after the same key has been changed that was used for authentication,
when another card comes into the RF field (don't forget to reset your variables).
In these cases the session key is no longer valid and so a CMAC must not be calculated.
The CRC32 of the new key is calculated only over the key data itself.
The CRC32 of the cryptogram is calculated over command, key number and the not yet encrypted cryptogram.
The following debug output has been generated by my code running in a Teensy 3.2 with a PN532 board from Adafruit.
For further details see my source code.
The C++ source code has been written for Arduino/Teensy, but it has been designed multiplatform so that it can be compiled on Visual Studio, Linux or other platforms. The ZIP file also contains a Visual Studio project.
In the following examples all keys have key version 0x10.
ISO Authentication with 2K3DES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (DES))
Sending: <1A 00>
Response: <AF B8 90 04 7F 2D C8 D6 8B>
* RndB_enc: B8 90 04 7F 2D C8 D6 8B
* RndB: 74 B8 43 5F CB A0 B6 75
* RndB_rot: B8 43 5F CB A0 B6 75 74
* RndA: 92 31 34 8B 66 35 A8 AF
* RndAB: 92 31 34 8B 66 35 A8 AF B8 43 5F CB A0 B6 75 74
* RndAB_enc: 7C 84 6A 50 7B 9B 6E 68 64 BC 33 72 A3 06 A8 C1
Sending: <AF 7C 84 6A 50 7B 9B 6E 68 64 BC 33 72 A3 06 A8 C1>
Response: <00 B7 96 DD 3F 81 15 45 F3>
* RndA_enc: B7 96 DD 3F 81 15 45 F3
* RndA_dec: 31 34 8B 66 35 A8 AF 92
* RndA_rot: 31 34 8B 66 35 A8 AF 92
* SessKey: 92 30 34 8A 74 B8 42 5E 92 30 34 8A 74 B8 42 5E (DES)
Change 2K3DES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: B4 28 2E FA 9E B8 2C AE B4 28 2E FA 9E B8 2C AE (DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (2K3DES)
* CRC Crypto: 0x5001FFC5
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 C5 FF 01 50 00 00 00 00
* CryptogrEnc: 87 99 59 11 8B D7 7C 70 10 7B CD B0 C0 9C C7 DA 82 15 04 AA 1E 36 04 9C
Sending: <C4 00 87 99 59 11 8B D7 7C 70 10 7B CD B0 C0 9C C7 DA 82 15 04 AA 1E 36 04 9C>
Response: <00>
Change 2K3DES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 9C 70 56 82 5C 08 9E C8 9C 70 56 82 5C 08 9E C8 (DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (2K3DES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (DES)
* CRC Crypto: 0xD7A73486
* CRC New Key: 0xC4EF3A3A
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 86 34 A7 D7 3A 3A EF C4
* CryptogrEnc: 7D 83 D3 4E FB 6C 84 98 48 E2 D6 37 AD A2 D0 87 14 36 1A E6 C4 63 14 52
Sending: <C4 01 7D 83 D3 4E FB 6C 84 98 48 E2 D6 37 AD A2 D0 87 14 36 1A E6 C4 63 14 52>
Response: <00 1D 5C 27 97 10 86 30 8D>
CMAC: 1D 5C 27 97 10 86 30 8D
ISO Authentication with 3K3DES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (3K3DES))
Sending: <1A 00>
Response: <AF 14 65 76 AC 1B 7D B8 CA 24 84 C5 69 7F 80 12 E1>
* RndB_enc: 14 65 76 AC 1B 7D B8 CA 24 84 C5 69 7F 80 12 E1
* RndB: BA 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4
* RndB_rot: 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4 BA
* RndA: F5 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6
* RndAB: F5 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 91 37 BB 7A 18 33 E7 39 F0 5E 8F 07 87 D0 C4 BA
* RndAB_enc: D0 55 BD 5E A0 1E BF C3 02 93 D4 8A 54 A0 51 B4 0A 66 57 7A 38 3C 58 ED 77 5C 51 BC 97 D4 FA BD
Sending: <AF D0 55 BD 5E A0 1E BF C3 02 93 D4 8A 54 A0 51 B4 0A 66 57 7A 38 3C 58 ED 77 5C 51 BC 97 D4 FA BD>
Response: <00 E1 EE 93 F0 12 C8 D6 72 11 D4 33 7C AD 56 6A 40>
* RndA_enc: E1 EE 93 F0 12 C8 D6 72 11 D4 33 7C AD 56 6A 40
* RndA_dec: 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 F5
* RndA_rot: 68 6F 3A 39 1C D3 8E BD 10 77 22 81 44 5B F6 F5
* SessKey: F4 68 6E 3A BA 90 36 BA D2 8E BC 10 32 E6 38 F0 80 44 5A F6 06 86 D0 C4 (3K3DES)
Change 3K3DES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: F4 68 6E 3A BA 90 36 BA D2 8E BC 10 32 E6 38 F0 80 44 5A F6 06 86 D0 C4 (3K3DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 (3K3DES)
* CRC Crypto: 0xA2003ED6
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 D6 3E 00 A2 00 00 00 00
* CryptogrEnc: 7F 88 90 C7 CA B9 A4 22 81 73 A6 41 B6 5F 0F 43 FD 40 4A 01 13 71 A9 90 4A 62 9E 3C 20 B2 FF 63
Sending: <C4 00 7F 88 90 C7 CA B9 A4 22 81 73 A6 41 B6 5F 0F 43 FD 40 4A 01 13 71 A9 90 4A 62 9E 3C 20 B2 FF 63>
Response: <00>
Change 3K3DES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 9C 52 0E 3C B4 5A B2 A4 A2 00 C4 DA 72 2C 0E F4 38 FE 8A 48 F8 18 9E 56 (3K3DES)
* SessKey IV: 00 00 00 00 00 00 00 00
* New Key: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 (3K3DES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (3K3DES)
* CRC Crypto: 0x078BAED8
* CRC New Key: 0x12A6733E
* Cryptogram: 00 10 20 31 40 50 60 70 80 90 A0 B0 B0 A0 90 80 70 60 50 40 30 20 10 00 D8 AE 8B 07 3E 73 A6 12
* CryptogrEnc: 72 18 2F 5B 0C F1 7E A0 86 A5 AE A5 64 ED 98 7A F3 90 CD B3 78 36 4E 2B C2 45 8B 3A E3 23 98 4D
Sending: <C4 01 72 18 2F 5B 0C F1 7E A0 86 A5 AE A5 64 ED 98 7A F3 90 CD B3 78 36 4E 2B C2 45 8B 3A E3 23 98 4D>
Response: <00 D2 E3 BD 0D 09 47 72 ED>
CMAC: D2 E3 BD 0D 09 47 72 ED
AES Authentication with AES default key #0
*** Authenticate(KeyNo= 0, Key= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (AES))
Sending: <AA 00>
Response: <AF FF 0A FB 10 B4 3F 3B 34 23 36 57 0F 7A 0E 8B 74>
* RndB_enc: FF 0A FB 10 B4 3F 3B 34 23 36 57 0F 7A 0E 8B 74
* RndB: 1F 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04
* RndB_rot: 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04 1F
* RndA: 73 AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C
* RndAB: 73 AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 45 19 27 E7 C0 FC DE 60 9E E8 02 EF 69 76 04 1F
* RndAB_enc: B3 11 34 03 F5 73 95 35 CA 1A 5D 4B D4 38 BE 03 2B 54 28 32 3D 0A 83 4D 11 8F 35 06 C4 2C 5B 01
Sending: <AF B3 11 34 03 F5 73 95 35 CA 1A 5D 4B D4 38 BE 03 2B 54 28 32 3D 0A 83 4D 11 8F 35 06 C4 2C 5B 01>
Response: <00 E2 AE 7D 31 29 48 19 69 E9 A0 C7 CC 89 1E DF 58>
* RndA_enc: E2 AE 7D 31 29 48 19 69 E9 A0 C7 CC 89 1E DF 58
* RndA_dec: AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 73
* RndA_rot: AE 5D 30 17 42 21 64 FB 16 25 D8 1F 2A 69 8C 73
* SessKey: 73 AE 5D 30 1F 45 19 27 1F 2A 69 8C EF 69 76 04 (AES)
Change AES default key #0
*** ChangeKey(KeyNo= 0)
* SessKey: 73 AE 5D 30 1F 45 19 27 1F 2A 69 8C EF 69 76 04 (AES)
* SessKey IV: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
* New Key: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (AES)
* CRC Crypto: 0x6BE6C6D2
* Cryptogram: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 10 D2 C6 E6 6B 00 00 00 00 00 00 00 00 00 00 00
* CryptogrEnc: 97 41 8E 6C C0 1C 4E 6F AD 4D 87 4D 8D 42 5C EA 32 51 36 11 47 2C DA 04 E3 5E FB 77 9A 7D A0 E4
Sending: <C4 00 97 41 8E 6C C0 1C 4E 6F AD 4D 87 4D 8D 42 5C EA 32 51 36 11 47 2C DA 04 E3 5E FB 77 9A 7D A0 E4>
Response: <00>
Change AES default key #1
*** ChangeKey(KeyNo= 1)
* SessKey: 1C D3 8E BD 95 F3 1C 8A B8 7F 0A C9 C4 EB 64 C6 (AES)
* SessKey IV: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
* New Key: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 (AES)
* Cur Key: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (AES)
* CRC Crypto: 0x84B47033
* CRC New Key: 0x1979E3BF
* Cryptogram: 00 10 20 30 40 50 60 70 80 90 A0 B0 B0 A0 90 80 10 33 70 B4 84 BF E3 79 19 00 00 00 00 00 00 00
* CryptogrEnc: 30 23 FA 06 2D 25 0A 04 35 BA E9 45 CA BE 96 5D 62 2A 47 1D 32 5D 1D 42 EA 81 44 41 CB 1A 20 C3
Sending: <C4 01 30 23 FA 06 2D 25 0A 04 35 BA E9 45 CA BE 96 5D 62 2A 47 1D 32 5D 1D 42 EA 81 44 41 CB 1A 20 C3>
Response: <00 9B 68 30 91 50 E0 72 5E>
CMAC: 9B 68 30 91 50 E0 72 5E
CMAC Calculation for AES 128
From: NIST
AES Key: 2b 7e 15 16 28 ae d2 a6 ab f7 15 88 09 cf 4f 3c
SubKey1: fb ee d6 18 35 71 33 66 7c 85 e0 8f 72 36 a8 de
SubKey2: f7 dd ac 30 6a e2 66 cc f9 0b c1 1e e4 6d 51 3b
Message: <empty>
CMAC: bb 1d 69 29 e9 59 37 28 7f a3 7d 12 9b 75 67 46
Message: 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a
CMAC: 07 0a 16 b4 6b 4d 41 44 f7 9b dd 9d d0 4a 28 7c
Message: 6b c1 be e2 2e 40 9f 96 e9 3d 7e 11 73 93 17 2a ae 2d 8a 57 1e 03 ac 9c 9e b7 6f ac 45 af 8e 51 30 c8 1c 46 a3 5c e4 11
CMAC: df a6 67 47 de 9a e6 30 30 ca 32 61 14 97 c8 27
If you need more examples (also for CreateApplication, SelectApplication, DeleteApplication, GetApplicationIDs, GetKeyVersion, GetKeySettings, ChangeKeySettings, GetCardVersion, FormatCard, CreateStdDataFile, GetFileIDs, GetFileSettings, WriteFileData, ReadFileData, DeleteFile) download the ZIP file on Codeproject where you find a HTML file with the entire selftest that tests all these commands.
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)