OpenBTS on Droid
To repeat what I said on Twitter, it’s somewhat pointless but a neat hack nonetheless – running a GSM base station from a CDMA handset. With minimal work it’s possible to get gnuradio and OpenBTS working on the ARMEL architecture used on the Droid, allowing my Droid to act as a base station to which handsets can connect; the Droid then connects calls using an on-board Asterisk server and routes them to the PSTN via SIP over Verizon’s 3G network.
The quick version: I can provide voice and SMS connectivity to local GSM handsets using nothing but a Droid and a USRP.
A quick log of what you’ll need to replicate this. This is from memory so I may have missed something; fortunately there’s an easier way that I’ll come back to.
- Root the Droid and install Sholes Mod.
- Mount your SD card in a desktop machine and create an EXT3 partition. I shrank the FAT32 partition but left it otherwise intact, this is probably a good idea if you want to still take pictures.
- debootstrap into the new ext3 partition, bearing in mind the new architecture (use the two-stage debootstrap with –foreign)
- Put the SD card back in the Droid, and mount the EXT3 partition (you’ll probably need to manually insmod the ext3 and jbd modules)
- “mount -o bind” all of the system filesystems into the mounted EXT3 environment (including /dev, /dev/pts, and /sys)
- Mount usbfs in the mounted filesystem at /proc/bus/usb (if you don’t it won’t find the USRP)
- chroot into the new Debian environment, and debootstrap –second-stage
- Go get dinner – it’ll be a while
- Install all the usual dependancies for building gnuradio (if you can’t figure this out on your own you’re in the wrong place!)
- Configure gnuradio with ./configure –disable-all-components –enable-usrp –enable-omnithread –enable-mblock –enable-pmt
- Patch for 52MHz clock (I highly doubt that Droid can handle the stock 64MHz clock)
- Patch the gnuradio makefiles for ARMEL
- Build gnuradio (again, it’ll be a while)
- Install libosip2-3.3.0 from source (the Debian package is out of date)
- Download and ./configure the openbts source, but don’t build it
- Apply the same makefile patch in Transceiver/ and Transceiver52M/ (or you’ll get the same build error)
- Build OpenBTS
- Install Asterisk (from the debian packages is fine)
- Configure as you wish, then connect the USRP (via a powered hub) in Host mode and have fun!
The easier way that I mentioned before would be for me to just zip up an image of my SD card and slap it on a fileserver somewhere public – I’ll also include some scripts to mount it and start everything up correctly. Give me a few days to clean it up and watch on Twitter for the link, it should be as simple as dropping 2 files on the SD card and then running one of them as root.
I’ll also post video of the Droid connecting a call (that sounds far less cool than it should) at some point, I’m also considering running a workshop on all of this if there’s any interest…?
Credit card “security”
I know I’m supposed to be writing up the OpenBTS thing (it’s coming) but this was a quick thought that I had to get out in the meantime.
I hear a lot of people talking about PCI, discussing whether or not it actually does anything for security, whether it was a move on the part of the card issuers to improve security or simply shift liability, about the strengths and weaknesses of the protections it provides. Almost invariably, these conversations completely miss the far larger issue in credit card security. PCI is nothing but a distraction, a shiny thing to wave in the faces of infosec’ers, execs, and politicians alike, trying to distract them from the bigger issue.
The bigger issue is this – credit cards are broken. The very concept of a “credit card” as it exists today is as fundamentally broken as anything in Infosec has ever been.
Let’s think like infosec professionals for a second here instead of like consumers. Your credit card is a token, one that is used to:
- Prove your identity to the merchant
- Confirm your intent to process a transaction
- Identify your source of funding
We have many protocols that can do all of this and more with a high level of security, it’s trivial to name half a dozen. None of them require you to give your full plaintext credentials to a third-party – although that’s exactly what happens every time you use your credit card. You have to give every merchant a complete list of every bit of information that is required to process transactions against your account – or else they can’t process the transaction. Those credentials remain static for several years, by design being given to several thousand anonymous strangers (known only by their participation in the system) over their lifetime. Multi-year credentials for financial authorization that are, by design, shared with any participant in the system. Does this sound broken yet?
Seriously, why are we still using credit card numbers? Why don’t we have smartcards containing a megabyte of pre-programmed single-use card numbers (that’s a LOT of card numbers!) that we pull up once and throw away? Or some kind of signature algorithm, put a public key on the card and sign the transaction electronically? Or secure tunnels between the card and the processor backend (hell, even between the terminal and the backend)?
Why is it so trivial to spoof our most commonplace payments system when there are such obvious examples of ways to fix it? Why, in short, do we still have credit card fraud?
PCI, no matter what its strengths and weaknesses are, is a band-aid on a festering gangrenous wound. It’s a shiny pink band-aid with a little bit of sparkle to distract us all, but it’s nothing compared to the fundamental brokenness of our credit card infrastructure. We need to stop blaming merchants and consumers for failing to protect a set of data with a process that is inevitably doomed to failure, and instead start blaming the credit card companies for failing to produce a payment vector that is compatible with the security requirements of the 21st century.
We stopped using plaintext protocols for sensitive information decades ago, for good reason. Think about that the next time you swipe your credit card.
More on Droid host mode
I’ve had a few days hacking on the Droid now (with some fun results that I’ll write up in a separate post in a moment), but I wanted to get back to a few things on Host mode USB first.
Firstly, adapters: these should work (3 links) to convert the Droid’s b-only socket to the correct A socket. Be careful of devices like this which will probably not work since the Droid has a Micro-B connector and that cable requires a Micro-A socket.
Next up, I’ve had a few folks ask for a review of the Droid comparing it to my G1. I’ll keep it quick – the screen and touch-response are far better, as is the keyboard, audio jack, speakers, CPU, and standard SD card (16Gb). It bugs me that there’s no pipe character on the keyboard (it is, after all, a *nix box), I don’t like the joypad mouse replacement and it bothers me that I have no cables or chargers for Micro-USB which is now the standard – all those Mini-USB dongles you’ve accumulated will soon be worthless. Whatever I think of it though I’ll forgive its flaws just purely because it supports USB host mode, even if the drivers are buggy as hell 
Speaking of bugs, some workarounds and other notes:
- A powered USB hub is very handy if you’re playing with host mode. You can add and remove devices from the hub and as long as the hub stays plugged into the socket it all continues to work. Self-powered is good because the Droid can’t supply much power, although optionally-powered will also work because the Droid can supply small peripherals such as keyboards, mice, and small hubs.
- I was talking this all over with Mike Baker and it seems that the only reason you can’t switch the port back and forth between host mode and peripheral mode is because the gadget driver locks it – this is the driver that provides such things as ADB. If you prevent that driver from loading you should be able to switch back and forth by poking the right value in /proc/. Haven’t confirmed this yet but it sounds plausible.
- There’s an odd signal coming out of the power line on the Droid’s USB port if you shut the device down in host mode. The +5v drops to about +3.3v with about 0.5v of signal modulated on top. It’s definitely a signal (it responds to button input) and this is after the device has been powered down. Mike was going to investigate further and I’m planning to write a PIC decoder for it as well, so we’ll see where it goes – ideas for the signal source would be useful (I’ll post traces soon).
- If your USB peripherals just stop working at any point check for crash logs in dmesg. The driver does crash regularly, it doesn’t cause a kernel panic but does require a reboot to get the port working again.
The big fun (at least in my eyes) is the fact that I now have a working GSM base station running on my Droid. Watch this space for a howto coming up soon…:)
USB Host mode on Motorola Droid
Yes, it’s true – Android (at long last!) has access to USB Host mode. I had been waiting for this to happen on the Nexus 1 or N900 some time soon, but as it turns out it’s the Droid that takes the crown. It’s a neat little hack that I heard about at Shmoocon; I’d like to thank to Mike Kershaw from Kismet and Mike Baker from OpenWRT for sharing Here’s how it works.
The USB hardware on the Droid is actually capable of USB-OTG (meaning that it can act as both host and peripheral), however it only possesses a standard USB Micro-B port instead of the Micro-AB port that you would normally get from an OTG device (such as the N810). With a minimal amount of effort (and tolerance of a few bugs) it’s possible to enable the B port as a host interface (as OTG says you should be able to do), meaning it supplies power and acts as the bus controller. It’s actually pretty easy; I can easily think of about a hundred million ways to make this useful on the Droid (think: plug any USB hardware you like into your Droid, as long as it works in Linux it should work in Android).
You’ll need to make two things, a micro-dongle to enable the port (you plug it in during boot time) and a cable with the right connectors on each end (for connecting your peripheral). To do this you’ll need three cables:
- A car charging cable (off-the-shelf at the Verizon store)
- A Micro-USB cable (as above)
- A USB extender cable (the teeny ones that sometimes come free with USB keys work great)
Start with the car charging cable. Break open the micro-usb connector (it comes apart fairly easily) and look at the little PCB inside – there should be a single tiny surface-mount resistor and two wires from the charger cable. Unsolder both wires and the resistor, and then bridge the pads where the resistor used to be so that it’s completely shorted. The end result should look something like this:
This is your micro-dongle.
Next up, you need to make your connector cable. Cut the end off the USB extender cable, you want to keep the socket end and discard the plug. Cut the micro-usb cable as well, but on this one you want to keep the plug and discard the socket. You should now have a micro-usb plug that’ll fit into your droid and a usb socket that you could plug a memory stick into. Strip the wires off the ends of both cables and join them to each other, connecting like colours (and the shield) together. When it’s finished it should look something like this:
(You’ll obviously want to insulate the wires afterwards, this is just to show how the colours are connected).
You don’t even need to root your droid in order to verify it works (although I rooted mine using the instructions here anyway), just do the following:
- Turn your Droid off
- Plug the micro-dongle into the USB port
- Turn the droid on
- Unplug the micro-dongle as soon as the Motorola logo disappears (as the Droid lodo is appearing).
Once your Droid is booted, pull up a terminal and look at dmesg – after plugging in your USB peripheral using the cable you made earlier you should see the usual kernel notifications about new USB devices being connected; they’ll also turn on (or start charging) if they’re powered by USB. You’ll only be able to plug in one peripheral before the port reverts to peripheral mode; you’ll have to reboot with the micro-dongle if you want to go back into host mode. Also, if you leave the micro-dongle plugged in too long it triggers another bug, the port gets stuck supplying power to devices but not actually recognising them. Hopefully the drivers are sufficiently open-source that these are easy bugs to squash, and that dynamically switching between host mode and peripheral mode won’t be too hard to add either.
Unsurprisingly there’s not much driver support for USB peripherals in the standard Android kernel (I couldn’t mount a USB key for example), but it’s easy enough for the ROM developers to start adding drivers – I’ll be flashing Sholes shortly to see how it does. Expect to see a whole new generation of Android hackery to start soon
//edit: Andrew de Quincey has apparently also gotten Host mode working on the Hero, and pointed out that while the stock Android kernel may not support USB storage it does support USB keyboards. Plugging one into my Droid using the steps above, it Just Works. It’s kinda nice to have a proper keyboard on a cellphone…:)