Proxmark developers 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.

#1 2017-08-20 14:39:24

iceman
Administrator
Registered: 2013-04-25
Posts: 3,861
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 smile   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.


modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

#2 2017-08-21 08:20:24

iceman
Administrator
Registered: 2013-04-25
Posts: 3,861
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                                                               |     |           

modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

#3 2017-08-21 09:53:18

iceman
Administrator
Registered: 2013-04-25
Posts: 3,861
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   

modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

#4 2017-08-21 16:15:26

carl55
Contributor
From: Colorado USA
Registered: 2010-07-04
Posts: 123

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: 3,861
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.


modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

#6 2017-08-21 23:02:14

iceman
Administrator
Registered: 2013-04-25
Posts: 3,861
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 smile

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


modhex(hkhehghthbhudcfcdchkigiehgduiehg)

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: 3,861
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.


modhex(hkhehghthbhudcfcdchkigiehgduiehg)

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 smile

iceman wrote:

Another forumuser has tested out the different CSN's found in the souce code.

Was this on a Rev C reader?

iceman wrote:

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 tongue 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: 3,861
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.


modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

#11 2017-09-11 16:28:39

carl55
Contributor
From: Colorado USA
Registered: 2010-07-04
Posts: 123

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: 3,861
Website

Re: hf iclass loclass

Sweet,  the answer I was looking for.

So an adaptation to 'sim 2',  to work with this keyroll.


modhex(hkhehghthbhudcfcdchkigiehgduiehg)

Offline

Board footer

Powered by FluxBB