>> So we're going to get this all going.
>> Okay, thank you very much. Today I am going to be presenting my topic which is 'Meddle: Framework for piggy- back fuzzing as well as it's pretty useful for reverse engineering, tool development as well. This presentation is not affiliated.

First I'm going to go over a little bit of background, then I'm going to go into the Meddle Framework itself then I'm going to go into a few examples of using the framework for several different purposes. One is, the first demo is attacking the OpenSource XRDP server and then afterwards we are going to go into go into dumping the devise IO control messages and I have written a parser to the capture into Windows Message Analyzer as well and if we have time we're going to…

>>[Audience] Can I interrupt momentarily? What's the initiation with first time speakers? 

>> That thing that I said wasn't going to happen, is happening. (Laughter) 

>.Speaker Okay, sorry about that guys. So first about myself, I'm visiting from Vancouver, Canada. I currently work at Microsoft, the presentation is not affiliated.   I originally got interested in re-engineering from game hacking, if anyone cares - probably not. So first I'm going to go over a little bit of background. There are several different types of Fuzzing…and some of these overlap with one another. They aren't exactly distinct. Like for example, File Format Fuzzing can be PDF for Microsoft Word meanwhile protocol Fuzzing could be things like RDP; Application Fuzzing could be COM objects or API calls and some of those cases you might be looking to say, escape a browser sandbox or it could be for elevation of privilege on the local machine. And web application Fuzzing is kind of a different story, it could be Joomia or web applications or looking for SQL injections. 

There's quite an array of existing Fuzzing tools out there right now.  A couple of these worth particular mention is I would say is SPIKE from Immunity is a very popular commercial one from my experience. Another couple worth mentioning is SAGE from Microsoft that is a really fascinating one that I'm going to go to go into a touch of detail on. The IOCtrlFuzzer from eSage Lab here is also really cool. It's actually running in the Windows driver mode and it Fuzzes all the driver communication coming from the driver itself. It's going to be related to one of our later examples where we're doing a similar thing from user mode. 

There are quite a few different Fuzzing algorithms, these are only a couple of the particular ones that I say are worth really good mentions. First, Naive protocol fuzzing, basically you don't understand anything about the file protocol itself. You would just basically randomly modify the data yourself and then load that data and application itself and hope that it would crash. So you don't know anything about the file and format, you don't know anything about the protocol.

Protocol aware fuzzing is where you understand certain thing about the, you might know a certain blob of blob of data represents a unicode string for example, maybe a length followed by unicode string and then you might try some specifically string related fuzzing attacks. You might try a format string, you might try, might try increasing the length of the string to be extremely large as well. So that's more protocol aware fuzzing where you have some underlying understanding of the protocol.

There's some real cool  examples of more Advanced algorithms, Auto Fuzz implemented a really cool protocol learning approach. You can give it multiple recordings of say client to server communications and then it builds a model of what it thinks that protocol is and then it starts fuzzing. So in that case it might recognize that this is  a string, this is a looks to be the command and this state leads to that state and then it might try some protocol specific attacks.

Feedback driven fuzzing is a really interesting approach when ran by quite a few people and it's used by Sage for example. It's where you actually do run time tracing of the application you are fuzzing and then you basically do controlling of the fuzzed input and then you see how it affects execution of the application you are fuzzing and then you can drive certain branches and conditions to be taken and explore deeper non accessible code so that's a really cool approach.

Google, well the code coverage fuzzing was proven very effective by Google. Google had a big fuzzier project where they fuzzed Adobe Flash, they built a collection of terabytes of Adobe Flash files, then they rendered each one of the those Adobe Flash files in an instrumented version of Flash Finery, and they recorded which code was executed with everyone of those flash files and then they reduced, they did a reduction then, they reduced the set of flash files to the minimum amount of flash  that gets complete code coverage within the Adobe flash library. So that way they know what they are now working with a set of Adobe flash files which gets code coverage as they can get using a small set of files. Then they began using the fuzzing and that was a really affective approach. I think they discovered over 200 vulnerabilities that were reported to Adobe. A very effective, very effective approach. 

So I'm going to give a quick introduction to a few of the more basic fuzzing algorithms. This is an example of file format fuzzing.  True type fonts have been the target of attack. I've seen quite a few cases where, the dokoo vulnerability, the dokoo government, well the dokoo apt, it exported vulnerability in their true type library because you can actually embed them say in a Word document and it will be installed when you render the Word document.   And it's actually, the true type fonts are actually rendered in the driver, in the kernel mode so they are rendered by 132k.sis, so if you open that document it gets remote code execution at the kernel level so it's already really screwed you. 

So, for a basic approach for fuzzing true type font, you would actually take an existing true type font and modify some of the data randomly creating thousands of variance in that true type font. And then you would install each of those fonts, render each font and then you would be hoping for the blue screen of death crashed report. As a really simple approach to it. But the true type font is actually really complicated because it's got it's own virtual machine language built in there, which they actually use for exploitive, which was rather impressive. 

So, another example of simple protocol fuzzing could be RDP, RDP client connecting up to an RDP server and you're just intercepting that network traffic that is being sent and received and you're just modifying some of that data in transit hoping for either the client or server to crash to indicate a vulnerability. So you'd queue up many of the RDP clients connecting up to the server constantly modifying the data hoping for, hoping to reveal a problem. But the problem here is that the later messages in the RDP protocol are actually encrypted messages, so it might not have quite the desired affect that you'd like unless you, unless you, unless you do the fuzzing before the encryption, internally within the RDP protocol.   

So an example.  How you can target the encrypted messages is you could do a client logic where you actually implement the fuzzing logic before the encrypting logic.  
Or you can actually take files approach starting the protocol as well for example.  

Lieu Wii gee and Romeo (indiscernible) had everyone really worried back in early 2012.  And when he posted his concept for an the Microsoft RD[P] vulnerability, his proof of concept was (indiscernible) the server and pipe in this binary provided.  Do this many times and you're going to see the RD[P] vulnerability.  There was a lot of worries surrounding this vulnerability, because it was hugely exploitable.  A lot of people are (indiscernible)ing internet.  And had a reliable (indiscernible) promote for this.  
But lucky for us, it was a really hard vulnerability.  And there's still no publicly known exploitation really.  
I'm just going to skip over it quickly, because I don't think we have enough time for that one. 
Now I'm going to go into metal.  It's open source frame work for vulnerability fuzzing.  You're going to be writing most of the plug ins in iron type font.  Which is basically the same as python for most purposes.  You can include (indiscernible) as far as I can tell, it's mostly the same.  The frame work itself is written in (indiscernible).  But you don't need to touch that.  You want to add functionality at the higher level.  I put a lot of work into making it support both 32 and 64‑bit process, so most everything you do is independent 64‑bit process. 
And unfortunately, it's Windows only. 

I haven't ... I've only been running this on a 64‑bit O[S] myself.  So I know it only works on 64‑bit or 32 against 64‑bit processes.  It still needs to be tested on a 32‑bit O[S].  But hopefully there shouldn't be any problems there . 
So the goal really is to bring real simplistic environment in order to write some fuzzing attacks.  And to be extendable, reproducible of course, because you want to know what caused the application crash to occur.  So the original goal is to go after piggy back fuzzing.  So you already have an RD[P] already for example.  So the idea is to automate many of those RD[P] clients mucking up the RD[P] server to implement the protocol for you. 
So the frame works consists of ... you only have to worry about the iron python stuff on the right.  It has one controller which is controlling the attack or measurement.  

And each controller can have multiple processes.  

Like you might be running 20 RD[P] clients in parallel all connecting to an RD[P] server.  And each process implemented multiple target.  Each target implements a set of hooks.  So you might have one target with win soft ten and one target for win soft receive.  And you might have a target that handle information to the process for example as well coordinating resolution.  
How generally how the controller, how you set up the controllers is it's ... the default controller have it running right now does a measurement baseline, first of all.  So it'll connect ... it'll create, say, an RD[P] client connecting up to the RD[P] server.  And in that process, it'll record say 100 messages sent to the server and three messages received. 
So that's instrumented as the baseline, first of all.  So you might ... in that process, it creates an RDP client, connects to the server, it'll probably wait about five or ten seconds and then it'll terminate the process.  And you have the measurement for baseline. Currently it's not the most intelligent way of doing it, Once it begins carrying out the attack, it creates, it sets up a work or two of processes.  So it'll be running 20 RD[P] clients in parallel.  You say those RD[P] clients is set up being ordered to attack a specific occurrence of specific events.  So the first process that's cued up, its goal is to attach the first message of the sent data.  The second process that's cued up is to attach the first mess OJ of the received data.  The second and third one is ... ... second message of the sent.  So in this way, you're fuzzying all the (indiscernible) messages ... ... the early messages from the protocol.  So it's just making sure your fuzzing the really deep messages in this case. 

And similarly, you're spending equal amount of time fuzzying the event type.  If you have an event that happens a thousand times vs. a up coL, you want to spent an equal amount of time, even though one occurs much more frequently than the other.  
So I'm going to go really quickly through what target looks like.  Everything is designed to be really quite simple.  So there isn't much code actually here.  So for the target, all you have to do is to implement the initialized (indiscernible) for whenever grade point is hit.  In the initialize, you just want to copy the stuff that's there.  And you want to modify these parameters in which functions and libraries will be considered.  The hook X words and symbols ... ... library will be considered for hooking.  And the symbols, if you enable the symbols library from the store, and hook in @ symbols that are loaded as well. 
The libraries just specify the libraries that will be considered.  You can specify them implicitly ... ...   soft is being targeted.  Or you could specify it by a (indiscernible) statement.  Similarly for functions.  You specify either the function names explicitly considered, or you specify red jacks which is an includes for the functions to be considered.  
   
So all this for initialize.  And great point hit is a bit more complicated.  For the parameters, first you specify the parameters, which is basically the arguments that are coming in at the great point location.  And enyou have to give it a calling convention and according to the processes it's attached to.  
So, this case, it's a pascal naming convention.  ... ... it needs to be transformed according to the process because it may be a 32 or a 64 process which influences the calling convention.  And then it transforms it into a registries specifications as well as a stack specification.  So it's going to make a sense in a second.  But it basically gives you an argument structure which has the parsed arguments.  And then you can access the verticals naturally. 
   
So this is what the parameters specification looks like.  This in this case we're hooking win soft send.  This does support complex structures is a fairly simple structure type.  
So we have, this is ordered, so make sure to put the arguments in order here. 
And here's ... here's the buffer.  If you look at the type of the buffer, that means it's a pointer.  Because it's ... the type of it is not numb.  In this case it's pointing to a method that knows how to parse this specific types.  In this case, it's parsed the buffer.  And that buffer is going to be a thick sized buffer, which is according to the argument (indiscernible).  So if the size variable is ten, you want it to only have .2 buffer size of ten.  So that's handed in through the type art for the reference to the argument.  
And the fuzz, the fuzz variable you have for each of the variable it's what the default action is you do with the w that parameter.  In this case, it's no fuzz for all of them.  We only want to fuzz the contents of the buffer.  We don't want to be fuzzing the contents of the buffer for example, in this case.  

This is what the parse buffer looks like.  If ... it returns just the same format.  Can be an array of parameters.  But in this case, it just returns ... it just searches upwards for the already resolved argument.  It needs to look up the size, what size of this, this buffer is and then it just adds it as a field called capital buffer.  
So, it ... so here, once you have the parse arguments, you can just do two string. And it's going to print all of them.  So here you can see the buffer is stored in RDX.  And the contents of the buffer is stored at that address.  And you can see the contents of the buffer, it's dumped hex 13 bytes of the buffer there.   
You can reference these fields naturally.  So you can do the argument for the buffer.  That is referring to the pointer of the buffer at that 2 string.  And now it's printing out the pointer as well as the contents of the buffer.  Or you could go right ahead right to the argument itself.  You can do arguments to the buffer and then dereference the pointer to the buffer two strings. 
So in the line above there, you see, it does arguments, dot size dot two‑inch.  
So when you reference a parameter like this you need to convert it to a type.  So, in a case like this this, you're converting the size to integer, because otherwise  it doesn't know how you want to access that underline type example.  So you can access them naturally once you have it parsed properly like that. 
The process is much simpler, which is great.  The only thing you have to change here is in the initialize, just specify the path to EXE as well as the command line.  You can attach to an existing running process if you include a pit instead.  In which case it'll ignore the arguments and attach the already running process if you include a pid as well, and it will ignore those 2 arguments directly attached to a already running process instead.  On the debugger attach, use the exact template in the examples except all you do is specify the targets that'll be added.  You can add multiple targets, but here is only adding the windsock_send to the target in this case.  
So the controller, the controller is the brains of it.  
It runs the measurements operates.  As well as the workers queue processes, which are running the attacks.  
The ... here's an example of how you do the measurement in the process.  The measurement phase.  You need to create a break point handler which the break point handler decides what to do with the fuzz information.  In this case, we just want to measure the fuzz blocks, for example, so you just create a break point measurement.  You create that process rdp and when you tell the controller engine to attach to it, the rdp process is already running with all the instrumentation. 
So just wait five second nd copy the measure out and stop it.  Now you're finish your baseline.  So you took your rdp client, you hook the windsock  32 function as it was loaded.  And connected to the server recorded all the communication, waiting five seconds and then terminate.  
The target brake point measurement just calls the target brake point handler recording a result. 
So now we finish the measurement part of it for the attack part of it.  You just implement a brake point attack instead of brake point measurement.  The brake point attack you tell it which event name as well as the number, the event number you would like to attach.  But you don't need to change any of this normally.  You can just use the existing template that's there for controller.  So normally, you just want to change the target and process implementation.  
So now I'm going to jump into the the first example of fuzzing ... the xrdp server.  So it's rdp server.  I've got it running on the VM right here.  
So this is the example of the target implementation here.  
So it's actually ... this one is very ... what we've been going through in an example so far targeting windsock 32 just a send example.  So here we're only hooking export to the library.  

So here I'm running it with a verbose flag so it connected up to the rdp server.  So it's just printing the buffers that are sent to the rdp server.  You can see these later messages here.  You don't see any clear text here because they're actually encrypted  blogs in the later communication.  But if I go up to the earlier communication, you can see clearly in some of the first messages, you see some clear ASCII.  It's connected to the server.  That's my computer name here for example. 
In this case it's, I just thought I'd show you what it looks like printing the buffers before I carry out the attack.  Now I'm running attack mode. 
And the first thing it does is a measurement, a process measurement right now. 
So it's recording the baseline.  So it's printed out that there were 20 messages involved with connecting unto that rod server.  And involved with 257 blocks.  
All the possible data is decomposed into eight byte chunks, blocks of fuzzable block.  Each one is considered a fuzz block, call add fuzz block with some logic. 
I I've got it set up to run 25 of the rdp clients in parallel right now. 
Let many go to control options.  
I'm running 25 of them parallel right now.  And they're going to each time out at five seconds and keep 20 of them running continuously. 
It usually only takes a matter of probably about one minute or so in order to crash the rdp  server right now.  Right now I'm running the old version which is vulnerable to vulnerability disclosures.  So you can see here, they're attacking all the different events of it right now. 
Some of the message blocks are coming up because it's failing to connect because it's buzzing with some of the early messages and causing it to lose connection. 
If I give it a few seconds, I'm hoping we're going to crash it.  And then I'll show you what the crash dump looks like. 
Come on.  Last time we ran it, it only took about 15 seconds or so.  I'm hoping this is going to crash in a second.  
It seems to be taking a little bit longer here than last time.  That's okay.  We're going to show another example in a second which is going to speed it up a little bit.  So back to the example, it still isn't ideal because you see the encrypted messages there deeper in the communication.  Although we are fuzzing that data, we're not fuzzing it properly, we don't know what type of encryption is applied to it, maybe there's some check, some checks assigned to it as well as for example.  
So, the problem is, now we have to figure out, we want to hook it before encryption as well. 

So, we may not know necessarily what the encryption protocols involved there so, I'm just going to be including target, which also paints the symbols along with the data. 
That is this one right oh here.  It's explicitly specifying the mstscax.  That's the library responsible for the rdp within the client.  And for the functions include statement, it included everything.  So everything internal symbol is hooked in this case.  And it's only hooking this symbols instead of the exports.  
And the brake point hit event with handler only prints the event name.  So then  we get an internal view of what it looks like.  I have to add that already. 
So now this is printing all the internal symbols but it's also printing the sent data at the same time.  So we have a frame of reference.  I'm just going to wait until it connects here.  What I'm going to look at is what's happening right before it's sends one of those encrypted messages internally. 
Sorry guys.  
So this one here is encrypted blobs that's being sent right here.  And you see just before it, it's calling all these send buffer functions.  I originally went ahead and looked and thought let's have a look at what the parameters are for these send buffers before encryption. See here, the encryption function is this RC4 which is being called shortly before the function is called.  So these send buffer functions, I found actually had really complex definitions that I wasn't able to easily reverse it.  But for the RC4 all you have to do is print, say define four arguments and all those pointers to buffers and just do print and you can clearly see what, based on the contents of that, it's clear to see which is which.  Which argument is which.  So that RC4  is the easiest one to hook.  So now, in this case, now this last target is attacking just that RC4 encrypted data.  
So here's it's just attacking the mstscax DLL.  RC4, which this one is a really simle definition, just key size buffer. 
So now I'm going to go ahead and carry that out for the buffer.  Now you can see the data here is looking much better now.  You can see msptc.exe there.  And here you can see my local machine time zone as well as my local IP  address as well.  So now the data's looking much better, it's looking not encrypted which is great.  Now I'm going to carry out that attack.  Which fuzzing the rdp buffer, instead of attacking the windsock messages.  So again it does the measure operation right there.  And it's found that there were 19 calls to RC4.  And of course 150 blocks of fuzzed data.  
So I was carrying out the same process here.  
And if you look closely at the screen you might ... actually, I already passed it.  
All right, that one's successful.  Now connect to the server because it's no longer there.  
I'm going to pull up the crash dump to show you what that looks like.  Although it's a fixed vulnerability now which could be one of a few. 
This one is the xrdp bit map compare with the CRC.  It had a fixed size array of the bit, in their bit map cashing.  And it's over flown, it's passed the ends of the bounds of the array.  Here you can see the self‑pointer is clearly incorrect, it's just a four by value, bf 5f.  And it tried to dereference a variable off it.  Which caused it to crash.  This vulnerability has fixed now, which is great.  

(Applause.)  That's it for the rdp example.  I'd be really careful about using open source  software for stuff.  Which might often be connected to the internet.  In this case, the rdp code, there were quite a lot of pretty bad vulnerabilities in it that can be exploited from remote execution even before authentication.  Even before authentication.  You should be careful about what code you have in your computers which is listening.  Especially if it's connected to the internet.  
So this right here is one of the other vulnerabilities where it creates a buffer, just 8KB for example, it doesn't even check when it copies data into it.  
So if the client says, oh, the size of the the field is actually bigger than that, it'll actually over flow that then.  That's another dangerous one.  

So now the second part of the presentation, I'm going to do a quick demonstration of hooking device control messages.  So device IO control messages are for low level communication firm from user mode up to drivers.  Drivers run in the kernel mode.
They can be used for things such as low level disk reading and writing as an example.  But it's used for all sorts of devices and drivers.  
So you might wonder what kind of devices are communicated with a normal basis.  This is a list of devices that are connected to notepad.  So if you start with notepad, you just do file save as, and browse the file save as dialogue that comes up, browse the network locations.  This is the list of the devices that are communicated with.  Like for example, I don't know what most of these are to be honest. NSI, point manager, lanmandatagram, et cetera.  
These ones here you see with the ... these are actually just file system accesses directly here. 
But in the add min divide NAD, in video add min device for example ... so here's a quick example of ... I'm not going to actually be attacking the device IO messages in this case.  You want to be careful if you do as well.  For example, we're a disk write operation, you could be corrupting stuff for your disk as well.  

So this is ... here, is actually going to be hooking ntdll hooking device profile.  Even though it says file in the same, that's actually the ... that's actually the lower level device IO control function.  Device IO  control file.  
And for when the break point hits, it's got more of a complex type here.  But again, this isn't a good example for complex type structures.  None of these are really complex structures in the case.  input buffer, output buffer - both of them are fix length buffers.  So it's rather simple calling convention.  And when this is hit, it's actually just logging it to a ... to basically csv file, which with the database 64 encoded.  Which then we're going to load into a windows message analyzer using a parser.  
So this is just printing the data again.  I've got it set upright now to often you might want to increase the surface it's testing by pairing it say with an autoscript.  In this case, using an autoscript for each process it attaches to to bring the style as well.  To (indiscernible).  Server.  
Here's what some of the log looks like in terms of who it's communicating with.  At the ver start it initializes within the admin device, ADVM.  I'm not sure what any of this communication is.  It's sending to the ADVM admin device, but also recording the output buffers as well.  
So when I ran that there, it was actually saving the data to capture that log there.  It's basically just a csv file.  And I've written and included window's message analyzer parser for it.  This is kind of what the parser looks like.  It's rather really simple.  It's, the only tricky part is the base 64 coding . 
And I'm just going to load up that capture file right now.  

So right now, it's ... the UI's been designed for multiple processes.  So you can capture with multiple processes.  
But in this case, we only have notepad, you could say expand this and it's grouped by the device it's communicating with.  And each of these, I've separated the input and out put buffers into two different messages currently.  And they decoded datas right here for example.  
So the idea is, with Windows ... for those of you who aren't familiar with Windows message analyzer, I think it was released in the last year by Microsoft.  It's a replacement to the Microsoft network monitor tool. The message analyzer is made to capture more generic messages.  So it capture and analyze network traffic for example.  But it's more designed for all types of Windows messages, so it could capture, it could process log files and event logs et cetera. 
It's much more generic then just network for all sorts of window's messages.  And if, although I haven't expanded on it, you can actually extend this as capture, this parser to parse the protocol for each of the individual devices you are communicating with.  You can write a parser for an admin device you start reverse engineering protocol for how it's communicating.

Okay, and I've just got one last simple account with you.  

So one last example here is say you're writing a sandbox using the frame work.  Right now it does support things like process forking.  But to be honest I've found a performance isn't quite what I wanted for currently for a sandbox.  You're going to find it's a little bit slower unfortunately.  

So in this case, I've written targets that handle several different things.  Like it's adding handle target, which is a  resolver for a handle identifier for names as well as it's adding a target to find what the clean modules are in the application.  So by default, it's currently not a really intelligent way of doing it.  It's assumes the first is module loaded is malicious and any module loaded afterwards is considered clean.  But say if they create (indiscernible) inject into it, that is also considered malicious, so only properly loaded modules is considered clean afterwards.  And it's logging registry.  And this log on trusted as logging, the exports of all dll's only if they're only logging at the function called incurred if it's coming from untrusted code.  Because you don't want to see every internal function that's called.  You want to see only if it's coming from untrusted code for example. 
And targets fork, is hooking the only the great process function.  So when it does create a process function, it will fork and attach on to the other process that's being created as well. 
But the performance isn't quite what I wanted unfortunately.  
But I'm working on improvement s for that.  

So here we're running notepad audi XE as a quick, simple example.  Now I'm just going to bring up the (indiscernible) dialogue, that will cause some registry changes. 
But as you can see, it's not the fastest, unfortunately.  
Give it a second, sorry.  
It should be almost there.  
I'm working on some ... I started working on a code in order to upgrade it right now using a native debugger engine.  And in in the future, I'd like to upgrade that to be not ... to actually attaching it to a debugger.  I want it to be more native based.  Not debugger based to improve the performance.  
So I'm just going to close that now.   Like I said, embarrassing slow.  
>>	Sorry?  
>>	(Inaudible - off mic). 
>>	You're right.  That is coming from each of the targets individually decides whether they want to hook the DLL.  So each of the targets want to hook each of the DLLs.  One of decides they want to hook 0.  One of them decides it wants to hook three of the exports.  Those are from two different targets, why you are seeing duplicate there.  Yup.  
So now that's actually created the log that, this events dot log here.  Which is the log file that recorded for that notepad run.  So if the registry handler is recording the query values, which is all of those.  
So this is where notepad itself is starting up.  It's recording all the export ... well whenever an export of any library is called from untrusted code, it's printing it out here.  So you can see what it's doing internally.  
And you should only be seeing what malicious code is calling in.  Like if kernel 32 calls NTD   function is automatically filtered out here.  
Yeah right now, it's automatically dereferencing strings at low level.  
So this right here comes common control dialogue 32 choose font W.  That's when I clicked on change the font.  So it's been recorded here.  And you'll see shortly after, it's going to set the values ... yeah, so now it's setting all the registry values as I hit okay, for example.  This is changing all the font settings.  And here, for example, it's changing it to the Times New Roman default font for notepad. 
And then you basically quits.  
One other thing is that I forgot to mention with the vulnerability fuzzing, each time it's creating a process, each process is logging into a file what changes it's made in the connection process.  And it's located in this log files folder.  
So when you have that rdp crash, for example, at the end of my last example, you can go ahead and refer to this log files folder and see how to reproduce the crash for example.  So it's going up sequentially.  So the last ones which communicated with it, were these bottom ones. 
So in these log files, you have this one didn't quite reach there.  
So these last processes I think were created but weren't able to connect to the server, that's why we're not seeing any fuzzing.  
Normally you'd see something like this where you'd see the brake point handler.  You see the arguments are passed in.  So you want ... if you want to reproduce this attack, you have to create a brake point attack sequentially use this seed number to reproduce the fuzzing decision.  And that tells you ... ... now it's buzzing block three from that from value of this to value of that for example.  So it uses several different algorithms because of the changing of keyword value. 
So in this case, it'll either flip a few random bits or modify a random byte in that keyword or modify a random word or D word in that section.  So, I think that about wraps up my presentation here.  Thanks very much for attending everyone.  

(Applause.)  Any questions?  I just realized I'll take ... okay yeah sure.  
>>	(Inaudible). 
>>	Yup.  Thank you.  Okay, thank you.