LF FSK demodulation of strong / clipped signals about proxmark3 HOT 17 CLOSED

ok now I understand better the confusion, I was only testing lf t55xx detect

Original LF hiQ from the dual antenna

lf 5xx detect always work at short distance, even when the tag is programmed for FSK.

pm3 --> lf t55xx detect
Chip Type  : T55x7          
Modulation : FSK2a          
Bit Rate   : 4 - RF/50          
Inverted   : Yes           
Offset     : 32          
Seq. Term. : No          
Block0     : 0x00107060          

But reading the emulated tag fails at short distance if it's an FSK (HID, AWID) and I have indeed to keep the badge 1 or 2 cm away.

But when I'm with the tag like 2cm away, I can't lf 5xx detect anymore.

LF lowQ on the dual antenna

Reading the emulated tag (HID, AWID) works somehow at closer distance, still half of the time it fails and I've to put some distance.

But now I can lf 5xx detect at much larger distance :D like 5cm instead of 2cm.

from proxmark3.

absolutely the same problem. lf t5xx detect doesnt work with any distances. Even worse with keyfobs.
the LQ antenna solves that particular problem.

Then we still have the FSK demodulation bugs.

from proxmark3.

I found a super weird bug, not sure how to tackle it but by hacking the samples representation I managed to read T55xx HID at close distance even with the hiQ LF antenna and high saturation!

In fsk_wave_demod (common/lfdemod.c) the src/dest buffer uint8_t *dest samples are mapped to a strange representation. From low to high (from -127 to 127 in the plot), we go roughly from 132..255;0..131 so all comparisons are nonsense. Here is a little hack that illustrates the fact, attempting to remap samples to range 0..255

diff --git a/common/lfdemod.c b/common/lfdemod.c
index 1ef5915c..2c180ea5 100644
--- a/common/lfdemod.c
+++ b/common/lfdemod.c
@@ -1668,11 +1668,16 @@ size_t fsk_wave_demod(uint8_t *dest, size_t size, uint8_t fchigh, uint8_t fclow,
        size_t last_transition = 0;
        size_t idx = 1;
        size_t numBits = 0;
+       for (idx=0; idx<size;idx++) {
+           //prnt("%03u %u", dest[idx], (dest[idx] > 131)? dest[idx] - 131 : dest[idx] + (255-131));
+           dest[idx] = (dest[idx] > 131)? dest[idx] - 131 : dest[idx] + (255-131);
+       }

And I can now read the T5577 HID directly on the antenna.

This is obviously not a proper patch, moreover the mapping varies slightly as if the buffer went first to some DC adjustment function because the 131 in my hack has to be adjusted every time.

Anyway, that points a big finger on the data representation of the dest source buffer!

from proxmark3.

i think its part of the old signal files which could have large values than 256...
but the fsk bug should be right in that code the fsk_wave_demod...

I think marshmellow42 took some extra values above / below the middle in order to handle weak signals..
1 = 132-255
0 = 0-131

if its called with values from a signed graphbuffer this will be bad

from proxmark3.

or is it my zeromean call?

from proxmark3.

yes completely 😆
removing the call to it fixed the issue

from proxmark3.

I fixed zeromean to be able to work properly on a buffer of uint8_t but actually I don't think this function brings anything. It's currently used only for the three FSK tags (AWID, HID, IOProx) before fskdemod -> fsk_wave_demod and this last one compares samples with signalprop.mean so even if the mean is not "in the middle", this works fine. Shifting samples to get the mean right in the middle of the range doesn't change anything.
So, @iceman1001 shall we just remove zeromean?

from proxmark3.

No, we shall not remove zeromean yet. We shall have a talk why it exists and where I saw it to be.
Thanks for the fix for it btw! That was needed!

from proxmark3.

Yup. you got most of the ideas in the first step.

1. make sure signal data from device is adjusted.

• getfromdevice
• custom impl like t55xx, hitag?

2. make sure signal data from a trace file is adjusted.
3. make sure signal data when manipulated with data commands is adjusted.

The mean calc must be absolute value since you are comparing it with a positive number.

from proxmark3.

and yes, confusing isNoise used to set values and return values is cleared up with how it should be.

from proxmark3.

• device acquisition - centered and computed properties. (good)

• data hpf [will be used for loaded signal data from file] centered, update graphbuf, computed properties (good)

• data samples (get_samples) - computes properties (good)

• data load - centered, update graphbuf, compute properties (good)

• data norm - compute properties (good)

• data bidirect - compute properties (good)

• data zerocross - compute properties (good)

• data iir - compute properties ( good)

• lf em em4x50read - computed properties (good)

• lf em (downloadsamplesEM) - remove offset done on device (good)
  Isn't there more downloading samples in this file?

• lf t55xx (aquiredata), isn't offset down on device side ??

from proxmark3.

lf em (downloadsamplesEM) - remove offset done on device (good)
Isn't there more downloading samples in this file?

I don't see, there is one single GetFromDevice

lf t55xx (aquiredata), isn't offset down on device side ??

Right, I'll fix it

from proxmark3.

Done. #122

from proxmark3.

I think we can close this one for now. Great stuff @doegox , very much appreciated help!

from proxmark3.

Almost forgot to ask, the google doc, for your LF testing, have you tested more since all these changes?

from proxmark3.

LowQ antenna

• should give longer operation distances for t55xx commands. Also a bit narrow operations distances with all the rest LF commands.

HighQ antenna

• should give very narrow operation distances for t55xx commands. Also longer operation distances with all the rest LF commands.

from proxmark3.

Almost forgot to ask, the google doc, for your LF testing, have you tested more since all these changes?

not yet, I'll do

from proxmark3.