hf mf sim after r845

[holiman]

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.

[holiman]

I committed the first fix. I'm thinking of adding some way to lower the HF_MINFIELD threshold from the client-side.

[holiman]

@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.

[pwpiwi]

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

[holiman]

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..

[holiman]

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?

[pwpiwi]

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).

[pwpiwi]

The 02in the example 4 should most probably be 26after a timeout. The tag doesn't respond because the authentication fails (wrong key).

[pwpiwi]

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).

[holiman]

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...

[iceman1001]

@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.

[pwpiwi]

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.

[holiman]

Any pictures?

[pwpiwi]

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.

[pwpiwi]

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 ). You can see that the tag's answer to the right is inverted. Otherwise (timing) its perfect:

Although it seems to have no impact, I have committed a fix as 7554370.

Screenshot 3: hf 14a sim after the fix:

[iceman1001]

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| ?

[pwpiwi]

Looks pretty good. This is how an unsuccessful authentication looks like.

[iceman1001]

I stand corrected, I was using a faulty dump. The "hf mf sim" works perfect.