Author Archives: mxs
Bluetooth: Defining NAP + UAP + LAP
Just a quick follow up to last week’s post, defining what NAP, UAP, and LAP actually are and where they come from. They are the 3 components of 6 byte “BD_ADDR” (Bluetooth device address):
NAP: “Non-significant Address Part”. 2 bytes. These are assigned by the IEEE and are publicly available here. Depending on who makes the Bluetooth hardware, there can be anywhere from 1 to 10′s of possible NAP portions. For example, Xerox is assigned 00-00-00 through 00-00-09 (along with 00-00-AA and 9C-93-4E). A search through the IEEE database for “Motorola” returns 250 results. Just to be clear, the first 2 bytes of these assignments are the NAP, and the last byte is the UAP. We can narrow the search space even further by filtering the list based on the assigned UAP, which we can also get by sniffing communication:
UAP: “Upper Address Part”. 1 byte. The UAP is also assigned by the IEEE and is listed on the same IEEE page as the NAP. The cool part about the UAP, which links it to both the NAP and the LAP (next section), is that it can be derived from packet data. As I mentioned in the previous post, Ubertooth provides a utility for calculating the NAP on-the-fly. This part involves some fairly complex unwhitening and brute-forcing, so we’ll leave that to Ubertooth 
LAP: “Lower Address Part”. 3 bytes. The LAP is easy — it’s transmitted with every packet as part of the packet header! All we have to do (which the Ubertooth does for us) is sit on one channel and wait for a packet to be transmitted. This happens frequently — to the “tune” (har har) of 1600 hops over 79 channels every second, meaning we should see just over 20 packets per second on our one channel if the two devices are communicating at full bandwidth.
So! Now we have the full BD_ADDR. What can we do with it?
Well, first of all, we can sniff Bluetooth! (Pending hardware support ). Bluetooth’s special “hopping” pattern is derived from the master device’s MAC address. Using the BD_ADDR of the master, in theory we can follow that hopping pattern and start extracting useful data from the Bluetooth communication.
We can also target one device directly, or emulate that device and cause all sorts of mischief. We can tell the other device that we forgot our secret Link Key, and need to re-pair and make a new one. Or run attacks against the Bluetooth implementation.
Wallet PIN Storage Best Practices
In light of some recent issues, we thought we’d try to answer the question: “So… where *should* Google Wallet have stored the PIN to protect it on a rooted device?” The answer is… the same place all the other sensitive data is stored! On the Secure Element (SE). Instead of storing the PIN in protected space on the filesystem (which works just fine on a non-rooted device), wallet applications should store the PIN for their particular applet within the SE. Then, using ISO 7816-4, or Application Protocol Data Unit (APDU) commands, send the PIN to the SE and let the SE do the verification. This article, written by a couple guys at RIM, gives a Blackberry-specific but generally very useful overview of NFC payment/Secure Element access components.
APDU commands are exchanged with the SE to execute lots of other functionality — they are the primary means of sending and receiving information from the SE. They can be sent using any API in place for smartcard/SE communication. On the Blackberry, the APDUConnection interface implements:
byte[] exchangeAPDU(byte[] commandAPDU)
The same article mentioned above gives a code snipped for actually using this method:
// The JSR177 connection will use the APDUConnection object
APDUConnection apduConn = null;
// The connection string for the JSR177 connection
String conStr = "apdu:0;target=41.5F.50.5F.44.5F.55.5F.41.70.71.01";
// Define the command to send to the Smart Card applet
byte[] command = { (byte) 0x00, (byte) 0x04, (byte) 0x00, (byte) 0x00 };
try
{
// Open a logical channel to the application
apduConn = (APDUConnection) Connector.open( conStr );
// Send an APDU and wait for a response
byte[] ret = apduConn.exchangeAPDU( command );
// Close the logical channel connection
apduConn.close();
}
catch( Exception e )
{
// handle the Exception
}
At this point, Blackberry seems to have the most comprehensive and well-defined SE interface, baked right in to Blackberry OS. This list of supported Java APIs includes JSR 177, which is the Security and Trust Services API (SATSA). The JSR 177 API allows a Java application to communicate with a smart-card (or SE). Blackberry OS implements JSR 177 in the APDUConnection interface. This interface has high-level methods, including one specifically for PIN verification:
“enterPin(int pinID): This is a high-level method that lets the J2ME application ask for the user PIN value for PIN verification purposes and send it to the card.”
In short, we’d love to see JSR 177 or equivalent implemented in Android. And if it already exists, please leave a link in the comments!
Ubertooth: Bluetooth Address Breakdown
The IG crew is just heading back from ShmooCon, which reminds me of last year’s awesome talk on the Ubertooth One. Intrepidus backed the kickstarter project and, as promised, got 2 Ubertooths. We recently started playing with it, and have a couple of tips and a supplementary script.
We originally followed the post here to get the Ubertooth set up on BackTrack 5, but then had some trouble keeping the device connected and sniffing reliably (similar to our experience with the Proxmark III — sensing a trend here ) After updating the firmware and setting this up on an Ubuntu host, the device works flawlessly. I honestly don’t remember if these are my comments in the commands below or if I found it somewhere on the internetz. I apologize if I stole your commands:
cd ubertooth/trunk/host/bluetooth_rxtx/
./ubertooth-util -f #puts the device in flash mode. lights should blink prettily.
cd ../usb_dfu/
./ubertooth-dfu write /path/to/firmware/bluetooth_rxtx.bin #this is the standard firmware. there are other special ones. suit yourself.
../bluetooth_rxtx/ubertooth-util detachThe “Getting Started” section of the Ubertooth site gives a pretty good idea of what the device can do. We found that the Ubertooth sits on one Bluetooth channel (out of the 79) and sniffs the LAP out of the Bluetooth packets. A little bit on Bluetooth address breakdown (This image is from section 3.2 of this paper):
Bluetooth address breakdown
Bluetooth MAC addresses are comprised of 3 pieces: the Lower Address Part (LAP), Upper Address Part (UAP), and the Non-significant Address Part (NAP). The picture above illustrates this nicely. The Ubertooth can sniff the LAP out of the air, and use the error checking field in the Bluetooth packets to figure out the UAP (ubertooth-lap and ubertooth-nap, respectively).
The NAP (and UAP) are assigned on a per-vendor bases by the IEEE. That means the UAP is available through both the Ubertooth and the IEEE database of NAP+UAP addresses. Using both these resources (and matching up the UAP from both), we can figure out the first 2 NAP bytes pretty quickly! Of course it’s also possible to figure it out if we haven’t calculated the NAP (by appending the LAP to everything we can pull from the IEEE database and ping each one sequentially).
Automating stuff is fun. Here’s my (sloppy) script to figure out the NAP using first the short method, then the long if that one fails: https://github.com/intrepidusgroup/napfinder
USRP for NFC Part 1
The USRP from Ettus Research is an awesome tool for radio analysis. It’s a really complex tool that is capable of doing almost anything involving radio signals (see these two previous Insight posts by Corey and myself, and Raj). That doesn’t even scratch the surface, though. This post will go into the detailed hardware setup for investigating NFC over the air communication using the USRP.
For the RFnoID project, a group of us temporarily turned into nocturnal, lab-dwelling creatures to get this set up. Full credit for this post goes to my group members: Rob Lee-Own, Scott Velivis, and Vincent Lin.
Step 1: Obtain USRP. Ettus Research has several models. For the RFnoID project, we used the plain ol’ black USRP1. At Intrepidus Group, we have the USRP N210. An enormous, frustrating, caveat to the USRP will be mentioned later, but for now, keep this in mind: The USRP1 uses USB, while the N210 uses Gigabit Ethernet to communicate with the computer. Select with care!
Step 2: Select your daughter boards. The USRP requires RFID works in three frequencies: 125 KHz, 13.56 MHz, and 900 MHz. We’re going to be focusing on ISO14443-A, which operates at 13.56 MHz. For the rest of this article, NFC refers to the 13.56 MHz band. We’ll need one daughter board for receiving, and one for transmitting. The low frequency transmit and receive daughterboards (LFTX and LFRX) should fit the bill for 13.56 MHz RF communication at DC to 30 MHz.
Step 3: Select your antennae! This part took trial and error, including some home brew (courtesy of Scott and Rob):
We ended up going with two of the DLP-RFID-ANT from Digi-Key at $40.
Here’s the tl;dr so far:
- USRP @ $1700 (USRP N210) or $700 (USRP 1)
- LFTX, LFRX @ $75 each
- 2x DLP-RFID-ANT @ $40 each
At this point, you should be able to hook it all up, set up GNU radio on your computer, plug in the USRP, and capture NFC goodness right out of the air. Wahoo!
In this video, we’re issuing a read command using libnfc in the left terminal, and detecting NFC energy using the USRP in the right terminal.
Still with me? Good. Here’s where we started spending long nights in the lab banging our heads against the desk. First, a little background on the software/protocol: NFC at its most basic level follows the ISO 14443-4 “Transmission protocol” specification. You can purchase that from ISO for 136 CHF. Google tells me that’s about $150 in real money. The real gem to pull out of those endless pages is that 0×52 is the WUP (wakeup) command, and it will wake up all tags in the area. 0×26 does something similar. In short, we used some hack-y Python to convert hex numbers into a wave format the USRP could understand and transmit. Code here. Feel free to use that code, but please credit RFnoID if you do find it useful. The USRP will modulate this wave at the carrier frequency. You do not need to do that part. You can set up the USRP to use that .wav file using:
from gnuradio import gr
gr.wavfile_source(“wave52.wav”, True)
We’ll get more into the software behind this in Part 2. Back to the hardware. Here’s what we were trying to get:
Notice that wave is 5.5V peak-to-peak. The NFC tag gets its energy from the RF signal the reader (or, in this case, the USRP) transmits. That’s the energy required to wake up and power an NFC tag.
When we transmitted, the tag simply wasn’t responding. Looking at our signal using the oscilloscope, we found that our signal was roughly .5V peak-to-peak. We required an amplifier to boost the signal to the 5.5V level and, luckily, found one in the lab. The amp doesn’t have to be this fancy, but needs to be SMA-in, SMA-out. We’re still searching for a cheaper amplifier that meets our criteria. Luckily Scott understands antennas much better than I do and says: “the 13.56mhz band is so narrow that even a very non-linear amp would look linear for a ~200khz bandwidth.” We’ll keep this post updated if we find something cheap that fits our criteria.
The second major issue we encountered came when we tried to do 2 things: first, detect energy in the NFC band; and second, send a blocking signal (0×52 works well for this purpose because it re-starts the tag’s initialization and anti-collision routine). We were using a USRP1. Remember we mentioned before that the USRP1 connects to the computer using USB. We were getting a large delay (~300 microseconds) we believe was coming from the USB stack (in the Linux kernel) buffering before sending a complete frame, causing a delay in detecting the RF energy. In theory, the USRP N210, which connects via Gigabit Ethernet, would not have this issue and could send frames as soon as they were received from the USRP.
More on the software (GNU radio and the scripts we used) in Part 2!
-Max
BlackHat 2011 and Defcon 19 Summary: MXS9000 Style
We’re all getting back from BlackHat and Defcon now, despite some weather delays and red-eyes, I think everyone had a blast again this year. First off, a big thanks to the Rio for hosting DC and putting up with some shenanigans: there were rumors of rogue cell towers, some definitely unsafe wifi, and elevators mysteriously ended up in “inspection” mode (I had to walk 30 flights down one night! /me shakes his fist). The venue was great (I think everyone appreciated the change in scenery) and the tracks were pretty well organized. My only complaint: CRT TVs? Still?
I really want to thank the FNGs for their valiant effort to misinterpret my list: “re-usable bowl“, “re-usable spoon”, “tube of sunscreen”:
There were some really interesting talks at both BH and DC. In particular, “Reviving SmartCard Analysis”, by Karsten Nohl and Chris Tarnovsky was awesome — Nohl was one of the guys who broke the Mifare Classic by grinding down the chip and looking at the gates to figure out Mifare’s Crypto-1 algorithm. For those of you who aren’t familiar with smartcards, they are essentially a full computing system, complete with a processor, ROM, RAM, and supplementary processors, scaled down onto one chip. In this presentation, the researchers went through some of the previous attacks on smartcards. In early revisions, it was possible to use a microscope to read out memory on the chip. Once that memory was encrypted, attackers began capturing data by putting tiny pins into the wires between the decryption centers and the processor. In newer smartcards, those wires are protected by a mesh, making it far more difficult to read data from that area. Still newer smartcards will hide decryption within the CPU. Nohl and Tarnovsky revealed several design weaknesses in some modern chips — in an unnamed chip, the key was stored right next to the encrypted data in ROM; the baseband processor has unencrypted memory; substantial portions of the bootloader are unencrypted; also, everything sent to on-chip peripherals is in the clear (the wires themselves can be scrambled, but on an 8 bit chip there are only so many possible orders). My favorite part of this talk was degate, a software tool for reverse engineering gate logic from images (the researchers plugged siliconzoo.org if you’re like me and can’t tell the difference between an AND gate and an XOR etched in silicon, or any other logic circuit for that matter).
Also — thank you to Immunity and BlackHat for hosting and sponsoring another great HackCup. It was a little more popular this year with 12 teams competing. Unfortunately, the initial round was only two 15 minute games and Goal++ suffered defeat in both (5-4 and, well, we won’t mention the second game). We’ll be back next year with a leaner, meaner, and more coordinated team. Watch out, Brazil. Pics to follow, as soon as Zach gets his camera back.
That’s it from me. Hope to see you all again next year at BH/DC.
-mxs9000
USRP 101: Unlocking Wireless PC Locks (and freeing dolphins)
Wireless PC Proximity Lock
Have you ever seen one of these “USB Proximity PC Locks” before and thought “There’s NO way that piece of junk is secure”… turns out, you were right.
We had a little office challange recently to break this system, just for fun, and along the way document our Universal Software Radio Peripheral (USRP) which I’m still just starting to get to know. By now, I figure most of our readers would be familiar with the OpenBTS Project which uses an USRP to impersonate a GSM base-station. While this is an impressive use of the hardware at a fraction of the cost of a comercial base-station, the USRP can also be used to impersonate less functional and almost worthless priceless equipment… like that USB proximity lock.
First things first, we need to get one of these locks ourselves. Surprisingly, I got one of these as a gift from ThinkGeek years ago and you can still find them on eBay and a few other sites. I was missing the drivers for mine, but you can still find a copy online. I installed it in an XP virtual machine and paired the remote with the USB dongle. Now anytime the remote was powered down or more than 30 feet away, the lock screen with these pretty dolphins was displayed.
Wireless Lock "lock" screen on XP
What I needed to know next was the approximate frequency. which the remote used to send data to the dongle and unlock the computer. My goal was to capture this transmission with the USRP, then replay the signal when the remote was turned off or out of range. Unfortunately the documentation that came with the wireless lock was pretty silent on what it used to do this. Given the device is so old, I doubted it would use BlueTooth, so I started to look through the installed application files for clues. The application is sold to be re-branded by many companies, but the string “Copyright (C) 2003 Dritek System Inc” in the HIDRead.dll seems to point to the actual manufacture. The USB dongle installed as a HID device under Windows, but the driver does not appear to say anything about the frequency which the dongle and the remote communicate. Neither does the documentation with the driver nor the PDFs I found online. However, one EBay post did contain an image of the back packaging which seems to have “FCC 434Mhz”. This matches the unlicensed spectrum that is commonly used for remote keyless car unlocking and garage doors.
This was also backed up when the remote device was taken apart. There are 2 main chips on the remote I was interested in, one labeled “NDR 550″ and the other “MDT10P55B1S”. Some surfing around leads to the NDR550 being from “Najing Electronic Devices Institute” which list this as a One Port Resonator which operates at 433.92 Mhz. Also looking at the remote’s PCB near the battery there are markings “315″ and “434″. Mine had a blue pen marks next to the “434″ text which falls within the range of the WBX board in our USRP.
Wireless PC Lock Remote
Using the GNU Radio spectrum analyzer around the 433.92Mhz frequency with our USRP N210, we do in fact receive a signal when the unlock remote is powered up and transmitting. The “uhd_fft.py” script comes with GNURadio UHD package. While the GUI was a bit unstable on my system, command line parameters worked well.
uhd_fft.py -f 433.9M -A TX/RX
USRP FFT
The next step was to capture the signal coming from the remote to the dongle. While far from stealthy, the Log Periodic antenna we had from WA5VJB works for 400-1000MHz ranges. So with a bit of gain tweaking and proper timing, we were able to snag a good complex capture of the signal out of the air. Again, GNU Radio makes this easy with the “uhd_rx_cfile.py” script.
uhd_rx_cfile.py -f 433.9M -A TX/RX -g 35 outfile.dump
Then it was time to replay the signal. To do this, we wrote a GNU Radio Companion (GRC) file. I’d recommend looking at the OZ9AEC GRC examples if you’re new to GRC and have a UHD device like our N210. However, this replay script was so easy you could basically point and click to get it working. You’ll need just one source (something that will generate a signal in this case) and one sink (something to transmit the signal). The source was the file we had just captured which we sent to the UHD: USRP Sink. Set the sample rate to match that of the capture (default 1M), the center frequency (433.9 MHz in this case), and adjust the gain depending on your antenna and range. We set the file sink to repeat so running the script would continuously replay the unlock command to the dongle. From there, simply execute the script and watch the PC unlock (Go free my dolphin friends!)
GRC Transmit from File
We also looked at unlocking the system using a Teensy USB development board as a fake dongle (Sid, I want my Teensy back!). We plan to have a follow up post on that, but if you start looking though the registry and configuration settings for this wireless lock, you’ll notice some data looks strange. The “SqrtyKey.Cfg” file and HKLM\SOFTWARE\KeyMark\Wireless PC Lock\Password Answer registry setting are encoded with a transposition cipher. It shouldn’t take you long to figure out the pattern, so once you have, you can use the python script below to save you some decoding time. [download id="271" format="2"] (update: link should now work) (update 2: the maddman posted an awesome clean up of the script for Python 3 here)
So there you have it. Want to defeat a $20 wireless PC lock? All you have to do is spend $2500 on USRP hardware
~Corey and Max
BeaCon
Last weekend Corey, Zach, and I went to BeaCon, organized by MassHackers. This was one of the most fun and interesting conferences I’ve been to this year, and I know other people there felt the same way. It was cool to talk in front of such an approachable and lively group of people and overall a great experience.
All the talks were good, but there were a couple that definitely stood out. Dan Rosenberg and Jon Bieberheide‘s talk on bypassing grsecurity/PaX was clever, super 1337, and full of new techniques, like Rosengroping. Schuyler Towne’s talk on the history of locks was informative and showed some clever ways lock manufacturers could still protect their customers who had to register their keys with the Stasi. One of the cooler designs included a set of 4 dials around the main lock cylinder which had to be set properly for the lock to be unlocked. Once the Stasi found out about this, people had to register the combination, as well as the key. To counter this, the locks were built such that the combinations could be easily reset. While this didn’t stop the Stasi from invading citizens’ privacy, it certainly delayed them in entering citizens’ homes.
Corey and I gave an introductory talk on NFC covering some of the hardware basics behind the readers and tags, the ISO 14443 A standard, prior research that others have done, and some cool haxx. Corey demo’d a malicous “Google Places” poster.
A big Thank You to Zach Lanier, Jack Daniel, and the Mass Hackers for putting on a great conference! Hope to see you guys up there next year.
Cheers,
Max
Cheap printer cartridges! Really.
We have a Lexmark Interact S605 printer in the office and when it shows the “Black Ink Cartridge Low” warning, I can’t help thinking… “cha ching, $25 to Lexmark”. The S605 takes the 100XL line of printer cartridges ($23.49 on Amazon). While reading reviews for the 100XL, I came across one from M. Walters pointing to the 105XL (physically identical to the 100XL but about 1/5th the price at $4.84 on Amazon). He or she claimed there is an RFID tag under the label which identifies the chip. We decided to try it out and, sure enough, M. Walters was right:
The 105XL cartridge fits just fine.
Whoops… we get the “unsupported cartridge” error when loading in the unmodified 105XL
Here are the RFID tags under the labels — we’re swapping the 100XL’s RFID tag with the 105XL’s tag.
Bingo! The cartridge now successfully authenticates to the printer, but it looks like the printer keeps track of each cartridge and its ink level. Still, we were able to print just fine with the new cartridge.
Max’s 2010 Las Vegas BH/DC Summary
Hey, this is Max Sobell and I’ve been interning with Intrepidus Group this past summer. I just got back from my first Blackhat/Defcon with IG a few days ago. Corey summed up quite a few of the really good talks but there was one more that was particularly interesting. The WiMAX Hacking (https://groups.google.com/group/wimax-hacking) talk, from Pierce, Goldy, and aSmig feat. sanitybit was great.
For those of you who aren’t familiar with WiMAX, it’s a wireless broadband technology being deployed (and spreading rapidly) by Clearwire (and others, though Clearwire has the largest network). The team’s research was done on the Clear network, which Time Warner, Comcast, and Sprint all re-brand, though it is the same physical network. One thing I really liked in the talk was the emphasis on the hardware hacks and jailbreaks. They combined some hardware hacking with some VPN tricks to own a couple WiMAX devices and the captive portal page. The team was able to send fragmented packets though OpenVPN on UDP/53 without actually logging into the portal to get free WiMAX. Unfortunately, the downside is that the Location Based Services (LBS) from Clearwire (currently not very accurate and can’t be turned off) allow anyone bumming off the network to be tracked down by fellow users via a development key. One thing that confused the audience was the speakers didn’t qualify what they meant by LBS. In the context of their talk, they were talking about traditional signal strength analysis and antenna orientation. What was not mentioned is that these 4g WiMAX cellular radios also have a real GPS radios which is a requirement of E911. I would assume that the carrier has the ability to locate a device within meters based on the GPS radio.
Friday morning Corey, Mike, and I played in the Hack Cup soccer games on the Goal++ team along with DC Campbell, DC’s friend Judd, and Adam Pridgen. We sustained some early injuries, which left Mike scooting around the Riviera for the rest of the week in a motorized cart, but made it to the semi-finals with no subs. Unfortunately after that we had to stop playing because we lost DC to the airport and Judd had to go back to work. But watch out next year, Goal++ will be back! A big thanks to Nico Waisman for organizing the tournament and to Immunity for sponsoring it.
That’s it from me!
-Max
