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?)
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.
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!
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…
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.
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.