NEW snoop function able to sniff LF/HF signal.

gaucho · 2014-04-02 08:24:39

I didn't found a better section to post this thread.
Enio on this thread http://www.proxmark.org/forum/viewtopic … =1599&p=22 started developing a new FPGA and ARM FW functions able to sniff data from the HF and LF path, saving data on the ARM memory or directly transferred to the pc (TBD).
HE also posted a debug full image with fixed delay and fixed sampling frequency and fixed path (HF).
This is a fundamental function that will allow easy study and exploit of new tags and new protocols.
Here Enio can upload details on its progess and share questions and answers.

Last edited by gaucho (2014-04-02 08:25:07)

gaucho · 2014-04-02 08:30:20

I'll continue from last enio post:

Enio wrote:

Im very low on time too, sadly - i hope i can get further at the weekend.
Edit: I have plans (after i finish the generic fpga passthru, allowing these hf snoops) to extend it. I want to passthru the data directly to the pc, kind of similar to the circular buffer thing in 14443a part - just with the addition to have a modulation detection included, basically to find the interesting parts. That way we can fill the BigBuffer on ARM with up to 24 Mbit/s (3MS/s) and hand the interesting data over to pc with up to 12Mbit/s (1.5MS/s) with help of usb 1.1. Depending on the size of the gaps between the transmissions, we might be able to snoop the interesting parts of a whole transmission on high detail, not just 40k samples - and if that wont work due to too long transmissions, at least with 13.56 Mhz clock on ssc (13.56 Mbit/s = 1.695 MS/s) it should work out. (We receive on ARM with ~1.7 MS/s and send them over with 1.5 MS/s, the gaps with no modulation should allow to empty the transmit buffer).
This would be really cool imho, im just not exactly sure how to put that into code.
My Idea is to reduce the sample value to be 0x01 to 0xFF (thats -127 to 127 - if adc finds a 0x00 make it 0x01). As i always send 2 samples per frame on ssc we might be able to use 0x00 to mark that a nonmodulated part starts and use the 2nd (or 3rd & 4rth) byte to send the length of the unmodulated part. For example if there is normal samples and then 300 samples not interesting, it would be [0xXX 0xXX ] (last normal sample) [0x00 0xFF](256 boring samples skipped)[0x00 0x2B](44 boring samples skipped) [0xXX 0xXX] (normal samples) - that way we can put it back together on plot to have the sample count (for timing stuff) between modulated data exact. This needs alot of logic in ARM (if theres enough power to not lose samples due to the calculations - i want to test how DMA works for that matter) or in FPGA - or in both.
Ill try to get a thread about all this created coming weekend, however until then, any ideas are welcome here too!

Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader? I do not agree with you, even if i'm not sure.
I think that we should first make stable the snoop function for HF and LF path, with a dedicated path on the client menu.
We need to make it stable on saving data on the PM3 memory. Later we can think to transfer that data "real time" to the computer with an enhancement of your function.
Also digital scopes has limited memory and they use workarounds to let the user watch what they want.
For this reason on your function we will be able to change delay from trigger, number of triggers to skip, trigger level, sampling frequency, and channel input (HF/LF)

Last edited by gaucho (2014-04-02 08:34:41)

asper · 2014-04-02 09:11:54

So this will be a kind of "oscilloscope" function, isn't it?

Enio · 2014-04-02 09:26:19

Thank you gaucho - just so you all see what its about - this is a snoop of a Mifare ATQA [0x0400, visible as 1(Start) 0010 0000 0(odd parity) 0000 0000 1(odd parity) End(1 bit no modulation)].

gaucho wrote:

Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader?

Well, this depends on the sampling speed, with 1.695MS/s (13.56 MHz on ssp clock - the main HF freq i aim for) it will be full in no time.

gaucho wrote:

I do not agree with you, even if i'm not sure.
I think that we should first make stable the snoop function for HF and LF path, with a dedicated path on the client menu.
We need to make it stable on saving data on the PM3 memory. Later we can think to transfer that data "real time" to the computer with an enhancement of your function.
Also digital scopes has limited memory and they use workarounds to let the user watch what they want.
For this reason on your function we will be able to change delay from trigger, number of triggers to skip, trigger level, sampling frequency, and channel input (HF/LF)

Yes, maybe i didnt make that clear - extending the snoop to record continous communication for a longer period is just an idea for the future. My priority is to get the generic snoop that dumps data into the buffer till its full implemented.

On that matter, on my client i already transferred the fpga passthru to its own module and i studied the code further to understand how configuration is done - its actually quite easy and theres enough room to extend configuration "codes" to support multiple options on fpga.

As a first step i will try to get all basic stuff integrated nondestructively into the current version, and add a test command-section where itll be easy to add and remove commands. I might have to disable one MAJOR_MODE" for a while though - ill explain details when im on it. However, as this passthru is capable of doing the lf read too, in the future we might get a MAJOR_MODE freed anyways.

Last edited by Enio (2014-04-02 09:29:20)

gaucho · 2014-04-02 10:29:29

Enio wrote:

gaucho wrote:
Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader?
Well, this depends on the sampling speed, with 1.695MS/s (13.56 MHz on ssp clock - the main HF freq i aim for) it will be full in no time.

You don't need that high resolution. When you use that high resolution you are observing a piece of the signal, just in case you want to observe specific modulation on a specific bit. Commonly, when you understood the kind of modulation, in order to manually decode the communication (by watching the signal on the "oscilloscope"), you just need 2 samples for each bit of communication. This means that the sampling frequency can be lowered a lot.

Last edited by gaucho (2014-04-02 10:31:15)

Enio · 2014-04-02 11:16:16

gaucho wrote:

Enio wrote:
gaucho wrote:
Are you sure that the 42000 samples are not sufficient to sample all the communication between tag and reader?
Well, this depends on the sampling speed, with 1.695MS/s (13.56 MHz on ssp clock - the main HF freq i aim for) it will be full in no time.
You don't need that high resolution. When you use that high resolution you are observing a piece of the signal, just in case you want to observe specific modulation on a specific bit. Commonly, when you understood the kind of modulation, in order to manually decode the communication (by watching the signal on the "oscilloscope"), you just need 2 samples for each bit of communication. This means that the sampling frequency can be lowered a lot.

You might not need it if you know what you are looking for. We can already put our specific wishs into fpga code and just get the result. However if i want to visually compare a long transaction - lets say some answers of a java card - and i want to find out which parts are "interesting" to measure the cpu load my request produced -it could very well be handy to capture the whole in 1go without fiddling with various triggers.

This will just be optional, and its low in priority, but why not do it if pm3 can?

gaucho · 2014-04-02 12:08:27

i agree with you. Just i don't think you can transfer data realtime on usb, since the windows/linux environment SLEEPs for 10 milliseconds whenever it wants, just do to its stuffs. On that time, i think you're not able to transfer anything, anyway i have no experience on usb transfer. May be there is a buffer on the usb driver on pc side. For sure the buffer on the arm is too much small. Let's see what we can do. Let's start from easy things as you already told.

Enio · 2014-04-02 16:38:49

gaucho wrote:

i agree with you. Just i don't think you can transfer data realtime on usb, since the windows/linux environment SLEEPs for 10 milliseconds whenever it wants, just do to its stuffs. On that time, i think you're not able to transfer anything, anyway i have no experience on usb transfer. May be there is a buffer on the usb driver on pc side. For sure the buffer on the arm is too much small. Let's see what we can do. Let's start from easy things as you already told.

These are buffered by the controller chips, no worries. A bigger problem is that these 12Mbit/s are brutto - the actual measured datarate can be 30 to 45% less. But yes, that'll come later.

Enio · 2014-04-02 17:14:42

asper wrote:

So this will be a kind of "oscilloscope" function, isn't it?

Yes, exactly. Primarily for PKD path - Maybe RAW has its use for lower frequencies, we'll see.

piwi · 2014-04-02 18:20:26

Enio wrote:

Thank you gaucho - just so you all see what its about - this is a snoop of a Mifare ATQA [0x0400, visible as 1(Start) 0010 0000 0(odd parity) 0000 0000 1(odd parity) End(1 bit no modulation)].

gaucho wrote:

@PIWI: for the signal on real mifare 1k tag, you can also watch my oscilloscope screenshot. All the screenshots shows the same result.

There is still a discrepancy I would like to understand with the tag response: gaucho's screenshots as well as Enio's previous screenshots show the subcarrier (modulation) at a higher voltage level than the unmodulated parts. It is just the other way round on Enio's last screenshot - and this is what I would expect from the ISO14443-2 description.

Any ideas?

If someone has two PM3s: how does a tag response with the latest code revision look like when you do hf mf sim (or hf 14a sim) on one of them and measure on TP1 at the other?

Enio · 2014-04-02 21:07:17

The weird thing is, the pcs->picc part seemd right on the prev. screens. As if only the answer were inverted..

gaucho · 2014-04-03 08:35:00

it is possible that different tags implement it in a different way, because it could be possible that it is not important. Anyway when i'll have the working function I'll try on my pm3 with my tag and we will see the result. Anyway, if i well understood, this doesn't change the way how you decode the data, so it seems to me a less important practical thing, even if for study purposes this is a really important matter.

piwi · 2014-04-03 10:40:13

Indeed it doesn't impact receiving tag data by the PM. You are right: the FPGA implementation just looks for modulation and ignores the DC level now. In previous revisions (pre 839) it looked at the DC level only - which would mean that it would have been important with these revisions.

However, there might be readers which are more fuzzy than the PM. When simulating a tag, we should do it correctly.

gaucho · 2014-04-03 12:35:03

piwi wrote:

However, there might be readers which are more fuzzy than the PM. When simulating a tag, we should do it correctly.

Sincerely i didn't understood how Enio made that screenshot.
It's not clear to me, how he performed the test:
Which tag did he used?
Tag was real or simulated? if simulated, how he did it?
Which reader did he used?
which command did he hitted on the PM3?
which is the sequence of operations?

Enio · 2014-04-03 12:55:42

gaucho wrote:

piwi wrote:
However, there might be readers which are more fuzzy than the PM. When simulating a tag, we should do it correctly.
Sincerely i didn't understood how Enio made that screenshot.
It's not clear to me, how he performed the test:
Which tag did he used?
Tag was real or simulated? if simulated, how he did it?
Which reader did he used?
which command did he hitted on the PM3?
which is the sequence of operations?

I snooped communication of a real Mifare classic 1k (MF1S50) and an nfc enabled phone running nxp TagInfo.
Command was MY latest version of hf 14b simlisten <samples to skip> (completely changed functionality completely -not related to 14b)

1. I put tag on pm3 antenna
2. I hit command
3. I quickly put phone close to card
4. data samples 40000
5. Hope i caught right window with the atqa

Ill soon put a version for yall to test, hopefully this weekend. I just need to separate it so its a nondestructive addition to current code, and add fpga configuration.

gaucho · 2014-04-08 14:15:51

i used nxp Taginfo on the phone of the girlfriend of my friend. it's really cool since it saves skipass data, even if by modifing it we could achieve a really interesting portable rfid hack tool.

are you proceeding? do you need support? (not from me, may be from someone stronger than me)

gaucho · 2014-04-22 11:13:03

@enio: My suggestion: do it well structured but with base functions. I mean that you could start releasing few features but working. even if you don't implement all the features.. someone could also help you to complete your work. we should never work alone.

Enio · 2014-04-22 21:04:54

Yes, i will. Problem was/is heavy workload but it should normalize soon.

I will release basic functionality that can be easily extended. One command with options, however itll be very easy to i.e. add an alias like lf read calling this function with correct options.

gaucho · 2014-04-22 22:37:23

I would like to help you, cause we have another mission after this: the bluetooth interface.

i think that we need 2 commands: "hf snoop" and "lf snoop". the only difference should be that one selects the hf path and the other selects the lf path.
On my board i will remove the mux, so i will not need to make this difference, but, for backward compatibility with the actual board, it is mandatory to leave the snoop functions inside the 2 sections HF/LF.

the syntax should be this:

hf snoop <sampling frequency in Hz> <trigger level between -128 and +128> <number of samples to skip> <number of trigger to skip>

the number of samples to aquire is not a parameter because we will use all available memory

do you agree?

i started my first test (i still need to check it in practice, as you know this is my first try on arm/client development):

inside cmdhf.c:

static command_t CommandTable[] = 
{
  {"help",      CmdHelp,          1, "This help"},
  {"14a",       CmdHF14A,         1, "{ ISO14443A RFIDs... }"},
  {"14b",       CmdHF14B,         1, "{ ISO14443B RFIDs... }"},
  {"15",        CmdHF15,          1, "{ ISO15693 RFIDs... }"},
  {"epa",       CmdHFEPA,         1, "{ German Identification Card... }"},
  {"legic",     CmdHFLegic,       0, "{ LEGIC RFIDs... }"},
  {"iclass",	CmdHFiClass,      1, "{ ICLASS RFIDs... }"},
  {"mf",      	CmdHFMF,		  1, "{ MIFARE RFIDs... }"},
  {"snoop",     CmdHFsnoop,       1, "{ snoop... }"},
  {"tune",      CmdHFTune,        0, "Continuously measure HF antenna tuning"},
  {NULL, NULL, 0, NULL}

};
int CmdHFsnoop(const char *Cmd)
{
	//do something
	//for now i could start printing out a string
	PrintAndLog("# Preparing data..");
	//get these parameters from Cmd:
	//-snoop frequency
	//-trigger level
	//-samples to skip(delay) from trigger
	//-number of trigger to skip
	//Note: the used memory is all the memory available, it is not a parameter
	int samplingFrequency, triggerLevel, samplesToSkip, triggersToSkip;
	char * pEnd;
	samplingFrequency =(int)strtol (Cmd,&pEnd,10);
	triggerLevel = (int)strtol (pEnd,&pEnd,10);
	samplesToSkip = (int)strtol (pEnd,&pEnd,10);
	triggersToSkip = (int)strtol (pEnd,NULL,10);
	
	PrintAndLog("# Sampling Frequency: %dHz",samplingFrequency);
    PrintAndLog("# Trigger Level: %d",triggerLevel);
    PrintAndLog("# Samples to Skip: %d",samplesToSkip);
    PrintAndLog("# Triggers to Skip: %d",triggersToSkip);

	UsbCommand c={CMD_HF_SNOOP};
	
    c.d.asDwords[0]=samplingFrequency;   
    c.d.asDwords[1]=triggerLevel;
    c.d.asDwords[2]=samplesToSkip ;
    c.d.asDwords[3]=triggersToSkip ;




	SendCommand(&c);

	PrintAndLog("# Snoop command sent..");
	return 0;
}

Last edited by gaucho (2014-04-25 16:23:58)

gaucho · 2014-04-23 21:34:28

REMOVED

Last edited by gaucho (2014-04-25 16:15:26)

Enio · 2014-05-04 21:55:51

Update: I finally found a bit time.

I went on replacing lf read into my hf snoop fpga code as theres no place for another FPGA_MAJOR_MODE and i dont want to touch other parts.

It was more complicated then i thought and im not happy with my fpga code - ill have to go over it again - but it works for now.

So now lf read and jf snoop is on one major mode and a newconfig register is used to swich between modes (lf powers antenna, hf not).

Todo: Clean up code, make better names for stuff and add sanity checks for command. Then integrate into git version (need read up about git).

Best

jonor · 2014-05-05 18:20:31

Very interesting your features. I hope to try it soon.
Would have been useful 5 years ago when I bought pm3 for analize a unknow tag, here a description after 4 four years of tests.

Last edited by jonor (2014-05-05 18:24:29)

Enio · 2014-05-27 23:13:07

Hey all!

Im sorry for the delays, i really didnt find the time to push this forward until now. Today i finished integrating the changes i made a while ago into a fork of the pm3 git version.

This is an unstable/testing version and the code is by no means final (which you might see at the names i used for my functions..).

The repo can be found at https://github.com/EnioArda/proxmark3

To get it working (on linux with pm3 on /dev/ttyACM0) you need to

git clone https://github.com/EnioArda/proxmark3.git <directoryname>
cd <directoryname>/client
./flasher /dev/ttyACM0 ../armsrc/obj/fullimage.elf
./proxmark3  /dev/ttyACM0

The main new function is

hf snoop

which is a bit tricky to use as its not final at all when it comes to triggers when to start recording, i had quite good results with putting a mifare card on the antenna, starting TagInfo on my NFC enabled Android device, executing

hf snoop 10000 1

and putting my phone close to the card.
You should get something like this after a few tries:

However, since in this version lf and hf snoop is put into a single fpga module, switched by configuration words, it would be really nice if you could test if lf read and functions using the old lf read fpga code still work as expected with this version.

Best, Enio

marshmellow · 2014-09-16 03:49:51

I would like to help with the lf snoop and lf read functions, but I don't have a compile environment set up. Is anyone still working on this project?

marshmellow · 2014-12-11 06:19:04

It appears this is now in the main and the lf snoop works great! Thanks.! I don't know if it is related but some are saying some lf Sim commands are functioning at incorrect rates.

Enio · 2014-12-11 08:13:19

This isnt in main, and it needs some adjustments to make it compatible with the new layout of fpga images. Ill soon go on improving this to a usable state.

marshmellow · 2014-12-11 15:22:11

strange... it appears to work in asper's compiled windows client version 0.0.5 http://www.proxmark.org/forum/viewtopic.php?id=1562&p=1. must be he has gone beyond the main trunk for that compile. I wonder if that may be where some of the comments/issues have been coming from lately. no matter I do find the function very helpful. Thanks!

iceman · 2014-12-11 21:56:46

yup, the "lf snoop" looks like it works.

lf snoop l
data sample 24000
data plot
data mandemod

However I still have issues with "lf em4x sim"...

asper · 2015-01-10 01:56:26

Enio any news about lf/hf snoop ?
Do you think it will be possible to save a 5-20 seconds trace in a file during sniffing or the USB is too slow for this ? I think 125KHz samples will consume less "space" than 13.56MHz... I would like to test some non-yet-supported 125KHz tags...

gaucho · 2015-01-15 20:47:50

Hi Enio,
i'm going to ski resort and i can try to aquire HF data in order to decode exchanged traffic. I'll share aquired data.

please, tell us if we can do it and how.

i would like to find a method to aquire data, download data on the pc, and trigger a new acquisition automatically.
I could implement a sort of script on the computer (on the proxmark GUI tool) in order to receive the data.
But it is important to log the data, not to show the graph.

holiman · 2015-01-29 01:59:11

asper wrote:

Enio any news about lf/hf snoop ?
Do you think it will be possible to save a 5-20 seconds trace in a file during sniffing or the USB is too slow for this ? I think 125KHz samples will consume less "space" than 13.56MHz... I would like to test some non-yet-supported 125KHz tags...

See http://www.proxmark.org/forum/viewtopic … 959#p13959 for this feature

holiman · 2015-02-16 17:29:19

Enio wrote:

Update: I finally found a bit time.
I went on replacing lf read into my hf snoop fpga code as theres no place for another FPGA_MAJOR_MODE and i dont want to touch other parts.
It was more complicated then i thought and im not happy with my fpga code - ill have to go over it again - but it works for now.
So now lf read and jf snoop is on one major mode and a newconfig register is used to swich between modes (lf powers antenna, hf not).

@Enio, I don't know if you noticed, but a couple of weeks after you wrote this, izsh split HF and LF into separate FPGA parts https://github.com/Proxmark/proxmark3/c … bbba80c70e.

This means, as of Jun 20 2014, these modes are defined:

fpga_hf.v:

// Major modes:

//   000 --  HF reader, transmitting to tag; modulation depth selectable
//   001 --  HF reader, receiving from tag, correlating as it goes; frequency selectable
//   010 --  HF simulated tag
//   011 --  HF ISO14443-A
//   111 --  everything off

fpga_lf.v:

// Major modes:
//   000 --  LF reader (generic)
//   001 --  LF edge detect (generic)
//   010 --  LF passthrough

Which means that in HF, there are three unused major modes, and five unused in LF.

Proxmark3 community

Announcement

#1 2014-04-02 08:24:39

NEW snoop function able to sniff LF/HF signal.

#2 2014-04-02 08:30:20

Re: NEW snoop function able to sniff LF/HF signal.

#3 2014-04-02 09:11:54

Re: NEW snoop function able to sniff LF/HF signal.

#4 2014-04-02 09:26:19

Re: NEW snoop function able to sniff LF/HF signal.

#5 2014-04-02 10:29:29

Re: NEW snoop function able to sniff LF/HF signal.

#6 2014-04-02 11:16:16

Re: NEW snoop function able to sniff LF/HF signal.

#7 2014-04-02 12:08:27

Re: NEW snoop function able to sniff LF/HF signal.

#8 2014-04-02 16:38:49

Re: NEW snoop function able to sniff LF/HF signal.

#9 2014-04-02 17:14:42

Re: NEW snoop function able to sniff LF/HF signal.

#10 2014-04-02 18:20:26

Re: NEW snoop function able to sniff LF/HF signal.

#11 2014-04-02 21:07:17

Re: NEW snoop function able to sniff LF/HF signal.

#12 2014-04-03 08:35:00

Re: NEW snoop function able to sniff LF/HF signal.

#13 2014-04-03 10:40:13

Re: NEW snoop function able to sniff LF/HF signal.

#14 2014-04-03 12:35:03

Re: NEW snoop function able to sniff LF/HF signal.

#15 2014-04-03 12:55:42

Re: NEW snoop function able to sniff LF/HF signal.

#16 2014-04-08 14:15:51

Re: NEW snoop function able to sniff LF/HF signal.

#17 2014-04-22 11:13:03

Re: NEW snoop function able to sniff LF/HF signal.

#18 2014-04-22 21:04:54

Re: NEW snoop function able to sniff LF/HF signal.

#19 2014-04-22 22:37:23

Re: NEW snoop function able to sniff LF/HF signal.

#20 2014-04-23 21:34:28

Re: NEW snoop function able to sniff LF/HF signal.

#21 2014-05-04 21:55:51

Re: NEW snoop function able to sniff LF/HF signal.

#22 2014-05-05 18:20:31

Re: NEW snoop function able to sniff LF/HF signal.

#23 2014-05-27 23:13:07

Re: NEW snoop function able to sniff LF/HF signal.

#24 2014-09-16 03:49:51

Re: NEW snoop function able to sniff LF/HF signal.

#25 2014-12-11 06:19:04

Re: NEW snoop function able to sniff LF/HF signal.

#26 2014-12-11 08:13:19

Re: NEW snoop function able to sniff LF/HF signal.

#27 2014-12-11 15:22:11

Re: NEW snoop function able to sniff LF/HF signal.

#28 2014-12-11 21:56:46

Re: NEW snoop function able to sniff LF/HF signal.

#29 2015-01-10 01:56:26

Re: NEW snoop function able to sniff LF/HF signal.

#30 2015-01-15 20:47:50

Re: NEW snoop function able to sniff LF/HF signal.

#31 2015-01-29 01:59:11

Re: NEW snoop function able to sniff LF/HF signal.

#32 2015-02-16 17:29:19

Re: NEW snoop function able to sniff LF/HF signal.

Board footer