Hi I have been trying to calculate a CRC for a device I want to write a software interface for. For simplicity I will say X is the device and Y is the hardware controller. I am looking for a nudge in the right direction I am sure I am on the correct track just a little confused on a few points.
When the device is idle it sends the following strings of data every 2 seconds or so that looks like it is counting up in hex: The 2 bytes between the | | is the CRC I assume. (XX) is the varying byte.
X: 96 10 01 E1 (E4) 01 FF 10 17 | F7 EC | 10 06 E1 96 FE
X: 96 10 01 E1 (E6) 01 FF 10 17 | 7F FA | 10 06 E1 96 FE
X: 96 10 01 E1 (E8) 01 FF 10 17 | C7 9B | 10 06 E1 96 FE
X: 96 10 01 E1 (EA) 01 FF 10 17 | 4F 8D | FE 10 06 E1 96 FE
X: 96 10 01 E1 (EC) 01 FF 10 17 | D7 B6 | FE 10 06 E1 96 FE
X: 96 10 01 E1 (EE) 01 FF 10 17 | 5F A0 | FE 10 06 E1 96 FE
Using reveng with reveng -w 16 -s and the above sets of data I get:
width=16 poly=0x1021 init=0x1e69 refin=true refout=true xorout=0x0000 check=0x3da6 name=(none)
When I intercept the a command from the controller I get:
X: 96 10 01 E1 (EE) 01 FF 10 17 | 5F A0 | FE 10 06 E1 96 FE -- Last line before command
Y: E1 10 01 96 (22) 05 01 C0 A8 35 00 10 17 |0B B8| FE 10 06 96 E1 FE
Where (22) is the the modifier |0B B8| is the CRC. How is the 22 derived from the E4? is it another CRC?
When I sent the same command several times I intercepted the following:
Y: E1100196220501C0A8350010170BB8FE100696E1FE
Y: E11001962A0501C0A835001017C1C7FE100696E1FE
Y: E11001962E0501C0909400101753C8FE100696E1FE
Y: E1100196300501809094001017C3EEFE100696E1FE
Y: E1100196360501C090940010170D48FE100696E1FE
Y: E11001962A0501C09094001017B6F7FE100696E1FE
Y: E11001962A0501C09094001017B6F7FE100696E1FE
Using reveng with reveng -w 16 -s and the above sets of data I get:
width=16 poly=0x1021 init=0xd313 refin=true refout=true xorout=0x0000 check=0x295f name=(none)
The polynomial is the same but init and check vary, sorry for the long post but here is the summary of my questions:
1) Is it common for say the device to use the same polynomial but different init and check to the controller?
2) Is the constant counting strings from the device used to offset the variable byte used to calculate the checksum? If so what is this mechanism called and what methods could be used to derive the relationship between the count and the byte?
3) Am I on the right track or have I got lost along the way?
Thanks for taking the time to read this and would really appreciate a kick in the right direction.
Drop the first byte off of your X and Y sequences, and then you'll get for both:
width=16 poly=0x1021 init=0xffff refin=true refout=true xorout=0xffff check=0x906e name="X-25"
To wit:
% reveng -w 16 -s 100196220501C0A8350010170BB8 1001962A0501C0A835001017C1C7 1001962E0501C0909400101753C8 100196300501809094001017C3EE 100196360501C090940010170D48 1001962A0501C09094001017B6F7
width=16 poly=0x1021 init=0xffff refin=true refout=true xorout=0xffff check=0x906e name="X-25"
% reveng -w 16 -s 1001E1E401FF1017F7EC 1001E1E601FF10177FFA 1001E1E801FF1017C79B 1001E1EA01FF10174F8D 1001E1EC01FF1017D7B6 1001E1EE01FF10175FA0
width=16 poly=0x1021 init=0xffff refin=true refout=true xorout=0xffff check=0x906e name="X-25"
Related
I have an AC Huffman table generated as follows:
Destination ID = 1
Class = 1 (AC Table)
Codes of length 01 bits (000 total):
Codes of length 02 bits (002 total): 00 01
Codes of length 03 bits (001 total): 02
Codes of length 04 bits (002 total): 03 11
Codes of length 05 bits (004 total): 04 05 21 31
Codes of length 06 bits (004 total): 06 12 41 51
Codes of length 07 bits (003 total): 07 61 71
Codes of length 08 bits (004 total): 13 22 32 81
Codes of length 09 bits (007 total): 08 14 42 91 A1 B1 C1
Codes of length 10 bits (005 total): 09 23 33 52 F0
Codes of length 11 bits (004 total): 15 62 72 D1
Codes of length 12 bits (004 total): 0A 16 24 34
Codes of length 13 bits (000 total):
Codes of length 14 bits (001 total): E1
Codes of length 15 bits (002 total): 25 F1
Codes of length 16 bits (119 total): 17 18 19 1A 26 27 28 29 2A 35 36 37 38 39 3A 43
44 45 46 47 48 49 4A 53 54 55 56 57 58 59 5A 63
64 65 66 67 68 69 6A 73 74 75 76 77 78 79 7A 82
83 84 85 86 87 88 89 8A 92 93 94 95 96 97 98 99
9A A2 A3 A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7
B8 B9 BA C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5
D6 D7 D8 D9 DA E2 E3 E4 E5 E6 E7 E8 E9 EA F2 F3
F4 F5 F6 F7 F8 F9 FA
Total number of codes: 162
I need to find the Mincode, Maxcode and Valptr values from this table. Apparently the decode procedure is not similar to the one of the DC table.
The following answer explains the retrieval of these values from a DC table:
answer
The generation of those tables and the Huffman decoding of the eight-bit value is exactly the same for AC and DC coefficients. What you do with the resulting eight-bit values is different.
When inspecting a transport stream using tsduck, I can see that some packets contains a PCR value in Hex. I am not sure how to convert these into timestamps.
For example, in the packet below the PCR value is 0x000002014CE
* Packet 179
---- TS Header ----
PID: 481 (0x01E1), header size: 25, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 4
Adaptation field: yes (21 bytes), payload: yes (163 bytes)
Discontinuity: 0, random access: 0, ES priority: 0
PCR: 0x000002014CE
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 34 14 12 00 00 0D B0 7E 4E 0C 02 0A 22 8E 00 00 D1 2D 03 64 00
29 00 00 01 E0 00 00 84 C0 0A 31 00 07 44 B7 11 00 05 D4 37 00 00 00 01
09 30 00 00 01 06 01 03 03 84 19 80 00 00 01 41 9A 84 93 D1 13 7F F0 28
2C 26 B5 35 90 10 B7 32 8C FF 00 D3 47 BE 4C 9A 83 AE CD B8 9C 09 5A 60
07 BE C4 F2 2C 5D D3 24 6C 7F A0 E1 C4 7B BC FA 37 CA C5 C0 B0 C4 2C 91
96 09 07 22 C4 A8 55 FF C2 BF 0E 7E 10 74 6D 84 F2 08 9D D0 29 52 7F 2B
F6 3E C8 23 1F BC 4E 80 C3 AE FD AC F4 96 08 E5 13 C8 A7 41 20 B4 F6 F8
E1 14 4A 03 4C 8E 98 00 04 73 2D AE 83 31 0B C8 61 03 3A A1
What I tried is looking at the first few instances of packets that had the PCR values in them, then converting them to decimal and subsequently dividing by 90,000 which is the clock rate of the PCR clock (i.e the timebase).
But looking at the last column, it doesn't look right. It would seem that the intervals are too high. I thought that the PCR must insert PCR stamps at least every 100ms or so, but this seems to be too infrequent....
You are not using the correct time base. If you look at the example you posted, tsduck shows the PCR as 0x000002014CE But that hex value does not show up in that packet at all. The reason is the PCR is more than just a time stamp, Its 2 timestamps. The PCR in the hex is actually 00 00 0D B0 7E 4E So how do we get from 0xDB07E4E to 0x2014CE? We extract the 90 kHz component by shifting 0xDB07E4E right by 15 bits, Then extract the 27MHz component by masking off the top 39 bits. Then multiply the 90kHz component by 300 to convert to 27MHz (300=27000000/90000) and add the two values together:
300*(0xDB07E4E>>15) + (0xDB07E4E&0x1ffff) = 0x2014CE
We now have the 27MHz timestamp. To convert that to seconds, divide by 27000000
0x2014CE/27000000=0.0779
Hence:
0x58e54 = 0.0135
0x78707 = 0.0183
TLDR: time base is 27000000, not 90000
I can't finish the authentication phase.
What I am using:
SAM module by NXP
Mifare Desfire PICC
I am following the next steps:
Get PICC SerialNumber (or UID) with GetVersion.
GET VERSION:
Tx: 90 60 00 00 00
Rx: 04 01 01 00 02 18 05 91 AF
GET VERSION 2:
Tx: 90 AF 00 00 00 00
Rx: 04 01 01 00 06 18 05 91 AF
GET VERSION 3:
Tx: 90 AF 00 00 00 00
Rx: 04 65 41 49 65 1B 80 8E 65 58 51 30 46 07 91 00
Get encrypted(RndB) from PICC.
Tx: 90 0A 00 00 01 00 00
Rx: 31 15 1A 19 DB ED CD 5A 91 AF
Send to SAM PICC_SN + ek(RndB).
Tx: 80 41 01 03 0F 80 1B 65 49 41 65 04 31 15 1A 19 DB ED CD 5A
Rx: 61 20
Get from SAM encrypted(RndA + RndB_rotated) + 1st half Session Key
Tx: 00 C0 00 00 20
Rx: F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB E9 F3 51 04 41 8A 4E A5 A2 B5 67 CA FF D8 D2 35 90 00
Send PICC encrypted(RndA + RndB_rotated).
Tx: 90 AF 00 00 10 F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB 00
Rx: 91 AE
So, this is a guide I have received from my suplier, and i don't have explanations about the apdus used; some i have found them on the internet, some others i guessed.
What I need to know is what does the next command i use:
to SAM module: 80 41 01 03 Lc Data
I need to know what encryption it deploys, why it needs PICC's UID (is this the IV), how can i know RndB, and what is expecting the PICC to end the authentication.
Thanks
Pd: Sorry for the text's format, it seems I'm unable to use correctly the tools for posting, everything gets in the same line it's disgusting...
I solved the problem and finished authentication.
The error was that i was requesting RndB encrypted with keyNo = 0, while corresponding key from SAM's key encryption should be keyNo = 2.
So:
--> 90 0A 00 00 01 02 00
<-- 91 B6 08 CE 9F B5 34 3B 91 AF
Carrying on, i finnish authentication:
--> 90 AF 00 00 10 0F DC FA B6 37 5F 30 34 D7 93 2D A1 3D D6 11 10 00
<-- E9 C2 F2 69 FE 38 78 28 91 00
But now I have the next problem. I've authenticated and I can read PICC's data but i'm afraid it's encrypted. I suppose it is encrypted with session key, so I need some apdu command to be sent to SAM, with data and session key, in order to decrypt data retrieved from PICC.
Am I right? if that is... which would be that SAM APDU?
I am working with a Visa CDET contact-less test card. I have successfully selected the Application, which gave me the following result:
<= 6f 29 84 07 a0 00 00 00 03 10 10 a5 1e 50 0b 56 49 53 41 20 43 52 45 44 49 54 5f 2d 02 65 6e 9f 38 09 9f 66 04 9f 02 06 9f 37 04
The result included a PDOL which asked for the following items:
Terminal Transaction Qualifiers
Length: 4 bytes
Authorised Amount
Length: 6 bytes
Unpredictable Number
Length: 4 bytes
When it comes to the GPO command, I do have all the elements needed as shown below:
=> 80 a8 00 00 10 83 0e f3 20 40 00 00 00 00 00 12 00 bc 4b a2 3f 00
But when i run the command, I received a 67 00 error: Wrong Lc length. What could be the issue? Keep in mind the same program works perfectly when working with Visa CDET Contact test cards from the same kit.
EDIT:
About the same problem, I have a test reader that I use to confirm my readings. The reader and its program can get the GPO options and return the result for other cards, but my program is not giving me any results when I try the EXACT same command using the EXACT same card in my custom program. The result is a blank, yet the status words are 90 00 (they are separate from the returned data). Why is that?
Just assume first, that the card is right: If the length of data object 83 is 0x0F (instead of 0x0E) if I counted correctly, then the total length to be supplied in LC has to be 0x11 instead of 0x10 (tag and length to be added). This does not explain, why the contact version works, but possibly it still will work after the adjustment.
I received a 67 00 error: Wrong Lc length.
ok, its because you dont have Lc=0x00 in APDU
just add 0x00 to APDU
I am getting a strange output when I try to connect my ISO 14443a card to an NFC reader.
0: : 26
0: 0: TAG 04 00
0: : 93 20
0: 0: TAG 47 82 db b3 ad
0: : 93 70 47 82 db b3 ad 3a f4
0: 0: TAG 28 b4 fc
0: : e0 50 bc a5
0: 0: TAG 13 78 80 82 02 80 31 80 66 b0 84 16 01 6e 01 83 00 90 00 03 d1
0: : e0 50 bc a5
0: 0: TAG 13 78 80 82 02 80 31 80 66 b0 84 16 01 6e 01 83 00 90 00 03 d1
0: : c2 e0 b4 <<<< WHAT??
0: 0: TAG 03 6a 82 4f 75
0: : 26
0: 0: TAG 04 00
0: : 78
You can see that the cards is woken up, performs the anti-collision, then sends its ATS when requested (it gets asked twice for some reason?).
After this, the reader sends a strange command (marked above) and the card responds with an 'Operation not supported' response.
The wake-up, anti-collision protocol then restarts, and this goes on and on.
My question is, what does the command (c2 e0 b4) sent from the reader mean?
Thanks in advance.
I do not know if you are still interested in the response, I will just save time for anyone else who might be looking for the solution(like I was).
This is nothing else but S(Deselect) block sent from the reader, consisting of Protcol Contol Byte(PCB) and 2 bytes of CRC_A
C2 E0 B4
The same applies for anyone who might be looking for this command coming from the reader:
B2 67 C7
It is R(NACK) block, consisting of Protcol Contol Byte(PCB) and 2 bytes of CRC_A
They both are a fundamental part of ISO-DEP protocol(Type 4A or Type 4B tags), so read description and how to properly handle them in the "NFC Digital Protocol" spec, chapter "13 ISO-DEP Protocol"