 Good afternoon everyone. My name is Damián Gomez. I'm from Argentina. I've been working at Immunity for almost two years. As a security researcher I focus on vulnerability analysis and exploit development. I'm the leader project of the visual exploit framework and among my current projects is I'm the main developer of Immunity Debugger which is the subject of this talk. Well, anyone who has ever caught an exploit will tell you that 80% of their development time was spent inside the debugger. Like with all the software engineers that exist today, the actual language implementation is somewhat irrelevant. Let's say as soon as you can craft a string it's more likely you are going to be able to call an exploit. Immunity last year introduced a visual, a graphical language for exploit development called VisualSploit which was based in the concept of drag and drop and exploit components from a tool board to a panel and having as a result a radio exploit. So, you can see the programming language is not something that will matter at the end. Since exploit is merely a solution to a problem that was solved using your debugger of choice. A problem that requires intelligently understanding of concepts like input crafting of heap analysis, memory manipulation. It's okay. Let's say inside the debugger you should be able to get the first abstract approach of your bug and the last concrete goal, the shell goal execution. So, what do we want from a debugger? For a vulnerability development, development, debugging framework, we want a simple understanding of the interface and we want to be able to script things. So, we want a powerful scripting language in it and we want it to be fast. Unfortunately, there is no perfect interface model for every exploit development situations, but there are some characteristics that will help us achieve what we want and those are a GUI, a common line and a scripting language. So, why a GUI? The graphical interface will make us fail. It will be easy to have a visualization of the CPU context or the stack. Let's say it's easy to see where EAX points or any register and a graphical interface is faster to learn for complex commands. You just don't have to learn the complex commands but you click them. But it has a downside and it's the slower usage than the common line. That's why we love the common line. The common line is a faster way to interact with the debugger. But let's say there are some complex commands that will be hard to remember. At least you are a full-time debugger user. So, you have to be checking the manual every time you want to type these complex commands. And we don't like this. And the last thing we are looking at in this kind of debugger is the scripting language. But forget about those awkward scripting language for debugging. We want a real scripting language. And the debugger has Python like the scripting language. Python is familiar and easy to learn. I mean, it's really easy. So, these characteristics will add, sorry, at immunity with immunity debugger integrates these three characteristics in his own vulnerability development exploit oriented debugger. We have been using immunity for some time at immunity. And we have great results during our testing. There is a screenshot of immunity debugger session which you can see there is a Python command at the command bar dumping the heap in a custom log window right in the upper side of the screenshot. The immunity debugger API, the immunity debugger API is simple. It runs like a cache of structures to speed up the experience. That means it's pretty useful, for example, for searching functions when you are doing some memory deep searches. It's useful to have some cache of them. And the immunity debugger API, it can not only perform debugging tasks, but it can also interact with the current GUI. You will have all the debugging tasks like step and execution, assembly, assembly, but also you will be able to control the GUI. There is something extra to say that is keep in mind that when you are running a Python command, the information will generate runtime, so every script run is femoral. But how deep can we do that with the API? Well, we can do mostly everything. For example, we can do assembly and disassembly methods to break points of reading and writing memory searching, execution, and stepping and analysis with it. As I said before, interacting with the GUI, what offers that to us? Well, creating new custom windows for displaying new data or tables, dialog boxes, input boxes, combo boxes. There is a script, a fine anti-DIP script that has a whistle that will guide you through the execution of the script. But the best way to show how interaction with the GUI is possible is with the Python or the one-eyed graph. The Python graph is a graphic library that will make a graph of the function of an ordinal representation of it and is entirely covered with the immunity developer API. Well, among immunity developer methods, we can read and write into memory, like when you are calling an exploit, it is more likely you are going to be manipulating memory all the time. So there are a lot of methods for reading and writing memory. And something else you will be doing while developing an exploit is searching, searching for patterns in memory. So the immunity developer API has a lot of searching methods, like the simple search, which will search in memory, or, for example, searching commands. Comments are searching commands which you can, for example, search regular expressions with it. And if you want a deeper search, you can even use the assembled method. You can assemble a command and then search it in memory. Okay, getting code cross-reference from data encode, it is also possible from the immunity developer libraries. And this is the immunity developer knowledge. As I said before, when you run a script inside the immunity developer, that script is run a lot in there. So there is a way to save into immunity developer memory the information of that script, the knowledge method will do it. Like, for example, you can save the spiel context inside a Python object and save it into the immunity developer session with the knowledge so you can get that spiel context later with the knowledge methods. There are three ways to script immunity developer, the byte commands, the byte hooks, and byte scripts. We're going to talk about the first two ones in this talk. The byte commands are Python scripts. It will help you develop a regression day developing time. These scripts are no catching, so that means you can run modifying a script and rerun it without the need to restart the debugger, so that's pretty useful. The Python commands are accessible via a command box or from the movie. And you can integrate the Python commands to the debugger features. Waiting a Python command is easy. You just have to create a file, import the library, and define a main function where you can instantiate the API and start using it. Then you just place that file into the Python command directory and you're ready to go. And byte hooks. Hooks are objects that hangs on the debugger sevens, like executable, any break point or post analysis hooks, et cetera. The good thing of hooking is that you can hook that event and place it in immunity debugger session memory, some code that will be executed when that event happens. So you can create a hook on an access relation to save the CPU context at this right moment and will be executed when the access relation happens. Creating a hook is easy also. It's almost like creating a Python command with a difference that you have to define a run function that is the one that will be executed when the hook type happens. This run function will receive the CPU context as argument, just to avoid problems, three problems. So you can see hook is very related to three. There is some easy way to identify a common vulnerability primitive with hooking. Let's see an example. For example, this string and copy where the size argument is the same as the size, the exact size of the source argument. Just with minor modifications of this script, you can find primitive in other functions. So let's see this example of hook. First of all, we start initiating the debugger class and we're setting a break point in the string and copy function. Then we're creating a hook and adding to the immunity debugger memory. And inside our class or hook class, we find run where we initiate the lead and base it on the CPU context. We receive it. We are going to read the arguments that are passed to the string and copy function. Once we have all the arguments, we're going to ask if the length of the read the argument is the same as the size argument. In that case, we are going to get the code stack and log it. This screenshot of the script running shows how the code stack is logged at the source when the source argument is the same length of the size argument. There is another type of hooking, which is inject hooking. The inject hooking is a login hook. They are much faster since it doesn't use the debugger. You can inject code directly in the function. And it's redirected to your code. The information is logged in the same memory base. So it's pretty much faster. The heap analysis tool uses the future. Hooking is the most poor injection hooking has some drawbacks. Since now, you can only report the results and cannot do conditional with it. In this example, we are creating this inject hooking and we are using the unknowledge method to save the information into a memory. And later, with another script, we are using the get knowledge method to get that fast hooking and log in the result we have while debugging. There is another thing in the debugger and how the heap lives. Since heap analysis is one of the most important tasks for exploit development, we have included a set of leaves to help for that. These leaves allow us to bring the state of memory or examine the heap or saving our story in the heap. For example, we can get all the current heaps or we can get a single object heap since when you are doing some exploit development, you may want to focus just in one single heap where you can get from this heap, the free leaves or the free leaves in use. And in the same way, you can get the chunks of every heap or from a single heap object. And again, these chunks are objects itself which has a lot of information of it. It is easy to access information. You can search inside chunks like... Okay, you can search inside chunks and you can specify the heap if you want like an optional heap argument to filter by heap, the search. There is another libraries, the data type discovery libraries which help you find the types of data in memory that's pretty useful when calling an exploit to know where and what is memory. For example, you can go and do a discovery of memory of what of a pointer that will return an object and you can ask in that object if it's a function pointer or a normal pointer, a dot pointer, a stack pointer and so on. This slide should talk by itself. We have Hiby trying to use PyCommerce and PyHooks which use the Python app to analyze false search discover and not to understand what is going on inside the developer to create an exploit. During the past month, a new team has been going on some script that was helping us in while developing exploits. These scripts include vulnerability analysis, heaps, protocol search in female and comparing memory. There are some examples of the scripts created. For example, Saifse that we showed you in a custom window, all the exception handlers in a process that are registered with Saifse. The fine anti-DIP script which will find an address to bypass software DIP. This script was used in one of the training and that's why it has a wizard on it where the first combo box asked for the first address, then you have an input box for inserting the assembly code to search and lastly you have another combo box that will search for the third written address. You can see the lower screen that shows a buffer that will help you bypass DIP. There is another script that will find memory leaks in a function. It's a hook. It will hook a function, then you will be fusing that function and you will be getting the leaks. Check the red line where a memory leak is detected in that function which was hooked by the next NIF. Finding that the types in memory is another script that will help discover what kind of data is inside the memory. You just have to specify an address and decide to read and in the log window will appear what kind of data they discover with the phone. The heap by command. With the heap by command you can make analysis of the heap and dump it and check what's inside like the screenshots shows. For example, check the double link of leads that the heap by command phone. There is another script, the chunk analyze that is another hook where you specify the address of the red node and you run the hack. You place it into memory and you start fusing. If you check the log window, you will be able, one of your fusing is over writing a function pointer of a double link list. The RPC will access to RPC information and will give function pointers of every RPC call. The duality script will look at memory pages and others that can be transformed into opcodes. This duality script will be described more later in the dog. In the case of story, I have to prepare. The mock pointer script. This tool will do some data recognition looking for function pointers and it will override them. Waiting for an access violation of one of these pointers over writing and when the extension occurs, it will trigger the hook and will start logging for the analysis. The search script. The search script is a simple script that will search for cryptographic routines in a given branch. Look at the screenshot how a lot of different algorithm was found in a library. We have a case of style here. It's a simple stack overflow in a web server. When you send a long request to it, it will crash with a stack overflow. However, there are some details in it. For example, when you send a long buffer, some stack arguments over writing won't allow us to reach EIP. Check the screenshot lines showing how an argument a redable address is over writing and get an access violation when reading this address. So we need to find a redable address to place as the argument there in the right object. Also we find this, which is pretty easy. We will be facing the second argument problem, a redable address. That's almost as easy as the first one. We just need to find a redable address. So to keep EIP, we need a redable address, that redable address, and the argument offset in our screen thing. Finding the offset should be easy. So when we got that address and the offset, we can craft a buffer. That if the others we found are right, we'll be able to hit EIP like the screenshot shows without any problem. So once we hit EIP, in detail we have control over EPP value, AP value, what ESP.2, which is one of the arguments, and with ESP.4.2, which is the other arguments. And we have more of 200 bytes of a control buffer. There is the context, I was talking about right here. And the first thing I could think of with this context is jumping back. But how? And that's the second problem. Check where, what ESP is pointing to. Since we are controlling what ESP points to, what if we can find an address to place at the right in argument, which first of all needs to be right able because of the first problem. And second, it can be transformed into op codes that would be of use here. Like let's say a jump back to land into our control buffer. But finding an address with these characteristics might be pretty tedious and pretty hard. So there is a script with immunity value that we talked some minutes ago that would help here. The wall is a script. The right script is easy to use. You just have to place the common argument to the script you are looking for. And how do it works? Well, it creates a mask of the search code, in this case a jump minus 10. And we get all the memory pages. And we try to find addresses that match our master code. And we can see in the screenshot, the local results, there is an address marked with a red line that may be of use here. So before finishing crafting our string with a brand new address, transformable address, we need to find a jump ESP for AIP. The search code script will do that really fast. You just have to write search code and the command you are willing to search. So resuming, we have bypassed the arguments problem. We have hit AIP. We have searched for a writeable address that can be transformed into an opcode. And we have searched for a jump ESP. And we have crafted the string. So if everything goes well, we will be having, in three, check the right red box where ESP is pointing to another address that in the disassembly window is transformed to a short jump back to run into our control buffer. Now I am going to do some immunity debugger demo. Okay. Now immunity debugger demo. Okay. Let's go for the conclusion then. So immunity debugger won't give you another of the box exploit, but it will sped up the time debugging because of the GUI, the graphical interface on the command line. And it will help you finding the bug with the API and the libraries and the immunity script that are provided with immunity debugger. And we help you crafting your exploit, making it more reliable. We have been using immunity debugger for months, well, we'll do some web with good results. And some things that are inside my head right now is an API server to connect the immunity debugger to visual exploit, canvas, or fosters, or which are the applications that could be of use when doing some vulnerability development. More graphic stuff like interaction with the graphs so we can manage vertices and move them around and even clicking them to modify the assembler and so on. And also a lot of comments that comes every day when we need it, we call them. And your script, yeah, that's something I was thinking about also. Immunity debugger is pretty curious about what you can do with the immunity debugger API. So we have launched a little contest for the most useful script where the first prize will be a Celica unit. I think it's up to October 10th or something like that. So if you're willing to call some script of use, just drop me a line later. You can download the immunity debugger, get it free, comment, script, idea, request, please email me. I'm willing to answer any questions you might have, but I think that's in the question and answer room. So that's it. Okay.