Hacker News new | ask | show | jobs
by InTheSwiss 4602 days ago
I am assuming that the RTOS has direct and full unrestricted access to the hardware such as the camera and microphone? If so then I would also assume that an over the air attack to silently suck data from the camera and microphone would be pretty easy for those with access to the RTOS (such as governments)?

I know there has been software to do just this in the past on some Nokia devices but I would assume (I am doing that a lot in this post!) it is just as possible in pretty much every mobile phone?

Anyone with knowledge of this care to comment on my assumptions?

5 comments

I would also assume that an over the air attack to silently suck data from the camera and microphone would be pretty easy for those with access to the RTOS (such as governments)?

This is correct. The rule of thumb is this: If you need to avoid being tracked, do not under any circumstances carry a cell phone unless you have removed the battery. Even if it's powered off, it can still be activated to remotely track you as long as the battery is in it. This tactic was used in catching the recent serial killer Luka. http://en.wikipedia.org/wiki/Luka_Magnotta

From the article: "His cell phone signal was traced to a hotel in Bagnolet, but he had left by the time police arrived.[55]"

You can bet that, since he was on the run, his cell phone was off.

There are other examples besides Luka. Circumstantial evidence is very strong that law enforcement can track you if you've powered off your phone but haven't removed the battery.

(I feel so strange posting this comment, since those who would benefit from this advice are probably of dubious character.)

EDIT: I edited my comment before Guvante's reply. But it looks like some people aren't really convinced. So here's another comment, from tlb 113 days ago: https://news.ycombinator.com/item?id=6087399

"There is reason to believe phones have been remotely hacked by law enforcement using carrier credentials to leave the cellular radio running and registering with the cell network even after the off button has been pushed and the phone appears to be off. Starting point for further reading: http://www.brighthub.com/electronics/gps/articles/51103.aspx "

tlb = Trevor Blackwell, one of the best electronics hackers in the world. You may know him as the creator of the first robot that walks like a human. http://paulgraham.com/anybots.html

Now I've presented circumstantial evidence and an appeal to authority, so of course feel free to doubt me. But don't be surprised to discover you've been tracked when carrying a powered-off cellphone with a battery in it.

> You can bet that, since he was on the run, his cell phone was off.

You then follow this with

> But if he was on the run, why was he carrying a cell phone? Answer: because he was stupid.

Your postulation that this is sufficient proof to say that they can track you with your phone off is suspect.

I was skeptical the last time this subject came up, too, but someone pointed out that for an attacker with root access, it would be easy enough to reprogram the phone's power button to act like it was turning the phone off without actually doing so.

Given the fact that US law enforcement and security agencies are (now) indisputably known to be in the zero-day hacking business, the burden of proof is on those of us who've always claimed these stories were exaggerated.

Personally, I no longer feel confident about calling bullshit on much of anything. With the US government's infinite budget and unaccountable influence over device manufacturers and telcos, no hack is impossible.

That's a different thing.

Can a phone be tracked while off - or can you install malware that prevents your phone from turning off while misleading the user to believe that it worked?

The latter is a lot easier to believe and what you talk about. The discussion above/the post you answered is about the former.

Sorry but can't avoid laughing at infinite budget etc etc after a masterpiece such as https://www.healthcare.gov/

If all the operations are carried on by the same kind of contractors, we can sleep tight for few years.

A friend of mine has always said that if you want a big f-up in projects then get the government to run it. But if you want something carried out with precision then get the military to do it.

Funny thing is, it doesn't seem to matter where healthcare systems are carried out they always run over time and over budget and end up in a big mess!

http://www.bbc.co.uk/news/uk-politics-24130684

That's the irritating thing -- that so much money is being spent for such poor results. The NSA isn't very cost-effective at preventing terrorist attacks, and healthcare.gov isn't very cost-effective at providing health insurance.

When confronted with my government's incompetence, I never know whether to be pissed off or relieved.

NSAs job isn't just to prevent terrorist attacks, it's also to gather and analyse information for the US government and to keep US communications secure. I don't know whether or not they're "cost effective", but I don't think anyone would doubt that they've given the US a huge strategic advantage.
I see your point, but this sort of work would be coming more from the makers of stuxnet than the makers of health insurance websites...
Or a full-on cynic/paranoiac would suggest the poorly-done websites are part of a gaslighting scheme.
'gaslighting' - we don't use that term often in the UK, looks like a good word though... Please can you explain what that word means in this context. Thanks!
The baseband can control everything, and the baseband itself can be controlled remotely. It is at least technically feasible. There's no real room for doubt on that.
>the baseband can control everything Why would that be the case? Baseband in this case refers to a frequency, eg taking data(audio, SMS, etc) and mod/demodulating it. It should take raw data at the bottom of the OSI model and prep it for the RF front end, and vice versa. I may absolutely be wrong, but it doesn't have any connection to the microphone other than receiving preprocessed digital audio from the application processor. Look at the interface for an e.g TI cc2500, that's the sort of device that's being discussed
"Baseband" in this case refers to a dedicated CPU and software that handles all of the high-level cellular radio protocol work. It's where the logic would be implemented to handle the data coming from a chip like the cc2500.
"I feel so strange posting this comment, since those who would benefit from this advice are probably of dubious character"

I don't think there's too much social harm done in pointing this out. It seems to be so well known that it's referenced (visually or even verbally) in movies and TV shows like Breaking Bad, where the criminals take the batteries out of their phones as an extra precaution against being tracked.

How does airplane mode fit in with this? Wasn't it until recently that FAA regulations required cellphones have an explicit means to halt ALL radio communication? If the phone's radio is still potentially active even when the device is "off", how could these baseband OS's get government certification?
There is no confirmation whether baseband processor can be reached while device is OFF/in Airplane mod.

And I join the crowd who think that is impossible. I bet someone would notice weird patterns if the baseband kept working despite of device off. (Speakers catching 2G, battery drain, interference with other devices, etc.)

The radio interface could listen/wait without even replying, ie wouldn't make the GSM RFI speaker noise. If governments, carriers and law enforcement could all manage to use this so incredibly rarely that it's never been observed.. then it could be real.

Given the types of people that would have to have access / knowledge of this though. For example people that suspect their partner of infidelity and is on the police liaison team of a carrier say...

I agree it's very unlikely, someone would have noticed it by now.

Oh, that is a fair point.

Though, not receiving any information back, draws the tracking practice significantly more difficult.

It need only reply if it is requested to do so, therefore for 99.9 recurring percent of the time there need be nothing observable.
"Airplane mode" is essentially and AT command sent to the baseband to disassociate and go to sleep, it doesn't disable the baseband CPU, DSP or anything else.

You could argue that "off" is the same thing, for instance, many Qualcomm devices boot with the BP first and and can do a lot before the AP is even taken out of halt, without initializing the LCD display, backlight, etc.

Theoretically, that wouldn't be hard:

* Push the airplane mode button.

* Have the FAA place the phone in a faraday cage for testing the phone.

* Don't remotely activate the phone at this point (which you wouldn't be able to anyway, the phone is in a faraday cage )

* "Forget" to tell the FAA about the cellular equivalent of "wake on lan" we built into this phone.

The addition of a mechanical power switch would probably make a successful product nowadays. Shouldn't be too hard to implement on individual phones if you have nimble fingers (not sure though, it's been ~decade since I last dissected one).
it is also an important piece of advice that could save someone's life for instance. there's nothing dubious about demanding privacy. now I just wish my nexus 4 had a removable battery..
This makes non-removable batteries creepy in addition to annoying!
Does removing the SIM prevent the common ways of tracing, or do they simply go off your IMEI?
Not a direct answer, but: by law, any cell phone can still place calls to 911 with the SIM removed. We can probably extrapolate from there.
Right, I was just wondering about the tracking methods used. Do they select by your handset identifier, or an identifier in the SIM?

Would removing the SIM be at all helpful for avoiding tracking if you couldn't ditch a phone with an integrated battery?

No, but you could clone or change your IMEI. Of course, doing so without care might also arouse suspicion, or otherwise betray your ID.
I see no reason for them being unable to do both: SIM identity and handset identity.
No, it won't help to remove the SIM card. Unless you've removed the battery from your phone, then you can be tracked. And there's no such thing as "can't ditch my phone."
The SIM isn't necessary to connect to a tower, meaning your GPS position will be reported unless you remove the battery.
If you remove the SIM you are usually still able to make emergency calls (911, 999, 112), which means it can still connect to cell towers.
Not necessarily your GPS, using it consumes more power ( ~ 30 - 100mA @3.3V ) than detecting your location passively using the cell-towers. It also takes longer to get a precise fix unless the phone is out in the open.
Instead of removing the battery, you could wrap the phone in foil.
Then, when you get stopped by the cops you have to explain why your phone is wrapped in foil. For which there can only be one possible reason. You might as well also carry a set of lock picks, crowbar and an acetylene torch, perhaps with a set of scales so that you can be processed that bit easier...
You can also create a Conspiracy theorist persona. Keep asking questions online with a semi anonymous account about the government excess, about the moon, the aliens, the freemasons etc.

Then if in court you can try to argue that for a tin foil hat like you, the actual tin foil cell phone protection isn't an indication of anything. And much less suspicious.

:-).

I like your thinking.

Not sure how it could be fully applied if in the police interrogation room having been apprehended in a dark alleyway with two large bin bags full of steaming skunk weed, freshly purchased off a Vietnamese gentleman insistent on counting every note of that £20000 just handed to him. Maybe that is just an edge case though.

Perhaps a better idea (and market opportunity) could be a 'walkers rucksack' that has a pocket for your cellphone. This pocket could be lined specifically to act as a Faraday Cage, explicitly so that you can have easy access to your phone for maps etc., yet be fairly certain that your day strolling in the hills will not be interrupted by the office, the wife and other cold callers. Such a bag could be plausibly denied in a way that plain old tin foil could not be.

Don't feel bad about yourself. I had a history teacher on college who was a very important political criticize of Hugo Chavez government. Each time she was going to talk about politics, she took the battery of her cell phone.
Good thing I never remove the battery when flying on an airplane.
No, not really. The actual answer is more complex.

Camera:

The high data rate required for imaging module means that it doesn't run on a shared bus. There's a number of standards, some proprietary and others loosely defined, but they all use direct connections to the image processor (which is in many cases part of the SoC).

Microphone:

Probably not going to access this one, because microphone wouldn't be on any sort of bus. They'll have a direct connection to a ADC, which would have a direct connection to an audio signal processor in the SoC.

Other sensors:

This depends on the implementation. If they use I2C, there's a good chance they'll be on a shared bus on which the baseband processor is also located. However, accessing that data requires details about the specific sensor. If a particular model of phone is being targeted, this isn't too hard. For example, I know the iPhone 4 uses the LIS331DLH Accelerometer. I can find the datasheet for that part, and then write a simple driver to access it's data. If they use SPI, which isn't a bus-based protocol, there's little chance of accessing the information directly. SPI devices can be daisy chained or separately selected to put more than one on a single port, but in such a configuration there's only ever one master (which would be the CPU).

There's also the possibility of reprogramming a PINMUX to move access from the AP to the BP on the same SoC for something like SPI.

Essentially, most of the pins on the SoC are re-programmable to have different functions or connect to different logical blocks within the SoC.

Along these lines there's also bit-banging SPI or I2C, which should work fine for infrequent updates from an accel or compass (and now things like pedometers being added to devices.)

As for microphone, if it's being read by the audio DSP, it's certainly accessible from the baseband, at least on Qualcomm . If nothing else you can load a DSP module that allows access to the raw PCM (or vocoder) data.

Same is probably true for the camera, which is usually on an HSIF or similar bus connected to the DSP.

TL;DR yes, the BB cpu has full access to everything, including the "main" cpu and all running processes. Why not, right? :)

It is important to note that all smartphone chips are optimized first for low cost and low power usage.

To actually isolate the baseband processor+GPS+Cell radio+Mic+Speaker would require a second high-speed bus.

Most cell phone processor designs put both the baseband and application processor in the same package both for cost and power saving reasons. Since both processors are typically ARM cores they will easily interface to the same bus for memory and peripherals. Only having one external bus means fewer external components, which is typically the strongest factor relative to the total power and cost.

There is also the legacy element. The article notes that most of the BB code is at least a decade old by now. Unless that code got a major rewrite, it would not run on a new, isolated architecture.

Specific processor block diagrams:

Samsung - https://memorylink.samsung.com/ecomobile/mem/ecomobile/appli...

Qualcomm (page 4) - https://developer.qualcomm.com/download/qusnapdragons4whitep...

That's not always the case. For instance, on Galaxy Nexus (CDMA), the radio is split from the AP, and are in fact manufactured by two completely different folks (the AP is TI OMAP, and the radio is VIA Telecom). I'd imagine the same thing with Mediatek, who is a large and growing player. You are right that Qualcomm does fuse their radio with their AP, though, and they do control quite a lot of the US market.
Well, good, if the radio and baseband do not live on-die with the AP. Market forces are pushing for a completely integrated design, but it's interesting from a security perspective.

The baseband is still considered the master CPU during boot - at least on the CDMA Nexus. So although there are some corner cases in terms of architecture, the security model is still completely broken. Send a payload to the baseband over the air, compromise it, and the entire phone is yours.

Qualcomm mostly has the modem on the same chip as the apps processor, but not always: the recently-popular APQ8064[0] (used in the Nexus 4) had a separate modem.

[0]http://en.wikipedia.org/wiki/Snapdragon_%28system_on_chip%29

"I am assuming that the RTOS has direct and full unrestricted access to the hardware such as the camera and microphone?"

You're thinking small ... the baseband processor (typically) has DMA access to the processor itself. Never mind pedestrian stuff like peripherals...

Further, since carriers interface with the baseband processor for OTA updates, that means your carrier has (essentially) DMA access to your phones cpu. I wish people appreciated just how deeply (as deep as deep gets, basically) your carrier can control the device in your hand - even if you have "rooted" it.

Does it also have access to internal debug registers in the cpu? Because some techniques(TREZOR) encrypt memory and store the key in those registers, as an antu-malware technique.
Why would the baseband processor need access to anything but the RF and maybe the GPS hardware?
For one thing, putting the voice signal processing in the baseband means that it's not vulnerable to timing glitches from "noisy neighbor" apps running on the application processor. For another, as a practical matter, a lot of the baseband software started out as the entire software stack for the single processor in a dumb-phone/feature-phone, which necessarily included the voice processing. Simply leaving it there avoids the technical effort of doing a port.
Quite often the baseband has the only direct access to the handset mic and speaker, including things like the agc and speakerphone. That's why a room bug can be implemented this way.

The article hints at a way to democratize access to this capability by using the RIL commands to turn on auto-answer and turn off any indication it's happening.

Yep. I had no idea this was the case until I read an article that came out shortly after the original iPhone. The dialer app in iOS during those first few months was pretty buggy and had an occasional tendency to crash or lock up while on calls, especially when pressing the "hang up" button. Every time it locked up on me, it'd never impact a call in progress though (much to my annoyance when trying to hang up).

It made perfect sense once I read that the speaker and mic were wired straight to the baseband, and the state of the dialer application had zilch to do with what was going on in the baseband.

RIL commands being extended AT commands? There is a community of phone unlockers who know everything about these for Qualcomm chipsets but their tools have the best DRM I've ever seen.
Way back when a wrote a couple chapters for Android Application Development I wrote about Android's RIL daemon and the underlying device-specific RIL libraries. It's gotten a lot more complicated, but the source code is open and includes what appears to be a reference implementation: https://github.com/android/platform_hardware_ril

I have not looked at this part of Android source code in depth in a while, but from a quick look it still looks very edifying about how this part of a smartphone works.

Similarly, the open source implementation of the Firefox OS RIL daemon can be read here: https://mxr.mozilla.org/mozilla-central/source/dom/system/go...

(Sadly, it's not used in all production devices.)

That's a lot of code! I wonder if it has more feature coverage than the Android device-independent RIL layer.
Have you documented the RPCs to the modem as well?
It wouldn't. Though you could build it that way, I guess, if you felt so compelled.

http://en.wikipedia.org/wiki/Baseband_processor