hf list 14a

[iceman1001]

Holimans new "hf list 14a", has a minor bug where it falsely identifies rows starting with a ISO_command value when it is not a ISO_command.

See the sample below for better understanding. the "DEC(50)" is wrong.

---

2658220 | 2668684 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL 2669936 | 2673520 | Tag | 01 77 40 | | 2688636 | 2693340 | Rdr | 60 01 7c 6a | | AUTH-A 2695360 | 2700096 | Tag | c0 f5 a6 a1 | | 2700924 | 2710236 | Rdr | 9d f6 ff 85 c0 d0 dc 92 | !crc| ? 2711488 | 2716160 | Tag | 5a 67 44! ed | | 2723036 | 2727804 | Rdr | c1 32 54 08 | !crc| DEC(50) 2729104 | 2749904 | Tag | 16! 09! 3d! 5a 19! fc e8! e2! 6f 88! 66! db! 25 05! 82! a6! | | | | | 57 5e! | !crc|

[holiman]

Could you clarify a bit... Everything after AUTH-A, in this printout - is that encrypted? If it is, I don't quite know how to deal with that situation...

[iceman1001]

Well, as long as you always look on bytes[0] position regardless, then this bug will exist. It is the same if the return nonce (not encrypted) happens to start with a byte that is the same as a ISO command. (ie the row afther AUTH-A)

[holiman]

When annotating traces, I don't want to add too much (any) history-state. For each 'line', we have access to if it is command or response, so we can avoid annotating responses as if they were commands. We can also add some validity checks, a DEC has a certain length, anything starting with c1 with wrong length should not be annotated as DEC.

So we're not tied to looking only at byte[0] - we can look at whatever we want (but let's not add history-state).

[iceman1001]

How about it should detect if it is Reader response, that should take away some errors. But if the annotaion shouldn't be too big and complicated, then we might just inform that there might be errors in the desc. To keep it simple

[holiman]

Actually, there's no annotation of responses currently. If we add more protocols, we may add annotation of responses, but there was no point annotating responses right now.

Length-checks are easy, warning is fine.

[holiman]

Oh, and if piwi reads this: I'm making trace more generic, and I am wondering about void StartCountSspClk() Can that be used in any mode, or do rules and conditions apply in order to use that function for timings?

[pwpiwi]

void StartcountSspClk() has indeed some rules and conditions:

• it counts the SspClk signal. This signal is generated by the FPGA and its frequency depends on the FPGA mode (may even be zero).
• it tries to synchronize with the ssp_frame signal. Again, this signal is generated by the FPGA. It may not be present in some modes.
• the implementation uses all three ARM timers (TC0, TC1, TC2), i.e. they are not available for other purposes when the timer is running. See hitag2.c and legicrf.c - they use timers. Same would be true for StartCountUS(), but this isn't used anywhere currently.

[holiman]

Oh! It just hit me ...

• Iclass uses StartcountSspClk for tracing.
• I just changed the FPGA code for iclass tag simulation, so the ssp_clk/ssp_frame signal is slower by a factor of 8.. Which means, that the clock goes slower whenever that mode is used.

For mifare, the exact timing is important, but for the rest of the protocols, it's not quite as important - it's nice to have a close-enough clock. Do you think we could use the microsecond-clock (StartCountUS())for iso14443b and iclass (and potentially other HF-protocols), or do you see any problems with that?

[holiman]

Specifically; "uses all three ARM timers" - is there any drawback with that?

[pwpiwi]

Otherwise than that there are no more timers/counters available - no.