I recently updated to the latest version of the Iceman PM3 fork and tried to update my PM3 using MacOS. I get the following error:
[+] Waiting for Proxmark3 to appear on /dev/tty.usbmodemiceman1
? 59 found
[=] Available memory on this board: 512K bytes
[=] Permitted flash range: 0x00102000-0x00180000
[+] Loading usable ELF segments:
[+] 0: V 0x00102000 P 0x00102000 (0x0004b51c->0x0004b51c) [R X] @0x98
[+] 1: V 0x00200000 P 0x0014d51c (0x00001c94->0x00001c94) [R X] @0x4b5b8
[=] Note: Extending previous segment from 0x4b51c to 0x4d1b0 bytes
[+] Flashing...
[+] Writing segments for file: fullimage.elf
[+] 0x00102000..0x0014f1af [0x4d1b0 / 617 blocks]
................[!!] ? Error: Unexpected reply 0x00fe NACK (expected ACK)
Lock Error
Lock Bits: 0x3352
[!!] ? Error writing block 16 of 617
[!] ⚠️ The flashing procedure failed, follow the suggested steps!
[+] All done
[=] Have a nice day!
Any idea how to recover from this? I couldn't find any information about how or why lock bits are being set on the device. I tried downloading and flashing a precompiled build. That wouldn't work automatically; I had to use --force to get the bootloader on there and when I try to flash the full image, I run into the lock bits error again.
Am I missing something simple here?
]]>While clones are common for things like Bluetooth modules, usually the clones work at least close to similarly. This one does not. I turned on the usart debugging:
PLATFORM_EXTRAS=BTADDON FPC_USART_DEV
recompiled, reflashed, and did some tests. It seems to respond differently to the initialization commands:
[usb] pm3 --> usart txrx -d "AT+VERSION"
[+] TX ( 10):AT+VERSION
[+] RX ( 13):BT SPP V3.0
[usb] pm3 --> usart txrx -d "AT+NAMEPM3_RDV4.0"
[+] TX ( 17):AT+NAMEPM3_RDV4.0
[+] RX ( 8):OKname
[usb] pm3 --> usart txrx -d "AT+ROLE=S"
[+] TX ( 9):AT+ROLE=S
[+] RX ( 9):OKSlave
The module I was shipped seems to not have been tested, as usart commands to initialize it properly didn't execute fully. The advertised name was:
PM3_RDV4.0AT+ROLE=S
I was able to execute the appropriate commands to get it initialized (see above), but I suspect that y'all may want to know that there are some misbehaving clones out there in the inventory. If there's other info about this unit that you need to figure out the supply chain issue, LMK. Hopefully if someone else comes across a misconfigured module this post could be helpful as well.
]]>This took me few months to figure it out and I solved it by mistake. I'm developing proxmark3 firmware using VirtualBox + VSCode/SSH and since always I had awful problems with flashing my device.
Proxmark was always properly rebooted into bootloader over USB but in the bootloader mode it was impossible to connect device back to Virtualbox (hypervisor was throwing errors).
Turned out everything works perfectly fine if there is no other USB device connected to the same USB controller. I assume it may be some timing issue or other USB configuration in bootloader mode that messes up with controller.
Edit: if it does not work, what helps is to add VirtualBox USB filter for proxmark instead of manually enabling device access and connect proxmark to USB with entering bootloader using button.
]]>I noticed in Makefile.platform.sample (and now in my Makefile.platform file) there's a line to uncomment for the 256k size that says "SKIP_LF=1". Does this mean I can only work with HF cards? My primary interest is on LF cards.
I also read that if you add "PLATFORM_SIZE=256" the error message will tell you how close you are to 256KB.
I've already created a topic about 256k compiling: http://www.proxmark.org/forum/viewtopic.php?id=11069
I think you can disable everything except the LF and the result will fit.
Alternative is to find an older release or to buy a new proxmark (ten years... this a total legacy).
Apparently flashing the full recovery .bin wasn't working despite finally flashing properly, but flashing just the boot ROM got things going. After flashing the bootrom only, the board booted with 4 blue LEDs but only 2 red. Power cycled the board holding the button down & the pm3-flash-all.bat running in the background for the past hour or more immediately found a Proxmark & flashed it. Now only blue LEDs show up & there is a COM port in Device Manager.
Getting a device/firmware mismatch warning in the client now. But at least I'm to the point where its running & I can fiddle with things. http://www.proxmark.org/forum/viewtopic.php?id=9259 indicates this may not be an actual problem.
[ PROXMARK3 ]
device.................... device / fw mismatch
firmware.................. RDV4
external flash............ present
smartcard reader.......... present
FPC USART for BT add-on... absent
[ ARM ]
bootrom: Iceman/master/v4.14831-832-g96f977ed8 2022-07-27 11:16:15 fccdc4306
os: Iceman/master/v4.14831-832-g96f977ed8 2022-07-27 11:16:26 fccdc4306
compiled with GCC 10.1.0
Original issue:
I managed to brick my Proxmark 3 RDV4 shortly after getting it (probably flashing the wrong firmware, but it's been a while). I ended up grabbing a Segger J-Link & the Proxgrind adapter PCB dongle to fit the JTAG ports on the Proxmark. I had a pile of issues getting it working & put it on the shelf for a while. I finally got back to it. It took a few tries to get the J-link to connect, but it finally connected & claimed it flashed proxmark3_recovery.bin successfully. But when I cycle power on the Proxmark I get 4 red & 4 blue lights constantly on as soon as I plug it in. When it powers up Windows (Win 11) just complains that some unknown USB device is connected. No serial ports ever show up in device manager. I've ran the various pm3 batch files & they are all just "[=] Waiting for Proxmark3 to appear...". Powering up the Proxmark with the button pressed doesn't change how it boots.
I'm pulling files from https://www.proxmarkbuilds.org/fileviewer.html#rdv4/
I've gone through https://github.com/Proxmark/proxmark3/wiki/De-Bricking-Segger & https://github.com/Proxmark/proxmark3/wiki/flashing
SEGGER J-Link Commander V7.68c (Compiled Jul 28 2022 15:47:10)
DLL version V7.68c, compiled Jul 28 2022 15:45:26
Connecting to J-Link via USB...O.K.
Firmware: J-Link V10 compiled Jul 22 2022 11:40:29
Hardware version: V10.10
J-Link uptime (since boot): N/A (Not supported by this model)
S/N: 260117013
License(s): FlashBP, GDB
OEM: SEGGER-EDU
VTref=3.296V
Type "connect" to establish a target connection, '?' for help
J-Link>exec device = AT91SAM7S256
Device "AT91SAM7S256" selected.
J-Link>exec EnableFlashDL
J-Link>h
Target connection not established yet but required for command.
Please specify device / core. <Default>: AT91SAM7S256
Type '?' for selection dialog
Device>
Please specify target interface:
J) JTAG (Default)
TIF>
Device position in JTAG chain (IRPre,DRPre) <Default>: -1,-1 => Auto-detect
JTAGConf>
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "AT91SAM7S256" selected.
Connecting to target via JTAG
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x3F0F0F0F, IRLen: 04, ARM7TDMI Core
ARM7 identified.
PC: (R15) = 00000068, CPSR = 200000D7 (ABORT mode, ARM FIQ dis. IRQ dis.)
Current:
R0 =00100E84, R1 =00200C84, R2 =007E0E32, R3 =00200000
R4 =00000080, R5 =00000000, R6 =FFA5FFFF, R7 =00840000
R8 =80000200, R9 =10100000, R10=08020800, R11=00801002, R12=80000100
R13=20000000, R14=00200C08, SPSR=200000D3
USR: R8 =80000200, R9 =10100000, R10=08020800, R11=00801002, R12=80000100
R13=00000001, R14=10130000
FIQ: R8 =00000080, R9 =00002200, R10=80000030, R11=00000050, R12=00048008
R13=41020281, R14=00000200, SPSR=6000009F
IRQ: R13=00000002, R14=00020050, SPSR=30000010
SVC: R13=00300E84, R14=00200008, SPSR=200000D7
ABT: R13=20000000, R14=00200C08, SPSR=200000D3
UND: R13=00000000, R14=00000100, SPSR=F0000038
J-Link>loadbin "C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin" 0x100000
Downloading file [C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin]...
J-Link: Flash download: Bank 0 @ 0x00100000: 1 range affected (262144 bytes)
J-Link: Flash download: Total: 8.352s (Prepare: 0.408s, Compare: 0.442s, Erase: 0.000s, Program & Verify: 7.408s, Restore: 0.092s)
J-Link: Flash download: Program & Verify speed: 34 KB/s
O.K.
J-Link>loadbin "C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin" 0x100000
Halting CPU for downloading file.
Downloading file [C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin]...
J-Link: Flash download: Bank 0 @ 0x00100000: Skipped. Contents already match
O.K.
J-Link>erase
Without any given address range, Erase Chip will be executed
Erasing device...
J-Link: Flash download: Total time needed: 6.715s (Prepare: 0.145s, Compare: 0.000s, Erase: 6.478s, Program: 0.000s, Verify: 0.000s, Restore: 0.091s)
Erasing done.
J-Link>loadbin "C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin" 0x100000
Downloading file [C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin]...
J-Link: Flash download: Bank 0 @ 0x00100000: 1 range affected (262144 bytes)
J-Link: Flash download: Total: 5.128s (Prepare: 0.148s, Compare: 0.419s, Erase: 0.000s, Program & Verify: 4.468s, Restore: 0.092s)
J-Link: Flash download: Program & Verify speed: 57 KB/s
O.K.
J-Link>
J-Link>loadbin "C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin" 0x100000
Halting CPU for downloading file.
Downloading file [C:\Users\devin\Downloads\Proxmark\recovery\proxmark3_recovery.bin]...
J-Link: Flash download: Bank 0 @ 0x00100000: Skipped. Contents already match
O.K.
J-Link>
J-Link>loadbin "C:\Users\devin\Downloads\Proxmark\recovery\bootrom.bin" 0x100000
Downloading file [C:\Users\devin\Downloads\Proxmark\recovery\bootrom.bin]...
J-Link: Flash download: Bank 0 @ 0x00100000: 1 range affected (8192 bytes)
J-Link: Flash download: Total: 0.410s (Prepare: 0.084s, Compare: 0.035s, Erase: 0.000s, Program & Verify: 0.245s, Restore: 0.044s)
J-Link: Flash download: Program & Verify speed: 32 KB/s
O.K.
J-Link>
I got your article from git , https://github.com/RfidResearchGroup/proxmark3/pull/1146
I am observing the same issue . can you please little bit elaborate it . I would like to see how the data is moving from client to firmware . Can you please share the steps in chronological order.
]]>