6 ms·

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 ov

• _stephan 13y ago
  Why would the baseband processor need access to anything but the RF and maybe the GPS hardware?
  • sliverstorm 13y ago
    It wouldn't. Though you could build it that way, I guess, if you felt so compelled. http://en.wikipedia.org/wiki/Baseband_processor http://en.wikipedia.org/wiki/Baseband_processor
  • rst 13y ago
    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.
  • Zigurd 13y ago
    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.
    • voltagex_ 13y ago
      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.
      • Zigurd 13y ago
        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 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.
        • reubenmorais 13y ago
          Similarly, the open source implementation of the Firefox OS RIL daemon can be read here: https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js https://mxr.mozilla.org/mozilla-central/source/dom/system/go... (Sadly, it's not used in all production devices.)
          • Zigurd 13y ago
            That's a lot of code! I wonder if it has more feature coverage than the Android device-independent RIL layer.
        • tmzt 13y ago
          Have you documented the RPCs to the modem as well?
    • ben1040 13y ago
      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.
• sillysaurus2 13y ago
  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 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 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 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 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.
  • imissmyjuno 13y ago
    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..
    • 13y ago
• sounds 13y ago
  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/application/applicationOverview.do?topMenu=A&subMenu=smartPhones&appNo=smartPhones&appLabel=Smart%20Phones https://memorylink.samsung.com/ecomobile/mem/ecomobile/appli... Qualcomm (page 4) - https://developer.qualcomm.com/download/qusnapdragons4whitepaperfnlrev6.pdf https://developer.qualcomm.com/download/qusnapdragons4whitep...
  • jwise0 13y ago
    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.
    • sounds 13y ago
      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.
• rsync 13y ago
  "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.
  • hershel 13y ago
    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.
• _Adam 13y ago
  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).
  • tmzt 13y ago
    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.