 Okay, my name is Nick Harber. I work at a company called Mandiant. It's at the bottom of the slide. We're an incident response company. Me personally, I lead the malware analysis team at Mandiant, so reversing's my thing. This talk is gonna be kind of primarily aimed at reverse engineers or people who are getting into reverse engineers. There will be a lot of code on the slides. There'll be some assembly code that freaks you guys out. You can go ahead and bail now. I won't be offended. You don't have to understand every bit of it though. There's still gonna be a lot of content in here for people who are absolutely brand new, don't know how to code, that sort of thing. All right, so as far as the agenda, I'm gonna start out, get some terminology out of the way so nobody's mystified whenever I start throwing out some terms. I'm gonna talk about the history of dynamic analysis and the current techniques that people are using in the field and the current techniques that I use when I'm doing malware analysis. And like I said, this is a reverse engineering talk and since I'm a malware analysis guy, it's always gonna be with the hint of malware analysis. I know there's several different disciplines of reversing. I'm pretty much always gonna take the discipline of malware. So basically at the end, the care at the end of the stick for this talk will be a new tool. And I'm gonna basically get me setting it up throughout the talk and how it compares and contrasts with other tools that are currently out there. All right, so a little bit about reverse engineering. We split it off into two different, so let me just take this out. This is really annoying. Oh, all real hackers have their dog as their background. Yeah, he is. All right, so we split off reverse engineering into two main disciplines, our two main categories, static analysis, which is everything that doesn't involve actually running the code. Analogy there being like an autopsy, you know it's dead, you're picking it apart, you're figuring out what it does. The other half of the picture is dynamic analysis, which is you're letting them malware run, you're seeing what it does, observing its behavior. So the tool that I'm gonna be presenting about, and the techniques we're gonna be talking about are also setting up virtual networks. A lot of this is accomplished with VMware, is what we currently use. This is certainly accomplished by people at the very basic level where you know anything about disassembly or any of that. You can set up Wireshark, do some basic behavioral analysis on malware. Getting more complicated, expensive solutions like Norman Sandbox and CW Sandbox, which these products are good, and they can pretty much do everything that my tool's gonna do. My tool's free, they're tools, tens of thousands of dollars. So I'm not gonna claim to be beating them, beating everybody at everything free, because this is a project in my own personal time. The tool I personally use, because it is also free and we get pretty good results from our analysis, is CIS Internals Process Monitor. I think quite a few of you have used it, it's very, very popular. I'm gonna be comparing mainly with that. And debuggers can do a lot of this stuff. The whole point of my tool is gonna be, I'm gonna be doing a lot of process tracing and API interception and all that without acting as a debugger. So if you've been thinking of a, you know, heckling me with a question like, why aren't you just using immunity debugger or whatever, the whole point is to be not using a debugger. I'm sure a debugger can work great in most certain stances for these things. Just there needs to be a tool out there to do that kind of thing without being a debugger at all. Journal level monitoring. So this is the technique employed by Process Monitor by CIS Internals. Here's a normal kind of graph of what happens when you do a system call in Windows. You have a user mode process, like notepad.exe. It issues a call called create file. This is something that's issued to the, like the programmer and the application that it can make this function call. And the code for that initially is provided by libraries, for in this case, kernel 32 is the library that provides that call. And all that happens in kernel 32, which is totally in user space, is it performs a system call. The system calls have to be implemented in this SSDT, the system service descriptor table. So it's kind of like an array of pointers in the kernel. So I'm gonna oversimplify the hell out of this whole process just in the sake of time. And then these go, and the kernel maps these to the actual handlers of the functions. So how Process Monitor works is they basically load a driver that hooks these SSDT entries. And so every time one of these is called, they'll eventually call the real thing. But along the way, they're gonna report back and say, hey, somebody called this. Capture the event, take note of it. Advantage is to that technique, every system call will be captured. You'll have a, that's a pretty good coverage as long as you're capturing everything in that table. Really kind of difficult to get around it. Certainly no way that I know of from user land that you can do something like create file without actually calling the actual service. Disadvantages, not every important function that we care about for the malware analysis or reverse engineering perspective is implemented as a actual system call. So there's important things like if you're one receivable of functions, a piece of malware is trying to load for later on, you'll see process, a bunch of calls like get rock address that's completely implemented in kernel 32, I believe. And yeah, that's never gonna be a system call, but you're still gonna want to see it happen. And also calls to internal DLLs of course will never be trapped, you're only gonna see that the actual system call that happens from the process that's implemented in kernel 32 or in TDLL directly into the actual kernel itself. Oh, another disadvantage, you're gonna see a lot of like housekeeping stuff. So every time you launch a process, like you make a hello world program, all it does is create hello world with a screen. You can use process monitor and fire up hello world. You're gonna see thousands of calls happening just for hello world.yxc. Now with skill, you can kind of filter that down and wait it down and get down to the beat, but it's still not a perfect system. You're seeing a lot more data than you really care about. I think we can do a little better. Well, here's a screenshot of process monitor. Initially when I put this in I was gonna talk in detail about it, but we'll just look at it whenever we get to the actual demo. Basically I'm gonna fire up some stuff, monitor, process monitor, there, process monitor, and then monitor, you can see the difference. I think it'll be pretty apparent. But basically this is a list of every system call that's happening. And this is currently filtered just for notepad.yxc. So you can see all you did was fire up notepad and I have 132,000 events, which is the system calls which is currently showing 793 on screen. This is really nothing important happening at all. API call monitoring for reverse engineering is using a debugger, which is pretty good. You can trap function calls all day long, not just system calls, so a lot of that same stuff I'm gonna be doing, you can certainly implement a debugger, certainly a script of the debugger is a very good solution. And the trap calls are gonna be, you can potentially get them to be more highly relevant to the trap program using techniques that I'll be talking about later. Disadvantages, main disadvantages, you have to act as a debugger. Then once you act as a debugger, then you're kind of thrown into the fight of this cat and mouse game debugging and anti-debugging, anti-anti-debugging, anti-anti-anti-debugging. You can play in that game if you want. I was just kind of looking for an easy, cheap way to get certain about the whole thing and not have a debugger in call of sorts, however. All right, so there's lots of different types of hooks. I'm specifically gonna be talking about inline hooks as the technique I chose. I think it's probably the most robust technique for the long haul, so I chose to implement it first and not even bother with other hooking types. Anyway, inline hooks can basically, you can trap any function call, not just system calls. Currently the tool we're gonna be talking about only traps, it can only walk through exports of DLLs and trap those, but on down the line, who knows, we can do anything. The trap calls can be highly relevant to the program's operation, because we're not gonna be seeing any of those process housekeeping system calls like we saw for Notepad. No device driver required, not operating as a debugger. Not only disadvantages, it's kind of a pain. I mean, there's really a lot of issues with it. And the tool that I'm gonna be releasing certainly is gonna show that. There's, it's not fully, I mean, this isn't, it's not on the Mandiant site yet because it's not full, it's not bulletproof yet. It's very much prototype. You can play around with it, kick the tires, write some scripts, that sort of thing. It is not the be all, end all tool yet. I think it will be a great piece of work, maybe in a couple months, check back. But anyway, it is a pain. Here's the whole idea. With inline hooks, we basically load stuff in the user space that handles, that traps the functions we're interested in and handles them all in user space so the kernel's never, never affected. This is basically the same graph we saw earlier, just you see the difference in where the hook handling is moved. All right, so what the heck is an inline hook? Inline hook is basically, you're going to the, where the function exists and you're modifying the code at that actual function, the assembled code for the function. And to implement these, just a little background in case you have no idea what the heck, how this all works, you basically have to find a function of interest. You have to disassemble the beginning of a function and this is very important. And this is different from the way a lot of malware will do it. For example, if malware is going to install an inline hook to trap like the send function and winsock to, you know, so I can monitor every outbound packet, they can pretty much know exactly what code is going to be at the send function. They don't need to disassemble it on the fly to figure out if they can install a hook or not. They can just blast over it and be done with it. Since we have a very general solution where things aren't known at the beginning, we have to disassemble. So I'll talk more on that in a minute. We disassemble, if possible, we overwrite the beginning bytes of the function with a jump or a call instruction. And the jump or call instruction that we write at the very beginning of the function points to our own block of code that's loaded into the process somewhere. Now, okay, like I said, we're gonna talk about why we disassemble. Take, for example, this little function right here, X or E, A, X, E, A, X, and return. This is a very simple function that just returns zero. It's only three bytes. A call or a jump instruction of the type we need is five bytes. If we overwrite this three byte function with five bytes of data, we're overwriting two bytes of God knows what. It might be just padding, but it might not be. So for safety, we're gonna disassemble just for the purpose of figuring out if we have enough space to overwrite. Actually there's one other purpose and I'll get to that in a second. So here's a more complicated function. This is more like what you would actually see. This is a function prologue at the beginning. It basically just sets up the stack for a function. You don't need to worry about it. Just note that these four instructions are at the very beginning of this function. Once the hook is installed, I've installed a jump hook right here. You can see we overwrote basically was at five bytes. So these two instructions and two bytes of this third instruction have been overwritten. So every piece of data starting after this first five bytes here is just unused. Because theoretically, whatever our jump handler is doing, if it's going to recreate these instructions, it has to jump back right here to let the program continue. These are just kind of unused. And there's different schools of thought on how you actually implement the hook handler. If you want to completely do something else and never return to the function. In my tool, what I actually do is I implement it with a call right here instead of a jump. And eventually the handler jumps back to this exact point after it's recreated the functionality that it overwrote. So that's another reason I use the disassemblers to figure out exactly what I need to do once I've finished playing with the function. All right, so once you have the hook function, what the heck do you do with it? You can inspect it. This is the terminology I use. I'm sure other people use different terminology. There's no standardization. I say inspect and intercept. Inspect being, I want to let the function continue once I'm done doing whatever I'm doing. I just want to look at the stack, see what arguments are being passed in. I do things like that. Intercept is I want to look at the stack and look at the arguments and all that junk. I just don't want to actually call the function once it's finished. So in this tool, it has the capability to basically, you can script a response whenever you hook something, so I can hook. The example I like using here is gethostbyname, which is the function in the Winsock library to do a DNS lookup. So we can script a response to gethostbyname to basically always kick back the same IP address for every DNS response, which is a good first step in sandboxing. And that would be an intercept operation as opposed to inspect. If we're just monitoring the API calls as a program runs, that's all interception. Yeah, so I kind of jumped the gun there on the rolling your own sandbox. Gethostbyname is my favorite to start out with because it's very easy to understand, very clear to implement. And we're gonna actually, I'll show you the code to implement it. You can do much more complex things and this will all be down the road. I don't have much of this implemented yet, but you could do things like, you can trap the call to connect to just kick back like a pseudo handle so that every successive send or receive to that pseudo handle. You just check if it's like the value deadbeef and if it is, handle it with your own Python code as opposed to letting Winsock handle it and really send it out across the wire. Same thing you could happen with the file handles. Create file, read file, write file, all that stuff. We can do the same thing. All right, before we get too far I'm just gonna, this technique hasn't been documented anywhere and it's a technique I use for unpacking on a daily basis and it's kind of what got me in the mindset of thinking about inline hooks for so many years. So I'm just gonna go ahead and quickly brief this, briefly talk about this pack, the technique I use for unpacking. And the reason I use this technique is it doesn't involve debuggers whatsoever with just some basic hooking we can easily unpack code. So the first thing you need to do to unpack code with inline hooks is disable the thing called known DLLs. Basically, if you have a DLL listed in known DLLs which most of the important system DLLs are, it'll always use the version that's in C colon backslash windows system 32. So for example, kernel 32 is always in that directory and it's always listed in this key so it's always gonna use that regardless of the regular DLL search path. The DLL search always goes to the current directory and application startup directory and then eventually works its way back to the system directories. So we disable this key which in my malware VM that's what I have disabled all the time so I can easily do this. You disable this key, you reboot, I copy kernel 32.dll to the current directory that I have the malware in that's packed. Now basically whenever I run that malware it's gonna use the local copy that I just copied as opposed to the actual system 32 copy. The difference here is we're gonna be modifying that version of kernel 32. If we've tried to modify the one in system 32 we can't because of Windows file protection. Theoretically you could disable it but you don't wanna do it trust me because we're gonna install a hook and that would be bad to do system wide. Next thing we need to do is find a function that's likely to be used in the unpacked code. I like write file, get command line is good. Basically packer stubs when they go to unpack a binary there's not a whole lot of win32 functions that they use. We need to find one that the unpacked binary is gonna use that the packer stub isn't gonna use. So I've never seen a packer stub which in this process of unpacking the binary calls write file. Potentially they could call get command line but write file is my favorite. I always hook that first and if it doesn't work I move on. Then you gotta find the location of that function within kernel 32. I'm talking about the physical location within the file that that function starts. I'm gonna omit the details of that process. It's a lot of kinda math and calculating. And once you find where that function actually starts you just replace the first two bytes with EBFE which is an infinite loop in Intel. Just do that with a hex editor and then you launch the pack binary and as long as it calls that function that you just installed that little hook to as soon as it hits that function call the process just the CPU usage spikes and the process is effectively hung. At this point then I just attach to it and dump process memory. It's basically, it's hung in a place where it can't do any anti-debugger checks unless potentially they have another thread running or something like that. But just thought I'd throw this in here. Two slides to officially document something which I use on a daily basis which I haven't seen anybody else document. So move on. All right, now I'm gonna talk about the actual tool. I've named it API thief. I'm sure there were better names out there at some point in time but I'm searching on the net. Everybody's taking all the good ones so I'm left with API thief. How this thing works as opposed to doing the on disk API hooking like the Microsoft detours library or the technique I just showed you. This thing operates completely in memory. So what we do is we launch a process in a suspended state. Then we use process injection to inject a DLL into that process. This is interesting to note because we launched it in a suspended state. We do process injection to get that DLL loaded. That's operating on a thread that's executing before main thread ever starts. So if you've ever played with processes in a suspended state, there's nothing going on. If it imports like 50 DLLs as long as it's still in that suspended state none of those DLLs get loaded. They only get loaded after you resume that main thread. So this DLL that we inject operates completely before the actual main code of that program. And it's the job of this injected DLL to run through the Win32 API functions and Kernel32 and all that and anything that we specify really to go through and hook them. And basically how it operates is it installs these hooks and they all point back to a single function dispatcher and then that function dispatcher is responsible for figuring out what it needs to do once the hooked function has actually been called. I'll talk about the design of it here in just a second but basically there's Python in the back end which is responsible for figuring out A, if you should hook a function and if so what kind of hook should you install and also once a hooked function has been called what do you do with it? Do you intercept, do you inspect, do you write data to the process, do you fix the return value to be a certain value? All that stuff is handled by Python. So quick note on the design. The injectable DLL is written completely in C with a lot of inline assembler. Not just because I love assembler but there's very specific reasons that the way that that function dispatcher needs to operate and I'll show you that in a minute needs to be an assembler. It has a built-in disassembler. It's actually a complete disassembler which is probably a bit more than is really needed for this function but yeah maybe on down the road we can do more with it. The GUI is written in C sharp and Iron Python is embedded which is basically see Python implemented in the .NET framework so it's not it's not gonna be using the same Python environment that maybe be installed on your box so just be aware of that but it does have a complete Python library along with it and it pretty much works the same as you would imagine. All right now how I differ from other types of inline hooking the main difference is I implement the hooks with a call instead of a jump. That's pretty rare. Normally like from a malware perspective or a root kit perspective you're installing a hook you always just everybody just throws it into a jump and they're fine because they typically have like a one-to-one mapping on functions that they hook to handlers that they've installed so if they hook create file they have a function which handles create file and does all the create file stuff. We don't have that luxury with this tool because this solution is very generic at the time we're writing the tool you have no idea how many functions you're gonna hook or what those functions are or any of that stuff that's all up to the Python code which could be customized or actually written at runtime of the program so we can't have individual functions inserted into the process which handle each one of these things uniquely so basically we use a call instruction instead of a jump so that all every hook we install they all point back to the same function which handles that hook and if you know the difference between a call and a jump is a call pushes a return address on the stack so if we implement if we put the call instruction at the first few bytes of let's say create file that return value that it pushes on the stack when it calls our dispatcher is gonna be different than the return value coming from let's say write file they're gonna be two completely different values and we can know exactly which function we're coming from which hooked function based on that return value so we can write a single general hook handler which can handle any hooked function and we can hook as many functions as we want and they're all fine so that's just a little segue into why I'm using hook instead of jump nobody probably cares all right so all hooks point to the same dispatcher currently I'm using named pipes to communicate back to the GUI that can be sockets in the future I don't really care this was just initially I was just only thinking locally and I was just simply named pipes no big deal and there's a persistent thread running in the target process which can be used for communications for example if the process is running and you just need to get a list of loaded modules or install a new hook that's all happening in another behind the scene thread so you don't have to wait for a hooked function to be called to actually have some interaction with that process all right and like I said before the Python layer handles all the logic on what functions to hook so we're gonna see some plugins and whatnot that go through and specify lists of functions to hook and whatnot but all that stuff can be written by you once you download the package that the entire plugin framework is in the Python layer so it's completely up to you here's the actual function dispatcher like I said there would be some assembly in the slide so this is it the next two slides just for anybody who is morbidly curious enough to know exactly how this thing is working basically you have to this is a decal spec naked function which is in C a function in which you yourself are responsible for setting up and destroying your own stack frame it's kind of crazy but the reason we have to do that is we need access to the actual return pointer on the stack so we have that call instruction from wherever the hook is installed calling this function this function needs to look at that return pointer on the stack so that it knows exactly what function called it and the only way you can do that that I know of is decal spec naked that's portable at least we also grab the pointer from the stack of the original function that called this the reason we actually look at that original pointer is so that we can filter out between where that API call got called from so we're really only interested in calls that are coming from like are executable so if I launch notepad I only care about calls from notepad I don't care about if notepad calls kernel 32 and kernel 32 calls something I don't want to see that call I only want to see the call from notepad to kernel 32 so this is one reason that I'm going to get much more condensed data than process monitor because process monitor is not going to do any type of filtering based on where the API call is coming from you're just going to get a dump of everything so recursive calls you're going to get all that in process monitor not in mine some people might be thinking well if you're going to be intercepting calls there's kind of an issue here with standard call versus C decal calls mainly there's a difference here between which function is responsible for fixing the stack based on the number of parameters passed in it's kind of an issue but here's basically how I handle that it's up to this is where we actually call process inspection this will get commands from the GUI on what to do to the process so it's actually a responsibility of the Python code to tell the hooked process how many bytes it needs to subtract off the stack at the beginning or add to the stack at the end of the function so it basically does that fix ups as long as the Python code has done its job right and you've told it hey this thing had two parameters fix the stack and let the program continue and it basically puts a value on the stack and then plays with the stack pointer and returns to it and at this return it actually jumps back to the original caller not to where that hook is and this is for an intercept by the way this is not for an inspect member inspect it actually lets the original function get called this is only in the case that we're actually intercepting that call and doing something else instead of it all right API thief has a full protocol there's other tools out there before I actually after I started this process I learned about like I defense had a tool called API logger which did similar and installed a few fixed inline hooks and handled them in a very simple way and it just kicked blindly kicked data over a socket back to the GUI problem with this though not thread safe so if you had multiple threads kicking stuff back you're basically getting you're gonna get overlap data and if one system call had a whole bunch of data it's passing back and it did it over several sends you're gonna get all that data just kind of garbled together presented to you the reverse engineer so as long as you by implementing a protocol and having it all thread safe and all that you're gonna get nice clean output back all the time so that's why I went on that path and the protocol supports a few primitives and these are commands that can be sent to the hooked function to get back data so when a hooked function is called the GUI can send it a request to get the ESP value which is the stack pointer and from that then we can basically figure out what arguments are on the stack and all that jazz you can also get the FS register if you guys are familiar with what that points to and all the good juicy tidbits you can get once you know the value of that we can set the EAX value this is what the return value of the function will be so in the case that we actually intercept a function instead of just inspecting it we wanna set a return value so the rest of the program can continue and this is the command that will actually set that set param size is what I was talking about earlier where you wanna set the number of arguments that are passed to the function no big deal here's an example of the protocol being called here's a hooked function gets called it sends a request to say hey a hooked was called the GUI tells it whether or not to do an intercept or to do an inspect with another packet that comes back message technically and we have a type message called response success this is actually gonna contain the data so when he says for example get ESP value the response success message is actually gonna contain the four byte value of the ESP register so this is just a little example of doing an intercept all right looking at the actual Python API to you don't have to know really much of what the how the protocol works it's pretty much easy to handle from the Python layer so the Python scripts have the ability you have the functions inspect and intercept so once your hook handler gets called it's up to you in Python to know hey do I wanna inspect this or do I wanna intercept it and you just simply say inspect and it'll go down that path once you're finished doing whatever you wanna do you call continue and then the program continues on so you could potentially like if you wanted to like a message box to pop up or something like that you can have or a mechanism to have you step through a program and making you click something to actually click through each system call it's perfectly doable cause it won't continue until you actually tell it to continue report is how we get information to the GUI console you'll see it have a nice little scrolling window of messages coming out and that's how you send a message I have some wrappers here called get arg and get args and Python this will return either a single argument or an array of arguments to the function and it's just gonna return the d words on the stack so it's if the d word actually points to a string you'll have to do some other things to actually go out and get that string I have wrappers for read asking read unicode string set return value and last but not least alloc read and write so we can allocate memory in the other process read and write memory these are just called the win 32 functions behind them so no big secret there but once you have the ability to intercept a function and read write and allocate memory into it and set the return values you can really pretty much do anything you want you can recreate any API function and screw with it however you want so here's an example Python script this is actually a plugin that handles beep and this is the complete plugin I know it's hard to see in the back I'll get to the important functionalities down here in the actual beep handler and you can see back on this slide I just call it register hook and tell it what I wanted to hook register hook is implemented in Python too so if you didn't like the way that works you can do it yourself so here's the handler for beep and beep is just a function which supposedly takes like the frequency to beep and the duration to beep if you don't have the device drivers it's just gonna error out but it's a useless function pretty much nowadays so I just show you here to demonstrate this particular function is going to intercept it so the real beep is never gonna get called it's going to get the arguments that were passed into it like I said there's two arguments it's gonna report those to our GUI console and since this is a standard call function as opposed to a C-deckle call we have to set the stack pointer back because it's up to this function to adjust the stack after the call not the function that called it so we have to call set param size tell it to set eight bytes and then I set the return value to one which in this case means success or true and this will actually get handled here's an example of a get host by name sandbox function very simple at the beginning we call intercept I get the first argument to the function with get arg I read the ASCII string that that points to because you just pass it the name the DNS name that you wanna look up so at this point host contains that DNS name I go ahead and report that to the console so we know what we're looking up then I allocate memory I allocate four bytes and I write this value into it and that's 127.0.0.1 and then I set the return value to be that pointer that we just allocated so this is gonna handle get host by name and get host by name is always gonna return 127.0.0.1 and it's also gonna report to the screen what we're trying to look up as you can see it's not all that complicated and I apologize I'm not the greatest Python programmer I just implemented here to have a decent little convenient extension language I'm not a purist or anything so if I'm doing stupid stuff you can tell me about it I don't care All right so here's, oops so here's API thief like I said it's very prototypish so I don't have an icon yet so what we have here hopefully everybody can see down here at the bottom there's a text box where you can specify the command line you can specify a full command line with arguments and everything I'm just gonna simplify the process here by clicking on the three dots to let you select and executable and I wrote a small binary here just to get a really simple test all this thing does is call like create file then it calls beep and it calls a few other things so once I've selected that here's the command line down here really nothing happening yet we have to hit this initialize button what initialize is gonna do is spawn the process in a suspended state then inject the DLL whenever I hit initialize though I have to make sure that my plugins are selected because I can't change those after the fact and the plugins I have here is a basic Win32 API monitor which I'll show you some of the code for it's really simple and that get host by name trap I'm gonna go ahead and enable that plugin there's another one that comes with the package on my website called load library hook I'm not gonna use this for these demos basically you'll need this plugin if you need to hook a DLL that gets called later by load library at runtime go ahead and load the load library hook plugin so it'll basically recurse down anything that's loaded at runtime because it currently it's only gonna hook what it's gonna see in memory to begin with so I call initialize I see create a process injected api-thief.dll api-thief initialize ready to launch process so the next step would be to click launch let me go ahead and browse a few things this is kind of useless data at this point but it went ahead and reported back to me a list of loaded modules in this process space I can also have down here I can browse the hooks that are installed so I have that basic Win32 API plugin loaded and that's hooking whole bunch of important API functions so I can browse the list it's quite extensive and I apologize it's not in alphabetical order and I loaded the plugin for get host by name and you can see WinSup232.dll has get host by name hooked you probably can't see all the way in the back but there's magnifying glasses which mean inspect and then there's little script icons which means it's gonna intercept it's gonna run a script instead of calling that function so and there's also a script window this is, to be perfectly honest, completely useless right now in this release of the tool eventually maybe it'll be cool oops but, oh I gotta launch it first let me go ahead and launch I said yeah, the script broke anyway I launched, so I went ahead and clicked launch and it's kind of, oh 10, okay you can see it called get system time as file time that's something that happens in the C runtime code at startup and in this case that's the only kernel 32 function that was called there are more functions that get called it's just, I only have the plugin to trap kernel 32 functions so it caught that one it caught a load library call on PSAPI which is in the code caught a call to create file C call back slash test dot text you can see here it called beep and then it called sleep sleep is an interesting one from our analysis too because if we can intercept sleep and just report that it's trying to sleep and then not actually sleep that can simplify a lot of people's lives because a lot of times malware will try to wait for some crazy amount of time and you'd have to go through and do a lot of static analysis to figure out how long it's trying to wait for in this case we can basically just tell it never sleep so this is a very simple list of functions and this basically maps exactly to the function of this program the domain function I just coded a few things really quick and you see that's all I get I should have launched should have been monitoring a process monitor why I did that oh well on the next demo we'll do that oops so let me do a more complicated one I'm gonna do oops I'm gonna do notepad dot exe just so you can see I'm not completely full of shit and using rig demos notepad is it's not the most complicated program in the world but it's the least complicated enough that it will screw up your life I'm gonna just do the basic win 32 API monitor click initialize and go ahead and launch process monitor here I already have a filter set up that's why so launch notepad notepad is now popped up on the screen over here you can see my data I don't have very much I have you know get proc address here for register pin app I have a few string compare functions these are implemented in kernel 32 there's string comparison string cat all that and this is something you're never gonna see with proc one you're never gonna see that this process was doing a string comparison for example you know untitled notepad a string cat because that's not a system call that's only a kernel 32 function call so here I am scrolling through the process monitor output and I have 327 events most of this has nothing to do with what the programmers of notepad dot exe designed this is just stuff that's happening for example every DLL that gets loaded you have to there has to be a create file for that DLL and and all this other stuff there's a lot of registry keys that just happen this is stuff we don't care about for malware analysis for the most part reverse engineering in this particular example I really needed to hook more user 32 functions to get to get the idea what's going on but you can see the idea of where we're going with this close that oh actually one more thing I wanted to do with notepad go ahead and launch this again I want to like save a file out so I'm going to say you know hi defcon save as test.txt and then down here at the bottom you'll see what the functions are called there's the string cat on test.txt there was a create file up here and I called a write file set into file much less data than this which is showing us 15,000 events for the same process and I think I'm getting ushered off the stage here in like one minute so my tools are available right now at rnicrosoft.net that's not an M and don't sue me if you are work for a company that might take offense eventually the tool will be up on mandiant.com and you can contact me here if you have major bug reports in the next couple months don't even bother I know anybody can send an email just you know there's tons of tons of bugs right now so maybe hold off a little bit on going and calling me out and trying to you know yell at me and scream at me so just be nice I'll show you a puppy yeah be nice thank you guys been great