hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

hfmfsniff · 2019-07-18 04:45:39

I put a regular M1 S50 tag (not a magic card etc.) on wall-mounted card reader for a sniffing test. Tried various orders and positions including tag-proxmark3-reader and proxmark3-tag-reader.

The result is consistent and confusing:
"hf mf sniff" gets me nothing, "hf 14a snoop" gives only Tag, hf snoop 10000 1, the plot looks good.

Anyone has any idea?

------------------All the relevant details -------------------

Hardware bought on the biggest seller on Taobao.com. All 14a functions worked very well and I cracked and cloned 10-20 tags with ease. But sniffing/snooping never worked.

Picture of the device (PM3 Easy), showing where HF antenna installed:

hw info: (firmware updated to latest, I also tried firmware v3.0.0)

proxmark3> hw ver
Prox/RFID mark3 RFID instrument
bootrom: master/v3.1.0-96-g2de2605-suspect 2019-06-23 19:48:11
os: master/v3.1.0-96-g2de2605-suspect 2019-06-23 19:48:13
fpga_lf.bit built for 2s30vq100 on 2015/03/06 at 07:38:04
fpga_hf.bit built for 2s30vq100 on 2019/03/20 at 08:08:07
SmartCard Slot: not available

uC: AT91SAM7S256 Rev D
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes. Used: 206506 bytes (79%). Free: 55638 bytes (21%).
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

running hf mf sniff, put tag on device antenna, then put on reader (tried various positions), the LED A (green on my device) keeps lighted, no blinking, no other LED lights up during sniffing. Result is as follows (null result):

proxmark3> hf mf sniff
-------------------------------------------------------------------------
Executing command.
Press the key on the proxmark3 device to abort both proxmark3 and client.
Press the key on pc keyboard to abort the client.
-------------------------------------------------------------------------
...........#db# Canceled by button.
#db# COMMAND FINISHED.
#db# maxDataLen=2, Uart.state=0, Uart.len=0
Done.
proxmark3> hf list 14a
Recorded Activity (TraceLen = 0 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, ' denotes short bytes)            | CRC | Annotation         |  
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|

Same procedure as above, except using command hf 14a snoop. This time another LED (maybe LED C) blinked very briefly, even hard to notice. The result: TAG data only, and lots of ! parity check warning

proxmark3> hf 14a snoop
#db# cancelled by button
#db# COMMAND FINISHED
#db# maxDataLen=3, Uart.state=0, Uart.len=0
#db# traceLen=166, Uart.output[0]=00000000
proxmark3> hf list 14a
Recorded Activity (TraceLen = 166 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, ' denotes short bytes)            | CRC | Annotation         |  
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|  
          0 |       2368 | Tag | 04  00                                                          |     |
      22240 |      28064 | Tag | 22  bd  f2  e5  88                                              |     |
      59168 |      62688 | Tag | 08  b6  dd                                                      |     |
      80128 |      80768 | Tag | 04'                                                             |     |
     252880 |     255248 | Tag | 04  00                                                          |     |
     275120 |     280944 | Tag | 22  bd  f2  e5  88                                              |     |
     312048 |     315568 | Tag | 08  b6  dd                                                      |     |
     337872 |     342608 | Tag | ce  be  52  d3                                                  |     |
     354496 |     359168 | Tag | 94  94  bd  bf!                                                 |     |
     375696 |     394896 | Tag | 49! 50  e9  cd  f8! e0  e7! 26  77  38! 7f! 85  7e! 5e! 12! 5f! |     |
            |            |     | 05'                                                             | !crc|
     421328 |     440528 | Tag | 87! fb! f2! c4! 58  2b! af! f3! 6b  a5! 01  78  ac! 01  87! a2! |     |
            |            |     | 0f'                                                             | !crc|
proxmark3>

Therefore I further drill down, and move to sniff the raw signal using "hf snoop 10000 1" (some other combination of parameters such as "hf snoop 10000 0" etc, to get the best capture). Both reader and tag signals are clearly captured.

proxmark3> hf snoop 10000 1
#db# Buffer cleared (40000 bytes)
#db# Skipping first 10000 sample pairs, Skipping 1 triggers.

#db# Trigger kicked! Value: 255, Dumping Samples Hispeed now.
#db# HF Snoop end
proxmark3> data samples 40000
Reading 39999 bytes from device memory

Data fetched
Samples @ 8 bits/smpl, decimation 1:1
proxmark3> data plot

The plot clearly shows both the reader and tag. Surprisingly, the tag signal is weaker than reader.
(I speculated that it is the reader signal since I had run another "hf snoop" with reader only, without a tag. The waveform of the reader is very different from a tag)

Zoom into a request-response dialogue between the reader and the tag

Zoom in more to show wave form difference between reader and tag

I don't know what is going on... It seems the device is not able to understand the wave and unable to translate reader's waves to digits. Looks like a firmware/software problem?

Also browsed several posts related to this issue but none seems directly related to my case.

Last edited by hfmfsniff (2019-07-18 16:39:32)

piwi · 2019-07-18 10:57:38

Thanks for providing such excellent information on your issue! Unfortunately the PM3 Easy is known to have such kind of issues.

You have correctly identified reader and tag signal on the plot. It is not astonishing but normal that the tag signal is much weaker than the reader signal because the reader is really sending a signal while the tag just damps the reader's signal more or less.

The many parity errors are normal as well. You see encrypted data. The parity is calculated before encryption.

I can see three issues which are probably hardware related:

There is indeed some noise with roughly 1/4 the amplitude of the tag signal. Its frequency is around 10kHz (not 50Hz as you assumed). This can indeed be disturbing.
The signal has some bias of approx. -20. In theory it should be symmetric to the 0 line.
The reader signal is too weak. It doesn't reach the bottom of the graph (-127) in many cases.

I think that an FPGA change could provide a more robust reader signal detection. Unfortunately I don't have too much time these days. But let's see.

hfmfsniff · 2019-07-18 16:31:08

Thanks a lot for a timely and satisfying reply.

piwi wrote:

Thanks for providing such excellent information on your issue! Unfortunately the PM3 Easy is known to have such kind of issues.
You have correctly identified reader and tag signal on the plot. It is not astonishing but normal that the tag signal is much weaker than the reader signal because the reader is really sending a signal while the tag just damps the reader's signal more or less.

Just to double check, is reader's signal loss ultimately rooted in the FPGA chip hardware? So modifying the antenna (what I originally planned to hack) or hack FPGA firmware will not address this issue?

Last edited by hfmfsniff (2019-07-18 16:31:48)

hfmfsniff · 2019-07-18 16:33:26

piwi wrote:

I can see three issues which are probably hardware related:
There is indeed some noise with roughly 1/4 the amplitude of the tag signal. Its frequency is around 10kHz (not 50Hz as you assumed). This can indeed be disturbing.
The signal has some bias of approx. -20. In theory it should be symmetric to the 0 line.
The reader signal is too weak. It doesn't reach the bottom of the graph (-127) in many cases.
I think that an FPGA change could provide a more robust reader signal detection. Unfortunately I don't have too much time these days. But let's see.

It seems to me that these 3 issues are not main causes for reader signal miss? And even if I somehow resolved all 3 issues listed above, reader's signals will still be (or very likely) missed from hf 14a snoop? Changing FPGA is the ultimate solution?

Last edited by hfmfsniff (2019-07-18 17:26:09)

piwi · 2019-07-18 17:52:34

Just to double check, is reader's signal loss ultimately rooted in the FPGA chip hardware? So modifying the antenna (what I originally planned to hack) or hack FPGA firmware will not address this issue?

No, what you see in the plot is the input to the FPGA. The issue is therefore either the antenna or the RF electronics up to the A/D converter. A better antenna would probably result in stronger signal and fix the issue. Or the FPGA code could be changed to cope with weak signals.

It seems to me that these 3 issues are not main causes for reader signal miss? And even if I somehow resolved all 3 issues listed above, reader's signals will still be (or very likely) missed from hf 14a snoop? Changing FPGA is the ultimate solution?

Correct, this are observations and not root causes. A stronger antenna signal would mitigate the first and third and the overall issue. The second shouldn't have an impact.

What do you get with 'hw tune'?

hfmfsniff · 2019-07-18 18:05:33

piwi wrote:

Just to double check, is reader's signal loss ultimately rooted in the FPGA chip hardware? So modifying the antenna (what I originally planned to hack) or hack FPGA firmware will not address this issue?
No, what you see in the plot is the input to the FPGA. The issue is therefore either the antenna or the RF electronics up to the A/D converter. A better antenna would probably result in stronger signal and fix the issue. Or the FPGA code could be changed to cope with weak signals.

I guess better antenna with stronger signal strength will not fix this issue, since FPGA correctly analyzed weak tag/card signal while totally missed out the strong reader signal

piwi wrote:

What do you get with 'hw tune'?

Sorry I forgot to paste hw tune

pm3 --> hw tune
[+] HF antenna: 27.42 V - 13.56 MHz
[+] HF antenna is OK

Last edited by hfmfsniff (2019-07-19 19:53:33)

iceman · 2019-07-19 09:29:16

I notice you don't run the latest builds. Looks like you are running v31 iceman as firmware and the client is to be RRG/Iceman build.

I suggest you try offical repo and see how your snoops looks like.

Then,
you can try RRG/Iceman repo, it deals with all kinds of legacy pm3 devices now days very nicely.
And if you do have a RDV4, then you should be on it.
https://github.com/RfidResearchGroup/proxmark3

hfmfsniff · 2019-07-19 19:39:52

iceman wrote:

I suggest you try offical repo and see how your snoops looks like.

Yes, multiple versions were tried, including official (not sooo up-to-date), but reader's signals still missing in "mf 14a snoop"
the offical hardware I used:

proxmark3> hw ver
Prox/RFID mark3 RFID instrument
bootrom: master/v3.1.0-96-g2de2605-suspect 2019-06-23 19:48:11
os: master/v3.1.0-96-g2de2605-suspect 2019-06-23 19:48:13
fpga_lf.bit built for 2s30vq100 on 2015/03/06 at 07:38:04
fpga_hf.bit built for 2s30vq100 on 2019/03/20 at 08:08:07

iceman wrote:

Then,
you can try RRG/Iceman repo, it deals with all kinds of legacy pm3 devices now days very nicely.
And if you do have a RDV4, then you should be on it.
https://github.com/RfidResearchGroup/proxmark3

I will definitely give it a try

hfmfsniff · 2019-07-20 22:11:12

piwi wrote:

No, what you see in the plot is the input to the FPGA. The issue is therefore either the antenna or the RF electronics up to the A/D converter. A better antenna would probably result in stronger signal and fix the issue. Or the FPGA code could be changed to cope with weak signals.

I have bought another one from another vendor who has experience with this issue before. He will send me a new PM3 easy whose sniffing is working normal. Let us see if a new vendor can provide better parts/assembly.

Last edited by hfmfsniff (2019-07-21 14:51:50)

iceman · 2019-07-23 08:44:15

Yeah, if you bought a cheap Pm3 easy clone, then they are known to have hardware issues. RMA it until you get one that works.

Proxmark3 community

Announcement

#1 2019-07-18 04:45:39

hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#2 2019-07-18 10:57:38

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#3 2019-07-18 16:31:08

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#4 2019-07-18 16:33:26

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#5 2019-07-18 17:52:34

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#6 2019-07-18 18:05:33

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#7 2019-07-19 09:29:16

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#8 2019-07-19 19:39:52

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#9 2019-07-20 22:11:12

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

#10 2019-07-23 08:44:15

Re: hf mf sniff get NOTHING, hf 14a snoop only TAG, hf snoop look GOOD?

Board footer