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
I have been writing a program to control a RWK400 iClass reader so I can do some experimenting with cards, but ran into a roadblock. I know others on the forum here have worked with them, so I'm hoping someone will have some insight.
When I send the "Select Key" command to choose one of the key storage locations in the reader, I get a 6E 00 response:
Tx: 80 52 00 01 08
Rx: 52
Tx: 00 00 00 00 00 00 00 00
Rx: 6E 00I get the correct 0x52 ACK byte after the first part of the command, so it is accepting that. The 6E 00 code is "Invalid Class", which seems to suggest that the reader wasn't expecting the 8 bytes of zeros, but was rather expecting a new command (starting with the 0x80 class byte). The protocol specification says those 8 bytes need to be sent, and the examples from HID agree, so that doesn't seem right though.
Selecting cards / reading CSNs work fine. I'm only getting errors with the longer commands that have multiple steps.
Anyone have an idea what I'm doing wrong? I must not be understanding some part of the protocol correctly.
Offline
I'm assuming you're starting with 80 52 ...?
You should've received 90 00 then sent Select_Card etc....
What is your timing between Tx/Rx like? The reader has a timeout of 80ms
Also, what f/w are you running?
Offline
You should issue a "Select Card" command (without authentication) before you issue a "Select Key" command.
You then take the CSN information that was returned and use that data in the "Select Key" command.
I don't believe that the reader will accept a value of 0x0000000000000000 since that is NOT a valid iClass CSN.
As 0xFFFF pointed out, you also need to watch out for the timeouts that HID mysteriously failed to talk about in the iClass Serial Protocol document.
Here is an example:
[Select Card]
Cmd = 80 A4 00 12 09
Response = A4 01 CSN0 CSN1 CSN2 CSN3 CSN4 CSN5 CSN6 CSN7 90 00
[Select Key]
Cmd(Part1) = 80 52 00 01 08
Response = 52
Cmd(Part2) = CSN0 CSN1 CSN2 CSN3 CSN4 CSN5 CSN6 CSN7 (received from SEL CARD response)
Response = 90 00
[Retrieve Data]
Cmd = 80 C0 00 00 08
Response = C0 + [8-byte Diversified Key of card] + 90 00
Offline
Turned out it was the timeout causing problems. I was sending a command, then polling for a response every 100ms, which I had assumed would be plenty fast. That delayed the Rx of the 0x52 byte beyond 80ms, so the reader timed out. Changed to polling every 10ms and it works fine now.
@carl55
I've been following the communication flow chart in Appendix A of the iClass Serial Protocol document. That (and the command flow table for Select_Current_Key) seem to suggest sending all zeros, but I also tried your method. I do get back the C0 and what looks like a plausible div key. I haven't gotten around to getting the master iClass key yet, so my testing is somewhat limited. Hopefully going to try the key extraction procedure today and then I can work through the full auth and read process with a card.
Thanks for the help!
Offline
Pages: 1