 This is my first time on stage at DEF CON not rapping, so I'm a little bit nervous. This is anti-forensics AF. When I would see internet memes that were like that silly AF or that stupid AF, I would read it as like that silly anti-forensics. My name is Int 80, I'm the rapper in dual core, and this is the fourth anti-forensics talk that I've ever made. So I the other three are online, I presented it like Derby CON and stuff like that, so you can watch them on YouTube. And here's some stuff we're going to talk about today. We're going to start kind of where I left off with my previous anti-forensics talk and we'll talk about some self modifying code in memory for Windows executables. This is like coming from the context of being an operator and being on a compromise system and you have malware in place running and you're trying to prevent your malware from being acquired and analyzed. Then we'll talk about some Android stuff. So I've got some Android-forensics research that I've done with my girlfriend and then also some anti-forensics and I'll probably win the award for worst DEF CON demo ever. And then I have some stuff with SD cards but I'm having display issues with my Linux laptop so if we can't get it to work, we will, I don't know, I'll be in the vendor area afterwards so I'll be happy to show you guys some cool SD card tricks. So I currently work on a red team and I get shells in right malware for a living and I come from a reverse engineering background. So I've never done forensics professionally so you know, don't really take my word for all of this. I mean it works but I'm not a forensics professional. I've had some really interesting run-ins with law enforcement and three letter agencies and I'd be happy to talk about my trolling of certain agencies like the FBI and the NSA in some other time when I have a drink in my hand or something like that so if you want to find me after the talk, tell you some fun stories. Again, I'm not an expert. I just like to try stupid things on computers and see what happens and so your mileage may vary but I'm sure you guys are always smarter than I am and can come up with way cooler and more technical things. And then the last part is kind of a commentary on our current legal system and every cool thing I know how to do with computers is illegal and so I've learned to do cool things with computers by doing illegal things. So I highly recommend doing illegal things. All right, cool. So we've all known for the past decade or so memory forensics is the new hotness. You can get all the good stuff out of RAM and so again the context here is like you're an operator, you're an attacker, you're on a system, you've got malware running, you've got an implant, so you've got you know persistence but it's expensive to build a tool chain, right? So you don't want to get your malware caught, you don't want it to be analyzed, you don't want IOCs to be coming out about your malware, you don't want it to be detected. So the whole goal is to keep our malware running on a system and thwart either acquisition and or analysis and so in the previous talk I've done some tampering for the acquisition side and this one will look at the analysis side with a little bit of acquisition. Like I said, cool stuff happens in memory but we kind of take advantage of this, right? The analysis tools, they need all of the data about your malware in order to be successful in analyzing what you've coded and so we don't need all of those sections once we're loaded in memory so we can tamper them or remove them or whatever and therefore our execution still continues, we persist as operators on our target environment but analysts lose and can't analyze our malware and so it's great, we can basically just like I said either modify or remove bytes and the analysis tools can't do their job. So this first demo is a POC that I wrote called the keys are like right next to each other and it's kind of a throwback to the bash.org quote. It's a common typo, the keys are like right next to each other. All right, here we go. Everybody see that okay? Like text is big enough. Cool. All right, awesome. All right, so I have a malware sample that I wrote called the keys are like right next to each other so it's running. All right, we can see that it's executing, everything's good. Let's do an acquisition of memory. So I'm using recall which is an open source framework published by Google, you can grab it off of their github and first of all we're going to do is acquire memory and we're going to put it in this file called lol.aff4 and you can name it whatever you want. I just think it's funny so I should have like a how to basic video in here somewhere probably. How many people are coming to the DEF CON party tonight? Awesome. I'll be rapping at 130 headlining so I'll see y'all there. How many people have heard the song drink all the booze hack all the things. That is exactly how many album sales we have. Wow. Thank you guys. I thought Ram was supposed to be fast. How many people first year at DEF CON? Nice. Thank you for coming. How many people 24th year at DEF CON? Nice. What I do is 64 bit VM. All right. Well, while that's going, this is what the malware looks like loaded from disk. This is statically loaded. The keys are like right next to each other in IDA. You get a nice call graph. We see all the subs. We can do strings. We can see all this cool stuff. Everything looks good. There's no real complaints here. Yes. Okay. Cool. We finished our acquisition. So now let's get that malware. Again, malware is still running. All right. So this basically gives you like an IPython notebook for your workspace in recall. And it's really nice. It's basically Python and you can get tab completion. So let's dump out this binary. We don't even have to know the PID. We can just say the keys. And let's give it a dump directory. Let's put it right on the desktop. So it's dumping it out of the acquired RAM image now. Cool. And so there we go. We got it dumped. PID 4792. Here's our executable 4792. Loaded in IDA. Doesn't know what to make of it. Guesses it's an MS-DOS. Let's see what it says. That does not look the same. And so you notice it doesn't even know the segment names. These instructions don't look legit. And then we have just a bunch of bytes. So but now we're still running. All right. So what does this look like for the code? This is a C++ file. 63 lines. Not including comments. Or including comments. So all we do is resolve our way into finding the header in memory. And once we've recognized like, yep, we found our header, our executable header, we call virtual protect. So we can set the right bit for permissions on the page for the header. And then we zero out the memory with this call to RTL zero memory. It's basically just memset underneath the hood. But what you end up with is losing all of the data structure about your portable executable at that point. The whole thing is gone. We reset the permissions back with virtual protect. And just in this case, POC just loops. And that's it. So pretty simple, but BTC analysis tools. So our malware persist hasn't been analyzed. You could go through here and try to like, you know, hit C in IDA and see if you can figure out like, is this code? Is this code? It's not data. Is it code? And maybe get some disassembly of the instructions, but it's going to be a pain in the butt. And I also don't know any forensics investigators that even have IDA installed to begin with. So I don't know. I'm hedging my bets. My threat model looks like that. Let's see. I can actually show you guys the hex editor too. This is what it looks like in the hex editor. So much zeros. Whereas the original in the hex editor looks like a normal Windows executable file. So pretty neat. But if you want to take this further, you could do some interesting things to throw off the analysis tools, right? Like two of my friends, Richard Wartell from Palo Alto Networks and Craig Smith from Open Garage has independently suggested to me like rewriting a new PE header. So I don't know if you guys have ever seen something like tiny PE where you could write like a new executable into like part of the memory space and you know, might throw the analyst off by a lot. They'd be like, oh, it's just tiny PE, even though it's, you know, a 10K file or something like that. You can do other things like modify values in the header and you get some interesting results, aka crashes with analysis tools if any of you are so inclined to research that particular vector. All right. Any questions on what we did with the keys or like right next to each other for Windows? So the whole reason this works is in order to get from on disk to in memory, you need your PE header so you can load and navigate all the data structures and get everything loaded. But once we're in memory, we don't need the PE header anymore, right? We don't need to reference back into there, into that section. Our code is executing, we're good to go. So in this case we just zero the memory and we're still running. We don't need to reference the section header, but the analysis tools failed. And so in the previous anti-forensics talk, I demoed this in Windows XP before it was end of life and here I demoed it in Windows 10. It still works. For completeness, in case you guys want to take pictures of the slides or anything like that, I mean I guess they're on the CD2, but I don't know anybody that has a CD drive by dual core CDs. This is what we ran. All right. So then the next question is, well, will it run in Linux? Usually the question is will it run Linux, but it's an Intel chip, so it'll run Linux. All right, cool. So here I've got Linux port of the code. The keys are like right next to each other. We're running. This is just some debugging output. All right, cool. So let's get RAM in Linux. Sorry, I made this talk a bit ago and I'm really forgetful because contact switching, so I have all my notes here. So to acquire RAM in Linux, in Windows we use Recall. We're going to use LIME, which is an open source tool published by the 504N6 guys. You can grab this off of GitHub as well. And once you build it, it shows up as a kernel module. So in this case, it's this LIME generic-ko, which matches the version number of your Linux kernel. We'll specify a path to dump it out to. So great, all we're doing is just loading this kernel module and it's going to acquire RAM for us. Are you kidding me? Oh, maybe I didn't build it. All right, let's build it. I really didn't know what was going to happen there. All right, that one worked. All right, so great, we have a memory acquisition. Let's check it out with volatility. Oh God, I hope this works too. So this is a Volatility is by the Volatility Foundation, open source framework written in Python, does a lot of cool stuff. One thing I'll go over with more verbosity in the slides is building volatility for your Linux setup. It by default, it doesn't come ready to run on Linux, but it's pretty straightforward to get it to get it going. So let's take a look at our memory acquisition here. All right, first, let's find our PID. These are all just modules that weren't installed. Oh God. Oh, there it is. All right, 9801. And just to confirm, yep, we're still still running, still doing evil stuff. It's false advertising, by the way, it's just printing. Okay, so looks looks like it dumped, right? Outside of the modules that it tried to load. Everything else is fine, no complaints, right? We're good to go. 400,000 hex looks like a solid base address for standard Linux image. So let's take a look. There it is. Okay, cool. So here's our process dumped out of memory. Oh, that's weird, it's empty. Sweet. We won. Zero file size. They couldn't, forensics investigator can't get our malware out of memory. Good job, us. Let's take a look at what this one looks like. So it's pretty much the same thing, a little extra debugging output. This code right here, line 16 through 20, is bad and I should feel bad. I'm literally like taking a shortcut to, I'm using fscanf and reading out of the proc maps to find the header in memory. There's probably an actual legit way to do this, but I'm lazy and this worked, so. Cool, so we find the header just like we did in the Windows version. In this case, instead of virtual protect, we call improtect. Again, setting permissions for both read write, all three, read write and execute. Then we call memset, zero out the header in memory, and call improtect again to restore the original permissions. So if you caught this right at the moment that the overwrite was happening, it might look weird seeing the header with all three read write execute permissions, but if you catch it afterwards, which you will maybe, then you'll see it look like normal with only read and execute. And then this is just more debug output, and here we go, just infinitely looping, doing evil stuff. So that's all it takes. Hack the planet. Cool. So, you know, we did get an acquisition with Lyme. We didn't tamper the acquisition too much, but we ended up not being able to extract the actual binary with volatility. So good job. This works for the same reason that the Windows 1 works. We don't need the executable header, right? So Windows uses portable executable or PE, and Linux uses ELF, which I don't know what it stands for, but who cares. And we do the same thing, we zero the header. And since we don't need it once we're in memory, it continues to run, but the analysis tools fail. So this was my win on the fly. I've successfully built Lyme with a make command. Good job, me. The real bread and butter here is the insmod, so inserting the kernel module and pointing it out to the output path and giving it the format. And this is the volatility stuff, so if you want to install it straight out of their GitHub, just do a git clone. Python setup.py install, pretty normal. Although I always forget that if I don't do it, like if I always use PIP for a while and I'm like, wait, how do I do this manually? That's why I put that line in there. And then this is building the Linux profile. Like I said, volatility out of the box is not going to work on a Linux VM or a Linux system, so you need to build a profile for the actual system that you're going to be acquiring the RAM from. So you'll go into this tools Linux subdirectory in the volatility directory, run make, and then it'll create this module.door file. And if you run head on it, the first line you should see should be .debuginfo, and that'll tell you that you did a good job. And I think all of this is in their GitHub anyways. And then once you've built the module.door file, you copy it into the volatility file system where it wants it, and then you can verify that you've got it by running that first volatility command that I ran and grepping for Linux, and that'll tell you that you've got a profile for Linux now. Then we did PSList to find our process ID, and then we did procdump, and that tries to dump the image of our malware and fails. Alright, Android stuff. Before I get started on the Android stuff, I will say that none of this addresses any of the Qualcomm trust zone issues, or like the deriving the hardware encryption key from that. The premise is in my threat model, I'm not going up against somebody that, or the people that I might be going up against don't care about me enough that they're going to send my Android device off to Israel for cracking. Alright, cool. So I also use Tor, use signal for those that follow the gruck on Twitter. I'm planning Thanksgiving, use Tor, use signal. I like that one because I'm allergic to nuts, my true merit credibility. The retweet in here is, I want to eat a pint of Jerry Garcia ice cream. Should I use a bowl or not? Use Tor, use signal. This one is selling social security numbers for Bitcoin. Please contact me on my XMPP and we'll discuss further. Use Tor, use signal. Okay, I'm really sorry, I'm just going to say it. I've had like this research for a while and really the only reason I made this talk is about the format for screaming goats in slide transitions was hilarious, so I'm so sorry to everybody. Okay, so this whole premise of Android stuff is all about using encryption, right? And so to understand why using encryption is so important for your Android device, we're going to talk about the acquisition and analysis process of Android forensics first. TLDR it sucks. Okay, so Android forensics is not the easiest thing. Anybody here done Android forensics? A few people? Nice. Alright, so this is the way that my girlfriend and I figured out how to do it. If you've got like flashy hardware and budget and stuff like that, it's probably way easier, but you have all these blockers in place that you need to work in order for your kill chain to be successful. So if you want RAM, you have to be running an Android kernel or a Linux kernel that allows loadable kernel modules, because you can use Lime to acquire RAM on Android as well. But all of the Android devices I looked at, none of them have a kernel that allows loadable kernel modules, which I mean is good. For my personal usage, I wouldn't want that, right? So you're probably going to lose at memory forensics right off the bat. The way we did acquisition was by cross compiling Netcat for ARM and then placing it onto the device, which already if you do traditional forensics, you're only read-only, right? Your method is read-only. And so you're already writing on to the device that you're going to be doing read-only from. And then there's a bunch of different interfaces that get exposed based on your build of Android. So in order for successful acquisition of RAM, you need the device to be powered on, the device to be decrypted, unlocked, rooted, and USB debugging. That's if you want a full physical acquisition of the NAND storage. So guess what? If you're encrypted, then you already killed them at the second step. And then if you want RAM acquisition, you need the loadable kernel modules. Okay, so this is like kind of the verbose like notes on doing Android forensics. Once you've attached your device to your acquisition machine, you can run ADB devices and that'll show you a list of Android devices that are attached. Then once you've got your cross-compiled Netcat binary, you push it up onto the Android device. So that's just ADB push. And then you set up a listener. This is like the weirdest thing I've ever seen in forensics. So you're forwarding all of the acquired data over a TCP listener on, in this case, port 4444. And if you're playing a drinking game and you had to drink on the word 4, you'd be in a lot of trouble right there. Then you spawn a shell, call SU. That's the part of the device being rooted. Copy the Netcat binary over into DevNC and change mode it for executable bits. And then you do a DD. And we're all familiar with DD, so that's fine. Nothing crazy there. But you pipe it into Netcat over your listener and then you acquire it over the Netcat connection. It's all USB, right? It's not like going out over the air or anything like that. It just seems like such a weird setup. And then a Shot 256 on it and make a backup copy and Shot 256 on the backup copy. Goat simulator. Okay, so one of the weird things that I found, my girlfriend and I found during our research on Android forensics was you'll find the NAND exposed by different interfaces. So if you look in PROC partitions that'll tell you where you can acquire from. But I've seen it under these ones that are listed. DevBlock, MMC Block, DevMTD, MTD, DevMTD Block, DevEMMC. And then I thought I was being clever there with that C++. No comment. Dad jokes. That's if you want physical acquisition. If you want logical acquisition it's way easier, right? You don't need root necessarily. You can just plug the device up. You'll need USB debugging enabled, but you can just do an ADB pull. There's like a bunch of facilities that are available via ADB and the Android SDK that you can acquire data off of a target Android device. I thought the ADB backup one was kind of interesting because it creates this like jar file and you have to put a pin in for it. If there's like a pin on the device I think and that then exposes your pin in the bash history if you were maybe targeting the forensic investigator. I don't know. More stuff, dump state, like all of these things get you different pieces of data about the device like radio history, location history, stuff like that. There's also a tool out there called AF Logical OSC and it's an open source edition. It's pretty nice can get you a good acquisition of data as well. I think there's a law enforcement edition so if you wanted to impersonate a law officer you could try to get a copy of that or be a law enforcement officer. Didn't even think about that second part. So yeah, so basically like you know it takes all that stuff just to get an acquisition that sucks and you know you're writing a netcat binary onto the device. You have to be able to justify all the changes that have happened to the device so it's you're violating the traditional forensics methodology. And yeah all this stuff is easy to disrupt right. We got that super long kill chain. If the device powers off it's over. If it's encrypted it's over. If USB debugging is not enabled and you can't get it unlocked it's over. It's not even a goat. Alright so use encryption right and here's some like example scenarios that I thought were applicable. So number one if you're out operating and your or your freedom fighting is the grout calls it. You're not going to bring your personal phone with you. You're not going to bring your personal device right. So you leave it at home. But what if you're out freedom fighting and you get rated by law enforcement while you're out. You don't want them to acquire all the evidence off of your device. Also like I may or may not know people that build hardware implants for Android devices and deploy them while operating. And so you know if your implant gets found by a blue team or somebody else that's not meant to find it. You don't want them to acquire whatever evidence you've acquired while operating. And then how many people here knows no cause. So cause has a penchant for smashing cell phones and initially I put this in as a shrug but when I looked at it in the context of Android it looks like an ASCII cause throwing a cell phone on the ground. Alright cool. So my thought was if I'm leaving an Android device somewhere and it's got full disc encryption and it's running and it gets acquired by somebody that I don't want to acquire it. All I really need to do is just turn off the device. It's powered off, everything's encrypted at rest, I win, kill chain's broken, friends and confessors here get nothing. And then of course lawyer up and that's after you've deleted Facebook and hit the gym. Oh before actually lawyer up first. Okay cool. So you have all these like awesome sensors available to you in your Android device right. You've got Bluetooth cellular etc. So my thought was you know you could pair to a Bluetooth device in your house and if it all of a sudden the device becomes unpaired turn the phone off now it's encrypted right so FBI comes they put your device in a Faraday bag you become unpaired or you go off the cell network right turn the phone off encrypted. It said a geofence if it wanders outside of the geofence using the GPS turn it off must have walked away on its own. So yeah so I'm just leveraging the facilities available to me in the Android device. So I wrote this tool called duck the police and it's just an Android app and I suck at programming as you could probably tell from the other source code so it's not it's not amazing but it does turn the phone off. So yeah so here's my entry for the worst DEF CON demo ever so you'll just kind of have to take my word for it. So I've got my duck the police app here with a Dolan icon and I select movement and I duck the police there we go and set my phone down and I pick it up and it's off and it's encrypted now. So now law enforcement gets no evidence off of my device. That was the easiest solution I could come up with and like right at the top of my coding capacity and this was the only meme I could find that said duck the police on it and these were my next best ones. That one I love because a former co-worker of mine he was like oh yeah you know like I can pick the boots on cars I can pick the lock on those. He's like the police charge 125 dollars to take them off. I charge 75. So much chaos on the internet. So yeah so that's uh that's like my android uh android stuff and uh again like those are my my ideas for scenarios but the device turns off and now all of your evidence is encrypted and again not taking into consideration the trust zone and trust Qualcomm trust zone stuff. Alright so I was going to play CTF with you guys um but unfortunately I demo gods are not with me on the display for my Linux laptop so I'm happy to demo this. I'm going to be uh I'm bending with hack 5. They're the bros in the vendor area that have the huge pineapple so if you want to come by or find me some other time during the conference um I can show you this in person but uh basically this is like some cool stuff that uh Craig Smith from OpenGrad just put me onto with SD cards and this was to prevent me from going too far in the slides before showing the answers. But basically the CTF setup is I have an SD card in my laptop and it's got a text file on it and you cat the text file and it says the rules are simple just add your name unmount the text or unmount the SD card uh remove it from the laptop plug it back in and verify that your name is still there and what ends up happening is uh you you can you know mount the SD card write append on to the um text file you mount it no complaints at all you remove the SD card you put it back in your name is not there and so the CTF is like we go back and forth like what would you try like people are like try like change mode zero zero zero zero you know like all zeros no no read no execute bits that doesn't work try change attribute you know make it plus a or plus i that doesn't work um and so what it is actually uh modification uh in working with the firmware on the SD card so there's an open source tool called SD tool and um what it can do is lock and unlock the device and this is aside from the physical lock that's on the device and so the rights all happen in memory so to the underlying OS everything looks good everything's fine but then below that the firmware uh to the SD card is not preventing or is preventing or not allowing the rights onto the actual storage so as we all say no logs no crime and so it's um it's it's pretty neat uh there's a couple caveats uh so like if you've got like a USB hub it may not work it might expose it as like um like a mass storage device uh but if you have a direct MMC device it should work you might need to go through different SD card um cages but one of them should work uh and the example scenario is where I thought this would be good also like building your own hardware implants using running off of uh an SD card uh anybody that's done like portal of pie or anything similar to that um you can do the same since it's a Raspberry Pi running off an SD card and if you make your like attack infrastructure attack VMs running off of SD cards none of your logs get written to the storage that's kind of neat. I still don't know what this what is that. How many people have seen this ladder goat? This is how you use SD tool um uh you just basically once you build it uh point it at the um MMC device and then you can get the status or lock in unlock it uh quick note I switch my make file to use Klang instead of uh GCC built uh GCC gave me errors but Klang was able to build okay.