Proxmark3 RDV4 unable to interpret my NExT's LF waveform

Hi! I had my NExT installed a week ago. I’ve been unable to read anything but garbage from the LF side, until today! I received my ProxLF antenna and it seems to be much better at coupling with the tag. I see a 150mV drop when running lf tune --mix, and data plot shows pretty clean waveforms.

One problem… it can’t actually parse the tag data. It looks like the PM3 is interpreting the waveform at the wrong phase. I’ve compared the output with a separate T5577 and they both look the same. However, the bit markers are shifted by half a wavelength. So on a T5577 that’s been wiped with lf t5 wipe, reading page 0 block 1 shows all 0's, and reading the same block on the implant shows all 1's. Block 0 for the implant isn’t interpreted at all by the proxmark, it just skips over it.

The current state of my implant should be that of a wiped T5577, with block 0 = 000880E0 and the rest empty. The traceability data is probably empty too since I did a test mode write earlier thinking that the tag was busted or something.

I’ve attached screenshots of the block 0 and block 1 waveform for both tags, and the lf t5 dump output.

Can any Proxmark wizards here give me some tips?

Implant data

Block 0 waveform:

Block 1 waveform:


[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  01 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  02 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  04 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  05 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  06 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  07 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  01 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  02 | FFFFFFFF | 11111111111111111111111111111111 | ....
[+]  03 | FFFFFFFF | 11111111111111111111111111111111 | ....
Non-implant T5577 data

Block 0 waveform:

Block 1 waveform:


[+] Reading Page 0:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E0 | 00000000000010001000000011100000 | ....
[+]  01 | 00000000 | 00000000000000000000000000000000 | ....
[+]  02 | 00000000 | 00000000000000000000000000000000 | ....
[+]  03 | 00000000 | 00000000000000000000000000000000 | ....
[+]  04 | 00000000 | 00000000000000000000000000000000 | ....
[+]  05 | 00000000 | 00000000000000000000000000000000 | ....
[+]  06 | 00000000 | 00000000000000000000000000000000 | ....
[+]  07 | 00000000 | 00000000000000000000000000000000 | ....
[+] Reading Page 1:
[+] blk | hex data | binary                           | ascii
[+] ----+----------+----------------------------------+-------
[+]  00 | 000880E0 | 00000000000010001000000011100000 | ....
[+]  01 | E0150A04 | 11100000000101010000101000000100 | ....
[+]  02 | 96792978 | 10010110011110010010100101111000 | .y)x
[+]  03 | 00000000 | 00000000000000000000000000000000 | ....
Proxmark startup
> pm3
[=] Session log /home/wolfizen/.proxmark3/logs/log_20211119.txt
[+] loaded from JSON file /home/wolfizen/.proxmark3/preferences.json
[=] Using UART port /dev/ttyACM0
[=] Communicating with PM3 over USB-CDC

  ██████╗ ███╗   ███╗█████╗
  ██╔══██╗████╗ ████║╚═══██╗
  ██████╔╝██╔████╔██║ ████╔╝
  ██╔═══╝ ██║╚██╔╝██║ ╚══██╗
  ██║     ██║ ╚═╝ ██║█████╔╝
  ╚═╝     ╚═╝     ╚═╝╚════╝     [ ❄️ Iceman ❄️ ]

 [ Proxmark3 RFID instrument ]

  RRG/Iceman/master/v4.14434-100-g8f32d4fc9 2021-11-19 12:36:22
  compiled with............. GCC 11.1.0
  platform.................. Linux / x86_64
  Readline support.......... present
  QT GUI support............ present
  native BT support......... present
  Python script support..... present
  Lua SWIG support.......... present
  Python SWIG support....... present

  device.................... RDV4
  firmware.................. RDV4
  external flash............ present
  smartcard reader.......... present
  FPC USART for BT add-on... absent

 [ ARM ]
  bootrom: RRG/Iceman/master/v4.14434-100-g8f32d4fc9 2021-11-19 12:36:17
       os: RRG/Iceman/master/v4.14434-100-g8f32d4fc9 2021-11-19 12:36:26
  compiled with GCC 11.2.0

 [ FPGA ]
  LF image built for 2s30vq100 on 2020-07-08 at 23:08:07
  HF image built for 2s30vq100 on 2020-07-08 at 23:08:19
  HF FeliCa image built for 2s30vq100 on 2020-07-08 at 23:08:30

 [ Hardware ]
  --= uC: AT91SAM7S512 Rev B
  --= Embedded Processor: ARM7TDMI
  --= Internal SRAM size: 64K bytes
  --= Architecture identifier: AT91SAM7Sxx Series
  --= Embedded flash memory 512K bytes ( 59% used )

[usb] pm3 -->

When did you get your rdv4? I seem to remember the early units had a batch go out without proper init and that caused LF garbage

Hmm, I received mine just last month, from Hacker Warehouse. But I don’t know when it was manufactured. Is it possible for me to get that via the PM3 client?

Yes it’s just an init command… I forget where it is but it’s on this forum somewhere…

Calling AI pilgrims… come in pilgrims!

1 Like

Maybe here? DT LF Antenna issue reading implant - #28 by amal

1 Like

Ran both the lf t5 deviceconfig ... commands and the init_rdv4 script from the thread you linked. Seems to be solid info, but unfortunately no changes with my reads. :cry:

Im going to try reading with some of the other T55XX modes available, see if I can get any differences or positive reads.

Edit: nope, none of the --r0, --r1, etc. modes get a positive read. The plot does change but not to something happy.

Are you able to read any other t5577 devices?

Also can you run a lf t5 detect

Oh yeah plenty! I can detect, read, and write tons of other T5577 devices. I have two models of tag here and they all work great. I have some waveform outputs from one of them at the top of the thread.

Doesn’t work with the implant :frowning:. It’s never succeeded with a detect. The waveforms and dumps I have so far are by setting the config from a known working tag (using lf t5 config -c ...) before reading the implant. And I chose this config (000880E0) because the other possible configs create waveforms that don’t match. I’ve tried the EM 410x config (00148040) and Indala (000820E0) as well, no dumps at all with those.

Apologies, I am late to the party, and yeah, I would have linked to the same thread


Is it possible that block 3 of page 1 was overwritten during test mode and is affecting the communication? Could someone provide me with the factory values for that block? I can try replacing that and testing again.

The specsheet says it does not transmit that block during regular-read (maybe lf t5 dump uses this?) mode so you might have to use direct-read (lf t5 read -b 3 --pg1).

More news, I’m able to write to the tag just fine, including block 0. I can see the tag changes behavior by looking at the waveform, and it is the correct output for the config. For example I tested lf em clone ... and it writes successfully. I am beginning to think it’s definitely a Proxmark problem…

Here’s a new waveform comparison for the EM-mode config (00148040). They are both the same, yet only the non-implant chip gets a successful read.

Implant (EM mode)

Non-implant T5577 (EM mode)

I’m wondering if there is a power transfer issue… USB port power settings for power saving? Different USB cable?

Well, I thought… if it’s writing I might as well try a hail-mary and go test it out for my intended purpose of cloning my apartment key. I wrote the EM ID to it, verified the output with an identical test tag, and presented my implant to the building readers. To my absolute surprise, it works!!! So… hooray‽ :tada: For everything except for being read by the Proxmark, it functions perfectly.

I’m going to keep an ex-vivo copy of my implant that I will use to manually verify my tag’s output any time I want to write to it. Kind of like how NASA has a copy of their spacecraft on Earth that they use to simulate the real one :laughing:. And maybe an update (or magic) will fix my Proxmark reads eventually…

Could very well be! It’s running off a powered USB hub, using the stock cable, but it does seem like power could be the issue. I did try other cables and ports after your suggestion, but no improvement. Good suggestion though!

And thank you @amal for your help so far :slight_smile:. I’m relieved the issue isn’t with the chip.

1 Like

Is the USB hub powered or a passive hub?

Direct powered. It’s a hub built-in to my monitor that gets power from the monitor’s power supply.

I did also try a port directly on my PC, same results.

1 Like

Hmm yeah and it kinda doesn’t make sense either with writing taking more power but succeeding while reading which takes less power is borking… odd.

1 Like