Research, development and trades concerning the powerful Proxmark3 device.
Remember; sharing is caring. Bring something back to the community.
"Learn the tools of the trade the hard way." +Fravia
You are not logged in.
Time changes and with it the technology
Proxmark3 @ discord
Users of this forum, please be aware that information stored on this site is not private.
Pages: 1
Hi. Today I tried iclass fob(no mark, nothing on back) with pm3 easy, but failed.
hf iclass chk f default_iclass_keys.dic
then got below:
failed to obtain cc! aborting
And tried
hf iclass dump k (leaked key)
same result, with e or without, with f testi or without.
I think the process for cloning is,
checking key, dumping, ???
pm3 easy, official version, boot rom and os 2018/7/24
Thanks.
Offline
Are you trying to use this key leaked from twitter? Because it's not quite this key you need to use:)
Offline
Thanks. I got leaked key, and used converted one(permuted-unpermuted). So...
hf iclass dump k (converted key)
hf iclass dump k (converted key) e
hf iclass dump f testi k default_iclass_keys.dic
hf iclass chk f default_iclass_keys.dic
all same results...
failed to obtain cc! aborting
It means wrond key? or any other problem?
Offline
Thanks. I got leaked key, and used converted one(permuted-unpermuted). So...
all same results...
failed to obtain cc! aborting
It means wrond key? or any other problem?
Maybe this is SE iclass card. same result for SE iclass cards even with correct keys.
Any progeress on SE iclass now?
Offline
I have recently been investigating why some PM3 users have had problems authenticating with certain iclass readers when using the Kcus key obtained using the loclass function.
For my tests I obtained three different "Elite" credentials (legacy, SR, and SE) that all supposedly utilize the same Elite custom authentication key (Kcus).
The legacy credential has the original data access control payload in blocks 6-9.
The SR credential has two data payloads (legacy [6-9] and SIO [10-16]).
The SE credential has a single SIO payload in blocks 6-12.
The interesting thing that I discovered is that if the credential identifies itself as a legacy or SR credential (Blk5=0xFFFFFFFFFFFFFFFF) then the Kdiv, nonce and mac used by the reader during the authentication process always seem to agree with the PM3 calculations for Kdiv,nonce, and mac.
However, if the credential identifies itself as an SE credential (Blk5=0xFFFFFF0006FFFFFF) then the nonce and mac sent out by the reader are different from what the PM3 calculates.
What this means is ......
The PM3 sim 2 command currently simulates a legacy credential. As a result, the nonce and mac data that are recovered are only applicable to non-SIO credentials. From the limited testing that I have done it appears that if the sim 2 command is modified to use an SE block 5 value of 0xFFFFFF0006FFFFFF then the nonce and mac values recovered no longer allow the loclass function to obtain a valid Kcus.
It would appear as though one or both of the Kdiv hashing algorithms may have been modified for SE credentials that only support an SIO payload.
If this is true, then the Kcus obtained from loclass will only work on legacy or SR credentials. The recovered Kcus key will not allow SE credentials to be read since the PM3 will be using an incorrect Kdiv.
I will continue looking into this further to see if I can learn more.
Offline
Sim 2, uses block5, Application issuer data AIA, https://github.com/iceman1001/proxmark3 … ss.c#L1319
is modified to 0xFFFFFF0006FFFFFF , it still doesn't match SE with SIO payloads nonce/mac ?
Offline
Below are two "sim 2" dumps from the same Elite iclass reader.
The first one has AIA set to 0xFFFFFFFFFFFFFFFF (legacy).
The second dump has AIA set to 0xFFFFFF0006FFFFFF (SE).
The first dump yields the correct Elite key when loclass is run. The second dump does not yield any key.
The mac values in the first dump agree with the known cipher algorithm. The second set of mac values do not.
The recovered key does allow me to read or modify a legacy or SR credential from that Elite system. The recovered key does not allow authentication with an SE card that works in the same system.
My tests are limited and very preliminary. Additional testing is needed.
000000 01 0a 0f ff f7 ff 12 e0
000008 fe ff ff ff ff ff ff ff
000010 de 0b aa 44 6e e2 a9 4b
000018 0c 06 0c fe f7 ff 12 e0
000020 fe ff ff ff ff ff ff ff
000028 21 b8 95 db 95 85 fa 84
000030 10 97 83 7b f7 ff 12 e0
000038 fe ff ff ff ff ff ff ff
000040 6b d6 b1 38 e6 6a e1 65
000048 13 97 82 7a f7 ff 12 e0
000050 fe ff ff ff ff ff ff ff
000058 42 ff b0 e9 ea ba 1c eb
000060 07 0e 0d f9 f7 ff 12 e0
000068 fe ff ff ff ff ff ff ff
000070 c4 2a f0 1a 74 2b d1 b6
000078 14 96 84 76 f7 ff 12 e0
000080 fe ff ff ff ff ff ff ff
000088 bb f5 3a 6c 5b e0 62 e2
000090 17 96 85 71 f7 ff 12 e0
000098 fe ff ff ff ff ff ff ff
0000a0 0d 0e d4 68 29 05 ea 9c
0000a8 ce c5 0f 77 f7 ff 12 e0
0000b0 fe ff ff ff ff ff ff ff
0000b8 3e 96 38 43 2e b0 bc c5
0000c0 d2 5a 82 f8 f7 ff 12 e0
0000c8 fe ff ff ff ff ff ff ff
0000d0 e7 55 e1 85 10 c4 08 ab
000000 01 0a 0f ff f7 ff 12 e0
000008 fe ff ff ff ff ff ff ff
000010 43 63 70 a4 d4 eb 1a dd
000018 0c 06 0c fe f7 ff 12 e0
000020 fe ff ff ff ff ff ff ff
000028 aa a6 7d fa 48 ea f9 72
000030 10 97 83 7b f7 ff 12 e0
000038 fe ff ff ff ff ff ff ff
000040 9a 4e 07 23 41 13 ea 1d
000048 13 97 82 7a f7 ff 12 e0
000050 fe ff ff ff ff ff ff ff
000058 88 af 5f a0 31 39 3c d2
000060 07 0e 0d f9 f7 ff 12 e0
000068 fe ff ff ff ff ff ff ff
000070 0b 32 2a ab 7c 1e c6 5d
000078 14 96 84 76 f7 ff 12 e0
000080 fe ff ff ff ff ff ff ff
000088 77 17 e1 2f 33 91 f9 01
000090 17 96 85 71 f7 ff 12 e0
000098 fe ff ff ff ff ff ff ff
0000a0 ca ab 2c 6b ed 62 3c b0
0000a8 ce c5 0f 77 f7 ff 12 e0
0000b0 fe ff ff ff ff ff ff ff
0000b8 ed 0d af 1a 6a f5 3f 22
0000c0 d2 5a 82 f8 f7 ff 12 e0
0000c8 fe ff ff ff ff ff ff ff
0000d0 67 eb 15 e7 74 10 96 5b
Offline
two problems now on SE iclass:
1.We dong have the correct algorithm to find out hte SE system Key,
2.We dont have the SE iclass empty card to write SIO dump payload.
what shall we do?
Offline
This is an update summarizing the latest testing that I have been doing with regards to why the PM3 "sim 2" and "loclass" functions do not always yield the correct high security authentication key. The functions appear to work well with legacy iclass systems but not with the newer iclass SE systems.
I set up some customized hardware that allowed me to monitor and log hundreds of thousands of authentication attempts in order to capture the associated nonce and mac values. A large number of captures were required in order to ensure that the same 32-bit random nonce value was observed for each variation of the test.
To minimize the number of variables I used a single SE reader that could be configured to operate in either standard security mode or high security mode. I also used a single "uninitialized" credential that could be configured as either a legacy credential or an SIO credential by simply changing the value of the AIA stored in Block 5. In addition, the value of the e-purse was fixed and not allowed to be updated by the reader.
The following conclusions were made based on the results of the tests:
1. When the SE reader was operating in a standard security mode and it interracted with a credential that was identifying itself as either a legacy credential or an SIO credential, the reader mac value was always the same for a given nonce. In other words, the AIA block 5 value appears to be a "don't care" in standard security mode.
2. When the SE reader was operating in a high security mode, the mac value obtained (using the same nonce) was different depending on whether the credential identified itself as a legacy credential or as an SIO credential. This indicates that either the cipher algorithm or one of its component variables is different when interracting with SIO credentials.
Based on this and other supplemental testing, the most likely scenario is that the Kdiv algorithm used for high security credentials has been modified for SIO payloads. This could mean that the hashing algorithm used to generate the high security key table has changed or it could also be something as simple as how the indexing into the table is done.
The bottom line is that the existing PM3 loclass function will only yield valid Kcus results on an SE reader if that reader supports the ability to read legacy payloads. The ability to read legacy payloads is denoted by a "T" in the fifth digit of the iclass SE reader part number(e.g 920NTNNEK00000).
If the sim 2 function is modified to emulate an SIO credential (Blk5=0xFFFFFF0006FFFFFF) then it will be able to invoke an authentication attempt on an SIO-only reader but the Kcus cannot be recovered since the PM3 code will be using an incorrect Kcus recovery algorithm.
Offline
This is an update summarizing the latest testing that I have been doing with regards to why the PM3 "sim 2" and "loclass" functions do not always yield the correct high security authentication key. The functions appear to work well with legacy iclass systems but not with the newer iclass SE systems.
I set up some customized hardware that allowed me to monitor and log hundreds of thousands of authentication attempts in order to capture the associated nonce and mac values. A large number of captures were required in order to ensure that the same 32-bit random nonce value was observed for each variation of the test.
To minimize the number of variables I used a single SE reader that could be configured to operate in either standard security mode or high security mode. I also used a single "uninitialized" credential that could be configured as either a legacy credential or an SIO credential by simply changing the value of the AIA stored in Block 5. In addition, the value of the e-purse was fixed and not allowed to be updated by the reader.The following conclusions were made based on the results of the tests:
1. When the SE reader was operating in a standard security mode and it interracted with a credential that was identifying itself as either a legacy credential or an SIO credential, the reader mac value was always the same for a given nonce. In other words, the AIA block 5 value appears to be a "don't care" in standard security mode.
2. When the SE reader was operating in a high security mode, the mac value obtained (using the same nonce) was different depending on whether the credential identified itself as a legacy credential or as an SIO credential. This indicates that either the cipher algorithm or one of its component variables is different when interracting with SIO credentials.
Based on this and other supplemental testing, the most likely scenario is that the Kdiv algorithm used for high security credentials has been modified for SIO payloads. This could mean that the hashing algorithm used to generate the high security key table has changed or it could also be something as simple as how the indexing into the table is done.
The bottom line is that the existing PM3 loclass function will only yield valid Kcus results on an SE reader if that reader supports the ability to read legacy payloads. The ability to read legacy payloads is denoted by a "T" in the fifth digit of the iclass SE reader part number(e.g 920NTNNEK00000).
If the sim 2 function is modified to emulate an SIO credential (Blk5=0xFFFFFF0006FFFFFF) then it will be able to invoke an authentication attempt on an SIO-only reader but the Kcus cannot be recovered since the PM3 code will be using an incorrect Kcus recovery algorithm.
carl55,you are a genuis!!! Great job done!!!
Offline
Pages: 1