When I go to the dir I get this:
bt4:~/proxmark3/linux/proxmark3-read-only# make
make -C bootrom all
make[1]: Entering directory `/root/proxmark3/linux/proxmark3-read-only/bootrom'
perl ../tools/mkversion.pl .. > version.c || cp ../common/default_version.c version.c
arm-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=gnu99 -I. -mthumb -mthumb-interwork -o obj/version.o version.c
make[1]: arm-eabi-gcc: Command not found
make[1]: *** [obj/version.o] Error 127
make[1]: Leaving directory `/root/proxmark3/linux/proxmark3-read-only/bootrom'
make: *** [bootrom/all] Error 2

> hi15reader
#db# 0 octets read from IDENTIFY request: 0 0 0 0 0 0
#db# 0 octets read from SELECT request: 0 0 0 0 0 0 0
#db# 807415840 octets read from XXX request: 0 0 0 0

when a card is in vicinity:
> hi15reader
#db# 12 octets read from IDENTIFY request: 0 0 55 4e
proxmark3> read failed: No error(-19)!
Trying to reopen device...

i've tested this behavior with different skidata iso15k cards.

I remember older firmwares, worked fine.

I read the contents of a legic card (has 2 segments).
I have some questions regarding there segments:
- I think 2 segments = 2 card applications, right?
- contain the segments any further structure or are they plain playload data (e.g. like file contents)
- has the content any relation to legic (or any other standard) or is the manfucturer free to write what he wants in the payload (use his own "standard")?

Thanks in advance ...

Best regards from Germany

BKone

However, I then decided to further explore the commands available in the Help system, to see what they all did.  At some point the traces STOPPED looking like the article...  So I did a device reset, and still, the same commands with the same card no longer produce any meaningful output!  I still get a significant tune voltage drop when the card is on the antenna, but the data plot output is not all nice like it used to be.  Sadly I didn't save the trace when it was nice, but it really looked exactly like this, from that tutorial:

Now here's what it looks like, it varies between these two patterns.  I've included trace files:

http://www.mediafire.com/file/yezng25tjzy/%20badtrace Trace file 1

http://www.mediafire.com/file/mit3j42ykjw/%20badtrace2 Trace file 2

Any suggestions on getting that nice mode back?
Thank you
CSM

I just uploaded a binary beta release
http://proxmark3.googlecode.com/files/p … s_beta.zip

if you guys (well, people with some knowledge, because there are no documentation yet) could give it a try, if possible from a pristine windows (so I know whether or not I forgot some DLLs), that'd be great.

to flash the proxmark with it, just use:
flasher.exe ..\arm\fullimage.elf
from the bin directory.

Let me know how it goes...

(on a pristine windows computer, you'll *first* have to install the proxmark driver I included, since it will install the libusb0 DLL. The installation procedure *will* be documented of course...)

Edit: A bootrom is included. If someone (with JTAG ^^) can test it as well...

Edit2: I have updated the link to the beta version

http://store.qkits.com/moreinfo.cfm/AN0201

http://store.qkits.com/moreinfo.cfm/AN0301

# LF antenna:  6.18 V @   125.00 kHz
# LF antenna:  6.31 V @   134.00 kHz
# LF optimal: 40.82 V @   203.39 kHz
# HF antenna:  0.10 V @    13.56 MHz
# Your HF antenna is unusable.

any ideas,  remove some coils?

Has anyone done anything with these cards?  I've seen a couple dead-end threads regarding iClass on here before, but I'm hoping maybe a few new people might have something to add or a latent interest

I have a stack of iClass P16K cards with the additional 125Khz Prox chips, so if you're in the US and want one or two through first-class mail, let me know.  If you're not in the US, maybe we can trade cards.

Here's a good overview, "Contactless Developer Guide - 5321-903_A.1.20":  http://www.hidglobal.com/documents/ok_c … _an_en.pdf

I have links to other docs, but none are as useful as that one.

I'm interest in a really really small rfid-reader - so my question is:
what's the smallest size possible if one would build an own?

i saw these: http://www.proxmark.org/forum/topic/264 … rk3-setup/
they are really nice! but what's the smallest size possible?

thanks in advance for your help!
oliver

@marauder
thanks - I edited my post :-)

At first I used a piece of wirewrap "green wire" and rolled a 5 turn aircoil 43mm diameter, then experimentally played around with adding or removing a turn while issuing the tune command to get a voltage reading. It mostly sat around 1.3V except when I let the coil turns lose and unravelled and the coil looked like a deformed spring the voltage jumped to over 10V but that was not really an option for an antenna. I then returned to the 43mm diameter coil with 4 turns and taped the coil with sellotape to keep it together then started deforming it to see what difference that made. It looks like I got lucky as squashing it to an elongated and slighlty rectangular shape moved the voltage to about 16V.

This is how I ended up with this shape. It used to be straighter but the coil has been through a lot. It's soldered direct to the test pads as somebody forgot to order the mating hirose connector when buying the parts...

The picture below is a typical setup where a RFID snapper card is sandwitched between the proxmark3 antenna and a snapper feeder (card reader, the black thing that looks like a USB flash key)

While in this close proximity, I issue the hi14asnoop command on the prox, then drive the snapper feeder with some python script for example issuing four consecutive list card commands in my python shell, like so:

Then stopping the snoop (press the prox button) and issuing the hi14alist command we can see what the prox snooped. Note that the card's UID changes every time, so it moves through UIDs 086B64BE, 08DC78E7, 08E743D1, 0841B329 and these UIDs in the snooped prox output match the returned values in the python debug output.

Finally for completeness I took Roel's idea of using a toilet paper roll, cut a slice and wound 150 turns of 0.125mm wire on it. I knew people had success in the past with around 100 turns so I started high and removed turns to get the tuning right. With 150 turns I used to get 45V on 125khz and about 20V on 136khz and as I removed turns these numbers moved closer to each other. There isn't much point going higher than 40V as the zenners will clip the voltage so I removed enough turns (lost count) until tune reported 29V at 125khz and 30V at 136khz. The picture below shows the final coil, sellotape is holding the coil to the TP roll and in the picture it's not actually soldered to the board as it's a little cumbersome to carry that around so I only fit it when needed. Currently I'm not doing any LF work so this coil isn't needed but it has successfully read some HID tags I have (in raw data mode).

If you choose to extract it to another drive/path = <new_path>, you must modify the paths in the files <new_path>\ProxSpace\pm3\cockpit\0setpath.bat and <new_path>\ProxSpace\msys\etc\fstab

I can't seem to use relative paths in 0setpath anymore due to "make -C .. -s _test" in _checkmake.bat throwing a uname not found error, if someone has any ideas, let me know.

I'm almost done with removing all windows specific code. Everything seems to compile and link just fine (I haven't test the QT part yet, but I wouldn't expect much issues with it).

I'm using mingw/msys + pthread-win32 (2.8) + readline 5.x (from gnuwin32) + libusb-win32 and a few changes in my sandbox I'd be willing to commit.

The only showstopper I'm having right now is with libusb, specifically, claiming the device.

After some google-ing, it seems we need to call usb_set_configuration under windows, whereas it's not absolutely mandatory on linux and mac os. When I'm calling usb_set_configuration(handle, 0), the return code is ok, but it still fails to claim the device afterwards. And when I'm calling usb_set_configuration(handle, 1), this function just hangs forever...

Would it be ok if I commit the code (which basically get rid of prox.c and windows specific code and includes, and use the exact same code than mac os and linux... Hence a unique code base for the client side, which is a big step forward maintainability IMHO), with the hope that someone else will help me figuring out this libusb issue? I'm running under VMWare, so I'm not quite sure whether or not it could be the issue.

It compiles and links all the tools just fine (proxmark3, snooper, cli and flasher), only the proxmark device claim is failing. Once this is fixed, hopefully everything else should be just fine since it's the exact same code than mac and linux.

What do you guys think?

i build an antenna which serves with 10,38V on 13,25MHz.
i tried software and bootrom, os and fpga-images from revisions 52, 216, 412 and the latest as of now 426.

i have cross compiled them with the elf and eabi cross-compiler respectively. (arm-eabi toolchainw as taken from http://github.com/jsnyder/arm-eabi-toolchain)

my intend is to sniff a whole mifare-classic sector read, but im failing at reading the information out of the pm3.

can someone of u help me? i can provide more information if needed.

i'm trying to compile the latest svn version. I used this manual to compile the new version: http://code.google.com/p/proxmark3/wiki … x_Platform

I'm currently running Ubunty 9.10 x64. After the make command i get the following error message:

make: arm-eabi-gcc: Command not found.

I tried to find this command but it's not on my system. What did i wrong?