Proxmark developers community

Research, development and trades concerning the powerful Proxmark3 device!

You are not logged in.

#1 Re: Questions and Requests » Broken bootloader (apparently?) » 2011-02-27 21:38:14

If the bootloader flashed OK, then hold down the button when you plug in the USB cable and it should appear on the USB bus, then while holding down the button you should be able to flash the osimage and fpgaimage. No need to JTAG.

And FFS make sure you use the client utilities from the client directory compiled from the Summer 09 (or whatever version you're flashing). Always always always always use the matching utilities for the version firmware that's flashed to your card.

#2 Re: General (USB driver, Framework, Protocol) » Create FPGA image » 2010-07-21 05:51:28

You don't have to do anything else, just compile the ARM code again since the Makefile already uses the fpga.bit file from the fpga directory.

#3 Re: Questions and Requests » Was decoding wonderfully, but now isn't?? (Windows binary Winter 2010) » 2010-03-17 23:50:14

It's not possible for the tune command to capture any samples and store them in the buffer roll !!11!1
Most likely your buffer contained either junk or old sample data from a much earlier lf read command.

#4 Re: Questions and Requests » Was decoding wonderfully, but now isn't?? (Windows binary Winter 2010) » 2010-03-17 10:19:16

What you are calling a glitch is in fact a plot of the antenna voltage as the frequency is swept over a range. The peak shows you where the antenna resonates best ie optimal frequency.

#5 Re: Questions and Requests » Was decoding wonderfully, but now isn't?? (Windows binary Winter 2010) » 2010-03-17 01:34:03

Are you doing a "lf read" before the "data samples" ?!?! .... you still need to actually _read_ the tag with lf read.

#6 Re: Proxmark Board Innovations » PM3 LCD » 2010-03-14 21:56:19

The screen is worth $18 in singles however the factory only ship via DHL for $50 and only accept Western Union or Telegraphic Transfer (extra few dollars for that). The display is the KWH028Q06-F02 from Wandisplay.

I haven't even fitted the LCD to the prototype yet as I came across a weird bug in HF path of the analog section which I'm trying to get to the bottom of. Since the schematic hasn't changed since the last working prototype, it's either a PCB production issue, component failure or some weird layout issue.

Given that, and the cost of the LCD plus shipping, you'd be better off going for the v17 board if you want something quickly.

#7 Re: 125 kHz - Antenna » ripped antenna from HID reader » 2010-03-10 04:46:34

Generally removing coils from an inductor reduces its inductance making it resonate at higher frequencies. As your inductor already resonated at over 200Khz, removing coils shifts it in the wrong direction, you want to add instead.

I don't know if it's too late and if you could put those coils back on but since the software tells you the resonant frequency of the coil you could use that to calculate a new C capacitor value that would shift the resonant frequency down to 125Khz.

F=1/(2*pi*sqrt(L*C))

You know the current F (203Khz) and the C, solve for L
Once you know the L solve for C at 125Khz and find the new optimal C value....

#8 Re: 125 kHz - Antenna » Ordered 125K kits from qKits » 2010-03-10 04:44:54

I have a feeling you don't understand how antennas work, it is a tuned LC circuit where L stands for the coil and C is the capacitor already fitted to the board. Buying some random coil off the internet that does not specify the inductance of the coil but just says it's for "125Khz RFID" is no guarantee of success at all. Still at $3 it's no big loss either so worth a try smile

Let us know how it works out

Regarding your other post... I'll reply in that thread...

#9 Re: Questions and Requests » Was decoding wonderfully, but now isn't?? (Windows binary Winter 2010) » 2010-03-09 00:52:56

I have had similar issues in the past with the proxmark board, I don't think it's software related. The way I dealt with it was to remove power from the board for a few minutes then power up again. I thought it was something weird with my board but is seems you have the issue too... maybe if it happens again I will debug the hardware properly to see what the issue is.

#10 Re: 13.56 MHz - Antenna » My set of antennas » 2010-03-09 00:47:35

Yeah, Microchip application note AN710 page 12.

#11 Re: Various Tools and Utilities » New ProxSpace development environment available for download » 2010-03-08 03:00:35

Since you know about SVN, why not go to http://code.google.com/p/proxmark3/ and click on the Downloads tab? There are Summer 09 binaries, Winter 10 binaries as well as the latest updated ProxSpace environment that should compile just fine under Windows?

Also where is this expectation coming from, that the latest SVN contains stable code. You are accessing a development environment undergoing constant changes, the code may well not be stable!!!

#12 Re: Windows Client » Winter '10 - test release » 2010-03-04 04:43:05

And here is a test without recompiling or reflashing at all.

> reset init
JTAG tap: sam7x.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600000f3 pc: 0x00119d92
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x00000000
> resume

To advance past bootrom code and into appmain

> halt
target state: halted
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x600000f3 pc: 0x00119d10
> mdw 0xffffff60
0xffffff60: 00480000
> resume

Waitstate above was 0, just executed "hf 14a read"

> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x800000d7 pc: 0x00000068

Processor now at address 0x68 = data abort, reset the board next

> reset init
JTAG tap: sam7x.cpu tap/device found: 0x3f0f0f0f (mfg: 0x787, part: 0xf0f0, ver: 0x3)
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: Abort
cpsr: 0x800000d7 pc: 0x00000094
requesting target halt and executing a soft reset
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x800000d3 pc: 0x00000000
> resume

To advance bast bootrom and into appmain again

> halt          
target state: halted
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400000f3 pc: 0x001193a0
> mdw 0xffffff60
0xffffff60: 00480000 
> mww 0xffffff60 0x00480100
> mdw 0xffffff60           
0xffffff60: 00480100 
> resume
>

Just set the wait state to 1 above and verified it by reading the register back, then let the board run the code again and in the proxmark console try I reading the card again:

proxmark3> hf 14a read
#db# 5214 cc cc
#db# ready..
proxmark3> hf 14a list
proxmark3> recorded activity:
 ETU     :rssi: who bytes
---------+----+----+-----------
 +      0:    :     52
 +    156:   0: TAG 02  04
 +      0:    :     93  20
 +    292:   0: TAG 80  40! 80  00!
 +      0:    :     93  70  80  40  80  00  da  45  30
 +      0:    :     52
 +    144:   0: TAG 02  00!
 +      0:    :     93  20
 +    292:   0: TAG 80  40! 80  00!
 +      0:    :     93  70  80  40  80  00  da  45  30

This time the board runs and returns data with loads of crc errors.

#13 Re: Windows Client » Winter '10 - test release » 2010-03-04 03:48:20

All my tests and debugging is done with code compiled with -O0, I never actually managed to pinpoint the exact place where the variable is set to that incorrect value mainly because single stepping through the code never produces the error, it's only when the code is running full tilt that it errors.

On that note, I'll add the following observation. I tested the latest (disputed) bootrom code change submitted by marcan where he increases the Flash Wait State (FWS) from 0 to 1 and the crash doesn't occur when FWS=1 while it always occurs with FWS=0

Only the bootrom code was reflashed between tests, the main osimage code was not reflashed or recompiled. This excludes the compiler as a variable I think and it wouldn't be unthinkable that incorrect FWS has been a source of unexplained code instability in the past, however as marcan stated, due to the increased FWS, code runs slower and reading a HF tag now produces a lot of CRC errors and incorrect tag reads (all other things remaining equal, only changing FSW to either 0 or 1 and testing).

#14 Re: MIFARE Classic » Mifare Classic Offline Cracker » 2010-03-03 21:48:32

Have you downloaded and extracted the latest ProxSpace ? It has a whole posix environment and gcc compiler all set up for you to use under windows.

#15 Re: Windows Client » Winter '10 - test release » 2010-03-03 10:47:05

Breakpoint 1, 0x0011b740 in GetParity (pbtCmd=0x20fe90 "R", iLen=1) at iso14443a.c:70
70      dwPar |= ((OddByteParity[pbtCmd[i]]) << i);
bt
#0  0x0011b740 in GetParity (pbtCmd=0x20fe90 "R", iLen=2097508) at iso14443a.c:70
#1  0x0011bae8 in LogTraceInfo (data=0x20fe90 "R", len=2097508) at iso14443a.c:106
#2  0x0011e998 in ReaderTransmitShort (bt=0x0) at iso14443a.c:1564
#3  0x0011e998 in ReaderTransmitShort (bt=0x20fe90 "R") at iso14443a.c:1564
#4  0x0011ec20 in ReaderIso14443a (parameter=0) at iso14443a.c:1643
#5  0x00117e28 in UsbPacketReceived (packet=0x200044 "\205\003", len=64) at appmain.c:638
#6  0x00119c68 in HandleRxdData () at ../common/usb.c:435
#7  0x00119d8e in UsbPoll (blinkLeds=0) at ../common/usb.c:495
#8  0x0011833e in AppMain () at appmain.c:880
#9  0x00110052 in Vector () at start.c:32

#16 Re: Windows Client » Winter '10 - test release » 2010-03-03 03:18:05

I think I might have solved this one, seems after the board crashes and ends in Data Abort, the link register points to the address the crash was triggered, which following it back ends up being in GetParity(). Placing a breakpoint in there and running the board through that a few times there are certain times where the variable iLen=2097508 or some such large value. GetParity() is often used in conjunction with LogTrace() which also uses a memcpy(dest,src,iLen), you see where this is going, when memcpy is executed with the very large iLen it eventually runs out of RAM and tries to write out of bounds, hence the Data Abort (which incidentally corresponds to a memory access at address 0x400000).

Since I can't find any piece of code that actually sets iLen to such a large value, I followed a hunch and changed the declaration of iLen in LogTrace() from int to size_t which seems to have magically fixed the problem. If it's a typecasting issue, I believe there are many more of those hidden treasures in the code, unfortunately. I'll commit now.

#17 Re: Windows Client » Winter '10 - test release » 2010-03-02 22:32:43

I'd recommend using a USB based JTAG, such as Amontec JTAGkey tiny or similar, with openocd to drive it, setup Eclipse as the IDE and use the currently recommended devkitARM/mingw/msys compilers and you should be all set.

#18 Re: Windows Client » Winter '10 - test release » 2010-03-02 20:25:09

Oh yeah, good call, so i compiled the code with -O0 and the behaviour is same but worse, the board now hangs and resets at that command (whereas before hitting the button would make it return). If I hit the debug button while it's hung it seems to be stuck at addr 0x68 which I believe is the data abort vector.

If I single step, the behaviour is even weirder... for example I breakpoint inside ReaderIso14443a then if I step "over" the functions, it seems to reliably hang at the first call to ReaderTransmitShort(wupa), but if I step "into", I seem to be able to single step all through that function and return back to the caller... does your board run fine with this winter release when executing that command regardless if there's a tag in the field or not?

#19 Re: Windows Client » Winter '10 - test release » 2010-03-02 14:44:30

I did some more testing today and I came across something weird, with latest SVN r412. When using the command "hf 14a read" the board seems to hang in read mode and doesn't return even after waiting a minute or so. Pressing the button aborts the read and the board is accessible again but hasn't managed to read the HF card in the field, example:

proxmark3> hf 14a read

Board appears to hang, wait 30 sec, press button, board spits out some bogus read status

#db# 33678 cc cc
#db# ready..
proxmark3> hf 14a list
proxmark3> recorded activity:
 ETU     :rssi: who bytes
---------+----+----+-----------
proxmark3>

Notice that there's nothing in the list despite the 33678 indicator. After a few hours of debugging, I managed to get the board to read a HF card by changing iso14443crc.c to remove the "static" keyword in the declaration of UpdateCrc14443 then add a header definition for UpdateCrc14443 to iso14443crc.h

I know this doesn't make sense, but I can reliably get the board to misbehave if I revert to original r412 code, recompile and reflash and I can fix it by making those changes. Can anyone else verify this?

#20 Re: Windows Client » Winter '10 - test release » 2010-03-02 04:34:20

Actually that "usb_reap" error is quite a pain if it happens in the middle of flashing the bootloader as it happened to me since you then have to break out the JTAG if you have it, or scream and pull your hair if you don't smile

#21 Re: Questions and Requests » HF atenna is unusable » 2010-03-01 03:46:42

What's your HF antenna like, dimensions, turns etc?

#22 Re: 125 kHz - Antenna » 125kHz antenna construction » 2010-03-01 01:54:39

Yes I'd tend to aggree, when I was last dong some development on the code late last year the code seemed flakey, like when it would crash then simply adding a printf statement would "fix" it. I had very little confidence in it, however in hindsight I believe a lot of that was due to the elf parser issues we recently fixed (thanx marcan) so the current (northern hemisphere) winter release should be a lot more stable.

I haven't had much time to actually test the functionality in terms of reading/writing tags but if anyone else has, please pipe up and let us know in this thread, so that if enough positive testing shows it is working, we can start recommending this firmware release as "the" one to use instead of the Summer 09.

#24 Re: 125 kHz - Antenna » 125kHz antenna construction » 2010-02-27 10:28:26

Great news that you got to the bottom if it and solved your problem. Personally, I treat the firmware and client software as a matching set and I never run an earlier or unknown client with a later firmware.

#25 Re: Windows Client » Winter '10 - test release » 2010-02-26 23:20:06

Yes that's what I did to recover, flashed an old Summer 2009 bootrom via JTAG then upgraded via USB.

Board footer

Powered by FluxBB