Proxmark3 community

my_fair_cats_sick

Contributor

Registered: 2016-03-15

Posts: 81

Timing Pins?

Are there any timing pins on the proxmark such that I can use a scope with commands from the client to toggle the pins?  I'm just trying to time some of the hardnested attack and optimize any of that code if possible (the stuff that is slow or runs a lot anyway).

iceman

Administrator

Registered: 2013-04-25

Posts: 9,537

Website

Re: Timing Pins?

you could use the LED's to turn on/off to get a trigger point, when looking at different parts of execution.

cjbrigato

Contributor

Registered: 2016-09-04

Posts: 52

Re: Timing Pins?

Timing client task is easy to do as it has the whole OS syscalls happly being there.
- > If timing is to be printed for client task then it is no matter of proxmark arm code.
- > if timing is to be printed for proxmark tasks, then still a Dbgprintf or CMD_ACK hook should be enough ?

If timing is to be done by proxmark for any reason, I think one of the known fork has leftovers with Tickers being reported with above  or alike hooks, just a matter of choix for what is to be reported by adding the hook-report to relevant part of code.

Still it should be something simple to make for quick needs, or could be thought as a long-term improvement by providing an architecture reflecting such needs, which is a matter of choice.

Still I' can't really see what at this state could need anything more than a printed report for such timing needs.

Edit : Iceman1001, LEDs are not consistant trigger, as very same condition tends to have quite heavy difference for a same led into "shortest time to turn on&off" by itself, from 1 to more than 30ms, and more strange than that, more than 50ms of diffence in same conditon from led X to led Y, making the A/B/C/D leds being indicator in short loops very led-dependant.
As very good  example I got just here is :
- if Matt's build of hf standalone is to be used
- with usb_disable
-  AND your piwi's implementation for getting ChkKeys "faster" (euphemism)
Then it not only makes an incredible demonstration for education , but also that (in my device) B and D led impossible to use to report acurate report of next-sector found keys, as the leds get's to be OFF _before_ having time to get ON physically. Using A and C makes them 'slighltly being making a short red pixel" during the whole process, getting Neither really on or off with such fast loop.

Last edited by cjbrigato (2016-09-30 04:22:41)

iceman

Administrator

Registered: 2013-04-25

Posts: 9,537

Website

Re: Timing Pins?

I've been wondering sometimes over some of the LEDON_n calls in loops.  Does it really tell me anything?  More then a debug info when testing to see if some device side code is reached?

I think that @OP meant with timing pins was to be used with a logical analyser,  to trigger when it should start recording.

cjbrigato

Contributor

Registered: 2016-09-04

Posts: 52

Re: Timing Pins?

@Iceman1001 : I couldn't ask for a question that would be asked for such the answer you made

What you say on his needs definitly makes sense, and so it makes my message absolutely out of the subject.
but still, it was quite a "concise" one, so I will left it here.

LEDS are usefull only for debuging what is not at anyhow being able to be seen by the client (before usb is enabled and working, for exemple) and as "Langage" to show the status if used in standalone mode. With 4 leds, it makes quite a lot of possibility for monitoring a standalone mode, but as said, when it comes in optimization and it gets too far, then leds are of no use.
This is your fault in part, by making piwi's implementation so easy to get working, matt indecence to have prepared needed standalone infrastructure, and  last but not least, usb_disabled which is in long run an impressive changer, just as MFG_DBG_LEVEL_NONE. If you set tracelen and trace buffers to 0, destroy tracing infrastructure, because not needed at all in standalone if not to be saved on flash for further use, then you got something working too fast for even beeing real.

Try it Iceman, it's really that. I won't talk again about bigbuf, but if you get rid of these contraint and do a little work on DMA, It's something of Hollywoodian dream. Just get your local countries keys, which are always the same between 13.56Mhz supplyers in order to be less work for them to have central management and voila.
You have in hand a device which can emulate 95% of the Tag you will see in the street in near 2.5s from booting.

Edit : also get every function used to ram. Every one. Destroy any line which doesn't do a real useful thing in the process you want to be afraid of. Make it a 50kb rom. Fear of your own thing.

Last edited by cjbrigato (2016-09-30 11:21:44)