Magic Ring/Mifare SAK mistake

Hello,

I have been working on trying to clone the RFID tag (mifare classic 1k) from our new apartment to my magic ring.

I’m pretty comfortable on the LF side of the house, but for playing on the HF side I turned to the RFID hacking/Iceman discord to get a little help as I wanted to make sure I didn’t brick my ring.

We were making progress - finally got a valid dump set up and was able to use the pm3 easy in sim mode to unlock the door. However the ring was still getting a red light from the reader. Someone recommended I change the SAK from 08 to 88 via wrbl. At that point in time the reader stopped even responding to the ring at all - and after all that and digging through the forums here some more I am starting to understand that the ring is now presenting as something totally different. I also don’t know how to correct it now haha, and this is the second ring I have the issue on (they both show up via hf 14a info as sak 88) Would anyone be able to help?

Thanks,
Andrew

just curious… do you know why did they suggest this? The only reason someone might do this is if the original tag had a SAK of 88… which would be rare. I’m assuming they had no idea what the SAK value of your original tag was, which puts the blame shame game on them not you.

What is the SAK of your original tag?

I would honestly go back to the person who suggested this and tell them they should help you fix it, and after they help you fix it, tell them they should refrain from having people just randomly change stuff for no reason or without proper data to give good reason.

I’m in cranky mode right now so that might come off a bit lame of me to say, but I’m irritated someone would give that advice when clearly they didn’t even confirm the SAK of your legit fob.

Yeah, but a fair statement.

Unfortunately my comment will come off as hindsight and maybe a bit wanky, but just to let you know what I do ( I’ve never bricked an implant )
I have a bunch of test cards, and at least one of each type of implant I have, before i try something new on any implant, i will practice a test write to it on the card first.

Its a great way to learn and if you fuck it up, you have only lost a fuck-all card

With your ring you only need a T5577 ( although if you are super comfortable with it you won’t need one ) and a Magic Mifare 1k gen2 card and you are sorted.

Without knowing all the commands you sent, I wonder if you were using / directed to send gen1 commands :man_shrugging:

If you are thinking of delving into the RFID world, I would personally recommend grabbing yourself a test card bundle and a magic card pack, and this will cover you for the majority of cards you will likely come across

3 Likes

it was me…

and for a very good reason. Link to gist

we confirmed the original has a 0x08 SAK and using detached SAKs (fake 0x88 in dumps yet 08 during anticol) is a legitimate anti cloning method used on a bunch of systems.

this won’t have negatively effected the card. the OP didn’t provide the full context (that a bunch of ppl were helping them in iceman’s discord server) and many things were tried, they did many things prior to and after changing the SAK that had 0 success with their cloning anyway incl but not limited to messing with sector ACLs.

a likely reason it’s still not working is the lock is validating that the sak in b0 is not 88 and it wants it to be. (need a burned in SAK of 08 and block 0 sak of 88).

just curious… do you know why did they suggest this? The only reason someone might do this is if the original tag had a SAK of 88… which would be rare.

Totally fair point! The OG tag has a sak of 08. The magic ring was reporting a sak of 88. So it made sense to me that the SAK needed to be changed to 08 to match.

I’m in cranky mode right now so that might come off a bit lame of me to say, but I’m irritated someone would give that advice when clearly they didn’t even confirm the SAK of your legit fob.

No not lame at all! I’m sure you guys deal with stuff like this far more than you’d care too. I was really trying to make sure I researched this thoroughly as I didn’t want to make a dumb mistake. As @Equipter pointed out the whole saga is documented in the #Mifare channel on the Iceman discord. Everyone was being really helpful and it was a team effort. I had mentioned it in there that I have a disability…I used to be really good in this realm, but my IT security/pentesting skills were strong in the 05-2013 years…then joined the military, got some brain trauma and yeah…memory loss sucks. Some of the knowledge & experience is still there but I know I tend to cross streams quickly now and I wanted the extra over the shoulder (and admittedly a bit of hand-holding) from everyone else to make sure I didn’t screw up lol.

1 Like

@Equipter I didn’t even realize that was you :laughing: Thanks so much for helping! and thanks for linking the gist. Once everyone stopped replying and I was sitting there looking at the data & looking for similar issues on here I decided to call it a night, not try anything further and post here first before doing anything else.

Yeah not providing full context was an error on my part. My brain had made the jump that mentioning that it was on the iceman discord server meant that anyone could go look and see the convo (and I didn’t wanna spam this thread with a transcript of a 2hr+ long chat on discord).

So then the fix should just be going back to the dump.json, and modifying blk 0 from the “FE41738844080400C848002000000014” value back to the “FE41738844880400C848002000000014” ?

it won’t make your tag work but the red light will come back on the reader.

to clarify. your tag isn’t bricked the reader is ignoring it due to its Sak-ness to prevent clonin

See that’s what I thought, but when I do that, the result I get is this:

[usb] pm3 → hf mf restore -f hf-mf-FE417388-dump.json
[+] loaded from JSON file hf-mf-FE417388-dump.json
[=] Restoring hf-mf-FE417388-dump.json to card
[=] block 0: FE 41 73 88 44 88 04 00 C8 48 00 20 00 00 00 14
[#] Auth error
[=] Writing to manufacture block w key B ( fail )
[=] block 1: D5 01 06 70 05 70 07 70 07 70 07 70 09 70 00 00
[#] Auth error

These blocks are okay

[=] block 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] block 21: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] block 22: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] block 23: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
[=] block 24: 58 D1 13 3E 02 AB 21 2B 29 E8 80 1C 41 29 7D 51
[=] block 25: 43 C9 D4 00 45 77 1F 63 00 00 00 00 00 00 00 00
[=] block 26: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] block 27: FF FF FF FF FF FF 0F 00 FF 00 FF FF FF FF FF FF
[=] block 28: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] block 29: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] block 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[=] block 31: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF

and 36-61 are okay as well, but followed by

[=] block 62: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[!] Invalid Access Conditions on sector 15, replacing with default values
[=] block 63: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
[=] Done!

Well I’m pleasantly surprised. Sorry for being a crank :wink:

I’ve never heard of mifare cards misrepresenting SAK like that. It’s interesting for sure.

1 Like

hehe always a happy ending. but yeah it’s a weird one

1 Like

Sorry for the delay in adding any more info, I fired off my previous and then had to head into work. But yeah, I’m out of my depth at this point. Restoring with the corrected values fails and doesn’t change what’s on the ring (though tbf, I haven’t tried changing values in any of the other blocks that seemed to take it fine)… still no red light response from the reader or anything like that. I’m afraid to go any further without guidance as I am scared of bricking it, but I also don’t want to dork things up if there’s some sort of forensic value here that could be teased out and potentially could help the rest of the community.

I’d be happy to send the magic ring to you guys for science if that’s something you’d want lol.