Proxmark3 community

beben

Contributor

Registered: 2015-03-05

Posts: 32

cload bug since update

Hi,

I'm having trouble loading an eml dump into a chinese Mifare using my Proxmark.

Here's a bit of context:

I've been using my Proxmark for 18 months, I updated the bootrom,fpga and os only once, when I first got my hands on the board. Ever since then, I've been running something like r839-svn iirc (around August 2013), merrily dumping and restoring Mifare cards along the way.

Yesterday, I decided it was time for an upgrade, and downloaded the latest client/roms from github (2.0.0-rc1-1). I flashed my bootrom/fpga/os without trouble and compiled my new client, eager to try the new iClass features. Everything seemed to work perfectly.

Today I tried cloning a Mifare Classic 1K card onto a Chinese Mifare using my usual routine:

On the Classic card:
proxmark3>hf mf mifare
proxmark3>hf mf nested 1 0 A a0a1a2a3a4a5a6 d
proxmark3>hf mf dump

Converting the binary to eml:
$pm3_mfd2eml.py dumpdata.bin data1.eml

On the chinese card:
proxmark3>hf mf cload data1

Unfortunately, cload fails every time with:
#db# wupC1 error                 
Can't set magic card block: 1 

I tried different chinese cards, some of which I know for a fact work perfectly, but I got the same error everytime.
When I try to set block 1 manually with csetblk 1, it works.

I could use some help, has anyone ever had that kind of error? Is it fixable? I would rather not downgrade the firmware.

Thanks in advance!

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: cload bug since update

Hm,   wupC1 is the indication for the magic wakeUp command 1,  0x40.   
When this fails,  the tag didn't respond correct to this command.   

Since the rest of your writes seems to work, maybe could something that you just wrote to Block0,  (ie changed the uid) and that causes the next write statement to fail.

hitnt:
if you don't want to exit the proxmark client to convert from dump -> eml,  then use the lua script "dumptoemul"

beben

Contributor

Registered: 2015-03-05

Posts: 32

Re: cload bug since update

Thanks for your quick answer (and for the hint)!

I don't understand how the contents of Block 0 could impact the next block write? could the crc derived from uid be blocking me? how?
I tried cloning several different cards and none of them work with cload, but when I manually set each of the 64 blocks, the clone card works perfectly...
I tried setting Block  manually and launching cload afterwards, but it does not seem to work either.

Thanks again!

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: cload bug since update

Regarding Block 0,   it is pivot to a chinese magic card.
A correct block must contain uid, bcc, atqa, sak  in the first 8bytes.  If not ,  by loading a dump from a normal tag with a "normal" block 0 (with only uid, bcc in the first 5bytes)  you can make your magic card unresponsive.

For the sake of it,  adjust the block0 in your dump to match a valid block0, like after a "csetuid"

hf mf csetuid nnnn
hf mf cgetblk 0
--use this block0 in your dump..
hf mf cload nnnnn

beben

Contributor

Registered: 2015-03-05

Posts: 32

Re: cload bug since update

Thanks for the clarification,

I tried the method you suggested but it also fails. When I use csetuid, the data in block0 is wiped and replaced with zeros, except for the first 8 bytes, that are correct. I tried modifying my dump to match the block created with csetuid exactly, and I still get a wupC1 error, except this time it's block0 that cannot be set (I used to be stuck on block1).

I also tried changing just the first 8 bytes in my dump, still no go, when I cload it into my chinese card it fails alternatively with wupC1 or wupC2, both on block0.

I tried wiping the chinese card (hf mf csetuid <uid> 0004 08 w) and restarting the process from the beginning, but I'm still stuck on Block1 (even when I manually edit the dump). I am not even trying to modify the existing card, just to clone it. I used to do it frequently on the same type of card before I upgraded the proxmark, and it never failed.

I tried dumping a Chinese card with csave and restoring it with cload (without touching the contents of the card inbetween) and it fails with wupC1, again on block1...

I tried loading the dump in the emulator with eload (which works), then from the emulator to the chinese card with "cload e", still wupC1, still block1

I think I might need to downgrade, do you think this could be due to a bug in the last client/os? Is there sqmething I'm doing wrong?

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: cload bug since update

there could be a bug,   new or old.  There has been a lot of changes in both client- and device-side code.
However, I like to believe this changes makes the pm3 better but old code could have been "fixed" to work with old faulty behavior.   If I get some time off this weekend, I can check out your issue.   

I suggest you open an issue on GitHub.  That will get the right attention for it.  You can alway contact me if you want to.

beben

Contributor

Registered: 2015-03-05

Posts: 32

Re: cload bug since update

Thank you very much, going to Github right now, I'll open an issue and refer to this post in it.

You've been very helpful, thanks for your work!

piwi

Contributor

Registered: 2013-06-04

Posts: 704

Re: cload bug since update

Fix pushed to github master.

iceman

Administrator

Registered: 2013-04-25

Posts: 9,538

Website

Re: cload bug since update

Great!, Piwi

beben

Contributor

Registered: 2015-03-05

Posts: 32

Re: cload bug since update

Works perfectly, thank you for your time!