when i’ve dispelled my schizo ranting into some community documentation on the wiki about everything i’ve mentioned, @amal could i work with you to add a brief but visible disclaimer that gen2s requires research and to read the (linked) wiki pages about what to look out for and how to not brick it.
3 Likes
also RIP iphone users, no MCT for us means gen2 implant needs proxmark (or if you’re fancy, a flipper) and it’s hilariously easy to brick a gen2 with the proxmark by doing what seems to be logical operations (using destination keyfile instead of original keyfile will fuck your sector trailers making them invalid and therefore memory unreadable)
2 Likes
Trying to write to a Gen2 with the wrong keyfile?
2 Likes
what one might think is the right keyfile, the keyfile of the gen2 with the data dump of a different card will fuck dem sectors up
hf mf restore -f originalcard.bin -k gen2keyfile.bin
1 Like
Well, I would have bricked a Gen2, because that’s exactly the command I would have used
So you want to give it the keyfile of the dump?
How does it get the keys to actually write to the Gen2?
Do the keys somehow depend on the rest of the data?
1 Like
you supply the keyfile of the original yeah, it assumes factory default, it’s not a problem if the keyfile of the gen2 has the same keys as the data dump file but yeah i couldn’t tell you why this is still a thing it’s definitely a bug and isn’t always fatal, sometimes just mashes up the keys real good and doesn’t hurt the acls but it happens enough that i used to give people 64 write block commands to use instead of restoring because id yet to find out how to stop it from happening.
2 Likes
Hmm, I just don’t understand why the Gen2 would accept a write with the wrong keys
I’ll have to kill some of my Gen2s and see what I can learn
Okay, I still haven’t managed to brick this Gen2, but I did find out that you have to use the --ka use specified keyfile to authenticate flag to get it to work the way I would have imagined it’d work by default
Not certain what it does with the keyfile if you leave off --ka yet
1 Like
it doesn’t accept wrong keys because it’s not using the supplied keys, honestly not looked at what’s going on too hard, gonna have a crack at it too with some normal mifare classics because fuq burning some gen2s
as far as i’m aware it’s assuming factory default keys for the write and won’t do it if they’re not. unsure. will test.
all i know is that command is the devil
1 Like
ooooooh. that will be the way around it for non default keying. don’t know why you’re able to supply a non relevant keyfile for anything but validation?
try with just -k
1 Like
Without -f you mean?
I’m starting to see what you mean…
1 Like
no, -k
(thank god pmref exists) it seems the nomenclature is just what’s really fucked up here and it can be avoided with ka but given -k is the param to specify keys to be used for literally everything else it’s very weird that it’s not here.
this certainly confirms a fix i will very eagerly be dishing out in the future (thank you aox) but it’s still odd but definitely no longer a stopping point and a very relevant part of what’s going to go in the gen2 wiki guide, another RTFI needed part of gen2 lore lol
2 Likes
Okay, I tried hf mf restore -k <keyfile> with both target and source keyfiles, and still no bricky
Though, it may be worth mentioning that these Gen2’s might not be proper Gen2’s according to amal…
2 Likes
when i’m back from work tomorrow ill do it and show ya, i can try find some examples they’re all over the discord.
they dont need to be gen2s, the problematic behaviour comes from changing sector trailers to invalid data which makes the ACLs unusable and the sector unreadable or writable, ergo this would also break a normal mifare classic’s memory
it might also have been fixed and i just hadn’t noticed but i’ve got like a billion examples of this happening before
3 Likes
That would be greatly appreciated!
The whole reason I picked up a pack of Gen2s was to push one as far as I could before bricking it, slightly annoyed that I haven’t managed it yet 
2 Likes
Funny enough the protection against this is simply setting access bits such that the access bits can’t be overwritten without authentication. The only way to break a sector sending a bed right is to mess up the access bit xor
https://forum.dangerousthings.com/uploads/short-url/5dvQpEwbU3ac41o2JFzorvHcs86.pdf
4 Likes
Doing what we do best
Derailing
BUT this was a great discussion.
I might put in its own thread after I find a natural break point.
“The pros and cons of a Mifare Classic Gen2”
or similar
3 Likes
you need authentication to change the access bits anyway, at least one of the keys is needed to change them at all times (unless set to read only) the default being KeyA to write, there isn’t a way to make it writable without authentication
if you mess with the access conditions in order to try and preserve them you will most likely either end up locking yourself out of that sector entirely or going against the rules of the system. if they’re not default in the dump you want to load they’ve been changed for a reason
if the system is designed to use the keys in a specific way that contradict the access conditions you locked into place it won’t be able to authenticate on the system
you’d have to manually set the keys then set the intended logic for the access bits while also changing it to remain writable and hope the system doesn’t read out the sector trailer for validation or test legitimacy logic with KeyB as described in the datasheet.
The only way to break a sector sending a bed right is to mess up the access bit xor
(or by not taking multiple manual steps to prevent the acls from being set to read only)
it’s a good point and one i’ll add to the long list of ways to not walk backwards into a dead gen2 but it’s extraneously complex especially for a newcomer and isn’t guaranteed to allow you to use the chip as the credential if the extra checks are in place (me love fastdump hash comparison)
but at least it prevents the memory getting permanently set to the motel 6 you stayed at 3 years ago which is certainly a win.
2 Likes
one thing worth mentioning about gen2s that is great is that they’re immune to SAK Swapping, gen1a are largely susceptible to it (ymmv there’s many variations of gen1a that have slightly different behaviours, my xm1 and the xmagics within my friends are susceptible)
you could have a system that doesn’t check for any magic, works with implant form factor and not be able to use it because of a single enabled bit.
4 Likes
And I just checked into the first Australian Hotel (I have encountered out of hundreds) which uses a mifare with a 7 uid and can’t program it to my xMagic. Damn.
3 Likes