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

51–60 of 79 posts

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

#51

Post by EvangelicalPig »

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…

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

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

#52

Post by mcny »

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.

Is this still a problem if the phone doesn't have a sim card and is on airplane mode with WiFi and Bluetooth turned on?

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

#53

Post by kevin_thibedeau »

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…

Sequential search is near optimal for short lists. On embedded hardware you don't always have the luxury to create elaborate data structures for the "proper" solution.

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

#54

Post by adrianN »

mcny wrote: post #52
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.

Is this still a problem if the phone doesn't have a sim card and is on airplane mode with WiFi and Bluetooth turned on?

I guess the answer to this is "who knows". You can't really trust the hardware on your phone.

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

#55

Post by an_account_name »

EvangelicalPig wrote: post #51
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…

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.

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

#56

Post by fmj »

userbinator wrote: post #48
cabaalis wrote: post #47

Really curious, why treat these automation capabilities as a vulnerability? Several security popups appeared, a cable was attached, an application executed on the computer... as a user I'd much rather have the possibility in the future of automating my phone's UI than to have vendors treat this as a vulnerability and patch. Edit: Just realized that the commands bypassed the prompts. That is a different beast. But the…

I found it somewhat amusing that they mentioned model, manufacturer, IMEI and serial as being a "sensitive information leak" --- if you're in physical possession of the phone, those things can be found without even turning it on.

It doesn't require an attacker to have physical possession of the phone. They just need you to plug your phone into one of their USB ports. Something like a public charging station would be perfect for this.

An IMEI and serial are still unique identifiers that can be used for tracking.

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

#58

Post by DarkStar851 »

joezydeco wrote: post #25
digi_owl wrote: post #22

Earlier quoted context omitted.

While not at guaranteed, killing the data wires (or shorting them) makes the device think it is dealing with a charge only port. 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...

The USB condom is more for situations where you are in public and wish to charge your device from an unknown and possibly hostile USB-A receptacle.

That Startech device still isolates the data line, it just has the added bonus of adding fast charging support. It'd be effective as a "USB condom" alternative.

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

#59

Post by ohazi »

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

Post reply on HN