Intrepidus Group

Category Archives: RFID

Unlocking NFC deadbolts with Androids

Posted: September 26, 2012 – 6:42 pm | Author: | Filed under: android, Conferences, Mobile Security, NFC, RFID

Program the EZon NFC lock to work with your Nexus

At Shmoocon  this last year, there was a vendor who caught my eye with the Samsung SHS-3121 Digital Keypad Keyless Deadbolt “EZon” Lock. They endorsed the lock for the unique digital keypad, which randomly displays two extra digits that must entered before pressing the actual unlock code. A fairly nice way to ensure extra smudge prints on the keypad and even wearing. What got my attention though was the NFC cards which could also be used to unlock the deadbolt. At Shmoocon, I scanned the sample card with my Galaxy Nexus and realized it was a Mifare Classic card… with no protected sectors or data on it (not that it would have mattered too much since the Mifare Classic encryption can be fairly easily broken at this point). We ordered one for the office to play with even though there were some warnings that the RFID side of things might not have the best security.

I don’t want to turn this into a full product review (or video overview), but I’ll just focus on the NFC side of things. The lock ships with 5 branded “Access Cards” which are Mifare Classics. The lock only appears to be checking the 4 byte UID of the card and if the UID has been previously registered with the lock, it allows access. The UID is like a unique serial number for each card and should be impossible to change after the card is manufactured. None of the cards that are shipped with the lock  are pre-registered, thus they must be manually added for access.

One thought of attack would be to similar to the HID card enumeration attacks (where if you know the ID from one card, it makes it pretty easy to find other values). Scanning the cards that were sent with the lock, the UIDs are not within close numerical range although some parts a similar (the UIDs were: 3e8700b1, be37feb0, eed2ffb0, fe2701b1, and… oops, I lost the last card). Additionally, the lock ships with brute-force detection enabled, which is refereed to as “prank” detection in the manual. Scan five invalid NFC cards in a row, the lock sounds an alarm and requires an administrator to unlock the device (or the door to be unlocked form the inside). Thumbs up for shipping with brute-force protection turned on by default. Unfortunately, we also noticed there’s a reset button hidden on the outside of the lock, so bring a paper clip and reset it after four attempts to avoid triggering the brute-force alarm and time-out.

That said, brute-forcing UIDs right now is a bit complicated. We haven’t seen a way to do this directly on a mobile device yet. A great whitepaper (PDF) on the current state of things was done by Michael Roland a few months ago. So while we can’t do this directly on our devices yet, we were able to purchase a knock-off “Mifare Classic” card from a contact in China which allows us to set the UID on a physical card using a non-standard command. At EUSecWest 2012, Max and I demonstrated using a Nexus S to read the UID off someone’s access card, then program onto this KIRF card in order to unlock the EZon.

So if you use one of these locks, you might want to keep your card in a shield when it’s not needed. However, you could also enroll your mobile phone to be your access key. This would then allow you to control when your card is active and when it is not. If you have an Android device that supports Google Wallet, you’re all set. The trick is to have Google Wallet installed with at least one “Loyalty Card” setup in the wallet, then make sure the card is enabled. Doing this enables NFC card emulation on your device which will present a UID to the EZon when it is within range. This type of card emulation is different from your payment information (so you don’t have to worry about the lock charging your bank account each time you unlock it). You can then enroll your phone just like a physical access card to the EZon and use your phone to unlock the device. The added benefit is that when your phone’s screen is turned off, card emulation is off as well which makes things a lot harder to tap and then clone.


Comments disabled

UltraReset – Bypassing NFC access control with your smartphone

Posted: September 21, 2012 – 8:24 pm | Author: and | Filed under: android, bugs, Conferences, Mobile Security, NFC, RFID, Tools

We were just in Amsterdam to present our research on uses of NFC for physical access control. The two main industries we focused on were transit and hotel systems. Ever since Intrepidus got us Nexus S phones with NFC early last year, we’ve been looking for real world uses of NFC on our trips. We discovered the flaw with the SF Muni Ultralight cards last year on a trip there and followed up with informing them of the issue in December. At the time, we had to take the cards home and use an NFC reader connected to a laptop to do testing. Since then, things have changed; the Android API supports reading from and writing to most Mifare NFC cards, Ultralights included.

Some of the coverage of this has confused all NFC transit systems with those using the Mifare Ultralight cards incorrectly. In our presentation, we listed several cities that we know have NFC transit systems as an example of how widespread the technology is becoming. We listed two cities using Mifare Ultralight cards incorrectly that we have 1) tested and 2) contacted with remediation details.

For those of you that missed the video, we have it posted here:

UltraReset Screenshot

UltraReset resetting an Ultralight transit card

This was a NJ Path 10 trip Ultralight card in the video. When we tap the card to the phone, our application reads all the data in pages 4 to 15 from the card and stores the data to the phone (we also store the card’s UID which we’ll write about more next week on hotel card issues). We then tap the card between two turn styles (which is why the count jumps by two). Once the 10 trips on card have been used up, touching it back to the phone causes the application to write the data back to the card. And with that, the card looks to be back in its original state when it was purchased with 10 rides remaining.

While these Ultralight cards don’t have access control features which are found in more expensive NFC cards, they do support a feature called a “One Way Counter” (which was named One Time Programmable or “OTP” in previous documents). These bits are in page 3 of the card’s data and once a bit is turned on, it can never be turned back off. This way, a card could be limited to being used only a limited number of times. These bits are left unchanged by the two transit systems we looked at which used Ultralight cards.

Ultralight Card OTP values

The one way counter (OTP) values of of the NJ Path card (top) and SF Muni (bottom). Neither system changes these bits when the card is used.

We know a number of cities are looking to roll out contactless technology and hope we can bring light to this issue so that it is implemented correctly in the future. One of the items we also raised in our talk is that full card emulation on smartphones is likely to happen soon. When this does, it could cause a number of NFC based access control  systems to be re-evaluated.

If you think your system might be vulnerable to this issue, we have put an Android application in the Play store which will read and compare the one way counter (“OTP”) on Ultralight cards. Note, the standard cards that you might get from transit systems typically are not Ultralights. Ultralights are typically only used for  “disposable” or “limited use” type tickets.

We have been reading lots of insightful comments on the articles we’ve seen. Please feel free to post questions or comments here and we will do our best to answer them (and no, we’re not planning to release the full UltraReset application). Last but not least, we would like to thank dragos and crew for having us at another one of the SecWest events — it’s always a great to catch up with folks in the industry and hear talks in the single track format. Thanks!

~Corey and Max

Comments disabled

The Cloud Comes to Your NFC Wallet

Posted: August 6, 2012 – 10:58 am | Author: | Filed under: android, NFC, RFID

This week, Google released a new “cloud” based wallet. We had some difficulty getting a device which actually *supported* this wallet, and in the end used Cyanogenmod 9 on a Nexus S 4G from Sprint and installed Google Wallet from the market.

The new wallet welcome screen

We were pretty curious what could possibly be cloud-based about a mobile wallet and how the Secure Element (SE) would be involved in all of this. It turned out that the difference between this wallet and the previous Google Wallet incarnations is that payments are made via a “virtual” credit card, and Google charges back to the original credit card. One Google credit card number (a Mastercard) is used for all of your Google wallet purchases, regardless of the “Selected Card”. For example, if you have a Visa and an Amex card in your wallet, and you want to pay for your groceries with the Visa card, you first select the Visa card via the Google Wallet UI, and it becomes the “Selected Card”. However, to the point-of-sales (PoS) terminal at the grocery store, it looks like you are paying with a Mastercard (which Google has issued to you).

The dialog displayed after making a payment using Google Wallet.

We haven’t yet tested if this MC credit card number is the same across all devices, though my initial guess is that each user will be issued a unique Mastercard credit card number from Google. If you read one of our previous posts on Google wallet, APDU commands are still sent between the wallet application and the phone’s secure element to select the active card, and they are logged to the standard logcat utility.

APDU command visible via logcat as 'desired' data when changing the selected card.

This behavior has a lot of parallels to Google Checkout (which now looks like it’s been merged with Wallet), where you link different financial institutions (credit card, bank account) to a single virtual account from which all your payments are made. This new update changes Google Wallet from a way to store and pay directly with your payment cards to a NFC Google Checkout service. Of course, this means that Google can now keep a repository of your purchases (blah blah big data blah blah). This new wallet format raises several interesting questions:

  1. Is the Mastercard credit card the same on my device and on your device? Or does each Google Wallet user get their own credit card number?
  2. What happens if this Google Mastercard credit card gets stolen?
  3. If I have multiple credit cards in my wallet, how does Google differentiate between cards? The standard “Selected Card” user interface still applies, but either Google is transferring data to its servers using the device’s internet connection (unlikely becuase I was able to make a transaction in airplane mode) or Google is transferring some piece of EMV Co. compatible data across the contactless interface at the time of the transaction.
  4. How do credit card rewards work if all transactions show up on my statement as “GOOGLE * <merchant>”
  5. How do Visa and Mastercard handle splitting the fees? Since there are now two transactions made (one between you and the merchant, and one between Google and you), we’re assuming there are twice as many fees. Is Google eating the fees and taking this as a loss leader?

We hope to find out the answers in a future post, after we get some more quality time with the magical Cloud Wallet.



Comments disabled


Posted: June 20, 2012 – 3:02 pm | Author: | Filed under: Conferences, NFC, RFID, Wireless

This is not what you think it is, unfortunately. It has nothing to do with the USRP, but is the second in a series of posts which should really be entitled “Alice’s Adventures in NFC-land”. Since the second post in this series was supposed to be about demodulation/decoding, I’ll continue the title with the hopes of eventually porting this to the USRP.

This past week I attended training at ReCon, taught by Milosch Meriac. Milosch designed the OpenPCD2 line of RFID hardware, as well as some kick-ass firmware to go along with it. The most important thing I learned? “You know nothing, Jon Snow.” The training, entitled “Holistic NFC Hacking”, covered RFID hardware hacking, including sniffing and emulation (both of which have been a constant thorn in my side while trying to explore the world of NFC). This post will cover sniffing, and a follow-up will cover emulation.

Corey and I have been giving an Intro to NFC Security talk at various venues, in which we have a brief introduction to RFID/NFC waves and hardware. One of our slides shows a 0×52 (wakeup all tags) command that we captured on an oscilloscope followed by the tag’s response, which is the beginning of the anti-collision routine. We point out that, while all communication is propagated on a 13.56 MHz carrier wave, the PCD to PICC (reader to tag) transmits data via Modified Miller encoding and modulates the wave at 100%. The PICC to PCD communication, however, uses Manchester encoding and modulates at only 10%. On top of that, the peaks of the 10% ASK modulation are mixed with an 848 KHz sub-carrier frequency. Here I’d say a picture is worth 10,000 words:

Keep in mind, this waveform has been run through Milosch’s RFID sniffer (more on that later) and is only the envelope of the signal. The envelope is what we care about; it is the top half of the signal, without the carrier wave (the 13.56 MHz part) that is really only useful for vibrating this data through space. In fact, compared to the waveform displayed above (which looks like it could almost be an ugly sine wave), the carrier is so fast that it would look like a solid blob sitting under the blue line. That is an important characteristic of RF communication: your carrier signal must be much faster than your data symbol rate or you will not be able to differentiate one from the other at your receiving end. For reference, here is the tag response *with* the carrier wave. Notice the bottom of the picture where we measure the frequency between the two dotted lines at 13.56 MHz. That part is taken out in the first picture.

Take a close look at the peaks of the tag’s response. What looks like noise or some strange form of clipping is actually another wave: the 848 KHz subcarrier wave we mentioned before. This is a really cool RF concept. 10% ASK is about all the tag can manage with the limited power provided to it. That can very easily look like noise on the signal, so the tag modulates the peaks of its response with a wave that is much faster than the data rate so that the response can be picked out by the receiver. By design, the 848 KHz wave is 1/16 of 13.56 MHz, which allows the sniffer to use a different register on the same counter for both waves (more on that in a later post, too). Here is a close-up of that wave (again, just the envelope):

I was looking for parts of this picture to crop, but I think every part here is important. The crosshairs in the upper right (within the box titled “Zoom Overview”) shows where we are within the whole wave. We are really zoomed in, looking directly at one of the peaks that we saw on the tag response before. Again, we can use the dotted lines to measure the frequency of the wave, or 1/(t2-t1) if we are looking at just 2 peaks. The calculation, on the bottom right, shows 800 KHz. While it’s not quite 848 KHz, we are just looking at one cycle and it’s pretty close.

As per Milosch’s explanation, when the entire wave is displayed on a Fast Fourier Transform (FFT), the 848 KHz wave just looks like 2 bumps at +800 KHz and -800 KHz from the main 13.56 MHz peak. If a sniffing antenna is tightly tuned to 13.56 MHz, it can miss the subcarrier and effectively act as a filter, removing the subcarrier from the waveform. In order to capture the whole wave, he suggested increasing the resistance of the antenna to increase the bandwidth of the signal it will receive. That way, the subcarrier property of the encoding from the PICC can be used to pick out the signal.

More adventures down the NFC rabbit hole soon – the next post will cover emulation; also, a big thank you to Milosch for the in-depth training.



1 comment

Java Reflection in Android…FTW

Posted: April 13, 2012 – 11:57 am | Author: and | Filed under: android, Conferences, Mobile Security, NFC, Reverse Engineering, RFID, Tools

I’ll be hitting a few smaller security conferences this spring (whatup BeaCon and BSidesROC) with a turbo talk on how Java reflection can be useful for accessing hidden APIs in Android. The team at Gibraltar had some great posts on this last year, but getting reflection to work for accessing the NfcAdapterExtras and NfcExecutionEnvironment classes was not as straight forward as things seemed. Here’s some tips on how to get it working (at least on an Gingerbread Nexus S).

First, you want to get familiar with the nfc_extras framework. This is not included in the standard Android SDK, but you can either pull the /system/framework/ file from a device or look at the Android source. You’ll see there are two classes: NfcAdapterExtras and NfcExecutionEnvironment. What I really wanted was in the embedded NfcExecutionEnvironment, but the proper way to get that object is from NfcAdapterExtras.getEmbeddedExecutionEnvironment(). So we’ll need to create that object and method first.

I decided to use reflection to access these classes in my own Android application. Since they’re not in the SDK, I couldn’t just “include android.nfc_extras.NFCAdapterExtras” in my code. Instead, we’ll just ask for that class by name at runtime.

String sReflectedClassName = "";
Class cReflectedNFCExtras = Class.forName(sReflectedClassName);

Wow, that’s pretty easy. Except that we’re going to need to tell the Dalvik VM to load that additional nfc_extras framework so that it knows about that class. To do that, add the following after your application tag in the AndroidManifest.XML file of your application.

<uses-library android:name=”” android:required=”true” />

Now back to our “cReflectedNFCExtras” class. The first thing we’ll need to do is get the singleton NfcAdapterExtras. This is returned by the get(NfcAdapter paramNfcAdapter) method. Note that it takes an NfcAdpater as a parameter, so we have to specify the class for that when looking for this method. The following line should work for that.

Method mReflectedGet = cReflectedNFCExtras.getMethod("get", Class.forName("android.nfc.NfcAdapter"));

However, at first I had mistake in my code that cause this method not to be found (thank Jeremy for fixing this). So instead, I had looped through all the methods using getDeclaredMethods() and stopped when the “get” method we want was found. Here’s the code for doing that followed by invoking the method and passing it the default NFCAdapter which would be the next thing we’d want to do.

Object oReturnedNFCExtras = null;
Method mReflectedMethods[] = cReflectedNFCExtras.getDeclaredMethods();
for (int i = 0; i < mReflectedMethods.length; i++){
   Log.d("NfcAdapterExtras METHOD:", mReflectedMethods[i].getName());
      //Standard default NFCAdapter... need to pass this in to get back the singleton
      NfcAdapter defaultAdapter = NfcAdapter.getDefaultAdapter(this);
      oReturnedNFCExtras = mReflectedMethods[i].invoke(cReflectedNFCExtras, defaultAdapter);

From here out, it’s smooth sailing as long as you take care of one more thing. Your application needs a special premission in order to use this framework, the one for “NFCEE_ADMIN“. The problem is this premission is declared with the protectionLevel of “signature” in the package. There’s a few ways to get around this, but as far as I know, they’ll all require that you have root on the device. Thus, even though we’re using reflection to access these classes, Android’s permissions are still enforced. My way of dealing with this was to resign the package with the same certificate I used to sign my newly created Android application, then adding the following line to my application’s AndroidManifest.xml

<uses-permission android:name=”” />

So there you go. We can now be NFCEE_ADMIN’s as well (on our own rooted devices) using reflection. I’m curious to try this out with other /system/framework packages as well. In most cases, the process should be more straight forward:

  1. Create a class using Class.forName(“package.class”)
  2. Find the method using  getClass().getMethod(“method”, paramTypes)
  3. Then invoke the method with the proper parameters


1 comment

Google Wallet coming for iOS?

Posted: March 15, 2012 – 11:42 am | Author: , and | Filed under: android, iOS, Mobile Security, NFC, RFID

The list of two OS types in WalletShared: ANDROID and IOS (click to enlarge)

Let’s start by saying this is no smoking gun, but a pretty interesting case of information leakage through an application. For our regular blog readers, you’ll know we’ve been looking into NFC based applications over the past year. The jewel of all NFC apps is easily Google Wallet and thus we’ve spent a large amount of time trying to understand it. When you decompile an Android application, which isn’t obfuscated, you’re able to see the same class names, method names, variable names, and other identifiers as in the developer’s source code. In this case, Google Wallet includes a package called “wallet.proto” which contains parsers for any “Protocol Buffer” formatted data the application uses. While the name “Protocol Buffers” sounds generic, it’s actually Google’s well-documented mechanism for serializing data (think of it as their version of XML or PLists). If you followed the Google Wallet PIN hashing issue, you’ll remember that the PIN hash is stored in a protocol buffer.

The “WalletShared” protocol buffers package in the current version of Google Wallet contains hints of iOS within the parsers definitions. This includes defining the “DeviceContext -> HardwareType” field with only two values: “ANDROID” and “IOS”. iOS strings are also found in two additional protocol buffers called “IosDevice” and “IosWallet”. The classes only leak a little detail about the information being collected which include items named “appId”, “appVersion”, “walletUuid”, and a few “model” and “version” items.

Function names with "iOS" in the string

Function names with

Now you might ask why anything about an iOS application, written in Objective C, would get compiled into an Android application, written in Java. This could happen because of how a Protocol Buffer structured data definition file is created. A developer typically creates a “.proto” file, which is a programming language independent file which defines the data structure. This “.proto” file is then compiled using the “protoc” application and creates the appropriate files for the language you are programming in. Thus, it’s simple to use the same “.proto” file to create a Java object or an Objective C object if they are both going to use the same data structure. While Objective C is not in the official protocol buffers package, there is an add-on for that language available. Thus it is quite likely if there was a “shared” data structure which both clients and the server would need to parse, the same “.proto” file would be used regardless of the application’s programming language.

Of course, if Google is developing Google Wallet for iOS, it raises numerous questions. Since iOS devices do not currently include an NFC radio or secure element, is Google planning to release a case, or “sleeve,” with these components? Or do they know something about the next iPhone we don’t? And if the next iPhone does have NFC and a Secure Element, would Apple allow Google access to those components? In any case, if Google is working on developing their wallet for iOS, this could be a sign of strong commitment by Google to contactless payment technology. And that’s a win for everyone regardless of which device is in your pocket right now.

Comments disabled

USRP for NFC Part 1

Posted: November 30, 2011 – 3:30 pm | Author: | Filed under: NFC, RFID, USRP

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:

  1. USRP @ $1700 (USRP N210) or $700 (USRP 1)
  2. LFTX, LFRX @ $75 each
  3. 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!


Comments disabled

NFC Intent Filters in Android 4.0 – Don’t forget the AAR

Posted: November 15, 2011 – 11:57 am | Author: | Filed under: android, Mobile Security, NFC, RFID

If you were developing a NFC application on Gingerbread for Android and were using intent filters, you had to be concerned about other applications on the device trying to intercept those intent messages. We did a blog post about this in May titled “Hijacking NFC Intents on Android“.  Well with Ice Cream Sandwich, you now have a new NDEF record which you can add to specify that your app should handle the NFC intent (and if your app isn’t installed, the user should then get prompted to download it from the market). This new tag is being called an Android Application Record (AAR).

In our past blog example, if you were writing your NDEF message using an application on Android, you would want to include a second NDEF record into your NDEF message. Here’s how that code would look:

NdefMessage msg = new NdefMessage(
new NdefRecord[] { rtdUriRecord, NdefRecord.createApplicationRecord(“”) });

Google has a good example of a full “Beam” application which supports AAR in the latest SDK (or you can view it online here). You’ll see the AAR is commented out in the code example, but you get the picture. This ends up being a great compromise for developers creating NFC applications. If you want to leave around generic NFC tags where it doesn’t matter what application handles the data, you don’t need to change a thing. However, if you need to launch a particular app, include one extra record. We’re not sure how well this will carry over to other platforms besides Android, but at least for now, our Blackberry Bold 9930 with NFC just ignores the extra NDEF record and handles the URL in the tag as expected.

Now the rest of this post is just so we can geek out about what an AAR actually is when written to a tag. We used an Ultralight-C and then read the tag data with libnfc. Here’s a screenshot of the values.

We’ve highlighted the AAR information. This appears to be using a Text Record Type Definition which follows the RTD external name format. If I’m reading the specs right, here’s what some of those values mean:

0F – Length of EXT tag (“”)
1C – Length of Text data (“”)

After that is our ASCII values for that record until our end of NDEF message marker “FE” (you can also see the Well Known URI record in the tag before the AAR data).


Comments disabled

A Brave New Wallet – First look at decompiling Google Wallet

Posted: September 21, 2011 – 10:12 am | Author: | Filed under: android, Humor, Mobile Security, NFC, Reverse Engineering, RFID, software security

For the record, I welcome our new contactless payment overlords. I truly see the value in having the ability to make a payment transaction with our mobile devices. This opens up an opportunity to make these transactions more secure, give customers a better user experience, and also give them more control over payment options. Sure there are risks involved with this new technology and everyone should do their own weighing of the risk versus benefits, but I imagine a good number of you already have done this with deciding to use a current payment system over cash (or gold). However, a first (and rather quick as I’m supposed to be on vacation) look at the new Google Wallet code makes me wonder if this first release might need a bit of polish.

If you would like to follow along even without a Nexus S 4G, you can grab the new over-the-air (OTA) update from Google here. You can find the main parts of the new Wallet application in the “\system\app” directory of the update, but it will need some deodexing.

I typically start going through an app with the AndroidManifest.xml file. One thing that jumped out at me with the six “debug” and five “fakes” activities listed in the manifest. As a general best practice, debugging code should be removed from production releases. However, you do have to appreciate the humor of the “BsBankManagerActivity”. Yup, sign up with “BS” bank by calling “6501111111″ or visiting “” (BS Bank heard there was a BEAST breaking TLS this week, so they dropped it). Going through the BS code leads to some more fun “bsness” later on as well, such the revelation that “something is seriously wrong with this image URL” (which they were working on back in January?)

Additionally, there’s a handful of test related phone numbers left in “DebugMenuHelper” and “DemoDataPopulator”. Here they are in the format found:

(415) 626-9682
(510) 351-0108

You will notice there are a few obfuscated classes in the wallet application. These appear to be related to the OTA proxy parts of the application. While not extremely complex in its functionality, I do think it’s appropriate to obfuscate this. Unfortunately, it appears that a great deal of logging can take place here and the default level is set to “FULL_LOGGING” (although it appears this level can be dynamically changed).

We haven’t yet seen what data gets logged by this, but the obvious concern would be a malicious log reading application as described over a year ago by the Lookout team. There also appears code that will send some log messages to ““.

Continuing with the testing related code in the production application, lets pull out the number of test/demo/uat URLs (which don’t seem totally bogus but still could be). “CodeConfiguration” has a number of these:

private static final DEFAULT_CITI_SOAP_URL_CAT:Ljava/lang/String; = Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalization ServicePortTypeEndpoint1

private static final DEFAULT_CITI_SOAP_URL_DEMO:Ljava/lang/String; = Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTA PersonalizationServicePortTypeEndpoint1

private static final DEFAULT_CITI_SOAP_URL_PROD:Ljava/lang/String; = FUT/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalizationServicePortTypeEndpoint1

private static final DEFAULT_FDCML_PROD_URL:Ljava/lang/String; = ""

private static final DEFAULT_FDCML_TEST_URL:Ljava/lang/String; = ""

private static final DEFAULT_TSM_URL_CAT:Ljava/lang/String; = ""

private static final DEFAULT_TSM_URL_PROD:Ljava/lang/String; = ""

const-string v1, "DEVELOPMENT"

const-string v2, ""

const-string v1, "SANDBOX"

const-string v2, ""

const-string v1, "PROD"

const-string v2, ""

Finally, with each point release of Gingerbread (2.3) we’ve see code around the NFC components changing greatly. Generally adding new functionality, but at times deprecating older ones. In the wallet code, there appears to be over 50 classes with at least one deprecated method.

I’m sure many others are looking at this code as well and have some intersting finds. We are looking forward to making a payment soon with our Nexus S. Maybe we’ll use it to buy a pair of shoes.

Update 11/18/2011

Its been a while now and there’s been quite a bit of good work on Google Wallet done on XDA Developers. To clear a few things up, the email address appears to be for Android Cloud to Device Messaging (C2DM) and a lot of the debug code was removed from the wallet updates which have been pushed. That said, you can flip on the “Debug” menu in the orginal code. If you want to get this to run on a device though, you’ll need to resign a few other packages or fix permissions.

Built in debug menu in Google Wallet


Comments disabled

USRP 101: Unlocking Wireless PC Locks (and freeing dolphins)

Posted: July 18, 2011 – 5:39 pm | Author: and | Filed under: Cryptography, Mobile Security, RFID, software security, Tools, USRP, Wireless

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 “” script comes with GNURadio UHD package. While the GUI was a bit unstable on my system, command line parameters worked well. -f 433.9M -A TX/RX


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 “” script. -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



This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24331 items have been purified.