proxmark/proxmark3

Proxmark 3

proxmark3's Issues

Missing file while compiling

ERROR:
cmdlf.c:30:21: error: cmdlfio.h: No such file or directory
cmdlf.c:536: error: 'CmdLFIO' undeclared here (not in a function)

CAUSE:
result of a merge (pull request from PenturaLabs).

cload issues since last update

Hi!

I'm having trouble cloning cards since I upgraded to 2.0.0-rc1 and was encouraged to post here in case this is actually a bug.
Context can be found here: http://www.proxmark.org/forum/viewtopic.php?pid=14603

Thank you.

ISO14443B is not working anymore

The actual code seems to have problems with ISO14443B; when sending commands [ex. hf 14b raw -c -p 06 00] to tags the pm3 hangs (solid red led) and resets itself after some seconds (10-15 seconds).

The code was surely working when 14b raw was introduced: 7cf3ef2

What is this iclass_dump.bin file?

A binary file in a source folder?
What is its purpose?

Commit: 6f10199
File: https://github.com/Proxmark/proxmark3/blob/master/client/loclass/iclass_dump.bin

256 vs 512Kb PM3

I noticed in the file common/ldscript.common, that it exports some variable for determine the size of avalible flash. In my case I've two PM3's, 256kb / 512kb.
The latter one with more memory would not benefit from this which the current settings.

osimage = 256K-96k,
and
_flash_end = ORIGIN(osimage) + LENGTH(osimage);

I suppose this needs to be set during compilation somehow.
Any suggestions on how to solve this?

---snippet---
*/

/* AT91SAM7S256 has 256k Flash and 64k RAM /
MEMORY
{
bootphase1 : ORIGIN = 0x00100000, LENGTH = 0x200 / Phase 1 bootloader: Copies real bootloader to RAM /
bootphase2 : ORIGIN = 0x00100200, LENGTH = 0x2000 - 0x200 / Main bootloader code, stored in Flash, executed from RAM /
fpgaimage : ORIGIN = 0x00102000, LENGTH = 96k - 0x2000 / Place where the FPGA image will end up /
osimage : ORIGIN = 0x00118000, LENGTH = 256K - 96k / Place where the main OS will end up /
ram : ORIGIN = 0x00200000, LENGTH = 64K - 0x20 / RAM, minus small common area /
commonarea : ORIGIN = 0x00200000 + 64K - 0x20, LENGTH = 0x20 / Communication between bootloader and main OS */
}

/* Export some information that can be used from within the firmware */
_bootphase1_version_pointer = ORIGIN(bootphase1) + LENGTH(bootphase1) - 0x4;
_osimage_entry = ORIGIN(osimage);
_bootrom_start = ORIGIN(bootphase1);
_bootrom_end = ORIGIN(bootphase2) + LENGTH(bootphase2);
_flash_start = ORIGIN(bootphase1);
_flash_end = ORIGIN(osimage) + LENGTH(osimage);
_stack_end = ORIGIN(ram) + LENGTH(ram) - 8;

missing commands. clone ioprox

Hi i had bought proxmark from xpfga and i was given the indala cloner software for it. can kind soul enlighten how do i upload the ioprox patch as i am missing the io commands in my software. i tried attempting to do a fresh installation but i was unable to get even proxmark.exe running. would really love if i could get some detailed instructions on how to get these io commands. i really dont know where exactly to add the patch provided here. https://penturalabs.wordpress.com/2014/03/11/proxmark3-vs-kanotech-ioprox/

LF Sim Timing issues

I've been testing the LF sim functions to see why they are so erratic as to their functionality.
I believe it comes down to the use of the clock in SimulateTagLowFrequency.
could someone explain what GPIO_SSC_CLK measures?

let me illustrate the issue:
a standard HID FSK2a tag should have waves 10 samples and 8 samples long depending on whether it is bit 1 or bit 0. so digitally it should be 1111100000 and 11110000.

if this is sent through the SimulateTagLowFrequncy the output has 2 errors.

1. the number of samples have lengthened to 11111110000000 and 11111000000
   so our clock is too slow
2. if you compensate for by reducing the bits sent to the function then the second issue becomes obvious: the transition between bit 1s and bit 0s creates extra 0 waves.
   So going from 1111000011110000 to 1111100000 translates 11110000001111100000 (added 2 extra 0 bits)

img1: bad timing:

img2: bad transition:

any thoughts?

I can get ASK clocks of 32 or greater to work fine but the lower the clock the worse this affects things.

Qt version detection in client\Makefile

The Qt used is normally the old 4.6.2, but if you, as I, tries with the latest Qt 5.3.1 you will run into some compiling issues in the client\makefile

After I´ve been looking into the Makefile magic, I think this is a possible solution..
When running the command "/qt/bin/moc -v" you get the current version of Qt.
The returned string is very different from Qt4 and Qt5. The fix tries to find "MOC 5" in the returned string if found it assumes Qt5. Otherwise it just thinks its old Qt4.

QT version, 4 or 5

qtplatform = $(shell $(MOC) -v)
ifneq (, $(findstring moc 5,$(qtplatform)))
CXXFLAGS = -I$(QTDIR)/include -I$(QTDIR)/include/QtCore -I$(QTDIR)/include/QtGui -I$(QTDIR)/include/QtWidgets -I/mingw/include
QTLDLIBS = -L$(QTDIR)/lib -lQt5Core -lQt5Gui -lQt5Widgets
else
CXXFLAGS = -I$(QTDIR)/include -I$(QTDIR)/include/QtCore -I$(QTDIR)/include/QtGui
QTLDLIBS = -L$(QTDIR)/lib -lQtCore4 -lQtGui4
endif

*edit: the if statment should be "ifneq" and findstr MOC -> findstr moc

script commands do not take working directory into account

Just a small bug I've encountered,

"script list" and "script run" both use relative path "./scripts/" to find scripts to list and/or run. This makes the script command unusable if you run the client from anywhere but the "client" folder.

ISO14443 - Can't emulate tags of greater than ~56 bytes.

Hello - I'm still having issues with emulating ISO14443a tags of lengths greater than 56 bytes.
I've tried increasing the default size of the ToSend buffer - which did help to extend the supported length - but am hitting an upper limit that i can't seem to locate why.

My current running code is forked in https://github.com/peterfillmore/proxmark3 . This adds support for reading and emulating ISO14443a based NFC payment cards. This is 'experimental' code for now, but works for reading EMV cards at the moment.

I've checked the parity outputs for long tags, which indicates it is correctly generated.
However when testing i find that something is going wrong with longer tags.
Here is a test using an ACR-122U reader and the RFIDIOt tools

Failing tag - 64 bytes:
uint8_t selectPPSE[] = {
0x6f,0x2f,0x84,0x0e,0x32,0x50,0x41,0x59,
0x2e,0x53,0x59,0x53,0x2e,0x44,0x44,0x46,
0x30,0x31,0xa5,0x1d,0xbf,0x0c,0x1a,0x61,
0x18,0x4f,0x07,0xa0,0x00,0x00,0x00,0x04,
0x18,0x4f,0x07,0xa0,0x00,0x00,0x00,0x04,
0x18,0x4f,0x07,0xa0,0x00,0x00,0x00,0x04,
0x10,0x10,0x50,0x0a,0x4d,0x61,0x73,0x74,
0x65,0x72,0x43,0x61,0x72,0x64,0x90,0x00};
python ChAP.py -dv
> 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
RESPONSE=
0
no PSE: 00 00

Passing tag - 56 bytes:
uint8_t selectPPSE[] = {
0x6f,0x2f,0x84,0x0e,0x32,0x50,0x41,0x59,
0x2e,0x53,0x59,0x53,0x2e,0x44,0x44,0x46,
0x30,0x31,0xa5,0x1d,0xbf,0x0c,0x1a,0x61,
0x18,0x4f,0x07,0xa0,0x00,0x00,0x00,0x04,
0x18,0x4f,0x07,0xa0,0x00,0x00,0x00,0x04,
0x10,0x10,0x50,0x0a,0x4d,0x61,0x73,0x74,
0x65,0x72,0x43,0x61,0x72,0x64,0x90,0x00};
> 00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
RESPONSE=
56
< 6F 2F 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 1D BF 0C 1A 61 18 4F 07 A0 00 00 00 04 18 4F 07 A0 00 00 00 04 10 10 50 0A 4D 61 73 74 65 72 43 61 72 64 90 0 PSE found!

This indicates something weird is happening with the modulation - as once i got over ~56 bytes i encounter failing packets.
Any hints on why this is happening would greatly be appreciated (also, its not the reader - a normal EMV NFC card is read fine (i.e tags>64 bytes are common).
Regards,
Peter Fillmore

t55xx Biphase configuration

At the moment @marshmellow42 and I have identified some minor problems with the biphase demodulation, where the lf t55xx read/info/trace will not manage to correctly decode a t55x7 tag configured for Biphase. We are looking into it.

I'm also noticing a strange behavior with t55x7 tags, where the Biphase configuration setting needs a password when setting it, regardless if the tag wasn't configured to be in password mode. Very strange indeed. If someone wants to do some test it would be good. At least so I can rule out the possiblity that its my t55x7 tags that are strange.

Command buffer overflow in hf tune?

Hi everyone,

I was playing around with hf tune, trying a bunch of RFID cards to sse which were HF, when I encountered some kind of bug.

I usually just run hf tune and check for a drop in voltage when the card is close to my antenna. Today, however, after a little while (around a minute, maybe less) the client started displaying:

WARNING: Command buffer about to overwrite command! This needs to be fixed!

instead of the usual "#db# XXXXXmV". Just thought I'd let you know, since I'm in no way proficient enough to fix this myself (yet).

I'm running a one-week old client (git pull today on master, but did not compile yet) with firmware 2.0.0-rc2.

Thanks as usual!

TL;DR: Ran "hf tune" for around a minute, got "WARNING: Command buffer about to overwrite command! This needs to be fixed!" 😘

BCC1, simulating 7bytes UID [hf mf sim]

I think I found a minor bug in the "hf mf sim" command.
It occures when trying to simulate a 7byte UID. I have noticed this from sniffed traces and compared them with the simulated traces.

https://github.com/Proxmark/proxmark3/blob/master/armsrc/iso14443a.c#L2269

The problem is the update of byte[0] to 0x88 doesnt reflect upon the BCC1.

Solution:

find
https://github.com/Proxmark/proxmark3/blob/master/armsrc/iso14443a.c#L2272

and add this row after it.

rUIDBCC1[4] = rUIDBCC1[0] ^ rUIDBCC1[1] ^ rUIDBCC1[2] ^ rUIDBCC1[3];

OS X - Unable to flash - Waiting for Proxmark to reappear on USB......

Hi All,

I have just been given a Proxmark Device.

I'm following the steps for OS X from the GitHub wiki page.

I'm currently stuck when I try update the boot loader

richtea -> ./flasher -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 (0x00000b60->0x00000b60) [RWX] @0x298

Waiting for Proxmark to appear on USB...
Connected units:
1. SN: ChangeMe [020/008]
 Found.
 Entering bootloader...
 (Press and release the button only to abort)
 Waiting for Proxmark to reappear on USB..........................................................................................................................

I have tried restarting after installing dummy driver.

I am holding the button down for 5 seconds when inserting the Proxmark.

My Proxmark is getting reported as:

ProxMark-3 RFID Instrument:

      Product ID: 0x4b8f
      Vendor ID: 0x9ac4
      Version: 0.01
      Serial Number: ChangeMe
      Speed: Up to 12 Mb/sec
      Manufacturer: J. Westhues
      Location ID: 0x14100000 / 19
      Current Available (mA): 500
      Current Required (mA): 500

Any help would be appreciated.

`hf mf sim` does not work while `hf 14a sim` does

Not sure where the problem is.

When I run hf mf sim, nothing seems to happen (I have tried several readers), but hf 14a sim works with all my readers.

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: master/v2.0.0-46-g4b36037-suspect 2015-05-20 20:51:58                 
#db# os: master/v2.0.0-46-g4b36037-suspect 2015-05-20 20:52:00                 
#db# HF FPGA image built on 2015/03/09 at 08:41:42                 
uC: AT91SAM7S256 Rev B          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 256K bytes          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory          

proxmark3> hf mf eload empty
................................................................
Loaded 64 blocks from file: empty.eml          

proxmark3> hf mf sim i
 uid:N/A, numreads:0, flags:1 (0x01)           
Press pm3-button to abort simulation          
#db# 4B UID: 01234567                 
[nothing happens: no LED on, the reader does not "see" the simulated card, I press the button]
#db# Emulator stopped. Tracing: 1  trace length: 0                  

proxmark3> hf 14a sim 1
Emulating ISO/IEC 14443 type A tag with 4 byte UID (00000000)          
[yellow LED on, a lot of "#db# Auth attempt {nr}{ar}:" lines when I try to read the simulated card, and the reader "sees" a Mifare Classic 1K with NUID 00000000]

Any ideas about what could happen here? Thanks!

hf mf sim after r845

With r844 and later, I am unable to do 'hf mf sim' and related commands (snoop) on one type of readers found in 'real-world'. The yellow led blinks, but nothing happens and even with 'hf mf dbg 4', there is nothing sent back from the device.

What happened to tagging?

Are there still any plans for git tagging? I had been off for some time and may have missed something - a lot of commits later v1.0.0 is still the latest tag?

hf mf csetuid

For a long while my "hf mf csetuid" has been all but reliable.
With Piwi's changes to iso14443a_select_card, I was told about the critical timings which are now in order.
I also noticed some entries on the forum asking about the magic cards not working.
When I commented out some "spindelays" here, https://github.com/Proxmark/proxmark3/blob/master/armsrc/mifarecmd.c#L906 , I got my "hf mf csetuid" to work without a problem.

I suspect this is the problem with the other magic-chines commands too.

I suggest the patch to comment out row 906 to 909.

Please review and come back with feedback.

Huge slowdown after issuing some commands

I was trying the new commands on mfu and discovered some strange behavior.

Here are the steps I followed:

1. plug the PM3
2. launch the client
3. hf mfu info
   -> takes a couple of seconds at most
4. hf mfu
   -> takes a minute to print the help
5. hf mfu info
   -> takes a minute (instead of seing the red light blinking, it goes on and off at a very slow pace)!

After that, pretty much all commands on pm3 are really slow to execute.
The only way I've found so far to return to normal state is to restart the pm3 by unplugging it.

I also managed to get the same behavior after issuing "hf mfu info" 16 times in row. The last one is slowed down. So it seems to be related to some buffer that help commands can fill faster...

bufferoverflow when reading NTAG215

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument
#db# bootrom: master/v2.0.0-45-g5023d4c-suspect 2015-05-02 17:17:31
#db# os: master/v2.0.0-45-g5023d4c-suspect 2015-05-02 21:05:24
#db# HF FPGA image built on 2015/03/09 at 08:41:42
uC: AT91SAM7S256 Rev B
Embedded Processor: ARM7TDMI
Nonvolatile Program Memory Size: 256K bytes
Second Nonvolatile Program Memory Size: None
Internal SRAM Size: 64K bytes
Architecture Identifier: AT91SAM7Sxx Series
Nonvolatile Program Memory Type: Embedded Flash Memory

proxmark3> hf 14a reader
 UID : 04 d2 57 7a e3 3e 80
ATQA : 00 44
 SAK : 00 [2]
*** buffer overflow detected ***: ./proxmark3 terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x73f1f)[0x7fa460dc2f1f]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7fa460e5a82c]
/lib/x86_64-linux-gnu/libc.so.6(+0x10a6f0)[0x7fa460e596f0]
./proxmark3[0x425b3e]
./proxmark3[0x43c908]
./proxmark3[0x4269c2]
./proxmark3[0x43c908]
./proxmark3[0x425241]
./proxmark3[0x43c908]
./proxmark3[0x406873]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x8182)[0x7fa462cd9182]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fa460e4a00d]
======= Memory map: ========
00400000-00491000 r-xp 00000000 08:01 321899                             /home/borjabugos/proxmark3/client/proxmark3
00690000-00691000 r--p 00090000 08:01 321899                             /home/borjabugos/proxmark3/client/proxmark3
00691000-00694000 rw-p 00091000 08:01 321899                             /home/borjabugos/proxmark3/client/proxmark3
00694000-01b6a000 rw-p 00000000 00:00 0
02813000-02834000 rw-p 00000000 00:00 0                                  [heap]
7fa458000000-7fa458021000 rw-p 00000000 00:00 0
7fa458021000-7fa45c000000 ---p 00000000 00:00 0
7fa45c323000-7fa45ca05000 r--p 00000000 08:01 8234                       /usr/lib/locale/locale-archive
7fa45ca05000-7fa45ca06000 ---p 00000000 00:00 0
7fa45ca06000-7fa45d206000 rw-p 00000000 00:00 0                          [stack:3551]
7fa45d206000-7fa45d207000 ---p 00000000 00:00 0
7fa45d207000-7fa45da07000 rw-p 00000000 00:00 0                          [stack:3550]
7fa45da07000-7fa45da0c000 r-xp 00000000 08:01 13395                      /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7fa45da0c000-7fa45dc0b000 ---p 00005000 08:01 13395                      /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7fa45dc0b000-7fa45dc0c000 r--p 00004000 08:01 13395                      /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7fa45dc0c000-7fa45dc0d000 rw-p 00005000 08:01 13395                      /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0
7fa45dc0d000-7fa45dc2a000 r-xp 00000000 08:01 14452                      /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7fa45dc2a000-7fa45de2a000 ---p 0001d000 08:01 14452                      /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7fa45de2a000-7fa45de2b000 r--p 0001d000 08:01 14452                      /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7fa45de2b000-7fa45de2c000 rw-p 0001e000 08:01 14452                      /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0
7fa45de2c000-7fa45de30000 r-xp 00000000 08:01 137809                     /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fa45de30000-7fa45e02f000 ---p 00004000 08:01 137809                     /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fa45e02f000-7fa45e030000 r--p 00003000 08:01 137809                     /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fa45e030000-7fa45e031000 rw-p 00004000 08:01 137809                     /lib/x86_64-linux-gnu/libuuid.so.1.3.0
7fa45e031000-7fa45e038000 r-xp 00000000 08:01 13666                      /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1
7fa45e038000-7fa45e237000 ---p 00007000 08:01 13666                      /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1
7fa45e237000-7fa45e238000 r--p 00006000 08:01 13666                      /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1
7fa45e238000-7fa45e239000 rw-p 00007000 08:01 13666                      /usr/lib/x86_64-linux-gnu/libffi.so.6.0.1
7fa45e239000-7fa45e276000 r-xp 00000000 08:01 137754                     /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7fa45e276000-7fa45e475000 ---p 0003d000 08:01 137754                     /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7fa45e475000-7fa45e476000 r--p 0003c000 08:01 137754                     /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7fa45e476000-7fa45e477000 rw-p 0003d000 08:01 137754                     /lib/x86_64-linux-gnu/libpcre.so.3.13.1
7fa45e477000-7fa45e479000 r-xp 00000000 08:01 13384                      /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7fa45e479000-7fa45e679000 ---p 00002000 08:01 13384                      /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7fa45e679000-7fa45e67a000 r--p 00002000 08:01 13384                      /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7fa45e67a000-7fa45e67b000 rw-p 00003000 08:01 13384                      /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0
7fa45e67b000-7fa45e6da000 r-xp 00000000 08:01 13423                      /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0
7fa45e6da000-7fa45e8da000 ---p 0005f000 08:01 13423                      /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0
7fa45e8da000-7fa45e8db000 r--p 0005f000 08:01 13423                      /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0
7fa45e8db000-7fa45e8e0000 rw-p 00060000 08:01 13423                      /usr/lib/x86_64-linux-gnu/libXt.so.6.0.0
7fa45e8e0000-7fa45e8e1000 rw-p 00000000 00:00 0
7fa45e8e1000-7fa45e908000 r-xp 00000000 08:01 137673                     /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fa45e908000-7fa45eb08000 ---p 00027000 08:01 137673                     /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fa45eb08000-7fa45eb0a000 r--p 00027000 08:01 137673                     /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fa45eb0a000-7fa45eb0b000 rw-p 00029000 08:01 137673                     /lib/x86_64-linux-gnu/libexpat.so.1.6.0
7fa45eb0b000-7fa45eb12000 r-xp 00000000 08:01 137779                     /lib/x86_64-linux-gnu/librt-2.19.so
7fa45eb12000-7fa45ed11000 ---p 00007000 08:01 137779                     /lib/x86_64-linux-gnu/librt-2.19.so
7fa45ed11000-7fa45ed12000 r--p 00006000 08:01 137779                     /lib/x86_64-linux-gnu/librt-2.19.so
7fa45ed12000-7fa45ed13000 rw-p 00007000 08:01 137779                     /lib/x86_64-linux-gnu/librt-2.19.so
7fa45ed13000-7fa45ee43000 r-xp 00000000 08:01 13380                      /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7fa45ee43000-7fa45f043000 ---p 00130000 08:01 13380                      /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7fa45f043000-7fa45f044000 r--p 00130000 08:01 13380                      /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7fa45f044000-7fa45f048000 rw-p 00131000 08:01 13380                      /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0
7fa45f048000-7fa45f059000 r-xp 00000000 08:01 13397                      /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7fa45f059000-7fa45f258000 ---p 00011000 08:01 13397                      /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7fa45f258000-7fa45f259000 r--p 00010000 08:01 13397                      /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7fa45f259000-7fa45f25a000 rw-p 00011000 08:01 13397                      /usr/lib/x86_64-linux-gnu/libXext.so.6.4.0
7fa45f25a000-7fa45f263000 r-xp 00000000 08:01 13419                      /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fa45f263000-7fa45f462000 ---p 00009000 08:01 13419                      /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fa45f462000-7fa45f463000 r--p 00008000 08:01 13419                      /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fa45f463000-7fa45f464000 rw-p 00009000 08:01 13419                      /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0
7fa45f464000-7fa45f473000 r-xp 00000000 08:01 13405                      /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
7fa45f473000-7fa45f672000 ---p 0000f000 08:01 13405                      /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
7fa45f672000-7fa45f673000 r--p 0000e000 08:01 13405                      /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
7fa45f673000-7fa45f674000 rw-p 0000f000 08:01 13405                      /usr/lib/x86_64-linux-gnu/libXi.so.6.1.0
7fa45f674000-7fa45f68b000 r-xp 00000000 08:01 13254                      /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0
7fa45f68b000-7fa45f88a000 ---p 00017000 08:01 13254                      /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0
7fa45f88a000-7fa45f88b000 r--p 00016000 08:01 13254                      /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0
7fa45f88b000-7fa45f88c000 rw-p 00017000 08:01 13254                      /usr/lib/x86_64-linux-gnu/libICE.so.6.3.0
7fa45f88c000-7fa45f890000 rw-p 00000000 00:00 0
7fa45f890000-7fa45f897000 r-xp 00000000 08:01 13376                      /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
7fa45f897000-7fa45fa96000 ---p 00007000 08:01 13376                      /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
7fa45fa96000-7fa45fa97000 r--p 00006000 08:01 13376                      /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
7fa45fa97000-7fa45fa98000 rw-p 00007000 08:01 13376                      /usr/lib/x86_64-linux-gnu/libSM.so.6.0.1
7fa45fa98000-7fa45fae7000 r-xp 00000000 08:01 13795                      /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0
7fa45fae7000-7fa45fce7000 ---p 0004f000 08:01 13795                      /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0
7fa45fce7000-7fa45fce8000 r--p 0004f000 08:01 13795                      /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0
7fa45fce8000-7fa45fce9000 rw-p 00050000 08:01 13795                      /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4002.0
7fa45fce9000-7fa45fd85000 r-xp 00000000 08:01 13708                      /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7fa45fd85000-7fa45ff84000 ---p 0009c000 08:01 13708                      /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7fa45ff84000-7fa45ff8a000 r--p 0009b000 08:01 13708                      /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7fa45ff8a000-7fa45ff8b000 rw-p 000a1000 08:01 13708                      /usr/lib/x86_64-linux-gnu/libfreetype.so.6.11.1
7fa45ff8b000-7fa45ffa3000 r-xp 00000000 08:01 137814                     /lib/x86_64-linux-gnu/libz.so.1.2.8
7fa45ffa3000-7fa4601a2000 ---p 00018000 08:01 137814                     /lib/x86_64-linux-gnu/libz.so.1.2.8
7fa4601a2000-7fa4601a3000 r--p 00017000 08:01 137814                     /lib/x86_64-linux-gnu/libz.so.1.2.8
7fa4601a3000-7fa4601a4000 rw-p 00018000 08:01 137814                     /lib/x86_64-linux-gnu/libz.so.1.2.8
7fa4601a4000-7fa4601c9000 r-xp 00000000 08:01 137766                     /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7fa4601c9000-7fa4603c8000 ---p 00025000 08:01 137766                     /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7fa4603c8000-7fa4603c9000 r--p 00024000 08:01 137766                     /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7fa4603c9000-7fa4603ca000 rw-p 00025000 08:01 137766                     /lib/x86_64-linux-gnu/libpng12.so.0.50.0
7fa4603ca000-7fa4604d0000 r-xp 00000000 08:01 137682                     /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0
7fa4604d0000-7fa4606cf000 ---p 00106000 08:01 137682                     /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0
7fa4606cf000-7fa4606d0000 r--p 00105000 08:01 137682                     /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0
7fa4606d0000-7fa4606d1000 rw-p 00106000 08:01 137682                     /lib/x86_64-linux-gnu/libglib-2.0.so.0.4002.0
7fa4606d1000-7fa4606d2000 rw-p 00000000 00:00 0
7fa4606d2000-7fa4606e9000 r-xp 00000000 08:01 13486                      /usr/lib/x86_64-linux-gnu/libaudio.so.2.4
7fa4606e9000-7fa4608e8000 ---p 00017000 08:01 13486                      /usr/lib/x86_64-linux-gnu/libaudio.so.2.4
7fa4608e8000-7fa4608e9000 r--p 00016000 08:01 13486                      /usr/lib/x86_64-linux-gnu/libaudio.so.2.4
7fa4608e9000-7fa4608ea000 rw-p 00017000 08:01 13486                      /usr/lib/x86_64-linux-gnu/libaudio.so.2.4
7fa4608ea000-7fa460924000 r-xp 00000000 08:01 13680                      /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7fa460924000-7fa460b23000 ---p 0003a000 08:01 13680                      /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7fa460b23000-7fa460b25000 r--p 00039000 08:01 13680                      /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7fa460b25000-7fa460b26000 rw-p 0003b000 08:01 13680                      /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.8.0
7fa460b26000-7fa460b4b000 r-xp 00000000 08:01 137797                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7fa460b4b000-7fa460d4a000 ---p 00025000 08:01 137797                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7fa460d4a000-7fa460d4e000 r--p 00024000 08:01 137797                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7fa460d4e000-7fa460d4f000 rw-p 00028000 08:01 137797                     /lib/x86_64-linux-gnu/libtinfo.so.5.9
7fa460d4f000-7fa460f0a000 r-xp 00000000 08:01 137650                     /lib/x86_64-linux-gnu/libc-2.19.so
7fa460f0a000-7fa46110a000 ---p 001bb000 08:01 137650                     /lib/x86_64-linux-gnu/libc-2.19.so
7fa46110a000-7fa46110e000 r--p 001bb000 08:01 137650                     /lib/x86_64-linux-gnu/libc-2.19.so
7fa46110e000-7fa461110000 rw-p 001bf000 08:01 137650                     /lib/x86_64-linux-gnu/libc-2.19.so
7fa461110000-7fa461115000 rw-p 00000000 00:00 0
7fa461115000-7fa46112b000 r-xp 00000000 08:01 137678                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7fa46112b000-7fa46132a000 ---p 00016000 08:01 137678                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7fa46132a000-7fa46132b000 rw-p 00015000 08:01 137678                     /lib/x86_64-linux-gnu/libgcc_s.so.1
7fa46132b000-7fa461430000 r-xp 00000000 08:01 137701                     /lib/x86_64-linux-gnu/libm-2.19.so
7fa461430000-7fa46162f000 ---p 00105000 08:01 137701                     /lib/x86_64-linux-gnu/libm-2.19.so
7fa46162f000-7fa461630000 r--p 00104000 08:01 137701                     /lib/x86_64-linux-gnu/libm-2.19.so
7fa461630000-7fa461631000 rw-p 00105000 08:01 137701                     /lib/x86_64-linux-gnu/libm-2.19.so
7fa461631000-7fa461717000 r-xp 00000000 08:01 14288                      /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7fa461717000-7fa461916000 ---p 000e6000 08:01 14288                      /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7fa461916000-7fa46191e000 r--p 000e5000 08:01 14288                      /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7fa46191e000-7fa461920000 rw-p 000ed000 08:01 14288                      /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
7fa461920000-7fa461935000 rw-p 00000000 00:00 0
7fa461935000-7fa461c0d000 r-xp 00000000 08:01 13326                      /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6
7fa461c0d000-7fa461e0d000 ---p 002d8000 08:01 13326                      /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6
7fa461e0d000-7fa461e18000 r--p 002d8000 08:01 13326                      /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6
7fa461e18000-7fa461e19000 rw-p 002e3000 08:01 13326                      /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.6
7fa461e19000-7fa461e1a000 rw-p 00000000 00:00 0
7fa461e1a000-7fa462880000 r-xp 00000000 08:01 13341                      /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6
7fa462880000-7fa462a80000 ---p 00a66000 08:01 13341                      /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6
7fa462a80000-7fa462ac2000 r--p 00a66000 08:01 13341                      /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6
7fa462ac2000-7fa462ac9000 rw-p 00aa8000 08:01 13341                      /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.6
7fa462ac9000-7fa462acd000 rw-p 00000000 00:00 0
7fa462acd000-7fa462ad0000 r-xp 00000000 08:01 137668                     /lib/x86_64-linux-gnu/libdl-2.19.so
7fa462ad0000-7fa462ccf000 ---p 00003000 08:01 137668                     /lib/x86_64-linux-gnu/libdl-2.19.so
7fa462ccf000-7fa462cd0000 r--p 00002000 08:01 137668                     /lib/x86_64-linux-gnu/libdl-2.19.so
7fa462cd0000-7fa462cd1000 rw-p 00003000 08:01 137668                     /lib/x86_64-linux-gnu/libdl-2.19.so
7fa462cd1000-7fa462cea000 r-xp 00000000 08:01 137771                     /lib/x86_64-linux-gnu/libpthread-2.19.so
7fa462cea000-7fa462ee9000 ---p 00019000 08:01 137771                     /lib/x86_64-linux-gnu/libpthread-2.19.so
7fa462ee9000-7fa462eea000 r--p 00018000 08:01 137771                     /lib/x86_64-linux-gnu/libpthread-2.19.so
7fa462eea000-7fa462eeb000 rw-p 00019000 08:01 137771                     /lib/x86_64-linux-gnu/libpthread-2.19.so
7fa462eeb000-7fa462eef000 rw-p 00000000 00:00 0
7fa462eef000-7fa462f2c000 r-xp 00000000 08:01 137776                     /lib/x86_64-linux-gnu/libreadline.so.6.3
7fa462f2c000-7fa46312c000 ---p 0003d000 08:01 137776                     /lib/x86_64-linux-gnu/libreadline.so.6.3
7fa46312c000-7fa46312e000 r--p 0003d000 08:01 137776                     /lib/x86_64-linux-gnu/libreadline.so.6.3
7fa46312e000-7fa463134000 rw-p 0003f000 08:01 137776                     /lib/x86_64-linux-gnu/libreadline.so.6.3
7fa463134000-7fa463135000 rw-p 00000000 00:00 0
7fa463135000-7fa463158000 r-xp 00000000 08:01 137626                     /lib/x86_64-linux-gnu/ld-2.19.so
7fa46332b000-7fa46333c000 rw-p 00000000 00:00 0
7fa46334b000-7fa46334e000 rw-p 00000000 00:00 0
7fa46334e000-7fa463355000 r--s 00000000 08:01 266429                     /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
7fa463355000-7fa463357000 rw-p 00000000 00:00 0
7fa463357000-7fa463358000 r--p 00022000 08:01 137626                     /lib/x86_64-linux-gnu/ld-2.19.so
7fa463358000-7fa463359000 rw-p 00023000 08:01 137626                     /lib/x86_64-linux-gnu/ld-2.19.so
7fa463359000-7fa46335a000 rw-p 00000000 00:00 0
7fff18cfe000-7fff18d1f000 rw-p 00000000 00:00 0                          [stack]
7fff18dc1000-7fff18dc3000 r-xp 00000000 00:00 0                          [vdso]
7fff18dc3000-7fff18dc5000 r--p 00000000 00:00 0                          [vvar]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

Version info for downloaded releases not generated

Now that we have github versioning, all versions will be automatically available for download as zip. These zip-files contain the source for manual building, but this means that users will start compiling without git-integration.
Thus, the builds will not contain version info..

How to solve?

• Some kind of hooks on version-tag-commits to automatically place version number in a file?

We probably need version info in some kind of static resource, question is how we generate that resource and when.

Issues with the parity calculations on ISO 14443 tags

Currently the proxmark firmware is limited to sending a max of 32 byte ISO 14443 tags due to issues with the parity generation. Naturally this limit is not readily apparent as no indication of this limit is provided.
Possibly we should put in a warning when attempting to read/emulate large tags.
This is due to the parity calculations for packets being performed using a uint32_t variable as a shift register. This affects a large portion of the code base for the ISO14443 support.

I've implemented fixes in an old version of the proxmark3 code - but will need to port it to the latest release for it to work.

Additionally we should also consider moving the modulation/demodulation code into the FPGA if possible. The current limits with RAM in the hardware makes emulating tags of >64 bytes impossible - as tag emulation requires taking the raw bit stream and expanding it to the required modulation in RAM.
If the modulation/demodulation code is moved to the FPGA then RAM would be conserved allowing bigger tags to be modulated.

Provide OS X instructions to use brew (instead of macports)

Hey! Got it working using brew.sh for OS X, would it be of interest for me to document and do a PR with additional instructions for the wiki?

Suggestion: identify "weak" mifare classic tags

This is not an issue, its a enhancement suggestion (?)
I started a thread on the forum about this idea.
http://www.proxmark.org/forum/viewtopic.php?pid=15426#p15426

Missing file?

Hello

I tried to compile commit 188b2db from 2/26/15. I am getting errors due to a missing file. optimized_cipher.h
Is this file somewhere else in the project or on the internet?

Iclass tag simulation, wrong modulation frequency

See info on here about the issue. Wrong frequency (doubled) when doing iso 15693 tag simulation. Affecting at least iclass, possibly other simulation modes.

Experiencing many collissions / failed reads after latest changes to fpga-code.

Since the latest fpga changes, my HF commands is hardly working anymore. Collisions and failed reads 95% of the time.

Trying to pinpoint it, I have tested an old bit-file from january 2015. With it, my HF commands works as expected.

Does someone have some suggestions on what this might be?

https://github.com/Proxmark/proxmark3/blob/master/fpga/fpga_hf.bit

Reworking how the graphing functions

I am currently rewriting the graph framework. I want to provide a better UI for experimenting with signals.

Here's how it looks right now:

What you can't see here, is that if you pull the slider to the left (increasing 'window'), the red graph updates in real time. The same thing with dir threshold:

Once you're happy with the settings, you can press apply, and the red signal is copied into the main signal buffer (graphbuffer):

This does not really affect the console-commands, they work as usual. I've had to restructure them a bit though; e.g. dirthreshold and autocorr look like this:

int CmdDirectionalThreshold(const char *Cmd)
{
    int8_t upThres = param_get8(Cmd, 0);
    int8_t downThres = param_get8(Cmd, 1);

    printf("Applying Up Threshold: %d, Down Threshold: %d\n", upThres, downThres);

    directionalThreshold(GraphBuffer, GraphBuffer,GraphTraceLen, upThres, downThres);
    RepaintGraphWindow();
    return 0;
}

That is, they parse the commands, then call an "api"-function which does the actual data operation. These data-operations all have the signature (const int* in, const int*out, size_t len, ... parameters..). That is, they take one read-buffer and one write-buffer. In the console-case, in and out are the same.

I think there are probably a few more things which could fit into this (changes from analog -> analog which depends on parameters which the user may want to fiddle with).
So that's for analog signals -> analog signals.

I have some thoughts on also doing another UI for functions which map analog->digital, i.e; decoders. The UI would show the digital out, represented both in bitstream-form, and hex-form (in four ways, shifted one bit each), and perhaps ascii form. Perhaps highlighting potential parity bits. And then the user could slide stuff like clock or starting point or whatever, and in real time see what makes the most sense.

This is still work in progress, but if anyone wants to tag along, feel free.

And I do think we're approaching a major version number increase soon.

reading KeyB in hf mf nested/mifare ?

It's not an issue, but an suggestion. Someone can edit this issue and give it the right label.

According to Adam Laurie, AdamLaurie/mfoc@5d8bf95

He suggested in the MFOC to use a found KeyA to try read KeyB from the sectortrailer.

hf list 14a

Holimans new "hf list 14a", has a minor bug where it falsely identifies rows starting with a ISO_command value when it is not a ISO_command.

See the sample below for better understanding. the "DEC(50)" is wrong.

---

2658220 | 2668684 | Rdr | 93 70 46 b8 77 b1 38 c2 35 | | ANTICOLL
2669936 | 2673520 | Tag | 01 77 40 | |
2688636 | 2693340 | Rdr | 60 01 7c 6a | | AUTH-A
2695360 | 2700096 | Tag | c0 f5 a6 a1 | |
2700924 | 2710236 | Rdr | 9d f6 ff 85 c0 d0 dc 92 | !crc| ?
2711488 | 2716160 | Tag | 5a 67 44! ed | |
2723036 | 2727804 | Rdr | c1 32 54 08 | !crc| DEC(50)
2729104 | 2749904 | Tag | 16! 09! 3d! 5a 19! fc e8! e2! 6f 88! 66! db! 25 05! 82! a6! | |
| | | 57 5e! | !crc|

"make" is broken

arm-none-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=c99 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO14443a -DWITH_ISO14443b -DWITH_ICLASS -DWITH_LEGICRF -DWITH_HITAG -I. -Os -mthumb-interwork -o obj/crapto1.o crapto1.c 
crapto1.c: In function 'quicksort':
crapto1.c:47:8: error: operation on '*it' may be undefined [-Werror=sequence-point]
    *it ^= (*it ^= *rit, *rit ^= *it);
        ^
crapto1.c:52:8: error: operation on '*rit' may be undefined [-Werror=sequence-point]
   *rit ^= (*rit ^= *start, *start ^= *rit);
        ^
crapto1.c: In function 'lfsr_rollback_bit':
crapto1.c:324:9: error: operation on 's->odd' may be undefined [-Werror=sequence-point]
  s->odd ^= (s->odd ^= s->even, s->even ^= s->odd);
         ^
cc1: all warnings being treated as errors

Sorry for not looking into that myself. Maybe one of you already know how to fix it. Or maybe I will have some time next week to look into it.

LF t55xx read commands broken

I was fiddling around in the LF t55xx commands and was always suprised with not getting some values outputted with issuing a "lf t55xx readblock 1"..
At least it should have given more then the "db: done" message.

I looked into the code in "cmdlft55x.c" and realized that all functions only calls "sendcommand" but never waits for a response.
I looked into the lfops.c in the ARMSRC, and sure enough, the read values is never sent back to the client.

LF T55xx read commands are flawed.

hf mf eload, esave, cload, save - filepath variabel too short

Original issue from Asper, only mention on the forum. http://www.proxmark.org/forum/viewtopic.php?id=1612

DESCRIPTION:
Working on the Graphical User Interface for Windows, I found a bug that affect "hf mf eload", "esave", "csave" and "cload" commands.

The bug consist in: the above SAVE commands are not able to find long paths to files (seems 14 characters is the maximum lenght) while LOAD commands are able to find files ONLY in client folder (short paths also seem not to be supported).

Other load/save functions (ex. legic or data) work perfectly.

---

LATE Answer:

in cmdhfmf.c - CmdHF14AMfELoad(const char *Cmd)

char filename[20];

....
....

len = strlen(Cmd);
if (len > 14) len = 14;

The command string is shortend to 14chars, so that is consistent with what you see.
The reserved space is 20, which is also small.

---

SOLUTION:

The codebase would become better if there was a uniform way for the length of filepaths,
I suggest adding a constant to data.h, #define FILEPATH_SIZE 1000
and make the needed changes in the code.

I did first a simple change in my fork, but remade one with a constant and some checks in the code. I will push it to my fork and see if it good enough.

Erros while trying to falsh my proxmark

Hi,
I have some trouble flashing my proxmark.

My proxmark setup:

proxmark3> hw version
#db# Prox/RFID mark3 RFID instrument                 
#db# bootrom: master/v1.0.0-13-ge17437f-suspect 2014-06-26 11:25:03                 
#db# os: master/v1.0.0-13-ge17437f-suspect 2014-06-26 11:25:04                 
#db# HF FPGA image built on 2014/ 6/19 at 21:26: 2                 
uC: AT91SAM7S512 Rev A          
Embedded Processor: ARM7TDMI          
Nonvolatile Program Memory Size: 512K bytes          
Second Nonvolatile Program Memory Size: None          
Internal SRAM Size: 64K bytes          
Architecture Identifier: AT91SAM7Sxx Series          
Nonvolatile Program Memory Type: Embedded Flash Memory   

My system setup:
Linux (64 Bit)

arm-none-eabi-gcc --version
arm-none-eabi-gcc (devkitARM release 43) 4.9.2

There are different errors and I can't really reproduce them exactly.

./client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf
Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x0001497e->0x0001497e) [R  ] @0xb4
1: V 0x00118000 P 0x00118000 (0x000186f9->0x000186f9) [R X] @0x14a38
2: V 0x00200000 P 0x001306f9 (0x000029f8->0x000029f8) [RWX] @0x2d138
Note: Extending previous segment from 0x186f9 to 0x1b0f1 bytes

Waiting for Proxmark to appear on /dev/ttyACM0...... Found.
Error: Unknown Proxmark mode

or

./client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf
Loading ELF file 'armsrc/obj/fullimage.elf'...
Loading usable ELF segments:
0: V 0x00102000 P 0x00102000 (0x0001497e->0x0001497e) [R  ] @0xb4
1: V 0x00118000 P 0x00118000 (0x000186f9->0x000186f9) [R X] @0x14a38
2: V 0x00200000 P 0x001306f9 (0x000029f8->0x000029f8) [RWX] @0x2d138
Note: Extending previous segment from 0x186f9 to 0x1b0f1 bytes

Waiting for Proxmark to appear on /dev/ttyACM0. Found.
Error: Unknown Proxmark mode
*** stack smashing detected ***: ./client/flasher terminated
[1]    8577 abort (core dumped)  ./client/flasher /dev/ttyACM0 armsrc/obj/fullimage.elf

or

./client/flasher /dev/ttyACM0 -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 (0x00000b30->0x00000b30) [RWX] @0x298

Waiting for Proxmark to appear on /dev/ttyACM0........................ Found.
Error: Unknown Proxmark mode
*** stack smashing detected ***: ./client/flasher terminated
[1]    8304 abort (core dumped)  ./client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf

or

./client/flasher /dev/ttyACM0 -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 (0x00000b30->0x00000b30) [RWX] @0x298

Waiting for Proxmark to appear on /dev/ttyACM0. Found.
Entering bootloader...
(Press and release the button only to abort)
Waiting for Proxmark to reappear on /dev/ttyACM0............... Found.
Note: Your bootloader does not understand the new START_FLASH command
      It is recommended that you update your bootloader

*** stack smashing detected ***: ./client/flasher terminated
[1]    8362 abort (core dumped)  ./client/flasher /dev/ttyACM0 -b bootrom/obj/bootrom.elf

Am I doing something wrong?
Whats up with the "stack smashing detected"? Is there something wrong with the code?

Thanks for any help!

HF 14a READ identify Ultralight/Ultralight-C/Ultralight EV1

I made a minor fix to the "hf 14a read" command to correctly identify between the different Ultralight tags.

---snipp--
pm3 --> hf 14a read
ATQA : 00 44
UID : 04 b7 80 9a f8 38 80
SAK : 00 [2]
MANUFACTURER : NXP Semiconductors Germany
TYPE : NXP MIFARE Ultralight EV1 48 bytes
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO

pm3 --> hf 14a read
ATQA : 00 44
UID : 01 02 03 04 05 06 07
SAK : 00 [2]
MANUFACTURER : Motorola UK
TYPE : NXP MIFARE Ultralight | Ultralight C
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO

HID Prox Standalone Mode is Broken

I've noticed that in the last few builds the standalone mode is broken. I've gone back and recompiled every version back to the merge from 9/19 (92d255d) and have found that that is the last known-good version of the code that functions correctly. The merge from 10/24 breaks it.

Thoughts on what's happening?

Compiling error on OSX. Missing readline

My environment:
Mac OS 10.10
readline 6.3.8 installed from brew located at /usr/local/Cellar/readline/6.3.8

gcc -std=c99 -I. -I../include -I../common -I/opt/local/include -I../liblua -I/usr/local/Cellar/readline/6.3.6/include/ -Wall  -g -O4 -DHAVE_GUI -c -o obj/ui.o ui.c
clang: warning: -O4 is equivalent to -O3
ui.c:48:19: error: use of undeclared identifier 'rl_readline_state'
        int need_hack = (rl_readline_state & RL_STATE_READCMD) > 0;
                         ^
ui.c:48:39: error: use of undeclared identifier 'RL_STATE_READCMD'
        int need_hack = (rl_readline_state & RL_STATE_READCMD) > 0;
                                             ^
ui.c:52:16: warning: implicit declaration of function 'rl_copy_text' is invalid in C99 [-Wimplicit-function-declaration]
                saved_line = rl_copy_text(0, rl_end);
                             ^
ui.c:52:14: warning: incompatible integer to pointer conversion assigning to 'char *' from 'int' [-Wint-conversion]
                saved_line = rl_copy_text(0, rl_end);
                           ^ ~~~~~~~~~~~~~~~~~~~~~~~
ui.c:53:3: warning: implicit declaration of function 'rl_save_prompt' is invalid in C99 [-Wimplicit-function-declaration]
                rl_save_prompt();
                ^
ui.c:54:3: warning: implicit declaration of function 'rl_replace_line' is invalid in C99 [-Wimplicit-function-declaration]
                rl_replace_line("", 0);
                ^
ui.c:66:3: warning: implicit declaration of function 'rl_restore_prompt' is invalid in C99 [-Wimplicit-function-declaration]
                rl_restore_prompt();
                ^
5 warnings and 2 errors generated.
make[1]: *** [obj/ui.o] Error 1
make: *** [client/all] Error 2

I fix this error by adding readline path to proxmark3/client/Makefile

LDLIBS = -L/usr/local/Cellar/readline/6.3.8/lib/ -L/opt/local/lib -L/usr/local/lib ../liblua/liblua.a -lreadline -lpthread -lm
CFLAGS = -std=c99 -I. -I../include -I../common -I/opt/local/include -I../liblua -I/usr/local/Cellar/readline/6.3.8/include/ -Wall $(COMMON_FLAGS) -g -O4

hf mf esave - always saves 4K

Decription:

The "hf mf esave" always saves as 4k ( 32_4 + 8_16)
Which could cause some confusion or ruin your dumps...

cmdhfmf.c
in iCmdHF14AMfESave(const char *Cmd)

// put hex
for (i = 0; i < 32*4 + 8*16; i++) {
    if (mfEmlGetMem(buf, i, 1)) {
        PrintAndLog("Cant get block: %d", i);
        break;
    }
    for (j = 0; j < 16; j++)
        fprintf(f, "%02x", buf[j]); 
    fprintf(f,"\n");
}

Possible FPGA issue

I recently rebuilt the FPGA, and got the warnings below. From what I could tell, these warnings were not there before the izsh-changes. I don't know what to make of it, so I'll just put it here and see if anyone else has any ideas - is this something we need to fix?

WARNING:Par:283 - There are 2 loadless signals in this design. This design will
cause Bitgen to issue DRC warnings.

Total REAL time to PAR completion: 2 secs
Total CPU time to PAR completion: 2 secs

Peak Memory Usage:  94 MB

Placement: Completed - No errors found.
Routing: Completed - No errors found.
Timing: Completed - No errors found.

Number of error messages: 0
Number of warning messages: 4
Number of info messages: 0

Writing design to file fpga_hf-placed.ncd



PAR done!
Release 10.1 - Bitgen K.31 (nt)
Copyright (c) 1995-2008 Xilinx, Inc.  All rights reserved.
Loading device for application Rf_Device from file '2s30.nph' in environment
C:\Xilinx\10.1\ISE.
   "fpga_hf" is an NCD, version 3.2, device xc2s30, package vq100, speed -6

Tue Dec 09 08:41:28 2014

Running DRC.
WARNING:PhysDesignRules:367 - The signal <pck0_IBUF> is incomplete. The signal
   does not drive any load pins in the design.
WARNING:PhysDesignRules:367 - The signal <cross_lo_IBUF> is incomplete. The
   signal does not drive any load pins in the design.
DRC detected 0 errors and 2 warnings.  Please see the previously displayed
individual error or warning messages for more details.

Minor bug in scripting.c regarding AES

Minor bug in scripting.c

https://github.com/Proxmark/proxmark3/blob/master/client/scripting.c#L264

@holiman 's changes from OpenSSL -> PolarSSL introduced a minor bug,

-- the offending line is:
aes_setkey_enc(&ctx, (const unsigned char *)aes_key, 128);

-- should be:
aes_setkey_dec(&ctx, aes_key, 128);

Missing file while compiling

ERROR:
cmdlf.c:30:21: error: cmdlfio.h: No such file or directory
cmdlf.c:536: error: 'CmdLFIO' undeclared here (not in a function)

CAUSE:
result of a merge (pull request from PenturaLabs).

hf list 14a - shows always parity error for all bytes.

I tried the latest sourcecode and the "hf list 14a" always gives me a "!" (ie: parity error) for every byte listed. I tried a couple of different tags, its the same for those tags aswell.

 Start |       End | Src | Data (! denotes parity error)                                   | CRC | Annotation         |

-----------|-----------|-----|-----------------------------------------------------------------|-----|--------------------|

     0 |       992 | Rdr | 52!                                                             |     | WUPA
  2228 |      4596 | Tag | 44! 00!                                                         |     |
  7040 |      9504 | Rdr | 93! 20!                                                         |     | ANTICOLL
 10676 |     16500 | Tag | 88! 04! 8f! 48! 4b!                                             |     |
 18688 |     29216 | Rdr | 93! 70! 88! 04! 8f! 48! 4b! 5f! 49!                             |     | SELECT_UID
 30388 |     33908 | Tag | 04! da! 17!                                                     |     |
 35200 |     37664 | Rdr | 95! 20!                                                         |     | ANTICOLL-2
 38836 |     44724 | Tag | 9a! f8! 38! 80! da!                                             |     |
 46848 |     57312 | Rdr | 95! 70! 9a! f8! 38! 80! da! 68! d4!                             |     | ANTICOLL-2
 58548 |     62132 | Tag | 00! fe! 51!                                                     |     |
 65664 |     70432 | Rdr | 30! 00! 02! a8!                                                 |     | READBLOCK(0)
 71604 |     92404 | Tag | 04! 8f! 48! 4b! 9a! f8! 38! 80! da! 48! 00! 00! 00! 00! 00! 00! |     |
       |           |     | 28! c9!                                                         |     |
105088 |    109856 | Rdr | 50! 00! 57! cd!                                                 |     | HALT

---

pm3 --> hw ver

db# Prox/RFID mark3 RFID instrument

db# bootrom: /-suspect 2015-01-28 19:34:43

db# os: /-suspect 2015-02-10 20:54:12

db# HF FPGA image built on 2015/01/15 at 12:19:06

bug in 14443a anti-collision code

When a collision occurs while operating via the command "hf 14a read" or a couple of other code paths, the iso14443a_select_card() function enters the following code path (cleaned up for line wraps/etc):

if (Demod.collisionPos) {           
    memset(uid_resp, 0, 4);
    uint16_t uid_resp_bits = 0;
    uint16_t collision_answer_offset = 0;
    // anti-collision-loop:
    while (Demod.collisionPos) {
        Dbprintf("Multiple tags detected. Collision after Bit %d", Demod.collisionPos);
        for (uint16_t i = collision_answer_offset; i < Demod.collisionPos; i++, uid_resp_bits++) {  
            uint16_t UIDbit = (resp[i/8] >> (i % 8)) & 0x01;
            uid_resp[uid_resp_bits & 0xf8] |= UIDbit << (uid_resp_bits % 8);
        }
        uid_resp[uid_resp_bits/8] |= 1 << (uid_resp_bits % 8);                  
        uid_resp_bits++;
        // construct anticollosion command:
        sel_uid[1] = ((2 + uid_resp_bits/8) << 4) | (uid_resp_bits & 0x07);     
        for (uint16_t i = 0; i <= uid_resp_bits/8; i++) {
            sel_uid[2+i] = uid_resp[i];
        }
        collision_answer_offset = uid_resp_bits%8;
        ReaderTransmitBits(sel_uid, 16 + uid_resp_bits, NULL);
        if (!ReaderReceiveOffset(resp, collision_answer_offset)) return 0;
    }
    // finally, add the last bits and BCC of the UID
    for (uint16_t i = collision_answer_offset; i < (Demod.len-1)*8; i++, uid_resp_bits++) {
        uint16_t UIDbit = (resp[i/8] >> (i%8)) & 0x01;
        uid_resp[uid_resp_bits/8] |= UIDbit << (uid_resp_bits % 8);
    }

} else { [...]

This results in an invalid response from the proxmark, for instance, consider:
two cards with UIDs of 0x04 0x62 0x1f 0x1a 0x94 0x35 0x80 and 0x04 0x42 0x23 0xd2 0x0b 0x35 0x80 respectively, and a collision occurs at bit 21, eliciting the following response: 0x88 0x04 0x62 0x3f 0xfd, then the proxmark responds with: 0x93 0x46 0x88 0x00 0x20 which is incorrect.

The correct response is : 0x93 0x46 0x88 0x04 0x22

This is due to the line:

uid_resp[uid_resp_bits & 0xf8] |= UIDbit << (uid_resp_bits % 8);

Which not only results in an invalid response, but also corrupts stack memory (id est with a collision at bit 21 we will eventually write to uid_resp[16], which is actually 4 bytes in length).This can be fixed by modifying the line to read as follows:

uid_resp[i / 8] |= UIDbit << (i % 8);

With this line changed, instead of hanging after the debug output informing us of the collision due to the UID not corresponding to the cards UID, we successfully complete the transaction:

Possible versioning issue

I think there may be a problem with my versioning-fix. I changed the size of version_info-struct, in order to fit more info in there. At the time, I didn't think it would be a problem, but it struck me later that if someone flashes the pm3 with "github-version", and then uses a "svn-version" of the client and does "hw version" or vice versa, there will probably be problems.

I don't know the best way to fix that.

• Crop git info more, to fit within 9 characters?
• Change versioning magic-number, so old clients and new clients are officially incompatible?

HF 15 Sim doesn't work

{"sim", CmdHF15Sim, 0, "Fake an ISO15693 tag"},

But

// Simulation is still not working very good
int CmdHF15Sim(const char *Cmd)
{
        UsbCommand c = {CMD_SIMTAG_ISO_15693, {strtol(Cmd, NULL, 0), 0, 0}};
        SendCommand(&c);
        return 0;
}

I get weird results, like it'll out put something like the following (3 different runs):

1K08080000*
4K04000400*
4K00100010*

Compile error on Archlinux

Hi
Im getting following compile error. Tested on fully updated archlinux. Any suggestions on how to fix this properly? thanks

arm-none-eabi-gcc -c -I../include -I../common -Wall -Werror -pedantic -std=c99 -DWITH_LF -DWITH_ISO15693 -DWITH_ISO14443a -DWITH_ISO14443b -DWITH_ICLASS -DWITH_LEGICRF -DWITH_HITAG  -DWITH_CRC -DON_DEVICE -fno-strict-aliasing -ffunction-sections -fdata-sections -I. -Os -mthumb-interwork -o obj/optimized_cipher.o optimized_cipher.c 
In file included from /usr/arm-none-eabi/include/sys/types.h:62:0,
                 from /usr/arm-none-eabi/include/stdio.h:48,
                 from optimized_cipher.c:64:
/usr/arm-none-eabi/include/sys/_stdint.h:31:19: error: conflicting types for 'int32_t'
 typedef __int32_t int32_t ;
                   ^
In file included from optimized_cipher.h:3:0,
                 from optimized_cipher.c:63:
./stdint.h:16:18: note: previous declaration of 'int32_t' was here
 typedef int      int32_t;
                  ^
In file included from /usr/arm-none-eabi/include/sys/types.h:62:0,
                 from /usr/arm-none-eabi/include/stdio.h:48,
                 from optimized_cipher.c:64:
/usr/arm-none-eabi/include/sys/_stdint.h:32:20: error: conflicting types for 'uint32_t'
 typedef __uint32_t uint32_t ;
                    ^
In file included from optimized_cipher.h:3:0,
                 from optimized_cipher.c:63:
./stdint.h:21:24: note: previous declaration of 'uint32_t' was here
 typedef unsigned int   uint32_t;
                        ^
../common/Makefile.common:83: recipe for target 'obj/optimized_cipher.o' failed
make[1]: *** [obj/optimized_cipher.o] Error 1
make[1]: Leaving directory '/tmp/proxmark3/armsrc'
Makefile:11: recipe for target 'armsrc/all' failed
make: *** [armsrc/all] Error 2

: obj/fullimage.elf section `.data' will not fit in region `osimage'

Noooo, but I guess it was only a matter of time. When I add my desfire stuff into the armsrc, the fullimage image size gets too big and overflows into the osimage area.

Does someone know how this works? Is it in the makefiles (common?) or the bootrom?

-------------SNIPPET ERROR MESSAGE
arm-none-eabi-gcc -nostartfiles -nodefaultlibs -Wl,-gc-sections -n -Wl,-T,ldscript,-Map,obj/fullimage.map -o obj/fullimage.elf obj
/version.o obj/fpga_lf.o obj/fpga_hf.o obj/start.o obj/iso15693.o obj/iso15693tools.o obj/lfops.o obj/hitag2.o obj/lfsampling.o ob
j/appmain.o obj/printf.o obj/util.o obj/string.o obj/usb_cdc.o obj/cmd.o obj/fpgaloader.o obj/legicrf.o obj/lfdemod.o obj/epa.o ob
j/iso14443a.o obj/mifareutil.o obj/mifarecmd.o obj/mifaresniff.o obj/iso14443.o obj/crapto1.o obj/crypto1.o obj/des.o obj/aes.o ob
j/desfire_key.o obj/desfire_crypto.o obj/mifaredesfire.o obj/iso14443crc.o obj/crc.o obj/crc16.o obj/crc32.o obj/legic_prng.o obj/
iclass.o obj/BigBuf.o obj/optimized_cipher.o -lgcc
c:/projects/proxmark3/proxspace-130613/proxspace/devkitarm/bin/../lib/gcc/arm-none-eabi/4.7.1/../../../../arm-none-eabi/bin/ld.exe
: obj/fullimage.elf section .data' will not fit in regionosimage'
c:/projects/proxmark3/proxspace-130613/proxspace/devkitarm/bin/../lib/gcc/arm-none-eabi/4.7.1/../../../../arm-none-eabi/bin/ld.exe
: region `osimage' overflowed by 936 bytes
collect2.exe: error: ld returned 1 exit status
make: *** [obj/fullimage.elf] Error 1

hf mf restore - always uses a fixed key.

I was reading on the old Google code issues list and this one triggers some ideas.
As it is now, the "hf mf restore" uses the default key A 0xffffffffffff to write to the tag.
If the tag doesn't have this set then the restore command fails.

https://code.google.com/p/proxmark3/issues/detail?id=37

I don't know how many uses the this command anymore but a choice to use the default key or use the keys from the keydump instead might be useful.

UsbCommand c = {CMD_MIFARE_WRITEBL, {FirstBlockOfSector(sectorNo) + blockNo, keyType, 0}};
memcpy(c.d.asBytes, key, 6);

the suggested fix on the google code is another hardcoded solution, but I think an inparameter solution would be nicer.

PrintAndLog("Usage:   hf mf restore [card memory]");
PrintAndLog("  [card memory]: 0 = 320 bytes (Mifare Mini), 1 = 1K (default), 2 = 2K, 4 = 4K");

      |

PrintAndLog("Usage: hf mf restore [card memory] -u <A|B> ");
PrintAndLog(" [card memory] : 0 = 320 bytes (Mifare Mini), 1 = 1K (default), 2 = 2K, 4 = 4K");
PrintAndLog(" -u : use keys from dumpkeys.bin file when writing to tg");
PrintAndLog(" <A|B> : use following keytype and key when writing to tag");

Proxmark log enhancements

It would be cool to have a time-stamp next to each line in the proxmark.log

Also, it seems that the log only shows the result of a command. The command itself that was issued before the result does not appear in the log.

It would give something like that:

12/04/2015 - 12:00PM: lf hid fskdemod
12/04/2015 - 12:01PM: #db# TAG ID: 2004F66073 (12345)

PM3 "broken" after bootrom update

Hi,

I just updated my bootrom due to 7cc204b commit.

$ ./client/flasher /dev/ttyACM0 -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 (0x00000b60->0x00000b60) [RWX] @0x298

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

Flashing...
Writing segments for file: bootrom/obj/bootrom.elf
 0x00100000..0x001001ff [0x200 / 1 blocks]. OK
 0x00100200..0x00100d5f [0xb60 / 6 blocks]...... OK

Resetting hardware...
All done.

Have a nice day!

But after that the red LED is turned on and the PM3 resets (the relay clicks) every X seconds. :-(
... And of course the /dev/ttyACM0 device is not showing up anymore.

Have I done something wrong? How can I get my PM3 back? JTAG?