Software equivalent of hitting the button?

beben · 2015-03-10 18:07:10

Hi,

I'm currently writing an lua script, and got stuck on a little problem. At some point, my script needs to cancel the current command and switch to another, but I can't figure out how to do it. Is there a function to simulate core.ukbhit() = true?

Thanks!

holiman · 2015-03-10 23:32:50

You can't abort the device unless the device checks usb comms. So, what do you want to abort?

marshmellow · 2015-03-11 03:05:34

holiman wrote:

You can't abort the device unless the device checks usb comms. So, what do you want to abort?

How is this coded? Is there a command I can look at for an example? I'd like to add it to the lf Sim commands.

iceman · 2015-03-11 08:32:57

Holiman has a technique, where he adds an "interactive" flag to the methods inparameters, and act accordingly on the deviceside

beben · 2015-03-11 10:00:24

Hi,

Basically my script needs to simulate various tags with a precise timing, but once the first simulation runs, the subsequent requests are ignored by the device.

It goes something like:

function sequence(inter)
core.console("lf em4x em410xsim 1234567890")
local t0 = clock()
while clock() - t0 <= inter do end
core.console("lf em4x em410xsim 3214567890")
local t0 = clock()
while clock() - t0 <= inter do end
core.console("lf em4x em410xsim 4566547890")
end

I might not be going at it correctly, I'm fairly new to proxmark scripting!

Anyway thank you all for your replies.

iceman · 2015-03-11 10:52:07

Well, before scripting in lua, you need to understand the actions of the individual pm3 commands you are going to run.

beben · 2015-03-11 11:47:41

So you're saying instead of core.console, I should script myself something similar to em410xsim, so that I can control its behavior every step of the way?

Should I do that in C and recompile the client?

Is there a way to make lower level calls in lua that I'm not aware of?

Sorry for all the newbie questions!

iceman · 2015-03-11 12:35:07

You need to understand what you are doing

core.console in lua, == running commands like in the pm3 client. ... ie: "lf read" ..

So the pm3 command default behavior is what you get from the core.console command.

BUT
The communication between client and device, is done with usb commands packages, and thanks to Holiman you can send basically the same usb commands in lua. However, this means you need to know what you are doing. Like understanding how a client sends a specific command and what to expect out from it.

If you look at the client, and see the "lf em410xsim" command and understand what it sends to the device.
Then you can do the same in lua, without the need for recompiling. There is some luascripts under /scripts and /lualibs folders which gives you an insight in how this works.

Lots and lots of trail and error. (figuring out how to do it in lua, is a special treat)

Last edited by iceman (2015-03-11 12:35:33)

beben · 2015-03-11 12:43:15

Ok, I'm going to take a look at USB commands and which are used during em410xsim.

Thanks for your help!

Last edited by beben (2015-03-11 16:48:56)

marshmellow · 2015-03-11 13:26:07

iceman wrote:

Holiman has a technique, where he adds an "interactive" flag to the methods inparameters, and act accordingly on the deviceside

Do you know of a command example this is used on?

iceman · 2015-03-11 13:27:08

"hf mf sim"

marshmellow · 2015-03-11 13:33:18

Thx

marshmellow · 2015-03-11 15:09:37

it appears the interactive mode just responds after the sim is complete with an ack (so the driving software knows it is complete). i'm guessing it needs another flag/option to actually stop the sim like exitAfterNReads. but that isn't actually simulating the button press as beben is asking about.

my guess is that while the device is simulating it isn't listening to the usb anymore, so just making a new command to set a flag like BUTTON_PRESS won't work.

i do think being able to simulate a BUTTON_PRESS is advantageous for automating future cracks.

so are there any ideas to building this?

Last edited by marshmellow (2015-03-11 15:10:35)

beben · 2015-03-11 16:46:37

I am now monitoring this thread...

Last edited by beben (2015-03-11 17:33:27)

iceman · 2015-03-11 17:35:44

@beben... You find it in the source... just start digging.

@marshmellow, well, you can send a inparameter and inside the arm-code, you can decide what this flag should do. If you want the device to stop after n times of trying or when a button is pressed. There is however, no magic inparameter that just fixes the button-press.

beben · 2015-03-11 18:12:30

Okay I'll dig then, thanks again !

marshmellow · 2015-03-11 18:53:13

I'm thinking more of a WTD_HIT that tests the USB to see if a special command is sent to halt.

Last edited by marshmellow (2015-03-11 18:53:58)

iceman · 2015-03-11 19:51:34

that would require some sort on knowledge what is currently running on the arm, like threads? processes?

It would be nice to have a general solution, maybe piwi gets a challenge from it?

holiman · 2015-03-11 22:17:37

So, as has been explained...
It is not a 'scripting'-problem, you'd have the same problem writing it in C on the client side. The ARM-side has only one thread, which in this instance is bad, but in other circumstances is good, since it means the device is very deterministic about how long time an operation takes, which is nice.

The un-nice thing is that we can't send anything to the device if it isn't listening. I don't really see a 'general' solution for this, however, specific solutions can be made pretty easily. Like I did for 'hf mf sim x' , where I exit after a successfull operation (in this case, after having received an AR/NR pair).

I don't know what 'successfull' would be in your LF sim case. Could you define it a bit?
Potential ways to solve it:

1. LF sim for a certain 'time' (number of processor ticks)
2. LF sim for a certain number of 'transmissions' (number of times we've sent the contents of the buffer)
3. LF sim continuously, but check USB packets in the waiting periods.

The second options is the one I'd go for. It will be easy and is logical. As for 'interactive', the point of 'interactive' is to tell the device to send an ACK back when it is finished. In normal HF/LF sim, no ACK is sent; in console mode, you're returned immediately to the console and can type again.

The problem with that way is that if you're invoking the command via 'core.console', you want the command to halt until the command is finished. Thus, I added 'interactive'-flag which does not return the prompt until the ACK is received from the device.

marshmellow · 2015-03-11 22:25:10

That is as I expected. And while #2 is likely the way I will go, I'd actually prefer giving the control(timer?) To the device/code that calls the Sim to stop it "at will" #3, thus if you had an external application connected to a wiegand reader you would run a Sim for x seconds and see if the reader responds. if it responds stop the Sim mark the test data as success and go on with next if it times out try next data.

beben · 2015-03-12 10:24:09

Actually I might need all three, for testing purposes. I am currently experimenting with a Time-based LF authentication, where the reader expects different values from the tag depending on what time it is. I'm trying to simulate such a tag using my prox but I need the switch to be very precise, depending on the rate at which the value has to change. I will look into all of these solutions and I'll come back to give you some feedback when I can (I'll probably be busy at work for the next three days or so...).

As always, thank you!

marshmellow · 2015-03-12 13:31:32

@beben, what you describe is probably best suited for a new function in the arm programming to do the specialized Sim and timing.

holiman · 2015-03-12 15:13:29

Hm, actually, we might be able to use usb_poll() the same way we use BUTTON_PRESSED on the device.. It could check each sim loop if there is anything on usb, and in that case exit to main loop. If it works, I guess several operations could benefit from that cobstruct.

Last edited by holiman (2015-03-12 15:13:54)

iceman · 2015-03-12 15:16:05

Depends if it messes with the critical timings in some commands.
But simulating and LF could benifit from it.

holiman · 2015-03-12 17:26:15

Well, feel free to try it out https://github.com/Proxmark/proxmark3/pull/77

Aborting lf simulation without pressing any button:

proxmark3> lf simask c i
preparing to sim ask data: 0 bits          
#db# Simulating with clk: 255, invert: 0, manchester: 1, separator: 0, n: 0                 
proxmark3> hw version
#db# Stopped                 
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: master/v1.1.0-38-gd6a120a-dirty-suspect 2014-12-08 19:51:04                 
#db# os: master/v2.0.0-rc2-28-g04bc1c6-dirty-suspect 2015-03-12 15:28:04                 
#db# LF FPGA image built on 2015/03/06 at 07:38:04                 
uC: AT91SAM7S512 Rev A          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 512K bytes          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory

marshmellow · 2015-03-12 17:30:21

Thanks, i was going to look into the usb_poll(), you beat me too it . i'll run some simulations when i get a chance.

marshmellow · 2015-03-13 18:19:07

this now is in the current github code. (thanks holiman)
so now any command sent to the proxmark after any lf sim will stop the simulation and then perform that command. (or you can still press the button)

beben · 2015-03-16 11:53:54

This seems to do the trick for my problem!

Thanks a lot guys.

atwolf · 2015-06-24 05:45:21

I am looking in the iclass code. could similar changes be done using usb_poll to stop the iclass sim function?
There are several locations of if(BUTTON_PRESS()) and if(!BUTTON_PRESS())
would adding the || usb_poll() and && !usb_poll() to all of these result in the same functionality.
or would it break simulating iclass/hf cards having to check the USB poll each time?

Last edited by atwolf (2015-06-24 05:48:30)

atwolf · 2015-06-24 06:08:17

Well the changes appear to work. The implementation is similar to the one for lf.
I don't know if it breaks anything else. I did test it against a door and the full sim worked fine.

I do not know how github works on a pull for a change so if someone has a chance to look at the changes and see if they are worth pushing.
The link below is my changed version of the armsrc/iclass.c file
https://drive.google.com/file/d/0B3LeAUIHyQVRdUo3LW9VMGpzb2M/view?usp=sharing

EDIT:

I am looking at adding a stop command to the hf iclass function that just sends something over USB that triggers the stop with the previous changes to the iclass code adding usb_poll().
Is there any issues with sending the usb command CMD_UNKNOWN to trigger a stop/button press message over USB
I am looking for something simple that doesnt cause any other events and the CMD_UNKNOWN might fit the bill.

Last edited by atwolf (2015-06-24 06:40:19)

holiman · 2015-06-24 20:31:40

Usb_poll should work fine. Been meaning to add it myself, to swap csn:s.

atwolf · 2015-06-25 04:05:27

I am using it to try multiple card dumps with the full sim mode.
it appears to be working nicely.

KernelJay · 2015-07-07 06:39:59

I am hitting some problems during tag simulation stemming from this change. I am finding that SimulateTagLowFrequency() aborts before simulation because usb_poll() is returning true. If I remove the commit when that check was added (https://github.com/Proxmark/proxmark3/commit/f7048dc8a930d5d1fbbc30a3caaa030a85564fdc) simulation mode works.

I did some testing and found that in my environment, usb_poll() is returning true on the first call but when I usb_read, I get back 0 bytes.

How about:

 #define SHORT_COIL()	LOW(GPIO_SSC_DOUT)
 #define OPEN_COIL()		HIGH(GPIO_SSC_DOUT)

	i = 0;
	byte_t rx[sizeof(UsbCommand)];
	for(;;) {
		//wait until SSC_CLK goes HIGH
		while(!(AT91C_BASE_PIOA->PIO_PDSR & GPIO_SSC_CLK)) {
			if(BUTTON_PRESS() || (usb_poll() && usb_read(rx,sizeof(UsbCommand)))) {

Does anyone know why I would get an empty UsbCommand? Does it happen to anyone else? I can reproduce by just running 'lf hid sim deadbeef' or doing any basic lf simfsk commands.

marshmellow · 2015-07-07 12:57:37

How odd... I assume you aren't hitting enter too many times in the cli.. . I cannot reproduce this in my environment. OS? Bad USB port?

Will adding the usb_read affect the timing of the sim?

KernelJay · 2015-07-07 17:03:51

It is probably something bad with my laptop. (Not an extra 'enter' though!)

I was somewhat pushed into moving to a MacBook Pro last year and it has definitely had some weird USB behavior like the periodic kernel panic, bus hang, and of course there is the fact that the keyboard/mouse hang when the PM3 boots.

Anyway -- regarding the performance I think it is unlikely that this would affect timing more than just having the usb_poll() since usb_read() will only execute if usb_poll() is true in which case the current code would be aborting simulation anyway. In my environment, I just get one time with the empty UsbCommand so it might also be possible to check the USB buffer before going into the loop to completely avoid a performance hit. I have had successful tests on an HID-37 and an AWID26.

Proxmark3 community

Announcement

#1 2015-03-10 18:07:10

Software equivalent of hitting the button?

#2 2015-03-10 23:32:50

Re: Software equivalent of hitting the button?

#3 2015-03-11 03:05:34

Re: Software equivalent of hitting the button?

#4 2015-03-11 08:32:57

Re: Software equivalent of hitting the button?

#5 2015-03-11 10:00:24

Re: Software equivalent of hitting the button?

#6 2015-03-11 10:52:07

Re: Software equivalent of hitting the button?

#7 2015-03-11 11:47:41

Re: Software equivalent of hitting the button?

#8 2015-03-11 12:35:07

Re: Software equivalent of hitting the button?

#9 2015-03-11 12:43:15

Re: Software equivalent of hitting the button?

#10 2015-03-11 13:26:07

Re: Software equivalent of hitting the button?

#11 2015-03-11 13:27:08

Re: Software equivalent of hitting the button?

#12 2015-03-11 13:33:18

Re: Software equivalent of hitting the button?

#13 2015-03-11 15:09:37

Re: Software equivalent of hitting the button?

#14 2015-03-11 16:46:37

Re: Software equivalent of hitting the button?

#15 2015-03-11 17:35:44

Re: Software equivalent of hitting the button?

#16 2015-03-11 18:12:30

Re: Software equivalent of hitting the button?

#17 2015-03-11 18:53:13

Re: Software equivalent of hitting the button?

#18 2015-03-11 19:51:34

Re: Software equivalent of hitting the button?

#19 2015-03-11 22:17:37

Re: Software equivalent of hitting the button?

#20 2015-03-11 22:25:10

Re: Software equivalent of hitting the button?

#21 2015-03-12 10:24:09

Re: Software equivalent of hitting the button?

#22 2015-03-12 13:31:32

Re: Software equivalent of hitting the button?

#23 2015-03-12 15:13:29

Re: Software equivalent of hitting the button?

#24 2015-03-12 15:16:05

Re: Software equivalent of hitting the button?

#25 2015-03-12 17:26:15

Re: Software equivalent of hitting the button?

#26 2015-03-12 17:30:21

Re: Software equivalent of hitting the button?

#27 2015-03-13 18:19:07

Re: Software equivalent of hitting the button?

#28 2015-03-16 11:53:54

Re: Software equivalent of hitting the button?

#29 2015-06-24 05:45:21

Re: Software equivalent of hitting the button?

#30 2015-06-24 06:08:17

Re: Software equivalent of hitting the button?

#31 2015-06-24 20:31:40

Re: Software equivalent of hitting the button?

#32 2015-06-25 04:05:27

Re: Software equivalent of hitting the button?

#33 2015-07-07 06:39:59

Re: Software equivalent of hitting the button?

#34 2015-07-07 12:57:37

Re: Software equivalent of hitting the button?

#35 2015-07-07 17:03:51

Re: Software equivalent of hitting the button?

Board footer