Decoding NexKey

mnl · 2015-03-07 13:58:12

Hi everyone!

I'm pretty new to RFID reverse-engineering, so sorry for any obvious mistakes!

The card looks like this:
Nexkey front Nexkey back

(the numeric card ID is 74755342 27912)

First, I have scanned the DigiReader manual (google for 6600025F-DigiReader_Manual.pdf) to find any technical details:
- transmit 132kHz
- receive 66kHz
- PSK modulation
- 88-bit bitstream
- 8-bit preamble
- 32-bit reserved field
- 32-bit keycode field
- mode character
- parity character
- checksum byte

Next, I've configured the proxmark to use 134kHz carrier and captured some samples - it seems that the clock rate is RF/16:
Samples

After demodulating the samples by hand, I was able to recover the following bitstream:

01010011 11111111111111111111111111111111 10110111001101111000000111011011 1101 1000 11111011

Then, I've divided the bitstream into sections according to the hints from the manual:

Preamble:
01010011 - I have already seen that somewhere before ;)

32-bit reserved value:
11111111111111111111111111111111

32-bit keycode field:
1011 -> B
0111 -> 7
0011 -> 3
0111 -> 7
1000 -> 8
0001 -> 1
1101 -> D
1011 -> B

Mode character:
1101

Parity character:
1000

Checksum byte:
11111011

Each parity bit seems to be calculated by XOR'ing one bit from each nibble representing the keycode field (the entire value needs to be negated after that to match this specific example).

So there are some questions remaining:
1. How the checksum byte is calculated? A have already checked all major, standard CRC-8 calculations - no luck. Maybe it is using some non-default initial value?
2. Is the parity calculation algorithm right? Need more data to confirm that...
3. How to convert the ID, which is written on the card, to the HEX keycode? (some ideas?)

Unfortunately I don't have more than one card at the moment. Maybe someone will be able to deliver more samples to help me with the research?

marshmellow · 2015-03-07 14:55:56

I'm curious, did the "data rawdemod p1" not demod it?

mnl · 2015-03-08 13:32:20

Just checked "data rawdemod p1" - the bitstream is valid except for the assumed preamble. Most probably, the first bit is missing.

rawdemod

"data rawdemod p1" decodes these samples as:

but it should be:

01010011

Please correct me if I am wrong.

marshmellow · 2015-03-08 15:35:08

If I remember correctly, the demod skips to the first phase change to align itself, so it often will skip the first few bits. As long as your trace is long enough it won't matter as the data repeats.

Last edited by marshmellow (2015-03-08 15:44:14)

marshmellow · 2015-03-08 15:36:15

Can you post a trace?

marshmellow · 2015-03-08 15:54:04

are you sure it is not psk2?

mnl · 2015-03-08 16:48:56

marshmellow, thank you for your interest!

As you said, when I run rawdemod over a longer trace, the output is the same as you can find in my first post.

I'm not sure how to guess the modulation type... I will try to collect data from more than only 1 card and look for any patterns.

You can download trace here: http://pastebin.com/NbX7jX02

marshmellow · 2015-03-09 00:56:03

well with psk2 demod you get:

11111010 00000000 00000000 00000000 00000000 01101100101011000100000100110110 0011 0100 10000110 00000000 00000000000000000000000000000000

take the printed number 27912 = 110110100001000 and reverse the bits:
000100001011011

01101100101011000100000100110110 0011 0100 10000110 
              00010 00010 11011

totally just a guess

marshmellow · 2015-03-09 17:56:06

and my guess is completely wrong. the number returned by a reader is the 74755342. so it could be psk1 or psk2, but my guess is the ID is either xor encrypted or just bit scrambled. any idea what the "mode" bit does. I think quadrakey is similar? yes?

I have a few quadrakey examples but i haven't been able to make any progress (granted haven't really worked at it)

marshmellow · 2015-03-09 18:18:42

i found it looks like we are off by one. and it is psk1. read the blocks off a quadrakey.
the preamble is 0x56 or 01010110

also it appears to be a straight bit scramble on the quadrakey, so likely here as well, but would need many more samples or a reader to emulate on (if we could figure out the checksum & parities or brute force them)

Last edited by marshmellow (2015-03-09 19:13:35)

marshmellow · 2015-03-09 18:59:13

.. our demod for nexkey is inverted.

01010110000000000000000000000000000000000010010001100100001111110001001000010011100000100000000000000000000000000000000000000000

should be more accurate

marshmellow · 2015-03-09 19:10:50

i think i found the bit scramble pattern:

32bit UID:
00100100011001000011111100010010
bits numbered from left (MSB):
12345678901234567890123456789012

descramble:
b1 b5 b9 b13 b17 b21 b25 b29 b2 b6 b10 b14 b18 b22 b26 b30 b3 b7 b11 b15 b19 b23 b27 b31 b4 b8 b12 b16 b20 b24 b28 b32

=:
00000100011101001010110100001100    =  74755340

quadrakey follows exactly the same rules

now checksum and parity?

Last edited by marshmellow (2015-03-09 19:14:26)

joe · 2015-03-09 19:31:05

Look the same , but my is magnatic. Maybe is dual frequency , I'm not sure.

marshmellow · 2015-03-09 19:35:42

@joe did you try to read yours on the proxmark?

joe · 2015-03-09 19:47:52

2 cards, 1 thin I thick. All are Honeywell .

joe · 2015-03-09 19:51:02

I will try it some other time , I have no intention to emulate it now. But is interesting to find out.

mnl · 2015-03-10 17:03:01

Wow, thank you marshmellow for the scrambling pattern!

I've bought three cards from a local dealer

So, to sum it up:

1. 69829039 23514

01010110000000000000000000000000000000000011000001010000010110010001011100011101000110000000000000000000000000000000000000000000

http://pastebin.com/JtHErKiU

2. 69847552 23514

01010110000000000000000000000000000000000010001001000000011010000010010000011101011111100000000000000000000000000000000000000000

http://pastebin.com/ennw22Y7

3. 69779340 23514

01010110000000000000000000000000000000000011000001100010011110110010001000010011101111110000000000000000000000000000000000000000

http://pastebin.com/wL9P599m

4. 74755342 27912

01010110000000000000000000000000000000000010010001100100001111110001001000010011100000100000000000000000000000000000000000000000

http://pastebin.com/KMHSziN2

marshmellow · 2015-03-10 17:10:20

@mnl, Thank you for sharing your traces and for the initial reference to the reader docs. it led to the findings.

now for the parity calc and the checksum calc I'm not sure of. i'll see if i can put together a tag list of hex values (for length) to see if we can see any clues.

mnl · 2015-03-10 17:30:17

I think that cloning NexKey to a T55xx card works (at least the reader makes the "beep" sound and the light changes its color).

You have to configure the T55xx card to use PSK-1 modulation, RF/16 bit rate, RF/2 PSK-CF and 4 32-bit data blocks:

00000000 00000100 00010000 10000000 -> 00041080 for the block 0

Then you have to invert the bitstream, divide it into 32-blocks and write them on the card.

marshmellow · 2015-03-10 17:33:43

is the inverting necessary. it seems not as some of your newer traces are inverted and some are not.

marshmellow · 2015-03-10 17:50:28

list of codes to check parity calc and checksum calc with:

Raw                 Mode  Parity?  Checksum? (end of raw) ID hex    ID
5600000000213C9F8F     1     5     0C                     1F15A56D  521512301
5600000000213C9F9E     1     5     F4                     1F15A56E  521512302
5600000000213C9F9F     1     D     B4                     1F15A56F  521512303
5600000000213D8E8E     1     5     B4                     1F15A570  521512304
5600000000213D8E8F     1     D     D4                     1F15A571  521512305
5600000000213D8E9E     1     D     54                     1F15A572  521512306
5600000000213D8E9F     1     5     54                     1F15A573  521512307
5600000000213D8F9F     1     D     A4                     1F15A577  521512311
5600000000213D9E8E     1     D     24                     1F15A578  521512312
5600000000213D9F9F     1     5     78                     1F15A57F  521512319
5600000000302C8E8E     1     5     B8                     1F15A580  521512320
5600000000312C9F9F     1     D     B3                     1F15A5CF  521512399
5600000000312D8E8E     1     5     B3                     1F15A5D0  521512400
560000000024643F12     1     3     82                     0474AD0E  74755342
560000000030627B22     1     3     BF                     0428BF8C  69779340
560000000022406824     1     D     7E                     0429CA00  69847552
560000000030505917     1     D     18                     042981AF  69829039

mnl · 2015-03-10 17:58:58

Inverting makes the first phase shift, which indicates a change from 0 to 1 in the preamble segment, to be a negative value on the graph. It seems it does matter for the reader.

marshmellow · 2015-03-10 18:21:43

mnl wrote:

It seems it does matter for the reader.

you are correct. i re-looked at the traces and for some reason the rawdemod p1 did not need to invert the 69779340 trace, but if i look at the wave it definitely is inverted. (i'll check the rawdemod p1 code, must be it just takes the first phase change and assumes it is switching it to 1 from 0)

marshmellow · 2015-03-10 18:23:21

interesting enough, all of the quadrakey examples i have are not inverted.

mnl · 2015-03-10 21:42:44

@marshmellow, can you upload a sample trace from a Quadrakey card?

marshmellow · 2015-03-10 21:54:29

here is one: 521512301
http://pastebin.com/UhDQGYea

mnl · 2015-03-12 21:19:14

Parity is also scrambled:

Columns:
1 HEX ID + Mode
2 Calculated parity (XOR bits with the corresponding digit)
3 Original parity

123412341234123412341234123412341234 4231 PPPP
001000010011110010011111100011110001 0101 0101
001000010011110010011111100111100001 0101 0101
001000010011110010011111100111110001 1101 1101
001000010011110110001110100011100001 0101 0101
001000010011110110001110100011110001 1101 1101
001000010011110110001110100111100001 1101 1101
001000010011110110001110100111110001 0101 0101
001000010011110110001111100111110001 1101 1101
001000010011110110011110100011100001 1101 1101
001000010011110110011111100111110001 0101 0101
001100000010110010001110100011100001 0101 0101
001100010010110010011111100111110001 1101 1101
001100010010110110001110100011100001 0101 0101
001001000110010000111111000100100001 0011 0011
001100000110001001111011001000100001 0011 0011
001000100100000001101000001001000001 1101 1101
001100000101000001011001000101110001 1101 1101

And checksum? Tried reveng (http://reveng.sourceforge.net/), but no luck (probably not CRC).

iceman · 2015-03-12 22:11:38

How do you decode a quadrakey?

mnl · 2015-03-12 22:19:31

@iceman nexkey and quadrakey share the same format (let's call it nexwatch ). Nevertheless, I have to invert the bitstream of quadrakey to get valid reads using data rawdemod p1.

mnl · 2015-03-12 22:31:40

The bitstream seems to consist of the following blocks:

8-bit preamble -> 01010110
32-bit reserved word  -> 32 "0"
32-bit code -> use descrambling method as described by @marshmellow in post #12
4-bit mode field -> 0001 (only one value seen so far)
4-bit parity -> XOR bits from code and mode field as described in post #27
8-bit checksum -> algorithm not yet known

marshmellow · 2015-03-14 04:49:17

The rawdemod p1 had a few bugs that prevented it from determining the proper invert in many cases. I've issued a fix that significantly improves it's accuracy. Though it is still possible for it to get it wrong if there is significant noise after a phase shift. So a good read should be fine.

This should help make things more consistent when reading these tags. It will likely be accepted in a day or two.

marshmellow · 2015-03-16 16:45:22

No one has ideas on the checksum I guess.

mnl · 2015-03-23 02:38:33

That's sick, but seems to work...

1. Subtract every byte from ID field using an unsigned, one byte register:
1F - 15 - A5 - 6D = F6
2. Subtract BC from the result:
F6 - BC = 3A
3. Reverse the bits of a parity nibble:
5 -> 0101 -> 1010 -> A
4. Subtract the reversed parity from the result:
3A - A = 30 -> 00110000
5. Reverse the bits:
00001100 -> 0C
6. Check for any other ID:
1F15A577 -> A4

In case of Nexkey, magic value is 86 instead of BC:

0474AD0E -> 82
042981AF -> 18

I will prepare a perl script to confirm all recorded traces and eventually provide some initial code for reading / cloning these cards.

Last edited by mnl (2015-03-23 02:42:39)

marshmellow · 2015-03-23 04:17:08

interesting, i don't get F6 with the first step i get F8
this does seem work if you adjust the BC to BE, but i don't have the example for nexkey to see how to adjust the key

could you tell me what you get for 04-74-AD-0E = ?

marshmellow · 2015-03-23 04:57:59

i have to use BE with quadrakey and 88 with nexkey, but the formula appears to work. obviously more testing / samples will prove it.

marshmellow · 2015-03-23 05:11:09

how did you come to that algo? i'm impressed.

(though i have a feeling they do something a bit simpler somehow...)

iceman · 2015-03-23 09:48:42

Is the step with the parity needed in a algo? Looks like you can clear low nibble in 0x3A direct.

IE:  
 (( 03a & 0xf0) >> 4)   //clear and shift
 
 // reverse last nibble.

Last edited by iceman (2015-03-23 10:17:17)

marshmellow · 2015-03-23 12:44:40

I don't believe that will work for the other examples.

iceman · 2015-03-23 13:21:45

You are correct, it doesn't work for other samples.
And I also need the 0xBE magic number not 0xBC.

mnl · 2015-03-24 09:48:50

marshmellow wrote:

interesting, i don't get F6 with the first step i get F8
this does seem work if you adjust the BC to BE, but i don't have the example for nexkey to see how to adjust the key

Sorry, my mistake! (it was so late then..)

I was using calc.exe to simulate a register and added 255 instead of 256, when it overflowed you two are correct with the adjustments to the "magic" value.

@mmarshmellow, I started by looking at the checksum and noticed that there is only 1-bit difference between two consecutive IDs sharing the same parity nibble. The next observation was that there are situations when different IDs have the same checksum byte. So first I tried to correct the checksum by subtracting the parity nibble and then it was clear that the algorithm does not involve any fancy CRC or LRC. The value of checksum decreases as the numeric ID grow by 1, so I assumed that there must be a kind of subtracting register. However, the last step should involve calculating the initial value of the register, not a "magic" value to be subtracted at the final step.

Thank you @mmarshmellow, @iceman for verification.

iceman · 2015-03-24 10:07:57

Its all in the latest PR from @Marshmellow.

btw, did you implement the crc verifcation in the lfops.c aswell for ioprox. I think you can get it from my fork otherwise. not sure anymore.

marshmellow · 2015-03-24 12:10:23

I did not build a nexkey/quadrakey demod. Yet. I did add the ioprox algo check.

iceman · 2015-03-24 12:16:56

I think I'm confused here, which one was solved here?
Wasn't it the nexKey ? inside the io prox commands?

marshmellow · 2015-03-24 12:20:39

Ioprox is separate, but it is now fully in the main trunk. Nexkey/quadrakey we now have full knowledge of, thanks to mnls work. But no direct demod exists in the pm3 yet.

iceman · 2015-03-24 12:45:06

Ok, I see.

asper · 2015-03-24 13:34:58

Superb team work here! Congrats!

Nubian · 2020-02-25 05:33:35

mnl wrote:

However, the last step should involve calculating the initial value of the register, not a "magic" value to be subtracted at the final step.

@mnl final step "magic" value algo should be?

iceman · 2020-05-10 22:02:54

Looks like I totally forgot about this one.

Nexwatch cmd will now print the descrambled 88bit format id/parity/checksum according to the old findings in this thread.
Thanks to @mnl , @marshmellow!

[usb|script] pm3 --> lf nex demod
[+]  NexWatch raw id : 0x40c00080
[+]         88bit id : 69779340 0x428bf8c
[+]             mode : 1
[+]           parity : ok  [3 == 3]
[+]         checksum : ok  [BF]
[+]          Keytype : Nexkey
[+] DemodBuffer: 560000000030627B2213BF0000000000

[edit] implemented the parity / checksum / keytype

crocs · 2020-07-16 20:09:29

Could someone please explain what would be correlation between bitstream and content of card blocks (0-3?). Or at least point me in the right direction, because i am definitely missing something trying to manually decode/encode the card content.

[edit] It seems that with software version i was using , im getting unreliable readouts, not conforming to the research in this topic.
[edit2]: Nope. i still dont get it. How do i get from this

blk | hex data | binary
----+----------+---------------------------------
  0 | 00042080 | 00000000000001000010000010000000
  1 | FA000000 | 11111010000000000000000000000000
  2 | 000530D1 | 00000000000001010011000011010001
  3 | 55397700 | 01010101001110010111011100000000
  4 | 00000000 | 00000000000000000000000000000000
  5 | 00000000 | 00000000000000000000000000000000
  6 | 00000000 | 00000000000000000000000000000000
  7 | 00000000 | 00000000000000000000000000000000
Reading Page 1:

to this :

Checking for known tags:

NexWatch ID: 67913575
Had to Invert - probably NexKey
DemodBuffer: A9FFFFFFFFFCEFB0CCE8D2FFFFFFFFFF

Help!

Last edited by crocs (2020-07-17 13:29:54)

Proxmark3 community

Announcement

#1 2015-03-07 13:58:12

Decoding NexKey

#2 2015-03-07 14:55:56

Re: Decoding NexKey

#3 2015-03-08 13:32:20

Re: Decoding NexKey

#4 2015-03-08 15:35:08

Re: Decoding NexKey

#5 2015-03-08 15:36:15

Re: Decoding NexKey

#6 2015-03-08 15:54:04

Re: Decoding NexKey

#7 2015-03-08 16:48:56

Re: Decoding NexKey

#8 2015-03-09 00:56:03

Re: Decoding NexKey

#9 2015-03-09 17:56:06

Re: Decoding NexKey

#10 2015-03-09 18:18:42

Re: Decoding NexKey

#11 2015-03-09 18:59:13

Re: Decoding NexKey

#12 2015-03-09 19:10:50

Re: Decoding NexKey

#13 2015-03-09 19:31:05

Re: Decoding NexKey

#14 2015-03-09 19:35:42

Re: Decoding NexKey

#15 2015-03-09 19:47:52

Re: Decoding NexKey

#16 2015-03-09 19:51:02

Re: Decoding NexKey

#17 2015-03-10 17:03:01

Re: Decoding NexKey

#18 2015-03-10 17:10:20

Re: Decoding NexKey

#19 2015-03-10 17:30:17

Re: Decoding NexKey

#20 2015-03-10 17:33:43

Re: Decoding NexKey

#21 2015-03-10 17:50:28

Re: Decoding NexKey

#22 2015-03-10 17:58:58

Re: Decoding NexKey

#23 2015-03-10 18:21:43

Re: Decoding NexKey

#24 2015-03-10 18:23:21

Re: Decoding NexKey

#25 2015-03-10 21:42:44

Re: Decoding NexKey

#26 2015-03-10 21:54:29

Re: Decoding NexKey

#27 2015-03-12 21:19:14

Re: Decoding NexKey

#28 2015-03-12 22:11:38

Re: Decoding NexKey

#29 2015-03-12 22:19:31

Re: Decoding NexKey

#30 2015-03-12 22:31:40

Re: Decoding NexKey

#31 2015-03-14 04:49:17

Re: Decoding NexKey

#32 2015-03-16 16:45:22

Re: Decoding NexKey

#33 2015-03-23 02:38:33

Re: Decoding NexKey

#34 2015-03-23 04:17:08

Re: Decoding NexKey

#35 2015-03-23 04:57:59

Re: Decoding NexKey

#36 2015-03-23 05:11:09

Re: Decoding NexKey

#37 2015-03-23 09:48:42

Re: Decoding NexKey

#38 2015-03-23 12:44:40

Re: Decoding NexKey

#39 2015-03-23 13:21:45

Re: Decoding NexKey