Reversing readers...

0xFFFF · 2012-11-26 11:42:21

I'm working on acquiring firmware dumps of the various iClass readers out there.
So far I only have one and a bit iClass firmware dumps.
I'm curious to know if anyone else out there has been attempting the same thing or has experience with extracting code from PIC micros.
Can anyone in Proxmark land help?

vivat · 2012-11-26 16:23:31

Hello
Try tools like PICdisasm, unPIC...Or send the chips to some reversing company like http://break-ic.com/ (not a spam). BTW why they don't use read protection bit?

0xFFFF · 2012-11-26 22:28:40

vivat wrote:

BTW why they don't use read protection bit?

Actually, they do. The protection bit only helps people sleep better at night.
You can circumvent PIC security using a number of techniques.

Have you used the reversing company you mentioned? What is the pricing like?

carl55 · 2012-11-27 15:30:49

I have successfully extracted the firmware from an RW300 RevA iclass reader using the method that was described in the "Heart of Darkness" paper published last year. The RevA readers use the PIC 18F452 whereas the newer RevC readers use the PIC 18F67J11 which is not vulnerable to the same code extraction method. I have disassembled the RevA code and have used it to learn about how the iclass system is designed. I am not sure that I see the value in extracting the firmware from multiple reader models since they all support the same basic functions.

vivat · 2012-11-27 18:31:54

0xFFFF wrote:

Have you used the reversing company you mentioned? What is the pricing like?

No, this was example
As soon as you guys have firmware dumps, maybe you can upload them to somewhere like http://proxmark.org/files/?

Last edited by vivat (2012-11-27 18:34:19)

0xFFFF · 2012-11-28 11:54:49

carl55 wrote:

I have successfully extracted the firmware from an RW300 RevA iclass reader using the method that was described in the "Heart of Darkness" paper published last year. The RevA readers use the PIC 18F452

Personally I'm having difficulty finding Rev A readers to copy. I have the 18LF6722. HID also use the PIC18FXX2 family.

carl55 wrote:

I am not sure that I see the value in extracting the firmware from multiple reader models since they all support the same basic functions.

Some are similar but they are not all the same. I'm interested in the SE series. I only have two readers at this point in time.

I'd like to compare notes if you're interested.

vivat wrote:

No, this was example

Ah. Well if I get desperate, I'll give them a buzz and let you know how things pan out.

vivat wrote:

As soon as you guys have firmware dumps, maybe you can upload them to somewhere like http://proxmark.org/files/?

I don't think that is a decision I could make. I'd like to know what Roel thinks before I proceeded with anything.
I'd like to hear your reasons why you think this should be done. What about firmware from other manufacturers? (Perhaps another topic?)

Have you attempted the method in the paper titled "Heart of Darkness"?

vivat · 2012-11-28 13:45:50

0xFFFF wrote:

I'd like to hear your reasons why you think this should be done. What about firmware from other manufacturers? (Perhaps another topic?)
Have you attempted the method in the paper titled "Heart of Darkness"?

1. Because there is not so much info about systems built upon "security by obscurity" principle. Having some wiki pages would be nice. Reading academic research papers is boring sometimes. If you don't want legal problems from HID(because reverse engineering/decompiling may be illegal in your country) you can upload archived dumps to some file-sharing junk like rapidshare and set a password.
2. iClass is not very popular in my city. I have read this paper but I don't have any iClass tags/reader.

carl55 · 2012-11-28 16:36:56

Vivat,
I personally do not feel comfortable publishing the iclass firmware dump since it contains all of HID's master authentication and encryption keys. I am however more than willing to assist anyone who makes a reasonable effort to pursue this task on their own.

0xFFFF,
There are usually several RevA iclass readers available on the U.S. Ebay site at any given time. The iclass SE readers are harder to get since they are so new. I assume that HID has fixed all of the previous security vulnerabilities and changed all of the keys in these new SE readers. As a result, I have not tried to analyze them yet.
I am certainly willing to compare notes with you about iclass firmware/key extraction. You can contact me at "info at proxclone dot com".

vivat · 2012-11-29 17:33:00

carl55 wrote:

Vivat,
I personally do not feel comfortable publishing the iclass firmware dump since it contains all of HID's master authentication and encryption keys. I am however more than willing to assist anyone who makes a reasonable effort to pursue this task on their own.

So you think that
iClass dump = iClass master key(s) ?
If they decided to put the key(s) inside every iClass reader they make it's their own security problem. They probably must be using some obfuscation method (hashing/crypting etc) to hide key(s) in firmware. Let's say I want to learn how this system organized to make open-source implementation. Having publicly and freely available information will help me a lot.
Why should I buy their crappy reader for the purpose to learn how iClass works?

carl55 · 2012-11-30 01:10:24

The iclass readers store the master authentication and encryption keys in both EEPROM and in a "Table of Constants" in the front part of the firmware image. They are not obfuscated in any manner. The copy in firmware appears to be reloaded into EEPROM whenever a HID "Reset" configuration card is presented to the reader. This allow the reader to be restored back to a default state whenever needed. As an example, if a reader is configured for Elite/High Security mode then the Reset configuration card can be used to put the reader back into standard security mode. It also erases all of the user keys if any of those have been loaded (R/W models only).
I wouldn't necessarily consider iClass readers to be "crappy" as you stated. With a tool like the Proxmark3 in the hands of a determined hacker, almost all readers on the market today are vulnerable to some type of attack that will make them look less than perfect.

losbolos · 2012-12-01 17:40:25

Has anyone ever tried the technique posted below before?
Link: http://blog.opensecurityresearch.com/2012/11/dumping-iclass-keys.html

From my understanding, it combines the method of extracting RAM dumps described in proxclone (by carl55?) and borrowing codes from Meriac's OpenPCD project. This is useful for beginners like me who'd like to find an easier way of extracting iClass firmware.

I had a problem when trying it out though, and all it gave me was a bunch of 0s dump. It seems that when I applied the VPP programming voltage (using a 9V battery), the LED on the RW300 unit turned off so I'm not sure if it's still responding to commands sent to it.
Does anybody know whether the VPP voltage has to be applied in a certain way? (timing, resistor across VPP-VDD?)

0xFFFF · 2012-12-02 10:07:34

Nope. But it would've been good to know before I put the 'dumper code' on my only Rev A.

I have one of the FTDI leads lying around somewhere. When I find it I'll see if I can get get a full dump of my useless Rev A.

*EDIT*

Found it. I've put a lead together.... and nothing. Device ID is 00000420 (PIC18F452).

carl55 · 2012-12-02 17:26:51

First off you need to be sure that you are using a RevA reader and NOT a RevB or RevC reader. The newer readers use a different PIC microcontroller that is not vulnerable to the same type of attack. After two months of discussions with Microchip's technical support staff I am still unable to tell you exactly why but it appears as though the newer readers clear all GPR's whenever debug mode is entered. As a result, the RAM dump will yield only 0's.
Regarding the programming voltage, there is no fancy procedure, you just apply Vpp according to Figure 2-4 in the PIC18F Programming Specification document. Be careful though since the minimum Vpp voltage is 9.0V (nothing less). When I performed this hack I simply manually applied 12Vdc to the Vpp pin with no pullups ... but either approach should work. The LED getting turned off is a good sign. That is supposed to happen when you enter debug mode since the unit has been master cleared and has not yet been allowed to reach the routine where the LED is turned back on.

0xFFFF,
Your RW300 reader is not useless. It can be revived. Send me an email and I will send you the appropriate hex file (with code protection removed of course) that will allow you to load it back to its original state (provided you have a PICKit2 or other load device).

losbolos · 2012-12-02 22:11:27

Thanks, carl55. Looks like I'm doing it correctly all this time.
I was able to delete the boot and the panels 1-3 separately using the FTDI cable but I'm not able to load the "dumper code".

carl55,
Do you mind sending me the hex file as well so I can restore my units since they are basically useless if I can't get the FW out of it.

carl55 · 2013-01-04 18:05:06

Shortman,
It has been a long time since I performed my first dump of firmware/EEPROM from my RW300 reader so I can't remember all of the details of what I had to do to get it to work. I do remember having some problems though and reading back all zero's was certainly one of them. I can send you a copy of my microcontroller assembly code that I used to extract the EEPROM portion. You can look at the program flow and comments to hopefully see what I ended up with that worked.
It is unclear to me what you mean by "having no knowledge of the command set". If you are talking on the ICSP debug interface then the command set is documented in the PIC programming specification for the 18F452 device. If you are talking about talking to the RW300 via the RS-232 interface then you will need to have the HID iClass Serial Protocol document.
Regarding your power cycle question, you do need to recycle power to the PIC after loading the dumper code in order to get the PIC to run the newly loaded code. A power cycle basically forces the PIC to begin execution at the power-on / cold reset interrupt vector address.
Send an email to me ( info at proxclone dot com) and I will fix you up with the files that you need.

carbo · 2013-02-26 18:34:19

losbolos and shortman,
I also tried the method described by Brad (http://blog.opensecurityresearch.com/2012/11/dumping-iclass-keys.html) on RW300 and like you I only get zeros back. Did you ever find out what the problem was in your case?

urkis · 2013-09-15 14:21:48

Is anyone working on some read/write function for Iclass like mifare? IClass is being more and more popular and we need to implement some good iclass functions to proxmark. If someone have the keys for the standard security level, feel free to contribute to the development community!

Last edited by urkis (2013-09-15 14:22:15)

midnitesnake · 2013-09-15 15:23:46

I agree iClass is slowly becoming more popular over mifare and proxmarkII

I picked up an 1x ole rw300 reader for a cheap price - not sure if its working, but apparently you need 2x readers to extract the firmware, this is as far as I have got at the moment.

0xFFFF · 2013-09-15 23:21:03

Check the h/w version of the rw300. Different versions have different PICs which will determine how/if you can extract the firmware.
Rev A definitely works. Carl55 and I have done this before.

midnitesnake · 2013-10-10 15:46:58

Im currently trying (http://blog.opensecurityresearch.com/2012/11/dumping-iclass-keys.html) on a RW300 Rev A reader.

After 3x attempts:
Red LEDs and a tune on start-up.
Green LED when I apply a card.
Apply the ftdi cable, with a 9v battery.
Nothing for 30secs, then a bunch of zeros.

Update 3x different attempts:
Red leds and a tune on start-up.
Green led when I apply a card.
Apply the ftdi cable, with a 12v battery.
LEDs go out
Nothing for 30secs, then a bunch of zeros.

Do you think this is a firmware issue?

Thanks

Snake

Last edited by midnitesnake (2013-10-11 21:21:52)

dramsbo · 2013-10-30 09:23:49

midnitesnake,

Did you get any further with this? I have a selection of RW300 readers which all claim to be RevA on the packaging, but just give me 0's when I follow the method described in the paper above.

midnitesnake · 2013-10-30 10:41:19

Still stuck with 0's.

Think the memory has been cleared as this guy found out http://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=1030&context=cscsp

I think I going to have to try the original method of overwriting the boot loader to dump the memory. This will break my reader, but don't think I have many options.

Im also not sure what wires the extracted memory will flow over? The readers UART? of the PIC/Emulated PIC UART?

Last edited by midnitesnake (2013-10-30 11:03:38)

carbo · 2013-10-31 15:20:58

midnitesnake: I don't think the problem is a cleared memory. I got the same problem, reading all zeros, even when trying to read from a rewritten (non-empty and non-code-protected) device using that method.

dramsbo · 2013-11-05 15:08:07

Does anyone know if this particular attack is limited to the RW300/400? I have some access to R10 / RW100s, but having tried the method, still only get 0's.

carl55 · 2013-11-05 17:34:41

The specific attack should (in theory) work with any of the older Revision A iClass readers since they all use the same PIC microcontroller. The inherent backdoor flaw is associated solely with the PIC 18F452 microcontroller and has nothing to do with the other circuitry in the design. The attack simply involves communicating directly with the PIC via the ICSP debug interface to read out the contents of its internal RAM File Memory.
Since it appears that several people are having the same problem performing this hack I would suspect that the problem is more likely with the tool that is being used rather than the reader itself. When I originally discovered this backdoor access to the PIC 18F452 RAM ( http://www.proxclone.com/pdfs/iClass_Key_Extraction.pdf ) I was using a dedicated 8-bit microcontroller to generate the necessary SPI serial data streams. Using a microcontroller with the code written in assembly language allowed my design to adhere to the very specific timing constraints that are required when communicating on this interface.
When you try and use a device like the FTDI cable that is running under a complex Operating System you cannot guarantee that the low level bit streams are not being impacted by the random interrupts and task switching activities that are inherent in that kind of implementation. I would suggest that you hook up a hardware logic analyzer to verify that the sequence of events that is occurring is consistent with the desired communication protocol and PIC ICSP timing requirements .

carbo · 2013-12-11 11:20:21

The FTDI has (according to datasheets) a FT232RQ chip which supports synchronous bit bang mode, so I don't see why it shouldn't work. I tried different versions of the driver, but I have not tried on different operating systems. But I do agree that there could be something not working out in the timing and that it might be easier to control with a low level device as you suggest. So I tried to use an Arduino to talk over the ICSP interface, but I still don't seem to get other than zeros. (And I know I have non-zero-data.) I got the timing requirements from the PIC18FXX2/XX8 flash microcontroller programming specification, and I made sure that there is a generous margin to the minimum limits. However, there seems to be numerous frequency settings for the PIC, I'm not sure if different settings will affect the ICSP-timing? Otherwise there is something else I am missing ...

marshmellow · 2014-08-17 04:17:26

Has anyone had success with the ftdi cable? Or is that method not viable?

yeti · 2014-10-18 04:07:57

I've been playing with an R10 rev A for the past couple of days attempting at performing the method from Open Security Research. From what I can tell, it does work and the memory mapping is consistent between multiple card readings, as the Wiegand output is correct for each dump. The code did require a slight modification or two in order to function appropriately as I used an FTDI breakout board instead of the cable.

yeti · 2014-10-18 05:15:52

yeti wrote:

I've been playing with an R10 rev A for the past couple of days attempting at performing the method from Open Security Research. From what I can tell, it does work and the memory mapping is consistent between multiple card readings, as the Wiegand output is correct for each dump. The code did require a slight modification or two in order to function appropriately as I used an FTDI breakout board instead of the cable.

Confirmed. I was able to get the keys from the R10 rev A.

marshmellow · 2014-10-19 02:54:12

yeti wrote:

The code did require a slight modification or two in order to function appropriately as I used an FTDI breakout board instead of the cable.

do you mind sharing what FTDI breakout board you used, and maybe even the adjustments needed?

yeti · 2014-10-22 04:22:15

marshmellow wrote:

yeti wrote:
The code did require a slight modification or two in order to function appropriately as I used an FTDI breakout board instead of the cable.
do you mind sharing what FTDI breakout board you used, and maybe even the adjustments needed?

Certainly for the breakout board. I used a 3.3/5V Basic FTDI breakout board from TinyOSShop. They are now called TinySine. It's using an FT232R so we can set the proper bitbang mode.

As for the code modifications, giving them out would ruin half of the fun

I would note that aside from needing the offsets populated, which we can derive from previous papers on the subject, there are at least one or two changes that should be made. I'd recommend validating the output between the cable used in the example and any FTDI breakout board or cable one may be using.....

Leaving that tidbit I'd be happy to share some of my screw-ups/enlightenments with the process:
1. Ensure that there is constantly 12V power supplied to the reader. Although the reader can be powered from the ICSP connection there were issues after supplying VPP from the 9V+ power source that kept successful EEPROM dumps out of reach.
2. Don't fry the damn thing. I thought I killed my reader when I had a potential surge and goof on the FTDI. The reader would not power on at all. Thankfully I bought my PICKITv2 as insurance in case I had to follow the Heart of Darkness method. I was able to get the reader working again after the reader sorted itself out using the PICKIT and running the diagnostic in MPLAB IDE. Kinda made the purchase less painful in hindsight.
3. Do not bother with the BitMode tool in the FTD2XX example program folders. I found it ruined my output before I could ruin it myself, although it kept the reader from incessantly whining before unplugging it after running the program. Running it prevented me from getting any successful reads (as it would fail a test for asynchronous mode). This required I unplug the board from my workstation and then plug it back in (and then remember to rmmod ftdi_sio and usbserial....usually conveniently after trying to run the program to try again)

yeti · 2015-01-08 04:20:54

fnop wrote:

Has anyone gotten the Open security research method to work and would be willing to share what changes they had to make?
I am dumping all zeros at this point. One thing i noticed... the output here http://blog.opensecurityresearch.com/2012/11/dumping-iclass-keys.html says "Checking bitmode...Success! - 0xf0" but when I run mine shows "Checking bitmode...Success! - 0xf2"
I'm using a FTDI TTL‑232R‑3V3 cable.

It does work, but I'd recommend using a 5V FTDI cable instead of a 3.3V cable. As for the value reported back when checking bitmode my output value did not match the example's bitmode output. I had different values reported back depending upon which FTDI board and cable I used as a sanity check, but it will work. As I stated in a previous post, I wouldn't try to use any of the test scripts for testing bit bang that are included from FTDI, as they can cause issues when attempting to communicate with the reader.

atwolf · 2015-05-01 03:02:43

I have managed to get my hands on a R10 rev A with the header on the back.

just a few questions on extracting the key. Don't worry im not asking for the offsets or the key itself. I am looking though the whitepaper to find those out.

The header which is pin one? is it left to right or right to left? I just want to confirm so i dont blow the thing up. I don't have the required tools right now (maybe in a week) to identify the pins myself.
https://lh3.googleusercontent.com/-sJXblLPKwa0/VULRbxSpG4I/AAAAAAAAKg0/FjoDy5JFKDg/s0/20150501_095848.jpg
is it the pin near the little coper bit?

With the code to dump the memory it mentions a specific FTDI cable.
I only have access to 5v FTDI boards, It came from ebay and is the knockoff FTDI chip that had some issues with the windows drivers several months back. Does anyone know if this breakout is compatible?

Lastly the code mentions colours of the FTDI wires not their actual function when mapped back to pins.
I am looking for the pinout details now to try and match colour to pin but if anyone has this info already it would be a big help.

Thanks for all the work that's been done here

atwolf · 2015-05-13 02:04:57

I am still getting all 0s and could really use any assistance or advice on what i might be doing wrong or what else i should try.

I got a proper 5v FTDI same as advised in the code. I am powering the reader from a 12v supply.
reader is powered up. scan a card, plug the header in and the vpp to a 9v battery.
the red light on the reader turns off as soon as VPP is applied.
The code runs but spits back all 0s
I am using the same driver version however im using a 64bit kali linux build installed on a laptop directly.
I blacklisted the normal serial driver so it never loads.
When VPP is removed the reader restarts stays green and constantly buzzes. removing the ftdi header or running the code again stops this and sets it back to normal where a card can be scanned.

proxmarkzzz · 2015-05-13 08:47:47

As alternative you can use the usbpicprog PIC programmer (http://usbpicprog.org/). It comes with an opensource firmware which you can easily tweak to remove only one memory segment in stead of erasing all the memory at once.

yeti · 2015-05-14 04:21:46

atwolf wrote:

I am still getting all 0s and could really use any assistance or advice on what i might be doing wrong or what else i should try.
I got a proper 5v FTDI same as advised in the code. I am powering the reader from a 12v supply.
reader is powered up. scan a card, plug the header in and the vpp to a 9v battery.
the red light on the reader turns off as soon as VPP is applied.
The code runs but spits back all 0s
I am using the same driver version however im using a 64bit kali linux build installed on a laptop directly.
I blacklisted the normal serial driver so it never loads.
When VPP is removed the reader restarts stays green and constantly buzzes. removing the ftdi header or running the code again stops this and sets it back to normal where a card can be scanned.

I'm interested to see which model R10 you have as all the models that I had access to had a different pin orientation then the picture you had from the previous post, but I'm sure there are different orientations based on the model numbers for the R10 rev A.

It sounds like you are following the same steps that I did as well as what was recommended in the article. I would recommend doing three things:
1. Validate that you aren't running usbserial (which you stated you blacklisted) as well as ftdi_sio. They will both load every time you unplug the FTDI. As I recall when I would forget about ftdi_sio the reader would incessantly buzz after running the program unsuccessfully.
2. Validate which version of C libraries you are running for FTDI support. I was lazy when I attempted with Kali and had to scrounge up a BackTrack 5r3 iso as it had the correct version of glibc and the dependencies I needed. If you are able to run it I'll assume you have what you need.
3. You may want to alter the program to give yourself more time to apply VPP. Depending on how elegant your setup is you may want to put some extra time in to apply VPP and keep it applied. Instead of using a battery pack I literally scrambled to connect my 9V battery after running the program and then make sure that power was constantly applied.

Above all else, read the code and understand what is being done. I suspect you may also want to review your FTDI board to validate its pinout. As I mentioned in my previous post there are some changes required and this will not work "out of the box"

A good check when you think you have it is to validate the Wiegand value reported against the card itself (http://www.brivo.com/support/card-calculator/). If you get that right you are almost there.

atwolf · 2015-05-14 05:22:58

Thanks for the info, I have actually started looking at a hardware option.

Going to see if i can manage something with an arduino instead.
I am also attempting with bus pirate and a raspberry pi since they both do SPI out of the box so no need for code that does bitbanging.

If anyone has already tried alternative hardware based methods would be interested to hear if there was any success.

atwolf · 2015-06-05 10:53:27

It looks like the R10 i have is actually a R10 Rev B.
Given the number of options tried im starting to lean to the fact its not vulnerable to the attack.
Even though its got the same pin out i think this RevB might lock out the dumping methods.

Its such a shame that it doesn't appear vulnerable, I have been trying to find online anyone who is selling any of the known attackable versions but 0 luck so far.

HID Iclass safer now due to not being able to find a vulnerable reader for sale.
If anyone has one that they would be willing to Loan(in AU) or Sell for a reasonable price please let me know.

Proxmark3 community

Announcement

#1 2012-11-26 11:42:21

Reversing readers...

#2 2012-11-26 16:23:31

Re: Reversing readers...

#3 2012-11-26 22:28:40

Re: Reversing readers...

#4 2012-11-27 15:30:49

Re: Reversing readers...

#5 2012-11-27 18:31:54

Re: Reversing readers...

#6 2012-11-28 11:54:49

Re: Reversing readers...

#7 2012-11-28 13:45:50

Re: Reversing readers...

#8 2012-11-28 16:36:56

Re: Reversing readers...

#9 2012-11-29 17:33:00

Re: Reversing readers...

#10 2012-11-30 01:10:24

Re: Reversing readers...

#11 2012-12-01 17:40:25

Re: Reversing readers...

#12 2012-12-02 10:07:34

Re: Reversing readers...

#13 2012-12-02 17:26:51

Re: Reversing readers...

#14 2012-12-02 22:11:27

Re: Reversing readers...

#15 2013-01-04 18:05:06

Re: Reversing readers...

#16 2013-02-26 18:34:19

Re: Reversing readers...

#17 2013-09-15 14:21:48

Re: Reversing readers...

#18 2013-09-15 15:23:46

Re: Reversing readers...

#19 2013-09-15 23:21:03

Re: Reversing readers...

#20 2013-10-10 15:46:58

Re: Reversing readers...

#21 2013-10-30 09:23:49

Re: Reversing readers...

#22 2013-10-30 10:41:19

Re: Reversing readers...

#23 2013-10-31 15:20:58

Re: Reversing readers...

#24 2013-11-05 15:08:07

Re: Reversing readers...

#25 2013-11-05 17:34:41

Re: Reversing readers...

#26 2013-12-11 11:20:21

Re: Reversing readers...

#27 2014-08-17 04:17:26

Re: Reversing readers...

#28 2014-10-18 04:07:57

Re: Reversing readers...

#29 2014-10-18 05:15:52

Re: Reversing readers...

#30 2014-10-19 02:54:12

Re: Reversing readers...

#31 2014-10-22 04:22:15

Re: Reversing readers...

#32 2015-01-08 04:20:54

Re: Reversing readers...

#33 2015-05-01 03:02:43

Re: Reversing readers...

#34 2015-05-13 02:04:57

Re: Reversing readers...

#35 2015-05-13 08:47:47

Re: Reversing readers...

#36 2015-05-14 04:21:46

Re: Reversing readers...

#37 2015-05-14 05:22:58

Re: Reversing readers...

#38 2015-06-05 10:53:27

Re: Reversing readers...

Board footer