If you’re an Evil Customs Agent or other nefarious Three Letter Agency Person, you’re probably very interesting in getting data off people’s phones. Even if the screen is locked, there’s a way around this problem: just use the Android Debug Bridge (ADB), a handy way to get a shell on any Android device with just a USB cable. The ADB can be turned off, though, so what is the Stasi to do if they can’t access your phone over ADB? [Michael Ossmann] and [Kyle Osborn] have the answer that involves a little-known property of USB devices.
USB mini and micro plugs have five pins – power, ground, D+, D-, and an oft-overlooked ID pin. With a particular resistance between this ID pin and ground, the USB multiplexor inside your phone can allow anyone with the proper hardware to access the state of the charger, get an audio signal, mess around with the MP3s on your device, or even get a shell.
To test their theory, [Michael] and [Kyle] rigged up a simple USB plug to UART adapter (seen above) that included a specific value of resistor to enable a shell on their test phone. Amazingly, it worked and the thought of having a secure phone was never had again.
The guys went farther with some proprietary Samsung hardware that could, if they had the service manual, unlock any samsung phone made in the last 15 years. They’re working on building a device that will automagically get a shell on any phone and have built some rather interesting hardware. If you’re interested in helping them out with their project, they have a project site up with all the information to get up to speed on this very ingenious hack.
The article title is definitely misleading, and it seems as if Brian didnt read the paper at all. This isnt applicable to ANY android device, only those which use multiplexers ICs on the USB port, and only if they are designed to explicitly allow this. The hack here tested only the Nexus and was able to get to a debugger which had access to an unprivileged shell. I havent played with android much, but if you rooted your device couldnt you just ‘chmod -x adb’ to fix this issue?
Also this isnt applicable to just any Nexus either, from the paper:
“The Galaxy Nexus was running CyanogenMod [10]. Subsequent tests of
devices of the same model running different operating systems yielded
different results. We were unable to gain access to the FIQ debugger on
a unit with an operating system provided by Verizon. On a unit with an
operating system provided by Sprint, we were able to access the FIQ
debugger, but the console command was missing or disabled.”
So basically if you rooted your device, and installed a poorly configured community ROM you have a security issue, if you use the default install your ok. God damn this post was alarmist.
I agree that the article would be much improved by the deletion of the letter “y” from “any” in the title.
Don’t trust chmod to save you from this type of vulnerability. There are many ways that an attacker may be able to elevate privilege given something as complex as a shell.
What I hope people get out of this work is not: “Hey, these guys can get a shell on some phones!” but is instead: “Wow, there are huge, unexplored attack surfaces accessible through multiplexed wired interfaces on all sorts of devices.”
Give the Cyanogenmod guys 20 minutes to fix this hole.
gice CM 20 min to fix it? please – they cant fix it until someone else does, and posts the patch…
No, this *exact* hack may not be available to every Android device, but this kind of hack is. I can say that every smartphone around have a multiplexer chip installed, or they would not be that smart.
So even if the used resistance may not work on Motorola phones, another one surely will. If they have access to the support manual for all makers (and there’s just a few), they will be able to attack every and all Android phones out there.
And I bet NSA have that manuals, don’t you think?
This is the dumbest post i’ve read on here a while. The multiplexer chips aren’t what make phones smart and if you read the paper on the author’s site or my 2nd post you would have seen that this only worked with a poorly configured 3rd party OS.
I’m surprised this hack uses a resistor. I’m sure most devices require some active handshaking on that extra pin.
chmod -x will not necessarily fix the problem. Most roms have the adbd
(android debug bridge daemon) loaded in ram after boot. It is tied to init.
So, even if you chmod -x adbd, rebooting the device will bring it back to
it’s normal state.
time to dremmel off that pin thx Had for the heads up.
If you do that, then say goodbye to USB OTG and other stuff.
Easier solution: just flash a custom kernel with the FIQ debugger disabled.
Easier solution: lose the cellphone.
Easier easier solution dont travel.
Somehow I don’t see you traveling outside of your mother’s basement given how voraciously you leave shit replies on Hack-A-Day articles.
That’s why I have a dumb-phone…
That won’t help. Most of them have a service interface in the proprietory sockets that you charged with. The ones that didn’t would have the same interface inside as some pads by the SIM socket. The interfaces are used to reflash the phones or do diagnostics so you have complete access to everything.
yes, but ‘everything’ on a dumbphone doesnt look anything like ‘everything’ on most smartphones.
“everything” on a dumbphone is like the phone number of the phone :)
The only thing on my “dumb” phone is phone numbers….. what exactly are they going to hack into?
The number of your parts supplier in China?
This is very well known since years. There are even resistor tables available. Google for USB-JIG for instance.
Lets see…
1. Maintain physical security of the device
2. Don’t trust unknown media/cords
It’s an interesting attack vector, but the mitigation strategies are at least a decade old.
Try that when you’re going through customs, though.
You can do this with a Parallax Propeller, but ADB must be on.
http://obex.parallax.com/object/116
ok then to secure the device just short the id pin to ground so nothing will work
Poorly written article that is hard to follow and totally misleading. Typos and words being mixed up making it unclear if you do or don’t need adb enabled. Boo for this poorly written piece of shite.
Just because you dont understand what is being done doesnt mean it is poorly written. It dumb it down for you, abd is disabled on the phone you gain a shell to the phone through the usb port once you have shell access it is just a matter of changing a single value in the phones database in order to enable adb, once adb has been enabled you then use thay access to push programs down to the phone…
It’s adb, not abd. But it’s okay, commenters don’t have to get it right every time. I expect more from the authors of HaD though.
I understand how it works by reading the original article. I can’t understand the author because his writing is full of typos, missing words etc. Perhaps you’d be better off reading the original article to understand how misleading Brians writeup is.
Granted i didnt read the article but i did watch the talk. The talk was very easy to follow imo and after watching the talk and reading the write up it isnt actually that missleading. Maybe brian just watched the talk and didnt read the article :/