 So what if I told you there is a cyber risk present today in cellular communications that allows an attacker the ability to send you a phone call and your device is compromised? That's it. There's no user interaction. There's no clicking any links. There's no picking up the phone. Just a simple fact of the simple ability for the phone call to be sent. And this threat vector which is present in cellular communications today provides an attacker the ability to deliver a no-click remote code execution exploit over the air under the radar to your device. And to be more accurate, any device that's even momentarily connected to an attacker-controlled cellular tower. So today we're super excited to be here. I appreciate everyone joining. We wanted to talk to you about our review of the Pixel 6 Monum Stack. It's been a culmination of many months of our efforts. I'm Farzan Karimi. I'm the engineering manager of the Android Red Team. I'm joined by our world-class researchers here, Shuang Cheng, our technical lead, Eugene Rodinov, and Shilin Gong. All right, so here's our session agenda. We provide a brief overview of the Pixel 6 Monum Stack and share the results of our impactful 2021 Red Team engagement of the Monum. 2021, yes, that's how long it took us to get PR approval if we get up here. Before jumping into what we were able to exploit, we'll set up a context and cover a high-level architecture of the Pixel Monum followed by our key findings. We'll then cover two CVEs that if you Google, you'll see nothing about them on the internet today, aside from the fact that they're rated critical severity by NIST and our Android severity guidelines. These two CVEs that we identified were integral in our exploit chain. So we're going to deep-dive those. We're going to show you a demo that's pretty exciting. And then moving on, actually, we also want to cover a very important step you can take from a mediation standpoint that's better protect yourself. So it's probably the most important take-away from this presentation, so stay tuned for that. I do want to emphasize, before moving on, that everything we're going to present today is fixed. No zero days, I'm sorry. So just a really high-level, actually, I'm sorry. Just wanted to give you a basic understanding of the engagement missions that we had for this review. The primary objective for our review was to get code execution on the Pixel 6 Modem stack via the baseband. And it worked with our feature teams to fix all these bugs before release. We did a pretty good job on that. There was a critical issue that came up that put this talk into jeopardy that Eugene would cover in a bit. And then bonus points, for working with our Modem OEM to fix everything before release. As with most DEF CON presentations, we did achieve these objectives. So a little bit about us. As I mentioned, we're the Android Red Team. We work for Google. Our mission is to increase Android security. That means we Red Team devices that run on Android. It could be Google Pixel. It could be Pixel Watch, a whole ecosystem of devices. We do that a number of ways through offensive research where we simulate adversarial campaigns. We build tools that help us scale. So we invest a lot in fuzzing and primarily continuous fuzzing to help us scale and find bugs while we're doing more manual code reviews and exploit development. That's the third item, exploit dev. It's a place we spend a lot of time in. A lot of people ask, why do you spend weeks on exploit dev? And for us, it's so important to be able to better articulate these complex issues to leadership with a demo. It also allows us to find more vulnerabilities as we go through the exploit writing exercise. So it's a really fruitful investment for us. And then finally, we invest a lot in remediation. We work with our feature teams to fix bugs. If nobody's fixing our bugs, we suck as a Red Team. And so we want to make sure we build a good relationship there. And so that's something we really value. So let's get right into it. Why do we pick the modem? For starters, it's been an emerging area of risk in a mobile connectivity space for a few years now. You can see some of the headlines. These are all very recent, some very recent work by Project Zero earlier this year on the modem. Why all this attention now? So the short answer is the cost to ride has dramatically decreased in the past few years. So if you're looking to get yourself equipment, such as a software divine radio and an SDR, 10 years ago, that would have put you back $10,000 to $20,000. Today, you can get an SDR for 2K. So it becomes more accessible for security researchers and real hackers to go purchase this equipment and target cellular comms. It's also one reason we're seeing more of a recent influx of bugs coming in through our bug bounty program and why we're able to get a bunch of SDRs for our team to find a bunch of bugs. So what can you do if you actually find a bug in the modem? So some earlier I mentioned over-the-air RCE. If you're not familiar with that terminology, over-the-air is simply just a form of digital communication, usually in the form of a software update that's sent wirelessly over-the-air to your phone, sometimes through Wi-Fi networks. Most of the time, it's associated with cellular communications. In the Pixel modem stack, getting over-the-air RCE nets you code execution in a privileged context. That's because there's no concept of identity isolation or network segmentation within the modem itself. So you get code execution, what can you do? So one thing you can do is now of service. I could already see eyes glazing when I say DOS, but in the context of modem, it's actually pretty impactful. So just imagine a football stadium filled with tens of thousands of people all connected to a single attacker-controlled cellular tower and then everyone losing connectivity all at once. If you're more of a nation-state profile, you have more interesting exploit vectors at your disposal. You may be interested in pulling SMS text data or RCS text data and just passively sniff that information. You could also spoof messages coming from users that you target, and all this allows you to do something else, so you could target OTP code sent over SMS to get yourself a MFA bypass. So we all know there's forgot your password opportunities to just get a code sent to your text or phone, and then you can log in. Wink, wink, that is our demo later today, so we'll be covering. What can be worse than all that? Well, how about I pivot to the kernel? So with full root kernel privilege access, you have the ability to fully own the phone, all bets are off. So before getting into our finding is an exploit, work a little background on the modem's always helpful. Wait, who's snuck this slide in? It's a 56K modem. It's not what we were talking about. It's very clever, there's zero laughs there. Thank you, there's better than black hat, thanks. Moving on, let's talk about Pixel modem, what even is it? Well, it provides you a means to connect to a cellular network so you can check texts, surf the web, get phone calls. It's a critical component with access to sensitive user data like SMS data, remotely accessible with radio technologies, and it's a high profile target for nation state, and Project Zero, if you listen to their offensive con talk from earlier this year, it's been a historical source of vulnerabilities because it's using legacy protocols. And these all present opportunities for security improvement. It's also super important to note that while we're all on 4G and 5G today, it still supports the 2G standard, right? And that's an important theme that we're gonna get into in this presentation. So just a quick visual of our attack surface analysis of the modem, so everything you see in blue here just kind of represents the different layers and the components of the modem, all the way from the communication layer down to the physical layer. Stuff in red is what we targeted during our red team engagement. Dark red is what we were actually able to exploit, so specifically the pre-authentication attack surface in 2G as well as some low level decoders such as ASAN-1. If you see aka, that just basically means authentication and key agreement, which is just a common protocol in cellular communications to support mutual off between a device and a carrier. Before I hand it off to Shwan, I wanna get ahead of a question that maybe some of you are already asking and it's, well, I'm on a current generation pixel or iPhone and I'm connected to 5G right now. I'm safe, right? Why does your presentation matter to me? Well, there's a lot of ways you can find yourself forced back on 2G, right? So just listing a couple here, some of these factors, and it's important to note that there's a lot of complex logic that goes into how each of these factors are weighted, right? It's not straightforward, but if thing is like network coverage, depending on the country or region you're in, 2G may be your only option, right? So if you're there, you're on 2G if you wanna make a phone call. Emergency calls often over 2G when others aren't available. Other standards like 4G and 5G. There's signal strength, network congestion, battery optimization, so 2G uses less battery in 4G. So if you're low battery, that might be a factor that influences you to switch over to 2G. These individual factors actually don't matter too much. The intent of this slide is to just show that a motivated adversary will find the right combination of these ingredients to influence your phone to switch back to 2G. And it's in 2G that our attack lives and thrives. So with that, I'll hand it over to Shuan who will cover our methodologies. Okay, before we talk about our result, let's talk about our approaches. So following engagement, we conducted mostly with Fuzzy as our primary approach. The reason that we wanted to Fuzzy is that we were given a really large code base and it's very complex. And Fuzzy has been proven very effective and long-lasting for these kind of situations. For Fuzzy, we mostly focused on something we call host-based Fuzzy. Here, host is a term that comes from Android build system. It's in comparison to device. Host-based Fuzzy means that we found our target, we compile it into a fuzzer that can run on Linux host environment. And to do that, we need to carefully hack the build system and mark the hardware dependencies so that we can build our target and run it on the Linux environment without physical devices attached. We also looked into emulations of full systems that allows us to do more closer to the actual hardware attacks. And lastly, we plan on device fuzzing at the beginning but we were running out of time so that was cut. Fuzzing is our primary approach. In addition to fuzzing, we also use static analysis. Here, we use code QL as our primary tool for something like exploring the code base or doing variant analysis. And lastly, manual code review is always our last resort to apply on the areas identified by the above two approaches, all the areas hard to cover by those two approaches. So by the end of the engagement, we created 10 fuzzers, host-based fuzzers, running our internal fuzzing platform 24-7. This is benefit that you get from fuzzing is that you get something running all the time after engagement. And it's very useful to catch regressions on new bugs along runs. We also developed a very easy to use framework kind of thing so that we can easily convert any new modern component with that we think is suspicious into a host-based fuzzers in future engagement. And during this engagement, we found fuzzers not only a great finding bugs, they also tell you which area you should look into. By the number of crashes you found, you can jump into the area. One thing we noticed that fuzzing, fuzzers sometimes are blocked by the minor issues like an all-point dereference and one byte OOB read. Those can get fixed, but to fix this in production code takes time. Our solution is while it's getting fixed, let's just jump into the code, start manual code review, auditing the related code so that we can speed up our bug-finding process and find as many as bugs by the end of the engagement. Another challenge we run into is with large code base, how can we prioritize our component for fuzzing? We were giving a code base something around two gigabytes with source code and libraries and how can we find out which one is the first target? It's impossible to look through the source code. What we did is let's study the 3GPP spec and understand which component is dealing with untrusted data, all which component is dealing with decoders. Like for example here, ASM decoder, it's always a hot topic, so that's our first target. And another thing like the TRV data structures that commonly use in the 3GPP spec, those are all the code targets for our fuzzing. And in addition, we use CodeQL as our static lens tools. Modem not only has large code space, code size, but also has very complex configurations. These configurations involves compiler, macros, and redefinitions of some symbols. It's not easy to pinpoint which function you are looking at. And CodeQL helps a lot in this thing. It gives us the exact function that used for the task entry point, our interrupt handlers. It also visualize the interactions between different components. The other way we use CodeQL error is to do general bug findings. We use that to find certain patterns, like memcopy that writes to a fixed size buffer, but use a non-constant size parameter. It doesn't necessary to be a issue, but there's issues coming from that kind of usages. And also, fuzzers find bugs. We use CodeQL errors to do valid analysis for those bugs, trying to see if we can find similar bugs. Lastly, by the end of the engagement, we noticed there's a publication research paper called FormWare, which is doing emulation-based fuzzing. Inspired by that, we also create our own full-stack emulation using code-based approach. With the hardware layers added, we can drop in the FormWare binary and emulate part of the functions, which is great for root cause analysis and debugging of our crashes. By the way, here's how it looks like when we run our emulation-based fuzzer. And what happens when we throw in the crash test input that we discovered from the whole-space fuzzer? It gives us more information on the memory layout and lots of details that we couldn't have from the whole-space fuzzer. From here, I'll hand over to Eugene, talk about findings. Thank you, Sean. Before we go into the details of the vulnerabilities which we identified during the fuzzing and code review, I'd like to bring your attention to your really great research presented earlier this year, the offensive con by Google Project Zero, how to hack Shannon-based band from a phone, which focuses on a different attack surface that we investigated in our work. They were hacking modem from a phone while we are hacking modem from a malicious base station. So this is an important distinction here. At the same time, they mentioned that they were looking at 2G and SN.1 attack surface and they mentioned that they didn't find anything interesting there, like maybe all the bugs are gone. Honestly, when our engagement team saw this presentation, we felt very relieved and very rewarded for the statement, which means, which might mean that we are, our bug hunting work, which took one year earlier, was actually useful and meaningful. We're not going to take all the credit for that. There has been other great research contributing to security in this area, but with the next slide, I would like to introduce some additional context. During this engagement, we spent about three to four months. In total, we identified about 120 vulnerabilities in 2G and SN.1 surface and about 50 vulnerabilities are specifically in SN.1 decoders. And as you can see that the vast majority of these bugs were got by fuzzers. Like about 80% of the vulnerabilities were reported by fuzzers. And we were mostly relying on stack traces to de-dupe the vulnerabilities. So there is a chance that there is the same root cause, but it manifests itself in different crashes. So they got different bugs assignments. Those fuzzers are running even today on our continuous fuzzing infrastructure. Fun fact, shortly after submitting to Black Hat and DevCon, one of the fuzzers identified a critical issue and we were even thinking about withdrawing from the conferences because we didn't want to release zero days. And there is no way PRN legal would clear this presentation to be here. But well, here we go. The issue was fixed and we're speaking about it. By critical vulnerabilities, we mean mostly out of bounds memory rights which are reachable remotely. Obviously not all the criticals are exploitable because we got quite a few off-by-one rights which are very difficult to leverage to get code execution on modem in a remote context. Yet we got quite a few powerful primitives. So one of them, which we will be discussing later, the core primitive for demonstrating code execution modem is CVE-2017-0. This is an out of bounds write-in heap. There is another vulnerability which would make exploitation super easy and straightforward. Well, not super easy, definitely not super easy, but we didn't need to rely on Rob-style attacks is MMU misconfiguration which rendered heap and stack code executable. So we simply run in a shell code from the heap work just fine. And with that, let's take a look at the vulnerability as 2017-0. This is a linear out of bounds write-in heap. This is a classic straightforward out of bounds write-in heap. You can see on the code snippet here. Okay, yeah. So we have one byte buffer allocated at this point. So, and this buffer is passed to ASN-decode-information-element function which decodes arbitrary number fully attacker-controlled bytes into it. Due to technical constraints, we are able to override only up to 255 bytes on the heap but which is still a lot. And this vulnerability is triggered during the call setup stage. So before receiving the call and even before showing identification to a user that someone is calling them, there is a number of ASN-1 messages sent from the base station to the modem and exploitation happens. The vulnerability is triggered at this stage. So there is no user interaction involved at all. User doesn't need to pick up the phone. So this is a very powerful primitive by itself. Right now we'll show you how we leverage it to get arbitrary write primitive. But before doing this, a few words about heap management because it is important to understand how we are getting arbitrary write. So every buffer allocated on the heap is prefixed with a 32 byte header which contains metadata for the allocation such as how many bytes were requested, what is the task ID allocating memory and a very important information stored in the very beginning. The first two bytes is the identifier of the allocation driver. So it appears there is multiple allocation drivers used by malloc and one of them is a partitioned memory driver which corresponds to 0400 highlighted here in red. Essentially it manages, it allocates memory from array of fixed size memory blocks which grow with the power of two. The state of the memory blocks is kept in the additional bitmap and looking at this partitioned memory driver we didn't find anything what we can do with this to overwrite something useful. However, looking around we identified there is another allocation driver, system dynamic memory driver which has ID 0100 and luckily for us, but luckily for Modem, they're using on double linked lists with unsafe unlinking and this double linked list is also in the heap header which we're able to overwrite. So this is pretty straightforward classical unsafe unlinking technique to get arbitrary write. In our case, the adjacent object which follows the vulnerable buffer is very reliably allocated during the vulnerability exploitation stage. So I think in 90% of cases, well maybe even closer to 99, there is always another object following right after the vulnerable buffer. So as you can see on this image, the address starts at 3A0 is actually the vulnerable buffer which corresponds to the one byte buffer and at the address 3C0 is the header of the next adjacent object. So we simply overwrite it, we change the allocation driver ID to 0100, we forge the double linked list and luckily for us, and again, luckily for Modem, this buffer is very reliably freed after the overwrite operation. So we almost have a very reliable arbitrary write primitive and we use this primitive to hook free function. The implementation of the free function in this Modem is quite generic. It's just a stub which calls real implementation using function pointer which is stored in global variables. So we simply override this global pointer and this is how we hook the function. Just to summarize everything together, how is there getting RC in Modem looks like? Before the overflow, we have buffer A and buffer B. Buffer B has partition memory driver allocation driver ID. We overwrite it and change to system dynamic allocator. We forge the double linked lists so we modify pre-field to point to a malicious system header which is located in the global data which is readable, writable, and executable thanks to the MMU misconfiguration. And this is also part of the stage zero payload which contains shell code. And once this buffer is freed, during unsafe unlinking, we modify the free function pointer redirected to our shell code and here how it works. There is one unclear piece here. Well, at least one for me is how did you get stage zero payload here? This is what I'm going to be here discussing here. So before triggering the vulnerability, we need to send the stage zero shell code and we identify the primitive for doing this which allows us to send from the malicious base station to the victim device up to 80 bytes and we know where exactly those 80 bytes are stored because we need to know the virtual address at which this malicious shell code is located. There is no SLR. So this address is fixed. Once we have it, we trigger a CB-2017.0 to your free function and at this point we're invoking our stage zero shell code at every free operation. It is very convenient because we're able to inspect contents of the free buffer and the heap is used very frequently in many cases in modems or we can intercept and inspect for a lot of data. 80 bytes is actually not allowed to implement anything meaningful for stage zero shell code because it's not only shell code, it's also the malicious system dynamic heap header and what stage zero shell code is doing is just functionality to your receive stage one shell code which is also sent in chunks, 80 bytes per iteration. Later, she'll in for show you a demo and you can see that how we're sending stage one shell code. Stage zero shell code assembles stage one shell code altogether, copies it into your executable heap and re hooks free function and at this point we can implement arbitrary complexity functionality in stage one shell code. We implemented SMS forwarding functionality which forwards SMS messages from the victim device to the attacker control number and at this point we are ready for the demo. So let's go to the remote code execution into modern firmware. So here's how the attack looks like. The first step, the victim connect to a digital serial network either 3G, 4G or 5G. It doesn't matter. The only requirement is that the victim enables 2G on his phone. But you know, 2G is default enabled on the Pixel 6 and on most of the phones. So now we can set up a malicious base station. It's a 2G base station. We'll set it up and waiting for the victim to connect to it. You know there are lots of purpose and methods about how to get a victim connected to a fake 2G base station. So this is not a problem. Then we can, I'm waiting for the victim connect to it and once the victim connected to the 2G base station we can start our attack. Once the attack succeed, we will have fully control the victim's base band from where we are in the victim's model. So now we can do a lot of funny stuff. For example, we can use the job or intercept the victim's incoming phone call. Also we can modify the incoming SMS message or send out SMS message on behalf of the victim. Here for demo purpose we can capture and transfer all the incoming SMS message to our phone so that we can take over the victim's Twitter account. Here is the device we are using. We are using three devices. On the left is the victim using pixel six. And in the middle is the open BTS. We build this fake base station using open BTS and we will modify the source code, inject our malicious packages and do our attack and on the right is another phone. It's a regular phone. Any phone can make a call, works for us. Okay. Let's play the demo. It's a lot of work. Let me figure out why. I think we can click it. Okay, so we are playing the demo. You can see the victim is going to connect to our fake base station. Once the victim connected, we can start our attack. The first step is to send out the initial payload. This is a small piece of code. So we will broadcast this piece of code into the victim's modern phone memory. So now it's inside the victim's modern memory but it's not running. We are getting it running by calling the victim. You can see once the victim receives the call, the victim doesn't have to do anything. Our vulnerability will be triggered and this initial payload will be triggered. So at this moment, we already have a small piece of code running inside the victim's modern but it's just a small piece of code. We want to do a more complicated task. So we are sending more code. We send them piece by piece and the first stage payload we will receive and assemble them together. Once all the code received, the share code will be running and send out a message back. So you can see now we received a message from the victim and the content to the pond. So this SMS message is sending out from the victim's modern phone by all share code. So that means all share code is running successfully inside the victim's modern and we have fully controlled the victim's modern. Okay. This is the first part of the demo. For the second part, we are going to demo we can take over the victim's Twitter account to do that. Let's put the victim back to a normal base station. So you can see the victim connect back to the normal base station. That's simply we stop our base station, then the victim will connect back. So the victim can log into Twitter or GitHub or yeah. Okay. So now the victim opens his Twitter account, check in for the new message and also his profile, you can see he's very kind of him and he has a brilliant profile and also anyone know who is the victim? Okay. Yeah. I think if you now come to us and get the bonus, okay. So if you have a Twitter account but you don't remember the password, you are told Twitter, I forgot my password. So Twitter will say, okay, give me your phone number. I will send you an SMS message which contains an authentication code. You give us this code back so we can confirm you own this account. So that's how the attack works. You can see we enter the victim's phone number and the victim receives this message. So, you know, we have a share code running inside the victim's model. So this message will be forward to us. So you can see we receive the same message. So using the code inside this message, we can bypass the authentication from Twitter and get into the victim's Twitter account and we set the password. Yeah. And here you can see the victim can see this message on his phone but this is just a demo purpose. In real attack we can hide this message, make it invisible. So, okay. Now we have bypassed the authentication and modified the password. So we are setting it to a very strong password. And I think we're done. Yeah, that's all. Yeah, we have to take over the account. Yeah, so that's the account we have. Yeah, that's the demo into the remote code execution of Modem firmware. Thank you. Yeah, I'll hand it over to Xuen in the next part. Thank you, Xuenian. Very impressive video. Let's just focus. Okay, just to clarify that in the video you'll see a lot of operations on the victim's phone but those are just for them for us to speed up the demo. In real case, victim doesn't need to do anything. This is a zero-click, fully remote attack. To get the attack to happen, there are some prerequisites. First, the victim's device needs to have 2G stack enabled, which is by default on Pixel 6 and many other modern devices. And also the victim needs to be in the nearby range for us to deploy the attack. Depending on what hardware you're using, this nearby range can be up to five miles range. Once we launch the attack, we get a full Modem firmware compromise. We have full control of the Modem firmware. If I have time, I can write a debug Modem firmware. And in demo, we just showed how to demonstrate the Twitter account takeover but the real consequences can be much worse. You can take over somebody's Bitcoin account, get all their monies, or you can even send messages on behalf of them. We also, during the engagement, found other bugs that hinting it's possible to pivot in from Modem to Android OS that can lead to full system compromise. However, we ran out of time so we didn't dig further in that direction. And the issues utilized by this exploit, there are three issues. The first one is the root cause. We have attacker-controlled heap overwrite in the GSM stack. And second, we have a misconfiguration in the MMU that allows us to have writeable and executable memory. And lastly, the lack of standard security mitigations making our exploit easier. Yeah, before Modem engagement, I always thinking hacking Modem over-to-air is a very high-tech complex task. It requires very expensive devices. But our setup really surprised and scared me. As you can see, it's pretty simple. The core part of this setup is that white box under the phones. This is a SDR device. In our case, we use USRPP 200. And then we have a bunch of cables. For legal compliances, we also have fair day cage so that we don't interfere with neighborhood telecommunications. So if you are malicious attackers, make sure you have this box so that you don't break the law. Yeah, it's very important. Anyway, and for softwares, we have software-based GSM solutions. There are many of them. Open BTS, E2 BTS. They are either free or open source to use, very accessible. This entire setup is very accessible. It's less than a couple thousand dollars and you can get even cheaper with a cheaper SDR devices. And like other exploitations, we always run into challenges. For this one, the first challenge we run into is when we put everything into the fair day cage, they interfere with each other. And the radio is totally black magic to me. So I have no idea how to solve it correctly. What way do you just manually take the positions so that they work? And of course, we also need to mix a couple of softwares working together. They are all complex softwares. We have to carefully take the configurations so we can get a reliable exploitation. Because this is exploitations, we do this on production images. And debugging shell code on production image is a pain. Luckily, we were able to collect ramdown and inspect the memory status when it crashes. We also modify some of the command handlers and to conform the successful deployment of exploitations. Lastly, as Eugene mentioned, our first stage payload used to fit in 80 bytes space. It's less than 80 bytes because we also need to fit in some fake heap primitives. It's not easy. We have to go through all the arm instructions that are trying to get that works. Eventually we got it work. So that comes the demo. So from here, I'll hand over to Eugene and talk about remediations. Thank you. Speaking of remediation and hardening work, besides finding vulnerabilities via fuzzing and manual code review, Android security is also trying to reduce attack surface and make this rotation of classes of the vulnerabilities more difficult. And one of the features which was recently shipped with Android 12, which is supported on certain versions of radio hell, is ability to disallow 2G networks in various SIM settings. And this mitigations would essentially make you immune to the attacks which we just demonstrated because in this case, the enforcement works at the hardware and the firmware level. And when the toggle is off, the modem simply won't scan for 2G networks. Insecurity of 2G protocol stack is a non-topic. There are many security features missing, including mutual authentication. And this is one of the reasons why we specifically looked in this attack surface. So you don't need to have the pixel device to do this. It should be available on the supported versions since Android 12 and supported radio hell versions. So if you haven't done this, Android user is in this audience. This is what I recommend doing, especially since we are here at DEF CON. And in addition to that, we're exploring options on enabling compiler-based mitigations for bare metal code in production. Unfortunately, state of the compiler-based mitigations for bare metal code is behind of user space code and even kernel, for various reasons, significant resource constraints, missing support from the tool chain. So this is what we are currently exploring and playing with to enable Bound Sanitizer, Integer Sanitizer for the modem firmware, running not only on the pre-release test devices, but also to be used in production. And with that, I'm passionate to you for some for concluding thoughts. All right, thanks, Eugene. Just some final thoughts to wrap up this session. We, again, red-teamed to secure the pixel modem. We found over 20 criticals and 50 of them in ASAN alone, so a big attack surface, lots of value and focusing in that stack alone. We invested a lot in fuzzing. That's probably how we found most of our bugs, so we continue to do that. Just as Eugene mentioned, 2G is an outdated protocol. Please flip that toggle off if you have an Android phone. There's been reports and some articles already that there's a couple of fake 2G base stations around DEF CON. If you're in, what was it, Paris and Caesar is probably here by now, too. This is your friendly reminder to disable 2G. And if you can't find that 2G toggle, you may be on an iPhone. On the mitigation side, we're doing more work in this space. There's actually a great article that was released by our connectivity security team two days ago that talks about what you can do more than just disabling 2G or what we've already done. So check out that article, links on the bottom, right? And it talks about doing things like disabling NullSci for support on cellular networks. So lots of investment in this space. Our work is never done. Just mentioning red team is just one thing we do. Out of many things at Google. So special thanks to all the work streams here and all these teams that participated heavily in our review. We couldn't have found all these bugs without some help. So we really appreciate everyone's contributions. Last thing we'll all leave you with is that this has been a very exciting review for us, but our work isn't done. We teased a pivot to the kernel earlier. So who knows? Maybe you'll hear more about that at a conference near you soon. Thank you. We have two minutes for Q and A, if anybody has any questions. There's a line, okay. There's a line in the center. You could also come up if you don't want to ask your questions out loud. Have we released any of the fuzzing framework for the public? Juan, do you? I can answer that. Unfortunately, the framework is ready to the source code that we cannot release. So this is totally internal use. Yes. Yeah, great question. So how much of that 2G toggle that reduces the attack surface we've seen? So most of our attack surface can be eliminated or mitigated by flipping the 2G toggle, but emergency calls use 2G. So you can't fully disable it. We don't disable it by default. That's the reason we don't. So, but you have the option to manually. To comment on that. So I think what happens is 2G by default will be disabled if you flip the toggle. But if you are making a 911 calls, that 2G stack will then be enabled just to make sure you get enough coverage. Yeah. Yes. The question is why do we still allow 2G for the most part? Why can't we fix the client protocol and the device drivers? Yep. Let me try to answer this question from my perspective. So first, 2G itself is by design lack of lots of security issues. So like there's no way for the device to know that if they are talking to a legit 2G base station or malicious ones. So this opens a big attack surface that we cannot fix it by spec. And second is software by default there's always bugs. Nobody can guarantee there's 100% bug-free software. So the way that we mitigate these is to reduce the attack surface and of course fixing the bugs is another perspective and we are doing that all the time. It's just you cannot guarantee your software is running 100% bug-free. Correct. Yeah. The design of 2G doesn't have proper authentications. Any other questions? All right. Well, thanks everyone. Appreciate your time. Oh, there is one more. Sorry. So the question was like just by going in airplane mode but still using WiFi, disabling WiFi and going on airplane mode or not going on airplane mode. Okay. Yeah, it's a good question. I don't know if we can comment too much on that. Like if you could disable airplane or enable airplane mode, disable WiFi can information still be leaked out? Probably through Bluetooth or oh, everything off. Yeah, I mean, there's always, you know, do you have any thoughts on this one? I don't know how this airplane mode and WiFi disability is implemented out. So my understanding is if you disable them like airplane mode, modem should be like shut down and it shouldn't be working at all. But I heard some brand, they have this. So when you turn off WiFi, the WiFi is actually not completely turned off for some reason, which I don't know any details about that and I don't know which device has that. But modem should be turned off completely if you turn on airplane mode. I think that's by law. I think we're done on time, right? Cool, thanks again, guys. Thanks.