There was a great Defcon talk about this called The Secret Life of SIM Cards that I can recommend watching (they release the video for these some time after the conference).
The talk itself was about a group that had an enormous camping trip (I hope that phrasing doesn't diminunise it) called Toorcamp of a few thousand people that thought it would be fun to also put together their own cell network for just them. They bought and programmed SIM cards and hid puzzles in the programs on them.
But the amount of programming that can be done on the SIM card alone without involving the main processor at all was really quite fascinating and there's a lot of detail in the talk if you can track it down. Here are the slides at least https://speakerdeck.com/codebutler/the-secret-life-of-sim-ca...
I did some JavaCard development on a project probably ten years ago - and the highlight was meeting the "Head of SIM" at a major network, being told how many times a day everyone's SIM card 'crashes'.
I wrote my Master's thesis on software platforms for smartcard applications in 1999. An interesting platform running javacard apart from SIMs is/was the Java iButton from Maxim (then Dallas Semiconductor).
Also, all ATM cards which are smartcards (i.e. almost all of them in countries such as France, Norway) can also hold several applications. The banks just doesn't allow it. In theory you could, even with today's technology, buy a blank card (say, with a David Bowie picture if that's your thing) and have the bank, visa, mastercard, grocery loyalty programme, library card, frequent flyer applications etc on it. Just carry one card! But no, everyone wants to own the card have their logo in it. Sigh.
AFAICT, the neo900 has a plain old closed baseband processor.
So you can "root" it and control the OS all you want, your carrier still owns you and your phone, what with (potentially) DMA level access to your CPU.
neo900 is interesting, but it is not any more open in this regard than any other handset.
One of the side effects of software eating the world is that the world becomes more exploitable. I expect that over time we may see the emergence of general 'software building codes' much like there are physical building codes, and more importantly liability associated with failing to provably meet such codes.
The current 'random person implements firmware that controls the this chip' practice and the 'no warranty etc etc' disclaimers will, I predict, be replaced by manufacturers who are willing to warrant their code.
I am getting tired of seeing physical building codes thrown around in comparison to software. I've looked at residential building codes, because I've done my own work like building a deck, framing and finishing my basement, and researching how to build concrete & steel suspended floors, or wood floors - seeing what their spans are - seeing how lightweight steel framing vs wood framing works - it's quite fascinating. (I was considering designing my own house, but the wife shot that down)
And there is simply NO COMPARISON in complexity to software. In physical building, you over engineer and get redundancy. You also know that almost everyone builds plumb and level, rectangular rooms, with easy span and shear calculations. You also know that wood follows a predictable strength pattern. So you put in enough nails of the right length, to enough wood of the right thickness, and you're good. How much intelligence do you think you need to follow a building code? Building materials and techniques change GLACIALLY compared to software. (A good thing!)
Whereas in software, one single bit flip will just fuck you up.
The complexity of software doesn't preclude standardized "building codes." Obviously the codes would have to be just as complex, but software could be used to check that those codes are met. It wouldn't be perfect, but current building codes for physical buildings also have their flaws (every building [vs design] needs to be physically inspected by a person [much easier to exploit than a machine]).
These already exist, for example it is very difficult to build biomedical software that gets hooked up into a living thing - even if you use it only for research. In practice such a hard realtime guarantee can only be met by a devices like an FPGA. All of this is in a code.
Real issue here is why such codes don't exist for for this particular problem.
In practice such a hard realtime guarantee can only be met by a devices like an FPGA.
There have always been fully deterministic CPUs around for that purpose. The simpler the system, the better; just hook a Forth chip to a memory without caches and you're set.
You probably don't want a system where all the hardware and software for controlling mobile radios is readily accessible to and modifiable by anyone. You might think you do, but the first time you try to call an emergency service and you can't get through because one idiot somewhere in range of the same base station has screwed up his debugging code and jammed a control channel, you'll change your mind.
I've been the guy who drives around in a truck with a lot of mobile scanning equipment to try and figure out where the rogue device is. There is no magic button like in the movies, where they can immediately triangulate the source of the interference to within a 5 cubic metre box. You basically have to rely on simple physics and boots on the ground. The device you're hunting for isn't playing nicely, so any assumptions you could normally make based on things like which base stations it's in contact with won't necessarily be valid. Things are a bit smarter in modern networks than they were back when I worked in the field, but physics is still physics.
In short, there is a legitimate justification, born of experience, for every telecommunications regulatory authority in the known universe requiring this stuff to be certified before you can legally use it. This is also why in some jurisdictions agents acting for telecommunications regulators have certain legal rights to access private property.
Of course this only affects the radio equipment. I see no reason it should be necessary or possible for such software to have any control over other integrated peripherals such as cameras, speakers, microphones or local storage. And the primary concern is people who could modify the code and break the network, not preventing any legitimate audit to prove that devices are only doing what they say they're doing.
A country could enforce openess of the source code for imported software and firmware.
- If Toyota (or any car manufacturer) wants to import cars into my country, then they better show us the sources of their firmware and software (and let us re-compile it and re-install it, to make sure it corresponds to the embedded code). And let the papers compare the code quality of Toyota vs. BMW.
- If Microsoft (or any software vendor) wants to import software into my country, then they better show us the sources of their systems and applications (and let us re-compile it and re-install it, to make sure it corresponds to the binary code, and doesn't contain backdoors to the NSA (or the MSI, or the MI5 or whatever).
- and so on.
And actually, citizens can do the same at their level, not letting enter their house any device or software whose code is not open source or even libre software (so they can recompile it and reinstall it on their hardware).
But a country has more weight than a few citizen that would be qualified of lunatics, and has more resources to analyse and validate the software and firmware.
hardware manufacturers should be less concerned about what their firmware reveals about their IP and more concerned with what not revealing their firmware source code reveals about their security.
the fact that you can get DMA by compromising _any_ device on the bus is a problem too. imo, none of these peripherals should have unmitigated DMA.
Thats easy to just say, but how wil you financially protect the company developing the software / hardware, if their competitors can just copy the work. Or stated the other way round, how will you keep companies encentivised to develop new software / hardware?
I think it is a consequence of the fast improvements in functionality made. People would rather be on a feature rich beta branch, than a safe stable branch. I also expect this to change as the industry matures.
After some particularly huge disasters I've had to deal with coming onto new projects and with general consumer electronics, I'd go for the latter every time both as a consumer and company these days. Time is valuable and losing it to a feature packed unreliable mess is a big risk to that time.
Extending that metaphor, a profession could evolve around zoning for permissible uses of code based on types of software and intended audience, much like urban planners do with zoning codes and city master plans.
Possibly; there are already standards in certain areas. But it can greatly increase cost and time-to-market, so even when there are codes corners will be cut. See the Toyota lawsuit at the moment.
Oh, and applying pretty much any "software building codes" to the web app industry would probably kill startup culture entirely.
> applying pretty much any "software building codes" to the web app industry would probably kill startup culture entirely.
Not necessarily. To use the analogy with the building industry, there are different requirements depending on what the building will be used for. Startups holding or processing financial information might have one set of regulations, whereas those hosting cat pictures might be less rigorous.
This is very unlikely because such embedded software operates on extremely low level and it's completely dependent on a particular hardware design (not just the chip, but the whole architecture). It's extremely hard to make that portable enough to make it sellable, especially with the speed of technology advances today.
... The voice came from an oblong metal plaque like a dulled mirror ... The instrument (the telescreen, it was called) could be dimmed, but there was no way of shutting it off completely. (1.1.3)
Oceanians live in a constant state of being monitored by the Party, through the use of advanced, invasive technology.
It was terribly dangerous to let your thoughts wander when you were in any public place or within range of a telescreen. The smallest thing could give you away. A nervous tic, an unconscious look of anxiety, a habit of muttering to yourself – anything that carried with it the suggestion of abnormality, of having something to hide. In any case, to wear an improper expression on your face (to look incredulous when a victory was announced, for example) was itself a punishable offense. There was even a word for it in Newspeak: facecrime, it was called. (1.5.65)
Is the the google input box a door to the world or a window into your mind?
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?
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.
"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?
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..
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.
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.
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.
"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.
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.
Coming from a background of developing audio hardware drivers for the Blackberry (I worked on the last generation and current generation before getting bored and leaving a year ago), I can tell you that even if the baseband were able to turn on auto-answering, (I have no idea if that's possible, by the way) it wouldn't know how to configure the microphone and speakers to allow for recording or playback unless it convinced the application processor to help.
If you are concerned about your Blackberry spying on you, there's a special "security plug" that you can insert into the headphone jack which will short all of the pins to ground, disabling the microphone. I assume other phones support this as well.
Re: the security plug, I'll believe you that it might work for your line of devices, but in the schematics for the relatively few phones I've looked at there was always active selection on the phone pins.
Think about it: you put normal headphones in the jack (no microphones, only tip, ring, sleeve): it will already short the mic input
If I put normal headphones in my phone's 3.5 mm jack, it recognizes that they don't have a mic and doesn't mute the built-in mic. So there are definitely some devices where this won't work.
There's no way to access the audio ICs from I2C or SPI on the BP?
You might also need access to the PMIC to turn on the amplifiers, but most designs I've seen have access ports from both BP and AP. (This was on Motorola devices, Q and the EZX phones.)
I don't know where, but it sounds fairly simple to make: cut the connector off from an old headset, and solder all of the wires in it together. One of the wires (the uninsulated one) in there is ground, the other three are signal.
There is also a second OS hiding in your computer right now! (There might even be a third, or forth, depending on your hardware configuration and manufacturer.)
Proprietary BIOS software has suffered the same issues for the last twenty+ years.
Good thing all these embedded computers in my computer don't have antennas attached with buggy baseband that blindly decodes and trusts messages coming thereon. :-)
Right, it's not like wifi adapters have independent processors of their own with closed-source, potentially buggy firmware that does DMA into main processor memory. :-)
It's also worth thinking about netboot (which comes in several flavors), in which the main processor's potentially buggy BIOS may be independently decoding and processing packets coming over physical wires.
I don't think you realize how much noise computers radiate. If someone wanted to emit a signal instead of noise, it would be quite possible to do so. (People are doing DX work by connecting an IO pin of their Raspberry Pi to a long wire.)
Readit News
This is what Java Card was developed to run on.
If you are interested in getting lower level access to your radio, you could look at the defunct http://openmoko.com/freerunner.html project or the resurrection of the Freeruner, http://www.openphoenux.org/
The talk itself was about a group that had an enormous camping trip (I hope that phrasing doesn't diminunise it) called Toorcamp of a few thousand people that thought it would be fun to also put together their own cell network for just them. They bought and programmed SIM cards and hid puzzles in the programs on them.
But the amount of programming that can be done on the SIM card alone without involving the main processor at all was really quite fascinating and there's a lot of detail in the talk if you can track it down. Here are the slides at least https://speakerdeck.com/codebutler/the-secret-life-of-sim-ca...
Also, all ATM cards which are smartcards (i.e. almost all of them in countries such as France, Norway) can also hold several applications. The banks just doesn't allow it. In theory you could, even with today's technology, buy a blank card (say, with a David Bowie picture if that's your thing) and have the bank, visa, mastercard, grocery loyalty programme, library card, frequent flyer applications etc on it. Just carry one card! But no, everyone wants to own the card have their logo in it. Sigh.
http://neo900.org/
So you can "root" it and control the OS all you want, your carrier still owns you and your phone, what with (potentially) DMA level access to your CPU.
neo900 is interesting, but it is not any more open in this regard than any other handset.
The current 'random person implements firmware that controls the this chip' practice and the 'no warranty etc etc' disclaimers will, I predict, be replaced by manufacturers who are willing to warrant their code.
And there is simply NO COMPARISON in complexity to software. In physical building, you over engineer and get redundancy. You also know that almost everyone builds plumb and level, rectangular rooms, with easy span and shear calculations. You also know that wood follows a predictable strength pattern. So you put in enough nails of the right length, to enough wood of the right thickness, and you're good. How much intelligence do you think you need to follow a building code? Building materials and techniques change GLACIALLY compared to software. (A good thing!)
Whereas in software, one single bit flip will just fuck you up.
Real issue here is why such codes don't exist for for this particular problem.
There have always been fully deterministic CPUs around for that purpose. The simpler the system, the better; just hook a Forth chip to a memory without caches and you're set.
I've been the guy who drives around in a truck with a lot of mobile scanning equipment to try and figure out where the rogue device is. There is no magic button like in the movies, where they can immediately triangulate the source of the interference to within a 5 cubic metre box. You basically have to rely on simple physics and boots on the ground. The device you're hunting for isn't playing nicely, so any assumptions you could normally make based on things like which base stations it's in contact with won't necessarily be valid. Things are a bit smarter in modern networks than they were back when I worked in the field, but physics is still physics.
In short, there is a legitimate justification, born of experience, for every telecommunications regulatory authority in the known universe requiring this stuff to be certified before you can legally use it. This is also why in some jurisdictions agents acting for telecommunications regulators have certain legal rights to access private property.
Of course this only affects the radio equipment. I see no reason it should be necessary or possible for such software to have any control over other integrated peripherals such as cameras, speakers, microphones or local storage. And the primary concern is people who could modify the code and break the network, not preventing any legitimate audit to prove that devices are only doing what they say they're doing.
- If Toyota (or any car manufacturer) wants to import cars into my country, then they better show us the sources of their firmware and software (and let us re-compile it and re-install it, to make sure it corresponds to the embedded code). And let the papers compare the code quality of Toyota vs. BMW.
- If Microsoft (or any software vendor) wants to import software into my country, then they better show us the sources of their systems and applications (and let us re-compile it and re-install it, to make sure it corresponds to the binary code, and doesn't contain backdoors to the NSA (or the MSI, or the MI5 or whatever).
- and so on.
And actually, citizens can do the same at their level, not letting enter their house any device or software whose code is not open source or even libre software (so they can recompile it and reinstall it on their hardware).
But a country has more weight than a few citizen that would be qualified of lunatics, and has more resources to analyse and validate the software and firmware.
hardware manufacturers should be less concerned about what their firmware reveals about their IP and more concerned with what not revealing their firmware source code reveals about their security.
the fact that you can get DMA by compromising _any_ device on the bus is a problem too. imo, none of these peripherals should have unmitigated DMA.
Consumers want the latest.
Companies want the most stable.
After some particularly huge disasters I've had to deal with coming onto new projects and with general consumer electronics, I'd go for the latter every time both as a consumer and company these days. Time is valuable and losing it to a feature packed unreliable mess is a big risk to that time.
Oh, and applying pretty much any "software building codes" to the web app industry would probably kill startup culture entirely.
Not necessarily. To use the analogy with the building industry, there are different requirements depending on what the building will be used for. Startups holding or processing financial information might have one set of regulations, whereas those hosting cat pictures might be less rigorous.
You should run that prediction by some of your friends in the legal department and see what they think.
Dead Comment
Oceanians live in a constant state of being monitored by the Party, through the use of advanced, invasive technology.
It was terribly dangerous to let your thoughts wander when you were in any public place or within range of a telescreen. The smallest thing could give you away. A nervous tic, an unconscious look of anxiety, a habit of muttering to yourself – anything that carried with it the suggestion of abnormality, of having something to hide. In any case, to wear an improper expression on your face (to look incredulous when a victory was announced, for example) was itself a punishable offense. There was even a word for it in Newspeak: facecrime, it was called. (1.5.65)
Is the the google input box a door to the world or a window into your mind?
How many fingers do you see?
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?
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 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 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.
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).
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.
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...
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.
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.
http://en.wikipedia.org/wiki/Baseband_processor
If you are concerned about your Blackberry spying on you, there's a special "security plug" that you can insert into the headphone jack which will short all of the pins to ground, disabling the microphone. I assume other phones support this as well.
Think about it: you put normal headphones in the jack (no microphones, only tip, ring, sleeve): it will already short the mic input
You might also need access to the PMIC to turn on the amplifiers, but most designs I've seen have access ports from both BP and AP. (This was on Motorola devices, Q and the EZX phones.)
where can I get one?
# batteries
IIRC most battery charging circuits also have a dedicated real time ~OS running. http://www.youtube.com/watch?v=dlSBQ5b6Pdw
# hard drives
Also recently someone did run linux in its hard drive controller (which is a set of arm cores, ~v9 and m3)
HaD intro : http://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-hackin...
Direct link : http://spritesmods.com/?art=hddhack
Proprietary BIOS software has suffered the same issues for the last twenty+ years.
It's also worth thinking about netboot (which comes in several flavors), in which the main processor's potentially buggy BIOS may be independently decoding and processing packets coming over physical wires.
https://github.com/torvalds/linux/search?q=i6050 (Intel WiMAX)
https://github.com/torvalds/linux/search?q=i2400m (Intel WiMAX)
https://github.com/torvalds/linux/search?q=iwlwifi (Intel WiFi)