 Okay, so let's get started. This talk is covert debugging. My name is Danny Quest. I'm a co-founder of Offensive Computing, a PhD student at New Mexico Tech. I do reverse engineering, exploit development, and a member of the CDC NSF. Hey, how's it going? I'm Val Smith. I'm also a co-founder of Offensive Computing. I do malware analysis and reverse engineering, a contributor to the Metasploit project. We're giving a talk later. Also do penetration testing, exploit development, and member of CDC NSF. So just real quick, tell you in case you don't know what Offensive Computing is, is we're an online malware analysis website. We have a blog where we post analysis about the latest threats. We have, as far as we know, the largest openly available malware collection on the internet, about 160,000 samples that you can go download. We provide a couple of services. If anybody is curious about that, we do custom malware analysis, reverse engineering, malware intelligence gathering type stuff. Okay, so this talk is about debugging software, and it's specifically about debugging malware, because it's a powerful tool. It's the main way that you unpack or expose the internals of the malware. And so the goal is to trace runtime performance, monitor API calls, and basically get to the dynamic analysis, because that means we can get automation. But malware is getting real good at preventing it. Val will talk a little bit about some of the methods, just at a overview level. But basically they detect whether they're being debugged. They detect whether they're in a virtual machine. And these are all techniques that were pioneered by legitimate software. So the talk is going to go like this. We're going to talk about software armoring or packing techniques. We're going to talk about some of the covert debugging requirements. We'll present a one solution for removing software armoring, which is dynamic instrumentation. And then we'll show our OS page fault-assisted covert debugger. And then as an application of all this, we'll apply it and make a generic unpacker and show you the results. Okay, so I'm going to go over the different techniques that software uses to protect itself from being analyzed. We like to call it software armoring. And this is going to be kind of a high-level generic talk about this, and then we'll dig down as we go and show some demos. So these are the main techniques that you commonly see, both legitimate software and malware using to protect itself from being reverse engineered. The first most common is called packing or encryption. This is where they obfuscate the binary. We'll go into detail on each one. There's SEH tricks, virtual machine detection, debugger detection, and something called shifting decode frame. Okay, so basically the way that the packing or encoding of a binary works is that they take the original piece of malware with the normal code where you can see all the assembly instructions and they pack it or encode it so that when you load it up into Ida Pro or whatever tool you use for disassembling, it's basically gibberish. The reasons for doing this is to make it small, make it hard to analyze that kind of thing. So inside of there, there's usually a small decoder stub that knows it's a set of assembly instructions that knows how to de-obfuscate the binary and then execute it. They play all kinds of tricks with portable executables, which is the Windows file format, to keep you from analyzing them, such as hiding the import table, obscuring the relocations, encrypting, compressing different parts, and we'll show a little bit about those things. So as you can see up there, that's sort of what a normal portable executable file looks like. To the right, you can see clear assembly instructions that make sense, API calls, that sort of thing. This is what a packed or obfuscated binary would look like. It's basically nonsense. You can't tell anything with a small stub of instructions that start to say, this is how you decode this. So our goal is to get to the decoded part of the binary. Okay, the next technique that malware uses to protect itself is called virtual machine detection, and we gave a talk about this at DEF CON last year. There's a whole bunch of ways to do this and lots of great tools. We kind of like the single instruction detection method. This is using various descriptor tables to figure out that you're running in a virtual machine. Joanna Rukowska released a great tool called Red Pill. They're Scoopy-Doo, and then the tool we released last year called OCVM detect. So basically, virtual machines try to be efficient and fast and work well, but they don't necessarily try to be secure or stealthy. They're not root kids. They're just virtual machines. So they don't fully emulate all the bugs. There's ways to find signatures that you're being virtualized. Okay, another common thing that packers like to do is called debugger detection. Generally, when you're analyzing a piece of software, you're going to run it in debugger and step through and see what's happening. The easiest way to detect that you're being debugged, there's a Windows API call called is debugger present. This checks the process execution blot for a magic bit that says, hey, I'm being debugged. This is easy to hide from. Oli debug has a plug-in that does it. So you can basically say, no, I'm not debugging you. And a lot of pieces of malware will take that and believe it. One of the better ways to detect that you're being debugged is a timing attack. Basically, you issue the RDTSC instruction and see, am I executing very slowly? When you're running in debugger, it's thousands and thousand times slower than just running normally. So this is a good way to detect you're being debugged, and it's pretty effective and hard to get around. Okay, so there's a few other methods. A good one is called breakpoint detection. This is where you scan for int three instructions. Generally, debugger is going to issue lots of breakpoints so that you can analyze at each point what's going on. Another thing they do is called check something. This is where they check to see, has my executable been modified? Are they basically trying to crack me or see what's going on? There's even the hardware debugging detection. There's CPU flags you can look at and say, oh, yeah, I'm in the middle of being debugged right now. People used to use a tool called softice, which has been discontinued. And it was pretty good for doing debugging of software, but there's a lot of different ways to detect it. There's a bounce checker signature that was pretty good. Okay, so this is sort of related to packing and unpacking. Some malware uses the structured exception handler. Basically what this is is the malware will issue some sort of error, like a divide by zero or something else that gets passed to the structured exception handler, which says, okay, what handler takes care of this error? Well, in the case of malware, the handler is the actual unpacking instructions. This makes it hard to debug or figure out because debuggers say, oh, there's an error. What do I do now? And they crash or they stop debugging. There's ways to get around that too. And we'll talk about some of those later. But it's a pretty good method for unpacking in a complex way. Shifting decode frame is one of the hardest things to deal with with obfuscated malware. Basically, this is where each little block of instructions is encoded. And then at runtime, it's decoded, executed, reencoded, and the next block comes and gets decoded. This means that it's very unlikely or unusual for you to have the entire binary sitting in memory clear text decoded. This is very hard to defeat. And some people are actually implementing it for legitimate uses like protecting themselves, patch guard, that sort of thing. The main thing, though, is that if it executes, it can be unpacked. At some point, the processor needs to execute valid code, not gibberish. And so if you can observe that, you can unpack it. Okay, so now I'm going to go into manual unpacking. This is the process for deofuscating these binaries. So basically the way an unpacker works, I described a little bit before. There's a right to an area of memory, this is the decode, that area is then executed. And then there's more rights to memory, sometimes reencoding optionally or other things. Since the processor can only execute machine code, you can monitor this unpacking process and get to the instructions after they've been decoded. Unpacking is basically a function of timing. If you can get there at the right time when everything's deofuscated, you can tell what's going on, you can dump it to a file. At some point, it has to be unpacked before it executes. So there's several stages to unpacking malware. So I'm going to go through each one briefly. The first one is you typically want to identify what type of packer is being used. Sometimes you can't because there's custom packers or targeted packers that are used, but most of the times the first step you take. The next part and generally one of the harder parts is finding what's called the original entry point. This is the address at which the original binary executes. So when it's packed, there's an entry point for the packer and then eventually gets to the original entry point of the original binary. Once you've got the entry point, you typically dump the process memory to a file and then fix up any problems with the file, make sure it's in the right format, fix the import address table, and then you should be able to analyze it at this point. Okay, so for the first stage, there's a whole bunch of different tools for identifying what type of packer. The probably the most common is called PID, and it's a little GUI tool that uses signature-based scanning of files. It has a huge database of packers and it can tell generally what a file is packed with. The next is called MSFP Scan. This comes as part of the Metasploit framework, and it was modified like last year to do packer identification similar to PID. Eric Herrera wrote a great tool called PE file, which Danny's contributed a lot of code to to make it hardened against malware. So if you get a chance, check that tool out as well. A couple of things you can do is you can actually manually look at in IDA and the disassembly look at section names and things like that. And there's often a hint, like it might say UPEX in there or something like that. And there's a bunch of other scanners, but the first ones are pretty much the most commonly used. So this screen shows you kind of what it looks like. These are various tools for showing how to detect what packer is being used. On the bottom black window is MSFP Scan. There's PID, our website. Okay, the next stage of unpacking is finding the original entry point, probably the most difficult stage. There's a bunch of great scripts for AliDebug to do this for a lot of different packers, but these are very specific to packer type, packer version. When new versions come out, these scripts don't work. OpenRCE is probably one of the best repositories for reverse engineering scripts. So definitely check that out. There's a lot of other tools, but again, they're signature based. They're not generic. They're GUI tools hard to automate. So that's why we started to work on what we'll talk about later. So this sort of shows the process of finding the original entry point. Up there at the top, you can see in green a little address highlighted. That's the original entry point in this particular case. So once you've identified the entry point, then you're going to dump the process memory of the process you're trying to get to a file. There's a lot of tools for this. AliDump is a plug-in for AliDebug, LordPE, and you can write your own. That's what we've done. This is basically the flow though. These four API calls will get you what you need to dump the file. Basically open process, reprocess memory. It's pretty simple. This is a screenshot of LordPE dumping a particular process to a file. Okay. One of the final stages is fixing up any problems with the file format, rebuilding the import address table. It turns out it's not a hard problem, but it's a tedious problem. So there's not very many tools that do it. The main tool is called import rec. And it's a GUI tool, not very automatable, but it's probably the best tool out there. You can also do this by hand with a hex editor, but I wouldn't recommend it take days. So this is a screenshot of import rec and another tool called Reversion, trying to rebuild the import table on a particular file. Okay. So at this point, once you've got the OEP, dump the file, you should have clean disassembly, something that you can analyze in Ida Pro and see what's going on. There should be internal functions, visible strings that make sense unless they've done other encoding afterwards. This process is pretty manual. It can take, you know, like an average of four hours or so per file. And if you have 100,000 files you have to unpack, you're never going to get done. The hardest part is generally finding the original entry point. Once file is unpacked, this is basically kind of what it'll look like. All kinds of stuff visible, lots of information. We're going to show a quick demo. Okay, so this demo is basically manually unpacking a file that's been packed with UPEX. First thing we're going to do is identify what packer it is. This tool, PID, you can see down there, it shows UPEX 0.89. And I'm going to prove it's actually a valid file. So I execute it, open support. This is a real piece of malware. It's a backdoor called NetBull. Then the next thing we're going to do is open it Ida Pro so you can see how broken the analysis is because of the packer. So Ida Pro is going to start to analyze it. It gave us a few errors. You can see the names window is basically empty. It says start, but there's not a lot of information there. There's no internal functions available at all. The import table is pretty sparse. Generally, this has got 100 things in it or more. So usually the next thing you would do is put the file into OliDebug and load a OEP finding script. That's exactly what we're going to do here. OliDebug even detected that something wasn't right. It was packed. So we have this script called OEP Finder for UPEX. We run that. And you can see the top address there, 40BB08, is the original entry point. So we're going to go ahead and dump this process to a file. So we can try to analyze it. LoadPE is really nice for doing this. But it's kind of manual. You can see lots of windows, lots of stuff to click through. You can't really automate this. So dump.exe is the name of the file that we dumped. I want to go ahead and rebuild the imports table. So import rec is going through scanning the file, trying to see what DLLs are imported, what functions are being used from the DLLs. You can kind of see that stuff scrolling by there, like socket, send, et cetera. So we tell import rec to fix the file. And now we're going to open the dumped, repaired file in IdaPro and you should see a totally different view. So it's beginning to analyze our file. Blue up there at the top is good. That means it's actually finding good code. So there are the imports tables fully populated. You can see registry key modifications. It can create files. Names, windows populated. There's a bunch of internal functions available. And here's assembly instructions that make sense. So this is a lot different than the original view when it was packed. There's a lot more information we can find there. So that's the tedious manual process of manually unpacking software. And one second here. So what? You know, people know how to manually unpack software and we need to basically automate this method. It takes a lot of work to go through this process. And if you've got a malware collection of a significant size, you're going to need a lot, a lot of time and a lot of patience, which you know, it's hard to come by. So the unpacking, this is a very automatable process. And we need a generic way to debug it need a way to modify this process at a fundamental level. Furthermore, we wanted to work generically across all executables and all packed binaries. We want it to be efficient so that we don't have to spend a lot of computing time doing this. We'd like to be as undetectable as we can. And we should make it so that it's extensible and it can be automated fairly easily. So again, the algorithm that's that's been stated in many papers is that you can track written memory. If you see any execution inside of that written memory, there's a good chance that it's unpacked because the unpacker has to modify the code and then execute it. So the two things we have to monitor for are memory rights and executes. And then again, we want to automate this. The first example of a good way to do this is dynamic instrumentation. And specifically Intel's pin library. This is a real good dynamic instrumentation library. It uses just in time a compiler to insert code before instructions. Pin retains the consistency of the executable. So when it goes to look at itself and inspect to see if anything's been modified, it can see if there's been any changes to it. And pin allows that to go through. And it gives you good control of execution. You can do it at the instruction level. You can do it based on a memory read memory write or any other memory access and at the basic block level. The nice thing about pin is it allows you to attach and detach at will and still keep the program running. So this is what normal instructions look like. This is just assembly. Pin inserts itself before each instruction provided you tell it to insert your callbacks before each instruction is executed. And the end up executable looks like this is that you have an instruction, you have the pin instructions, and then you can look at this. So it allows you to take a look at both the instructions, the memory, and all this. So what we did is that we used the pin hooks or the API to watch for memory writes and executes. And then we just tracked the writes inside of a hash table. And the simple heuristic we use is that if we see an execution on one of those written pages, then we dump. And it turns out this is pretty successful. So for the most common packers, that is 70% of them, this works pretty well. What it doesn't work on are packers that self verify. This is a highly scientific sampling of the known malware, which is what we have. And this, this is the top packers that that we see. Primarily, we see UPX as a packer, which we which this dynamic instrumentation method is able to get through P compact is a close second armadillo. We'll ignore that one till the second technique, because this doesn't work on that. But FSG AS pack and AS protect, those all work. So what we get is really good results on these foreign packers. And just just to validate the results, we created a simple Hello World application, probably same one, everybody's written, and then graph the results on the basic block using a program called GDE or Go Visual Diagram Editor by or AS. So this chart here, each of these blocks represents a basic block inside of the executable. And every connection represents a transition from one basic block to another. So you can probably guess that this is Windows because it's a lot bigger than you would expect. But what we're looking for here is an unpacking loop, we're looking for lots of or a tightly coupled loop referencing itself and in a pretty tightly bound area. So the thing that with the most connections, it's visible here in the Hello World is on the lower right hand corner. And if we zoom in on this view, we can see that there's actually good execution in here. And it's pretty unreadable. But inside of each one of those boxes is a listing of the address that's been executed. And manually verifying it, you can go and look at this in Oli. And it's actually the unpacking loop. So the generic algorithm that we described previously works pretty well. And again, we have verified everything manually by manually unpacking it before we threw it at a lot of malware. All the addresses display clustering, which you can you could see on that previous graph. And what's nice about PIN is that you get the attach and detach so that you can take a snapshot of an executable get out of its way and that sort of thing. So you could actually get around some of the other methods or the obfuscation methods. Okay, so Val's going to show you a demo of the dynamic instrumentation version. All right. So what we're going to do is unpack some malware. Okay, so we're going to go through the same steps just to show you that we're being honest here. This one's packed with a packer called FSG. It's also a real piece of malware, same one, Netball. It actually executes and open support does what it's supposed to do. We're going to go ahead and make sure that it's not running and that I've killed it. I'm going to open it up in IDIS so you can see how messed up the analysis is. So I had to give us a little error there. You look same, basically, same stuff as UPEX. The names windows empty, there's no functions for us to look at. Imports are going to be all pretty much gone. So this file, as far as analysis goes, is useless to us. So we need to unpack it. So we're going to fire up our tool here, run it against the FSG packed Netball that's going to run. And right now what it's doing is it's detecting memory reads, writes, executes and dumping files for us. And second, you should see, yeah, there's a bunch of dump files up here. Each file is named with what we call the candidate OEP address. We're working on automating the import table rebuilding. We just ran out of time, but we'll have that soon. But for now I'm going to go ahead and rebuild it with import rec just to show that it's memories all in the right place. Everything's good. So we're going to pick this dump file right here of FSG and turns out it's the same original entry point as we found earlier with the Ali debug script. So that's one way to validate our results. We know we're actually finding the true original entry point. So repair that dump file. We're going to open up the dynamic instrumentation dump file that we created. And we'll get a totally different view. The nice thing is that now there's a command line tool for doing this that you can script, automate, pass it a bunch of files. So you can see already right away, you know, the names windows fully populated. There's going to be valid assembly instructions. And this is a memory dump, sort of like what you do with Lord PE. So in here's a bunch of internal functions to the file. Imports window, same stuff basically as we saw before, except it's a much more automated technique for doing this. And you can see here valid assembly instructions, all kinds of interesting stuff. And yeah, it is graphing. So one way to tell how good your unpack is is if you can actually follow across references. And it turns out we can. So we've got a very good unpacked dump of this file. And there's some strings that are actually here. English readable makes sense. Where as previously they were basically garbage. So it turns out the first technique is pretty good at unpacking these things. Back to Danny. There are some problems with it. First of all, using pins, since it puts itself inside the process's memory, it's extremely detectable. If a packer actually goes and does a memory check some like Armadillo or T-lock do, it'll find it. So there's some more work that needs to be done. The first one is we need to extend this to a method that's generic and not detectable. Pin is currently extremely slow. It's about a thousand times slower than native at best. And other tools, if you do any sort of other analysis, could be even slower. So we need to find a faster implementation. So we need some core operating system component that monitors all the memory, intercepts all memory accesses, is fast, and facilitates logging, and is a fundamental part of the OS that the packer expects to be there. So to do that, we overload the memory management unit. And so this is kind of going to go into an OS 101 or how virtual memory works to explain the process a bit. So the Intel memory management has a system where each process has its own dedicated memory. And each address must be translated from virtual memory to an actual physical address, which corresponds to addresses inside of a stick of RAM. And non-physical address extension 32-bit processors use a two-page index and a byte index. And each process has its own page directory. So if we go through a translation, we start off with our own virtual address and the CPU will divide that up by its virtual page number. The very first 10 bits are going to be the page directory index. And that's going to be used in conjunction with the CR3 register to find the page directory. That's then used to find the page table entry and the page table index. And inside that page table entry, you're going to find supervisor bits, control bits, and that sort of thing. So that's where we're going to unload it. And then at the very end, the byte index is going to find the actual address inside of the page that's desired. So all the page directory and page table information is a hardware-defined data structure. And that all contains things like permissions. So for instance, you don't want kernel code to be able to, I'm sorry, you don't want user code to be able to access kernel code. You also need to know whether the particular bit of memory has been paged to a disk. And it also, there's also user-defined bits, which is how the US, how Microsoft implements demand paging. So this is somewhat of a difficult or a time intensive process. So what Intel has done is they've implemented a TLB or a translation look-aside buffer. And its whole process is to do these translations and then once it's translated to keep it into an associative cache. And whenever there's a page fault, like say for instance, the page isn't loaded into RAM or there are incorrect privileges or there's demand paging, then that'll actually hit that. So, and these are all indicated by special fields in there. Intel further optimizes memory look-ups into two domains. The first one is data. So if you're referencing inside of a data structure or referencing an array, that'll hit the data TLB. Instructions, actual executions hit the instruction TLB. And the instruction TLB is a little bit more optimized because less look-ups, that means faster code. And when it comes down to it, the DTLB is access less. So to load addresses into the DTLB, you simply reference memory. So that top instruction, the same thing as dereferencing a pointer in C. Instruction TLB, the way you can manually load this is take the address that you want to execute, just swap it out with a RET instruction, which is a 0xC3, call it, return, and then restore it. And that'll manually load the TLB. So when you actually get a memory look-up, the first thing that happens is that the hardware determines whether it's present in the cache, and if it is, then it just returns it. If it's not there, then the hardware actually goes through the process of walking the page directory. And once it finds it in there, it looks and see if the page table is valid. If it's not, then it swaps over to the operating system on the page fault handler. So if it's page to disk, it retrieves it, and then the next thing that it looks at is, are the permissions correct? And this permission checking portion of the page fault handler is what we use for our own purposes. So we came with this tool named Saffron. If there's any Firefly fans in the audience, that's where it came from. So what Saffron is, is it's a Intel pin and the hybrid page fault handler. It was inspired by Ollie Bone by Joe Stewart. This is really great work. We saw it at DefCon last year and started looking at this. So Joe, if you're out there, thank you. Of course it's designed for 32-bit Intel CPUs, and we replaced the Windows trap handler and log memory accesses. There was some previous work on this. Jamie Butler and Sherry Sparks wrote the Shadowwalker root kit, which is actually used to hide memory access or our root kits inside of the kernel. PAX actually implements non-executable frames inside of the page fault handler. It's another good work, but that's for Linux. Again, Ollie Bone by Joe Stewart. This is a break on execute for identifying these things. This is real good. And Memolize recently came out in Uninformed by Scape, and this is used for tracing memory accesses, and all uses a similar technique. So our implementation is we find the interrupt descriptor table and change out the page fault handler, and saffron, we slip that in there, and then just monitor to make sure that we're looking at the right memory. If we find something that's interesting to us, we log it and hand it off to the saffron monitor process. And the executable that's packed is in its own set of memory, and we don't have any direct hooks inside of it, so it allows us to keep it untainted of our code. Again, we overload the supervisor bit. We mark the supervisor bit on every valid page table entry, and then invalidate it so that we can actually get good lookups inside of it. Finding the memory can be a little interesting. The Ollie Bone method was to tag the areas of memory yourself, but we've actually automated this process. We do two things. We scroll through all available memory and tag it. We also look at the portable executable header and find what the executable wants to load so that we can get that information out as well. So once the trap to the page fault handler occurs, we determine if we're interested in it. We unset the supervisor bit to allow the process to load memory into the TLB, and then we reset it afterwards. So this, we need to modify the auto-impacker that we had before, and essentially the change that we make is that we look for written pages and then monitor for executions into that page. And so each execution that incurs inside of one of those written pages is marked as our original entry point. Once we find that, we dump the memory of the process. So what we see are reads, writes, and executes. We can actually control the execution of the program because it's essentially stopped while the page fault handler servicing it. And all of these are extremely apparent. But the thing is you only get executions for a certain page. The upside of this is that you get very accurate and very fast, very fast results. So we'll go ahead and show a demo of this here. So what we're going to do is look at TLock, which is a particularly annoying piece of malware here. So what we're going to do is load this into PEID, show you that it's actually TLock, and then we'll load the UPX version too. And what we're going to do with the UPX version is use that to just show that we can find the OEP on a different version of this. So we load that up. We load the Olly script to find the original entry point. You don't have to do this, it's just illustrated for what we're showing here. But again we're looking at this, the address ends with the BB08 instruction. So after we do that, we'll first step to do is to load the saffron module into memory or into the kernel. And once that happens we're going to execute the saffron kernel monitor or the userland monitor process. And we give it the TLock executable. So this is actually TLock executing, and if you look at this address, the first one that it hit on is this original entry point that ends with BB08. We're going to load the packed version of TLock just to show that it doesn't look so happy. And as you can see there's nothing here. There's a start function which is pretty useless, not a lot of good information. There's the usual suspects when you have a packed executable and the strings have no useful information, except for my password it looks like. And the flow graph is extremely useless too. There's only one function. So we're going to close that, load up one of the files that we unpacked, and what we do is we will take that first one that unpacked and drag that over into IDA and see how that looks. We'll let that go through. Things are looking a little better, the names windows populating. IDA is not screaming in pain anymore, or no more than usual. We have functions inside of the actual executable. If we look at the top graph there's lots of blue, blue or code sections, so that's good. We have actual functions in here with assembly and like Val said there's a good way to look and see if there's useful information is to get cross references and those exist inside of here. And again we're getting a lot more useful code than we did before and the flow graph looks good. Names exist and it's continuing to populate and we have strings as well. Here we go. And so we have registry keys, we have the original name of the malware that the author probably put in there to brag about it, and that sort of thing. So everything looks good and then from here on you can do your standard analysis and go on to that. All right, so auto-impact results, it turns out to be an extremely effective method for bypassing this detection. SEHD code problems are completely circumvented because we don't actually touch the executable and likewise any memory checksum that occurs we don't modify process memory so it's going to look at itself and say everything looks good. So we get good dumps and this is effective across a good wide range of packers. There are some caveats to this. We have some system requirements. This only runs on XP service pack 2 and the reason for this is that Vista really isn't a target for malware authors yet because it's not very widely deployed. Data execution prevention has to be turned off because Microsoft actually uses the page fault handler to implement some of those. Second one is single CPU mode. There are strange mutexes that we don't have access to easily, so that's the other thing that has to happen. And it's 32-bit only again because malware is typically 32-bit. But there's no reason why this method couldn't be ported to 64-bit mode. Next one is that you have to run it on real hardware. Virtual machines, it turns out, we found out last week, play their own tricks with the instruction TLB. And furthermore, if you're using a virtual machine for this it'll work most times but in most cases it's extremely detectable. And you should also take precautions because of this. Make a good restore procedure and don't run it on the internet. Also, if you're looking at TLock, make sure you don't have a kernel debugger attached because otherwise TLock will play its usual tricks of dividing by zero and creating strange exceptions. So what we're going to do here is we'll have an initial release of the dynamic instrumentation version of saffron, which is already on offensive computing right now. And we're going to package up a kernel version and provide that later. And it will integrate a lot of the results into offensive computing and it'll be available next to the standard sample download. So what we're going to do right now is we'll have a montage sequence of packers that will go by and Val will actually do that for you. I'll let you. Okay, this is sort of the you're going to die packers section. So what we're going to do is we're going to rapidly run through basically every packer we're able to get our hands on and unpack them automatically very rapidly. And this is sort of just showing, this is the TLock video one second. So what we're going to do is generate lots of original entry points and dump files. The first one is AS pack and you can see right there, same original entry point as before. AS protect is another, it's a pretty good packer, still falls to saffron, same entry point. And this is sort of like a proof of concept that hey look we can unpack pretty much all of these commonly used packers, FSG, same thing. And it's typically going to be the first second address. I think we've seen a couple within the first four. Here's a packer called Mew and there we get the the magic OEP in the first hit. So this method basically covers like 90% of all the packers that get used. There's some really hard custom ones we haven't been able to get our hands on the test, but you know there's PE compact, no problem. I think the next one is Petit, PE pack. There it is in the second second hit. One thing we didn't do was test any of the advanced options that some of these packers have. So this is the sort of the default options that they come with. There's Petit, third hit. So yeah if you've got a packer out there, if you have something that we don't have listed that you think is interesting, shoot us an email and we'll give it a test and see how it goes. There's packs, no problem. Again UPX, this time we're doing it with the kernel version, so the dynamic instrumentation version. We pop that one in the second hit and even scrambled version of UPX, no problem, same thing. Pretty much all packers we managed to take care of. Armadillo is a little interesting and I think that one's coming up pretty soon. We don't get exactly the same OEP but it turns out it's in the same page of memory, so the dump is valid and it's totally readable, works fine. So you can see here every time we ran that we generated a bunch of dump files for each one named with our candidate originally and original entry points. So there it is. Okay again all the paper and presentation code is currently available on offensivecomputing.net and we'd like y'all to go there and participate in there but I'd also like to take time to thank Lori Librock, Houdini Escape, Bugcheck, Skywing, the awesome Ty Brodell and everybody in Unformed and Vax and at this time I guess we're ready for questions. Thank you. The question was if we tried it against the morphine unpacker and that was another one that was we didn't have time to do but we suspect it'll work okay. I couldn't quite hear this. Yeah you might want to come up here because we're...