Closed holiman closed 9 years ago
I committed the first fix. I'm thinking of adding some way to lower the HF_MINFIELD threshold from the client-side.
@pwpiwi , to be clear; you're talking about the current hf list 14a
as opposed to the old one? The old list function wasn't very robust when data was malformed, e.g. zero-length data and stuff like that.
yes, I do have the current hf list 14a. Please find below some examples of what I think are the results of a wrong synchronization in the Miller decoder. The wrong reader commands are marked in bold.
Example 1 (repeated Rdr 26, Tag 0400):
2687944 | 2689000 | Rdr | 26 | |
2690556 | 2692924 | Tag | 04 00 | |
2700424 | 2702888 | Rdr | 93 20 | |
2704636 | 2710460 | Tag | aa bb cc dd 00 | |
2718244 | 2728772 | Rdr | 93 70 aa bb cc dd 00 03 9e | |
2730328 | 2733848 | Tag | 08 b6 dd | |
2842178 | 2846946 | Rdr | e0 81 b8 62 | |
2848310 | 2848950 | Tag | 04 | |
3188508 | 3189564 | Rdr | 26 | |
3190928 | 3193296 | Tag | 04 00 | |
5100224 | 5101280 | Rdr | 26 | |
5102516 | 5104884 | Tag | 04 00 | |
5488128 | 5489184 | Rdr | 26 | |
5490612 | 5492980 | Tag | 04 00 | |
7399874 | 7400930 | Rdr | 26 | |
7402166 | 7404534 | Tag | 04 00 | |
7787840 | 7788896 | Rdr | 26 | |
7790260 | 7792628 | Tag | 04 00 | |
7800130 | 7802594 | Rdr | 93 20 | |
7804214 | 7810038 | Tag | aa bb cc dd 00 |
Example 2 (weird Reader response after RATS):
7941824 | 7946592 | Rdr | e0 81 b8 62 | |
7947956 | 7948596 | Tag | 04 | |
8288462 | 8288814 | Rdr | 02 | |
10186398 | 10187454 | Rdr | 26 | |
10188818 | 10191186 | Tag | 04 00 |
Example 3 (weird Reader response after SELECT):
11075046 | 11076102 | Rdr | 26 | |
11077594 | 11079962 | Tag | 04 00 | |
11087462 | 11089926 | Rdr | 93 20 | |
11091674 | 11097498 | Tag | aa bb cc dd 00 | |
11105346 | 11115874 | Rdr | 93 70 aa bb cc dd 00 03 9e | |
11117366 | 11120886 | Tag | 08 b6 dd | |
11562542 | 11563150 | Rdr | 09 | |
12649190 | 12650246 | Rdr | 26 | |
12651738 | 12654106 | Tag | 04 00 |
Example 4 (weird Reader response after AUTH):
27660638 | 27665342 | Rdr | 60 00 f5 7b | |
27669522 | 27674258 | Tag | 01 02 03 04 | |
27850910 | 27860286 | Rdr | 22 a2 0e 05 7f 8f d9 71 | !crc |
28525518 | 28525870 | Rdr | 02 | |
29260964 | 29262020 | Rdr | 26 | |
29263320 | 29265688 | Tag | 04 00 |
Examples 5 and 6 (corrupted AUTH (?) after SELECT)
34856192 | 34857248 | Rdr | 26 | |
34858676 | 34861044 | Tag | 04 00 | |
34868544 | 34871008 | Rdr | 93 20 | |
34872628 | 34878452 | Tag | aa bb cc dd 00 | |
34886266 | 34896794 | Rdr | 93 70 aa bb cc dd 00 03 9e | |
34898286 | 34901806 | Tag | 08 b6 dd | |
35644958 | 35649342 | Rdr | 2a e0 4a 19 | !crc |
35650834 | 35651474 | Tag | 04 | |
35766750 | 35771518 | Rdr | 50 00 57 cd | |
35898638 | 35899694 | Rdr | 26 |
43216356 | 43217412 | Rdr | 26 | |
43218648 | 43221016 | Tag | 04 00 | |
43228518 | 43230982 | Rdr | 93 20 | |
43232730 | 43238554 | Tag | aa bb cc dd 00 | |
43246402 | 43256930 | Rdr | 93 70 aa bb cc dd 00 03 9e | |
43258422 | 43261942 | Tag | 08 b6 dd | |
43374622 | 43379006 | Rdr | 6c 20 0b 05 | !crc |
43380370 | 43381010 | Tag | 04 |
I tested a couple of times only. Do these error appear frequently? Regarding corruptions during auth/post-auth, it's difficult without knowing the expected result, but regarding the other errors; one thing struck me.
The 09
could have been 26
rightshifted twice.
The 02
could have been 26
rightshifted four times (or half a byte).
Why it got stuck in 26/0400-loop is really weird.. I wonder if the demod-buffer (or parts thereof) is not been properly cleared in all situations..
Isn't this strange also:
Example 4 (weird Reader response after AUTH):
27660638 | 27665342 | Rdr | 60 00 f5 7b | |
27669522 | 27674258 | Tag | 01 02 03 04 | |
27850910 | 27860286 | Rdr | 22 a2 0e 05 7f 8f d9 71 | !crc |
28525518 | 28525870 | Rdr | 02 |
The reader sends AR/NR, but the tag doesn't answer, instead the reader issues 02
(or, possibly something else). Why doesn't the tag answer earlier?
Regarding corruptions during auth/post-auth, it's difficult without knowing the expected result,
I should have added more information: The last examples show the start of the authentication sequence (with a NON valid key), i.e. still nothing encrypted. The expected reader command at this point in the communication would be 60 00 f5 7b (AUTH-A(0), see beginning of example 4).
The 02
in the example 4 should most probably be 26
after a timeout. The tag doesn't respond because the authentication fails (wrong key).
I have committed a fix in 0c8d25e. As discussed above the major point is reducing the waiting time for a stable (i.e. unmodulated) signal in the Miller decoder before looking for a start bit.
In addition I saved some more waiting cycles in EmSend14443Raw(). The FPGA has an internal delay queue which takes care of the required n*64+20 carrier clock cycles delay between reader command and tag answer. Up to now we assumed the worst case (queue full) and waited enough time that it can be emptied (sent to the reader) before switching the FPGA mode back to TAGSIM_LISTEN. Now checking how much of the queue has really been used and waiting accordingly.
Finally I have made the start bit detection more strict. Up to now we had accepted a sequence of at least 64 ones, followed by two to 11 zeroes followed by at least four ones as a start bit (pattern ....1111111xxxxxxx00xx1111xxxxxxxxxx). Changed to at least 24 ones, followed by two or three zeroes followed by at least five ones (pattern .....1111111100x11111xxxxxxx).
Nice!
I just tested this, as far as I can tell, it works. At least, simming works against the readers I have access to now, and I think we've looked deep enough at this issue that I don't believe we've left anything out. A job well done.
@iceman1001 , could you also confirm that the functionality which didn't work for you earlier now works? I'm itching to finally close this one...
@holiman Sadly I can't since I don't have access to the aformentioned reader. But I have trust in yours and piwis good work.
I'm itching to finally close this one...
Please keep it open for a few days more. I confirmed that there is a phase error "on air" and I am about to fix it.
Any pictures?
Any pictures?
Not yet. Still a long way to become friend with the DSO :angry: :rage: :boom:. But if you look at your own pictures comparing simulated tag and snooped real tag you get the idea.
Ah, I just thought that was an artefact from doing measurements on the same board we're generating the signals from or something.
And that was a good thought as well. The field on air is indeed inverted - both simulated and real tag.
I have some pictures now. The captures had been made with a coil of three loops directly connected to the DSO probe. Reader was an HID Omnikey 5427 CK.
Screenshot 1: A real tag. The fat yellow areas are the 13,56MHz carrier. Left is (the end of) the reader request, right is (the beginning of) the tag's answer:
Screenshot 2: An emulated tag (hf 14a sim 1
Although it seems to have no impact, I have committed a fix as 7554370.
Screenshot 3: hf 14a sim after the fix:
Well, i got my hands on a device again and could test @holiman @pwpiwi changes.
It looks like the response from reader is received, which is good during Auth. Which is good.
but it fails in next step..
(side issue, it seems now also that the "hf mf sniff" has stopped working, but I will have to do further tests to verify it)
---start snippet from a "HF MF SIM u x" session.
Recorded Activity (TraceLen = 10185 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer iso14443a - All times are in carrier periods (1/13.56Mhz) iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
-----------|-----------|-----|-----------------------------------------------------------------|-----|--------------
0 | 992 | Rdr | 52 | | WUPA
2612 | 4980 | Tag | 04 00 | |
37958 | 40422 | Rdr | 93 20 | | ANTICOLL
42234 | 48058 | Tag | af be e9 ef 17 | |
83356 | 93884 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID
95376 | 98896 | Tag | 08 b6 dd | |
127436 | 132204 | Rdr | 50 00 57 cd | | HALT
295586 | 296578 | Rdr | 52 | | WUPA
298070 | 300438 | Tag | 04 00 | |
335558 | 346086 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID
347770 | 351290 | Tag | 08 b6 dd | |
408268 | 413036 | Rdr | 50 00 57 cd | | HALT
581788 | 582844 | Rdr | 26 | | REQA
868764 | 869756 | Rdr | 52 | | WUPA
871312 | 873680 | Tag | 04 00 | |
910078 | 920606 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID
922162 | 925682 | Tag | 08 b6 dd | |
955308 | 960076 | Rdr | 50 00 57 cd | | HALT
1128092 | 1129148 | Rdr | 26 | | REQA 1415458 | 1416450 | Rdr | 52 | | WUPA 1417942 | 1420310 | Tag | 04 00 | | 1455430 | 1465958 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID 1467642 | 1471162 | Tag | 08 b6 dd | | 1511628 | 1516396 | Rdr | 50 00 57 cd | | HALT 1674412 | 1675468 | Rdr | 26 | | REQA 1961250 | 1962242 | Rdr | 52 | | WUPA 1963862 | 1966230 | Tag | 04 00 | | 2005246 | 2015774 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID 2017330 | 2020850 | Tag | 08 b6 dd | | 2086908 | 2091676 | Rdr | 50 00 57 cd | | HALT 2247388 | 2248380 | Rdr | 52 | | WUPA 2250000 | 2252368 | Tag | 04 00 | | 2288766 | 2299294 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID 2300850 | 2304370 | Tag | 08 b6 dd | | 2373760 | 2378464 | Rdr | 60 00 f5 7b | | AUTH-A(0) 2382900 | 2387636 | Tag | 01 02 03 04 | | 2388524 | 2397900 | Rdr | 5e 59 fa 21 a4 b5 66 5f | !crc| ? 5948252 | 5949244 | Rdr | 52 | | WUPA 5950864 | 5953232 | Tag | 04 00 | | 5989830 | 6000358 | Rdr | 93 70 af be e9 ef 17 aa 0d | | SELECT_UID 6002042 | 6005562 | Tag | 08 b6 dd | | 6072512 | 6077216 | Rdr | 60 00 f5 7b | | AUTH-A(0) 6081716 | 6086452 | Tag | 01 02 03 04 | | 6087340 | 6096652 | Rdr | 3b 6f 81 06 11 b0 1c 3d | !crc| ?
Looks pretty good. This is how an unsuccessful authentication looks like.
I stand corrected, I was using a faulty dump. The "hf mf sim" works perfect.
With r844 and later, I am unable to do 'hf mf sim' and related commands (snoop) on one type of readers found in 'real-world'. The yellow led blinks, but nothing happens and even with 'hf mf dbg 4', there is nothing sent back from the device.