iClass is coming...

midnitesnake · 2014-05-07 11:43:03

proxmarkzzz wrote:

According to this article it should produce something like:

   key: 1122334455667788
   csn: bbbbaaaabbbbeeee

 hash2: 8a e9 68 11 03 52 6e 2e bb 3f ec dd da 8e 90 e8 
        b3 90 09 54 b1 b4 5f e8 7e dd 37 3f 0d 00 e1 ee 
        61 f8 ea 79 fe f6 be 5e a6 15 16 84 ef 6d a2 0a 
        06 1a 3e d4 4b 19 b9 8d 1a a8 77 30 9c 0e d5 ee 
        35 d0 1b 73 e1 76 65 b2 dc 1f 4e cc e3 8d 2f f4 
        12 27 0c 9e c2 88 87 b1 d7 3d 60 d7 5c ed eb a5 
        a7 1f 96 5f d5 fc d6 a1 e2 42 c1 70 fb 99 06 ee 
        58 08 4c f7 37 fd a0 4e f4 de 46 fa 31 b6 98 5e 
        
 hash1: 001c365508601122

  Ksel: 6c8d44f92a2d01bf

Ok, I have hash1 down. No problem there.

but according to above z0 = e9 11 52 2b 3f dd 8e e8

but when i try z0=des_ecb(key, ~key) = f2 e7 33 d7 35 fe ae 2c

and I thought Ksel(i)=h(hash1(id)(i) ) (where h = hash2(Kcus))
so I thought 00 = 8a, 1c = 0d ....

Is it possible to have another hash2 example, to figure out where Ive obviously gone wrong.

Thanks

0xFFFF · 2014-05-07 13:05:15

Certain Omnikey 5427 readers have a lot more keys in them.

carl55 · 2014-05-07 16:27:23

@midnitesnake
It appears that you simply missed the key permutation.
If you permute [6c 8d 44 f9 2a 2d 01 bf] you get [8a 0d b9 88 bb a7 90 ea] as shown below.

1 0 1 1 1 1 1 1 bf
0 0 0 0 0 0 0 1 01
0 0 1 0 1 1 0 1 2d
0 0 1 0 1 0 1 0 2a
1 1 1 1 1 0 0 1 f9
0 1 0 0 0 1 0 0 44
1 0 0 0 1 1 0 1 8d
0 1 1 0 1 1 0 0 6c

8 0 b 8 b a 9 e
a d 9 8 b 7 0 a

app_o1 · 2014-05-07 16:28:07

Does anyone know what is the difference between a 5321 V1 and a 5321 V2 ?

Since Meriac publication (in 2011 ?), the only difference I have seen was the release of new drivers that make writing commands fail. But they were aware of the exploit before that...

carl55 · 2014-05-07 21:49:36

@midnitesnake
I think part of the confusion is due to the fact that the iClass reader algorithms (e.g hash2 key tables) use permuted keys whereas the OmniKey reader uses non-permuted keys.

Here is another example:

Key: 0xDEADFEEDDEADFEED
This is the permuted high security "Elite" key that is stored in the iclass reader EEPROM. It is also the same value stored in a configuration card that would be used to place the reader into high security "Elite" mode of operation.

CSN: 01020304F7FF12E0 - UID stored in Block 0 of iClass card.

hash2: 19 3F A5 E9 B8 39 9B 28 C3 08 EE C8 AB 1E C5 39
       01 66 1A FE 33 C8 E0 AD AC 9A 54 37 B3 FE 6E 8F
       22 EA BB F1 DB 7B C6 C1 88 5F FC A2 36 03 41 7A
       AC 2B E6 03 1C 04 CE AA DD 5D 0C 15 5A A4 2E 97
       3F 55 7D 4E 02 2F FE 23 1A 12 EB 0A DA 1F F1 BD
       9E 93 1E CF 4A 90 24 5D 6A 75 0E AA 7E 81 4A B1
       EA F6 12 59 EA CC AA 34 63 2A 6A 49 D0 3E 48 B8
       30 26 D3 45 A5 F3 0F 6A 42 29 FF 42 C2 1E 9A FE

hash1: 7E722F402D025142 - Eight index values that are used as pointers into the above key table

Ksel: 5FFA15B1F33561C6 - Pre-fortified key that would be needed by the OmniKey reader to talk to above CSN.
Ksel(p): 9AD37A3F03A5937D - Pre-fortified "permuted" HS key that would be needed by an iclass reader to talk to above CSN.
hash0: 056A1DE5284A49A2 - hash0 result (aka diversified key) that is computed using Ksel and stored in the card (Block 3).

**NOTE: This post was edited due to a previous error with the key. All of the data has been re-calculated.

Last edited by carl55 (2014-05-08 15:32:27)

midnitesnake · 2014-05-07 22:43:12

@carl55

Thanks, for the additional examples. I didn't see the permute reference in this article, so I was missing the permute bit. Thats now sorted within my code.

I still can't generate my own hash2 though:

key :00 00 00 00 de ad fe ed
~key:ff ff ff ff 21 52 01 12
z[0]=DESenc(key,~key)
z[0]:91 f0 a0 bc 91 8b 5a f9

UPDATE:
Still not sure, proxmarkzzz example works for me,except the hash2 bit, with carl's example again hash2 fails and hash0 fails:

Proxmarkzzz
hash1: 00 1c 36 55 08 60 11 22 
key permute:6c 8d 44 f9 2a 2d 01 bf
CSN Key : bb bb aa aa bb bb ee ee 
{CSN}Key: d6 ad 3c a6 19 65 9e 6b 
Div Key : cd 58 8a c8 3a ff 19 db 
----------------------------------------
Carl55
hash1: 7e 72 2f 40 2d 02 51 42
key: 9a d3 7a 3f 03 a5 93 7d 
key permute : 5f fa 15 b1 f3 35 61 c6 
CSN Key : 01 02 03 04 f7 ff 12 e0 
{CSN}Key: 1c 10 7b 04 e6 c8 01 a7 
Div Key : 50 4d 29 10 9b 06 6c 43

Last edited by midnitesnake (2014-05-11 22:15:23)

asper · 2014-05-08 07:42:45

app_o1 wrote:

Does anyone know what is the difference between a 5321 V1 and a 5321 V2 ?
Since Meriac publication (in 2011 ?), the only difference I have seen was the release of new drivers that make writing commands fail. But they were aware of the exploit before that...

http://www.case.at/static/media/uploads/Files/omnikey_5321_v2_faq.pdf

I am not able to sniff (with pm3) a communication between an epa and omnikey 5321 v2 while it works using a mobile phone to read the epa.

holiman · 2014-05-10 21:01:54

Everyone with FPGA knowledge, don't miss this thread about my investigation into iclass simulation issues:
http://www.proxmark.org/forum/viewtopic … 279#p11279

carl55 · 2014-05-11 15:01:14

Good work in the above referenced post and a very nice summary of your test results. Hopefully you have zeroed in on the PM3 iclass problem. It would be nice to finally put this issue to bed. The PM3 has always worked somewhat intermittent with the RevA iclass readers and not at all with the newer version readers. I believe HID may have used a different 13.56Mhz Reader IC in the later version readers which may be less tolerable of the condition you described. I do know that the latest iClass SE reader design uses an Inside Contactless "PicoRead" reader chip for the front end RF interface.

0xFFFF · 2014-05-12 00:02:56

carl55 wrote:

I believe HID may have used a different 13.56Mhz Reader IC in the later version readers which may be less tolerable of the condition you described. I do know that the latest iClass SE reader design uses an Inside Contactless "PicoRead" reader chip for the front end RF interface.

Where did you get that information from?
I have R10 SE readers with CLRC663s in them.

carl55 · 2014-05-12 00:31:50

 Where did you get that information from?
I have R10 SE readers with CLRC663s in them.

I un-potted an R40 iClassSE reader. The 16-pin SSOP chip that is located on the backside of the PCB along with the other RF interface components is labeled "PicoRead".

0xFFFF · 2014-05-12 04:30:33

Interesting. What h/w f/w revision?

*Can we continue this here?

proxmarkzzz · 2014-05-14 08:28:06

With a stored (permuted) key:

DEADFEEDDEADFEED

The output that is computed with the keys in "normal" notation probably looks something like:

   key: 55aaffffaa77bbff
   csn: 01020304f7ff12e0

 hash2: 19 3f a5 e9 b8 39 9b 28 c3 08 ee c8 ab 1e c5 39 
        01 66 1a fe 33 c8 e0 ad ac 9a 54 37 b3 fe 6e 8f 
        22 ea bb f1 db 7b c6 c1 88 5f fc a2 36 03 41 7a 
        ac 2b e6 03 1c 04 ce aa dd 5d 0c 15 5a a4 2e 97 
        3f 55 7d 4e 02 2f fe 23 1a 12 eb 0a da 1f f1 bd 
        9e 93 1e cf 4a 90 24 5d 6a 75 0e aa 7e 81 4a b1 
        ea f6 12 59 ea cc aa 34 63 2a 6a 49 d0 3e 48 b8 
        30 26 d3 45 a5 f3 0f 6a 42 29 ff 42 c2 1e 9a fe 
        
 hash1: 7e722f402d025142

  Ksel: 5ffa15b1f33561c6
 {csn}: 1c107b04e6c801a7

           | x| y|z0|z1|z2|z3|z4|z5|z6|z7|
 original:  1c 10 27 06 00 32 26 13 30 1e 
   x|y|z':  1c 10 27 07 02 35 26 14 32 21 
   x|y|z^:  1c 10 27 07 02 35 26 14 32 21 
   p|y|z^:  69 10 27 07 02 35 26 14 32 21 
   p|y|z~:  69 10 28 26 14 08 32 03 36 21 
        k:        50 4d 29 10 9b 06 6c 43 

 hash0: 504d29109b066c43

carl55 · 2014-05-14 15:26:46

I agree with all of the data in the above post. The hash0 part of the calculation in my earlier post was wrong.

@midnitesnake:
Send me an email ( info at proxclone dot com) if you are still having trouble with the hash2 algorithm.
I can send you some additional information that shows how the class reader implements the algorithm. It also includes a step by step example calculation.

midnitesnake · 2014-05-14 16:37:23

Thanks for your help (Proxmarkzzz and Carl55).

I can identify that my current problem is located within the key/permuted variant of the initial DES encryption. Hopefully I can solve this soon.

UPDATE:

Thanks, think I finally cracked it. Those last examples were really helpful.

Last edited by midnitesnake (2014-05-14 22:53:52)

holiman · 2014-05-14 19:43:25

I'll be glad to give a hand also, and incorporating yours and pentura_prox's code into the library.. You could either mail me or create a pull request

holiman · 2014-06-16 20:35:47

Update!

I've finally gotten some time with a legit reader again, and tested my code with the fixed fpga version. It worked fine, and I was able to perform the carl55-attack using 126 malicious CSNs (although, I think it missed one, I maybe only have 125 ). I've refined the code a bit into my iclass-fixes branch, and now it dumps out the results to a binary file.

Next (last?) part is to write some code which reads the dumpfile and performs the bruteforce using the iclass cipher implementation that we put together a while back.

midnitesnake · 2014-06-17 11:06:59

Following my previous post, I've automated the reading of the CSN and CC to dump standard iClass contents, now all you need is the magic-key; in theory should also work for elite cards:

proxmark3> hf iclass dump [magic key here]
#db#      Selected CSN: 87 4a 11 01 f8 ff 12 e0                 
#db# Readcheck on Sector 2                 
#db#      CC: fe ff ff ff ff ff ff ff                        
Calculated_MAC	5a61a146
#db# Readcheck on Sector 2                 
#db#      CC: fe ff ff ff ff ff ff ff                 
#db# Authenticate                 
#db#      AA: 5a 61 a1 46                 
#db#      AR: 2e e5 6c b9                 
#db# Dump Contents                 
#db#      00: 87 4a 11 01 f8 ff 12 e0                 
#db#      01: 12 ff ff ff 7f 1f ff 3c                 
#db#      02: fe ff ff ff ff ff ff ff                 
#db#      03: ff ff ff ff ff ff ff ff                 
#db#      04: ff ff ff ff ff ff ff ff                 
#db#      05: ff ff ff ff ff ff ff ff                 
#db#      06: 03 03 03 03 00 03 e0 17                 
#db#      07: 07 4f b8 50 a7 e8 aa 79                 
#db#      08: 2a d4 c8 21 1f 99 68 71                 
#db#      09: 2a d4 c8 21 1f 99 68 71                 
#db#      0a: ff ff ff ff ff ff ff ff  
...

Patch already sent to PenturaProx to commit / into his research, as I was using his iclass-research fork

Last edited by midnitesnake (2014-06-17 11:19:53)

iceman · 2014-06-17 13:13:26

Sweet!
Great work from both of you, Holiman and Midnitesnake!

holiman · 2014-06-21 23:51:26

I've updated the loclass library now, it can read dumpfiles from the reader-attack and recover the high security key table. I've removed potentially sensitive data from the dump below, but you get the picture.

[+] Testing iClass Elite functinality...[+] Testing key diversification ...
[+] Iclass key permutation OK!
[+] Testing three-byte crack from known values...
[+] Testing crack from dumpfile...
[+] Loaded dump file iclass_dump.bin
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 Found! 0x00,0x01,0x45 = [.. removed..]
[ removed some data here..]
Saved data to 'iclass_keytable_dump-11.bin'

Performed full crack in 213.419998 seconds

	High Security Key Table

00| .. removed
10| .. removed
20| .. removed 
30| .. removed
40| .. removed
50| .. removed
60| .. removed
70| .. removed

Next steps: recover The 64-bit HS Custom Key Value and plug everything into pm3.

holiman · 2014-06-23 13:24:15

Update: I've implemented calculation of custom key now. Then I looked a bit more on "dismantling", and started experimenting with using more "optimal" csn-values instead of 126. I haven't verified these numbers, but my python-hacky-implementation of hash1 found these values (on left you can see what bytes are obtained):

    set([ 2,  8]) csn:  20 a8 0f ff f7 df 12 43 -> hash: 01 01 00 00 45 02 45 08
    set([ 3,  6]) csn:  04 8b 0d fd f7 ff 94 e0 -> hash: 03 03 00 00 45 01 06 45
    set([ 4,  5]) csn:  cc d3 0f ff e3 ff 12 e0 -> hash: 01 01 04 00 45 01 05 45
    set([ 7,  9]) csn:  02 e9 0f ff f7 3f 12 c0 -> hash: 01 01 00 00 45 07 45 09
    set([10, 13]) csn:  00 18 0f ff f7 ff a2 43 -> hash: 01 01 00 00 45 01 0d 0a
    set([11, 12]) csn:  00 5a 0f ff f7 ff a0 03 -> hash: 01 01 00 00 45 01 0c 0b
    set([14, 15]) csn:  00 33 0f af f7 cd 12 3a -> hash: 01 01 00 01 45 0e 45 0f

First three same as before, and then each csn only needs to 2^16 calculations, and yields two bytes - which are all within the first 16 bytes of the key lookup table (we only need the first 16 bytes to calculate the custom key).

All fits within 8 malicious CSNs, which takes about ten seconds to perform against a reader (as opposed to a couple of minutes). I think I will switch to this variant before I commit my things to pm3-head (but first I need to verify that my calculations were correct).

Last edited by holiman (2014-06-23 13:24:32)

carl55 · 2014-06-23 15:05:49

That would really be great if that approach works, however ....

I was under the impression that the iclass readers will only attempt authentication with a tag that it has determined to be a valid iclass credential. In other words the CSN needs to be "XX XX XX XX XX FF 12 E0". I believe that the reader enforces this rule in order to prevent off-the-shelf "Picopass" cards from being programmed (and sold) as "functionally equivalent/counterfeit" iclass cards.

The ISO/IEC CD 7816-13 document, titled "Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 13: Registration of integrated circuit manufacturers" specifies that the smart card used by Inside Contactless has been assigned a CSN code of "12" which means that all of their cards 64-bit CSN starts with 0xE012. The remaining 48-bits can be used by them in any way that they please. I am assuming that official HID iClass cards have been assigned their own sub-block of numbers so as to prevent any unauthorized "iclass clones" from entering the market.

If this is true then the hash1 values that you selected may not work as you intended. The only way to know for sure is to run a test on a real system. Hopefully my information is wrong and your approach can be used as you suggested to simplify the high security key recovery process.

holiman · 2014-06-23 20:32:53

Wow, thanks a lot for catching that. I'd never have spotted such a thing (deep within specs). I let the computer generate some more heat, this is what I came up with. The left column shows what bytes are 'won' by each csn, the middle what values the hash consists of (minus 00,01,0x45):

bytes|--requires----------|--- csn -----------------------| hash -------------------------|
2,12 |set([2, 12])        | csn:  00 13 94 7e 76 ff 12 e0 | hash: 02 0c 01 00 45 01 45 45
7,11 |set([7, 11])        | csn:  2a 99 ac 79 ec ff 12 e0 | hash: 07 45 0b 00 45 01 45 45
3,15 |set([3, 15])        | csn:  17 12 01 fd f7 ff 12 e0 | hash: 03 0f 00 00 45 01 45 45
4,8  |set([4, 8])         | csn:  cd 56 01 7c 6f ff 12 e0 | hash: 04 00 08 00 45 01 45 45
6,14 |set([6, 8, 14])     | csn:  4b 5e 0b 72 ef ff 12 e0 | hash: 0e 06 08 00 45 01 45 45
9,5  |set([9, 11, 15, 5]) | csn:  00 73 d8 75 58 ff 12 e0 | hash: 0b 09 0f 00 45 01 05 45
10,13|set([10, 13, 15, 5])| csn:  0c 90 32 f3 5d ff 12 e0 | hash: 0d 0f 0a 00 45 01 05 45

holiman · 2014-06-25 21:21:19

So, now I've 'finished' loclass https://github.com/holiman/loclass/(for now). The bruteforcer I implemented https://github.com/holiman/loclass/blob … te_crack.c can read a dump which has been saved by pm3.
The bruteforcer takes each dump-item, determines what bytes are required (hash1 of csn) and commences bruteforcing the bytes which are possible (but it does not try to bruteforce more than three bytes at a time). So, that code does not care what sequence of CSNs are used, it "just works". It can be invoked from commandline with ">./loclass -f iclass_dump.bin".

I'll try to commit my iclass-fixes branch to main soon, then import the patches midnitesnake and penturaprox.

holiman · 2014-06-27 12:20:30

I've pushed some new code to iclass-fixes branch of proxmark github now.https://github.com/Proxmark/proxmark3/tree/iclass-fixes

I think it's stable enough to go into main, but it would be nice if someone other than me confirmed that it works. It adds 'hf iclass sim 2', which uses the 8 malicious CSNs, saves the response-data into a dumpfile. After that, you can use loclass to bruteforce the dumpfile, as I've not yet integrated loclass with pm3.

iceman · 2014-06-27 14:43:15

before I had both yours and penturas version mixed in a codeversion. I noticed that you had similar code, so if you will merge both codebases someone with insight should look over the differences in code otherwise I fear that there will be more duplicate code laying around then necessary.

holiman · 2014-06-27 20:20:38

Yep, I know. penturalabs version has been submitted as a pull-request to github, I will merge the functionality into iclass-fixes. However, I merged everything from head into iclass-fixes today. I will go on away on holiday for a few weeks (beginning next week), so I won't do much during that time. But just so you guys know, iclass elite haxxoring is now functional and available.

iceman · 2014-06-27 21:11:23

You have done great work, and so did Carl and Midnitesnake and Pentura aswell. Enjoy your vaccation, have a good one and drink some great beers for you are worth it.

holiman · 2014-06-28 19:56:20

I have
- Pushed iclass-fixes to master
- Merged penturalabs pull-request, into a new branch. https://github.com/Proxmark/proxmark3/tree/PenturaLabs-iclass-research. This branch compiles, but I haven't checked if the functionality is intact. I have access to an iclass card for a few more days, I will try to test it against an elite card and see if I can dump the contents.

midnitesnake · 2014-06-29 09:36:19

Applied changes in Pentura-labs-iclass-research to fix "iclass dump". Changed the doMAC function in loclass to support CCNR's of different lengths - which is needed when writing to cards. Also changed diversifyKey in keys.c, had to uncomment:
uint64_t crypted_csn_swapped = swapZvalues(crypt_csn);

RadioWar · 2014-07-14 06:59:34

who can give me compiled stand-alone Windows versions ? i want to test iclass dump

midnitesnake · 2014-07-17 11:23:21

I have pushed some of the iclass developments between Pentura_Prox, Holiman and myself into the unstable branch.

Not quite working the same, but I have noticed changes in the firmware between the fork. While using the Pentura_Prox version everything was working ok as expected.

When I moved to the latest github repo, testing the firmware (flasher /dev/xxx armsrc/obj/osimage.elf) ended up bricking my device. I've since recovered the Proxmark via JTAG, and successfully got the main branch working correctly. I've ported the iclass developments into unstable, but its not running as smoothly? could be down to the fact I'm using the RyscCorp HF antenna that came with the proxmark?

Sometimes, the dump option fails to dump the contents, or incorrectly classifies a valid MAC as authentication failure.
Othertimes, it fails to accurately collect the CSN and CC, which affects MAC calculation.

More testing is required.

proxmark3> hf iclass dump [magic key here]
#db#      Selected CSN: 87 4a 11 01 f8 ff 12 e0                 
#db# Readcheck on Sector 2                 
#db#      CC: fe ff ff ff ff ff ff ff                 
DEBUG: 87 4a 11 01 f8 ff 12 e0           
DEBUG: fe ff ff ff ff ff ff ff           
isOk:00          
DES Key: 7d 32 56 b6 90 61 51 c1           
DESr Key: 7d 32 04 75 58 41 aa d5           
Div Key: 21 fc 37 12 a5 d0 31 38           
Calculated_MAC	5a61a146
proxmark3> hf iclass replay 5a61a146
#db# Readcheck on Sector 2                 
#db#      CC: fe ff ff ff ff ff ff ff                 
#db# Authenticate                 
#db#      AA: 5a 61 a1 46                 
#db#      AR: 2e e5 6c b9                 
#db# Dump Contents                 
#db#      00: 87 4a 11 01 f8 ff 12 e0                 
#db#      01: 12 ff ff ff 7f 1f ff 3c                 
#db#      02: fe ff ff ff ff ff ff ff                 
#db#      03: ff ff ff ff ff ff ff ff                 
#db#      04: ff ff ff ff ff ff ff ff                 
#db#      05: ff ff ff ff ff ff ff ff                 
#db#      06: 03 03 03 03 00 03 e0 17   
...

Antenna stuff:

proxmark3> hw tune
#db# Measuring antenna characteristics, please wait...                 
#db# Measuring complete, sending report back to host                 
          
# LF antenna:  0.13 V @   125.00 kHz          
# LF antenna:  0.00 V @   134.00 kHz          
# LF optimal:  0.00 V @ 12000.00 kHz          
# HF antenna:  9.05 V @    13.56 MHz

asper · 2014-07-17 12:47:12

I man, it seems that your antenna is not as good as it should be... can you test with a better antenna (higher voltage) ?

holiman · 2014-07-19 20:18:48

@midnitesnake , I'm not a git wizard.. but what's the status of the files in unstable? Did you start from "my" penturaprox_iclass_research branch, or did you "branch off" from something else? It'd be great if we could designate a proper "iclass"-branch, where we can collaborate to get everything working. I'm fine with switching to the unstable branch, but does it contain the same things that "my" branch contains? I put some work into importing all pentura-stuff into my elite-stuff earlier..

Neuer_User · 2014-07-20 07:36:34

@holiman
have a look here : https://github.com/Proxmark/proxmark3/network

midnitesnake · 2014-07-20 09:03:44

@holiman; its just loclass and some of the methods for dumping cards we were working on.

I updated to the latest git version, and something broke? I had to reflash my proxmark over JTAG. Not sure what changed, so I whacked my/our stuff in unstable so others could easily test. It can easily be replaced when your elite stuff is finished.

Its mainly because I know the user behind Pentura_prox is no longer at Pentura and unlikely to be around, unless he resurfaces under another handle?

holiman · 2014-07-20 11:53:11

Regarding your bricking, that's because izsh made some heavy changes, requiring the bootrom to be updated aswell. There's a closed issue in github about that.

In the 'PenturaLabs-iclass-research' branch, I took all available code from pentura_prox, and re-imported loclass (which had changed a lot since penturaprox added it), and made everything compile. Then I started some refactoring to make it less copy-paste-based. Unfortunately, I do not have access to standard cards, so was unable to do the last tests, and I wasn't able to get elite-dumping to work as intended.

@midnitesnake, could you please instead check out that branch and
1. Check if you are missing something that is present in your code but not in that branch
2. See if you can get dump to work on iclass standard?

midnitesnake · 2014-07-20 12:47:51

OK - dump works correctly on your branch.

Something isn't quite right with unstable (as i mentioned above), even though the code is identical to pentura-prox's version. I'm going to try and create my own hirose antenna this week, and see if that makes a difference.

EDIT: Built a hirose antenna from scratch

without card

proxmark3> hw tune
#db# Measuring antenna characteristics, please wait...                 
#db# Measuring complete, sending report back to host                 
          
# LF antenna:  0.13 V @   125.00 kHz          
# LF antenna:  0.00 V @   134.00 kHz          
# LF optimal:  0.00 V @ 12000.00 kHz          
# HF antenna: 12.54 V @    13.56 MHz          
# Your LF antenna is unusable.

with card

proxmark3> hw tune
#db# Measuring antenna characteristics, please wait...                 
#db# Measuring complete, sending report back to host                 
          
# LF antenna:  0.13 V @   125.00 kHz          
# LF antenna:  0.00 V @   134.00 kHz          
# LF optimal:  0.00 V @ 12000.00 kHz          
# HF antenna:  5.22 V @    13.56 MHz          
# Your LF antenna is unusable.

I can now rule out the antenna. Appears to be more of a timing issue? sometimes dump will work, other times it ends after calculating the MAC for card authentication. Think I need to write in more error detection / correction into the routine.

Last edited by midnitesnake (2014-07-22 17:11:57)

goaz · 2014-07-30 10:29:53

how can get the magic key?

holiman · 2014-07-30 12:38:00

@midnitesnake - when you say 'identical', are you sure?

Can't you just keep working on "my" branch, and ignore unstable? That way we will all be collaborating...

holiman · 2014-07-30 12:40:37

@goaz , in case of elite, it can be dumped by doing 'hf iclass sim x' (if i recall correctly). Then you take the dump binary, and run it through loclass - it's all in existence, but I've not yet connected the dots. If it is iclass standard and not elite, the key can be dumped from firmware in a few different ways. Some people have access to the key, but afaik it's not been publically leaked anywhere (yet), and I don't want to leak it here myself either.

meccan · 2014-08-04 11:36:16

I'm using PenturaLabs-iclass-research/v1.0.0-39-g9e28ee9-suspect 2014-08-04 and I'm quite impressed on the progress with iclass on the proxmark. However, I noticed that when dumping standard security cards the script sometimes stops before dumping, or I get an authentication error, some cards seem to always give an authentication error although they are definitly standard security and the "magic key" correct. On the contrast, when it works it gives me the same results as it would with Omnikey + Copyclass.

Furthermore, how is implementing write functions going? eg. hf iclass write <key> 10 11ffffff7f1fff3c just gives me a "Block data must include 8 HEX symbols" and if I shorten it down to 8 HEX symbols (is it not suppose to be 16?) I get an "#db# unknown command:: 0x0397 ". Is that just me not doing it right?

midnitesnake · 2014-08-04 21:05:04

write functionality hasn't been finished. Personally, I've been too busy to resume coding... hopefully I can finish it soon. The guy behind Pentura_Prox left Pentura so the account is now dead? I'm awaiting for him to resurface and help out?

As for the dump, from analysing the debug statements - sometimes the CSN & CC aren't correctly read in, which generates the error your seeing. I agree its no different than copy class at the moment, but least its on the proxmark; we need to add the 3DES decryption routine.

Progress is happening, but I'm afraid slow...

Last edited by midnitesnake (2014-08-04 21:08:41)

holiman · 2014-08-17 18:39:58

Slow here too, I'm afraid. I lost access to the iClass elite system before summer, hope to get some more time hands-on with one this fall, in order to tie up all loose ends (dumping elite, making things more stable). In the meanwhile, I wrote a blog post: http://martin.swende.se/blog/Elite-Hacking.html .

holiman · 2014-09-19 08:48:49

I've merged the iclass-branch into head now, please report if there are any issues, I heard some talk about build-issues on windows, but I've had no problems building on linux.

asper · 2014-09-20 13:01:04

It compiles fine under my win environement; added pm3-bin-0.0.5 to the specific thread's 1st post. Thank you holiman !

Last edited by asper (2014-09-20 13:01:51)

holiman · 2014-12-14 22:00:21

carl55 wrote:

That would really be great if that approach works, however ....
I was under the impression that the iclass readers will only attempt authentication with a tag that it has determined to be a valid iclass credential. In other words the CSN needs to be "XX XX XX XX XX FF 12 E0". I believe that the reader enforces this rule in order to prevent off-the-shelf "Picopass" cards from being programmed (and sold) as "functionally equivalent/counterfeit" iclass cards.
The ISO/IEC CD 7816-13 document, titled "Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 13: Registration of integrated circuit manufacturers" specifies that the smart card used by Inside Contactless has been assigned a CSN code of "12" which means that all of their cards 64-bit CSN starts with 0xE012. The remaining 48-bits can be used by them in any way that they please. I am assuming that official HID iClass cards have been assigned their own sub-block of numbers so as to prevent any unauthorized "iclass clones" from entering the market.
If this is true then the hash1 values that you selected may not work as you intended. The only way to know for sure is to run a test on a real system. Hopefully my information is wrong and your approach can be used as you suggested to simplify the high security key recovery process.

Actually, I've now had the chance to test it (actually, not me, but someone else). It turns out that the required format is not only "XX XX XX XX XX FF 12 E0" but some additional requirements are in place. Perhaps "XX XX XX XX F7 FF 12 E0" is needed? The csn's I had chosen were not accepted.

I've pushed some fixes to trunk now.

holiman · 2014-12-19 08:58:14

The forum user omikron has helped me putting the finishing touches on the iclass elite implementation. Two things were wrong:
- The CSNs used were not accepted by the reader
- There was a bug in hash1, causing 'dump' to fail.

With these issues fixed, he has now been to attack the reader, crack the key and dump an elite tag - all using pm3!
The dump is still a bit flaky, it works only sometimes. I hope to get my hands on some tags and a reader soonish, and
1. to get dump into being stable,
2. to be able to do full-data simulation.
3. to be able to dump elite card, store dump, program blank std-tag into a 'clone' of the elite card (but with it's own CSN)

iceman · 2014-12-19 13:51:14

I don't know if I said it before but Holiman, you have done great work here. For that I am thankful.

asper · 2014-12-19 16:46:17

I agree with iceman ! Thank you !!

Proxmark3 community

Announcement

#51 2014-05-07 11:43:03

Re: iClass is coming...

#52 2014-05-07 13:05:15

Re: iClass is coming...

#53 2014-05-07 16:27:23

Re: iClass is coming...

#54 2014-05-07 16:28:07

Re: iClass is coming...

#55 2014-05-07 21:49:36

Re: iClass is coming...

#56 2014-05-07 22:43:12

Re: iClass is coming...

#57 2014-05-08 07:42:45

Re: iClass is coming...

#58 2014-05-10 21:01:54

Re: iClass is coming...

#59 2014-05-11 15:01:14

Re: iClass is coming...

#60 2014-05-12 00:02:56

Re: iClass is coming...

#61 2014-05-12 00:31:50

Re: iClass is coming...

#62 2014-05-12 04:30:33

Re: iClass is coming...

#63 2014-05-14 08:28:06

Re: iClass is coming...

#64 2014-05-14 15:26:46

Re: iClass is coming...

#65 2014-05-14 16:37:23

Re: iClass is coming...

#66 2014-05-14 19:43:25

Re: iClass is coming...

#67 2014-06-16 20:35:47

Re: iClass is coming...

#68 2014-06-17 11:06:59

Re: iClass is coming...

#69 2014-06-17 13:13:26

Re: iClass is coming...

#70 2014-06-21 23:51:26

Re: iClass is coming...

#71 2014-06-23 13:24:15

Re: iClass is coming...

#72 2014-06-23 15:05:49

Re: iClass is coming...

#73 2014-06-23 20:32:53

Re: iClass is coming...

#74 2014-06-25 21:21:19

Re: iClass is coming...

#75 2014-06-27 12:20:30

Re: iClass is coming...

#76 2014-06-27 14:43:15

Re: iClass is coming...

#77 2014-06-27 20:20:38

Re: iClass is coming...

#78 2014-06-27 21:11:23

Re: iClass is coming...

#79 2014-06-28 19:56:20

Re: iClass is coming...

#80 2014-06-29 09:36:19

Re: iClass is coming...

#81 2014-07-14 06:59:34

Re: iClass is coming...

#82 2014-07-17 11:23:21

Re: iClass is coming...

#83 2014-07-17 12:47:12

Re: iClass is coming...

#84 2014-07-19 20:18:48

Re: iClass is coming...

#85 2014-07-20 07:36:34

Re: iClass is coming...

#86 2014-07-20 09:03:44

Re: iClass is coming...

#87 2014-07-20 11:53:11

Re: iClass is coming...

#88 2014-07-20 12:47:51

Re: iClass is coming...

#89 2014-07-30 10:29:53

Re: iClass is coming...