 Alright so I am very excited to hear this talk because it's going to be given by a kid that is very young, very intelligent. In fact he's competing in the CTF this weekend which makes him way smarter than the lawyer talking to you right now. That's for sure. But I'm also excited because this talk in the abstract, you can see it actually has some magic words in there. How to get started. Yeah? Because a lot of these talks you're going to see this weekend kind of drop you right in the middle and you're picking up just as little bit as you see somebody show off some kind of cool exploit. This is going to be much more of a kind of a 45 minutes survey course I understand. So sit back and relax and let's give Shamus a big round of applause. Have a good time. Thank you. Alright so I hope you're all here because you're interested in learning something about how the baseband in your phone works. So I guess we'll just get started then. So this is kind of the brief agenda for the talk. A little bit about me, why I think these are an interesting research topic and why I've been working on them for the past several months. A little bit about the history and evolution of the platform because I think knowing certain design decisions and why they were made in the past can really help you when you're looking at disassembly and code and like did they really do that silly thing? A little bit about how a modern system on a chip is laid out. It's changed a lot since the first cell phones were introduced. A little bit about the actual custom CPU architecture that the baseband chips and Qualcomm phones actually run on. A brief intro to some cell stuff because not everybody has a huge radio background. I know I didn't. And then how you actually start analyzing these things. So I'm Shamus. I've been working in information security for about four years now. I'm still an undergraduate student actually. I go to UMBC in Maryland. I was a member of their competition team when we went to CCDC a couple years back. I'm participating in the CTF here with Spaceballs this weekend. I'm really interested in like embedded systems and vulnerability research and exploit development and all those kinds of things. And kernels. I like playing with kernels. All right. So my goals for my research and hopefully for what I kind of want some of you guys to get out of this talk is what is a baseband and how is it really like interact with Android? I wanted to find bugs in it. That was my main goal and also wanted to like learn something and have fun. So there's been a little bit of prior work in the area. The first few real baseband talks came out 2010, 2011. And this was back when the Qualcomm basebands ran on ARM processors. And they used a completely different real-time operating system than they run now. So it's a little bit outdated but still worth looking through all these old talks and digging up the videos. They give a great background introduction to some of this stuff. The first talk which really tackled their new architecture was baseband exploitation in 2013, which was given at PAXSEC. It was the first talk to really cover hexagon and any details about it whatsoever. And that's around when those chips started being introduced into phones 2012, 2013. Every Qualcomm phone since then sold has one of these chips in it. And then more recently there was a talk just this past year at Cansec West, which was after I started doing my research. And that was a talk which kind of talked about a bug they found and the debugger they built around it and some of the cool things they did. But it was a lot less of like how do you get started looking for bugs, which those have always historically been some of the most useful talks to me when I'm trying to learn something, not a walk through of exploiting like this kernel zero day. Those are cool and I learn things from them, but I also want to find my own. So for those of you who aren't entirely sure what a baseband is, it's the main chip in your cell phone which actually communicates with the cellular network. On some level it handles the transformation of radio waves into actual ones and zeros and then processes the information inside of those. There's a ridiculous number of cellular standards and use around the world and most baseband chips support most if not all of them and fall over in between them because you don't know if you're leaving the country or if you're roaming in between cells, different carriers, if you're roaming on a different carrier they have things to have differently. So there's a lot of complexity within these, just inherent to the nature of them. It's also your phone's main external interface to the rest of the world. Your data comes over this, your internet, all your text messages and it's one of the last few attack surfaces where you can actually get truly like remote code execution, unauthenticated, no user interaction whatsoever along with some of the other firmware in your phone like the Bluetooth and the Wi-Fi. A lot of exploits have been going the way of you need a browser bug and phishing and somebody clicks in a link. This you really don't really need much in the way of interaction. You just need a phone number. So that's why it was interesting to me. So I kind of picked Qualcomm to focus on as they had by far the largest market share of the whole baseband market. And at least up until recently most of your high end phones carried Qualcomm chip of some kind in them. All your Snapdragon processors and most of your high end androids these days. The markets spread up a little bit more. Huawei makes some of their own basebands. Samsung makes some with their Xenos chips. But the main reason Qualcomm owns a lot of the market is they were the big proponent of a cellular standard called CDMA, which is one of the two big ones. They're kind of grouped into two groups. So you have GSM and you have CDMA. And if this is why phones can be carrier locked because AT&T is GSM and Verizon is CDMA. And they have a death grip in all the patents in the United States for CDMA basically. So if you want to sell a phone which does that, you kind of got to stick a Qualcomm chip in it. For phones in other markets around the world, CDMA is more prominently United States thing. So you'll see a little more variety in the chips. But they still have more than half the market share. So a little bit about the history of the platform. These chips in your phones, the basebands, they run a completely separate operating system separate from Android or iOS. So it's own self-contained operating system with its own bugs and its own rules. So these are something called an RTOS, a real-time embedded operating system. They're typically found in lots of like industrial applications, power, gas, electric, things which have strict time constraints. And you can't have a process like a browser hanging up and freezing your entire system. Things need to happen on a schedule. And there can't be any kind of interruption to those. And you can kind of split RTOSes into two separate categories where they either have some form of memory protection or they just don't. So there's either some form of virtual memory, even if it's not meant for protection purposes or that everything just runs in like a flat address space, straight in memory. The RTOSes are used pretty widely. Cisco routers use one of them, Thredex is Intel's, that runs Intel's modems. And some newer Broadcom Wi-Fi chips I just recently learned, things like that. So going back to the start of the mobile phones, Rex was Qualcomm's real-time executive. It was the original RTOS which ran the modem. And this is before you had smart phones in Android. So this ran your entire phone. It was actually designed for the Intel 186. And then as they started growing as a company and the 186 was getting a little outdated, they actually tried to license a 386 core from Intel. And Intel kind of blew them off at the time because they were busy with other things. But if they hadn't, the cellular market would look pretty different today. Because this is what drove the switched arm on all your chips and phones. So Intel might very well have started producing like lower power consumption chips and the mobile market might not be all armed if they hadn't rejected Qualcomm's offer way back when. But this chip, so they poured it to ARM. This RTOS, sorry. They poured it to ARM and everything ran in supervisor mode. There was no privilege separation. If you had any kind of code execution, you were king. It kind of ran as like one single process and your tasks were just threads in that process. So it was very much a product of its times in the early 90s. So you'll actually still run into this, which is the reason I'm kind of going through some of the quirks. If you buy any kind of like feature phone, so like not a smart phone, burner phone type of deal. A lot of those run something called Qualcomm Brew, which is like their binary runtime for wireless, I think. And that Rex is the core heart of that, actually, the rest of it's piled on top. So tasks are your threads, basically. Every task has a task control block, which kind of stores the information about it, where your stack pointer currently is. What's the priority of the task? Because this is an RTOS, so if your task has a really high priority, it's not going to interrupt it. The size of your stack. Every task has its own stack and then when they are suspended to let room for something else happen, this is all just saved. So if you have any kind of like overflow or code execution, you can actually overwrite a different tasks current state from the stack. So when it's restored, you just took control of something else. The task control blocks are stored in a doubly linked list, so we're going to process another operating system. It's very trivial to dork with things on this system. The only problems is it's poorly documented. So kind of moving out of the end of the 90s and into the mid-2000s, Qualcomm decided to switch away from Rex. And they didn't actually do it for any security reasons. It's just really tricky to debug code when you have no memory protections. You don't know whether something's being caused by some of your code overwriting some other code. Accidentally, it's really tricky to debug things. So they started looking for solutions. If you dig through some of their ancient documentation, you can find Rex didn't even do any kind of parameter validation. They basically told you whatever you passed our API better be right because we're not going to check it. It's great for when you're trying to find bugs. Sadly, they kind of moved away from this to something a little bit more secure. So in the middle, like 2005, 2006-ish, they switched to microkernel called L4, which is kind of an academic microkernel. Came out of academia in the 90s, I think. The way most people have heard of it is something called SEL4, which was the formally verified version of it, which was mathematically proven to be free of certain bug classes. But the microkernel itself was freely available in different kinds of licenses. So this is actually a much more mature operating system. You actually have real processes and real threads. There's actually a privilege separation barrier. The kernel runs in supervisor mode and the actual program is running user space. They were actually going to port L4 to their newest DSP, the one they designed in-house. And they kind of had a falling out with the company they were working with on this with L4. So they decided to just rewrite their own real-time operating system, not really necessarily learning from the mistakes from the last time they did that. So they took L4, which is much more secure than what they had before, and they kind of ruined it by writing an emulation layer for their old RTOS because they didn't want to actually change any of their code base for the modem services. This is something you'll see a lot when you're dealing with this kind of firmware is it has to be approved by different licensing bodies and reevaluate when you make changes. And that can be quite a process to go through. So they try and avoid changing things as much as possible, which is why bugs can be long-lived sometimes or there's terrible turnaround times actually getting updates for your baseband or your Wi-Fi firmware, things like that. So they wrote this emulation layer so they could take all of their actual modem software and it will keep the same API it thinks it's talking to and it transparently converts it on the back end. So that doesn't really help you eliminate that many bugs. But they at least do run the modem software in user mode now instead of in kernel space. And then moving on from that you know they kind of started developing their own in-house digital signal processor. This is the thing which makes Qualcomm chips pretty unique is most other basebands Huawei's HighSilicon, Samsung's Shannon baseband, they all run on some form of ARM processor and they might have some digital signal processing logic to handle like the lower level physical layer conversion. But everything actually runs on ARM. A lot of the actual processing does. Qualcomm actually runs everything just on the DSP as opposed to having the DSP handle some of the conversion and then passing it over to a different processor. So the current one is Kirt, the Qualcomm Real-Time OS. It used to have a different name. I don't know actually what that stood for. It used to be called Blast. And there are actually two hexagon cores in most of your phones now. They have one which handles the baseband, the broadband radio, and they have one which handles audio processing. So they actually expose this to application developers. You can, if you think your algorithm will run better on digital signal processor for some audio tricks you're trying to do, you actually have access to this in a limited capacity. Most the APIs are again backwards compatible so they don't have to change as much software. So some of the threading stuff changed a little bit, but a lot of it's pretty much the same. It's a pretty mature Real-Time OS as far as Real-Time OS is go. You have mutexes and semaphores, same kind of priority-based scheduling you see across a lot of these. But it does actually have memory protections and the operating system itself handles the virtual to physical memory mapping. So the mitigations are kind of hit and miss on this. It is far ahead of its peers. Samsung for instance has NX and has it turned on in some places but not necessarily covering what you would expect it to. There is a complete lack of ASLR and this is common in all base bands. It's really tricky to port some of this software to actually move around in an address space. And like the Real-Time OS loads in the same spot every time. The kernel base is the same place. And then these things have hard code addresses calling each other around. So there's no ASLR. There's plenty of gadgets once you actually have code execution. They do have a non-executable stack so you can't really write to code. You're not supposed to be able to execute data and it does its best to enforce that. It does have stack cookies. It actually has a special register. The frame key register which actually holds some of this stack cookie information and X source it. And then its heat protection is more for accidental corruption. It kind of just marks whether your blocks are in use or not with a magic value. It's not anything super tricky like you see on windows or some of the more common heat valid cares for browsers these days. So it's kind of a mixed bag as far as exploitation is concerned. You can't directly jump to your shell code but as soon as you actually like get program counter or something like that there's no ASLR so it's pretty easy to know where things are in memory and form your own gadgets or use a gadget to write your shell code into a place you can execute it. So AMSS is their actual name for the software stack which runs on the modem. You'll see a lot of confusion about this if you ever start doing any research people call won't like say this covers more than actually does but it's the actual modem software, different drivers and protocols and everything you really use to talk to a cell tower. The lower part of it is pretty chipset specific you know which air interface protocols you actually support. You know there is a dozen different cell standards. The hardware is all different. See of low level different hardware drivers. And on the feature phones I mentioned earlier you have like Q chat and Q camera and Q message and all these applications which actually run are part of AMSS on those and they run on the same baseband. So there's more than 60 different processes or tasks which this is comprised of. You have a watch dog to make sure things don't really time out. You have a sleep timer to save power. You have different things for call control and message processing and diagnostics. Of those one of the most important is the actual diagnostics task. It provides a client server infrastructure where you can request information from the modem stack. And this is what a lot of Qualcomm's internal tools will talk to. So it's a holdover from their old rec stays. It will handle requests over serial or serial exposed over USB which is more common now. When it's a packet based protocol you send information and send stuff back. So if you ever get your hands on any of the Qualcomm tools which have been floating around this is how you pull off any kind of over-the-air logs, failures, debugging information if you manage to turn it on, current status if you're trying to like test things over the air, different statistics on calls or drop packs as packets and things like that. So modern systems on a chip are a lot more complicated than they used to be. And one of the things you kind of run into is something called a Qfuse at least on Qualcomm devices. Samsung's have their own similar depending on the chipset. But it's a bank of one-time programmable fuses. There is very little public documentation about what controls what. But these are one time once you blow the bit you're not really supposed to be able to change it back. And hardware debugging is disabled in production devices by blowing one of these bits. Supposedly the factory has a way to re-enable it but I haven't been able to figure it out and I don't know anyone else who's mentioned being able to figure it out either. This is how if you ever have a Samsung phone they have something called the Nox bit which is blown if you flash an unsigned kernel. And they kind of use that towards void warranty claims sometimes. So if you unlock your bootloader and start dorking with your Android device that's how they tell and that's how they'll deny you if you break it. Secure boot is heavily based off this. The cryptographic keys are burned in and can't be changed. The trust zone uses an undefined number of these bits as well. So in the good old days before more modern Android and iOS devices you kind of had your baseband processor and your actual application processor. And the baseband was actually the first one which booted up and brought up the application processor. I didn't have direct DMA. If you pop the baseband you can kind of just control everything and write to the application processor and the user would never know. Chips are a lot more complicated now and they have a lot more interconnected subsystems. So on the current Qualcomm SOC for example you have your modem processor subsystem which is composed of this hexagon DSP and the actual accompanying like hardware ASIC which handles the over-the-air stuff. You have your actual application processor set which on more recent devices is like its own set of eight ARM cores. You have something called RPM which handles power management for the device and this has its own bootloader and bootrom and it runs its own it's its own separate ARM core. You don't really know about it. There's an interesting piece of research. I'm trying to remember the company name. I think it was aleph security and they used a bug and were able to dump some of these other bootloaders so they could dump like the RPM bootloader and you can play with it and see what it does. These are all cryptographically verified to before they're actually uploaded to the device. Your wireless subsystem is its own separate little subsystem. On most devices it's a Broadcom chip although Qualcomm has their own Wi-Fi. I don't know which phones they put it on. Then you have your audio subsystem which is another digital signal processor which again is exposed to the user. So this is a really simplified boot order. It's actually a lot more complicated than that. Usually you power on the phone. The burned-in bootloader powers up and it loads a secondary stage bootloader and that loads like the RPM firmware to handle a lot of the power on the device and then it loads a second stage which actually loads your trust zone. Your QSE is Qualcomm's trust zone environment. So it loads that and then the trust zone handles loading everything else. So all the cryptographic signatures are verified by the trust zone after this point. So that loads the application bootloader. So that's like a boot or S boot which actually boots your Android kernel for example. So that handles loading the kernel and the kernel itself pushes over something called a modem boot authenticator which handles validating the actual modem image which is then pushed over and the modem has its own say a boot loader and then the AMSS software is validated and the modem kind is brought up. Then after that your wireless and your other DSPs are brought online. So the the baseband and the application processor have to have some way to be able to talk to each other. To be able to say hey I want to make a phone call, hey you got an incoming text, things like that. So on most devices there's a form of shared memory interface where one side writes some data and the other side checks periodically and picks it up and processes it. And there's actually a common set of APIs if we're talking about Android here iOS does a little different. But there's a common set of APIs on the Linux and on the modem side which take care of initializing this, allocating this, searching for things in it. So it is part of the actual like main RAM. The baseband chip does not get its own separate RAM and neither do any of these other subsystems. They are all actually talking to the same eight or however many gigs of RAM you have on your phone and it's just portioned up with each little device once it's own little piece. So the SMD is the shared memory driver which is a more high level wrapper around some of these low level APIs. So you can kind of just have a pipe and shove data into it and then the other side just reads from it. It's a little less complicated for driver developers. Each of your AMSS tasks has its own separate two-way channel over this shared memory interface. So your diagnostics has a set of channels and that's where it passes information. Remote procedure calls have their own set of channels. Your GPS has your own set of channels. So this is one of your main attack surfaces if you're looking to elevate your privileges from the baseband chip itself to the actual application processor. They talk back and forth and this is one of the main ways they communicate. So if you can find bugs and how messages are being parsed or sent, that's how you can kind of jump and try and get code execution on the other side. One of the other things they also have is the QMI protocol Qualcomm design. Originally it was kind of designed to supplement the old Haze AT command set you used to program modems with and it itself like Qualcomm, everything Qualcomm does is a wrap around another older protocol they used to have. But it's used to talk to your modem. You can configure it, send in different commands, but you don't actually make any hardware decisions based off of this. All you can do is kind of influence how different pieces act. Again just like the diagnostic task it's a client server model. It's a variable length packet structure which is interestingly this is where a lot of your bugs are going to be. There's a set header and then a different number of payloads you can send and these are all type length value based. So the first portion specifies what this is. If you're trying to set up a phone call or what you're trying to accomplish. Then the next piece is how long is the message and then followed by the actual data. So because this was originally coded quite a while ago it's quite possible to find bugs and it just blindly trusts the values you're feeding it for for instance like your length and if it passes that into some sort of copy or it makes parsing decisions based on that you can try and get code execution in the kernel on the Android or iOS side. So the real kind of new thing about what Qualcomm has been doing is they design their own custom in-house DSP. It's not really based on anything else. So you know if you were here and you heard about the CTF last year where they wrote their own custom architecture with 9-bit bytes. It's not quite as bad as that but it's not really related to any type of Intel or ARM assembly code you usually see. It's a general purpose digital signal processor which is really interesting. It's not specifically designed to handle cellular stuff which is why you can handle like audio processing on it as well. So there are two on the sock like I mentioned earlier. One is dedicated just for your broadband radio and the second one is just for audio processing and if you write NAP you can actually access this. That's its own separate attack service for like breaking out of sandboxes if you're trying to play audio and things like that because that other audio DSP also has its own R-toss on it and if you can pop that you kind of get like media server privileges depending on how your Android device is enabled and you have a lot more privileges from there to try and escalate to the system. So the way the hexagon chip is laid out you have a variable number of hardware threads depends on the specific iteration of chip but you can say four for general example. So kind of like cores on an Intel device and each of those threads shares the L1 and the L2 caches between them. The threads don't have separate caches but there are separate caches for instructions and for data and operands just like you have on ARM or a power pc chip. So you can't even if there was no annex or dep you couldn't just smash the stack and then jump to your shell code because that's data and it won't be in the instruction cache and you'll cause a fault. So you actually do have to like dork with cache lines and stuff if you are trying to build an exploit like that. And the other really interesting thing is these four hardware threads are designed for parallel execution so when you compile a program down to hexagon it actually the compiler figures out different operations which don't need they don't depend on each other. So then it will schedule those just to run at the same time simultaneously across all four threads. So this is kind of high level how that how it's laid out. Each thread has an execution unit it pulls instructions. Those are packet based so your packet doesn't have to be four instructions. It can be three and the execution unit will just not fetch anything for that. So you don't have the packets run out of order. You can't have a packet with three running on three of the threads and the other threads actually like a packet ahead. It'll just kind of spin wheels for a cycle and then pull in the next packet. Then they have shared instruction data caches and then a shared more high level l2 cache. So the architecture is kind of standard as far as embed devices go. You have a bunch of general purpose registers they're 32 bits wide. Your first six are used to pass arguments to functions when you're looking at the assembly. The return value is stored in register zero and then you have a split between caller saved and call e save just kind of like you do on most other architectures. The stack is again pretty standard. You have a stack pointer and a frame pointer and you have a link register just like arm for holding return addresses in. The stack grows downwards from high to low memory. It does need to be eight byte aligned which is a one gotcha when you're writing an exploit. And because Qualcomm designed this architecture from scratch they kind of had the freedom to put in a lot of different things they wanted to. So they have instructions which will just take care of setting up and tearing down your stack frames as opposed to the compiler wasting a few instructions on it like it kind of does with Intel and ARM. So it's pretty standard. The threads in their R-toss are actually saved on the stack. They're pretty far apart but if you have a large enough overwrite you can corrupt the state of another thread or another process just like you were able to back in rex. That hasn't really changed. Besides your kind of standard yeah we have registers we pass arguments and it works like a computer. They add in a couple really useful things for debugging. So you have a system status register which is the first place you should be checking when you get like a RAM dump or any kind of crash. So this holds the ACID which is the address space ID the crash happened in. It'll hold an 8-bit value for the cause of the crash whether it was a like a page fault or you know divide by zero or your other standard operations. And it will tell you which of the virtual address registers to look in for more information. So there are actually two different bad virtual address registers which hold exception addresses generated. So the address of the exception handler when an exception occurs. And there's like two separate executions slots for each of those threads which is why there's two registers. And then you have an exception link register which holds the program counter value from when an exception was triggered and so it saves it off for you. So they actually have a lot of useful debugging information. So this is a little more recently introduced. They've been constantly making iterations of this processor. So on the most recent ones probably shipped in the phones in the last year or so they've introduced something called protection domains which implement hardware hardware enforced separate address spaces. And they did this because they have the capability to run the Wi-Fi subsystem on the same DSP as the broadband radio and they want to keep them very, very separate so they can't touch each other. And this sounds like a really cool idea in theory except that means your Wi-Fi and your broadband are going to be sharing the same layer one and layer two caches. I haven't really dug into that but I'm pretty sure you can either get intro leaks or really influence the way the other one is seeing the cache. So it's kind of divided there's a kernel mode then they have kind of like a a second split after that in between standard users and guests. So guest is more like ring one or ring two on Intel device as opposed to ring three which is the user. So your broadband radio stuff kind of runs in the guest OS mode. The RTOS kernel itself runs in the kernel mode and then your Wi-Fi would run in user mode. And interestingly enough sometimes these stack checks for like the stack canaries and stuff aren't actually done in kernel mode only in the user in the guest mode. All right. So cellular stuff is very very complicated. I had spent way too much time reading documentation trying to figure this stuff out but after the first generation telephone lines it kind of split into two branches as they were going into wireless. So you have GSM which is time division multiple access based and then you have the standard Qualcomm came up with which is why they really own a lot of patents around it which is CDMA which is a code division multiple access I think. And those kind of split onto separate branches for like the next 20 years each adding things independently of each other and then LTE is kind of a convergence of the two. So over here on on my screen is on the left but where you see GSM and CDMA that's really like second generation what you think of as a 2G cellular network those did not originally have any ability for data. You had no internet you couldn't get your emails so that was kind of hacked on to the standards with the form of edge and GPRS in the case of GSM networks. So that's really what they call 2.5G once you start digging into like the cellular forums. And then it kind of kept on proceeding through 3G and adding more higher speeds trying to make things more efficient less power hungry. And then LTE is kind of where we're at now and they're already discussing the fifth generation network standards. So just like when you're looking at networking on a computer you have your OSI or your TCP IP model and things are kind of split up into different layers. Cellular Stack has that as well. Things are broken up into several different layers and just like with TCP IP the higher up you go the more complicated things are and there are more bugs. Think of it kind of like Layer 2 you have your Ethernet and you can have like ARP spoofing and stuff and it's really confusing computers about who you are and you can go up to IP you have more nonsense you can play with the headers and like IP fragmentation and reassembly and it's more trying to dork with the actual other end of the connection as opposed to fooling them about who you are. So cellular is pretty much the same way. You have your physical layer which in this case it's not over a wire it's over the air and then as you go up it gets more complicated and there's more things to parse. So up at this top level with like the NAS layer and your internet protocol stuff is a really good place to hunt for bugs. Like all your call control signaling happens up there there's loads of messages with like length value and type length value associated with them. Going down a little bit to like radio resource control there's lots of messages in there but typically there are a little more fixed length when you're digging through the standards. So there is a load of different ways you can actually make or receive a call. 2G, 3G, 2.5G over LTE is it a real voice call or is it just voice over data call? You know voice over LTE is more common now but any kind of like voice call you can make over the internet you can also make it over the internet on your phone. And the cell of your phone is typically support all of these because you don't know where in the country or what network you're really going to be on and you can your call type can drop as you're switching in between cells if you've ever been driving and your call quality gets bad and it dropped to 2G because you have no cell coverage. So all these different ways to do things adds a lot of complexity and these aren't really that simple to begin with. There's a lot more involved in the setup in the tear down and there isn't just like a TCP IP handshake. To be fair only from BTS over to MS is the actual handset part of this the rest of that's actually more in the back and in the cellular network but it's still pretty complicated. Trying to go through these. The best place to start looking for bugs is the standards. They don't specify any kind of implementation they just say what it should look like and it's totally up to the vendor and the carrier and the OEM to work this out. 3GPP is the organization which kind of says these are the standards we're going to deal with and that's made up of several different organizations and they all argue and eventually agree on something. Unlike Wi-Fi or Bluetooth these are freely available you can just go download them which is fantastic. The reason nobody does is because they're like 80,000 pages long and they're terrible but they're actually really useful when you are looking for bugs. So you can kind of see it specifies the packet itself what each octet is in the packet and it breaks down to like each bit in that octet and the part you're so that's interesting after you think you found a bug and you're trying to trigger it. The more interesting part to look at to start is where it specifies what options you can really add and so there's a bunch of mandatory and optional ones as you can see and you're interested in all the ones which have variable length options basically LV or TLV because it's a good chance one of these they screwed up somewhere along the way. So how do you actually want to get started dealing with this? It's their own custom architecture there is no like IDA Pro does not support this natively so there are a few plugins for IDA Pro out of the three of those I found the GSMK one off of GitHub to be the most intuitive to start with at first it's actually been updated somewhat recently for IDA 7 the second one down is actually a Python wrapper around the ObjDump patches Qualcomm themselves has provided so that's a good place to start for if you want to write your own disassembler because they kind of did some of the hard work of parsing the documentation for you I started trying to port that into BinaryNinja because I wanted the lifting to an intermediate language but that's still really gross and in no shape to be released anybody unfortunately so what do you actually look at on a device? The radio firmware is usually on its own separate partition it varies from device to device you'll have to find a way to pull that off you might have to root your phone in order to get it it really varies because the Android ecosystem is so fragmented it's a massive binary this one I just pulled off of my current phone is 300 megabytes and when you load it into IDA it will find 80,000 plus functions and there's no debugging information or anything there is a lot of strings which is useful especially a lot of like debugging information left in those strings but you still have 80,000 functions to dig through with no really good place to start so I was trying to cut down on the effort so one of my ideas I had was if I'm looking for exploits I'm going to be looking for memory copies and string copies now I want to find the memory allocations and the deallocations and all that kind of stuff all your standard library functions essentially so I was like those should be called fairly frequently I think given how often and how many different pieces need to parse things so you could use IDAPython to kind of count the number of cross references to a function that doesn't necessarily give you the best metric because like one part of that graph could be called a whole bunch of different times but it's an easy place to start and these things will be called two, three, thousand, four, four thousand times so you kind of sort that and start at the top of the list and work down and I found memory copies and things like that pretty quickly and they're usually pretty obvious when you're staring at the assembly code a couple like type copy loops and a stub at either end so how do you actually debug this thing is the problem even debugging an Android kernel is really irritating to do if you ever try it when you're trying to do it on a device you have to do like a serial over UART option or like over USB and you got to patch it and KGDB is not fun to deal with this is even worse so Qualcomm has some internal tools which use that DIIG protocol and talk to it we aren't really supposed to have those a few of them have been leaked from different carriers and things like that it's pretty hair-miss some of them don't work on newer phones these phones do support JTAG although on some phones it's disabled in production devices but to get that JTAG connection you need to buy it from a company called Lagerbach and they're the only ones who make it and it's something like north of ten thousand dollars that was way out of my budget although I'm sure it works very well the approach some of the other presentations on the subject have taken is they get memory read write through an exploit and then they kind of build a debugger around that that implies you already have an exploit to start with rather than using a debugger to help you poke around either one's a good option but the way I took was since the modem firmware is right here I can just patch that and try and make it do what I want and the only problem with that is they are signed so if you make a change you'll fail the signature verification and nothing happens unlike Samsung modems which are encrypted on disk Qualcomm doesn't encrypt them so it's easy to disassemble and patch them but you have to get past the signature verification which like I mentioned earlier with the boot order happens in the trust zone so you need a trust zone bug the great thing about base bands is they don't change that often because this firmware has to be recertified so even if you're looking at a phone which is a few years old a lot of it really hasn't changed that much and at least is a place to start so there's been trust zone bugs going back years and any number of them will work depends on which phone and which trust zone version you have but it's only a two byte change in the trust zone you patch which stables the signature checking so you can use that as an arbitrary right you patch out those bytes and then you can load wherever the hell you want so it does require you to have an unlock boot loader so that you can compile your own kernel and flash that and the modem has its own set of internal hashes for different segments within it and those still do need to be consistent but that's a little those aren't cryptographic in nature they're just more of an integrity error kind of check and you can fix those up so there's plenty of different CVEs they're all over the place some of them have like full pox you don't even need to do that much work to you turn into a trust zone right to disable things with so then you actually need to build a debugger around this and I'm running a little short on time but to build a debugger you basically need to be able to read and write memory to set break points if you're trying to like this to a piece of data you might need to change permission since you're really not supposed to be able to write to that and setting register values is kind of useful too so there's a few different ways the baseband takes input obviously over the air is the main way trying to implement a debugger over the radio is not something I wanted to try you have that shared memory interface again and you could write a kernel drive at a time and talk to that but you need something to respond on the other end and that's kind of what that Kansak West talk did was they implemented debugging stuff on the other end and they kind of talked back and forth and built a full featured debugger around it I didn't really want to take the effort to do that and one of the other ways you used to originally talk to them was over serial for these Hayes AT commands is how you originally used to configure something you could pass it dialing and connection parameters and then say here's the number and make a call and they did it so we've kind of come a long way but these modems still support this and still expose this the different carriers and OEMs and vendors add their own command extensions to them some of them do really ridiculous things Samsung has had issues in the past where there are commands to unlock the device so even if it's passcode locked if you plug into your computer and talk to the modem you can like unlock it so some of those really aren't that great so since I can patch the modem firmware and I can patch out the signature checking so I can upload my own I figured this is an already easy way to talk to a device I don't need to write my own stub on the other end and these already have a way to all the input output to serials already handled for you because there's you know 100 different AT commands you know all that logic is already pre-declared for you so I can just hook one of those handlers patch out what it does and replace it with my functionality so I picked a couple different qualcomm commands which aren't really used frequently I'm not even sure what some of them do but now they do what I want them to do so you can just you make one a read you pass it now address you pass the size it's a bit stuff back out same thing with writes and you've trying to change permissions you can turn these primitives into a more featured debugger without actually having to work with a ton of code on the modem side and I found about this actually putting all this hard work is that company Lauterbach actually makes a simulator for hexagon so you can upload a ramdump to this simulator and it will show you the whole processor state and you can like debug it and this is actually really cool and it is actually free like most enterprise software there's like a free trial you can get and sure like their scripting abilities are kind of limited but you can kind of work with that for not having to pay ten thousand dollars if you actually want to test stuff you need a license to broadcast and cellular frequencies most places in the world otherwise like in America the FCC gets really mad at you so you're supposed to have some kind of fairy cage or do it in your concrete basement and pray they never come knock on your door and I've been really lucky in that software defined radios have gotten a lot cheaper recently and there's a lot different ones to choose from and as long as it's full duplex it can transmit and receive at the same time it can support gsm and edge and gprs and the different things I want to play with I just bought the Blader F recently because that was the cheapest and I'm a student and I'm poor but the options get way more expensive after that but the Blader F works great for my purposes I've had zero complaints all it needs to do is be full duplex I think the hack RF is cheaper but is not full duplex that won't work um a bunch of different open source projects have come up 8bts open bts the list keeps on growing every year um 8bts is the one I ended up going with as it's actually really cleanly documented and in the code comments it'll say which part of the standards this came from and which table like these options came from is really easy to cross reference when you're trying to cause a bug and trigger it and yeah I think we're pretty much out of time but I will be hanging around if anybody has questions for me or you can hit me up on Twitter or something I usually respond pretty quickly so yeah