Author Archives: benn
Google Wallet – Last Four Digits Revealed to Malware Vulnerability
If you’re using Google Wallet, please check your version number and ensure you’re up-to-date (1.1-R57v5 as of this post). This post describes an issue we discovered and reported to Google a few weeks ago. It has now been patched in the latest version of Google Wallet. We think it’s an interesting concern for both end users of Google Wallet and other application developers. While not the most earth shattering vulnerability, it’s probably not something you would want malware collecting about you or your credit cards.
To start, there has been a lot of great research into Google Wallet recently, including the ability to brute force the account PIN and viaForensics dive into application data storage. Both of those attacks required root level access to the device. However, in this attack, the heart of the issue involves the ability to send a specially formatted intent message to Google Wallet. This is something any Android application can do, once installed, without any additional permissions. The specially formatted intent message essentially tells Google Wallet to turn on verbose logging. Data which gets logged includes the last four digits of any credit cards that have been associated with your Google Checkout account (since Google Checkout is now rebranded/merged with Google Wallet). While the full card number is not shown, this data (along with other information that might get collected as well), could be used to target you for a fairly believable social engineering attack. Additionally, the inclusion of Google Checkout information means card numbers which I never thought of as part of my mobile phone’s digital wallet, were included as well (you’ll see these as “UNPROVISIONED” listings in the logs).
Last 4 digits of credit card numbers from Google Wallet/Checkout in the Android Logs
We’ve put together a short video which shows our “malware” application sending this intent message and collecting data on a non-rooted Galaxy Nexus (running version 1.1-R52v7 of Google Wallet) . You’ll notice the application does require the one permission, the ability to read the device logs. For the technical details, please see the our security advisory.
http://intrepidusgroup.com/advisories/intrepidus-advisory-20120418.txt
As for the fix, Google has stated they’ve reviewed all of Wallet’s logging features and have added the android:exported=”false” attribute to the LoggingPriorityChangeReceiver to prevent third party applications from enabling this feature.
Video: Google Wallet – Verbose Log Capture Malware Example
Java Reflection in Android…FTW
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/com.android.nfc_extras.jar 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 = "com.android.nfc_extras.NfcAdapterExtras";
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=”com.google.android.nfc_extras” 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());
if(mReflectedMethods[i].getName().contentEquals("get")){
//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 com.android.nfc3 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 com.android.nfc3 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=”com.android.nfc.permission.NFCEE_ADMIN” />
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:
- Create a class using Class.forName(“package.class”)
- Find the method using getClass().getMethod(“method”, paramTypes)
- Then invoke the method with the proper parameters
Google Wallet coming for iOS?
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
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.
Google Wallet PIN Brute Forcing
Google Wallet is a project of great interest right now as it is a big shift in how we pay for goods and services in the US (Japan is quite far ahead of everyone on mobile payments). Some researchers have discovered that Google Wallet is storing the PIN for your wallet on the device in a relatively insecure format. Since this information was already released into the wild, we felt we should share our perspective and how we would approach this problem. The PIN data is stored in the application’s SQLite database.
The SQLite database is stored in the Google Wallet data directory. Google wallet stores the pin in the proto column of the metadata table. The data is encoded using the protobuf format (also by Google). The following SQL query retrieves the data:
select hex(proto) from metadata where id = "deviceInfo";
This query retrieves the protobuf data encoding a number of device and user specific information. Protobuf is a data serialization format, similar to JSON in concept. Next the data must be deserialized. The standard way to work with protobuf data is to define a .proto file, which acts as a key for deserialization. These .proto files get compiled down to application specific code and are not in their native human readable format. Raj decided to start to write a generic protobuf decoder (Protobuf Easy Decode) . This Python module can decode protobuf data without a .proto file. Some data is inevitably lost when reading raw protobuf data without a .proto file.
Recovering the PIN with the decoded data required some understanding of the specific .proto structure. Once the salt and the hash of the salted pin retrieved, brute forcing the PIN is a trivial matter: brute_pin.py illustrates how to brute force the PIN.
Shmootime: Shmoocon 2012
It’s time for one of our favorite security conference, Shmoocon. The Intrepidus Group will be there both on stage and in the booth (…and maybe in the hotel bar from time to time). If you’ve got a barcode, please drop by and say hello. The team has busy putting together a fairly crazy, yet shmooball free, booth for this year (apologies in advance to our neighbors). Just looking for the punching bag. We also plan to setup a tent and camp out in the Break It track where you can catch some of us (past and present) speaking.
Say hello to our booth babe
Android Backdoor Fail – The Kindle Fire Easter Egg
Happy New Year! And for all you Kindle Fire owners, happy early Easter as well. TeamAndIRC released their code and write-up for BurritoRoot which restores root level ADB access on the Kindle Fire. There were other ways to root the Fire before the latest update from Amazon, but this one is attention deserving because of how blatantly the developers left this back door wide open.
You can follow along even without a Fire by grabbing the 6.2.1 software update from Amazon’s site. Download the “bin” file, extract it, then find the “service.jar” framework file. This jar will be in the Android format, so to view this in jd-gui, you’ll want to convert it first (dex2jar works well).
Besides the standard com.android.server package you would expect to see in the service framework file, you’ll also notice there’s a “com.lab126.services” package (Lab126 appears to have done work for a number of Kindle releases). At that point, it’s pretty hard to ignore a class called “EasterEggReceiver”. There’s not much to this class and nothing has been obfuscated to make it hard to follow. Any application which broadcasts an intent message to the “com.amazon.internal.E_COMMAND” service with the correct extra data can enable the ADB daemon to restart as root. No permissions are needed to send that intent and there are no checks in the framework to see who sent the intent message (like maybe try to limit this to only apps with a certain signature) — simply any Android app on the device can call this backdoor feature.
Dex2Jar view of Kindle Fire's Services framework file
The means of data passing and the severity of this “feature” are different from the HTCLoggers.apk issue from October of last year, but I think they are both signs of the same trend. Mobile developers writing any sort of inter-process communication call or service need to ensure they are communicating only with other trusted apps. Android already gives you a way to do this, if your apps are signed with the same certificate. I’m a fan of Easter Eggs, but sometimes you want to make sure to limit who can walk away with your tasty burrito.
Man-in-the-Middle (MiTM) and certificate setup on Android 4.0
The Nexus Galaxy and Android’s Ice Cream Sandwich (ICS) are finally here. If you’ve done Android application testing in the past, you’ve probably have tried to install your own Certificate Authority (CA) cert on to an Android device or emulator. This process was somewhat painful and required root level access on physical devices. We have an old blog post here on that process, but that all changes now with ICS.
Installing a certificate can now be done in the Settings->Security menu of an Android 4.0 device and handled in the “Credential Storage” section. This does not require the device to be rooted (at least on the builds we’ve seen so far). The “Trusted Credentials” setting will list both the system wide installed certificates as well as any user added ones. An additional feature is now with a few simple clicks, the end user can disable any CA certificate on their device. Is your vendor still hanging with DigiNotar? Now you can disable that yourself without having to pull files from the device. Just click on the certificate, scroll down to the bottom of the pop-up message, then click the “Disable” button on the right.
Android 4.0 Credential Storage menu
Installing your own certificate is almost as easy. Here was my process. I needed the CA cert I generated in Mallory loaded onto to my Nexus. Mallory creates a unique CA certificate per-installation and stores it in Mallory’s “ca” directory. To move this onto the phone, I started up Python’s SimpleHTTPServer in that directory.
~/mallory/current/src/ca$ python -m SimpleHTTPServer
Now on the phone, I pointed the browser to that server on port 8000 in order to download the “ca.cer” file (adjust your IP address/port/filename as necessary).
http://192.168.90.1:8000/ca.cer
On my device, this dropped the CA certificate to the SD card. Back in Settings->Security screen, find the “Install from storage” option. Click that and your “ca.cer” file gets loaded into the “Trusted Credentials” store under the “User” tab. No bouncing castles or root needed. This will require you to set a passcode on your device (if there is not one already). Face unlock doesn’t appear to cut it just yet.
Mallory's CA Cert loaded on the device
~benn
NFC Intent Filters in Android 4.0 – Don’t forget the AAR
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(“com.google.android.apps.maps”) });
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:
54 – RTD_TEXT
0F – Length of EXT tag (“android.com:pkg”)
1C – Length of Text data (“com.google.android.apps.maps”)
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).
~benn
A Brave New Wallet – First look at decompiling Google Wallet
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 “http://bsbank.com” (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:
4155589991
(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 “gtec.skcc@gmail.com“.
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; = https://systemtest.citibankonline.citibank.com/MSMOTA Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalization ServicePortTypeEndpoint1
private static final DEFAULT_CITI_SOAP_URL_DEMO:Ljava/lang/String; = https://systemtest.citibankonline.citibank.com/MSMOTA Personalization/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTA PersonalizationServicePortTypeEndpoint1
private static final DEFAULT_CITI_SOAP_URL_PROD:Ljava/lang/String; = https://test.mobileservices.accountonline.com/MSMOTAPersonalization_ FUT/Webservices/MSMPayPassOTAPersonalizationService-service1.serviceagent/MSMPayPassOTAPersonalizationServicePortTypeEndpoint1
private static final DEFAULT_FDCML_PROD_URL:Ljava/lang/String; = "https://www.fdmobileservices.com/mAccountsWeb/MbankingService"
private static final DEFAULT_FDCML_TEST_URL:Ljava/lang/String; = "https://cat.fdmobileservices.com/mAccountsWeb/MbankingService"
private static final DEFAULT_TSM_URL_CAT:Ljava/lang/String; = "https://uat.skcctsm.com:8443"
private static final DEFAULT_TSM_URL_PROD:Ljava/lang/String; = "https://pip.skcctsm.com:8443"
const-string v1, "DEVELOPMENT"
const-string v2, "https://jmt0.google.com/cm"
const-string v1, "SANDBOX"
const-string v2, "https://cream.sandbox.google.com"
const-string v1, "PROD"
const-string v2, "https://clients5.google.com/cm"
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.
-b3nn
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
