Proxmark3 community
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.
Announcement
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
#1 2017-08-20 14:39:24
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
hf iclass loclass
Someone send me a trace and mac-bin file from the hf iclass sim 2 command.
Usually in Elite/Highsecurity mode the simulation gathering of CC's goes well, this time it didn't.
This got me a bit curious, as usual.
After looking inside the source code and reading old iclass pdf's I realized that we still use the old CSNS from Carl55 (15 of them) but Holiman published an enhancement where using a better selection of CSNs we only need 8 of them. These are not used and he published it 2014 
Since I suspect that HID has blacklisted those CSN:s I decided to ask Holiman how he found them. He told me and I did the same since the HASH1 has high collision rate it doesn't take long to get new ones.
In iceman fork the three current existing sets of CSN:s are, Carl55, Holiman and mine. I wonder if they work better or not. Feel free to test them out and report back to me.
Set the above aside and I found more issues, there were some non-existing checks on refences in the iclass device-side code, also fixed,
and the minor fact all iclass commands didn't turn of the antenna afterwards ?!?! also fixed, and today I found out that the simulation should also use the tracelog but it doesn't work. I haven't gotten around to solve it yet.
There other users reporting that the iclass simulation doesn't work against rev2, rev3 HID readers. Others report that PM3 RDV2 (elechouse) doesn't work at all with iclass simulation. All of this is strange to me.
My problem is that I don't have a HID iClass reader setup to test my pm3 code. I do test this with two pm3 kits. However it is really disappointing results so far. I'm guessing the UART is not properly working but much more tests needs to be done.
Offline
#2 2017-08-21 08:20:24
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: hf iclass loclass
This is a system in Legacy mode.
I got an trace from someone trying against a reader where the sim 2 fails, so here we can see how it fails on a legacy mode system.
hf iclass sim 2
0 | 0 | Rdr |0a | | ACTALL
400 | 400 | Tag |0f | |
1338736 | 1338736 | Rdr |0a | | ACTALL
1339168 | 1339168 | Tag |0f | |
2676336 | 2676336 | Rdr |0a | | ACTALL
2676720 | 2676720 | Tag |0f | |
2725200 | 2725200 | Rdr |0c | | IDENTIFY
2728272 | 2728272 | Tag |40 e1 e1 ff fe 5f 02 3c 43 01 | ok |
2771216 | 2771216 | Rdr |81 40 e1 e1 ff fe 5f 02 3c | | SELECT
2774352 | 2774352 | Tag |01 0a 0f ff f7 ff 12 e0 62 75 | ok |
2858464 | 2858464 | Rdr |0c 05 de 64 | ok | READ(5)
2946800 | 2946800 | Rdr |0c 05 de 64 | ok | READ(5)
4017264 | 4017264 | Rdr |0a | | ACTALL
4017664 | 4017664 | Tag |0f | |
4065504 | 4065504 | Rdr |0c | | IDENTIFY
4068624 | 4068624 | Tag |40 e1 e1 ff fe 5f 02 3c 43 01 | ok |
4111440 | 4111440 | Rdr |81 40 e1 e1 ff fe 5f 02 3c | | SELECT
4114512 | 4114512 | Tag |01 0a 0f ff f7 ff 12 e0 62 75 | ok |
4198896 | 4198896 | Rdr |0c 05 de 64 | ok | READ(5)
4286832 | 4286832 | Rdr |0c 05 de 64 | ok | READ(5)
5358320 | 5358320 | Rdr |0a | | ACTALL
5358784 | 5358784 | Tag |0f | | Offline
#3 2017-08-21 09:53:18
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: hf iclass loclass
Another user feedback, different system than the previously posted.
One bug is the log-times, it becomes negative.
The trace is partial, but it collects all the 15 csn responses.
However the collected mac-bin file also fails.
To clarify, I've tested against two working mac-bin files and it finds the correct key. So the implementation does work, but something has changed it seems.
hf iclass sim 2
------------|------------|-----|-----------------------------------------------------------------|-----|--------------------|
0 | 0 | Rdr | 0a | | ACTALL
368 | 368 | Tag | 0f | |
12752 | 12752 | Rdr | 0c | | IDENTIFY
15824 | 15824 | Tag | 60 e1 e1 ff fe 5f 02 1c b1 96 | ok |
61840 | 61840 | Rdr | 81 60 e1 e1 ff fe 5f 02 1c | | SELECT
64992 | 64992 | Tag | 00 0b 0f ff f7 ff 12 e0 08 6b | ok |
87712 | 87712 | Rdr | 00 | | HALT
280624 | 280624 | Rdr | 81 00 0b 0f ff f7 ff 12 e0 | | SELECT
283680 | 283680 | Tag | 00 0b 0f ff f7 ff 12 e0 08 6b | ok |
318432 | 318432 | Rdr | 84 00 73 33 | ok | PAGESEL(0)
321584 | 321584 | Tag | 00 0b 0f ff f7 ff 12 e0 08 6b | ok |
399952 | 399952 | Rdr | 88 02 | | READCHECK[Kd](2)
402528 | 402528 | Tag | 00 00 00 00 00 00 00 00 | ok |
570800 | 570800 | Rdr | 05 57 38 7b 79 57 89 5b d0 | | CHECK
-91745664 | -91745664 | Rdr | 0a | | ACTALL
-91745296 | -91745296 | Tag | 0f | |
-91732928 | -91732928 | Rdr | 0c | | IDENTIFY
-91729840 | -91729840 | Tag | 80 c0 01 e1 fe 5f 02 1c ef 25 | ok |
-91683680 | -91683680 | Rdr | 81 80 c0 01 e1 fe 5f 02 1c | | SELECT
-91680608 | -91680608 | Tag | 00 04 0e 08 f7 ff 12 e0 ad d9 | ok |
-91657856 | -91657856 | Rdr | 00 | | HALT
-91464832 | -91464832 | Rdr | 81 00 04 0e 08 f7 ff 12 e0 | | SELECT
-91461712 | -91461712 | Tag | 00 04 0e 08 f7 ff 12 e0 ad d9 | ok |
-91426960 | -91426960 | Rdr | 84 00 73 33 | ok | PAGESEL(0)
-91423824 | -91423824 | Tag | 00 04 0e 08 f7 ff 12 e0 ad d9 | ok |
-91345712 | -91345712 | Rdr | 88 02 | | READCHECK[Kd](2)
-91342992 | -91342992 | Tag | 00 00 00 00 00 00 00 00 | ok |
-91171632 | -91171632 | Rdr | 05 2e 09 2d 61 3c 9e 81 00 | | CHECK
-91744784 | -91744784 | Rdr | 0a Offline
#4 2017-08-21 16:15:26
- carl55
- Contributor
- From: Arizona USA
- Registered: 2010-07-04
- Posts: 175
Re: hf iclass loclass
It appears from the trace above that the card challenge being used is all 0's.
I have found that certain versions of reader firmware do not know how to handle an e-purse value of 0 and will simply perform a software reset of the reader in order to recover. In addition, if you do want to have a value of zero then you should use a value of 0x0000FFFFFFFFFFFF or 0xFFFFFFFF0000FFFF in order to be consistent with the picopass e-purse defined structure.
I believe the original SIM code used the following:
uint8_t card_challenge_data[8] = {0xfe,0xff,0xff,0xff,0xff,0xff,0xff,0xff};
Was this changed for some reason?
Offline
#5 2017-08-21 16:49:59
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: hf iclass loclass
Thats a very good observation, I've been so used seeing all zero nonces (from darkside source among others) that I forgot to ask about this one.
Let me push your original value and get some testing done.
Offline
#6 2017-08-21 23:02:14
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: hf iclass loclass
For people who wants to learn something new, let me show you the extra debug messages for iClass Manchester demodulation
When you get an output which starts and ends with 0xBB like seen below, this is not proper iclass reader/tag communication with unknown commands in the iclass transport protocol. Nop, it is the debug statements for the Manchester DEMOD code.
The 0xBB is separator and the values are broken down as following using
sample row: bb! 33! bb! 01 02 04 08 bb!
0xBB sep,
0x33 error code, ( DEMOD_ERROR_WAIT )
0xBB sep,
0x01 (0001) demodulated bit,
0x02 (0010) demod buffer 1,
0x04 (0100) demod buffer 2,
0x08 (1000) syncbit,
0xBB sep
pm3 --> hf iclass reader 1
#db# Done...
Readstatus:00
Quitting...
pm3 --> hf li iclass
Recorded Activity (TraceLen = 162 bytes)
Start = Start of Start Bit, End = End of last modulation. Src = Source of Transfer
iClass - Timings are not as accurate
Start | End | Src | Data (! denotes parity error) | CRC | Annotation
------------|------------|-----|-----------------------------------------------------------------|-----|------------
0 | 0 | Rdr |0a | | ACTALL
1280 | 1280 | Tag |bb! 33! bb! 01 02 04 08 bb! | ok |
1280 | 1280 | Rdr |0c | | IDENTIFY
1616 | 1616 | Tag |bb! 33! bb! 00! 02 00! 02 bb! | ok |
1616 | 1616 | Rdr |0a | | ACTALL
2336 | 2336 | Tag |bb! d4! bb! 02 08 00! 08 bb! | ok |
2336 | 2336 | Rdr |0c | | IDENTIFY
2448 | 2448 | Tag |bb! 33! bb! 00! 00! 00! 02 bb! | ok |
2448 | 2448 | Rdr |0a | | ACTALL
2720 | 2720 | Tag |bb! d4! bb! 08 0b 01 04 bb! | ok |
2720 | 2720 | Rdr |0c | | IDENTIFY
3232 | 3232 | Tag |bb! d4! bb! 02 02 08 04 bb! | ok |As seen the actual source code part https://github.com/Proxmark/proxmark3/b … ass.c#L596
Offline
#7 2017-09-11 08:32:53
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: hf iclass loclass
Haven't been on this forum for a while, this looks promising! I don't suppose anyone has had a chance to test it out on an old Rev C reader?
Haven't found a lot of time recently to work on my PM3... I think I still have antenna issues because the furthest I ever got was the reader sending IDENTIFY. My current coil isn't even waking the reader up from its power saving mode. If I ever get my antenna working I'll test this out for you (starting to wonder if I should just cut my losses and buy a better proxmark....)
Offline
#8 2017-09-11 09:35:43
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: hf iclass loclass
Another forumuser has tested out the different CSN's found in the souce code.
The inital 15 from Carl55 works.
The 8 from Holiman, first CSN works then it get stuck. ie reader don't like the 2:d CSN.
The 9 from iceman works.
We can assume 'sim 2' / 'loclass' works as it should and if someone has a problem with it, it usually is because the reader is not configured to use ELITE /HIGH SECURITY.
The idea the reader switches between different AA1 keys while running its authentication sequence is still un-verified.
Offline
#9 2017-09-11 10:13:37
- mollusc
- Contributor
- From: Vic - Australia
- Registered: 2017-05-01
- Posts: 33
Re: hf iclass loclass
Really appreciate all the work you put into this iceman
Another forumuser has tested out the different CSN's found in the souce code.
Was this on a Rev C reader?
We can assume 'sim 2' / 'loclass' works as it should and if someone has a problem with it, it usually is because the reader is not configured to use ELITE /HIGH SECURITY.
So perhaps the reported problems are largely due to a flood of cheap RDV2 easy clones with poor antenna performance 
And on top of that, the attack doesn't work on readers configured for standard security (which is fine because we already have the keys for that).
The idea the reader switches between different AA1 keys while running its authentication sequence is still un-verified.
Don't think I've run into this theory on the forum. Care to elaborate?
Offline
#10 2017-09-11 15:10:03
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: hf iclass loclass
Rev.C reader, I don't know which model the sim 2 was tested against.
The cheap pm3 kits with poor antenna, wasn't it you who found out the LF antenna had a different capacitor making the tune calculations be miss-guiding.. 100 -> 200? Not sure how we are to detect such hardware changes.
The idea of alternative swapping AA1 keys, does like this.
Some say that old known AA1 key works but doesn't work on the system. Utterly strange. simulation tracelogs shows two auth for each csn. So the idea of the reader nowdays as a counter, has 2 aa1 keys, which when presented with against sim 2 attack will fail or give you a key which is not used but valid.
First AA1 against CSN, then sim2 takes next CSN, and reader "swaps" to the second AA1, then sim2 takes next CSN, reader swaps to first AA1..
If this is true, it implies we would need to adjust sim2, to keep track of two auths against every CSN. And generate two files, to be used in the offline loclass attack.
Offline
#11 2017-09-11 16:28:39
- carl55
- Contributor
- From: Arizona USA
- Registered: 2010-07-04
- Posts: 175
Re: hf iclass loclass
I believe that you are referring above to how the iclass "keyroll" function works.
When a particular system updates to a new high security key, it typically will use the keyroll function (initiated via configuration card) to update the existing card population of all users. To accomplish this update the reader has to be able to authenticate with the non-updated credentials using the old key. Once the key on that card has been updated it must then also be able to authenticate with the updated credential using the new key.
Since the keyroll function may take days, weeks, or months to completely update all user cards the reader must be able to have two active authentication keys during this time. Once all cards at that installation have been "rolled", the administrator would normally use a "keyroll stop" configuration card in order to setup the reader so it will only accept the new authentication key going forward.
Since the "sim" command, by design, will always fail to authenticate, the reader (if in keyroll mode) will simply try the second key. The theory is that this "ping-pong" use of keys is not currently being handled by the PM3 code.
Luckily, most system that are placed in keyroll mode are only in that mode for a short time.
[NOTE: The concept of a keyroll mode has been verified through the analysis of the older RevA iclass reader firmware. The reader firmware utilized two separate key tables in RAM and dedicated two separate EEPROM locations for the old and new Kcus keys. To my knowledge, the concept of keyroll has since been discontinued with the introduction of iclass SE because of its security vulnerabilities.]
Offline
#12 2017-09-11 17:08:56
- iceman
- Administrator
- Registered: 2013-04-25
- Posts: 9,538
- Website
Re: hf iclass loclass
Sweet, the answer I was looking for.
So an adaptation to 'sim 2', to work with this keyroll.
Offline
Pages: 1