[solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

MilkThief · 2014-10-27 15:03:05

EDIT [13-04-15]: This issue was fixed and an important improvement was made.
This command was a zombie since the start of the world, and now is better than before.
Some brave guys has spent a lot of pure brain-time for fixing it.
This represent the start of a new ProxMark era...
Thank you, Iceman!
Thank you, Mashmellow!
Thank you, Piwi!
Thank you all, guys!

Hi all,
I received a EM4X reader from China and I'm playing with it. I've used an arduino one in order to convert the W26 interface to serial and I can read a lot of tags without any problem from a distance of 10-15 cm.

The second step is to try the proxmark3 emulation, so I used the "lf em4x em410xsim"
I hit the command "lf em4x em410xsim aabbccddee", the client says "sending data" and after a while "emulating".
Well, I try to put the PM3 antenna near (then attached) the reader and nothing happens.

I'm using the latest GITHUB version and I can read, write and "watch" the tags.
Could somebody check if the simulator is working or is gone between one release and another?
If somebody confirms, we can open a issue on GITHUB...
Thank you!

Last edited by MilkThief (2015-03-13 11:03:18)

iceman · 2014-10-27 16:22:33

cmdlfem4x.c - CmdEM410xSim :: writes 48 bytes to graphbuffer and manchester encodes it. Sends it to
cmdlf.c - CmdLFSim :: which sends the the bytes in graphbuffer in turns of 48 at each time to the pm3 device via CMD_DOWNLOADED_SIM_SAMPLES_125K
appmain.c - UsbPacketReceived :: CMD_DOWNLOADED_SIM_SAMPLES_125K :: copies 48bytes each time to BigBuff.
cmdlf.c - CmdLFSim :: after finished uploading bytes it issues a CMD_SIMULATE_TAG_125K with GraphTraceLen , gap == 0, 0 (No stop gap)
appmain.c - UsbPacketReceived :: CMD_SIMULATE_TAG_125K :: just calls..
lfops.c - SimulateTagLowFrequency :: which repeats over and over, sending LONG (1) or SHORT (0) signals..

So if your reader wants something else then manchester encoding, it will not work.

Question if sending 48bytes at a time is so optimal? I don't know if the SimulateTagLowFrequency is working but should. Someone who knows the low level stuff on the pm3 could tell.

MilkThief · 2014-10-27 16:43:17

I do this (under Linux):

1) I read a EM410 tag with the PM3, see a UID, i.e. 0f0c618450.
2) I read the tag with the tag reader, i see the serial UID 0f0c618450.
3) I simulate the tag with the PM3 with "lf em4x em410xsim 0f0c618450"
4) I read the PM3 antenna with the tag reader. Nothing happens.

As the reader reads the tag, it should read the simulated tag, too. Or not? What do I miss?

iceman · 2014-10-27 17:16:49

Didn't you have two pm3's ??

try read with one while the other one sim's.. Then look at the data plot graph on both..

iceman · 2014-10-27 19:45:42

I tried to sim and watch with my setup (2 pm3s) I did some changes in the code, you can see if in my fork. If you could try them out and see if it helped you.

iceman · 2014-10-27 21:40:00

And I change the datatransfer size from 48 to USB_CMD_DATA_SIZE. Much faster now, and I test with setting the clock to 64 in the Sim-calls.

iceman · 2014-10-28 10:56:44

When I tried running with two pm3's I got some results.

PM3-1 
      "lf em4x 410xsim 2233445566"

PM3-2 
     "data plot"
     "lf em4x 410xwatch"

With this it doesn't work and ususally shows a auto-detected clock on 67. Should be 64.
how ever, if I try on the pm3-2 to stop the xwatch and do a normal read.

pm3-2 
    lf read
    data samples 12000
    lf em4x 410xread 
    lf em4x 410xread 67
    lf em4x 410xread 66

With manually setting the clock to 66, it works.

I guess somehow the clock gets wrong.. I did some tests, with changing the call to manchester("64") but didnt work.
So either in the sending part or recieving has a clock problem.

iceman · 2014-10-29 00:55:58

After testing some different things, I think it is this loop, and the GPIO_SSC_CLK that sends the simulated data in a different speed (offset from 64 usually 66/67 on my pm3's) then the expected clockspeed of 64.

1) while(!(AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK)
2) while(AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK)

Can someone explain it for me?

lfops.c - SimulateTagLowFrequency


	for(;;) {
		
		while(!(AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK)) {
			 if(BUTTON_PRESS()) {
				 DbpString("Stopped at 0");
				 FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF); // field off
				 return;
			 }
			 WDT_HIT();
		}
        
		if ( buff[i] )
			OPEN_COIL();
		else
			SHORT_COIL();
       
		 while(AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK) {
			 if(BUTTON_PRESS()) {
				DbpString("Stopped at 1");
				FpgaWriteConfWord(FPGA_MAJOR_MODE_OFF); // field off
				return;
			}
			WDT_HIT();
		 }
        
		++i;
		if(i == period) {
			i = 0;
			if (gap) {
				// turn of modulation
				SHORT_COIL();
				// wait
				SpinDelay(gap);
			} 
		}
	}

MilkThief · 2014-10-29 13:14:37

iceman wrote:

When I tried running with two pm3's I got some results.
PM3-1 
      "lf em4x 410xsim 2233445566"

PM3-2 
     "data plot"
     "lf em4x 410xwatch" 
With this it doesn't work and ususally shows a auto-detected clock on 67. Should be 64.
how ever, if I try on the pm3-2 to stop the xwatch and do a normal read.
pm3-2 
    lf read
    data samples 12000
    lf em4x 410xread 
    lf em4x 410xread 67
    lf em4x 410xread 66
With manually setting the clock to 66, it works.
I guess somehow the clock gets wrong.. I did some tests, with changing the call to manchester("64") but didnt work.
So either in the sending part or recieving has a clock problem.

And this is definitely the reason why I cannot read a simulated tag with a standard reader that reads without problems the original tag...
Proxmark emulates with a wrong clock, the proxmark used as reader can "autoclock" or use different clock (and continue reading), the original reader is set to 64 and cannot read.

So the lf simulator is broken and cannot be used in a "real" scene.
Please, could anyone help Iceman in fixing this annoying bug?
Thank you all and thanks Iceman!

holiman · 2014-10-31 10:40:27

I'm looking into this. I don't quite understand why lf sim uses lf edge detect mode, instead of lf passthrough. The edge detect mode is a lot more complex, and has features which aren't being used in this case anyway. Also, I don't quite see what clock that mode uses, so I'm not 100% sure that it uses the correct frequency.

vivat · 2014-11-02 06:46:34

AFAIK in 2009 there was only lf edge detect mode; lf passthrough was implemented by roel for hitag research.
http://www.proxmark.org/forum/viewtopic.php?id=242

holiman · 2014-11-02 17:48:03

I'm investigating.. And it seems that whatever divisor I set for the FPGA clock, the actual frequency I get is ~ 170 KHz, instead of 250 KHz. It's pretty strange. The register which is read is GPIO_SSC_CLK, but I can't follow exactly what is setting that register (I am good at ARM, and I know a bit about the FPGA, but the connections between the two are a bit of a mystery to me).
The LF-part of the FPGA appears to have a general purpose clock divider, typically used to generate a 125KHz clock. In the LF-detect mode, the ARM tries to read that clock and generate antenna flippings which go straight through the FPGA to the output. So, what I've done is that instead of opening/closing coil, I light up a diode and use an oscilloscope to measure the frequency.

I don't know what causes the signal, if it is something which is unconnected and just digitizing some 170KHz noise source from somewhere....

holiman · 2014-11-02 18:06:18

Ok., it appears the signal we're catching in the ARM comes from the 'cross_lo'. The only reference I found about that is from this post http://www.proxmark.org/forum/viewtopic.php?id=304.

The AT91SAM7 SSC clock input is connected to CROSS_LO which (through a buffer) directly comes from the antenna (if the relay is switched to the peak detect path).

So, there is a signal from the antenna, but what we want is the clock (pck_divclk). How this is supposed to work I don't know.

iceman · 2014-11-02 18:20:57

well, in the thread you linked, they did talk about this sim and the fgpa code... Knowledge lost I guess, if you don't have a good connection with Adam.

holiman · 2014-11-02 18:21:33

I tried fiddling a bit with the antenna when measuring; and found that the frequency changes if I hover with the antenna over my computer. So, to conclude; the simulation frequency is not based on internal clocks, but instead the device tries to find a 125KHz clock from the reader field.

I don't know if that is good or if it would be better to use the clock from the internal oscillator. Obviously, the current method is not 100%, otherwise we wouldn't be having this thread...

iceman · 2014-11-02 18:56:39

I guess it has been working good enough and then it falled into darkness. If it used the peakdetect before all changes, and worked, it may need some thing else now.

Question is if you can change the fpga code to work with a internal clock instead?

holiman · 2014-11-02 20:01:29

iceman wrote:

Question is if you can change the fpga code to work with a internal clock instead?

The simple fix is a one-liner. lo_edge_detect.v:

assign ssp_clk = cross_lo;

Changes into

assign ssp_clk = pck_divclk;

Two problems though,
* I need to either locate my old virtual-windows-xp machine with necessary tools for FPGA-building, or setup a new one
* I'm not sure if this is a fix for the better or for the worse, and if I ruin anything else that uses the same mode. So either I'll need to check that a bit further, or I need to find *another* gpio-port to send this signal on, so the caller from the ARM-side can choose which signal to use (and we don't have to modify the FPGA if we decide to switch back to the 'reader clock' mode.

holiman · 2014-11-02 21:45:40

Actually, before I go through that trouble, I'm going to start by checking a more realistic scenario. What I did now was without a reader-field. I want to try instead and see how it behaves (the clock) against an actual reader (or another pm3). I have two pm3:s, but unfortunately only one LF-antenna. Will try to build or borrow an extra one.

Last edited by holiman (2014-11-02 21:46:11)

holiman · 2014-11-02 22:21:41

Also, I'm not quite sure about what the expected dampening/undampening frequency is - I may have been on a goose chase. As said previously, I'll need to watch a 'proper' LF exchange with a scope to check what is wrong.

EDIT: nevermind. After having stared at a problem too long I got confused. The actual dampening frequency is set by the manchester encoder, expressed in number of 'ticks' on the carrier frequency. So, for some reason, in some circumstances, the signal miss a beat (or, miss a couple of beats each 64 ticks). I suspect that your problems are basically antenna-related. So, what voltage do you get from your antennas? I do not think anything has changed because of the changes done by izsh.

Last edited by holiman (2014-11-03 09:00:20)

Omikron · 2014-11-16 23:34:15

I will say that I am having very similar behavior. I can read the tag without issue, but simulation fails to be properly detected by the reader. My antenna reads at the following:

[== Undefined ==]
proxmark3> hw tune
#db# Measuring antenna characteristics, please wait...
#db# Measuring complete, sending report back to host

# LF antenna: 23.90 V @   125.00 kHz
# LF antenna: 23.77 V @   134.00 kHz
# LF optimal: 28.06 V @   129.03 kHz
# HF antenna: 11.67 V @    13.56 MHz

Any thoughts on a fix or further troubleshooting? Was there a last known-good firmware that did work with em4x emulation?

iceman · 2014-11-17 05:49:50

Holiman,
i have like 20+ on my voltages, one standard antenna and one home-made. I can use both of them for other commands successfully, don't know why this operation should be so different och more complex.
one of the things I did look into was the man-encode rutin, I changed it to produce data for 60-62 ticks, and that is identified as 64 ticks (which is correct) but it can't decode it at all.

Omikron · 2014-11-17 19:16:10

In other news not directly related to em4x emulation but perhaps may be related in code, the latest nightly build is is producing very odd behavior for me in HID standalone mode. Cloning fails and tags fail to read into memory. Rolling back to 0.0.5 seems to restore functionality.

Any chance the Coverity fixes are "fixing" things? :-)

iceman · 2014-11-27 00:55:25

Just hooked up my rfidler, to see if I can read the sim, but when I issue my sim commands it gets stuck inside lfops.c. I tnever seem to get passed this loop.

 // Wait until SSP_CLK = low
while ( AT91C_BASE_PIOA->PIO_PDSE & GPIO_SSC_CLK){
}

iceman · 2014-12-07 17:16:00

I tried some more, in lfops.c - SimulateTagLowFrequency method.

--PM1 --
the loops works, starts sending a uid when trigger with a reader near the antenna

		// PIO_PDSR = Pin Data Status Register  
		// GPIO_SSC_CLK  = SSC Transmit Clock
		// wait ssp_clk == high
		while(!(AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK)) {  
			 if(BUTTON_PRESS()) {
				 DbpString("Stopped at 0");
				 return;
			 }
			 WDT_HIT();
		}
		
		if ( buf[i] > 0 ){
			OPEN_COIL();
		} else {
			SHORT_COIL();
		}
	   
	    // wait ssp_clk == low
		 while( (AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK) ) {  
			 if(BUTTON_PRESS()) {
				DbpString("stopped at 1");
				return;
			}
			WDT_HIT();
		}

--PM2--

The code stops inside loop 2 ( "stopped at 1") , it near exits the while loop. Very strange.

holiman · 2014-12-08 23:55:47

@iceman - what code are you using? Still on your own branch ?

iceman · 2014-12-09 00:08:01

Yeah, still holding on to my branch. I have all patches from the master repo.

Regarding the "sim", I think its interesting that it different between my two PM3's..
side question about the rfidler, how do you see the captured wave data with it?!? I'm trying to see if my rfidler can read the simulated tags, but so far no luck.

holiman · 2014-12-09 08:25:38

iceman wrote:

side question about the rfidler, how do you see the captured wave data with it?!? I'm trying to see if my rfidler can read the simulated tags, but so far no luck.

You use the client-side python program in the python directory. Example

./rfidler.py /dev/RFIDler 'set tag askraw' 'potset h 150' 'set fc 745' 'set rate 33' plot 4000

Or, to store corresponding to dump:

./rfidler.py /dev/RFIDler 'set tag askraw' 'potset h 150' 'set fc 745' 'set rate 33' store 4000 my_tag_dump

Or to view a stored dump:

./rfidler.py /dev/RFIDler load my_tag_dump_20141130-200227.xml

However, that's not quite the same as viewing the captured wave data. When you're listening 'normally', the wave data is not stored and sent to the client as in pm3, it's demodulated/decoded in real-time according to how you've configured it. The examples above captures the raw data and sends to the client, but there is no client-side functionality to do further operations on the data, such as manchester decode.

I have some loose plans on creating a framework for signal/data analysis. Sometimes I really would want to have one.

holiman · 2014-12-09 09:40:15

iceman wrote:

I tried some more, in lfops.c - SimulateTagLowFrequency method.

--PM1 --
the loops works, starts sending a uid when trigger with a reader near the antenna
		// PIO_PDSR = Pin Data Status Register  
		// GPIO_SSC_CLK  = SSC Transmit Clock
		// wait ssp_clk == high
		while(!(AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK)) {  
			 if(BUTTON_PRESS()) {
				 DbpString("Stopped at 0");
				 return;
			 }
			 WDT_HIT();
		}
		
		if ( buf[i] > 0 ){
			OPEN_COIL();
		} else {
			SHORT_COIL();
		}
	   
	    // wait ssp_clk == low
		 while( (AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK) ) {  
			 if(BUTTON_PRESS()) {
				DbpString("stopped at 1");
				return;
			}
			WDT_HIT();
		}
--PM2--
The code stops inside loop 2 ( "stopped at 1") , it near exits the while loop. Very strange.

Hm. I don't get it. You mean that you see "stopped at 1", but you haven't pressed the button? And what do you mean by "it near exits the while loop"?

iceman · 2014-12-09 18:47:10

hehe, ska du alltid dissa mina dåliga inlägg, Holiman?

Anyway, You are right. my post lacks some clarity.
Let me try to clear it.

I meant with "stopped at 1" is a way of identifing the while-loop that gets stuck. I only get the "stopped at 1" when I press the button.
"it near exists" is autocorrect.. I meant to write "It never exits that particular while-loop". The condition is never met.

Condition " (AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK) " is never fullfilled.

iceman · 2014-12-09 18:49:32

About the rfidler, it would be nice to have a thread where we can talk how to use it together with the PM3.. I like the way it demodulates/decodes/ so causally with "autotag"... The PM3 should implement that function.

MilkThief · 2014-12-10 00:37:26

Guys, thank you for trying to make lf sim working. And thank you iceman for the great contribution you are giving to pm3 and its community. I hope one day your fixes will become "official" and I'll be the first one that will start building a monument with your appearance! ;-)

I found this... Hope can help you in diffing the code and understanding where the bad bytes were added... :-)

holiman · 2014-12-10 11:41:13

Hm. I don't know it this is directly related to the last posts, but I read through izsh's blog post about LF_EDGE_DETECT again https://fail0verflow.com/blog/2014/prox … ction.html.
Specifically, look at this image:
.

The envelope looks a bit like it is being spread on the right side. It looks like the new peaks are detected and signalled pretty fast on the left side, but the new minimum on the right side is not adjusted to with equal speed. Such artefacts could presumably cause a bit of lagging in the frequency, could it perhaps be responsible for turning fc-64 clocked signals into fc-66 ? I don't know... It would be nice to get @izsh into this thread again...

iceman · 2014-12-10 12:43:29

However, you can't fold an edge "before" you get the first lower value only afterwards. So there will always be a right side spread,,,

holiman · 2014-12-10 12:51:50

I maybe wasn't clear; a spread/delay is ok, but when I said left-side and right side, I meant that the adjustment to a larger amplitude seemed to happen faster than the adjustement to a lower amplitude. I don't care about the delay that is incurred per se, but if the delay causes amplitude modulation ON-keys to be wider and OFF-keys to be smaller, that would be an issue.

But I don't know if is an issue, or if it is *the* issue. It is just a hunch, so far.

iceman · 2014-12-10 13:12:48

Aha, I understand. Yes, that seems to smell... But didn't @Izsh apply a lowpass bandfilter on the signal also? Shouldn't that smoothen out things?

holiman · 2014-12-10 13:19:42

I don't know, I actually am not quite certain that I've understood the picture fully, exactly what it does. I've asked izsh to take a look, I may be way off...

iceman · 2014-12-10 14:10:28

izsh's own comment states that the peaks are detected with an unpredicatable delay...

// NB: the min value (resp. max value) is updated only when the next high peak
// (resp. low peak) is reached/detected, since you can't know it isn't a
// local minima (resp. maxima) until then.
// This also means the peaks are detected with an unpredictable delay.
// This algorithm therefore can't be used directly for realtime peak detections,
// but it can be used as a simple envelope follower.

iceman · 2014-12-10 22:37:02

And it is strange how often you find something... Like for instance, today I found Izsh's LF minor mode: FPGA_LF_EDGE_DETECT_TOGGLE_MODE

iZsh · 2014-12-11 00:11:50

hello,
I'm not sure i understand the left/right side comment, and unfortunately my attention span is very short lately. Could you tl;dr what's going on and why you think the min/max follower is the issue?

As for the internal clock vs external for the 125khz clock, I don't have access to the code right now to check, but just be careful that the code has to work for sniffing as well.

Note that the min/max follower algorithm is used to set the thresholds for the edge detection. Its speed at detecting the new min/max is therefore usually not an issue, except maybe at the beginning of a signal since the peak thresholds would not be initialized and we could miss the first peak for instance. There are some parameters you can play with, dynamically, to adjust those thresholds (but again, I dont have the code in front of me right now, I can't therefore be specific). To debug whatever your issue is, you could do what the LF test suite is doing: save your raw signal in a file, and then simulate the verilog code with iverilog to output the debug graphs (min/max, threshold, and peaks). It will become obvious if there is an issue, and what the issue is, looking at the graph.

the FPGA_LF_EDGE_DETECT_TOGGLE_MODE is used to detect all the edges, even when going twice in a row in the same direction (as needed in my blog post, due to hw lfilter which makes the signal returns to zero after a while)

I tried to comment the code as best as i could, and the blog post is also documenting the whole thing. So hopefully that should help :-)

But please, make sure you run the test suite I created (because it had none for LF before my changes, it is therefore possible I broke something, not being able to test the whole codebase) if you change the fpga code, and/or add appropriate new test cases if you fix a bug. That's the only way we're ever going to get to a point where we know we're not breaking and/or regressing something when modifying the fpga code.
In fact, creating test suites for the arm/client side would help as well I guess. This whole project needs more proper software engineering/good practices (test suites, stop having code snippets copied/pasted everywhere instead of factoring them into useful functions etc.). Yeah, sorry for ranting ;-)

Last edited by iZsh (2014-12-11 00:33:12)

iceman · 2014-12-14 10:55:07

Looking into another part of the code which has more detailed use of the fpga (hitag-sim-code) I'm getting responses on my RFidler when I run "autotag" on it when I run my "lf em4x 410xsim" command.

However, it seems that I need some exact timings, especiall with regards to EM41xx tag response timings. not the reader, but the tag.
is a tagframe 8*64 (fc)? where every 8fc is a bit?

I feel it's close now.

iceman · 2014-12-26 13:15:32

As you all know I've been struggeling to get the "lf em4x 410xsim" (which relies on "lf sim") to work properly for awhile now.

well, my major issue is that I'm stumbleing in the dark when it comes to the fpga.. I can only look at old code in the arm to figure out whats happens. It is very timeconsuming and tedious work. My current version is able to "start simulating" when the pm3 enters a reader field. thats good I guess. but (and its a big santas butt) I don't understand how to keep track of time when to "send" or "not send" (ie power on or off) ... If you could give me some hints or help I would really appreciate it. I'm looking for a good clock from the fpga to keep count of things.

Is there someone here on the forum which has worked on the "lf" part with fpga? If you can look into my lfops.c (SimulateTagLowFrequencyA) method, https://github.com/iceman1001/proxmark3 … ops.c#L569 to help me with the timing that would be much appreciated.

marshmellow · 2015-03-03 23:06:16

it appears this has been an issue for a long time. it appears it goes back to r619 and lo_edge_detect.v replacing lo_simulate.v.

i've been testing old versions of the firmware to see if the simulation modes ever worked well, and it appears that before r619 they did. after that all the simulation methods samples per wave have been exaggerated with extra samples. this still works in some situations (right combination of reader/antenna and tag data). but it doesn't work well (or at all in many cases).

the big change at r619 was to enable two way lf communication for the hitag2. this changed the fpga and created the lf edge detect mode in place of the lo simulate mode. it appears this change may have created this issue as a biproduct. the fix? i do not know fpga programming yet... to be continued.

urkis post at http://www.proxmark.org/forum/viewtopic … 6021#p6021 appears to indicate the sim issues beginning around the above timing as well.

iceman · 2015-03-04 10:00:46

I have been following your steps on the forum regarding lf sim, as I have had an interest in it. I got stuck on the clock issue, but it all lead to the fpga code which unfortunately I don't know how to either. Holiman looked into it, but he didn't have a development environment setup for fpga either. So the ideas fell to sleep.

Great done with testing different fpga setups and finding out where it broke the sim command. Its a good start for a fix.

marshmellow · 2015-03-04 14:20:11

It just seems a bit silly that we can Sim mifare, hitag2, and now iclass, but simple lf tags we are struggling with.
I did notice a post from roel that mentioned he found a smaller focused antenna worked better for lf simulation. Around 4cm in diameter. I am going to build one and see if it makes any difference. (I've tested 3 other antennas so far and they do modify the results.)

iceman · 2015-03-04 14:46:05

I have a bunch of lf antennas, in different sizes, but havn't gotten around to start testing that suggestion.
So many funny things to figure out, so little time.

marshmellow · 2015-03-05 23:46:02

thanks to piwi and holiman we've made recent progress fixing the fpga code for lf simulating. this should be resolved shortly.

iceman · 2015-03-06 01:07:45

yeah!

piwi · 2015-03-06 09:46:44

FPGA fix pushed to github master.

iceman · 2015-03-06 09:51:48

überPiwi!, überMarshmellow!
finally this functionality is fixed!

marshmellow · 2015-03-06 19:46:50

ok sim commands set and ready for joining the trunk. (pull request made)

just a note, i did fix the lf em em410xsim command which can sim a given EM ID value. you can also sim this card after a demod (from the demod buffer) using lf simask

if you have a good strong antenna and don't want to bother demoding, you can try a lf search (or lf read - data samples) and then lf sim (attempts to simulate any wave in the graphbuffer. (PSK/NRZ probably would not work here as it relies on zero crossings)

there is also
lf simfsk for fsk simulating (either from demodbuffer or given a RAW ID value)
lf simpsk for psk simulating (same as above...)
lf simask for ask simulating (as mentioned above - can choose askraw or askman simulation type)

Proxmark3 community

Announcement

#1 2014-10-27 15:03:05

[solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#2 2014-10-27 16:22:33

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#3 2014-10-27 16:43:17

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#4 2014-10-27 17:16:49

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#5 2014-10-27 19:45:42

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#6 2014-10-27 21:40:00

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#7 2014-10-28 10:56:44

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#8 2014-10-29 00:55:58

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#9 2014-10-29 13:14:37

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#10 2014-10-31 10:40:27

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#11 2014-11-02 06:46:34

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#12 2014-11-02 17:48:03

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#13 2014-11-02 18:06:18

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#14 2014-11-02 18:20:57

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#15 2014-11-02 18:21:33

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#16 2014-11-02 18:56:39

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#17 2014-11-02 20:01:29

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#18 2014-11-02 21:45:40

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#19 2014-11-02 22:21:41

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#20 2014-11-16 23:34:15

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#21 2014-11-17 05:49:50

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#22 2014-11-17 19:16:10

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#23 2014-11-27 00:55:25

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#24 2014-12-07 17:16:00

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#25 2014-12-08 23:55:47

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#26 2014-12-09 00:08:01

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#27 2014-12-09 08:25:38

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#28 2014-12-09 09:40:15

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#29 2014-12-09 18:47:10

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#30 2014-12-09 18:49:32

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#31 2014-12-10 00:37:26

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#32 2014-12-10 11:41:13

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#33 2014-12-10 12:43:29

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#34 2014-12-10 12:51:50

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#35 2014-12-10 13:12:48

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#36 2014-12-10 13:19:42

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#37 2014-12-10 14:10:28

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#38 2014-12-10 22:37:02

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?

#39 2014-12-11 00:11:50

Re: [solved] lf em4x em410xsim NOT WORKING for me. Is it broken?