Proxmark3 community

shinechou

Contributor

Registered: 2008-10-20

Posts: 35

anyone run "20090301_proxmark_doob.zip" smoothly?

hi all,

I'd flash my pm3 using the newest "20090301_proxmark_doob.zip" version, but when I use "hi14asnoop" to snoop the communications, I can't stop the snooping process via the push-butoon ("SW1" component) as I do with the "20081211" version. and it's very strange that the returned-parameter of "tune" is half lower than the "20081211" version (but the antenna) is the same one.

anyone can help me? thx a ton in advance!

BR.
Ryan

doob

Member

Registered: 2008-07-21

Posts: 15

Re: anyone run "20090301_proxmark_doob.zip" smoothly?

I had been tinkering with the hi14asnoop command, priamrily because I kept hitting traceLen>2000 (2000 is the defined value of TRACE_LENGTH) during ReaderISO1443a after only halfway through authentication with a DESFire tag (in fact just after cascade 2 select) - I was basically trying to increase the buffersize so that I could negotiate further with the tag.

Anyway, that is a long way of saying it shouldn't have made any difference to either the button functionality and certainly not the tune function but it is possible - I'll look at that again. Once I can get ReaderISO1443a equipped with a bigger buffer I'll post updated version - If I can see why either of the above may be happening I'll also let you know.

cheers

shinechou

Contributor

Registered: 2008-10-20

Posts: 35

Re: anyone run "20090301_proxmark_doob.zip" smoothly?

thx for ur help! just wait for ur good newes!

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: anyone run "20090301_proxmark_doob.zip" smoothly?

Hey just a quick caution message regarding 20090301_proxmark_doob.zip I was going to build on it and make some changes when I noticed that the fpgaimg.c file in that archive has a zero length and therefore the fpgaimg.s19 produced is incorrect and flashing it will erase your FPGA code. Just drop in the fpgaimg.c from the previous version and you'll be sweet.

This will be fixed when I upload a new version in the next few days if the idea I'm working on pans out otherwise you've been warned

shinechou

Contributor

Registered: 2008-10-20

Posts: 35

Re: anyone run "20090301_proxmark_doob.zip" smoothly?

Hey just a quick caution message regarding 20090301_proxmark_doob.zip

thx, so wait for ur new version is my choice!

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: anyone run "20090301_proxmark_doob.zip" smoothly?

Heh, I may have been overly optimistic regarding a new version. It was based on an idea I had very late last night while half asleep, but looking into it today in more detail it's proving to be harder than I thought.

Basically I remembered that last year someone wanted the ability to be able to drive the low frequency antenna at an arbitrary frequency from say anywhere between 100khz to 200khz. This frequency is currently determined by PCK0 which is driven by the ARM at 24Mhz and divided internally in the FPGA by 12 or 11 and then again by 16 to get one of only two final drive frequencies of 125Khz or 136Khz. Because on the ARM side you can only drive PCK0 at 24/12/6/3/etc MHZ but nothing in between, if you want fine control of the final frequency you're restricted to having to divide that clock down in the FPGA as in the current design.

I noticed that the Synchronous Serial Port can provide clock via SSP_CLK and that this clock frequency is set by the formula SSP_CLK=MCK/2*SSC_CMR where MCK is the Master Clock = 48Mhz and SSC_CMR is a 12 bit ARM register. Due to the high resolution of the divisor (12 bits) one could in principle drive SSP_CLK anywhere from 24Mhz to about 6kHz in 6Khz steps (numbers are slightly rounded but close). Due to the further neccessary division by 16 in the FPGA (and doing away with the divide by 12 or 11) one could drive the low frequency antenna from 1.5Mhz to 366Hz in 366Hz steps (in theory) but of course in practice most of this range is of no use as the physical antenna has only a fairy narrow frequency response so it wouldn't make much sense driving an antenna dimensioned (tuned) for 125Khz at 1Mhz for example. You would nevertheless have fine frequency control in the range of interest from say 100Khz to 150Khz, or of course by having an assortment of physical antennas tuned for different ranges nothing could stop you from using the entire 1.5Mhz range, really.

On closer investigation of my idea there are however two fairly big problems. First, the SSP_CLK is always an output from FPGA to the ARM (ie the FPGA drives this pin). While the ARM can also drive this pin, the FPGA needs to be reconfigured so that pin is an input. There is a danger that through bad programming, one could have the FPGA and the ARM both driving this pin and this would be "A Bad Thing" as damage could occur. Secondly and more importantly, I don't see an easy way to have that FPGA pin act as an input sometimes and an output at others (my FPGA/Verilog skills are fairly rudimentary).

After this long story, I think it would be far far easier to implement a high resolution programmable divisor in the FPGA than proceed with the above SSP_CLK idea.

d18c7db

Contributor

Registered: 2008-08-19

Posts: 292

Re: anyone run "20090301_proxmark_doob.zip" smoothly?

And my math above is way off, in fact you don't get the fine frequency control I thought as the scale is exponential so at the high frequency end you have very large steps like 1.5Mhz then 750khz, 500khz, 375Khz, etc for divisor 1, 2, 3, 4 respectively and only at the low frequency end you have the fine steps eg 366.48, 366.39, 366.3 Hz for divisor 4093, 4094, 4095. Better get some sleep now