My (idiot's) HID iCLASS DY Cloning Guide

So, I have seen many different post giving hints, recommendations, asking questions, and so on, for how to clone an HID iCLASS DY card. It seems to be the typical choice for a varieties of universities out there. After some months, and much silliness, I have gotten a reliable system down, so I have decided to write a guide. Millage may vary. Also, I am not an expert. This is my first RFID project ever, but I did get it to work, and hope you will too!

First step, buy a Proxmark 3 Easy, found here from Dangerous Things:

So so worth it, so so cool.

Once it has arrived, follow this guide to a tee (I recommend watching the video and following along):

It will get you setup with the latest, greatest software/firmware, all that jazz, on your Proxmark and corresponding personal computer. I did all mine on Windows 10.

Okay great. After all that, you should end up with the following in your command prompt:

Put the card you want to clone on top of the proxmark, then type into the command prompt:

hf iclass info

It will spit out a bunch of info, but basically you’re looking for this, the fingerprint section, at the very end of the page:

image

If it says that, all is good. You can then proceed to find the encryption key. I did this by entering:

hf iclass chk -f iclass_elite_keys.dic --elite

This checks the list of default elite keys using the elite computations encryption method. It should spit out a key. Save that key. I put it in a separate .txt file, but it should be somewhere in your sessions logs. Next step, run this:

hf iclass dump -k FFFFFFFFFFFFFFFF --elite

Except, instead of the 16 "F"s, put in the key you just saved somewhere, no spaces, exactly as it was given to you. If you omit the “–elite” at the end, it will not work, at least not for me. If this spits out a tag memory, fabulous. You are in a great place. It should have the headers:

block# | data | ascii |lck| info

I really just paid attention to the block# and data sections. If you have gotten to this point, you need to buy some blank cards. These are what I got:

Or, just anything that says “Brand New HID 2000PGGMN iCLASS PVC Card, iCLASS 13.56 MHz contactless read/write” or something along those lines. You want a readable, writable, blank card that matches that fingerprint from earlier.

Once you have your blank card, you need to copy it over. There may be a more efficient way to do this, but I did it manually. From here on out, it should only be the new, blank card sitting on top of the proxmark. First, find the encryption key for your card. The ones I bought did not use elite computations, so I got the key using this similar command:

hf iclass chk -f iclass_default_keys.dic

That will hopefully spit out the encryption key. Now, you must save that key, like the one you got before. Here comes the tedium. You must copy over all of the blocks from 5 onwards. I don’t know too much about what blocks are necessary, and some seem unused, but I just copied them all, and it worked. Use this command:

hf iclass wrbl --blk 5 -d FFFFFFFFFFFFFFFF -k FFFFFFFFFFFFFFFF

Again, replace the "F"s with the given key/data. The data comes directly after the “-d”, and is what was found after using the dump command from earlier. They key is the one you most recently found, in the previous step, for the new, blank cards, and goes after the “-k”. The block number comes after the “–blk”, and is listed on the table from the dump command from earlier, right next to the data you will write to “-d”. Make sure blocks and data align, i.e., for “–blk” 18, you write the 16 characters that were in the same row from the original card’s dump. I did this manually for every block from 5 to 18. Do not do this for any blocks before 5, yet. Also, block 5 was the same on both cards, as were many, so may not need to be copied over, but I figured I might as well. Now now you must change the key from the one that came with the blank card to that of your original card. It is done through these commands:

hf iclass calcnewkey --old FFFFFFFFFFFFFFFF --new FFFFFFFFFFFFFFFF --elite

Where the “–old” key is the one from your new, blank card, and “–new” is the key from the card you are trying to copy. This will spit out the CSN, epurse, old div key, new div key, and xor div key. Next, run this command:

hf iclass wrbl --blk 3 -d FFFFFFFFFFFFFFFF -k FFFFFFFFFFFFFFFF

Where “-d” is the xor div key and “-k” is the blank card’s original key, i.e., what you just put in the previous command for “–old”.

If you were able to get everything here to work, great! You should now have two effectively identical cards! Go test it out!

I am no expert, but if you have any questions/screenshots/comments/corrections, please feel free to leave them on this thread and I will do my very best to address.

I got quite a huge amount of inspiration form this post:

I would recommend reading the whole thing. That last bit where the new key is calculated and written to block 3 was largely inspired by “[NinjuhhNutz]”'s comment on the post. I recommend reading that as well, as it discusses card that are in personalization vs application mode. I did not delve into personalization mode though, as I found it very difficult to find cards that were in this state, and am trying to make the most direct guide possible. Good luck!

P.S.,
As I get more posting permissions, questions, and comments, I’ll try and order some new cards and make a full YouTube tutorial, but for now, I hope this helps!

9 Likes

Whoa, first post and it’s a well written and informed guide. Great stuff man.

6 Likes

A post was merged into an existing topic: The anti​:no_entry_sign:-derailment​:railway_car: & thread​:thread: hijacking​:gun: thread​:thread: :interrobang:

That is an excellent post and a great guide!

Some tips and tricks to add to it though:

You may also need to end up running hf iclass chk -f iclass_default_keys.dic on the source card if your system isn’t configured with elite keys. Moreover, if it is configured with a default key, the hf iclass info command will show you a decoded credential underneath the fingerprint info:


If you see that, you can likely just use the hf iclass encode command to write that data to the blank card


This process can be done in one shot with the hf iclass restore -f <dumpfile> --first 6 --last 18 -k <key>
You can change that to --first 5 to start at block 5 instead of 6, but I’m not certain that is necessary here


I believe it's also possible to run into a card like this that is set up with an SIO credential, which is tied to the UID, and means you're kind of out of luck cloning at the moment, without pursuing some form of downgrade attack
1 Like

the famed iclass SR.

as stated you can’t transplant the SIO, but what you can do is write just the PACs data to the iclass legacy and attempt to use it, if they have standard legacy enabled this will work, if they’re eager beavers about their maintenance and disabled non-sio legacy, it won’t work.

personally i’ve seen it work more times than not.

1 Like

SIO can’t be decoded by the PM3, right? You need something like an ESPKey?

1 Like

How can you tell if it’s an elite?

There are two dictionaries as far as I know, iclass_default_keys and iclass_elite_keys, it sounds like his source card’s keys were in that second one

1 Like

fuck my life good catch, disregard that moment of embarrassment i apologise.

AIA is set still as legacy on original which is just legacy turned elite, that and the title tripped me up. i’m tired lmfao

some tweaks id make to the wording n process but i’m going to go drown myself in shame

@offbrandman if you want me to throw your tutorial up on the wiki lmk i’ll get it posted up when im next up and about.

1 Like

something i can actually read and answer without looking like a twat!

aye proxmark can’t

depends on the SIO, legacy keyed (not elite with legacy aia) and SE need a weaponised normal HID reader (SE enabled if you’re going after SE)

elite keyed would need a weaponised reader from the system using that key to get the pacs binary

2 Likes

That makes sense, I hadn’t thought of that, thanks!

Nice try, that won’t stop me from harassing you with questions!

I’m doing this from memory now though, so lets see if any of this makes sense


You mentioned that legacy credentials all share a key, is that the main --ki key or just whatever the diversified key calcnewkey is for? Are they at all related?

This link:
https://www.proxmark.io/www.proxmark.org/forum/viewtopic.php%3Fid=5210.html
Talks about the different keys on picopass a little, and says:

This key is what is actually stored on the credential and is different for each credential since it is calculated using the CSN and the main authentication key.

But then I don’t understand why you’d want or be able to change that key with calknewkey if it’s generated from the card data, does elite change how that key works?

tl;dr: got any suggestions where I can go read and learn more about iClass legacy? Would stuff like that be in the datasheet?


If you were cloning an elite to a legacy (Is that possible?), you would need to update the AIA to reflect that it’s elite now?

2 Likes

legacy all have the same access key, tends to be --ki 0 but 1-2-3 and i believe 4 also exist for edge cases. the second hidden key is made up of stuff from inside the card for decoding

calcnewkey is just for elite, it’s for key rolling which is when you’re upgrading to elite and need to change the key of the card to be elite-ified in line with the to the xordiv to work on the system

if you’re going from legacy to legacy you don’t need to calculate it because they have the same key, you can’t xordiv something with itself you just get no change.

so yes you can downgrade elite to legacy IF the system still has legacy authentication enabled as an acceptable vector for receiving the PACs data, if they have disabled legacy on the reader it wouldn’t work

as for AIA nah, elite goes with SE or Legacy AIA depending on what card was used to be turned into an elite card, there’s no specific branding for elite besides decals on the cards themselves (ER - Encoder reader)(E - elite) (SR - legacy + SIO) etc. you can leave it as is.

as for research materials, datasheets are good but the white papers tell you more about he structure relevant to the card type you’re going with, can’t recommend heart of darkness enough, definitely worth the read.

find them all on
http://proxmark.org/files/Documents/13.56%20MHz%20-%20iClass/

(also just gonna toss these in here because theyre all incredible and teach you a lot especially because they need to lay some foundational knowledge before explaining their exploits)

https://youtu.be/Eef70bSRl_0?si=49f-2uAUWQgzNhOr

https://www.youtube.com/live/ghiHXK4GEzE?si=1mkyQaHTQ0a7r2Zd

https://youtu.be/EvbNQnZlPJg?si=rCXlfq3Zopcial7j

https://youtu.be/NARJrwX_KFY?si=53ApXvCJYCmRWAPn

2 Likes

It’s not possible to change the keys on a card to respond to the elite keys of a system?

What does this mean then?


That makes sense to me, except that the calcnewkey command includes an example for std to std, any idea why for?


Just for the rare instances when you find a legacy with an odd-ball key?


:heart_eyes:
Thanks!

And double-thanks again just for taking the time to answer the questions and letting me pick your brain :classic_tongue:

1 Like

so it is but you’re diversifying the key by what it was, to a valid key relating to the csn so that the system can build the correct key to access it. essentially the reader is doing that same calcnewkey operation, takes the csn, the legacy fingerprint and the key for the site (same one we used to read the memory) and then uses what it builds to request the PACs (+sio if it has it) and then authenticate. you’re basically burying the elite key inside all that other data so the system recognises it.

i hear you asking “but if the csn is involved doesn’t the system know it’s a different card” not if they’re not using SIO. if there’s no SIO then the reader just uses the csn to build the auth key, grab the PACS (fc/cn) and sends it to the panel to be checked to see if it is valid in the database

if they’re using SIO you’re short on luck because you can’t encode the SIO it’s fingerprinted to the CSN in which case they’d be using OSDP instead of wiegand on the readers.

so you’d better hope they’ve got legacy w/no SIO allowed as a means of auth. in which case you wouldn’t upgrade to elite.

so this std - std is going from one standard key to another (read previous about the niche different existing standard keys), in which case you would do the calcnewkey but you’re not really going to comes across anything but ki 0 because that is the default standard key, the others come from deployments where the MASTER key is changed, but if you do, that’s what you do.

precisely

E2A; i’m gonna refine this when i’ve got the time because my run on sentences are making me sieze, if it’s it super clear it will be later dw; also this is from my understanding which will be getting clarified with some experts in iclass later too incase i’ve said the wrong thing which is totally possible. if someone notices a mistake trust i’ll have been slapped for it already.

IMPORTANT this is a WIP don’t take it as bible yet plz and thanks

1 Like

:emoji_mindblown:

I always thought the readers just had a few keys programmed into them

Ha, I actually hadn’t made that connection, that’s a good point!


Greatly appreciated, I love learning about this stuff, so cool
1 Like

Great post, thanks for the callout (I should be on here more
)

One of the issues I see in general is that HID is :poop: about their naming conventions. I’m not exactly clear what the difference between a iClass DY (which was my source card) and a iClass DP card is.

The other issue I have is that DY cards can contain both SE and legacy data - some readers on my campus check the SE blocks, some don’t. It’s kind of a tossup what’ll work and what won’t. Does your calcnewkey fix this issue? I was under the impression that the serial number on the card was locked and couldn’t be overwritten.

1 Like

Hmm, now I’m confused again

Why do we need a dictionary chk command if we can just generated the auth key from the UID and on-chip key? And/or how does the reader get that on-chip data without the auth key to begin with?

1 Like

it’s not getting it from the card it’s getting it from the scheme the card is using, legacy is all the same key, SE is a KDF the system knows to use and elite is a key already known to the system

1 Like

no they can’t? legacy and SE is keying for the card, not relevant to specific blocks of data within the card, there is no SE blocks and legacy blocks

what it sounds like you’re experiencing is some readers allow your PACs data to be recieved via a legacy keyed credential, while others have legacy disabled, enforcing PACs to come through SE keyed cards, it’s not a split memory problem it’s a keying issue, one you can’t get around without identifying what (if any) ulterior chipsets are enabled for that reader that you could pass your PACs through.

RE key rolling/calcnewkey: you can’t keyroll SE onto a new card because you don’t have the key in the first place, calcnewkey is for elite-keying which is different to SE. the only way to encode as SE would be to have one of those expensive AF HID encoders that run off a set amount of credits (read: amount of times it can be used to encode).

for markings

iClass is the only important word there. GY DY DP are all arbitrary manufacturing markers that do not inform the contents not encoding of the card.

iClass GY/DP etc is just telling you that it has an iclass chip in it. other markings such as E, ER, SE, SR can be found in other places printed on the card if encoded as such, or not at all if custom encoded. (note, SE obviously can also appear next to iClass but sometimes it doesn’t, instead being printed elsewhere like the bottom right hand corner)

TLDR; dissuade yourself of the notion that GY/DP/DL mean anything because they don’t. and also read this:
https://www.hidglobal.com/sites/default/files/documentlibrary/an0109_a.2_credential_id_markings_application_note.pdf

2 Likes

From this PDF:

Makes it look to me like it might be possible?

I don’t understand this
 different from the main --ki 0 auth key?
SE is SIO Enabled, right? SIO is just the credential part I thought?

1 Like

this is for emulating a card that has SIO, which requires having the same CSN (which you can’t do with a card hence the emulator)

no, SE is a different keying scheme from legacy, instead of using a static global base key (–ki0) it uses a KDF to derive keys specific to each card with no shaded base between them.

SIO can be applied to legacy, SE and Elite keyed cards. it is a way of encrypting the PACs content (credential) with factors specific to that card, CSN and Keying scheme.

SIO enabled cards are SR and are not inherently tied to any specific keying as all can have SIO because it’s a second form of authentication.

SE credentials don’t have anything specific done to their memory set apart from any other card type, not all SE credentials have SIO wrapped around their PACs content

1 Like