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
Hi.
Firstly, apologies for starting up yet another HID key-dumping thread, but I'm approaching my wit's end and appreciate like some reassurance that I'm not being a total idiot - though I haven't ruled that out.
I have 3 R40s (6120AKN0000) (there were 4, but it turns out the "Erase" function on the Microchip PIC programmer software doesn't have a safety catch), and am trying to follow the various guides out there to extract firmware, boot loader, EEPROM, etc., and failing miserably.
I started out by reading the "Heart of Darkness" paper and believe I have familiarised myself generally with the concepts, though I am by no means an electronic engineer. I then tried to use an FTDI TTL cable and follow the steps in the OpenSecurityResearch blog post (hxxp://blog.opensecurityresearch.com/2012/11/dumping-iclass-keys.html), but found that I get only 0's returned.
I then came across the Pentura "iCLASS is not enough" post (hxxps://penturalabs.wordpress.com/2014/03/17/iclass-is-not-enough/) and am attempting to follow that through, but not having a massive amount of success with that either. The author says that he didn't have any success with the OpenSecurityResearch post, but was able to use the pic18-icsp code in the OpenPCD repo (hxxp://www.openpcd.org/git-view/iclass-security) to dump the relevant info.
I have managed to compile this code and have run it (admittedly within a Windows 7 VM with the FTDI cable passed through from the host OS), but don't get any meaningful output from it.
The app detects the FTDI cable, and with the cable physically connected to the R40 and after pressing "Connect" on the application, I can then press "Read" and the text area populates with 0's until 120h, at which point the app locks up and has to be forcibly terminated.
It has occurred to me that I still have the FTDI pins wired for use with the OpenSecurityResearch article, and that the Pentura blog post doesn't mention the order of the pins. Looking through the code for the pic18-icsp app, it does define some pins. Does the following table look like what is needed?
Reader FTDI
----------------------------------
Pin 1 Vss Black
Pin 2 Vdd Red
Pin 3 Vpp/MClr Yellow
Pin 4 PGD Green
Pin 5 PGC Orange
Pin 6 PGM BrownAny pointers / advice would be appreciated!
Offline
Looks like the pin connections above do the trick, though I still can't get anything other than 0s from the OpenSecurityResearch code. I took the reader I erased earlier, connected it to my PICkit, and wrote some random test data to the boot and EEPROM areas with the PICkit Programmer leaving the code-protect and data-protect bits unset.
I then tried to erase and flash this reader using the pic18-icsp code, re-connected the reader to the PICkit, and re-read the boot and EEPROM areas to find that my original test data was still intact.
It looks rather like I'm screwing something up with the various examples of bit-banging-related code. I have tried it both passed through to a Windows VM and natively on a Linux machine, and get nothing encouraging from bit-banging, while the PICkit programming (from a Windows VM) worked fine.
In an effort to re-create exactly the steps outlined in the OpenSecurityResearch article, I have downloaded Backtrack 5r3 and attempted to compile the code. gcc now complains that the libftdi2xx.so is using a later version of glibc. I can't update the Backtrack installation as the distro is now dead, and the repos have been removed. I can only surmise that the author was running a (then) up-to-date and current version of Backtrack when he wrote the article, and that these updates had pulled the distro up to a version of glibc sufficient to work with the FTDI so.
I can also take the .hex files produced by the OpenPCD firmware-dumper code and flash that to the reader, but that has the effect of erasing the entire reader before flashing, and still setting the code-protect fuses. I seem to recall that the PICkit3 programmer allows erasing and programming of individual blocks rather than bulk-erasing, so I'll look in to that.
In the meantime, if anyone has any suggestions (or observations about where I'm going wrong) which might put me out of my misery, please feel free!
Offline
I am somewhat confused. You stated that you have a copy of the ".hex" firmware code that was produced by the OpenPCD firmware dumper code.
If you have that code then by definition you have a copy of the firmware and the EEPROM memory (including iclass keys). You simply need to extract that information from the file.
If you modify the configuration register values that are used to enable/disable the code protection then you should be able to view the data using the PICKit2.
Below are the values of the configuration bits for the "code protect" state and the "non-code protect" state.
With Code Protection Enabled
Config1 (0x30000) = 2200
Config2 (0x30002) = 0F0A
Config3 (0x30004) = 0100
Config4 (0x30006) = 0081
Config5 (0x30008) = 0000
Config6 (0x3000A) = 8000
Config7 (0x3000C) = 400F
With Code Protection Disabled
Config1 (0x30000) = 2200
Config2 (0x30002) = 0E0A
Config3 (0x30004) = 0100
Config4 (0x30006) = 0081
Config5 (0x30008) = C00F
Config6 (0x3000A) = E00F
Config7 (0x3000C) = 400F
You simply need to modify these values in the ".hex" file so they get loaded to a non-code protected state.
You do this by modifying/replacing the section of the ".hex" file that loads these parameters. It is usually found at the very end of the file.
Delete this from ".hex" file
:020000040030CA
:0E00000000220A0F00018100000000800F4066
:020000040020DA
:08000000FFFFFFFFFFFFFFFF00
:00000001FF
Replace deleted ".hex" file data with this:
:020000040030CA
:0E00000000220A0E000181000FC00FE00F4029
:020000040020DA
:08000000FFFFFFFFFFFFFFFF00
:00000001FF
Also, make sure that the "Enable Code Protect" and "Enable Data Protect" check boxes are unchecked in the PICKit2 TOOLS menu.
Otherwise it will override the configuration bit settings that were loaded from the ".hex" file.
Once you do this you should now see legitimate data (not all 0's) show up in the PICKit2 code and data windows.
Last edited by carl55 (2016-01-02 17:16:39)
Offline
Hi Carl, I'll bet you're not half as confused as I am!
The .hex file I was refering to was the code which is produced by compiling Milosch Meriac's firmware-dumper application (http://www.openpcd.org/git-view/iclass-security/tree/firmware-dumper). Unless I'm mistaken (again, ruling nothing out), this can be flashed to the reader at, first, the program memory and then on a second reader the EEPROM, to obtain the various data.
This code is, apparently, what the OpenSecurityResearch article was based upon.
I can successfully put the code on to the reader using a PICkit, but I haven't quite figured out how to receive the data that it's reading from the device and sending back.
The second method (as resorted to in the Pentura blog post) involved compiling some code for a Win32 app ((http://www.openpcd.org/git-view/iclass-security/tree/pic18-icsp) and running it to erase, flash via bit-banging, and dump various parts of the reader's memory. This doesn't appear to have worked for me as the known values I put on the reader's EEPROM before using this app were still there after attempting flashing.
Similarly, the OpenSecurityResearch article only ever dumps 0's, despite me having totally erased the EEPROM, removed the code-protection, and written known values. I have no idea why the FTDI cable-based methods don't work. I modified the OpenSecurityResearch code to output the raw EEPROM values it receives while it is dumping to make sure it wasn't the permutation which was messing up, and still get 0's.
It seems like neither of the bit-banging methods work. I have tried it with two different FTDI TTL232-5v cables with the same results, and with a dedicated 12v power source rather than relying on the power from the FTDI cable.
In short, I'm still stuck trying to recover the data from a working reader. Once I have that, I can apply your suggestions above to reflash to a reader and let me view the data. I did re-read the firmware-dumper code (referenced above), and noted that it sets the code/data-protect when it generates the dumper hex. I'll modify that so that I am at least able to read that from the reader while I'm tinkering.
Offline
OK, my mistake. I misunderstood what PIC hex load file you were referring to.
One thing to be clear about .....
You can't use Milosch Meriac's dumper code to obtain data from an R40 reader. His dumper code relies on the use of the readers RS-232 serial interface to dump out the data where it can then be captured by some terminal software running on a PC. His code sends the data he is trying to dump directly to the PIC's UART peripheral.
Only the HID RW series reader/writers have the RS-232 serial port interface brought out of the reader.
In order to dump data from a "non R/W reader" the firmware dumper code must first be modified to bit bang the data out one of the other interface pins of the reader (e.g. wiegand D0). This is the method I used to dump firmware out of the R10,R40, RK40 readers when I was doing my testing.
The FTDI method is simply used to dump the PIC RAM. This will gain you access to the reader key information but it cannot be used to dump the reader firmware. This attack can be used with "any" RevA reader and is not just restricted to the RW models.
If you send me your email address I can probably set you up with what you need. (info at proxclone dot com).
Offline
Pages: 1