Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

atcommands.org

Post reply on HN
Print view View original

61–70 of 79 posts

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#61

Post by tinus_hn »

Laforet wrote: post #37

Huh, this is an old trick but always a good one. Back in the days when iPhones were AT&T exclusive people managed to bypass the carrier lock by fuzzing all possible permutations of AT commands to the baseband. Once a crash was found it could potebtially be used as an exploit to modify its internal state. It took Apple four years to harden their baseband firmware to resist all kinds of fuzzing efforts and bear in mind…

Apple provides the baseband firmware itself. Android manufacturers have to ask the chipset manufacturer for updates. That’s a major difference.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#62

Post by mcbridematt »

xen2xen1 wrote: post #4

Umm, Hayes commands are still used? That's a blast from the past. I thought those went out in the 80s or 90s?

The phone OS itself would actually use something like the QMI (Qualcomm management interface) protocol or MBIM for modem cards.

The Hayes/AT commands are still used either for debug purposes, or for non-smartphone use cases like IoT.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#63

Post by Erlich_Bachman »

klondike_ wrote: post #46

The real issue here is proprietary baseband modems. These modems contain fully functional microprocessors along with low level access to the main processor. Even if you replace your ROM with an open source one, it is usually impossible to change the firmware on the modem.

The new Librem phones are supposed to have a hardware switch that cuts the power to the baseband modem when needed. That's about the best we can do at this point in time it seems.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#64

Post by Laforet »

an_account_name wrote: post #55
EvangelicalPig wrote: post #51

Earlier quoted context omitted.

Related: Anyone remember how Geohot's iPhone 2G hardware unlock worked back in the day? (~2007)

I remember there was one that could be triggered just by loading a web page with a specially crafted image file.

That would be a later jailbreak, not a baseband unlock per se.

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.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#65

Post by IshKebab »

userbinator wrote: post #50

I'm surprised that the full command strings appear verbatim in the firmware --- and even more surprised that they appear with their "AT" prefix; this suggests they're being parsed by an algorithm that isn't particularly efficient, like a linear search. If something more optimised like a switch or trie were used, it wouldn't be possible to extract them this way, and some more intense reverse-engineering would be requi…

It would be ridiculous over-engineering to use a trie here given the performance requirements.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#67

Post by Flow »

ohazi wrote: post #59
klondike_ wrote: post #46

The real issue here is proprietary baseband modems. These modems contain fully functional microprocessors along with low level access to the main processor. Even if you replace your ROM with an open source one, it is usually impossible to change the firmware on the modem.

It'd be nice if someone designed a phone that architecturally resembled a computer attached to a mobile hotspot. 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 bas…

I recall reading an article years ago describing iPhone being architectured like this. Even if the baseband system is compromised, it don't have access to the rest of the system. And traffic from the rest of the system passing thru the baseband is mostly encrypted.

I don't know if it's true, but it makes sense given the, allegedly, crappy code base in Broadcoms firmwares.

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#68

Post by nanch »

I'm glad to see this research being done. They did a great job with the paper and their searchable site.

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: https://github.com/FICS/atcmd/blob/master/usbswitch/usbswitc...

is based off the same code from Dec 2015 here: https://github.com/ud2/advisories/blob/master/android/samsun...

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#69

Post by maccam94 »

Flow wrote: post #67
ohazi wrote: post #59

Earlier quoted context omitted.

It'd be nice if someone designed a phone that architecturally resembled a computer attached to a mobile hotspot. 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 bas…

I recall reading an article years ago describing iPhone being architectured like this. Even if the baseband system is compromised, it don't have access to the rest of the system. And traffic from the rest of the system passing thru the baseband is mostly encrypted. I don't know if it's true, but it makes sense given the, allegedly, crappy code base in Broadcoms firmwares.

The iPhone connects to the baseband via an internal USB connection, so the baseband doesn't have full direct memory access to the phone

Re: ATtention Spanned: Comprehensive Android Vulnerability Analysis of AT Commands

#70

Post by rainbowmverse »

Flow wrote: post #67
ohazi wrote: post #59

Earlier quoted context omitted.

It'd be nice if someone designed a phone that architecturally resembled a computer attached to a mobile hotspot. 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 bas…

I recall reading an article years ago describing iPhone being architectured like this. Even if the baseband system is compromised, it don't have access to the rest of the system. And traffic from the rest of the system passing thru the baseband is mostly encrypted. I don't know if it's true, but it makes sense given the, allegedly, crappy code base in Broadcoms firmwares.

From the iOS security guide PDF (https://www.apple.com/business/site/docs/iOS_Security_Guide....):

>> "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."

Post reply on HN