lf t55xx detect broken

[elafargue]

This function is currently broken in the iceman port. It seems to be working fine in firmware - the client from the official branch works great with iceman firmware for that command.

If you can point me towards what you think might be broken, I can probably help?

• by the way, let me know if these issues help -

[iceman1001]

This one is not limited to t55xx detect, but all LF. For current problems in LF, it comes down to unsigned vs signed data of the signal and a common\lfdemod.c file which needs to be executed on both device / client.

The mixup every in the LF code of when using signed or unsigned data is confusing to work with.

Since we use dual types for the signal data, there is a need to loop the data arrays always. All of these repeating loops is not needed and is making commands like lf search lf t55xx detect become more and more slow for each new demodulation/decoding of a tag.

Not even conseqent usage if the two types of signal data, like only unsigned data on device and signed data on client. As it is now, client uses both signed and unsiged in different functions.

One of the direct causes for this is based on the last statement, you find the root inside graph.c where it tries to detect ASKClock on clientside, with data copied via getfromGraphbuff() which returns a unsigned data and my changes are looking for signed data of "how & low" in signal. (short version)

solution:

• either fix all client code to use signed.. but that will fail inside common\lfdemod.c calls later on.
• either fix all client code to use unsigned data, and there is lot of places to change and test out.
• either revert changes and keep having the current mess.

I do like that you are testing out the firmware here, I need a complete rundown of what is working and not in order to fix it. Since I'm the cause of the most of the big ones doesn't mean all commands with all parameters is properly tested

[angelsl]

I ran into issues with lf viking and bisected it to 3b91a33eecebb60bc65bdd6a47c18d7bbc732c4f. I suppose this is related.

[iceman1001]

ok, i reverted that one.

[dylangerdaly]

Yeah I can't read any LF Tag, even compiling the main proxmark3 firmware and flashing, I can't read anything.

I'm trying to clone a PAC/Stanley Tag, but I can't read any LF Tag at all, surely there a fix?

[iceman1001]

That is a bit too generic to answer. Lets start with the basic questions

• hw status
• hw tune
• hw version
• which os are you using?
• which pm3 hardware are you using?

[dylangerdaly]

Yes! Of course, sorry about that

pm3 --> hw status
#db# Memory          
#db#   BIGBUF_SIZE.............40000          
#db#   Available memory........40000          
#db# Tracing          
#db#   tracing ................1          
#db#   traceLen ...............0          
#db# Currently loaded FPGA image          
#db#   mode.................... HF image built for 2s30vq100 on 2018/ 8/10 at 11:48:34          
#db# Flash memory          
#db#   init....................FAIL          
#db# Smart card module (ISO 7816)          
#db#   version.................FAILED          
#db# LF Sampling config          
#db#   [q] divisor.............95 (125 KHz)          
#db#   [b] bps.................8          
#db#   [d] decimation..........1          
#db#   [a] averaging...........Yes          
#db#   [t] trigger threshold...0          
#db# USB Speed          
#db#   Sending USB packets to client...          
#db#   Time elapsed............1500ms          
#db#   Bytes transferred.......828928          
#db#   USB Transfer Speed PM3 -> Client = 552618 Bytes/s          
#db# Various          
#db#   MF_DBGLEVEL.............1          
#db#   ToSendMax...............-1          
#db#   ToSendBit...............0          
#db#   ToSend BUFFERSIZE.......2308          
#db# Installed StandAlone Mods          
#db#    LF HID26 standalone - aka SamyRun (Samy Kamkar)   

pm3 --> hw tune

[=] measuring antenna characteristics, please wait...

....

[+] LF antenna: 37.67 V - 125.00 kHz          
[+] LF antenna: 26.91 V - 134.00 kHz          
[+] LF optimal: 40.22 V - 127.66 kHz          
[+] LF antenna is OK 

[+] HF antenna: 30.82 V - 13.56 MHz          
[+] HF antenna is OK          

[+] Displaying LF tuning graph. Divisor 89 is 134khz, 95 is 125khz.

No GUI in this build!

pm3 --> hw version

Proxmark3 RFID instrument

 [ CLIENT ]          
 client: iceman build for RDV40 with flashmem; smartcard;  

 [ ARM ]
 bootrom: iceman/master/ice_v3.1.0-1030-gd87b2084 2018-08-28 21:34:03
      os: iceman/master/ice_v3.1.0-1030-gd87b2084 2018-08-28 21:34:06

 [ FPGA ]
 LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
 HF image built for 2s30vq100 on 2018/ 8/10 at 11:48:34          

 [ Hardware ]           
  --= uC: AT91SAM7S512 Rev B          
  --= Embedded Processor: ARM7TDMI          
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 236398 bytes (45%) Free: 287890 bytes (55%)          
  --= Second Nonvolatile Program Memory Size: None          
  --= Internal SRAM Size: 64K bytes          
  --= Architecture Identifier: AT91SAM7Sxx Series          
  --= Nonvolatile Program Memory Type: Embedded Flash Memory    

• Fedora 28
• Elechouse Proxmark3 V2 (Regret this purchase after seeing the RDV40 😞)

[dylangerdaly]

I'm getting

proxmark3> lf t55xx info
proxmark3> lf t55xx info
proxmark3> lf t55xx info
proxmark3> lf t55xx info
proxmark3> lf t55xx info
proxmark3> lf t55xx info
proxmark3> lf t55xx info
proxmark3> lf t55xx info

With the tag the came in the box, labled T5577

HF works a treat, just LF dosen't work

[TomHarkness]

Strange - antenna voltage is on the low side. Can you make sure all screws are properly fastened on the antenna?

I've seen two people with the same issue. Try writing an ID to the card that came with the pm4. Use "lf hid clone 1122334455".

Then try "lf search"

and or

"lf t55 detect"

Let me know how this goes. I think sometimes the Pm4 has a hard time with blank t55 modulation settings.

Alternatively - try some more LF cards and chips...

~TH

[KazWolfe]

Probably related - I can run lf t55 detect but not info or read.

pm3 --> lf t55 detect
Chip Type  : T55x7          
Modulation : PSK1          
Bit Rate   : 2 - RF/32          
Inverted   : Yes          
Offset     : 57          
Seq. Term. : No          
Block0     : 0x60081040          

pm3 --> lf t55 info
pm3 --> lf t55 read
Reading Page 0:          
blk | hex data | binary                           | ascii          
----+----------+----------------------------------+------- 

Version information as follows:

 [ CLIENT ]          
 client: iceman build for RDV40 with flashmem; smartcard;  

 [ ARM ]
 bootrom: iceman/master/ice_v3.1.0-1054-g018ab99c 2018-09-06 14:46:40
      os: iceman/master/ice_v3.1.0-1054-g018ab99c 2018-09-06 14:46:41

 [ FPGA ]
 LF image built for 2s30vq100 on 2017/10/25 at 19:50:50
 HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23          

 [ Hardware ]           
  --= uC: AT91SAM7S512 Rev B          
  --= Embedded Processor: ARM7TDMI          
  --= Nonvolatile Program Memory Size: 512K bytes, Used: 238676 bytes (46%) Free: 285612 bytes (54%)          
  --= Second Nonvolatile Program Memory Size: None          
  --= Internal SRAM Size: 64K bytes          
  --= Architecture Identifier: AT91SAM7Sxx Series          
  --= Nonvolatile Program Memory Type: Embedded Flash Memory 

The reader does work on the master/mainline client, even without reflashing firmware, suggesting something is wrong with the client itself. This card is an IDTECK card, if that's important.

The information returned by lf t55 detect is the same as in master - on all of info, detect, and read. When running lf search, the proper data is returned by the IDTECK check, so I'm not sure why this isn't working on the T55 reader (intentional if idteck, maybe?).

[TomHarkness]

Oh interesting find that its working on mainline, hmm.

[angelsl]

This fork is pretty bleeding edge. There are so many changes and improvements compared to proxmark3.

Could you try debugging and finding exactly what is wrong? Or try finding a working revision in this fork and then bisect to find the offending change?

[dylangerdaly]

No worries, I found out the cable size of the antenna matters, LF should use the smaller 15cm cable, HF is the longer 20cm. My elechouse kit came with 2, 20cm cables...

Looks like I'm picking up a 15cm.

[iceman1001]

@dylangerdaly head over to the RRG repo and try it. It should have sorted out all issues with LF now.

[dylangerdaly]

I think the specific issue I'm having are related to the antenna cable, I couldn't get any LF data back, I think it was due to the higher voltage or something along those lines.

I'll check out that repo, cheers!

[TomHarkness]

Strange my RDV2 kit came with smaller cables. However I've used cables upwards of 30-40cm on both LF / HF without issues..

[dylangerdaly]

Does anyone know where I can pickup the new RDV4?

Maybe I was just sold a 🍋

I've picked up a MMCX Straight Male to Right Angle Female, maybe the cables are bad quality?

I'll let y'all know

[dylangerdaly]

Eeep, just flashed RRG, Proxmark3 RDV2 is now unresponsive 😟 Getting nothing on USB when plugging it in.

Do I buy a Segger J-LINK or just get the RDV4?

[dylangerdaly]

Holding the button allowed reverting back to this repo :sweat:

[iceman1001]

... your device get a new usb enumeration when you flash a new repo onto it. Usually you need to set modemmanager/udev rules, and/or keep track of which new com port that it got..

[dylangerdaly]

It literally doesn't show up at all in dmesg, the Linux Kernel dosne't see it, I think RRG Repo is only compatible with the RDV4.

[iceman1001]

your original comment, showed a broken compilation, that would explain why your device didn't work. I added some fixes for it,

[dylangerdaly]

Oh wow, pulled in the change and it's working now! Thank you very much!

pm3 --> lf t55xx detect
Chip Type  : T55x7          
Modulation : ASK          
Bit Rate   : 2 - RF/32          
Inverted   : No          
Offset     : 31          
Seq. Term. : Yes          
Block0     : 0x000880E8    

[iceman1001]

Great! Now its only a question if OP @elafargue still have issues..

[elafargue]

I will test and report asap

[elafargue]

No joy on the RRG branch - lf t55xx detect returns: [!] Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

And same on iceman branch... I am testing on a T5577 card and a T5558 tag, both return the same. Setting the config to FSK does return data but it varies with each read and is probably garbage, ASK returns nothing...

[dylangerdaly]

Mine does this as well, then I tried another t55xx keyfob and it worked.

[iceman1001]

on RRG repo you will need to use the new lf t55xx deviceconfig h command to set timings.

If your tag is configured with FSK (like hid clone) you will need some distance between tag and antenna for the detect command to work.

iceman repo has none of these fixes, so that is useless to test in the moment

[TomHarkness]

Timing can cause issues with different modulation modes as above. It's alsso worth noting that unfortunately t55xx chips are not all consistent. Some are cheaply made and the timings may need to be adjusted.

Try the RRG repo - you'll need to edit the makefile as above and if you don't see a USB device or have some issues. Press and hold the button before inserting the cable, keep it held throughout the flashing process. See below from previous issue post on the RRG repo:

I have tried it with RDV40, using a T5577 configure to EM410x , and using

lf t55xx deviceconfig a 29 b 17 c 15 d 47 e 15
lf t55xx detect

and it works. However, in order to configure the t5577, it needs to be able to detect it. Once its detected, no problem with lf em 410x_write 0F0368568B 1

Those timings seem to work well as a pretty "generic" set of timings for most cards and keyfob t55 chips.

[iceman1001]

So, this should have been fixed with latest source in RRG repo.