search

RfidResearchGroup / proxmark3

Iceman Fork - Proxmark3
http://www.icedev.se
GNU General Public License v3.0
3.72k stars 999 forks source link

lf em 4x05_dump password not working #1021

Closed will-caruana closed 3 years ago

will-caruana commented 3 years ago

Describe the bug The password is not being used to dump the card tested with --pwd and -p

To Reproduce lf em 4x05_dump --pwd 50524F58

Expected behavior The password would be passed and card would be dumped.

Screenshots lf em 4x05_dump --pwd 50524F58 lf em dump: invalid argument "50524F58" to option -p|--pwd [!] ⚠ Try 'lf em dump --help' for more information.

Desktop (please complete the following information): [usb] pm3 --> hw version

[ Proxmark3 RFID instrument ]

[ CLIENT ] client: RRG/Iceman/master/v4.9237-1797-g378f5fae 2020-10-19 19:50:10 compiled with GCC 9.3.0 OS:Linux ARCH:x86_64

[ PROXMARK3 ] firmware.................. PM3RDV4 external flash............ present smartcard reader.......... present FPC USART for BT add-on... present

[ ARM ] bootrom: RRG/Iceman/master/v4.9237-1797-g378f5fae 2020-10-19 19:50:30 os: RRG/Iceman/master/v4.9237-1797-g378f5fae 2020-10-19 19:50:42 compiled with GCC 8.3.1 20190703 (release) [gcc-8-branch revision 273027]

[ FPGA ] LF image built for 2s30vq100 on 2020-07-08 at 23: 8: 7 HF image built for 2s30vq100 on 2020-07-08 at 23: 8:19 HF FeliCa image built for 2s30vq100 on 2020-07-08 at 23: 8:30

[ Hardware ] --= uC: AT91SAM7S512 Rev A --= Embedded Processor: ARM7TDMI --= Nonvolatile Program Memory Size: 512K bytes, Used: 295944 bytes (56%) Free: 228344 bytes (44%) --= Second Nonvolatile Program Memory Size: None --= Internal SRAM Size: 64K bytes --= Architecture Identifier: AT91SAM7Sxx Series

mwalker33 commented 3 years ago

Try the password hex with the leading 0x as per the help and report back. e.g. lf em 4x05_dump --pwd 0x50524F58

iceman1001 commented 3 years ago

one issue is that the examples say "w/o 0x" and the "-p" say with.. anyway, the idea of using u64 as arg is kind of useless if we need to have 0x prefix. The "-p" would need a hexstring instead.

doegox commented 3 years ago

Indeed I found and fixed the wrong example today without noticing this issue, but I agree with iceman, we should have a way to parse hex directly. Maybe not arg_u64 but something dedicated, arg_u64hex?

iceman1001 commented 3 years ago

we have arg_str0 where we call hextobuffer.. but the problem is we get a hex array, -p 01020304 -> {01 02 03 04} and if we convert that one we get 04030201 value....

The idea of arg_u64hex is a good one

will-caruana commented 3 years ago

Just did a git pull and this seems to have been fixed thank you!