Main. Developers community. iClass Is Not Enough. Hacking iClass for Fun, Door-Entry and a Free Lunch. iClass has been broken in the public domain since approximately 2010 when Meriac published his findings at the 27th CCC in Berlin with the Heart of Darkness White-paper.
But why does there appear to be limited support for hacking these cards within the community? The cards have been in the industry since 2001, boasting stronger security then the original Mifare. Since the Heart of Darkness publication HID Global appear to have pulled all their public documentation, and now you have to sign NDA’s go get the documentation needed to learn more about these cards. Also the HID RW300 Rev A Reader Meric exploited is now in short supply. There are a few other readers on eBay etc; but they are typically Rev B or C, which use a different micro-controller that isn’t vulnerable to the same attack Meriac used to extract HID’s Master Authentication & Decryption Keys – which are still in use today! An Unsuccessful Quick Hack. Proxmark3 vs Kantech ioProx. Earlier today we released a patch into the Proxmark3 community for initial support of the LF 125kHz ioProx tags from Kantech.
Current operations are FSK-demodulation and card/tag cloning. Not much is revealed about this type of tag, and only limited data can be found on its data sheet. Kantech state that readers/cards are compatible with standard 26-bit Wiegand and Kantech Extended Secure Format (XSF). But it is difficult to find any info on the XSF format. Instead the community has been hard at work collecting cards/fobs and analysing the differences. From what we have worked out the Kantech ioProx is a RF/64 FSK2a straight modulation.
New Functionality Demodulation Simply place your ioProx tag on the antenna and issue the command: >lf io fskdemod It should return one answer. Example: #00000000 #01111000 #01101111 #10100000 #00110000 #10111110 #00011110 #00001011 #XSF(01)BE:03011 (00786fa030be1e0b) Cloning. Proxmark3 – Adding Ultralight Support. Introduction The Proxmark3 appeared to be missing Mifare Ultralight support.
The ability to identify Ultralight cards was present within the ‘hf 14a reader‘ command. However the facility to read and write cards was sadly missing. But no worries as the protocol and instruction set is essentially the same as Mifare Classic; the only difference is standard Ultralight cards do not need authentication, and encryption and the Block size is 4 bytes long (Note: UltralightC cards are encrypted). As of this morning the svn revision 814 now supports Mifare Ultralight thanks to a community supporter by the handle ‘midnitesnake’. A simple ‘svn update‘ will update any current repository. But I Am The Droid Your Looking For…. Proxmark3 Client Native on Android A member of the Proxmark3 community known as Asper has managed to cross-compile the proxmark3 client for the Android platform.
Depending on the model of your phone (it needs to be rooted), and so long as you have (or can install) the cdc-acm kernel module. This eliminates the need for custom ROMs or even a chrooted environment (such as a chrooted Kali install). You can then freely operate the Proxmark3 over a standard USB OTG (On-The-Go) cable. Allowing for full manipulation and cloning capabilities of LF (125kHz) and HF (13.56MHz) tags. I was really excited to try this out, you might be to! Access Control Part 3: Using the Big Guns!
Introduction Or rather miniature guns, that pack a powerful punch… Our previous posting on Access Control Part 2: Mifare Attacks, we demonstrated a weakness in some Mifare implementations.
Our previous attack relied on the use of a single default key, and using the nested attack to eventually recover all keys for the card. Additionally, we used a rather cheap and affordable ACR-122U reader that costs approximately $40(USD), and the attack process took approximately 20-30 minutes. Below we will repeat the attack with some more advanced piece of kit – the Proxmark3; the kit costs approximately $400(USD) including the antennas and necessary cables (you have to pay a little extra for a protective case). As the Proxmark3 is specifically built for RFID hacking/research; it contains an ARM Processor and Field Programmable Gate Array (FPGA), the attacks are a lot faster as calculations can be performed in hardware as opposed to software. Checking For Default Keys proxmark3> hf mf chk *1 ? Proxmark3 Client Compilation on OSX 10.7+
Recently, I tried to compile the proxmark3 client on OSX using the most recent codebase from the SVN (r756).
I was plagued by errors, regarding the use of QT and missing frameworks. Consensus on the forums was to strip the QT libraries from the Makefile, and recompile. But the client object files hook a lot of graphical calls useful for researching tag modulation. Stripping QT is just not an acceptable option. A familiar looking error: g++ -I/Library/Frameworks/QtGui.framework/Versions/Current/Headers -I/Library/Frameworks/QtCore.framework/Versions/Current/Headers -c -o obj/proxgui.o proxgui.cpp In file included from proxgui.cpp:12:0: proxguiqt.h:11:24: fatal error: QApplication: No such file or directory compilation terminated. make: *** [obj/proxgui.o] Error 1.