 I'm Josh Thomas, Monk. We're going to get started. We're going to have a lot of fun today, I hope. A couple of intro ratted to the talk. I made a drinking game and then I got really lame and I don't have anything to drink on stage. But if you do and want to play around, this is Ricky. Ricky likes to drink. If you see Ricky, take a drink. He'll come up a lot. So this talk has a couple phases, but before I even get started with the actual talk, hands up if you run Android. Hands keep them up if you actually have your own kernel, own ROM. Did you actually compile it? Okay. Did you ever look at the source? Like any source at all? Wow. Okay. All of it? Yeah. So you have no fucking clue what's running on your phone. We'll come back. Even if like someone was in the room, I was like, yeah, I looked at every fucking line. No, you didn't. Sorry. We all know that, but this talk is going to play with what you don't know about what's already running on your phone. So start. I wanted to skip this because personally I really don't like these slides, but given what I'm talking about, I guess I needed a little bit of background so why you should trust me. Don't, if this makes logical sense to you, thank you, man, then believe me, if not, have fun with the tools I'm going to show you. These are my opinions, not my employers. And the tools in the second half of the preso are really, yeah, they're fun, they're playful, they're offensive, whatever. The whole point of me open sourcing them is we don't know these type of tools exist. Let's learn about these tools. Let's figure out how to protect against them. I'm not really talking Odeys. We'll get to that in a second and I'll get on a tirade. But this is post Odey, post X. Like I'm in the system. We've, as a community, don't really ever look at that type of persistence and how to protect against it. So I'm going to show you how I, as an attacker, would do things and then maybe we can all start figuring out how to protect against me. So I'm going to talk about boring-ass things and then I'm going to talk about the actual war games that we're going to talk about today and then we'll go through a couple scenarios on my tools and what they do. Then we'll wrap up at the very end. So, boring kit. I hear malware. I hear root kits. I fucking think spam. It's boring. It's really, really boring. It makes money. You know, someone wants to pop 50,000 boxes so they can do something. Blah, blah, blah, blah, blah. It's boring. It's not interesting at all. But hackers love the mallwares, right? Because with the mallwares you can get the credit and then you can buy all the things. Again, fucking boring. It is, right? I mean, it's not innovation. There's nothing new. It's normally not actually anything sexy at all. It's just iterative, boring. You don't have to do anything cool because you don't really care if your bots get popped, right? I mean, that's not the point. You know you're going to lose them. You know you can just pop another 50,000 next month. It just goes back and forth. Everything's disposable. No one specifically targeted boring. If you want to know more about that mentality, Mudge did a great keynote two years ago and pretty much everything he's talked about since then kind of talks about that symbiotic relationship and how that's boring. Whatever. Our real fun. For every game, we need rules, right? So what do we need? We need two players. We need game mechanics and we need goals for a game. Player one. I wonder who player one is. I'm going to go with player one is any government worldwide, any state-sponsored organization, so you're talking people with a lot of money or corporations with a lot of money. You know, bad guys, right? Maybe more bad guys. Prep in for it. Maybe more bad guys. Player two. So we've got a lot of money on player one. Who's player two? Fucking you and you and y'all. That's pretty cool. So in this game, when we start getting into mechanics, we still need O-days, right? We actually want to pop things. We're starting to target people for some reason. So we still use O-days, but really that's just the gift wrap. I mean that is disposable. No one cares. Well, a lot of people care and I'm trying to get you to not care so much. What we really want is we want to get on devices. That's the only reason we use O-days. O-days are not the real point. They're disposable. I'm going to spend money on an O-day to get on your device to then do something interesting. But because everyone likes O-days and I'm saying it a whole bunch, how much do they cost? Do they cost money? There's the grug with more money. And fuck it, more money, right? Like, so Rick Ross is happy because there's a lot of money. But I mean, again, you may spend 10, 20, 30, 50K, 500K, a million on some really sexy O-day. Remember that number, a million. We'll pretend that all O-days sell for a million. Every single O-day is a million dollar O-day. I want to hack all the things. So I need all the O-days. I don't really care about laptops anymore, personally. This is where it's at to me. It's all mobile devices. It's all cell phones. They have everything. I can listen to all your calls. I can read all your emails. I know exactly where you are. I mean, it's obvious. This is now what used to be our computer. This is now us in digital form. We carry them everywhere. We use them for everything. Oh, if you're targeting him, Symbian O-days are actually still worth a million dollars. But fuck it, right? Like, everyone raise their hand. I'm Android. I'm special. There's no exploits there. Sure. Unless, you know, I had money at which point. So we've got game mechanics for this type of world. What we're really doing is we're taking an O-day. We're jumping on the device. So what I care about is that kit, whatever that implant is I'm putting on a device. That's where the real money is. That's what's doing something. And I mean, let your minds run wild. What would you want to do on someone's phone? You know, whatever that is, that's what you're doing. Doing that type of coding is boring. Those are just lame-ass developers in cube farms cranking out code. It's typical software. It's boring. It takes dev time. People have a real job. But it costs money too. Typically, it costs a lot more money than an O-day. Typically it costs a fuck ton more than an O-day. As I mean, think about it, right? If you're trying to do something sexy, a million dollars for an O-day, $20 million for whatever you're going to do, which do you not want to lose? Especially if you know when you bought that O-day, it's got a shelf life. What you really, really, really care about is protecting that large investment, not this disposable thing that you bought that, I mean, you know, maybe around two months, maybe around six months. So we get a little more disturbed. That's okay. What do we want? We want all the data. That's what your cell phone is. That's what I want. I want everything. So we've got all of our players. Let's have a game. Who's going to win this game? How long is it going to take? Very, very, very short. And I wonder who won. Yeah, they won. Every time. They, it's, no one is even remotely capable of writing the tools right now that can detect against advanced things. Because we're not looking at it. We're still focused on malware and spam and all the boring shit. So if I'm writing $20 million worth of code, I want to protect that investment. I want to protect it lots. I want to make sure that it's never found. I want to make sure that it's deep. It's not something that's going to pop up on McAfee. It's not something that's going to pop up on the New York Times front page that we found X doing Y. This needs to never ever exist. So again, because we kind of picked on him a little earlier, he, the gruck actually does talk about quite a bit of these things, at least in the theoretical thing on Twitter, which is always kind of fun. But what we don't want is we never want our gear to show up. That will make Rick sad. And we don't want a sad Rick. We want a happy Rick. So we're going to hide. We're going to hide deep. We're going to have a lot of fun hiding. Before I move one definition because I just tend to say it and I've realized that not everyone knows what I'm talking about. So if I say air to glass, what I mean is I'm coming off CDMA, GSM, Wi-Fi. I don't know. I'm coming from somewhere, Bluetooth, outside of the phone. I'm getting on the phone. Air to glass means I never touch storage. So I've got an implant. It's in a device. When you reboot that device, it's gone, right? It's got to be reinfected. If you do something like that, though, you're pretty damn secure on the protection of your investment. Because unless someone can forensically jump in there and grab things out of ram, volatile memory before they reboot, you're safe. The problem with air to glass is I mean, you never know when you're going to lose your implant. That sucks. And you've got limited space, right? If you don't want to start interacting and being obvious that there's something wrong with the phone. So War Game One, let's move away from air to glass. How can I get something on disk and hide it to where no one can find it? So this is the NANDEX project. This project was originally funded by DARPA's cyber fast track. Awesome, awesome, awesome project. The goal of this was how can I do a proof of concept for offensive work and then how can we take that and try to defend against it? So I'll do my demo. So I'm going to run the demo twice on video and then once at the beginning and once at the end of talking about it. So what we have on the, ooh, is it not showing up? Cool. So what this video is going to do, yeah. I'm basically side loading a kernel module which we'll talk about and look at source in a second. But this is going to kill a block on NAND. So I've got an implant that's actually on disk, it's saved on disk. Now I'm going to remove that block of memory from the phone. I can still call into it but it doesn't exist. DD won't pull it, forensics tools won't pull it. It's just gone from typical devices. I show this twice because I just really love how sexually Android crashes here. So we're side loading a kernel module remotely and I'm forcing a kernel thing as well and we reboot eventually and the block of memory is just gone. Now I've got 512K I can play with for as long as I want. How do I do this? Sweet. How NAND works. Let's start there. So NAND is very complicated. You've got little bitty buckets that hold an electron. If there's an electron in there you've got a one. If there's no electron it's a zero. That's basic binary. That's how this hardware works. EEs decided to say hey, these little buckets that hold one bit need to be organized into pages. Those pages are then logically created into blocks. Blocks are pretty easy to deal with. It's what you're normally dealing with if you're writing drivers at a block level. It's easier to latch on to for us as security and software guys. So blocks typically half a meg. When you wipe NAND everything gets set to ones. The reason everything is FFs is there's an electron in every little bucket. Then when you're actually writing data to NAND you start popping electrons off. You get a zero. So you kind of sculpt your data in NAND. But that's trapping in individual electrons is hard. The hardware wears out. It dies over time. I'm taking advantage of that. The same way that the designers of the hardware take advantage of that. What they do is they know it's going to die. They know it's going to die after 10,000 to a million rights. That little bucket. So they build in tools to gracefully fail. They have a threshold of I can detect so many bits aren't writing when I want them to. Once I go past that threshold that block is marked bad. It's never used again. The kernel doesn't see it. The driver doesn't see it. It's just there's a bit that gets flipped saying I am bad and it's never touched again. Anything that goes through the driver, the very first thing in the driver code goes is this block bad? If it's marked bad the driver just says no. It's not there. So that's handled in the bad block table which is typically stored on NAND itself. NAND actually has a table somewhere saying you can trust this block. You can't trust this block. In NAND there's two types that we see. Typically we see managed NAND which has a little embedded controller where all that logic goes. On some NAND like Sony phones that's actually built into the kernel. The kernel deals with it. For how NAND X works it's really irrelevant where that code is. The code that's open source on GitHub is attacking the raw NANDs just because it was easier to stay in kernel and everyone kind of gets that better. Raw NAND has a very complicated driver because it's got to do all this ware leveling and all this bit checking and ECC values and whatnot. Ware leveling is proprietary enclosed. We don't really care about for this. I go into way more detail in other talks so if you're interested in this deck it's also online. We're going to attack the MTD subsystem which is like this super epic massive driver for Linux that a ton of things are run through. I'll attack it again in a little bit. For NAND it manages how everything is working so we can get into that driver and start arbitrarily saying this block's bad but go ahead and let me write data to it. Go ahead and let me read from it again. Let's just make sure no one else can but me. Can we do that? Yeah, thanks. If I wanted to hide NAND in general, once you figure out blocks get marked bad and then disappear, I can do that at a shit ton of levels. I can do that with the file system but the file system then has trailing pointers and stuff to data that just got removed which is why you see that horrible crash on screen. MTD subsystems much lower, it's clean. I forget the actual number of lines of code that I had to change but it was like 30, something like that, like it was tiny. And then I've got full control. So it's an Android, it's also in Linux so any device you see that's running Linux or Linux variant or maybe pseudo based off Linux or inspired by Linux, start thinking SCADA, things like that as well. I mean, everything that's running the hardware is susceptible to this type of attack. Everything that is running software pseudo based on this code is also susceptible. When I started the project I expected full hardware, I didn't have to do that, I just had to buy a shit ton of phones. I bought a ton of phones, I started playing with them, I found one that had full MTD, like the whole NAND was basically managed by MTD. There was no Turing thing built into managed NAND. So I was like, sweet, this is really easy to code on. I created a couple of unit tests because that's what you do, right? So I created a unit test that basically just killed arbitrarily read and write, read and wrote data to a block of NAND, marked it bad, checked that nothing else could see it. And then read and write again. Yeah, so the code was ungodly simple and if you are actually interested in how I'm pulling it off, I spent more time writing notes in the source code that I checked into GitHub than I actually did the coding. I tried to just walk line by line of exactly how everything works. In a nutshell, I'm grabbing a block, I'm erasing it, writing dead beef all over it. I'm making it disappear from the system, writing dead beef again and then reading it back out just to kind of show that we've got full arbitrary control. Oh, and for the demo, then I'm doing a double release on the driver just to force a reboot of the phone because when I do that then it reads back the bad block table from NAND and the thing disappears. So the demo that I have the video for and kill block 37 just kind of arbitrarily picked that block. That's where a system or, yes, Android.settings is stored so it's no longer there. That phone is, I've got it with me if anyone wants to play with it, it's quirky. But yeah, so I can take data, it's gone from the system and yet I can still arbitrarily read and write. I took these phones after I did this, full factory reset, dead beef is still there. You know, DD didn't see dead beef, ran my tools, sell dead beef, another factory reset, you know, throw other ROMs on there, do a whole bunch of things. The phone's completely stable and it's just dead beef all over it. I've got like a quarter of the NAND that's just dead beef and nothing sees it. That's pretty fun. Since I'm running a little fast, one of the other fun things you can do with this is I'm making drives disappear half a meg at a time. And after half a meg I'm forcing a reboot but you don't have to, you can just disappear the drive under the OS, you can disappear the whole damn drive and nothing can recover that device at that point. It's just gone. When you start talking cell phones it's like, it fucking sucks, it's like it's in your box and it's inconvenient, you get pissed off. If that's SCADA, that gets scary real quick. Because it's remote, I don't care if it's remote, I mean, and it's not patchable, you can't recover because there's no drive there. The hardware goes no, dude, there's no storage space left and it's just dead, you've got to replace the device. So, yeah. So that was first. Cool. Yeah. And it's all on GitHub if you want to read about it. I've got links but it's basically my name and then NANDX. I've got a paper that goes into great ridiculous detail on how NAND works and then a bunch of source code and the presentation and I mean it's out there. There's no fix that I can see so since this is kind of an offensive for defensive type of a talk, if you can think of a way to protect against this, I'd love to hear it or really would. Because it's based off an assumption that the guys that originally sat down with pen and paper on a napkin and figured out how NAND would work, they made an assumption that it had to fail and I mean the hardware is based on that, the hardware is built on that assumption, these software on top of it's built on that assumption and there's nothing that can keep me from taking advantage of it, we can hide and we can hide deep. None of our tools can pull it out right now. Any tool that you can start kind of thinking about how I could protect against this starts failing real quick. Yeah, I can wipe everything on boot that's in a bad block table, not really. You can't validate that since blocks do go bad, how do you validate that she wipes it or not. And if I'm going to build a layer, I can just block it anyway. So that was NANDX. Second project I'm working on is clock-clocking beats. What this is looking at is like, okay, I'm hidden on disk, that's cool. I still have to run at some point. I want to be able to run and never have a user be able to tell that something's going on. I mean obviously you don't want your threads showing up and things like that, that's great, but I want to go deeper. What if I want to make sure that the kernel just has no fucking clue that anything's running? What if I want to make the kernel have no ability to even see that? So clock-clocking beats is looking at taking a running operating system and slightly tweaking the processor by overclocking it. And then outside of full kernel space like in hardware, damn near, I'm injecting a second process. It's a thread that runs outside of the kernel that I manage myself. That thread runs my kit. So no tool that you would write that's running in kernel space remotely has permission to even see me. Like I just don't exist. I can reach in but it can't reach out because it doesn't know I'm there and it has no ability to know I'm there. That project is at the very beginning and it will be on GitHub as soon as I'm done. Wow, I'm going to finish so early. Whatever. Burner, this is the really fun one. So like I said, I've got 20 million invested in whatever kit I'm shoving onto a device. I'm actively monitoring that. I know it's getting ready to get found. I know that it's going to, my phone's going to be in someone's hands that's going to do a forensic deep dive. Maybe I don't have all that much faith in NANDEX anymore. Maybe someone's figured out how to get rid of it. Maybe there's other tools. I want to make sure that nothing that I have on there gets out. So I want to set the phone on fire remotely. Why not, right? So and I want to do this all from the kernel. This project will be on GitHub probably within about a month and a half. I really wanted to demo it but I swear to God it's the lamest demo ever. It's like side load kernel module, phone turns off. That's it, right? It's hard to show it never boots again. What it does internally is I'm playing with all the voltages that run internal to the phone. So I can target specific pieces of hardware like the chip or the NAND or the baseband and just start dumping a lot of power to them and fry them. And this seems to universally work on almost every Android phone I've poked at in the run time of this project which is pretty much probably what you have in your pocket. So I can attack and kill your phone dead and make sure that it will never turn on. The only way to ever pull data off of it at that point would be to take it apart, desolder the chips and put the NAND in a reader. Maybe you can find me then, but that's it. So now we've hidden, right? I feel good that with those three projects together you're probably not going to find any code that I'm running at all. How do we combat against that? Us as users and hackers. How do we make sure that that deep just doesn't happen to us? I'm discussing everything. That's my solution. If I can think of these, someone else can. If I can open source them, hopefully at least we start talking about it. Maybe we start looking for things like this. At that point, we're at least nowhere to look for security because we're not right now at all. Maybe it'll make us work a little harder. I felt pretty good about this. I was like, yeah, I'm awesome. And that's pretty much it for me. I'm ungodly early, but I'd love questions.