LogTrace usages

[doegox]

trafficstars

I fixed some usages where duration was wrongly used as timestamp_end. Still, some usages seem weird...

client/src/cmdtrace.c:

• ISO14443A - All times are in carrier periods (1/13.56MHz)
• Thinfilm - All times are in carrier periods (1/13.56MHz)
• iClass: ?
• LEGIC - Reader Mode: Timings are in ticks (1us == 1.5ticks), Tag mode: (1/212 kHz == 4.7us)
• ISO14443B: ?
• ISO15693: ?
• ISO7816-4 / Smartcard : ?
• Hitag1 / Hitag2 / HitagS - Timings in ETU (8us)
• FeliCa : ?

ARM:

• ISO14443A:
  • hf 14a reader: timings seem ok, but with offsets of 64 or 128 units compared to e.g. libnfc/spec.
  • Internally using (GetCountSspClk() + 8) & 0xfffffff8 then *16 or <<4 and with corrective offsets
• iClass
  • SniffIClass: GetCountSspClk()
  • doIClassSimulation: GetCountSspClk() << 4
  • ReaderTransmitIClass_ext/ReaderReceiveIClass : no duration, no start ? g_rsamples==0 unused?
• LEGIC
  • reader mode: using GET_TICKS
  • tag mode = ??
• ISO14443B
  • simulate: 0, 0
  • GetTagSamplesFor14443bDemod / CodeAndTransmit14443bAsReader / SniffIso14443b : GetCountSspClk();
• ISO15693
  • GetCountSspClk() << 4
• ISO7816-4
  • 0, 0
• Hitag1 / Hitag2 / HitagS
  • SniffHiitag2: 0, 0
  • SimulateHitag2: lf_count_edge_periods(128)/0, 0
  • ReaderHitag: idem
• FeliCa
  • TransmitFor18092_AsReader: GetCountSspClk()) & 0xfffffff8) then << 4, duration = felica_lasttime_prox2air_start + felica_lasttime_prox2air_start ??
  • WaitForFelicaReply / felicasniff: ((GetCountSspClk() & 0xfffffff8) << 4) - DELAY_AIR2ARM_AS_READER - timeout, ((GetCountSspClk() & 0xfffffff8) << 4) - DELAY_AIR2ARM_AS_READER, ??

[doegox]

iso15: seems ok but 15b seems to short to record properly durations (or duration computation is wrong)

[usb] pm3 --> hw dbg 3
#db# Debug level: 3
[usb] pm3 --> hf 15 reader
#db# [!] error, uneven octet! (extra bits!) mask 02
#db# Error in LogTrace: duration too long for 15 bits encoding: 0x002a97e0 start:0x00003680 end:0x002ace60
#db# Forcing duration = 0

[+]  UID: E0 07 C0 13 55 29 08 7E
[+] TYPE: Texas Instrument; Tag-it HF-I Standard; 8x32bit
[usb] pm3 --> trace list
[=] downloading tracelog from device
[+] Recorded activity (trace len = 36 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)

      Start |        End | Src | Data (! denotes parity error)                                           | CRC | Annotation
------------+------------+-----+-------------------------------------------------------------------------+-----+--------------------
          0 |       3408 | Rdr |26  01  00! f6! 0a!                                                      | !crc| REQA
       3424 |       3424 | Tag |00! 00! 7e! 08  29  55! 13  c0! 07  e0  35! b0                           | !crc| 

[iceman1001]

Amazing bugs, and documentation of these timings. I struggled all years in getting someone to explain it all.

1. log trace, timestamp end vs duration. Could be a semantic error

2. operation execution time.
   reader EOF - tag SOF tag EOF - reader SOF or reader SOF - tag SOF tag SOF - reader SOF

Kind of curious, 15bits = 16383. Kind of many systems will go past 16383 of (1/13.56MHz) before getting an answer. 16383 * 8us = 131064 us, 1310ms, 1.31 Sec...
Its almost like we should increase this to 31bits ? Or is there no major advantage with that?

#db# Error in LogTrace: duration too long for 15 bits encoding: 0x002a97e0 start:0x00003680 end:0x002ace60

[doegox]

duration should be the duration of the answer: tag SOF-EOF but they don't do it all, iso15693 duration is like 300ms, I don't understand it. Yes if we're sure we need more bits for duration we can increase its size (and break compatibility with recorded traces) but it's not clear to me at all is it's needed, a frame itself shouldn't be that long

[iceman1001]

or the duration from request eof to tag sof.. Depends on what you wanna measure. For the time critical parts, we need to keep it precise. Known that the answer took 56us isn't as usefull if we didn't know the whole chain.

I guess here is where the umbiquos tracelog / duration / timestamp end, started.

[doegox]

the duration from request eof to tag sof

You have already that information by comparing timestamp_start of req, duration of req, timestamp_start of resp. If duration becomes the time to respond, you're losing the information about the frame duration.

[doegox]

So right now, for e.g. iso14443A which is one of the decent traces so far, we have:

• in the trace record: for each frame: the direction, the time of start and the duration of the frame
• in the print to the user: for each frame: the direction, the time of start and the time of end of the frame

It would probably be nice also to display explicitly the time between req and resp, but that doesn't need to be added to the trace format, it's just matter of computing it from the available info.

[iceman1001]

there is an option for frame-delay, which does print the delay between EOF and SOF

[doegox]

hooooo :)

[iceman1001]

You learn new things about proxmark3 everyday

[iceman1001]

In the branch FPGA, the timings has been improved for iCLASS; ISO15, and 14b.