Winter '10 - test release

iZsh · 2010-02-26 16:09:02

Hello,

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

Last edited by iZsh (2010-02-27 11:10:23)

d18c7db · 2010-02-26 21:55:37

Thanks iZsh and and marcan, the latest changes are pretty awesome.

I compiled the latest r405 tree in the proxspace environment (devkitARM-r27) and it compiles fine, no warnings or errors. The main os flashes and appears to work (issued some lf and hf commands and data plot window, but no antenna and no actual tag reading)

The bootrom fails to flash, see out output below (i've deleted some progress dots ... for brevity):

$ client/flasher.exe -b bootrom/obj/bootrom.elf
Loading ELF file 'bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x0000172c->0x00001780) [RWX] @0x294
Error: PHDR file size does not equal memory size
(DATA+BSS PHDRs do not make sense on ROM platforms!)
Error while loading bootrom/obj/bootrom.elf

$ client/flasher.exe armsrc/obj/fullimage.elf
Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x0000a4bc->0x0000a4bc) [R  ] @0xb4
1: V 0x00110000 P 0x00110000 (0x000140b8->0x000140b8) [R X] @0xa570
2: V 0x00200000 P 0x001240b8 (0x00000004->0x00000004) [RW ] @0x1e628
Note: Extending previous segment from 0x140b8 to 0x140bc bytes

Waiting for Proxmark to appear on USB... Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on USB... Found.

Flashing...
Writing segments for file: armsrc/obj/fullimage.elf
 0x00102000..0x0010c4bb [0xa4bc / 165 blocks].....<deleted>.. OK
 0x00110000..0x001240bb [0x140bc / 321 blocks]....<deleted>.. OK

Resetting hardware...
All done.

Have a nice day!

Omikron · 2010-02-26 22:29:41

I'd test it, but I just packed up all of my equipment in preparation for RSA next week. I'll test it some when I get to San Francisco. :-P

iZsh · 2010-02-26 22:30:28

Can you test the binary release? Because I'd really like to do a binary release for end users : they shouldn't have to compile anything. That'd prevent "non-developers" from compiling anything (which tends to yield to frustrations on both side).

@marcan: you fail

marcan · 2010-02-26 22:44:05

d18c7db: try svn again, I forgot to make the PHDRs explicit for the bootrom. The flasher is really paranoid and I'm trying to strictly follow some ELF semantics, so it issues that error if the BSS and DATA sections are merged because theoretically that would imply allocating space in Flash for BSS (even though that is unnecessary and makes no sense - it's an artifact of the way ROM images are built with ELF).

d18c7db · 2010-02-26 23:02:22

Heh, as luck would have it something went wrong, I don't think it's a problem with the source code, just something weird with the USB bus, I'll recover with the JTAG and try again

Flashing...
Writing segments for file: bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 2 blocks].. OK
 0x00100200..0x0010192b [0x172c / 24 blocks]...........write failed: usb_reap: timeout error!
Trying to reopen device...
proxmark3> ReceiveCommandPoll returned 0
Error: Unexpected reply 0x0000 (expected ACK)
 ERROR
Error writing block 11 of 24

d18c7db · 2010-02-26 23:09:20

Yep, it's all good, flashed the bootloader a couple of times and it succeeded. Btw "hw ver" shows "#db# bootrom: Missing/Invalid version information"

$ client/flasher.exe -b bootrom/obj/bootrom.elf
Loading ELF file 'bootrom/obj/bootrom.elf'...
Loading usable ELF segments:
0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
1: V 0x00200000 P 0x00100200 (0x0000172c->0x0000172c) [R X] @0x294

Waiting for Proxmark to appear on USB... Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on USB.... Found.

Flashing...
Writing segments for file: bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 2 blocks].. OK
 0x00100200..0x0010192b [0x172c / 24 blocks]........................ OK

Resetting hardware...
All done.

Have a nice day!

$ client/proxmark3
proxmark3> hw ver
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: Missing/Invalid version information
#db# os: svn 389-suspect 2010-02-26 20:22:29
#db# FPGA image built on 2009/12/ 8 at  8: 3:54
proxmark3>

Last edited by d18c7db (2010-02-26 23:11:09)

marcan · 2010-02-26 23:12:05

Can you confirm that flashing an old bootrom and then the new bootrom still works?

d18c7db · 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.

marcan · 2010-02-27 00:29:43

The bootrom version glitch should be fixed now (had to add KEEP() to make sure the linker doesn't throw away the section)

iZsh · 2010-02-27 11:10:54

I updated the link to the beta version

proxcat · 2010-02-27 16:46:35

Just tested on a pristine windows host. Flashing worked fine however proxmark3.exe failed to start due to missing DLLs. First one encountered was mingwm10.dll but there may be more.

proxcat · 2010-02-27 16:50:48

Re: DLL woes, I think the client Makefile might need a -static thrown in.

iZsh · 2010-02-27 17:20:20

mingwm10.dll is available on the internet, could you tell me what's missing apart from this one?

as for the -static, that's not that simple unfortunately...

proxcat · 2010-02-27 17:24:54

Looks like that was the only one missing. Nice work!

iZsh · 2010-02-27 17:51:42

ok, I'll upload a new version tomorrow including the .dll.
I have to go atm

Widmo · 2010-02-27 21:05:49

How to install drivers?

Thanks

proxcat · 2010-02-27 22:25:31

On XP, connect your Proxmark then click:

Control Panel -> System -> Hardware Tab -> Device Manager

Find the Proxmark under "Human Interface Devices", it will show up as a "USB Human Interface Device".

Right click the device and select "Update Driver", specify the proxmark_driver folder and you should be all set.

Widmo · 2010-02-28 02:58:57

Ye, I think it is that way, but proxmark is not detected in this lists.

I have Windows 7 x64 and x86 and can't do it on both.

I will wait for some XP system

Thank You!

iZsh · 2010-02-28 11:56:23

I updated the zip file. it now includes the missing dll and the bootrom fix from d18.

Hopefully this archive would now work just fine

Last edited by iZsh (2010-02-28 11:56:47)

Widmo · 2010-02-28 13:59:12

Ye, I think it is that way, but proxmark is not detected in this lists.

I have Windows 7 x64 and x86 and can't do it on both.

I will wait for some XP system

Thank You!

aawnsd · 2010-03-02 00:25:40

tried http://proxmark3.googlecode.com/files/p … s_beta.zip (downloaded 03/01/2010) on a newly installed win os.

For installing USB driver I followed instructions from here: http://www.proxmark.org/forum/post/2813/#p2813

d18c7db wrote:

This is the magic: run msys\mingw\bin\inf-wizard.exe, it is a GUI app, click next, select the device with PID/VID 9AC4/4B8F, on the next screen leave everything as is (or you can put proxmark3 in the manufacturer name), click next and save the files back in msys\mingw\bin
Next go into the Windows Device Manager (right click My Computer, select Manage) and expand the Human Interface Devices tree, double click each device in turn and select the Details tab until you find the one with PID/VID 9AC4/4B8F, exit that dialog and right click that last device, select Update Driver, select "No" to windows connecting to Windows Update, select advanced on the next screen, select "Don't search, I will choose...", select "Have Disk", then browse to msys\mingw\bin and let it install the driver.

I got all the tools flasher, proxmark3, cli up and running...

I still get one error during "hw reset" or during flashing. I tried to build latest trunk (412), but issue stays. Here is what I get:

proxmark3> hw reset
write failed: usb_reap: reaping request failed, win error: one device connected to the system is not running...
!
Trying to reopen device...
read failed: usb_reap: reaping request failed, win error: one device connected to the system is not running...
(-5)!
Trying to reopen device...
proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: svn 412-suspect 2010-03-01 21:18:48
#db# os: svn 412-suspect 2010-03-01 21:18:10
#db# FPGA image built on 2009/12/ 8 at  8: 3:54

Anybody can help on the meaning and on how to solve it?

iZsh · 2010-03-02 02:04:54

probably nothing to worry about, looks like a timing issue since it seems to work after the 2nd attempt (when it tries to reopen the device it just sleeps for a while and try again, so it really depends how long it takes for your OS to reacquire the device). It seems to work just fine in your log, except of course the unnecessary error messages until it actually works.

BTW, the driver was included in the zip file (with the .inf file already generated), so you only had to tell the device manager to use it (but that's probably what you actually did? I'm not sure since you quoted the generation part as well).

d18c7db · 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

proxcat · 2010-03-02 12:38:08

When running in an XP VM, the client gets to fire off about one or two commands before the client goes loopy. By loopy, I mean continuous reap errors or crashing. I plan on doing some more testing running native today.

One thing I've noticed is that the voltages reported by 'hw tune' differ from previous releases.

Is there a reason why we aren't tracking bugs with googlecode?

d18c7db · 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?

iZsh · 2010-03-02 19:15:49

it might be an inlining/optimisation "issue" then (but more probably a bug which is exhibited because of it). You could check the assembly output to compare the ComputeCrc14443() assembly output.

d18c7db · 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?

aawnsd · 2010-03-02 21:29:42

iZsh wrote:

BTW, the driver was included in the zip file (with the .inf file already generated), so you only had to tell the device manager to use it (but that's probably what you actually did? I'm not sure since you quoted the generation part as well).

I used both (first yours, then I built it from trunk). Both gave same error.

Hmmm another strange thing is the following. PM3 was initially flashed with svn216. I used old prox.exe to flash, unsing s19 files. At a certain point board was not recognized and needed to start it with pushed button (then it was recognized). This what I described disappeard (reboot help!!?? ).

I made some own changes to source, recompile and reflash (svn412, my branch) now I get no error. Cooooooollll

Last edited by aawnsd (2010-03-02 21:30:04)

aawnsd · 2010-03-02 21:32:45

d18c7db wrote:

...After a few hours of debugging...

I was almost ready to build a wiggler jtag (openocd: is that enough flash via jtag?) today after the strange usb error yesterday... but i did not need it... kwel...

BTW, what is the needed hw and sw toolchain to debug the application?

d18c7db · 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.

d18c7db · 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.

iZsh · 2010-03-03 08:14:41

For the same reason that changing the -O option was randomly changing the behavior, the fact that it "magically" fixes the problem isn't a proof that it's actually fixed. The change you committed might be the correct one, or might be not. it really depends what exactly is happening, that's why the investigation shouldn't stop here IMHO. Otherwise, it might pop up back again later on and even be harder to debug.

I'd refer to the last rule of David J Agans's book "debugging" : "if you didn't fix it, it ain't fix it"

I don't have jtag, so I can't take a look at it. Can you dump the call stack when you have such a large value ?

d18c7db · 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

iZsh · 2010-03-03 13:51:11

if you can reproduce the problem with -O0 (to prevent from inlining for example), that would be even better

Edit: BTW, I'm still not sure I'm following your analysis.
You said the crash was happening in GetParity, but then you said it was coming from the memcpy in TraceLog?
Where is it crashing exactly? Is it in the loop in GetParity() or during the mempcy() call in TraceLog?

To further debug I would print the memory address of the different iLen function parameters (I'm suspecting some kind of stack overflow), I would also set some conditional breakpoint on iLen >= some_large_value.

Last edited by iZsh (2010-03-03 14:14:16)

d18c7db · 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).

d18c7db · 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.

Ground Loop · 2010-03-07 20:55:57

I tried to use the binary beta package from the start of this thread, and am totally stuck at the USB Driver stage. I'm no driver noob, and I've given it a few tries, but can't get past the "Waiting for Proxmark to appear on USB".

With earlier versions, the default HID assignment worked fine, of course.
For this version, I tried upgrading to the included "proxmark_driver" files.
This doesn't seem to make any difference.
The device still shows up in Device Manager as an HID device.

I've tried uninstalling and re-installing with the directed driver as well. The VID/PID match, but it always pulls in a USB Human Interface Device after install.

There are references in this thread to a mingw-inf program, which doesn't appear to be included in this beta release. Where can I find it?

I brought my proxmark3 over from a working Linux system, and have not built the Windows tools myself. I was hoping this binary package would contain all the needed Windows components.

If there are more files needed than are in this .zip, perhaps they could be added to make a complete turnkey package?

Anyway, back to Linux for now.

Ground Loop · 2010-03-07 21:25:19

I'm starting to think that something on the ProxMark3 needs to be reprogrammed before it matches the included libusb/proxmark3 Windows driver?

The Driver File Details for the installed device still point to hidclass, hidparse, hidusb .sys files, and hid.dll. Even though I can repeatedly select the libusb0.sys and proxmark3 files, it doesn't seem to use them. Is there something in the USB Enumeration that is forcing Win32 to use the default HID driver?

iZsh · 2010-03-07 21:40:41

I had the same issue initially because I was not choosing the proper option to install the driver.

During the driver update:
"Install from a list or specific location (Advanced)"->"Don't search. I will choose the driver to install" [1] ->"Have disk"...

Make sure you select [1], and not "search for the best driver in these locations", even after providing the path to the driver. It is NOT the same and will not work otherwise.

Ground Loop · 2010-03-07 22:08:14

iZsh! Thank you, that was exactly it.

I'm in business now.

iZsh · 2010-03-07 22:15:39

Thanks microsoft for being so intuitive*...

(*) a subliminal message is embedded

CardSaysMoops · 2010-03-08 04:20:31

Hey, downloaded this today, and got a stock Proxmark3 from proxmark.com to update easily. Had to do the fullimage plus the bootloader, but no trouble after figuring out that I had to hold the button down to flash the bootloader. Thank you THANK YOU for making such a clean, simple package. With names like fullimage.elf, proxmark3.exe and flasher.exe it's almost noob level. Had to copy the help commands down in a text file, but successfully figured out an unknown card I have by going through the tutorial at http://code.google.com/p/proxmark3/wiki/TagOps .

iZsh · 2010-03-08 15:22:59

I'm feeling warm and fuzzy inside, you're the first one not complaining about my changes

Cex · 2010-03-10 08:04:29

Hello,

Nice work, but I think I found a bug.

When using 'lf read', the command does not work if the 'h' parameter is specified (to read at 134KHz).

Thanks for this release.

Regards,
Cex.

edo512 · 2010-03-18 11:34:00

I got stuck with the PM3 upgrade process: I have a "Summer of '09" firmware (including bootloader) on the device, and every attempt at installing the new PM3 driver end up with a "The specified location does not contain information about your hardware".

I then realized the PM3 was appearing twice (same PID/VID) on my hardware manager: first as a "HID compliant device" and second as a "USB HID Device". I had to choose the "USB HID device" in order to have the driver installed... Rings a bell to anyone?

Last edited by edo512 (2010-03-18 11:40:43)

edo512 · 2010-03-18 12:35:25

Another strange issue: now that I have upgraded my PM3 to the r412 release, the lf read command is totally broken: when I type it, the red LED on the PM3 starts to blink apparently randomly, and after about 30 second the board resets (watchdog?). Is this a known issue? Not being able to read LF tags anymore is definitely a big problem!

The upside is that the new flasher tool seems to be working perfectly, very nice to use.

Ed

CardSaysMoops · 2010-03-18 14:48:03

I have been able to use the lf read command OK on the Winter '10 release. I upgraded the bootloader, and the fullimage.elf, but I came from a little older code that the boards from proxmark3.com come with.

albertoparis · 2010-05-11 16:06:54

Hi,

Hi, I am using a PM3 with Winter'10 firmware/os/bootloader (r412) and Windows binary software, under freshly installed WinXP Pro. I have a OmniKey Cardman 5321 reader (USB), some MIFARE Classic 1K tags and use the OmniKey Diagnostic Tool (ODT) to check tags presence on the OmniKey reader ... Downloaded the Winter'10 binary package, updated firmware/os/bootloader on my brand new PM3, and everything there was perfect. The proxmark3.exe software works, but there are some problems:

1) I see everywhere in the forums that everyone uses the "old" (?) command format, as described in the Reference Manual, but on Winter'10 package the commands are used differently. For example:
In the Reference Manual, they use: tune
In Winter'10, you have to use: hw tune
In the Reference Manual, they use: hi14asnoop
In Winter'10, you have to use: hf 14a snoop
In the Reference Manual, they use: hi14alist
In Winter'10, you have to use: hf 14a list

2) Some commands will not work, because they do not accept parameters that the documentation says it should accept. For example:
In the Reference Manual, they use: detectreader [l|h]
In Winter'10, you have to use: hw detectreader (by itself), but "hw detectreader h" or " hw detectreader l" won't work

proxmark3> hw
detectreader      ['l'|'h'] -- Detect external reader field (option 'l' or 'h' to limit to LF or HF)
-- 
proxmark3> hw detectreader
#db# LF 125/134 Baseline : 1
#db# HF 13.56 Baseline: 8
#db# HF 13.56 Field Change: 8 13 65e6
...
proxmark3> hw detectreader h
use 'detectreader' or 'detectreader l' or 'detectreader h'
proxmark3> hw detectreader l
use 'detectreader' or 'detectreader l' or 'detectreader h'

In the Reference Manual, they use: loread [ h ]
In Winter'10, you have to use: lf read (by itself), but "lf read h" won't work

proxmark3> lf
read                  ['h'] -- Read 125/134 kHz LF ID-only tar (option 'h' for 134)
--
proxmark3> lf read
#db# buffer samples: 76 74 76 74 76 75 76 74 ...
proxmark3> lf read h
use 'read' or 'read h'

3) Some commands will accept the provided parameter, but use it in unknown ways. For example:
In the Reference Manual, they use: hi14sim <UID>
In Winter'10, you have to use: hf 14a sim <UID>, but the resulting information shows some different non-related UID, like:

proxmark3> hf 14a sim
Emulating 14443A TAG with UID 0               0
--
proxmark3> hf 14a sim 123456
Emulating 14443A TAG with UID 0         1123456
--
proxmark3> hf 14a sim 1234567890
Emulating 14443A TAG with UID 112        34567890
--
proxmark3> hf 14a sim 12345678901234567890
Emulating 14443A TAG with UID 56789012        34567890

Dealing with this three issues, what is your recommendation ? Should I use a different version for firmware, os, bootloader or Win software ? Is there any documentation on this "new" (?) command format ?

cup · 2010-06-22 18:26:27

I am having trouble with some of the commands not working...anyone know what this means?

proxmark3> hw tune
unrecognized command 00000401

or

proxmark3> hw detectreader
#db# unknown command

but this works...
proxmark3> hw detectreader help
use 'detectreader' or 'detectreader l' or 'detectreader h'

Some other commands do not work as well (including the em4x commands, which I would like to use).

Any help from anyone would be much appreciated...i know these arent the most active forums...but i figured i'd ask

thanks.

Proxmark3 community

Announcement

#1 2010-02-26 16:09:02

Winter '10 - test release

#2 2010-02-26 21:55:37

Re: Winter '10 - test release

#3 2010-02-26 22:29:41

Re: Winter '10 - test release

#4 2010-02-26 22:30:28

Re: Winter '10 - test release

#5 2010-02-26 22:44:05

Re: Winter '10 - test release

#6 2010-02-26 23:02:22

Re: Winter '10 - test release

#7 2010-02-26 23:09:20

Re: Winter '10 - test release

#8 2010-02-26 23:12:05

Re: Winter '10 - test release

#9 2010-02-26 23:20:06

Re: Winter '10 - test release

#10 2010-02-27 00:29:43

Re: Winter '10 - test release

#11 2010-02-27 11:10:54

Re: Winter '10 - test release

#12 2010-02-27 16:46:35

Re: Winter '10 - test release

#13 2010-02-27 16:50:48

Re: Winter '10 - test release

#14 2010-02-27 17:20:20

Re: Winter '10 - test release

#15 2010-02-27 17:24:54

Re: Winter '10 - test release

#16 2010-02-27 17:51:42

Re: Winter '10 - test release

#17 2010-02-27 21:05:49

Re: Winter '10 - test release

#18 2010-02-27 22:25:31

Re: Winter '10 - test release

#19 2010-02-28 02:58:57

Re: Winter '10 - test release

#20 2010-02-28 11:56:23

Re: Winter '10 - test release

#21 2010-02-28 13:59:12

Re: Winter '10 - test release

#22 2010-03-02 00:25:40

Re: Winter '10 - test release

#23 2010-03-02 02:04:54

Re: Winter '10 - test release

#24 2010-03-02 04:34:20

Re: Winter '10 - test release

#25 2010-03-02 12:38:08

Re: Winter '10 - test release

#26 2010-03-02 14:44:30

Re: Winter '10 - test release

#27 2010-03-02 19:15:49

Re: Winter '10 - test release

#28 2010-03-02 20:25:09

Re: Winter '10 - test release

#29 2010-03-02 21:29:42

Re: Winter '10 - test release

#30 2010-03-02 21:32:45

Re: Winter '10 - test release

#31 2010-03-02 22:32:43

Re: Winter '10 - test release

#32 2010-03-03 03:18:05

Re: Winter '10 - test release

#33 2010-03-03 08:14:41

Re: Winter '10 - test release

#34 2010-03-03 10:47:05

Re: Winter '10 - test release

#35 2010-03-03 13:51:11

Re: Winter '10 - test release

#36 2010-03-04 03:48:20

Re: Winter '10 - test release

#37 2010-03-04 04:43:05

Re: Winter '10 - test release

#38 2010-03-07 20:55:57

Re: Winter '10 - test release

#39 2010-03-07 21:25:19

Re: Winter '10 - test release