You could have an SoC of your choice for a user-facing operating system and a separate SoC with separate memory for the baseband and whatever the hell the carrier wants to push to the device. The operating system running on the user SoC could have a driver that allows it to get internet access from the baseband SoC over some high-bandwidth-but-not-memory-sharing bus.
Until I can buy something like this, my gpg and ssh keys are staying far away from my phone, which kind of sucks.
I don't know if it's true, but it makes sense given the, allegedly, crappy code base in Broadcoms firmwares.
>> "To protect the device from vulnerabilities in network processor firmware, network interfaces including Wi-Fi and baseband have limited access to application processor memory. When USB or SDIO is used to interface with the network processor, the network processor cannot initiate Direct Memory Access (DMA) transactions to the application processor. When PCIe is used, each network processor is on its own isolated PCIe bus. An IOMMU on each PCIe bus limits the network processor’s DMA access to pages of memory containing its network packets or control structures."
Although I guess it makes sense given that apple designs their own application processor SoCs and then has to use a separate (Qualcomm, Intel) modem rather than using a Snapdragon eight-something with everything talking to everything in the same package.
I'm not a huge Apple fan lately, and have never liked the iPhone, but this definitely seems like a pretty concrete bullet point for "iPhone is generally more secure than Android."
For maximum speed (900MB/s), the NVMe in the 6 shipped data to/from the processor core using NVMe-side DMA bus mastering.
This begged the question: if you could hardware-MITM the communications between the NVMe and the main processor, and then reverse-engineer the way the DMA bus mastering was done... could you do arbitrary I/O on the main CPU?
Well, the NVMe has a package-embedded Cortex-M5 (actually a Cortex-R5) inside, which handles raw NAND interface, TRIM, sector reallocation, and related functionality. (It may operate at 200MHz.)
So... since the NVMe is PCI-e, it begs the question, could you possibly connect it to a PC? The answer is a solid YES, if you're motivated enough to commision the custom ZIF SOIC receptacle required. But it Just Works(TM)!
It turns out the firmware upgrades for this microcontroller were (at the time, at least) distributed in unencrypted iOS packages. This made it possible to understand the NVMe update process, fake the iPhone CPU side of the update sequence via the PC PCI-e connection, and exploit the firmware update code to write attacker-defined code into the host PC's memory - proving without a shadow of a doubt that the NVMe's PCI transciever fuses were configured for RDMA.
With this established, all you need to do is flip everything over and turn _the PC into a fake NVMe_ by creating a 2nd test rig (with a 2nd commission for the inverse of the SOIC socket) that hooks the PC PCE-e port to the iPhone CPU _via an FPGA_, figure out the various low-level steps involved in initialization before the RDMA bit is enabled...
...and discover that the iPhone 6 CPU doesn't IOMMU-protect the memory area where SecureROM is running from. (Since, at the point the NVMe is initialized, SecureROM is running and waiting for the NVMe to ping it so it can fetch and validate iBoot, the iOS stage2 bootloader).
Maybe. Why didn't Apple IOMMU-protect the SecureROM area?!?
At least the guy who figured this out got $200k for his efforts.
The above was TL;DRed from http://ramtin-amin.fr/#nvmepcie and http://ramtin-amin.fr/#nvmedma, which I needed to read multiple times (in some cases weeks/months apart) to fully grasp.
Since I read the above I have 0% confidence in Apple device security.
To be fair, I highly doubt the 6's design phase started anytime after the incident, so maybe a "we don't need to push that far" carried through the life of the 6 project. I wonder if anyone tried to lobby to lock this down. Or maybe Apple doesn't care if people push that hard? Or maybe...
I was mostly concerned about what horrible things could be done via OTA updates from the carrier (or payloads designed to look like carrier OTA updates, since apparently they're rarely encryoted).
In the case of ultra-portable devices (that are all the more easily stolen) there should be a measure of physical security though. I also use the iPhone 6 example because the San Bernadino shooter's 5S was physically confiscated by police.
This being said, wireless vulnerabilities are indeed a high priority. You're probably already aware of the various vulnerabilities suffered by Broadcom Wi-Fi chipsets used in almost all phones.
- https://bugs.chromium.org/p/project-zero/issues/detail?id=12... <-- pwning an iPhone 7, FWIW
Your concerns regarding cellular encryption are made all the more valid because of the extremely high political sensitivity of surfacing _anything_ that would even remotely suggest that encryption is not being used (classical security by obscurity). Someone asked for a cellular encryption indicator in Android 9 years ago, and I thought the response they received was very very insightful and gave a lot of food for thought. Slowly reading between the lines of every official reply is necessary. https://issuetracker.google.com/issues/36911336
It took Apple four years to harden their baseband firmware to resist all kinds of fuzzing efforts and bear in mind Apple only had 2-3 concurrent models to worry about. It must be harder for android vendors with their myriad different platforms.
Geohot's first iPhone hack, IIRC, used an unsecured JTAG pinout he managed to find on the PCB that allowed direct write access to the firmware. Later it was discovered that the system bootloader had enough exploits that the process could be done entirely in software.
Later iPhone models would gradually ramp up security to the point that nothing of this sort could be done very easily even with physical access.
Us BBS nerds used to know AT commands by heart. We would send instructions to our 2400 baud Hayes modems using QModem:
ATZ = reset
ATDT1234 = dial 1234 on a touch tone phone (DP for pulse dial)
The Hayes/AT commands are still used either for debug purposes, or for non-smartphone use cases like IoT.
wow that is embarrassing. This needs to be added to CTS like 5 years ago ..
> We found that in some cases the "charge-only" USB mode may also fail to block AT commands.
Thus various companies have made devices that conditionally apply said short.
Here is one example: https://www.startech.com/Cables/USB-2.0/USB-Adapters/USB-2-F...
It would only work on USB-C host devices as well though, USB-A would still revert to either 500mA as long as the data lines are tied with a resistor
Don't do that. Ever. Always use your own charger and cable, preferably the ones that came with the phone. If not make sure you're sourcing them from a reputable company and not an anonymous Chinese importer.
Also I see they got access to /proc which I assume is also access to memory via /proc/pid/mem?
As mentioned in the article/paper, this attack vector has been used before.
The AT+USBDEBUG command was used to unlock the Samsung S6 Dec 10, 2015.
Blog about this exploit back then: https://www.bloglovin.com/blogs/xda-developers-5233323/2015-...
Video of the unlock back then: https://twitter.com/rpaleari/status/674983960162787328/video...
The code published by FICS here:
is based off the same code from Dec 2015 here:
Am I conflating 2 different issues? Before, it was a theoretical risk. So with a basestation/stingrays you could do it remotely, and now over USB as well.
Edit: Just realized that the commands bypassed the prompts. That is a different beast. But the question still remains.
An IMEI and serial are still unique identifiers that can be used for tracking.
Now I am wary of public charging stations.
And, it is time to hack on my phone.
Frankly, the automation they show in the video can be super useful.
Err... were these commands meant to be obfuscated the whole time?