Read on Twitter
I'll be live tweeting some of the #BHUSA2020 mobile track today, starting with "Emulating Samsung's Baseband for Security Testing" by Grant Hernandez and and Marius Muench.
Of course the stream cuts out as soon as I post that lol
Anyway, we start out by going over past research on public baseband security work (there's not very much, I recognize every talk/paper they've linked).
They start by introducing ShannonEE, the emulation environment they built.
They start by introducing ShannonEE, the emulation environment they built.
He starts by talking about how exceedingly difficult it is to get into this type of work. The hardware is a huge headache and the standards are "acronym soup" (can confirm lol).
His first setup was a 2G base station and some basic logging with adb (android debug bridge).
His first setup was a 2G base station and some basic logging with adb (android debug bridge).
whoops, talk was too interesting, so I accidentally stopped tweeting. Going from notes now:
Anyway, eventually they (1) realized OTA fuzzing is hell (which I can confirm), and (2) there were some problems with modem dumps requiring root, but root disables some logging.
Anyway, eventually they (1) realized OTA fuzzing is hell (which I can confirm), and (2) there were some problems with modem dumps requiring root, but root disables some logging.
BTW OTA = "over the air", basically it means crafting and broadcasting actual radio messages that the modem then receives
There's some other work in this research space (by the qualcomm security team iirc) where they inject mocked OTA messages as part of a modem fuzzing project
There's some other work in this research space (by the qualcomm security team iirc) where they inject mocked OTA messages as part of a modem fuzzing project
Also, before I go on I just want to point out that (1) they didn't have source code access (they talk abt reversing in a bit) (lol pun not intended), (2) there's no paper to read atm, & (3) their tools will be released once they're done going thu the disclosure process w Samsung.
So, they got started by acquired firmware images, buying a research phone, and then got started reversing~!
There was a nice chart of how things were structured, which iirc was informed by other firmware they'd reversed.
There was a nice chart of how things were structured, which iirc was informed by other firmware they'd reversed.
One of the first things they noticed was a common pattern where a certain conditional flag was set which indicated that nothing was actually encrypted, sooo that saved a lot of time and they just dropped everything into Ghidra and got to work
To note: all previous researcher in this space starts out by talking about how they dealt with the modem.bin file being encrypted, so the fact that they didn't have to deal with this is pretty significant (and nice!)
Next up is screenshot from reversing where they highlight the functions they are primarily interested in, namely "boot" and "main".
and also the Shannon boot modes they are interested in:
- DUMP mode, for when the device is crashing
- BOOT mode, for when things are starting normally
they also mention UART for bootloader debug printing, which can later be dumped from the kernel
- DUMP mode, for when the device is crashing
- BOOT mode, for when things are starting normally
they also mention UART for bootloader debug printing, which can later be dumped from the kernel
tbc the previously mentioned kernel is the proprietary Samsung kernel, which they were able to get access to thx to the GPL
the highlight from the above pic is `link_device_memory.h`, which contains structs on memory shared between the AP and CP
quick aside, AP = Application Processor (e.g. like where android runs)
CP = cellular processor, the thing that contains the modem/baseband/etc
quick aside, AP = Application Processor (e.g. like where android runs)
CP = cellular processor, the thing that contains the modem/baseband/etc
more aside for context, the ~~big thing~~ in this field is if u can (1) get to the AP from the CP, or (2) access shared memory between the two
My notes are sparse, gonna summarize the next few slides tersely:
- mapping some magic numbers bw Samsung Kernel + part of the baseband they'd reversed
- Started out using avatar^2. Python based peripheral def'ns for easy prototyping, so they didnt have 2 compile C over and over
- mapping some magic numbers bw Samsung Kernel + part of the baseband they'd reversed
- Started out using avatar^2. Python based peripheral def'ns for easy prototyping, so they didnt have 2 compile C over and over
also they briefly mentioned that the Samsung RIL is the IPC between the kernel and the baseband itself
