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. After patiently stalking eBay and other tech recycling companies; I was lucky enough to obtain a single HID RW300 Rev A, this post will walk through the exploit used to obtain the keys, and follow Meriac’s initial research and exploits. An Unsuccessful Quick Hack Hacking – the Right Way Thanks Like this:
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 Cloning is easy as placing a T55x7 card on the LF antenna and issuing the command: 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. Svn checkout proxmark3 Demonstration The end result, of reading an ultralight keycard from a hotel (the square brackets indicate whether the block is write-protected/locked(1) or unlocked(0): proxmark3> hf mf urdcard Attempting to Read Ultralight... Hf mf urdblhf mf wrbl. 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.
I was really excited to try this out, you might be to! Full details are available on the proxmark forum: A brief summary of the walkthrough I used, can be found below…. Full credit for the Android Port, belongs to the hard work of Asper! Installing Proxmark Client on Android Root your Android device (Not covered here).Install Android Terminal Emulator - Optional/Other necessary steps (depending on device or stock ROM) Demo Source. 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 Below is the patch: UPDATE (30/12/2013):Patch for OSX 10.9: The Proxmark3 client in operation: $ . Like this: Like Loading...