 All right, good afternoon, and thanks for coming out to see our talk. There's a great presentation across the way, so I'm glad you guys were interested in learning about things, what we have to say. So basically, we're going to talk about teal smithing. Using a case study is nightabridge, and we're also going to throw in some other things that we've done previously. First off, my name is Adam Pridgen, and this is Matthew Wollin-Leber. And as a brief introduction to what the presentation is going to cover, we're going to give an introduction to what we're actually going to talk about, you know, a little bit of background about teal smithing and such, then discuss what teal smithing is and the development process that we kind of use, and then we'll talk about some of the cases and shortcuts that we actually apply our techniques to, so that way you can see and real life how you could actually learn from this type of stuff. Then we'll talk a little bit about REBridge. It's basically an evolutionary project that just came out of a really random idea I was given to by a friend, and I had experienced previously, and so it's just kind of evolved from one thing into something grand and spectacular, but it's tedious to do software and development, so we use tool smithing and try to do rapid prototyping to help speed up the development process. And then we'll follow that up with some lessons learned from the various techniques and various processes that we've used, and then we'll talk conclusions and give special thanks. So just a brief background or introduction to me, I've been in information security for about seven years. Before that I was in the military, so I've always been really entrenched in attacker-defender type of mentality. So I got involved in security when I was at the University of Texas, so I've been a student. I've taught adjunct faculty in an adjunct faculty position before. I'm a pen tester, a reverser, and I love the right code. Finally I'm working at Pretorian, and my personal site is thecoverofnight.com, hence the green and black background. And this is Matt. Hi, my name is Matt Wallenover. I'm the incident team lead at the George Washington University. Primarily we focus on monitoring the network. It's fairly high throughput, we have two slash 16s. Also handle all the reversing, the binary analysis type stuff. I used to be a consultant, worked for the government, was a contractor, a pen tester. Basically decided that the only place that would put up with me was a university. So now I'm a staff there and hopefully I'll be a PhD student before too long. So a little bit of introduction to what we're actually doing here. It's a talk about tool smithing, it's a talk about Ida Ridge, but basically it all derives from one thing. We're sort of lazy, but we're OCD about getting things done. So we want to make sure that we surpass the expectations we have on projects, but we want to work smarter, not harder, so if we get a chance to write some code we want to do that. So basically a lot of this talk is tips and techniques to how to get that done while still doing short term projects that a lot of people are going to be familiar with. And a lot of it's experience based. So this is called tool smithing, it's based off of a lot of software development techniques in the past. It's something that Adam and I both do naturally and that he really picked up for this talk. It's intended to make the development process easier, faster, streamline it from not being a big software development project, but small tools meant to help get things done. Generally these aren't standalone applications or additions or add-ons to other programs that help you meet particular needs that you have for your project or whatever software you need to do. So it's not reinventing the wheel every time, it's adding on incrementally just to get stuff done. So really what we want to talk about are rapid prototyping, especially in time box windows. When we talk about tool smithing we're talking about prototyping capabilities. We're talking about saying I'm on a time box pen test and I need a tool that does X and Y and I need to model and conceptualize what I'm trying to accomplish. And then from that model conceptualization I'm trying to implement something so that I can get something useful out of it. The point being is you don't want to spend 16 hours when you have only a week to complete an engagement. The idea is to finish your script or your tool in a matter of like four to five hours and get it to a point where it's working and then you can actually apply it to something. The whole idea is to build something that's loose and open and then you can go back and improve it or release it or do whatever you want. But the primary goal is always to make everything you do into a specific functional task. So the way we look at this is sort of an evolutionary type thing. So you have your particular project requirements that you're doing. If you're a pen test you're on the gig for what, a week, maybe two. If it's malware or reversing you might have a bit longer. So from that you go into quick hacks that just make your life easier. After a while though you might be like, hey, this was a really good idea. We should make this something more. You sort of evolve into a proof of concept code. And this is something that is more than just a quick hack but it's just, hey, this bigger idea might actually work. From there you move into a bigger prototype. This is something that is your full idea. It's sort of where Ida Bridge slash RE Bridge is now it's there. It's working, it's bigger than something you do on a project. A lot of times we put into it but it's definitely not something that you'd think of as pushed out there software. And from there you have all of your tools and techniques. So you have this big thing that you have now and you should make your process better. Take in your tools to be able to deliver better services for whatever your next project is. So rapid prototyping. We've already emphasized this before. You need to meet an objective. You need to do it really quickly. It's often short-lived, it's time box development. So the idea is to find a task that's gonna only take you a couple hours or maybe even a day and use that as one of your primary milestones. And so what you do from there is you try to identify as many short cuts as you can possibly take, which means taking in open source software, looking for documentation and stuff along that lines. So we're gonna backped a little bit and talk a little bit about how we work in this type of environment. So first of all, in general, we work in ad hoc groups. It's not like someone comes in and says, I need a tool that is gonna get me root by, or get me passwords out of the registry because somebody saved their WinSEP key. It doesn't happen like that. It's very ad hoc, it's very fluid. So generally what happens is you'll find an objective that you need to meet. You'll be like, hey man, I don't know how to do this. Do you have any idea to start bouncing ideas off of each other? You'll write code together and then you'll just glue the code together and make it work. Now another drawback to this is putting these pieces together gets to be a little bit tedious. As you're rewriting code or updating code or merging code, it's all super frustrating. A bigger element of this is when you start looking at more complex ideas or more complex architectures, say like a distributed system. Distributed systems aren't something that people encounter on a day-to-day basis. So if you start looking at, okay, I wanna make tool X and tool Y talk to each other, how do I do that? I need to do it so that it's atomic so that any changes made don't tromp over changes made by a previous iteration. You need to make it so that the communication makes sense between the two. So you gotta kind of take up what you're trying to do and build a prototype so you can understand how the two are gonna actually interact. So this kind of goes back to Fred Brooks from the Mythical Man Month, where you just prototype so you build one to throw it away. So we tend to lean towards a more iterative process. So we write a basic tool. We get an idea of what went wrong, what went right. We take it and we iterate and we create a new tool based off of it. Or we create a new iteration, add more functionality or features based off of that. The idea is just to model it once or twice, get a good understanding or grasp of what's gonna happen, and then start working on what might be a final product. The idea is you're never gonna come up with a perfect solution the first time. And the more time you spend thinking about what you're gonna do, you're just gonna burn yourself out wasting time trying to figure out what's the right way to do things. So generally the third implementation is considered to be the best. In the case of Iderbridge, it took me three times to actually get a working command line interface that would interact with not only Iderbridge, but also interact with any other tools that we would want to connect up to it. So all that being said, most of this development depends on the project. That being said, there's a lot of common challenges. Okay, so one of the first things you need to do when you're expecting these projects is identify exactly what needs to happen. So I don't think people tend to have these immediate great ideas that just come to them. I think that more often it's a problem that you face from a particular gig, from a particular challenge, so you can identify what you need to do. From there you need to make your milestones. This seems a little bit formal for project development type stuff. But if you're working alone or you're on a project, maybe you've decided, hey, I could do this thing manually, or I could write some code for it. You gotta sort of set your guidelines of if I can't actually get my code to work, when do I need to call stop and push this off to something later? So milestones are key for that reason. Additionally, if you're, this is a personal project that's gonna take some more time, you need to be able to set these milestones so that you're getting there and so you can work with people. And so it doesn't just fall away as you have more needs to come up. Don't try to write more code. Lots of people are like, I've hacked out this many lines of code, this many things, so just focus on getting things done. To do this, you're gonna use different libraries, different code bases. You're gonna be reading through documentation. Basically, don't reinvent the wheel every time. And so we also have debugging and interaction. So when you write code for the very first time, you don't really know if it's gonna work, you have this general concept, you compile and run it. And it's like, there was a pointer bug or maybe it didn't initialize something. So having a good environment and interacting with the data and the functions that you're actually putting into the development process is actually one of those key things that people should really look at and evaluate as they're doing things. So going back to what we've just said, there are some ways to address some of these challenges. So for instance, open source is a great source for figuring out how to do certain things, figuring out how to perhaps make a client talk to a server. So instead of going back and rewriting the entire protocol, you just go and repurpose some code from another person's project. That being said, you can go through and review the code and figure out what is usable and what is not. And then just strip out what you need and get rid of the rest. So in that case, the existing code base is always fantastic. And this really, really helps out when you're starting to think about developing complex components and complex projects. For instance, if you want to build a DNS mapping tool, you don't go through and implement the entire DNS protocol. It's quite tedious. So what you do is you go download Binds implementation. You strip out their stuff, and you just take their protocol and you implement that into your project. Same thing with building something like a fuzzer. So here are some of the tools of the trade. In general, we try to use Python. But we want to say that using high-level languages abstracts a lot of the complexities away from what you're trying to do, dealing with pointer arithmetic, dealing with complex structures. A lot of this stuff can be modeled very quickly in Python, or Ruby if that's your particular flavor. And that being said, I've talked about using debugging arguments or debugging environments to help with data interaction or rapid prototyping to enable you to change the functions and build quickly or make sure everything works quickly. IPython or IRB are perfect environments for this. IPython I use on a regular basis. IDEs and debuggers are also a good source if you're working in a structured development project. Some other things that I've used in the past that we've used in the past are network sniffers, such as Wireshark and Mallory. And this just gives us an opportunity to change stuff around, flip bits, figure out if we're really parsing a protocol correctly or making sure that the messages that we're forming actually go out correctly. So some tools of the trade. One is make sure you look at the API documentation. Sometimes it's a bit tedious. If you're looking to do some assembly or some stuff there, don't read the whole Intel assembly architecture. It's like 15 pounds. But if there's some quick stuff, go to MSDN, figure out what to do rather than reversing a whole Microsoft library, just go to the documentation, figure out, use what works. Look for books and papers. This is along the same lines. Make things easy for yourself. Find out what works. Don't push out resources because you only reverse or you only do things by the API. And again, build off of other source codes that already exist. Real code usages are nice because it shows you, oh, this actually works. Experiment. So the big thing is the big emphasis is find as many shortcuts as you can. And generally this goes back to using open source software. But ideally what it could come down to is maybe you just, instead of opting to do something in C, C++ or Java, you just go straight to Python or Ruby. And then you find out what you really need to implement in those more complex languages. So in this first case, what we're going to talk about is how I went through and identified and decrypted when SCP keys out of a client's Windows registry. So basically what it came down to is I managed to break into this host on a paid gig so it wasn't illegal. And I noticed that in the registry I found some keys that had password associated with them. When I went back and looked, it actually corresponded to the when SCP application. So rather than trying to reinvent the wheel, well, first of all, I thought, well, I wanna get at that. I know that those passwords have to be reversible because they're passed on to the client at some point. So it was like, how do I do this? I could do something really complex like attach a debugger or I could do something really quick like download the source code and review it. So what I did is I downloaded the when SCP stuff and found that there were some pretty nifty APIs that do the encryption and decryption. Now, for anyone that's curious, if you've ever installed one SCP, your passwords are actually saved and encoded format under sessions. And then, somebody like me can actually come back and steal them and decrypt them and get access to whatever you have. So the way I found it is I basically grep for encrypt and then I grep for password and these few things popped up. So starting off with the process, I found these API calls and then I went even further and I found the function definitions. And I noticed that this is just encrypting by an XOR and then hexifying it. So I wrote a quick Python script to decrypt it. So, you know, this is just basically showing how I took it in. So the first thing I did is I popped up IPython and port been asking unhexify it and now I have the data to work with. So the next thing I do is I go through and I write the decryption implementation. Unfortunately, in this particular case, I made a mistake because the output isn't anything legible or anything that I can really use. So I went back and I reviewed and I noticed, hey, I left a little till day off for the unary stuff. So by implementing this stuff or implementing this in IPython or by prototyping this in IPython, I was able to quickly get something back without having to write a script, run a script and having a non-interactive environment. So, you know, the whole premise was being able to write out a quick script, debug the code very quickly, modify the functions as needed and then move on to the next kill. So IPython was one of those interactive environments that helped give me this edge. So, we'll move on to our second case study. This goes back to when I was a pen tester again. One of the things I find a lot is that you'll get a tough engagement. They've already patched everything before. It's the one time of the year that they managed to patch this right before the pen testers come in. It's that ground rules, you can't bring in any zero days and they make things basically impossible. So, what I like to do is when you get in-house, look for some custom software, either something they wrote in-house or something that they brought from a small vendor that caters to their particular industry. And then I try to reverse that and find an exploit for it in a short amount of time. For small applications, this is pretty easy to do. I tend to like to focus on things that load in the browser. But you have some problems that the modules are loaded as they're needed. You can run through hundreds of iterations. And if you're trying to do a full trace on this or if you're trying to manually debug it, you're just gonna spend far, far too much time. So I created some add-ons to immunity debug. It's a nice interface. It's basically Oli debug with Python built in and a nice API. So basically, again, it's three quick scripts to do some lazy man tracing. If you were lucky enough and you had Ben Navi, you might not need to do this, but you don't always have that. So basically what happened is that I identified the vulnerable code. I knew what was happening. You had the crash there. And I wanted to develop some scripts that would sort of get me there so I could figure out exactly where the taint happened and work my way backwards. Now the initial thing was I could use load.dll hook, which is an API that's made available by immunity debugger. But basically it didn't work. I had to use BP hook. I spent hours and hours trying to make this work. Eventually the easiest way was just to go back and talk to immunity. Maybe they fixed it by now, but as of a year or so ago it was still broken. So here are two examples of the scripts. On the left-hand side, it's just a script that's loaded in immunity. It looks for all the modules loaded. And once it's there, it sort of stalks and sets a break point for the particular module. The way it does it is on the right. Basically it finds a load library, but load library A and load library W because you might have the wide bytes. And just puts a hook on those functions. So anytime the module's loaded or unloaded in there, it basically says, okay, I'm gonna set a break point and then you can use it inside the scripting to do your automated type stuff. So in this particular example, it was inside a browser as a custom plugin that they were using and it was loaded hundreds of times for each page that was there. So if you were doing this manually or if you said immunity debugger to load and to break on each module on loading, you just spent hours and hours. So this way you did it in code was much quicker. Here's a bit more in-depth of the class that you have to overload to be able to do that. Basically it's just using a variable to set a count to how many times you're gonna wait and let this load. So it's gonna have hundreds of objects on a page. You know that it's not in the first 50, you iterate through, it's not in the first 100. So you keep upping that count and eventually you let it load and let it run. And let's say on the 205th time, this is the one that you care about. You're there at the break point. You haven't spent hours and hours doing this stuff and you can start debugging backwards by maybe doing a small trace there forward or manually reversing it. And here are two more examples. So if you're still lazy and you wanna do this all automated, maybe you wanna let it run many, many times. You wanna get a lot of variables, information. So on the left it's just dumping the register values. On the right it's just doing the call stack trace. So basically it's just doing light tracing. You know where the problem happens. You get the debugger to iterate through those hundreds of steps and then you get it to dump the information that you care about at the last minute. That way you don't spend all your time there because you have other hosts to deal with. You have other things to break into. And basically what this enabled me to do was to fastly, to quickly reverse and find the taint and some small stack overflow that was used in our browser that seemed like this really cool thing. So within a week I was able to find a problem and exploit it and gain further access in the systems based on a couple of scripts. So the next case we're gonna talk about is Ida Pro scripting. In this particular case, Ida Pro offers you Ida Python which is a Python environment that you get to run Python code in. You can't prototype outside of it so you have to do it in a very piecewise fashion. And that kind of hinders the debugging process and it's also not very straightforward about how to get around. So the trick is writing small little scriptlets so that you can get to the point where you're actually doing something interesting. So this basic example is actually comes from an elf header parser I had to do in order to update the relocateables and the elf header that I was looking at for an arm binary. So basically as I said I had to do it piece by piece. One of the big things about Ida Pro is when you're running or one of the crazy things about Ida Pro or the more unforgiving things is if you run an Ida Python script and you start stomping around your IDB there's no control C, there's no going backwards. So there's no real undo. So you wanna make sure what you're doing is effective at least in the first or two iterations with small, small function calls or whatever. So in this particular case I wrote this basic function that would parse out the E header and give me a nice clean looking elf header. Unfortunately when I did this I had a bug in it and I wouldn't have caught it and it could have resulted in a more potentially disastrous outcome where I would have to revert back to my original IDB and if I hadn't backed it up that means I have to start all over after I've marked stuff up. So in this case I kind of illustrate that file start wasn't initialized in this particular function that I'm calling and so it could have been anything. So it could have been in the middle of the IDB and so if that was the case then I would have just stomped out any code or comments that I would have put in there. So as I said there's no control Z so there's no going back. So the whole idea is to implement your code in small segments and then do it iteratively as you work through the process. So after I fix a small little bug I was able to get an elf header, surprise, yay. So the next case that we're gonna talk about is code writing code. This is one of the things I don't emphasize enough when people are doing software development. So the idea is to write little scripts that write C code or write Python code for you. What this generally entails is you write a whole bunch of definitions for commands or the messages or you wanna script it in some way so you don't have to write all of the commands or messages for like a string. The best way to do it is write a script that's gonna do it for you. That helps speed up the development process and you don't have to spend all that time going through typing it in and possibly making typos. Additionally you can actually reuse the script later on if you decide that you wanna make some changes. So in this particular case I had all these definitions that I wanted to first of all export to Python and then second of all make string definitions. So this is actually kind of a lot of stuff to do for one person. It kind of drives me nuts when I have to go back and do stuff like this because I'd rather do stuff like solve a problem, not do data entry. So in this particular case, I used IPython again, I basically busted out all the lines and then I went through each definition and I saw if it had an underscore or not and if it had an underscore I put an S in front of it and then from there I get this nice little output where I get the pound F, the string underscore BP hit and then I get a string that represents that command in a lower case fashion. Now doing all the data entry for me is kind of boring. Some people might like to do it because that's what they do but I figured this would be really interesting or not really interesting but really useful because I don't wanna have to do this ever again. I just wanna be able to plug something in, run it, check it over real quick and then plop it in my source code. Additionally with doing stuff in Python, we're exporting the Python. In Python, I realized that I wanted to change the case convention of everything I was and use a more standard development convention so that if I ever gave this code to anybody they would understand what's going on. So I basically went through and I lower case everything and put it into or I just modified it, did a quick update without actually having to go through and correct the case for everything. So the final case is more to do with adding functionality to an external library and this kind of goes back to the whole use open source model. So what happened was I needed to, well, what I was trying to do is I was trying to model the communication, I was trying to get the communication to work between my debuggers and IDA Pro. The thing is I was doing all this in C++. Anyone who's developed in C++ or done C++ development realizes it gets really tedious and gets really difficult to implement stuff. I wanted to use Python but in order to use IDA Python with my plugin I would have to use an external language call and then once I do the external language call I don't actually get the side effect of when I ran my command. So what I really wanted was I wanted to be able to load IDA Python and with the IDA Python DLL or the module and so my code so that I could actually make those functions calls. But IDA Python doesn't really allow this naturally so I had to go through and add my own exports. And so by adding my own exports I can only save time up front because I was able to now use Python in my application but I also save time because I can use Python. I can prototype in Python. I can write 100 plus lines of code for every three or four lines of C++ code that I have to write and debug or that's an exaggeration. But I hopefully you get the point that using higher level languages is a lot easier than using lower level languages. So now all I have to do is import the module into my code and call the function and life is great. Life is easy. Okay so now we're gonna actually talk about RE bridge. It was originally called IDA bridge. The basic idea started, we have all our debuggers. Everybody seems to use IDA but you might prefer a community debugger. You might prefer a wind debug and you can't get the things to talk. Sure IDA has its own debuggers in it but they're pretty terrible to use. At least I find them terrible to use. So you have your own debugger that you have all your scripts for you have. You're just used to doing it and you just wanna convert things back over to IDA sometimes. So basically just wanted the tools to be able to talk to each other. So originally it was IDA bridge but then we thought, okay well all these tools might wanna talk to each other. A lot of the scripts we showed you before were sort of reversing type things but it mainly stemmed around they didn't talk to each other. You need to get information from one source to the other and RE bridge is sort of hoping to do this. So it's trying to fill a very specific gap. It's basically middleware. It's nothing super exciting but it lets your tools talk to each other. So if you have breakpoint set in IDA you can push them over to a wind debug or you can move data back and forth between them. So it just makes things a little bit easier. So like Matt was saying, RE bridge is a middleware. It's not meant to be an implementation for another reverse engineering tool. It's not meant to do X, Y and Z. It's meant to fill a gap, give you a server that sits between or a server and a client that sits between your IDA pro and your debugger or hopefully in the future debugger or a fuzzer and then they can communicate with each other. They can send each other messages and they all understand the messages. And so basically no one's reinventing new tools they're just reinventing a communication stack. So like we said, it's the whole idea is to make the tools interact with each other, give users the ability to control their tools from one tool or another and then also build it out as a distributed framework so that way you don't have to reverse from on the same machine. So if say I'm using IDA pro on my windows machine and I'm reverse engineering a Linux machine, I don't have to use VMware. I can just put it on a remote hardware somewhere and just make them talk across the network. And of course IDA pro does have the debugger functionality written into it but if anyone's ever tried to use the debugger it's very difficult to understand. It's difficult to use and get set up in the initial stages. So having something where you can just use a native debugger that you're always used to and not having to use somebody else's GUI or somebody else's being constrained to somebody else's tool that you don't appreciate is a huge plus. And the additional thing that we wanna do is we wanna make this middleware extendable. We want to make the middleware extendable using stuff like Python or Ruby. So we have several components that we've built out so far. The first one is the IDA bridge. It's basically a command line interface that uses asynchronous server or networking client that we pulled from collaborating. Again, we're emphasizing that you should use open source tools or open source software that's already implemented stuff to incorporate into your software. And then what we did is we modified the IDA Python lip so that way we don't have to go through and rewrite everything and see your C++ to do the actual interfacing with IDA pro. We can just rely completely on Python. And that also gave us another one because we can extend our Python classes or we can extend our handler classes using Python. So if we wanna add a new command, we just write a new Python class with the defined command elements and then we just roll from there. So we also use, we also for this implementation incorporated V trace or VDB, which is a product of Concerto and a Visigoth. So basically for VDB, we added in asynchronous server into the command line. And again, we use Python to be able to extend the handlers as needed. And so anyone that's familiar with the framework or understands how to write the plugins can actually go through and write the plugins. And again, you can also do it to the point where you could just load it in and using the Python interface. So that brings us to the bastard child of them all, WinDebug. So WinDebug, when I started working didn't really have a Python interface that I could actually load in as a plugin. So currently it's only implemented in C++. So it's incredibly difficult to add new, or it's more difficult to add new commands and make everything work and talk very quickly without having to go through recompile and testing all the time. But it does have the asynchronous server, which we also pull from another open source project by a Duke and by Lenox and Puscat. So basically we got all this stuff going. It's still an iterative process, but we have a few lessons that we learned from it. Basically as Adam said a lot, we like high level languages, I'm a native C programmer, but I appreciate that we're trying to get something done. Python or Ruby or something makes things a lot easier. Documentation is not always useful, sometimes it can be, but make sure you find examples in source code and just ping people when things aren't working, don't waste too much time. Believe in that the documentation is right and that you're doing something wrong because sometimes there's a gap. Write scripts to make things as automated as possible. Spend time thinking about what the model is and what you're really trying to do. And implement iteratively and understand iteratively. Don't try to build one big monolithic thing, solve little problems, then try to piece your code together. Yeah, the key thing is look for small milestones that you can accomplish over a long period of time. Cause the more small milestones that you can pile up or that you can complete over a few days or a few weeks, the more likely you'll move towards something. As you start building out, as you start dreaming big and start saying, I'm gonna implement all of this in one sitting, you start to become a little bit more bogged down because you're becoming more concerned with, oh, I'm not getting this done or I'm falling behind. And then it's just, it starts to propagate or it starts to become a little bit more cumbersome to deal with. So from personal experience, I've learned that the more small things that I say I'm gonna accomplish, the bigger things start to, or the small things start to add up to those bigger things. So some of our conclusions, basically try to use rapid prototyping as much as possible. We like coming from ideas from real world type thing, not just thinking of them being clever yourself, but here's a problem you have from pen testing. Here's a problem you have reversing some malware or here's a bug that you found. Go from what you need to get these actual jobs done as opposed to trying to think things through all at the beginning. Always use scripts. If you're doing something that's very tedious or painful while you're debugging or reversing, write a script for it. Make it useful and then from there, it tends that the way that you're doing it works out better overall. And so, in addition, we've introduced our eBridge model. It's basically a distributed network or a distributed framework that's gonna hopefully be a middleware that allows independent tools to integrate and talk to each other. Currently what we have is kind of like an alpha piece of software where it basically allows Ida Pro to talk to either one debugger or the other. But hopefully we would like to make this a little bit more interesting where we say, okay, let's connect more elements to the party and see if we can get more information being shared, more data being sifted through so that way we get more interesting results. And the whole idea is also to enable multiple users to share on the same session. So something like Collaborate, but on a more heterogenous playing field where basically we're starting to incorporate frameworks such as Radar or Bennavi or multiple debugger types into a single distributed session. So some related work that we've had, that we've experienced is, of course, Collaborate, which basically uses a central repo that maintains IDBs and allows users to make modifications and share those modifications out with others. So multiple users can actually connect and mark up the IDBs. Another one is Bencrowd, which is a product of Ben, of... Dynamics. Dynamics, sorry, there's a bug there. And this is basically a repo where users upload comments and functions from IDA Pro. And then they can share it with others and others can actually get the information that's already been shared or been revealed or identified by other people inside the crowd. So basically people get to reuse the work of others. There's also another project that we took from Biokugin, which is a little bit different. It's actually a vulnerability research and visualization tool that allows people to use Metasploit and WinDebug to speed up the vulnerability research process. And so with that being said, we'd like to offer special thanks to SciPy for creating iPython. Chris Eagle and Tim Vadas for Collaborate, E or Deli, and HexRace for Iodipython, Postcat and Linux for Biokugin and Visigoth and Conchotto for V-Trace. If you guys are interested in the code or the presentation slides, you should be able to find them from the GitHub link here at Matt's account, so you won't be hacking mine. Thanks. So are there any questions or comments? We kind of blaze through that pretty quickly. Yeah, yeah, right on. We're done.