xM1 - Mifare Classic clonning problems

You’ll need to crack the keys in that case. There’s some commands and I can assist if needed. You’ll need to identify what version of donor card you have - ie what it’s vulnerable to. Some older cards will be vulnerable to the timing attack, new cards are vulnerable to hardnested - which is a kind of attack that needs captured communications from a reader.


I’ve found the easiest way is to run the AutoPwn script in the Iceman version. Will try default keys, then nested, then hardnested, then something else I think, then brute force.

The ETA starts off with something horrid, and as it finds a working vuln it jumps right down.

Very simple way to do it!

1 Like

Ok, so today I’ll try to update proxmark.
Will this AutoPwn work with this firmware that @leumas95 linked?
Or I should use Iceman’s firmware for pm3

sorry for noob questions it’s my first time using it

1 Like

The one @leumas95 linked above is what a lot of us call the Iceman Fork - it used to be posted on his github, but its now technically called the RFID Research Group fork - he’s the (lead dev? Project manager? Head Wizard in Charge?)

It’ll work just fine with that version :slightly_smiling_face:


Yeah, so… I am encauntering more and more problems… Just when I thought that I manadged to update everything:

pm3 ~/proxmark3$ pm3-flash-all
[=] Session log E:\Downloads\ProxSpace-64\ProxSpace-64\pm3/.proxmark3/logs/log_20200623.txt
[=] Loading preferences...
[+] loaded from JSON file E:\Downloads\ProxSpace-64\ProxSpace-64\pm3/.proxmark3/preferences.json
[+] About to use the following files:
[+]    E:\Downloads\ProxSpace-64\ProxSpace-64\msys2\usr\local\bin\../share/proxmark3/firmware/bootrom.elf
[+]    E:\Downloads\ProxSpace-64\ProxSpace-64\msys2\usr\local\bin\../share/proxmark3/firmware/fullimage.elf
[+] Waiting for Proxmark3 to appear on COM5
[|] 59 found
[=] Available memory on this board: 512K bytes

[=] Permitted flash range: 0x00100000-0x00180000
[+] Loading ELF file E:\Downloads\ProxSpace-64\ProxSpace-64\msys2\usr\local\bin\../share/proxmark3/firmware/bootrom.elf
[+] Loading usable ELF segments:
[+]    0: V 0x00100000 P 0x00100000 (0x00000200->0x00000200) [R X] @0x94
[+]    1: V 0x00200000 P 0x00100200 (0x00000d50->0x00000d50) [R X] @0x298

[+] Loading ELF file E:\Downloads\ProxSpace-64\ProxSpace-64\msys2\usr\local\bin\../share/proxmark3/firmware/fullimage.elf
[+] Loading usable ELF segments:
[+]    0: V 0x00102000 P 0x00102000 (0x0003d530->0x0003d530) [R X] @0x94
[+]    1: V 0x00200000 P 0x0013f530 (0x00001970->0x00001970) [RW ] @0x3d5c4
[=] Note: Extending previous segment from 0x3d530 to 0x3eea0 bytes

[+] Flashing...
[+] Writing segments for file: E:\Downloads\ProxSpace-64\ProxSpace-64\msys2\usr\local\bin\../share/proxmark3/firmware/bootrom.elf
[+]  0x00100000..0x001001ff [0x200 / 1 blocks]
[+]  0x00100200..0x00100f4f [0xd50 / 7 blocks]

[+] Writing segments for file: E:\Downloads\ProxSpace-64\ProxSpace-64\msys2\usr\local\bin\../share/proxmark3/firmware/fullimage.elf
[+]  0x00102000..0x00140e9f [0x3eea0 / 504 blocks]
mm OK

[+] All done

Have a nice day!
pm3 ~/proxmark3$

But, now my pm3easy (guess I should mention it earlier, it’s pm3 EASY) is unrecognisable by Win10 (I’m using ProxSpace). It shows up as an unknown USB device with this error:

A request for the USB device descriptor failed.

However, when I plug it in with the flash button pressed it shows up normally on the COM ports.
I’ve read that, with pm3easy you should make Makefile.platform file with:


but I’ve got an error that it’s an invalid platform, so I’ve changed it to:


I was following those guides:

ProxSpace part ofc
and then:

I just hope that it’s not bricked and I don’t need to buy Bus Pirate or anything to fix it ._.

i would wipe the rrg repo entirely from proxspace… then do another git clone… update the Makefile.platform to PLATFORM=PM3OTHER and do a total make clean && make all and then make install … then hold the flash button down, plug in, run ./pm3-flash-bootrom with the button held down the whole time… let it finish… release the button… let it sit for 30 seconds… then unplug USB… then plug it back in with the button held (again) and do the ./pm3-flash-fullimage … release… 30 seconds… unplug USB… plug back in… then wait a good 60 seconds and see if it comes back online.

I have an old rysc corp proxmark3 original board i just did this to and it had some hiccups but finally after following the above it worked.


oh, and when i say 30 seconds… i mean 30 seconds… it took close to 28 seconds after releasing the button for a virtual com port to appear after updating the bootrom… i dunno what it’s doing but i let it do its thing and everything is happy now.

1 Like

Ok I’ll try, at first I didn’t understand what did you mean with rrg repo whoops
Thanks for a quick answer

If none of that works above :arrow_double_up:
you could always try the Konami Code below :arrow_double_down:

:arrow_up: :arrow_up: :arrow_down: :arrow_down: :arrow_left: :arrow_right: :arrow_left: :arrow_right: B, A

I hope that helps :wink:

  1. I’ve wiped the repo.
  2. Cloned it again.
  3. Updated Makefile.platform.
  4. make clean && make all
  5. make install
  6. flashed bootrom with button, after waiting for like 15s device appeared, but same as before it’s unrecognised with this error:
A request for the USB device descriptor failed.
  1. Unplug and repeat with the full image.
  2. Aaaand again with the same problem, it shows but isn’t working properly.

error code 43

P.S. Konami Code didn’t help, I’m in trouble, aren’t I?

Forgot to mention, diodes A, D and obviously Power are on. I don’t know what does it mean yet, but maybe it’ll be helpful.


The strangest part is that when I plug it in with the button, it shows correctly on the COM port.

I’ve got it working, after reinstalling drivers and reflashing again it just worked ¯\_(ツ)_/¯


I hope i’ts my last question here.
I’ve managed to get all the keys, but one block from one sector (s4b2) is refusing to be read. I am getting this errors:

[!] access rights do not allow reading of sector  4 block   2
[!] command execute timeout when trying to read block  2 of sector  4.

Is it normal? Will it cause any problems with using the xM1? If yes, or maybe yes, it any way to read it and copy it?

How are you getting keys? Are you using autopwn? If not, you should consider using it… it will escalate the attack methods as necessary to get all keys.

Yes I am using autopwn and I am getting all the keys, but still I can’t access this and only this fragment.

Hmm, what that probably means I’m guessing is that you can ignore that block.

It’s probably been mis configured so that neither KeyA nor KeyB has read access to that block, so I can’t see how any system could be using it. Replace the data with all 0’s and copy the sector trailer from another block and you should be fine

I.e. Replace Sector 4 block 2’s data with that of Sector 5 block 2

Since the xM1’s are Gen1a, even if you do mess this up, its no big deal and won’t brick your implant since you can always use the backdoor commands to reconfigure it

Could you explain how can I do it? Still learning :sweat_smile:
Btw it’s a public transportation pass and I wonder if I will have to repeat this process every ±3 months, when extending the ticket or is it just some kind of a token to theirs database. Probably the first option, I’ve heard some time ago there was a problem with people hacking and extending the duration of those cards, unless they’ve changed it after it.

I’m afraid I’m away from my computer at the moment, so it might be hard for me to explain without being able to double check things, next time I’m near my proxmark I’ll share instructions if someone else hasn’t already.

As for if you’ll have to do this many times, I’m not sure - every transport network/company/etc does this differently. So its likely you will, but also likely you won’t.

I think its actually pretty unusual to find a public transport network still using Mifare Classic instead of a newer secure card for the reason you mentioned - you’re one of the lucky ones!

It’s Poland you know xD

I’ll be waiting for help, thanks :grinning:

Ok so we are speaking the same language, which sector is this exactly? For now I will call it Sector X

Confirm you have keys for this sector from autopwn (confirm this yourself, then confirm it to us).

From what I understand, you do have keys for sector X but when you attempt to use those keys to access data in sector X, you cannot access data and you receive an error. If this is the case, @Compgeek is right - the sector itself may be inaccessible. How could this happen? There are two major ways this could happen…

  1. The sector trailer for sector X contains keys A and B and also access bits for the sector, which inform the chip which key can do what (read or write or change keys or change access bits)… it’s possible that the access bits were configured such that neither key A or B can read the sector’s content. It may still be possible that one or both keys could write to the sector. I believe it’s also possible to set access bits in such a way that you could make it so keys would be unable to read any sector data, but still be able to use at least one key to change access bits. This means you could re-enable reading of data… read it… then disable reading of the data again… kinda like a double locked door… sorta… anyway, I forget the specifics but you can read my little PDF thingy I wrote back when I was looking into this Mifare stuff.

  1. Someone messed up the access bits and locked the sector completely. The Mifare crypto1 ROM code includes a kind of integrity check for access bits… like a really shitty CRC check. So when you want to change them, you write the access bits as expected, but then you also need to include an inverted bit version (also detailed in my little PDF thingy), and if you fuck up the bit inversion and it doesn’t match then the entire sector is locked out forever, regardless of whether or not you have valid keys or not.

So, the point here is, if you’re in situation 1, then you might be able to use the keys you’ve been able to recover to reset access bits for sector X to enable keys to read the data. If you are in situation 2, then the data is irrelevant because nothing can access it… but it may not need accessing if the keys can still be validated through a crypto1 authentication command… meaning the data in the sector was never used, just the keys were used as a kind of password feature… so as @compgeek said, you can just assume the data in that sector is all 0000s and ignore it… write 0000s to your target chip for sector X and set the keys appropriately for sector X on your target chip and see if it works.