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!
Ok, so today I’ll try to update proxmark.
Will this AutoPwn work with this firmware that @NiamhAstra linked?
Or I should use Iceman’s firmware for pm3
sorry for noob questions it’s my first time using it
The one @NiamhAstra 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 
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]
OK
[+] 0x00100200..0x00100f4f [0xd50 / 7 blocks]
OK
[+] 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:
PLATFORM=PM3EASY
but I’ve got an error that it’s an invalid platform, so I’ve changed it to:
PLATFORM=PM3OTHER
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.
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 
you could always try the Konami Code below 
B, A
I hope that helps 
A request for the USB device descriptor failed.
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.
GOOD INFO
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 
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 
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…
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.
Wow thanks for so detailed response.
I am pretty sure I’ve got those keys. I am going to test it tomorrow tho, it’s currently 3 AM where I live.
