hf mf sim esave sim issue

[idunnohmm]

If I run "hf mf sim u XXXXXXXX", "hf mf esave dump1", "hf mf sim u XXXXXXXX", "hf mf esave dump2" the first dump1.eml is correct but the second dump2.eml blocks are all shifted down one row. In dump2 the first block is all 0s and the rest are blocks 0-62, block 63 isn't written. I've been able to reproduce this pretty consistently.

[ dump1.eml sector 0 ] 3A25723F520804006263646566676869 00000000000000000000000000000000 00000000000000000000000000000000 FFFFFFFFFFFFFF078069FFFFFFFFFFFF [ dump1.eml sector 63 ] 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 FFFFFFFFFFFFFF078069FFFFFFFFFFFF

[ dump2.eml sector 0 (blocks 0-3) ] 00000000000000000000000000000000 3A25723F520804006263646566676869 00000000000000000000000000000000 00000000000000000000000000000000 [ dump2.eml sector 63 ] FFFFFFFFFFFFFF078069FFFFFFFFFFFF 00000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000

My environment for reference.

[ CLIENT ] client: iceman build for RDV40 with flashmem; smartcard;

[ ARM ] bootrom: iceman// 2018-09-11 09:39:19 os: iceman// 2018-09-11 09:39:31

[ FPGA ] LF image built for 2s30vq100 on 2017/10/25 at 19:50:50 HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23

[ Hardware ] --= uC: AT91SAM7S256 Rev D --= Embedded Processor: ARM7TDMI --= Nonvolatile Program Memory Size: 256K bytes, Used: 237342 bytes (91%) Free: 24802 bytes ( 9%) --= Second Nonvolatile Program Memory Size: None --= Internal SRAM Size: 64K bytes --= Architecture Identifier: AT91SAM7Sxx Series --= Nonvolatile Program Memory Type: Embedded Flash Memory

[iceman1001]

Pushed a change into the RRG repo. Lets see if this fixes your issue

https://github.com/RfidResearchGroup/proxmark3/commit/5c0517526a65be65962316b14b064fdcc7a391bb

[idunnohmm]

But my hardware is V3 as I don't have RDV40 and I'm using the official iceman1001 (this) repo. I noticed the [ ARM ] section for the RRG distro is this instead: [ ARM ] bootrom: iceman/master/ice_v3.1.0-1054-g018ab99c 2018-09-17 00:56:18 os: iceman/master/ice_v3.1.0-1054-g018ab99c 2018-09-17 00:56:40 Tried using the RRG client compiled with your latest commit and now the dumps are all blank! pm3 --> hf mf sim u FFFFFFFF hf mf sim u FFFFFFFF uid:FF FF FF FF , numreads:0, flags:2 (0x02) pm3 --> hf mf esave dump01 hf mf esave dump01 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-00000000-dump.bin [+] saved 64 blocks to text file hf-mf-00000000-dump.eml pm3 --> hf mf sim u FFFFFFFF hf mf sim u FFFFFFFF uid:FF FF FF FF , numreads:0, flags:2 (0x02) pm3 --> hf mf esave dump02 hf mf esave dump02 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-00000000-dump-1.bin [+] saved 64 blocks to text file hf-mf-00000000-dump-1.eml

After further testing this bug is intermittent and occurs randomly... sometimes it does save correctly other times it doesn't. UID has been masked below but the FFFFFFFF saves are correct while the 00000000 ones are all zeroes. At least I know when it saves successfully and ignores my numbering wishes. ;-/ pm3 --> hf mf esave dump06 hf mf esave dump06 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-00000000-dump-3.bin [+] saved 64 blocks to text file hf-mf-00000000-dump-3.eml pm3 --> hf mf esave dump07 hf mf esave dump07 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-FFFFFFFF-dump-2.bin [+] saved 64 blocks to text file hf-mf-FFFFFFFF-dump-2.eml pm3 --> hf mf sim u FFFFFFFF hf mf sim u FFFFFFFF uid:FF FF FF FF , numreads:0, flags:2 (0x02) pm3 --> hf mf esave dump08 hf mf esave dump08 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-00000000-dump-4.bin [+] saved 64 blocks to text file hf-mf-00000000-dump-4.eml pm3 --> hf mf esave dump09 hf mf esave dump09 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-FFFFFFFF-dump-3.bin [+] saved 64 blocks to text file hf-mf-FFFFFFFF-dump-3.eml pm3 --> hf mf esave dump10 hf mf esave dump10 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-FFFFFFFF-dump-4.bin [+] saved 64 blocks to text file hf-mf-FFFFFFFF-dump-4.eml

[iceman1001]

...first of all, don't mix between client/firmware from different repos / compilation times.

So compile / flash RRG repo and use the same client.

Next, I don't see you fill the emulator memory anywhere... I only see you are running sim command without a eload before. This will start a simulation with empty emulator memory. Which in the next step you are saving the same empty emulator memory.. Several times.

A proper way to test would be, like this, where I upload the content of a magic gen1a card up to emulator memory. Then save emulator memory, two times in arow. And compare two EML files to see. In this case all three files are the same (from csave, esave, esave) .

pm3 --> hf mf csave e 1
[+] Saving magic mifare 1K
[=] uploading to emulator memory
.............

[+] uploaded 1024 bytes to emulator memory
[+] saved 1024 bytes to binary file hf-mf-1AB33A09-dump.bin
[+] saved 64 blocks to text file hf-mf-1AB33A09-dump.eml
pm3 -->
pm3 --> hf mf esave 1
[=] dowingloading from emulator memory
[+] saved 1024 bytes to binary file hf-mf-1AB33A09-dump-1.bin
[+] saved 64 blocks to text file hf-mf-1AB33A09-dump-1.eml
pm3 -->
pm3 --> hf mf esave 1
[=] dowingloading from emulator memory
[+] saved 1024 bytes to binary file hf-mf-1AB33A09-dump-2.bin
[+] saved 64 blocks to text file hf-mf-1AB33A09-dump-2.eml
pm3 -->exit

m3 ~/client$ diff  hf-mf-1AB33A09-dump.eml hf-mf-1AB33A09-dump-1.eml
pm3 ~/client$ diff  hf-mf-1AB33A09-dump.eml hf-mf-1AB33A09-dump-2.eml
pm3 ~/client$

The are no differences from the diff command outputed, meaning they are the same.

[idunnohmm]

Thanks iceman. I did try flashing my Elechouse Proxmark3 RDV3 Easy with the RRD bootrom & os but it bricked so I assume my device is not compatible. It flashed successfully but didn't boot, no USB device connection and no COMx port allocation even after unplugging and replugging. Had to reflash with this bootrom to recover. I am preloading the emulator memory before I sim too even though I didn't paste that output above. Again the dumps above were UID is FFFFFFFF all are correct. I will try specifying the type '1' parameter like you do and maybe I'll have better luck. Originally when it broke the blocks were all shifted down by one and the last block was lost but now when it breaks everything is empty. I will just have to manage.

[iceman1001]

aha. Yes, Now I see. In order for PM3 RDV20, PM3 RDV30 to be flashed with RRG Repo , you must edit these two Makefiles. You need to remove

1. client/Makefile (comment out one line WITH_FPC etc
2. armsrc/Makefiel (comment out three line WITH_FPC, WITH_SMARTCARD, WITH_FLASH)

recompile and your older device will work nicely

[idunnohmm]

Thanks again, following your advice I successfully flashed my PM3 V30 Easy. Unfortunately the bug persists and it is probably my hardware implementation/variation. You get what you pay for. It appears no matter what the first read of the emulated card always returns blank, subsequent reads then return the correct data. I'll just have to be aware of this. I suspect it is also why my reader always fails on first contact.

[ CLIENT ] client: iceman

[ ARM ] bootrom: iceman/master/f679db96-dirty-unclean 2018-09-17 18:57:54 os: iceman/master/f679db96-dirty-unclean 2018-09-17 18:58:03

[ FPGA ] LF image built for 2s30vq100 on 2018/ 9/ 8 at 13:57:51 HF image built for 2s30vq100 on 2018/ 9/ 3 at 21:40:23

[ Hardware ] --= uC: AT91SAM7S256 Rev D --= Embedded Processor: ARM7TDMI --= Nonvolatile Program Memory Size: 256K bytes, Used: 242959 bytes (93%) Free: 19185 bytes ( 7%) --= Second Nonvolatile Program Memory Size: None --= Internal SRAM Size: 64K bytes --= Architecture Identifier: AT91SAM7Sxx Series --= Nonvolatile Program Memory Type: Embedded Flash Memory

pm3 --> hf mf csave u 1 hf mf csave u 1 [+] Saving magic mifare 1K [+] saved 1024 bytes to binary file hf-mf-BBD40A02-dump.bin [+] saved 64 blocks to text file hf-mf-BBD40A02-dump.eml

pm3 --> hf mf eload 1 hf-mf-BBD40A02-dump hf mf eload 1 hf-mf-BBD40A02-dump ................................................................ pm3 --> hf mf sim u BBD40A02 hf mf sim u BBD40A02 uid:BB D4 0A 02 , numreads:0, flags:2 (0x02) pm3 --> hf mf esave 1 hf mf esave 1 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-00000000-dump-10.bin [+] saved 64 blocks to text file hf-mf-00000000-dump-10.eml pm3 --> hf mf esave 1 hf mf esave 1 [=] dowingloading from emulator memory [+] saved 1024 bytes to binary file hf-mf-BBD40A02-dump-1.bin [+] saved 64 blocks to text file hf-mf-BBD40A02-dump-1.eml pm3 --> hf mf sim u BBD40A02 hf mf sim u BBD40A02 uid:BB D4 0A 02 , numreads:0, flags:2 (0x02) pm3 --> hf mf eget 0 hf mf eget 0

data[ 0]:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 pm3 --> hf mf eget 0 hf mf eget 0

data[ 0]:BB D4 0A 02 67 08 04 00 62 63 64 65 66 67 68 69

[iceman1001]

hm.. ok, there seem to be another bug than what I thought it would be. I will look into it

[iceman1001]

Hold on, after you run your sim command, did you remember to press the button to stop simulating?

[iceman1001]

if you don't, your first "hf mf eget" becomes the command which is interrupting the simulation command and abort sim. Doing so will stop the original intent (hf mf eget) to be executed and will return a bunch on zeros...

[idunnohmm]

Bingo! I wasn't pressing the button to stop the sim and since I didn't use the 'i' (interactive) flag, the console returned immediately giving me the impression I could happily command the PM3 again. I remember the first time I saw this I thought sim wasn't working. You're right the first command is what is actually stopping the sim but it also executes which threw me off. Funny I actually thought it was a bug stopping the sim when I use eget or esave. Even using the 'i' flag it isn't truly interactive as any input will stop the sim; the console just doesn't return. I guess this behavior isn't so intuitive for a non-seasoned user like me. That what makes the PM3 a hacker's tool. You have to understand it in a way which only comes with experience. Very appreciative of you taking the time to help an amateur like me learn this awesome piece of hardware.