Help with HID Seos Downgrade to iClass Cloning

Support
1

Hey everyone, I’m currently trying to perform a downgrade attack on a reader, cloning my card from an HID Seos to an iClass legacy credential. Below are the tools I have available, as well as a description of what I have done so far.

Tools:

  • HID iClass SE Reader, “weaponized” with a Wiegand tap so I can read the binary output
  • Flipper Zero
  • Proxmark 3 Easy
  • Two Blank iClass cards (16k)

What I’ve Done:
Using the Wiegand tap and comparing several different cards on the same infrastructure, I’ve identified the protocol which I verified doing parity checks by hand. It’s a 48 bit protocol, with a site code and individual card numbers I have identified. I have the binary and can convert them to hex.

From what I understand, I need a way to get this 48 bit HEX string into block 7 of an iClass card? This is where I’m having a hard time. I understand there is some kind of encoding involved so I have to do more than just put block 7 onto a standard credential. Proxmark is coming in the mail. I have done as much reading as possible and am still struggling to understand the next step.

I’ve identified a reader which beeps when presented with an emulated iClass legacy credential, so i know an iClass card properly configured would likely work as a downgrade attack. ALTHOUGH - I would prefer to just emulate the card on my flipper, which is a possibility with the Picopass app. I just would need to format it like the following:

Filetype: Flipper Picopass device
Version: 1
Credential: 00 00 C0 00 45 02 1E 58
# Picopass blocks
Block 0: 6D C2 5B 15 FE FF 12 E0
Block 1: 12 FF FF FF 7F 1F FF 3C
Block 2: FF FF FF FF 05 FE FF FF
Block 3: B2 45 35 54 FC 7F 41 48
Block 4: FF FF FF FF FF FF FF FF
Block 5: FF FF FF FF FF FF FF FF
Block 6: 03 03 03 03 00 03 E0 17
Block 7: 78 36 02 A2 28 30 10 E8
Block 8: 2A D4 C8 21 1F 99 68 71
Block 9: 2A D4 C8 21 1F 99 68 71
Block 10: FF FF FF FF FF FF FF FF
Block 11: FF FF FF FF FF FF FF FF
Block 12: FF FF FF FF FF FF FF FF
Block 13: FF FF FF FF FF FF FF FF
Block 14: FF FF FF FF FF FF FF FF
Block 15: FF FF FF FF FF FF FF FF
Block 16: FF FF FF FF FF FF FF FF
Block 17: FF FF FF FF FF FF FF FF

So, is there a way to calculate what the other values would need to be by hand, provided I have 48 bits I know I need to have in block 7? Also, what do I do since the credential above (which makes the reader beep when I emulate it on the flipper) has 64 BITS but I only have 48 to offer from my Seos Credential??

2 Likes
2

paging @philidelphiaChickens who i hear is a wizard

1 Like
3

Here’s an example iClass Legacy credential:
Encoded

And again after using hf iclass decrypt

Decoded

In the second picture that 06 54 7E 68 is the actual wiegand data

You should be able to use a combination of the hf iclass encode and the hf iclass encrypt commands to duplicate the above with the wiegand data that you’ve ripped from the SEOS card

If you feel like sharing that wiegand data, I can give it a try on my card and try to give you a more copy-paste-able couple of commands

Edit: Okay, I’ve played with it, and it looks like the hf iclass encode command does the encrypting all in one go, so that should be the only command you need

1 Like
4

Thank you so much for your reply!

So, in theory since I already have the weigand binary data, I can just use hf iclass encode on that binary string and it will auto encode everything else on the credential for me? How do I know it is using the right key to encode? ALSO - can I use the proxmark software to do the encoding for me without a proxmark, and then just copy the HEX bits over to my picopass file to emulate on the flipper like I mentioned above?

I really appreciate you taking the time to explain these things. I’m just barely getting my feet wet but have wanted to learn about this stuff for a long time!

1 Like
5

Seems that way!

hf iclass chk -f iclass_default_keys.dic but it’s probably --ki 0

Possibly, the hf iclass encrypt command might work for that, but you’d have to tinker with it

I’m not really familiar enough with the Flipper’s inner workings to guarantee that, but I don’t see why not

2 Likes
6

It looks like you would just go block by block with it, but it should work even without the PM3

2 Likes
7

A few more questions:

The only way I will know if it is encoding using the right key is just by testing the vulnerable reader by making a card or emulating one, correct? It’s a trial and error thing? I don’t have access to an existing legacy credential that works with the system, only my Seos card.

If a group is participating in Corporate1000 and using one of those protocols, is it likely that they are using/were using a proprietary key to encode the iclass cards?

Thanks again for the mentoring.

1 Like
8

Those are questions probably best aimed at someone like @equipter, I don’t have that much practical experience with the systems, I just like playing with the cards :classic_tongue:

I think I read somewhere that readers can be set up with a few different keys, so if your cards take the default --ki 0 key the reader has a good chance of being able to talk to them

You may be able to sniff the correct key from the reader as well, not sure if the flipper can do that though

I also have no idea if you can even change the key that a card responds to

2 Likes
9

All right! I am back with some good news. I was able to successfully take the binary data and hf iclass encode --bin <binary> --ki 0 which encoded to a blank iClass card that i have. And… it worked on the reader! Now, I have a few follow up questions…

  1. HOW does iClass actually encode data to blocks 6-9 using --ki 0? I know there are some stored default keys… but WHAT is it actually doing bit-wise, where is the key stored, how does that work? Does it use a different key hidden on each card? Is it encrypted using the same key for all iClass cards? I have been unable to find any clear documentation or insight on this. If anyone has a detailed explanation on this I am all ears.

  2. How do I obtain the same blocks 6-9 that I obtained by feeding the binary/hex to hf iclass encode, but WITHOUT actually encoding to a card? That is, just getting the blocks that the pm3 WOULD write if there was a card present. I’d like to manually create a .picopass file and emulate on the flipper (or pm3!) rather then having to make a physical card every time. Can hf iclass encrypt do that? If so, could someone guide me through that?

  3. Are iClass cards single write only? Can you write multiple times? Do they have a lock bit / section? I’m using 16k iClass GL cards.

I am so glad I stumbled across this forum. You guys are great!

1 Like
10

Now that you have the card you can use hf iclass dump --ki 0 to see the data if you wanted, but you can also use the encrypt command for that, let’s look at my demo card again:
Decoded

Encoded
You can see that block 6 doesn’t change much, so we’ll skip that one, it doesn’t seem to be fully encrypted. I’m honestly not sure why the last byte changes

If I take block 7 from the unencrypted image 0000000006547E68 and run it through hf iclass encrypt -d 0000000006547E68 it spits out: 769CB4A198E0DEC8 which you can see matches block 7 in the encrypted image

Repeat for blocks 8 and 9 and you’re good to go

The key isn’t stored anywhere on the card that we can get at it, the card just knows to only respond to requests that properly authenticate with it

Most iClass legacy cards are protected with one of a number of default keys, by far the most common one is stored in --ki 0 on your pm3, for more info on the keys in your PM3 right now try hf iclass managekeys -p. HID did offer unique keys for iClass cards marketed as Elite keys, those can be more troublesome for us

They are re-writable. They probably have lock bits, but I don’t know enough about their config to tell you for sure. So long as you only play with the credential blocks 6-9, you should be fine, in my experience

1 Like
11

I only appear 10 days later… Sorry.

This is correct. As long as you aren’t modifying blocks before block 6, you aren’t running a risk of locking it.

I honestly think the best way to think of these is to think of them as glorified encryption keys. If you don’t have the correct key, it’ll spout bad data, or no data at all. Cards are honestly a little suprisingly powerful - we forget that those cards take the same amount of power to nicely get an xLED or xSIID lit up.

I’m most familiar with 2k cards, but you shouldn’t have any issues. The 16 vs 2k is a difference in overall data storage capacity, not in the transmission networks.

2 Likes
12

Do you happen to know what’s going on with that last byte in block 6? Only thing I can think of is that being how the reader determines if the credential is plaintext or encoded

13

to answer your question super late, you’d be correct, if the last byte of block 6 is 0x17 then it’s encrypted. more details here

4 Likes