This Chip Does Not Exist: Pre-Silicon Fuzzing

[Music] my name is Ron Hart I'm a security researcher at Intel um I've I've been there about a year I graduated from Purdue in December uh from the Masters program um so I'm pretty fresh but my my focus and the team that I'm I'm on is focused on system software security so that means basically kernel and Below um so we'll talk about that stack but that's a little bit of my background I'm I'm very focused on fuzzing symbolic execution program analysis that type of thing um and my main weakness is that I never use any of the tools I make I just make the tools and then hope somebody will pick them up first of all don't sue

me please uh and also more importantly don't Su the company um and this slide says as far as I'm aware you're not allowed to so we're all good so there's a there's a full talk about fuzzing so I'm not going to go super in depth but just by show of hands who uh knows what fuzzing is okay almost everybody excellent that's kind of what I figured um and uh who has used AFL ++ in the last 2 years okay pretty good pretty good so um OG fuzzing cat Dev you random into your binary uh shocking amount of stuff crashes this was uh I was a teaching assistant in school and this is actually one of uh my hidden test cases on every

assignment was this um not many points but uh not a whole lot of points gotten on that one so nowadays we do it a lot smarter we use mutators we use feedback we observe the program State we do symbolic tracing of paths as we're executing we use hypervisors all of this stuff um and I'm going to talk about how we've done a little bit of smarter fuzzing but um one thing that I really want to focus on is how fuzzing can be used not just for finding OD days in in stuff um you know that's a great use case for it gets you a lot of cloud on Twitter X whatever it is um but you know we can use fuzzing for

for a lot of more normal development practices as well uh differential fuzz testing allows us to if we're developing a new version of a product test against the old version of the product and make sure that things function the same so users won't see discrepancies and how end points are behaving that sort of thing um we can use it for property testing and say okay instead of building a unit test with 50 cases we're just going to say this is never allowed to be more than five fuzz it make sure it's never more than five after 10 minutes and you're pretty much good to go um so things like that are really good applications of fuzzing that we want to

see adopted more as we do what my team is focused on and shift fuzzing as we say to the left which is uh make developers do it instead of having red team come behind and clean everybody up because it just doesn't scale when you're trying to have a team of eight people fuzz a 100 projects a year U it's just on a numbers game it doesn't work so fuzzing super effective but not a silver bullet of course we still need those red teams to come behind and we want them to focus on things like if you were watching last week the LI web pebg where fuzzing probably isn't going to find that one uh as a summary basically you had to have

six trees beta trees constructed exactly correctly and then you had you had to mess up the last one so that it would be corrupted the fuzzer is going to have some trouble reaching that state it might get there eventually Thousand Years 2,000 years something like that but we need we need manual analysis as well so that's that's a very important thing to keep in mind building fuzzers so at Intel we use a lot of fuzzers because we have a lot of software uh as you probably are aware we make CPUs um but we also make everything above that in the tech stack we do CPUs we do the firmware that runs on them we do the micro code below that firmware we

do the operating system on top of it we build the driver support for all of the hardware that we produce we build user space applications for the operating system that we're helping to support and we build web applications that you can reach over the Internet running on those operating systems and user space applications so we need fuzzers for every layer of that stack because we want to test for those types of assumptions that we covered as well as most importantly for security vulnerabilities so this is not an exhaustive list um but this is just kind of an overview of some examples of fuzzers that we use for various levels of of stuff we have the developer of BU

fuzz here go talk to him uh at some point uh great for Network fuzzing there's a workshop later um and then we also use wrestler for rest apis and web API fuzzing obviously user space is one of the most fuzzed spaces and we have really good support for enabling developers to do user space fuzzing with lib fuzzer you add a compile flag you write four lines of c and you're basically done you can't really ask for much better than that and that's the kind of that's the kind of development practice I we want to bring down the stack because as you go down it gets more difficult to harness things and more difficult to fuzz them so in the

kernel we move towards hypervisor based fuzzers because you need to boot a machine over and over you need to run it and specific uh device test paths so for example you need to fuzz uh virtual IO drivers you need to boot your devices and you need to F A hypervisor for that of course most hypervisors are based on kumu so from our most recent server CPU release the sapphire rapid CPUs is released around January to March and Kim support was added in April so that's that's pretty good that's really fast on the Kimi developers and they're amazing but we need a little bit better than that if we want to test our firmware before the CPUs come out um so KFL KFX

those are hypervisor based fuzzers they both require chemu support because they're using it under the hood below that when we're looking at system management interfaces we have an old tool called excite which I'll talk about this project is actually a successor to that one um and then even below that for some very custom deep features like the Intel management engine teams are generally using Uh custom Forks of fuzzers fuzzing things that are built in very specific ways um so we get pretty pretty hardcore there um and then even below that when we're at the hardware description language layer where we're looking at vhdl models of CPUs that are not produced not even modeled not emulated nothing um we can fuzz them at

the uh RTL or vhdl layer uh with tools like pressy fuzz which I think is actually on GitHub now so you can look that one up as well so more of the story there are a lot of fuzzers um so let's let's rewind and let's look at the use case that uh my team is trying to T tackle so we have CPUs we want to make the CPUs and we need to ship them with firmware when we ship the CPU and developing firmware takes a long time almost as long as designing the actual chip itself so you have to do the firmware design while you are doing the chip design um the problem with that is

how do you run firmware for a chip that you don't have um you need to virtualize emulate Etc um but the use case most of you may have seen is uh noticing something sketchy going on with your router um and I was in this situation a while ago I was looking at my router's JavaScript which you should never do tonight um and noticing some very interesting things that Sentry Link had put in there so uh what I did was I you know hit firmware update got into wire shark grabbed the grabbed the firmware download you know it basically just gives you an entire root file system so you unpack that um and then it actually

downloaded an old version cuz it has a bug so you need to fix the vendors code now and you need to download the real version um yes fun fact my router updates itself to the same version it's on only um so you need to download the real version by guessing their URL scheme then uh you you run Kimu in the unpacked root file system if you're really lucky um and your router is in X8 six machine it'll probably run uh but more likely it's it's running myips so you're going to need to Google that and somebody's blog is going to tell you that lib and v.o from this GitHub repo that uh you need to hit translate on is going to

work so you download it and you compile it on your machine you don't read the code um and then you put it in the root file system and it indeed does work because some people are really smart so you run Kimu fun fact this is actually by far my favorite way to emulate emulate routers is just run Kimu user on busy box in the unpacked root file system that's all you need to do you don't need to do Kimu system you don't need to do devices in most cases just do Kim user with the with the unpacked file system um and then uh yeah if you do need to do devices good luck so for us

it looks a little bit different at Intel uh you know we're not we're not working on your your ziel router and your wall that's been there for 15 years uh we're working on new stuff and we don't have the chips for it we don't have Chu support so uh we have a few options basically for how we want to run the firmware that we want to fuzz we can run it on real Hardware we need the hardware so that one's out um we can virtualize the hardware totally doable and will be done but usually it takes a long time uh which is kind of the issue and is not done early in the chip development

process or uh we can stub out the hardware so this means you go through your your firmware C code anywhere where it makes a call down to some feature in Hardware you just replace it with the c function that Returns the right value so you know if you're reading a model specific register in your CPU it's probably not going to work if you don't have it but if you just replace that function with something that returns zero every time you're probably going to be okay so we don't have this we don't have the CPUs we don't have virtualization and most importantly we do not have any time uh so it's a really hard cell as many of

you are probably aware to go to a development team that has a bunch of Sprints and a bunch of upcoming deadlines and say hey we need you to stub out all of your Hardware functionality so that we can fuzz your stuff it's just not going to happen so developers don't have time QA doesn't have time validation doesn't have time and the red team has some time but there's only five of them so what we need to do do is make it possible for developers to fuzz stuff without doing any work so they need to be able to install it and they need to be able to copy and paste all of the instructions to install

it because again and this is not a knock on any developers it's our fault as fuzzer authors for making our install processes so difficult if you have more than five options it's too many so you need to be able to install with a couple steps you need to be able to add your fuzzer into whatever development process is already happening so if they if if your development team is using make file driven development on Linux and it's just pure bespoke make files you need to work with that if they're using visual studio and they have a bunch of solutions everywhere and they're using uh all of Microsoft Macro systems and whatever they do I'm not a Windows

person um you need to work with that as well and finally it needs to be a good fuzzer so despite all of the all of the ease of use things that we need which are in my opinion the most important uh you know you can't just pipe de random into your program because that's not going to cut it it's 2023 so we made that fuzzer in theory uh it's called Target software fuzzer for simix which is a very nice legal approved name and not the original name we picked um but luckily it kind of sounds like tisus if you say it badly enough so I drew I drew some art for that and and away we go so tisus is

based on a simulation platform that we use at Intel that's also publicly available which is why I'm here telling you about it um it's called simix which as far as I'm aware doesn't actually stand for anything kind of like Kimu doesn't stand for anything except used to stand for quick emulator um and what simix is is a full system cycle accurate device modeling software so that device can be and usually is a CPU but it can also be a graphics card a network interface it can be a TPM um any of these things are modelable in simix and basically what you do you download simix you create a project you add a bunch of existing models to it because they are

tough to make you know not as hard as actually designing the CPU but as you can imagine modeling modeling a modern CPU is quite difficult um if you've ever tried to write an emulator um so you you plug in your your server CPU you plug in a TPM you plug in a a arc graphics card or whatever it may be you don't get those models um and then you boot it and it runs cycle accurate simulated including uh Power thermals all of that simulation on your Linux system in user space which is the key so tifus is of course Very uh AFL Plus+ style it's feedback directed uh we have comparison logging uh with red queen it's snapshot

based which is free for us because we're using simix which has snapshots you can launch as many processes as you want um and they'll all synchronize together so um we we'll get into some simic specific stuff in a minute but that's very useful for our specific use case and uh yeah basically we threw the kitchen of all current uh system software fuzzing Research into it it has mop it has Auto tokenization it has all kinds of mutations um there's a short list of things it doesn't have that we'll get to at the end so why simix first of all the number one reason is because everybody at Intel is using it for all of their firmware

development which means if everybody's already using it we can just ask them to plug a little plug one thing into this and now it'll fuzz instead of just running your software not bad for the developer perspective um from the fuzzer design perspective it's pretty amazing to work with having come from a let's Fork Kimu again background um because in instead of adding functionality to Kimu to add snapshots or add introspection which um fun fact is still not allowed in Kimu because of GPL violation rules um unless you unless you have a fork which there are several um if you want to read a register you call a function if you want to read memory you call a function if you want

to figure out what the thermal change over the execution of your your new hardware instruction was you call a function if you want to get the hash of all of your model specific registers for the CPU that you're running you call a function so there's a lot of really powerful stuff and we're only kind of scratching the surface at the moment but a lot of really powerful stuff you can do with simix that kind of is enabled because it's not designed as a scalable you know Cloud hyperscaler let's give people virtual machines emulator it's designed as a test bed it's designed for debugging um and all of that stuff so um second key feature is uh that I had to

do about 1 hour of work to get snapshots working with my fuzz uh because once again if you want to take a snapshot you call a function and then if you want to restore to it you call another one so um simix basically provides all of the hard stuff for us to build on top of and build our fuzzing research on top of so that's great for us you know we have models for all of our upcoming software but what about all of you who maybe do not work at Intel so uh simix is publicly available you can you can go on Google if you say download Intel simix there's a web page you can download it

and I actually found this out last week when I was checking to make the slides but it has all of our current currently available CPUs in it so uh if you want to go home and run a sapphire rapid CPU you can do that actually um if you want to do some research on those have at it you they're they're available to you so 12th generation client and Sapphire rapid C uh server CPUs are available in public simix so um it's it's at least on par and slightly ahead of actually Kim's release schedule for being able to uh emulate or simulate modern CPU uh designs we also have publicly available risk 5 models which the fuzzer doesn't

support yet but definitely will because there's a lot of people who are very interested in doing uh risk 5 research fuzzing uh firmware for risk 5 platforms like um all of the pine and orange pie type boards and things like that as well as mobile phone devices and finally for a developer experience we get free time travel debugging bug triage read all of the registers read all of the memory forward and backward step inspect everything and figure out why your firmware is crashing uh which is really important for the developers um a when they're you know categorizing their bugs and figuring out okay what stuff do we work on first um and B is very useful from a once they

start to work on it it's very quick to get to the root cause of the issue uh when you have basically every possible uh piece of data available to you second thing we do to get some free stuff is we don't Fork AFL um so this is not a talk about not forking AFL but I've done it three times I'm sure some of you in the audience have done it probably more than that um but there's a better way now and it's called live AFL so so uh lib AFL is a a library that's written in Rust and essentially what it does is Implement every part of AFL ++ as a library that you can just import

from create your own fuzzer using all of those uh components which includes basically uh from the binary up you you have a back end which may be uh Kimu it may be NYX kemu it may be KVM Kimu whatever it may be uh we have Freda which if you're in iOS or an Android reverse engineer or uh or security researcher you probably know Freda and are a big fan and uh tiny instrumentation for for really good Windows speed and instrumentation and then of course uh you can run native binaries you can run forking binaries you can run you know harness your library whatever whatever you may want to do with it um and the modular

approach approach is super helpful because you kind of pick a back end you pick all of your your fuzzer capabilities so if you need concolic tracing Li AFL has it you can add that in not every Target needs it so you get to choose whether you know you want to enable various stages you want to enable Red Queen your your uh program is parsing text so you want to enable grimoire which is a a gar mutator for for mostly English text um all of those are options with li AFL so um if you are a researcher in fuzzing and you're trying to implement new techniques for example you have a new power schedule you have a new mutator Li AFL is kind of

the perfect place to do that because you uh you just write it you test it out locally and then when you're done you can Upstream it and then everybody else can use it you can go to the conference and talk about it but it'll actually uh probably get used in production if you Upstream it to lfl uh instead of like me your three or four AFL Forks sitting on your GitHub for years with 16 to 25 Stars pretty respectable uh but not a whole lot of uh active use in in industry or research so big shout out to the LI AFL team for putting together such a such a great tool and uh I actually did license this

meme from the original Creator so you can't Su me for that either all right so that's that's what we get for free so this is what we are giving other people for free um as I mentioned pretty much everybody working on firmware in BIOS that Intel uses simix every day they you know make some changes to the BIOS they boot it in simix they see how it works make some test cases for it iterative development process um what we've given them is a three-step install process which is not one but is a little bit less than the five which I I use as my guideline so not bad you install rust you set an environment variable and then you run

build not great we can reduce it to two technically um maybe next week when we when we merge some patches um then to enable fuzzing in an existing simix project you add two or three lines of code um you basically initialize the fuzzer and then you say uh here's the things that I want to consider as crashes and then you say go fuzz it um you also have to add a harness to your to your C program unfortunately we give uh we have a triage mode where you drop directly into a the simix command line interface which gives you all of the you know classic debugging features you can kind of think of it as super ddb um and then anything

that gets merged in simix or lfl we get immediately uh we we pull in new Li AFL stuff um somebody fixed the oops somebody fixed the uh low-l message passing to be a little bit faster so now when you run a parallel instance you get uh almost double the executions per second um and we just continue to get improvements like that for free from the community which is great uh because there's only a couple of us working on this so the way the fuzzer works there's a there's a launcher and this is all essentially liffl concept so lfl provides this launcher and you say give me 64 cores of fuzzers and it says okay starting 64 fuzzers each of those 64

fuzzers uh starts up a a front end which is the LI AFL side and this is doing your your analysis of your coverage analysis of your comparison logging it's generating mutations of your test cases it's managing the synchronization of your Corpus um all of that jazz and then the the LI AFL side talks to the simix side and simix actually is a library as well um which we have bindings for in Rust and you know we we basically just program against simix as a library so um that's that's why it's easy to use is because it's not a binary um and we just load up a a module also written in Rust fun fact none of simix is written in

Rust and it doesn't support rust so um they were they were a bit confused when I told them what I'd done um so we load up a simix module in in simix that module handles uh basically catching events so when Specific Instructions happen comparisons and such it logs those and adds them to the coverage map um the simic site also handles snapshots of save and restore so we'll we'll look at harnesses in a second um and then um yes okay that's all it does all right so I'm not brave enough for a live demo I have some gifts for you oh and that's really small I'm so sorry okay so I'll just talk through it

so we've got a directory here we have two files in the directory this is what you get when you go to the website and you download simix you get a Intel simix package manager tarball and you get a uhpm file which is a uh basically just an archive of all of the packages that are publicly distributed so to install we uh we create a directory very magical um and then extract the the Intel simix package manager and uh yeah so the the package manager essentially just manages simix projects and allows you to install packages in the public release there's only one way to install the packages it's from the bundle but internally we have a bunch of ways to do it so it

handles those um and that's just a node app so pretty pretty easy to unpack and run on most platforms so then we uh go ahead and install your install your package bundle this is by the way not technically included in those three steps because uh internally developers have already done this so uh anybody who's counting you need to start over so included in the public simix distribution is simix base which is the simulator and all of the stuff in it um the x86 quick start platform and the xad and the quick start CPU platform which basically that's what provides all of our uh CPU models so all of the you know Sapphire Rapids and such that's that's

where that is it has risk five uh um CPU and it has some uh some training and stuff and then there's one here called dosy base I think that's how you pronounce it and that's the one that gives you all of the thermal and Power Trace stuff so if you're interested in side Channel stuff that's where you want to look um don't you can't sue me for that one either um yeah so once you've installed simix pretty pretty painless process um you go ahead and uh clone our repository this is where the three steps starts and we'll get to the we'll get to the fuzzing I promise so you clone a repo CD into it set an environment variable uh

through the through the the cool kid modern way and a do EnV file um pointing to the place that you just unpacked all of your simix packages um and the reason we have to do that is because uh I made a mistake early in the design of this and this will be fixed in about 6 days so so um and then we we just build and we pass a feature to tell the cargo build system if you haven't used it um is pretty wonderful it just builds rust and uh it's it's quite fast and quite ergonomic so this is one of the other advantages of using lib AFL is it lets you justify building everything in your

project in Rust uh which makes you much happier all right so we've got a we've got a fuzzer now go ahead and run it um with some with some help messaging which in our cases is actually quite long um and and complete because that needed to be done before open sourcing so um now that you have a fuzzer built we can go ahead and take a look at how do we harness a project for fuzzing so we have one example it's called uh it's the mini example in our repository and basically this is the smallest possible UEFI app that you can do so uh there's a we use ninja to build it and we'll see

in our ninja file we're including an include file here um and that's what we're going to take a look at first so there's there's two steps to harnessing you include a file and then you add two macros so this is the file we include and essentially what this gives us is a macro that says start and a macro that says stop stop so during normal execution uh the application will run we'll get to the start point it says here's a buffer and here's how big it is and the fuzzer says cool I'll fill that with stuff um and again way too small for anybody to see but we've got start stop stop extended don't worry about

stop extended um harness start you pass a buffer you pass a size the fuzzer fills the buffer up and then it writes back the actual size of the data it wrote because uh we don't want to smash the stack via the fuzzer we want to smash the stack via the fuzzer if that makes sense all right so after that we just need to add a couple lines to our C file and then we're good to go we can build it and we can start fuzzing this EFI application so up at the top we just include a header it it says include TS fs.h um and then if you're a normal person and you haven't read the UEFI

spec uh you can probably just ignore all of those tables if you have read the UEFI spec you'll recognize those basically I've just defined the minimum number of tables I need to print stuff um and tables in UEFI are just uh resources that are provided by the Hardware Via standard interface you can call functions on them you can pass data to them and they will do things such as write it to the screen move the cursor uh take some input Etc so we have a password Checker uh probably pretty similar to what you would see in the uh CTF that I think is going on today um kind of a 101 CTF example here if we put

in the password fuzzing it'll crash which is great um this is actually very hard for fuzzers built before about 5 years ago because there's a lot of magic value checks involved in this um it's really easy now because we have we have modern fuzzing techniques so a little bit of evolution for you so down here at the bottom we're declaring a buffer we're declaring a size and then we are calling our harness macro with the buffer and the size really riveting stuff um but it's good that it's boring because this is this is what the developers have to do they have to include something and they have to write five or six lines of code

um minimal example in real life you know usually you read some stuff from the fuzzer you write it to disk uh something else reads it from dis so you have to do a little little bit more work but in general it's been it's been a pretty easy process for most of the teams internally that we've worked with so um we're we're quite happy about that so now we've built our harnessed EFI application and finally we can we can uh go ahead and update our our script with the three lines I mentioned earlier um so we have uh let's see what am I doing okay so there's a there's a scripting language for simix it's simix scripting um it

also supports python scripting um simic scripting I actually find even though I was a python developer in a past life to be a lot more ergonomic for this particular use case so basically what we do is uh all this is doing is after boot it's booting to a hard disk and then it is putting in up up up up up Escape enter to click the UEFI shell in the bios so um it's a entering things on a keyboard and then waiting half a second so nothing very technologically advanced down here at the bottom is where the advanced stuff happens for fuzzing so the first thing we do is we download our EFI to the file

system and we just do that using a built-in uh simix utility for for downloading stuff onto file systems which is quite nice so we type in download mini. EFI and then we wait half a second because if you if you don't do that you end up with a lot of stuff over top of each other and then we stop our simulation so we've uh We've downloaded we've downloaded our EFI and we are no longer simulating after that is when the actual configuration of the fuzzer happens so um we can access this because it's been loaded for us by the fuzzer um basically we just have a property and the if if you were interested in checking this out

basically the at sign at the beginning of lines in a simic script means it's python so uh you might as well be writing python here and it indeed it does get past to eal um so what we do we say uh in it that says uh okay module go ahead and start up start your logger connect to the fuzzer front end Etc then we add a processor so right now this is a single single threaded fuzzer it supports multiple threads but we haven't tested it so I'm making no claims there um we add a processor which is just our our only CPU core that we're running and this is an x86 model and then we say add

fault 14 that means if a page fault happens the page fault will be considered as a crash so because this is UEFI we don't have a we don't have virtual memory setup or anything page fault means we wrote or read out of bounds and after that we just uh input the name of our EFI application followed by a new line and we're good to go so it'll start running our ufi application and the fuzzer takes it from there so let's take a

look it felt like I was typing really fast when I recorded this last night so we pass a bunch of options to the fuzzer so we pass a project which is a a simix project and a simix project is basically just a directory that you get that has certain models in it so so this one will have x86 obviously because that's what we're fuzzing we pass an input Corpus we pass a uh directory to put any solutions we find which is code for crashes um we set our log level we say one core because if we if we throw 64 cores at this little poor test program uh it'll get overwhelmed quite quickly um and then we we pass the

executable that we're loading and that's actually used for aut tokenization so we parse the PE executable we extract all of the strings from it and use those for uh very very efficient mutations against string checks um and then right now we have a bunch of arguments called D- file which copies a file into your project um and then if I could type a little faster at the very end uh we we run the script that we just created so that that script we were looking looking at that has the you know initialized fuzzer page fault is bad um and then we start it up so you see a bunch of logs from the simulation and then you start

seeing a bunch of logs from the fuzzer and you probably can't see but this is just lib afl's default logger format we get our runtime we get the number of clients connected we get the size of our Corpus we get the number of objectives we've found uh we get the amount of coverage that we have in in uh in ed and where is it right here we got an exception with page fault which means our our fuzzer has very quickly passed our all of our string checks and we get a page fault so great we have a crash um developer says cool I'll put that in jira and we say no no you need to figure

out why uh so to figure out why we add one flag which is-- Repro with the input that caused the crash and this will run just the same as before except now it drops into the simix shell so uh from the simic shell we can do whatever we want so we can disassemble the current instruction we can forget how to type simix commands uh oh there we go we can view our X as nonex which is completely useless um oops all right well we're going to miss the rest of that one because I don't know how to replay the I don't know how to replay the GIF oh it's actually still going okay we can print

all of our registers out um and then pretty much the best feature of uh triaging in simix is bookmarks so we can just reverse to the start of this test case uh where we started executing right after the test case was written into memory um so we reverse there and then we can just single step through the entire execution under that test case to see what what happened where did this go wrong so sometimes the point where the program crashes is not really the point that you care about when you're debugging the crash um so being able to step through the entire process is super nice and at the end we can continue and we get the crash again

so all right that's the whole feature set um there's a couple things I didn't mention like uh you can set a a break point which in simix is more like a watch point in GDB you can set read or write on some memory and if it's read or written that's bad and then uh you can also set executable watch points where uh if certain code is executed that's bad um and then uh here's our future road map so these are all filed as issues on our GitHub if you have ideas you're more than welcome to file more and uh I will take a look at them or I will ask you to implement them um but

yeah so we want to do some concolic execution we want to do taint tracking we want sanitizers which is the big one but that's probably that's probably an us problem um and yeah so questions all right if you want to ask ask a question come on up to the front so he can hear

you I asked YouTube and they didn't have haven't had any yet as well all right question for uh is this useful for anybody excellent all right that's really that's all I need to know if you if if you have ideas for improvements or or fixes that you'd like to see you can email me but knowing that at least somebody's interested in it is uh is quite useful obviously it's super useful for us um but the one of the reasons I took the job I have now is so that I could publish and open source the research that I was doing so um being able to respond to community feedback and make sure it's useful for people

outside of Intel is one of it uh I haven't checked the download stats we have some Stars we have uh a couple people have pinged me saying that they tried the examples at least okay so we have at least four having worked at Intel previously and done something similar to this when intel was not interested in publishing anything anywhere outside this is awesome so thank you for presenting this great yeah happy to hear it that's actually a great question the first crash I found with this fuzzer was in simix because I was uh I was sending a lot of inputs to a device that was not expecting them so actually uh one of one of the useful things about this has been

uh you know the models are not perfect and and if they are perfect sometimes they will still crash because the hardware would crash in such a scenario uh so you you kind of get double dip when you do this fuzzer you you send a bunch of stuff to a modeled device the firmware might crash the model might crash you look at the model crash and you say wait a minute this is modeled correctly that's a problem um that hasn't happened yet but I hope it does at some point got one from YouTube are executable watch points a feature of simix yes so uh basically the the way it works I did unfortunately I should have

shown it in the demo there's no reason not to um but basically the way it works is you say break some address and then either dx- R DW um and that means you know you can combine and mix and match those as you want but you can you can breakpoint anything so one obvious use case for that is uh code and system management shouldn't be running when the kernel or user space is running uh so if people are trying to R into the management engine that's probably something you want to know about so uh being able to detect things like that with just um and I guess probably the the YouTube comment may want to know

it's also applicable over a range so you don't have to set it for every address you can say this whole range of memory you can't execute it um and if you do then we found a crash for crash D duplication are you relying on lib AFL or are you doing some other stuff too with the extra information you have I haven't found enough crashes to D duplicate them yet I've been adding features as they've been demanded of me so uh that one that one is uh TBD but likely I would rely on Li AFL for that they have some they have some stuff you can use stack hashing and so forth well if anybody has any more

questions or or thinks of anything uh you're welcome to message me on my non-listed contact information I think my Mastadon is on the bsides page so you're welcome to message me on there that's probably a good way to get in touch um or you can just find me around and I'm happy to chat about it all right thanks [Music] browan