So You Want To Implant An HID Card

THIS POST IS A WORK IN PROGRESS. Additions / Corrections are requested.

Ever since the introduction of flexClass (and even sometime before then), I’ve seen a good deal of folks, especially new folks, looking for assistance in cloning an HID access card onto an implant. HID’s system is weird and not especially intuitive, and I wanted to write this as an informal “guide” to what HID cards are cloneable since I suspect cloning these things will become much more popular in the future. At some point in the soon I’ll update with a more in-depth guide to cloning an iClass card to a flexClass/blank RedTeamTools card.

Not all HID Cards are created equal.

HID is a big company. They have a multitude of different card types. See the post here for more information. Most of the rest of this article will be about cloning the most common commonly used iClass cards.

Not all cards labeled “iClass” are the same.

Not even the cards that are described as the same. HID has two different card types: iClass SE and normal old iClass. iClass has been “cracked” (i.e. easily hackable) for a long time, but SE cards are not. In general, if you have a system that uses SE cards, at this point there isn’t a good way to clone cards over. Some of the data stored on the card is encrypted.

What even is iClass SE?

HID sells iClass SE products, which use data that has been encrypted in such a way that the data can’t be cloned from one card to another without ceasing to function. We don’t know what kind of cryptographic process they’re using to encrypt this data, so we can’t reverse-engineer it.

Not all readers are the same

HID manufactures a great number of readers, enough so that they can accept pretty much any set of HID card types in any combination. This is great for interoperability, but not for figuring out what chip type you’ll need. Some readers can properly read iClass SE cards AND non-SE iClass cards, so It’s important to know what the reader is actually looking for when it scans a card.

How do I know what kind of card/reader I have?

Readers are fairly easy in terms of determining type. On the bottom of most readers, HID labels them as to what kind of cards the reader is set to accept. Blank readers do exist, and it’s helpful at that point to know what kind of cards you’re working with. If the information is covered up with a sticker (the place I have an HID card for uses CBORD. If you have CBORD, assume the readers are SE.)

Some are unlabeled, and this is a point where we will need to start doing some more guesswork based on the card information. This is where you’ll need a proxmark.

I have a card and reader that use non-SE iClass technology!

Blocks 6-9 are generally the non-secure HID iClass blocks. 1-5 are settings for the card (ie block size, UID, etc). Afterward are the SE (AKA secure) blocks. If there’s anything past those blocks, you are likely to run into problems cloning the card successfully.

Generally, I recommend getting a blank iClass card sold by RedTeamTools. These cards are essentially what’s in the flexClass in the traditional card form factor. Try cloning just blocks 6-9 and usin the cloned card on all the standard access points you use a card with. Does it work? Great! You should be good to go to get a flexClass.

I have a card and reader that use ProxPass technology!

Congratualations! Your life is going to be a little easier: generally, ProxPass cards can be cloned to the T5577, the chip inside the xEM, NeXT, and flexEM.

I have a card and reader that are iClass SE!

This is where is gets a little tricky. SE cards are generally non-clonable (though you can still clone blocks 6-9 as you would with a non-se card, in the hopes that some of the readers aren’t configured to only look for SE cards). If you are able to have two cards, you could possibly send one of them to @Amal for custom conversion. You’d need to take that up with him though.


This addition is for use with HID iClass legacy cards that aren’t using the HID master authentication key

PLEASE read this entire post several times before attempting anything. Mistakes are easier to avoid than they are to recover from

To start, if you have cloned you iClass legacy card (manually cloned blocks 6-9), yet aren’t getting any response from the appropriate readers, this may benefit you.

Assuming you are connected to the pm3 and running iceman repo with the credential that you are trying to get to work on the iClass readers

Step 1: hf ic chk -f iclass_default_keys.dic

assuming you get “found valid key”

“Key already at keyslot X”
whereas X=the key position in the result of:

hf ic managekeys -p

reference this key to what you have (hopefully) already documented as HID iClass master authentication key vs HID iClass default authentication key

NOTE WHAT KEY POSITION YOUR hf ic chk -iclass_default_keys.dic MATCHES WITH THE
hf ic managekeys -p COMMAND

ie. 0, 1, or 2

Step 2: hf ic info

Take note if you results show card in PERSONALIZATION vs APPLICATION mode. VERY IMPORTANT

Step 3: hf ic calcnewkey --oki X --nki Y
whereas X is the value for the HID master authentication key from the hf ic chk -f iclass_default_keys.dic cmd and Y is the value in the keyslot from hf ic chk -f iclass_default_keys.dic cmd


While it is possible to recover from an incorrect entry to block 3 (as I will describe below) it is neither fun, nor desirable. PLEASE ensure you have this next step 100% correct to prevent any headache later.
Also, before you go any further, document every value that you use in the following command, and where you use said values in the command. This will help save you in case you screw the pooch in the process.


Step 4:
If card shows in personalization mode

hf ic wrbl -b 3 -d XXXXXXXXXXXXXXXX --ki Y
whereas XXXXXXXXXXXXXXXX is Kdiv new from the hf ic calcnewkey cmd.
whereas Y is the value for the keyslot found in hf ic chk -f iclass_default_keys.dic cmd

if card show in application mode
hf ic wrbl -b 3 -d XXXXXXXXXXXXXXXX --ki Y
whereas XXXXXXXXXXXXXXXX is Kdiv xor from the hf ic calcnewkey cmd
whereas Y is the value for the keyslot found in hf ic chk -f iclass_default_keys.dic cmd

Step 5: hf ic chk -f iclass_default_keys.dic* again

Step 6: hf ic managekeys -p

The value for the “key already in keyslot X” should have changed to the desired HID iClass master authentication key as opposed to the HID iClass default authentication key.

Step 7: hf ic dump --ki X
whereas X is the keyslot value for the HID iClass master authentication key in the hf ic chk -f iclass_default_keys.dic cmd


If successful, you card is now operating using the HID iClass master authentication key and should be recognized by the appropriate readers! CONGRATS!


if using the iceman repo:
the hf ic managekeys SHOULD show (at least in my experience) the HID iClass master authentication key in slot 0 and the HID iClass default authentication key in slot 2.

Keep in mind that every line that uses X, Y, XXXXXXXXXXXXXXXX, or YYYYYYYYYYYYYYYY refers to that specific line ONLY. The implied values change depending on what line and Step it is referring to at that specific time.

Application mode-Kdiv xor
Personalization mode-Kdiv new

In personalization mode, the fuses in block 1 have not been blown, meaning the config block (block 1) can still be modified. I would suggest NOT changing this as it gives you more options down the road for fun stuff. You can go down that rabbit hole at your own convenience. :stuck_out_tongue:

In application mode, the fuses in block 1 HAVE been blown. You can no longer modify block 1. That I’m aware of, at least.



First off…I done it. SEVERAL TIMES so, don’t feel bad. I will attempt to help you get out of danger.

IF you followed my instruction and DOCUMENTED your values and where you put them.

hf ic rdbl -b 3 -k XXXXXXXXXXXXXXXX --raw
whereas XXXXXXXXXXXXXXXX is the INCORRECT value that you wrote to block 3

The --raw will allow the key to be used without any computation. Hopefully allowing you to recover.

If you get a successful read, then:

if application mode
whereas XXXXXXXXXXXXXXXX is the Kdiv xor and YYYYYYYYYYYYYYYY is the INCORRECT value that you wrote to block 3.

if in personalization mode
whereas XXXXXXXXXXXXXXXX is the Kdiv new and YYYYYYYYYYYYYYYY is the INCORRECT value that you wrote to block 3.


If you get a successful write:

hf ic dump -k X
whereas X is the HID iClass master authentication key

if you get a successful dump, you’re back in business!

if not, we still have work to do. Feel free to tag me in YOUR thread related to your specific problem and I will help where I can.

I’ve spent countless hours and over a dozen cards from iCLASS RFID Card ( (huge shoutout for those!!!) getting this to work for me. And, thanks to all those that have helped me along the way on here and the proxmark forum!

I’ve read over this post several times, but I may very well have missed something. If you find an error or find something I missed, please let me know so I can update!

As always, this is only a refence, and any modification to block 3 can turn your credential useless




Thanks @NinjuhhNutz , this is really useful!
I’m trying to clone an iClass Card that needs elite computations in order to decode, and this has given different xors as below:

(Key 7 was sniffed from the reader)

[=] idx| key
[=] —±-----------------------
[=] 0 | AE A6 84 A6 DA B2 32 78
[=] 1 | 76 65 54 43 32 21 10 00
[=] 2 | F0 E1 D2 C3 B4 A5 96 87
[=] 3 |
[=] 4 |
[=] 5 |
[=] 6 |
[=] 7 | B8 5B 8C E0 A0 D8 B6 BF
[=] —±-----------------------

//Not sure if this is the correct command - bricked the card subsequently
[usb] pm3 → hf ic calcnewkey --oki 0 --nki 7 --elite
[+] Using old key[0]… AE A6 84 A6 DA B2 32 78
[+] Using new key[7]… B8 5B 8C E0 A0 D8 B6 BF
[+] CSN F4 CA 2E 12 FF FF 12 E0
[+] epurse FC FF FF FF FF FF FF FF
[+] Old div key… 71 A7 01 46 2E 33 08 5C
[+] New div key… C3 67 F2 5C 2B 54 59 0C
[+] Xor div key… B2 C0 F3 1A 05 67 51 50

[usb] pm3 → hf ic calcnewkey --oki 0 --nki 7
[+] Using old key[0]… AE A6 84 A6 DA B2 32 78
[+] Using new key[7]… B8 5B 8C E0 A0 D8 B6 BF
[+] CSN F4 CA 2E 12 FF FF 12 E0
[+] epurse FC FF FF FF FF FF FF FF
[+] Old div key… 71 A7 01 46 2E 33 08 5C
[+] New div key… 60 79 65 2C C7 F2 4F F0
[+] Xor div key… 11 DE 64 6A E9 C1 47 AC

Seems like none of the div keys below are working with the reader, would you have any advice on how to retrieve the correct div keys for elite keys?
(Elite Key | HID Global)

Thanks so much! :slight_smile:

Sorry dude, I’ve been MIA lately with life and work and everything else going on. It’s been a while, BUT the Kdiv isn’t what the credential ACTUALLY uses during authentication. It’s a way for the system to “store” the key on the card, while “encrypted” for simplicity sake. Have you tried using the --raw option with the reader? I have VERY limited experience with iClass elite. So, I’m not sure how much help I can actually be. But, I generally have my PM3 connected to a pc at home and a laptop with me to remote in for any on the spot attempts.

Do you have an actual reader at your disposal? Or, just the ability to try without raising eyebrows? I ask because it was apparently quite entertaining to some of my buddies at work that knew what I was doing when trying to determine the type of reader and trying multiple credentials when I first started this journey :crazy_face: :stuck_out_tongue_closed_eyes:

Or, is it that you’re documenting the changed in the card and trying each of the Kdiv values until you get one that works? So that we are both on the same page and maybe I can be at least a little helpful.

Thanks @NinjuhhNutz !

Not sure how to use --raw with the reader, but the good news is that trying hf iclass sim -t 2 and hf iclass sim -t 4 it all decodes to the same key.

hf iclass sim -t 0 --csn 031FEC8AF7FF12E0 → simulate with specified CSN
hf iclass sim -t 1 → simulate with default CSN
hf iclass sim -t 2 → execute loclass attack online part
hf iclass sim -t 3 → simulate full iCLASS 2k tag
hf iclass sim -t 4 → Reader-attack, adapted for KeyRoll mode

Resulting key (same outcome)
[+] ----- High security custom key (Kcus) -----
[+] Standard format 41 43 23 E5 C7 9B 54 BF
[+] iCLASS format B8 5B 8C E0 A0 D8 B6 BF
[+] Key verified ( ok )

It’s an apartment complex and plenty of access to readers :slightly_smiling_face:

The interesting part is how an elite computation on calcnewkey will give completely different permutations.

Love your generosity with the other contributors too, even if this doesn’t succeed, have learnt a ton along the way and enjoying every bit of the process (no pun intended) :rofl:

Will let you know if I manage to get any other Xor values!

I’ll be the first to tell you that I’m a bit out of my comfort zone with the elite cards. :face_exhaling: I wish I could help more, but at this point I think you may very well know more than I do about them. Of course I’m willing to help in any way that I can. I just don’t have much confidence in my ability to do so :stuck_out_tongue:

@darkskylight I am in the same boat as yours trying to copy iclass elite key to a standard iclass 2k. Did it work for you yet?

I just had to put a reply in here, as I did some of the attempts above, but ended up going back from a working raw key to a brick again.
So, I spent some time thinking about it all, and there is a method that I think might make unbricking way easier, and almost guaranteed to work.
At least it simplified it for me personally!
Like Ninja said, you must have the last command you sent that bridcked the tag available, and I’d suggest finding it in the logs that are provided for just this kind of thing.
They might be located somewhere like:
I’d also suggest re openning the latest log as you go to copy and paste the results directly from there, rather than manually typing them from the screen, Less chance of mistakes.
You do have to remove spaces between digits sometimes to turn log output back into commands.
Also, as stated before, make sure you know which mode application or personalisation your tag is in, important!
In personalisation mode, what is in block 3 is what you last wrote to it.
so, the raw key will be just that, should be pretty easy to fix it, as you can just do a calcnewkey with the dictionary key you want and write the div key of it into block 3 using the data you last wrote as the raw key to write it, done! (hopefully)

As for application mode tags, which is every one I’ve ever handled, it’s a bit harder, but not too much.
Once again, find the command you last wrote to brick the card.
If you used a dictionary key to do it, then derive the corrosponding div key from that.
You can use Both --old or --new seem to give exactly the same result.
Place your tag on the proxmark. Then.
hf icl calcnewkey --oki 0 --new 0000000000000000
the old div key is the raw key you need here, the new and xor keys are rubbish.
Of course, if you last wrote the tag with a raw key then use the key as it is.
Ok, now you have the data you wrote, and the raw key you wrote it with, then you need to xor those together, the result is what will currently be in your block 3.
You can put windows calculator to good use here, put it in programmer mode and check hexodecimal.

Note: if your result has any leading 0s, the calculater might not have printed them on the left. so write the 0s back if so, you need 16 hex digits.
Now Try
hf icl rdbl -b 7 -k blk3blk3blk3blk3 --raw
It should work and you should get a response, Fingers crossed!!!

So, presumably, you now want to get the card back to using the default dictionary key. Once again, the rule is block 3 = what's there now xor what you write to it. so, we know what we have there, and we know what we want to put in there. but how to achieve this. We can once again use hf icl calcnewkey --old 0000000000000000 --nki 0 and the new div key is our new raw value we want in block 3. Note: the old div and the xor key listed in the result are rubbish. but remember, you can't just write it, you need the xor value and sadly, calcnewkey doesn't accept raw keys, I wish they'd put that in actualy! So, we need to make an xor value that will change blk3 into the new div key. Simple, we xor them together in calculater again. blk3blk3blk3blk3 ^ ndivndivndivndiv = datadatadatadata Data is the data that will change blk3 to ndiv raw key Now, hf icl wrbl -b 3 -d datadatadatadata -k blk3blk3blk3blk3 --raw and that should be your tag fixed!!! hf icl chk -f iclass_default_keys.dic If not, go to the top and try it all again with the latest block 3 write assuming it worked!

Ok, that’s my personal angle on it, hope it helps someone, it’s certainly made me much more confident messing with keys myself.


THIS is what my post was missing! It didn’t occur to me until I read your post. Kudos!