>> 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 64bit process, so most
everything you do is independent 64bit process. And unfortunately, it's Windows
only. I haven't.. I've only been running this on a 64bit O[S] myself. So I know it only
works on 64 bit or 32 against 64bit 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.