PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

0xFFFF · 2017-04-25 05:30:20

Might be of interest to some...

RK40 (old 6130)

RPK40 (new 921)

R10 (old 6100)

RP10 (new 900)

carl55 · 2017-04-25 19:56:17

Wow!, thanks 0xFFFF. People don't realize how helpful these types of photos can be.

As an example, if you look at your second photo (RK40 old) you will see a set of pads in the upper right corner. This is the 20-pin location where an RS232 interface chip goes when the same PCB is used in the more expensive (and difficult to find) Read/Write unit (RWK40). This chip is the "only" difference between a RevA RK40 and a RevA RWK40. The PIC18F452 firmware is the same for both types of readers. What this means is that you can cut out the rubberized potting material above this part and then attach two wires to the Tx and Rx pins ( 15 and 16) and you will have yourself a reader that can be used to dump out the firmware and iclass keys as described in the "heart of Darkness" paper.
In addition, there are eleven of these RevA RK40 readers being sold right now on ebay.com at the low price of $19 each.
eBay RK40 RevA
By adding a USB-to-UART adapter to these pins you can also create a fully functional iclass cloner module simply by writing some code that communicates on the RS232 interface using the iclass serial protocol.

I have also benefitted appreciably from your other iclass SE PCB photos while doing some research associated with the IClass SE Secure Access Module (SAM).
Thanks again!

Last edited by carl55 (2017-04-27 17:23:31)

0xFFFF · 2017-04-26 02:31:00

Happy to help!
There are a few Prox and RS232 modules hiding somewhere on my desk. I should have a look at them.
I only have one RWK40 and CP400 so I'm not terribly keen on pulling them apart. Would you know if the CP400 is the same internally?

I'm glad to hear that someone else is targeting the SAM. I'd love to hear from you if you have any findings.

carl55 · 2017-04-26 17:23:24

0xFFFF wrote:

Would you know if the CP400 is the same internally?

I don't know for sure but I suspect that the hardware is the same. I do know that the firmware is different.
The CP400 application software refuses to interact with the hardware if the Product ID and Version Number (stored in the first eight bytes of EEPROM) indicates that it is not a legitimate CP400 unit. If you knew the correct product ID for a CP400 then you might be able to use a normal RW400 reader to emulate the CP400 by writing its Vendor ID into the RW400's EEPROM. It would be an interesting experiment.

0xFFFF wrote:

I'm glad to hear that someone else is targeting the SAM. I'd love to hear from you if you have any findings.

I have been focussing on the high speed serial commication that exists between the reader microcontroller and the SAM.
The microcontroller appears to comunicate with the SAM using a proprietary serial protocol similar to the capture shown below.
(Note: The leftmost data is timestamp information that was added by my logic analyzer and it is NOT part of the actual data transmitted).

I have built a separate (external) microcontroller circuit that filters through the real time serial data and spits out all of the relevant information when a credential is being read. An example output of the filtered data is also shown in the second window below. I am convinced that once the protocol is fully understood then access to the SAM's internal functions and secure memory may be possible.
From my preliminary analysis there also appears to be some type of "heartbeat" information infused into the communication stream that I theorize is some sort of tamper detection mechanism. I suspect that if this periodic information is interrupted then the SAM will lock itself down and a special unlock sequence will then be required to restore normal operation again. I personally have bricked two different SE readers during my testing that I believe is related to this mechanism.

Example - Raw SAM Serial Communication Sequence (Partial Snapshot)

0.432983 00 00 15 A0 DA 02 63 00 00 0C 01 0A 00 00 00 00 BD 82 00 02 82 00 00 00 B6
0.434758 00 40 0C 0A 3E 0A 00 00 00 A6 02 82 00 90 00
0.435301 C4
0.435564 00 40 19 A0 DA 02 63 00 00 10 3E 0A 00 0A 00 00 BD 08 A4 06 81 04 00 94 F3 E7 00 00 7E
0.437513 00 00 14 0A 3E 0A 00 00 00 A6 82 00 08 A0 06 85 04 00 00 00 46 90 00
0.438313 F7
0.508848 00 00 19 A0 DA 02 63 00 00 10 3E 0A 00 0A 00 00 BD 08 A4 06 81 04 00 94 F4 30 00 00 EE
0.510953 00 40 16 0A 14 0A 00 00 00 A1 82 00 0A A0 82 00 06 80 04 02 04 09 0A 90 00
0.511819 5E
0.536569 00 40 36 A0 DA 02 63 00 00 2D 14 0A 00 00 00 00 BD 82 00 23 A0 82 00 1F A1 82 00 1B 81 01 14 A2 82 00 14 80 02 00 04 81 08 6C E3 E2 00 F8 FF 12 E0 86 04 00 94 F4 4C 00 00 DE
0.539760 00 00 1A 0A 14 0A 00 00 00 A1 10 A1 0E 80 04 0C 05 DE 64 81 02 00 04 82 02 01 F4 90 00
0.540758 45
0.546348 00 00 33 A0 DA 02 63 00 00 2A 14 0A 00 00 00 00 BD 82 00 20 A0 82 00 1C A0 82 00 18 80 82 00 0A FF FF FF 00 06 FF FF FF F8 8E 81 02 00 00 83 04 00 94 F4 55 00 00 4E
0.549872 00 40 18 0A 14 0A 00 00 00 A1 0E A1 0C 80 02 88 02 81 02 00 04 82 02 01 F4 90 00
0.550802 24
0.555194 00 40 31 A0 DA 02 63 00 00 28 14 0A 00 00 00 00 BD 82 00 1E A0 82 00 1A A0 82 00 16 80 82 00 08 FF FF FF FF 00 00 FF FF 81 02 00 00 83 04 00 94 F4 5E 00 00 41
0.563603 00 00 1F 0A 14 0A 00 00 00 A1 15 A1 13 80 09 05 D5 1E 9B 59 DB 35 FE 7C 81 02 00 04 82 02 01 F4 90 00
0.564760 86
0.570069 00 00 2D A0 DA 02 63 00 00 24 14 0A 00 00 00 00 BD 82 00 1A A0 82 00 16 A0 82 00 12 80 82 00 04 37 9F E4 13 81 02 00 00 83 04 00 94 F4 6D 00 00 7D
0.573308 00 40 1A 0A 14 0A 00 00 00 A1 10 A1 0E 80 04 06 06 45 56 81 02 00 04 82 02 01 F4 90 00
0.574304 A5
0.587289 00 40 4B A0 DA 02 63 00 00 42 14 0A 00 00 00 00 BD 82 00 38 A0 82 00 34 A0 82 00 30 80 82 00 22 30 32 81 05 01 86 28 89 38 A5 02 05 00 A6 08 81 01 01 04 03 03 00 09 A7 17 85 15 7E A9 A6 60 89 55 A7 81 02 00 00 83 04 00 94 F4 7E 00 00 27
0.590975 00 00 1A 0A 14 0A 00 00 00 A1 10 A1 0E 80 04 06 09 B2 AE 81 02 00 04 82 02 01 F4 90 00
0.591970 E5
0.604926 00 00 4B A0 DA 02 63 00 00 42 14 0A 00 00 00 00 BD 82 00 38 A0 82 00 34 A0 82 00 30 80 82 00 22 17 85 15 7E A9 A6 60 89 36 EE 5D 5D BA 4C 36 0A 7B FC 2B E2 70 8E 22 FC A9 02 05 00 05 00 00 00 3A C3 81 02 00 00 83 04 00 94 F4 90 00 00 EA
0.614122 00 40 17 0A 14 0A 00 00 00 A1 0D A1 0B 80 01 00 81 02 00 04 82 02 01 F4 90 00

iClass SE SIO Credential Read - Sample Output (extracted from raw serial data)

****************************
* iCLASS SE Data Extractor *
* Revision 1.0             *
* February 1, 2016         *
* www.proxclone.com        *
****************************

 Awaiting Data ....

CSN   = 6ce3e200f8ff12e0
Blk5  = ffffff0006ffffff
Blk2  = ffffffff0000ffff
Nonce = 0879799d (Auth)
MAC1  = ea3d04bd (Rdr Auth)
MAC2  = e4beee3f (Tag Auth)
Blk6  = 3032810501862889
Blk7  = 38a5020500a60881
Blk8  = 01010403030009a7
Blk9  = 1785157ea9a66089
Blk10 = 36ee5d5dba4c360a
Blk11 = 7bfc2be2708e22fc
Blk12 = a902050005000000
Fmt   = 26 bit
Wieg  = 0000000001320970
Fac   = 153  [H10301]
Card  = 1208

jump · 2017-04-26 22:59:41

Interesting. That protocol looks very familiar to me

0xFFFF · 2017-04-27 02:30:42

jump wrote:

Interesting. That protocol looks very familiar to me

Are you familiar with the INFINEON M8830-B1, NXP SAM AV1 or NXP SAM AV2?

jump · 2017-04-27 22:19:39

Not particularly. And that's probably why the header of the packets is different than the one I am used to.
But the payload on the other hand is something I know.
It seems, according to the capture, that the packets sent to the chip have a 16 bytes long header, then you have the payload (all are starting with 0xBD in the above snippet). The response from the chip seems to use a shorter header (9 bytes)

I also see some patterns and can make a bit of sense of the headers but the snippet is a bit short and without the direction of transmission and context it's harder to discriminate between a coincidence or an actual meaning for a given byte

Last edited by jump (2017-04-27 22:23:45)

0xFFFF · 2017-04-28 01:44:52

What I'm seeing is mostly APDUs with some sort of encapsulation.
I suspect the CLA will only between the values 0x80 and 0x83.

Everything I'm looking at breaks down pretty easily.
Looking at a random line from carl55...
BD 82 00 1A A0 82 00 16 A0 82 00 12 80 82 00 04 37 9F E4 13 81 02 00 00 83 04 00 94 F4 6D 00 00 7D

BD - Jump's start byte
82 - Channel
1A - Length byte

01  BD 82 00 1A
02  A0
03     82 00 16
04     A0
05        82 00 12
06        80
07           82 00 04 37 9F E4 13
08           81 02 00 00
09           83 04 00 94 F4 6D
10  00 00 7D

carl55 · 2017-04-28 01:57:38

Just to add some clarification to the raw communication capture shown above .....
The first line in each 3 line group are microcontroller to SAM data packets.
The second line is the SAM response back to the microcontroller.
I believe that the third line is simply an acknowledge checksum associated with the SAM to microcontroller response packet.

If anyone is interested, the link below is to a pdf that shows a more extensive communication sequence between the microcontroller and SAM for three different cards. I have overlayed the data from each read so it is easier to see the byte differences. The relevant data has also been color coded to make it easier to find.
Better Example Here

jump · 2017-04-28 07:50:48

The fact that the reply from the chip always end with 90 00 gives away the APDU wrapping indeed.
The payload is ASN.1 encoded in fact. So it's parsed as Type-Length-Value. If the MSB of Length is set then (Length & 0x7f) indicates how many following bytes are used to encode the length of the value.

Normally the bit 5 (starting from 0) of Type indicates whether the value will also be an ASN.1 value (constructed vs. primitive). But I already saw that rule not being followed by HID IIRC. Bits 6 and 7 indicates the class (unviersal, context, application, private).

So BD 82 00 1A is decoded as:
BD = Tag(context-specific, constructed, 0x1D)
82 = Length encoded in 2 following bytes
00 1A = Length of data (which will be ASN.1 encoded too because Tag is constructed)

0xFFFF · 2017-04-28 08:08:23

Ahh. Can't believe I didn't see that before.
HID uses ASN.1 all the time.

iceman · 2017-04-28 10:47:09

and where did I see a ASN.1 decode.. Something Peter Gutmann wrote.

Found a javascript imp:
https://lapo.it/asn1js/

With one row from above:
https://lapo.it/asn1js/#BD820038A082003 … 040094F490

carl55 · 2017-04-28 16:00:20

That's all very interesting. It looks like I have got some studying up to do.
Another interesting thing is that the same type of data structure also seems to show up in the cards actual SIO data payload. If you look at the contents of the first few blocks of SIO data in the earlier example you will see what I mean.
(Blks6-8 = 3032810501862889 38a5020500a60881 01010403030009a7).

Go_tus · 2017-05-05 07:10:47

Good job!!!! even I don't understand much. the blk 05 = ffffff0006ffffff always for the SIO type?

mollusc · 2017-05-11 02:53:34

Probably stating the obvious here, but if you paste the full contents of blocks 6-12 into the ASN.1 decoder linked above, it parses! The main payload seems to be "7EA9A6608936EE5D5DBA4C360A7BFC2BE2708E22FC". No doubt it's encrypted or otherwise obfuscated.

0xFFFF · 2017-09-27 08:40:35

Looking at carl55's post:
1st command has something to do with a timer.
2nd command is setting IO registers.
3rd command appears to be enabling / disabling reading of different technology types
4th command onwards, transmitted data:
0C05DE64
8002
05D51E9B59DB35FE7C
06064556
0609B2AE
00

jump · 2017-09-27 10:42:45

0xFFFF wrote:

1st command has something to do with a timer.

It's the primary SAM asking the IO control for the RunTimer (I guess that's the uptime of the reader)

0xFFFF wrote:

2nd command is setting IO registers.

Sleep command actually

0xFFFF wrote:

3rd command appears to be enabling / disabling reading of different technology types

Scan for a HF card, enabling protocols ISO14A, Pico15693, FSK and ASK
The answer is a Pico15693 card and its CSN

0xFFFF wrote:

4th command onwards, transmitted data:
0C05DE64
8002
05D51E9B59DB35FE7C
06064556
0609B2AE
00

0xFFFF · 2017-09-27 11:30:01

jump wrote:

0xFFFF wrote:
1st command has something to do with a timer.
It's the primary SAM asking the IO control for the RunTimer (I guess that's the uptime of the reader)

Yup. Specifically HwioCommandGetRunTimer

0xFFFF · 2017-09-28 01:36:56

FYI - If you don't want to or can't de-pot...
These messages can be transmitted via OSDP / UART.
I'm not sure about other interfaces (have not tested) but I'm sure that the SPI should work also.

Proxmark3 community

Announcement

#1 2017-04-25 05:30:20

PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#2 2017-04-25 19:56:17

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#3 2017-04-26 02:31:00

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#4 2017-04-26 17:23:24

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#5 2017-04-26 22:59:41

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#6 2017-04-27 02:30:42

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#7 2017-04-27 22:19:39

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#8 2017-04-28 01:44:52

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#9 2017-04-28 01:57:38

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#10 2017-04-28 07:50:48

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#11 2017-04-28 08:08:23

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#12 2017-04-28 10:47:09

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#13 2017-04-28 16:00:20

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#14 2017-05-05 07:10:47

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#15 2017-05-11 02:53:34

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#16 2017-09-27 08:40:35

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#17 2017-09-27 10:42:45

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#18 2017-09-27 11:30:01

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

#19 2017-09-28 01:36:56

Re: PCBs RK40 (old 6130), RPK40 (new 921), R10 (old 6100), RP10 (new 900)

Board footer