Platform Agnostic Kernel Fuzzing
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 93 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/36246 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
DEF CON 2463 / 93
4
6
7
11
15
20
26
33
34
35
36
39
40
46
49
53
58
62
63
66
68
72
79
90
92
93
00:00
SystemprogrammierungArchitektur <Informatik>FaltungsoperatorOperations ResearchNetzbetriebssystemBeobachtungsstudieResultanteFaltungsoperatorComputerarchitekturBildschirmfensterCASE <Informatik>Fuzzy-LogikComputeranimation
00:35
FaltungsoperatorComputersicherheitSystemplattformComputersicherheitModallogikExploitZahlenbereichGraphische BenutzeroberflächeBitFaltungsoperatorNetzbetriebssystemVersionsverwaltungProgrammfehlerBildschirmfensterStichprobenumfangPlastikkarteHypermediaThermodynamisches System
01:37
NP-hartes ProblemSystemzusammenbruchNachbarschaft <Mathematik>Große VereinheitlichungTotal <Mathematik>ZahlenbereichFaltungsoperatorZufallszahlenTwitter <Softwareplattform>EindeutigkeitSystemzusammenbruchSoftwaretestZahlenbereichRechenschieberDatenbankFuzzy-LogikSystemaufrufMinkowski-MetrikXMLComputeranimation
02:42
SpeicherabzugCodeNetzbetriebssystemSoftwaretestQuick-SortFramework <Informatik>UmwandlungsenthalpieHackerSoftwareentwicklerComputerarchitekturVorlesung/Konferenz
03:16
PrototypingArchitektur <Informatik>Fuzzy-LogikThermodynamisches SystemBenutzeroberflächeRechnernetzMultimediaMailing-ListeElektronische PublikationComputerarchitekturMereologieFramework <Informatik>UmwandlungsenthalpieSpeicherabzugProgrammfehlerKartesische KoordinatenDienst <Informatik>WissensbasisDiagramm
03:52
Elektronische PublikationThermodynamisches SystemMailing-ListeBenutzeroberflächeMultimediaRechnernetzPhysikalisches SystemSystemaufrufTelekommunikationFaltungsoperatorMAPGruppenoperationArchitektur <Informatik>UmwandlungsenthalpieBildschirmfensterInteraktives FernsehenMereologieSystemaufrufSoftwareentwicklerThermodynamisches SystemComputerarchitekturOpen SourceDatentypReverse EngineeringNetzbetriebssystemMinimumTelekommunikationBitEinsQuellcodeParametersystemMinkowski-MetrikFaltungsoperatorMAPJSONComputeranimation
04:55
TypentheorieFuzzy-LogikBoolesche AlgebraPunktZufallszahlenSystemaufrufMultiplikationsoperatorZahlenbereichEigenwertproblemWort <Informatik>Kategorie <Mathematik>GeradeStrömungsrichtungProgrammbibliothekOrtsoperatorThermodynamisches SystemObjekt <Kategorie>SystemaufrufAggregatzustandInformationsspeicherungMereologie
05:29
Objekt <Kategorie>SystemaufrufDeterministischer ProzessBildschirmfensterElektronische PublikationThermodynamisches SystemObjekt <Kategorie>DatenstrukturInformationsspeicherungBitSystemzusammenbruchAggregatzustandMereologieUmwandlungsenthalpieFunktionalFuzzy-LogikComputeranimation
06:07
ExpertensystemDatenstrukturQuellcodeLoginMini-DiscTemplateNichtunterscheidbarkeitQuellcodeDatenloggerRundungSystemaufrufBitSoftwaretestTemplateCASE <Informatik>Rechter WinkelBefehl <Informatik>VollständigkeitFunktionalQuick-SortElektronische PublikationLie-GruppeInstantiierungProgrammbibliothekBildschirmfensterParametersystemDatenstrukturWeb logSystemzusammenbruchLoginSocketFaltungsoperator
07:44
SystemzusammenbruchFaltungsoperatorDebuggingROM <Informatik>AnalysisSystemaufrufFunktionalSystemzusammenbruchMinimumProgrammbibliothekSpeicherabzugBildschirmfensterDreiecksfreier GraphElektronische PublikationBefehlsprozessorBootenZahlenbereichDebuggingFaltungsoperatorLoginQuaderInformationMomentenproblemPunktProzess <Informatik>Mini-DiscPerpetuum mobileKonfiguration <Informatik>PackprogrammMatchingComputeranimation
09:35
ROM <Informatik>SystemzusammenbruchAnalysisDatenbankInformationDatentypTypentheorieDatenbankProgrammfehlerElektronische PublikationHash-AlgorithmusKategorizitätBildschirmmaskeGewicht <Ausgleichsrechnung>Fuzzy-LogikVorzeichen <Mathematik>Computeranimation
10:19
SystemzusammenbruchThermodynamisches SystemSkriptspracheROM <Informatik>AnalysisWeb logComputerarchitekturThermodynamisches SystemSpeicherabzugSkriptspracheInformationsspeicherungElektronische PublikationBinärcodeObjekt <Kategorie>BildschirmfensterBootstrap-AggregationInstallation <Informatik>ZweiWrapper <Programmierung>Fuzzy-LogikProgrammbibliothekDatenbankComputeranimation
11:35
ProgrammbibliothekThermodynamisches SystemIterationSystemaufrufObjekt <Kategorie>DatenverwaltungFaltungsoperatorElektronische PublikationReelle ZahlSoftwaretestZahlenbereichFigurierte ZahlParametersystemSystemzusammenbruchTropfenObjekt <Kategorie>SystemaufrufProgrammfehlerQuaderBildschirmmaskeTablet PCProgrammbibliothekThermodynamisches SystemMultiplikationsoperatorIterationGarbentheorieInformationsspeicherungLoginProfil <Aerodynamik>Kontextbezogenes SystemFuzzy-LogikAggregatzustand
13:24
DatenverwaltungFaltungsoperatorImplementierungStichprobeBootstrap-AggregationSystemaufrufPhysikalisches SystemFuzzy-LogikImplementierungFaltungsoperatorBildschirmfensterObjekt <Kategorie>Thermodynamisches SystemInformationsspeicherungFramework <Informatik>Wrapper <Programmierung>ProgrammbibliothekProzess <Informatik>Hidden-Markov-ModellFlächentheorieCASE <Informatik>BeobachtungsstudieNichtlinearer OperatorBimodulSystemaufrufPunktComputeranimation
15:03
ATMFaltungsoperatorTreiber <Programm>BildschirmfensterInterface <Schaltung>CursorBildschirmfensterSystemaufrufInterface <Schaltung>CASE <Informatik>Thermodynamisches SystemTreiber <Programm>Element <Gruppentheorie>VisualisierungATMTouchscreenZusammenhängender GraphTermGraphfärbungKartesische KoordinatenNichtlinearer OperatorSoftwareentwicklerProgrammbibliothekFaltungsoperatorFlächentheorieDatenverwaltungExogene VariableBenutzeroberflächeCodeWrapper <Programmierung>MehrrechnersystemDickeComputeranimation
16:15
Kategorie <Mathematik>Physikalisches SystemDatenstrukturFaltungsoperatorElektronische PublikationEreignishorizontDatenstrukturFaltungsoperatorObjekt <Kategorie>BildschirmfensterKartesische KoordinatenTypentheorieInterface <Schaltung>Thermodynamisches SystemHalbleiterspeicherOrdnung <Mathematik>Quick-SortMinkowski-MetrikNichtlinearer OperatorProzess <Informatik>DatenverwaltungSpeicherverwaltungElektronische PublikationTelekommunikationMenütechnik
17:27
Objekt <Kategorie>Weg <Topologie>Thermodynamisches SystemProgrammbibliothekObjekt <Kategorie>InformationsspeicherungBildschirmfensterDeklarative ProgrammierspracheZahlenbereichImplementierungMAPSystemaufrufBitmap-GraphikThermodynamisches SystemElektronische PublikationProgrammbibliothekNetzbetriebssystemParametersystemKartesische KoordinatenSoftwareentwicklerZeiger <Informatik>MomentenproblemElement <Gruppentheorie>TypentheorieE-MailQuick-SortMinkowski-MetrikAliasingSoftware Development Kit
19:19
Objekt <Kategorie>Weg <Topologie>Thermodynamisches SystemProgrammbibliothekObjekt <Kategorie>InformationsspeicherungDatenfeldBildschirmfensterEinsMinkowski-MetrikStrebeRechter WinkelSelbstrepräsentationAutomatische IndexierungCASE <Informatik>ZahlenbereichJSON
20:29
Objekt <Kategorie>InformationsspeicherungBefehl <Informatik>ParametersystemFunktionalProgrammbibliothekRandomisierungAutomatische IndexierungSystemaufrufURLThermodynamisches SystemUmwandlungsenthalpieFreewareProgramm/QuellcodeComputeranimation
21:32
SystemaufrufPhysikalisches SystemReverse EngineeringNetzbetriebssystemSystemaufrufZahlenbereichWissensbasisDatentypThermodynamisches SystemMathematische LogikParametersystemVersionsverwaltungTypentheorieBildschirmfensterBitComputerarchitekturReverse EngineeringZwei
22:41
SystemaufrufPhysikalisches SystemSystemaufrufThermodynamisches SystemSelbstrepräsentationDatenfeldDatentypParametersystemComputeranimation
23:17
Physikalisches SystemSystemaufrufTemplateNetzbetriebssystemSystemaufrufParametersystemFunktionalApp <Programm>VariableThermodynamisches SystemMomentenproblemPrototypingTemplateSpeicherabzugComputerarchitekturQuick-SortZahlenbereichGeradePrinzip der gleichmäßigen BeschränktheitGruppenoperationDickeHochdruckFaltungsoperatorWrapper <Programmierung>GraphiktablettFuzzy-LogikComputeranimation
25:07
Physikalisches SystemSystemaufrufKeller <Informatik>ParametersystemForcingNetzbetriebssystemBildschirmfensterMinkowski-MetrikGruppenoperationFaltungsoperatorBefehlsprozessorSystemaufrufSystemplattformCASE <Informatik>FunktionalCodeOrdnung <Mathematik>Thermodynamisches SystemSpeicherabzugComputeranimation
26:00
SystemaufrufZeiger <Informatik>Funktion <Mathematik>ProgrammbibliothekFunktionalSoftwareentwicklerPrototypingInformationKartesische KoordinatenZusammenhängender GraphNichtlinearer OperatorWissensbasisZeiger <Informatik>Wrapper <Programmierung>SystemaufrufImplementierungATMProzess <Informatik>MomentenproblemObjekt <Kategorie>Case-ModdingNetzbetriebssystemComputeranimation
27:26
SystemaufrufElektronische PublikationCodeBefehl <Informatik>FunktionalSystemaufrufBitParametersystemBoolesche AlgebraWrapper <Programmierung>Computeranimation
28:00
SystemaufrufIndexberechnungBoolesche AlgebraPhysikalische TheorieCursorInformationsspeicherungObjekt <Kategorie>Automatische IndexierungMultiplikationsoperatorSystemaufrufProgrammbibliothekFunktionalCASE <Informatik>Wrapper <Programmierung>ParametersystemVariableDeklarative ProgrammierspracheBitPunktPrototypingComputeranimation
29:54
IndexberechnungParametersystemBildschirmfensterProgrammbibliothekFunktionalGraphfärbungValiditätUmwandlungsenthalpieKontextbezogenes SystemBitImplementierungSoftwaretestVariableAutomatische IndexierungSystemaufrufCASE <Informatik>Wrapper <Programmierung>TropfenBefehl <Informatik>HilfesystemTypentheorieStrebeComputeranimation
31:27
DatenstrukturOISCElektronische PublikationPunktFunktionalThermodynamisches SystemSystemaufrufProgrammbibliothekZahlenbereichPhysikalischer EffektParametersystemStrebePunktRechenschieberBildschirmfensterHilfesystemRechteckEinsMinimumMailing-ListeComputeranimation
32:33
BitBildschirmfensterSystemaufrufGraphfärbungWort <Informatik>Ganze ZahlDeklarative ProgrammierspracheInformationsspeicherungTypentheorieProgrammbibliothekComputeranimation
33:15
OISCMinimumRechter WinkelLogarithmusSkriptspracheBootstrap-AggregationDebuggingBimodulKonfigurationsdatenbankROM <Informatik>FaltungsoperatorKontrollstrukturThermodynamisches SystemFunktionalRechteckCASE <Informatik>BeobachtungsstudieElektronische PublikationDatenfeldHilfesystemTypentheorieKernel <Informatik>ÄquivalenzklasseWeb-SeiteThermodynamisches SystemDickeInformationSkriptspracheBildschirmfensterDatenbankOrdnung <Mathematik>DebuggingSystemzusammenbruchBimodulATMFaltungsoperatorBootstrap-AggregationAggregatzustandFehlermeldungKonfigurationsdatenbankAbgeschlossene MengeTelekommunikationTreiber <Programm>FreewareGamecontrollerBootenComputeranimation
34:55
SystemzusammenbruchROM <Informatik>FaltungsoperatorSpeicherabzugElektronische PublikationSystemzusammenbruchURLFunktion <Mathematik>Thermodynamisches SystemHalbleiterspeicherFaserbündelComputeranimation
35:51
Operations ResearchSystemprogrammierungPhysikalisches SystemSystemaufrufSystemzusammenbruchFaltungsoperatorWeb logFaltungsoperatorInterface <Schaltung>Elektronische PublikationThermodynamisches SystemKartesische KoordinatenSystemzusammenbruchNetzbetriebssystemBinärcodePortabilitätInformationsspeicherungDebuggingObjekt <Kategorie>MultiplikationsoperatorInformationMathematikBildschirmfensterSystemaufrufSystemplattformComputeranimation
36:52
OvalFuzzy-LogikKonfiguration <Informatik>Offene MengeSchreiben <Datenverarbeitung>SystemaufrufVerschlingungLesen <Datenverarbeitung>Ein-AusgabeBildschirmfensterFunktionalObjekt <Kategorie>ProgrammbibliothekSoftware Development KitDifferenteUmwandlungsenthalpieEinfache GenauigkeitSystemaufrufEindringerkennungParametersystemElektronische PublikationFramework <Informatik>CodeResultanteThermodynamisches SystemÄhnlichkeitsgeometrieProgramm/QuellcodeComputeranimation
37:37
SystemprogrammierungOperations ResearchSystemzusammenbruchVirtuelle RealitätVMware WorkstationSystemzusammenbruchUmwandlungsenthalpieBildschirmfensterBimodulMomentenproblemPrototypingStrömungsrichtungKontextbezogenes SystemAdditionProgrammfehlerMultiplikationsoperatorImplementierungMakrobefehlThermodynamisches SystemComputeranimation
38:33
BefehlsprozessorTotal <Mathematik>ZahlenbereichSystemzusammenbruchZeiger <Informatik>FreewarePufferüberlaufWeitverkehrsnetzNetzbetriebssystemStabilitätstheorie <Logik>BefehlsprozessorMomentenproblemResultanteBitEinfache GenauigkeitThermodynamisches SystemGefrierenLesen <Datenverarbeitung>TypentheoriePufferüberlaufZahlenbereichSystemzusammenbruchBildschirmfensterProgrammfehlerKategorie <Mathematik>Zeiger <Informatik>Puffer <Netzplantechnik>Computeranimation
39:46
SystemaufrufATMMittelwertRückkopplungBefehlsprozessorLoginSystemzusammenbruchSoftwaretestLastQuellcodeATMTreiber <Programm>FaltungsoperatorZahlenbereichFramework <Informatik>SystemzusammenbruchCASE <Informatik>ProgrammbibliothekQuaderInformationsspeicherungSpeicherabzugFormale SpracheÄhnlichkeitsgeometrieFunktionalPhysikalischer EffektOrdnungsreduktionTypentheorieProzess <Informatik>ImplementierungBefehl <Informatik>DatenloggerDatenfeldFuzzy-LogikSoftwaretestRückkopplungObjekt <Kategorie>VirtualisierungInformationBildschirmfensterMomentenproblemComputerarchitekturResultanteElektronische PublikationNummernsystemTwitter <Softwareplattform>UmwandlungsenthalpieMultiplikationsoperatorBimodulBefehlsprozessorSystemaufrufKontextbezogenes SystemThreadComputeranimation
43:55
RückkopplungQuellcodeMultiplikationsoperatorFramework <Informatik>FlächeninhaltComputeranimation
Transkript: Englisch(automatisch erzeugt)
00:00
Uh, without further ado, please help me welcome James and Georgie. Cool. Uh, thanks everyone. Um, so I'm James and this is Georgie. Um, alright, let's get started. Uh, so, quick agenda. Um, so we're gonna run through our motivation for writing a kernel fuzzer. Uh, we'll go over our, our architecture. Um, some caveats to be
00:24
aware of if you're doing your own kernel fuzzing. Uh, we'll run through Windows as a case study, plus the other operating systems we've looked at. Uh, we'll run through the results we've got, uh, and what we're looking to do over the next few months. So, motivation. Um, typically now with sandboxing, uh, kernel exploits are becoming more of a
00:42
necessity. Um, it's quite hard to break out sandbox environments, particularly if you're looking at things like Chrome. So if you look at the last poem to own wins over the last few years, they've all used kernel exploits to break out the sandbox process. Uh, so yeah, kernel exploits, pretty important nowadays, uh, for, for things like Privex. Um, also at NWR, we have a bit of a friendly internal competition
01:03
going on. Uh, so Neil's presented on his version of his Windows kernel fuzzer at T2. Um, obviously we're trying to beat the number of bugs we, uh, er, er, he got in his version. Um, but obviously we're primarily here to try and improve general operating system security. Uh, initially, and most of our research has been focused on
01:23
Windows, um, Windows 7. Uh, but we've actually ported the fuzzer to run on OSX and QNX. Uh, and we're looking to start running it properly over the next few months and trying to find some bugs in those, uh, OS's as well. So, how hard can it be? If you look over at Twitter, it would appear everyone has Win32k Oday. Um, and so do we. Uh, so
01:46
about a month ago, uh, we did a run. Um, purely a test run to make sure the fuzzer was pretty stable. So, as you can see, 16 VMs, just 48 hours, we got 65 crashes, 13 of those you need. Which, you know, I didn't think was too bad. 13 Odays in Win 7, okay,
02:01
cool. Uh, as it turns out though, we weren't being particularly effective with our fuzzing. So, for those that don't know, there's a number of syscalls in Win 7 that are simply just sleeps for all intents and purposes. So, we got the one there, NT delay execution. So, we managed to find that one, blacklist it, and actually, surprise, surprise, the fuzzer was a lot more effective. Um, so we, we ran it again last week. We
02:24
haven't triaged all the crashes, which is why we've not, uh, spoken in the slides, but we ended up with around 150 crashes, uh, and 40 of those were unique. Um, in the end actually, uh, we, we crashed our database, we were pushing all these, uh, uh, crashes too, because it ran out of space for it. So, that seems pretty cool. Uh,
02:44
we are going to release the framework for the fuzzer. Um, so, the core will be the released, um, but we're not going to release any OS specific stuff. Uh, but throughout the talk, we're going to go through how you would write the OS, uh, the OS specific stuff and give you some examples so you can go away and fuzz the OS's yourself. Um, it's
03:03
worth bearing in mind when you look at the code that we're hackers, not developers. It's pretty dirty in places. Um, so, yeah, bear that in mind. Our sort of test is, does it compile? Great. It probably works then. So, the architecture. Um, everything is nicely decoupled. So, you've got in there the center of the
03:22
framework core, um, which is basically what runs everything on the outside there, uh, which is the OS specific stuff. Uh, originally we dev this up in python, um, but we've completely rewritten it in C. Uh, it's much more efficient, significantly faster, and seems to be finding a lot more bugs for us, so. So, the first part is the OS API
03:43
knowledge base. Uh, all this is is the OS specific API that is used by applications to interface with services provided by the OS. So, this is the things devs do to, you know, do things with graphics or interact with devices or do networking, et cetera, et cetera. Um, many of these will wrap system calls. Um, we'll provide two examples of how we've
04:04
dev'd these, uh, for Windows and OSX, um, later on in the talk. Um, but we won't be releasing all of our ones. The next part, the next major part of the OS specific stuff is the system calls. Um, so system calls are a low level method for user space to kernel
04:21
space communications. Uh, these have to be implemented per architecture and operating system. So, that's fine for open source systems, you know, OSX or any next space system, these tend to be open source. Uh, for Windows it's a little bit more difficult, you have to reverse engineer these ones out or, or rely on other, uh, sources, maybe react OS or something like that. Uh, at the bottom there you can see
04:43
what a Cisco looks like internally to the fuzzer, so we just have a Cisco ID, uh, the arguments for that Cisco, and then just a return data type if it, if the Cisco provides a, uh, a return. Also, we have a number of, uh, fuzzed values, um, so there
05:00
you can just see the, the fuzzed values you can grab internally, uh, from the fuzzer. Um, we use the words fuzzed, but what we, we don't necessarily mean fuzzed actually. Um, so really we actually want the library calls and Cisco's to work, uh, and to get these to work, we actually have to return proper values. So, whilst we occasionally return a properly fuzzed value, most of the time you'll return
05:21
a normal value that is gonna ensure that the library system call works. Um, yeah. So, the next part is the object store. Um, the object store is used to maintain state across a fuzzing run, uh, and it stores OS specific objects of interest. So, currently, this is handles in Windows and file descriptors in Nix systems. Uh, it's
05:44
implemented as just a global array of structures. Um, it's deterministically populated by the fuzzer, and this is quite important for when we want to reproduce crashes. Uh, if this wasn't deterministic, then obviously we'd just never be able to reproduce any crashes we found. Uh, it's, it's quite easy to retrieve, updating certain new objects into the object store. Okay, uh, the next
06:06
bit is the helper functions. Um, so, helper functions, we use these for things like library calls that require a struct. It works in pretty much the same way as, uh, grabbing a fuzzed, uh, value. So, if you want to call for a struct for a library
06:21
call, you make a call to the helper function and it will return you a, a struct that should be, uh, should work fine in the library call. So, logging. Um, this is actually quite difficult in kernel fuzzing when you keep hitting crashes. Um, so, initially, we didn't have high hopes for the fuzzer, uh, so all we did was log, log a
06:42
PRNG seed. Um, as you might guess, as a fuzzer, we make heavy use of the rand function. So, if we can just seed this again, we'll always get a, a, a same run again, which makes reproducing quite easy. Bit of an issue, though, is it doesn't generate a standalone test case, which is ultimately where we want to get to. Um, so what we've moved on to doing is logging seed statements. So, our log
07:04
files are actually complete source files. Uh, and all we do is copy and paste these into a template. There are some issues with this, um, so occasionally, uh, if we get a BSOD, we'll find that actually the OS hasn't flushed the, uh, the write to the file before it's BSODed, uh, in the Windows instance. Uh, so we miss out on, let's say, the last
07:23
call. Um, as a work around, what we're doing is we're usually able to grab the stack trace and the arguments and everything else and figure out what it was doing. Uh, what we're looking towards doing in the future as well is maybe using something like logging over a socket or something like that, uh, which we're hoping will work a little bit
07:41
better. As you might guess, this is incredibly tedious. Um, so this is an example of our logging from a library call. Uh, what we do is we grab a, uh, a variable ID to tag onto the end of a variable, um, and then we assign that variable and call a function. Uh, as you can see at the bottom, um, we log the function call before
08:04
calling the function in the fuzzer to try and, uh, ensure that we log the crash before it actually crashes. So, crash detection. Um, there's actually two methods we tried with this. So the first way we tried was just attaching a kernel debugger while we were executing the fuzzer. Uh, obviously requires one or more debugger processes which
08:24
slows execution. So you can either have, uh, on the host debugging the VMs or a VM debugging another VM. Uh, but the plus point is we instantly analyze, uh, any crashes we find. The other option is unattended execution which is what we're working on at the moment. Uh, and this is just letting the OS handle the crash on its own. Um,
08:44
much faster execution and we can run more VMs as well and we have less, uh, wasted CPU cycles. Um, we recover and analyze the crashes, uh, upon reboot. Another way we've been looking at actually is, um, using hypervisor logs. So for example, VMware will actually log when a host, uh, a host has crashed and there's some information in
09:04
there that is actually quite useful. So this is the way the logging, uh, the crash detection, sorry, works. Um, when we reboot the box, the first thing we'll do is try and search for a memory dump files. Um, so this is quite specific to Windows. Um, if we find a memory dump file, we'll match that up with a log file. So there should only be
09:21
one log file on the disk which is the one that caused the crash. Um, if we get that memory dump file, what we do at the moment is, uh, under win bag, bang analyze and just grab those, uh, details out and then the 3 of them, we time stamp and just archive them all off. So, with a number of VMs, so our ultimate goal is to run this
09:42
across hundreds of VMs, is we need some form of way, of the fuzzer, fuzzer to push this into a central database. Um, so those 3 files I just described are actually pushed into a CouchDB database that we just have sat in AWS. Uh, this is really useful for us because it means we can actually do deduplication across all the VMs. So all we do is hash the stack, um, if we've seen that, uh, hash before, we just drop the
10:04
files and increment a counter. If we haven't, then we push the files up into, uh, CouchDB. It also means we can do some other categorization stuff, um, so doing stuff like type of AB, 14 IP, bug check ID, etc. Closer to the mic. Okay. Okay, so
10:23
that's the overall architecture for the fuzzer. Uh, right, yes. So, that was the
10:49
overall architecture. So this is what a fuzzing run looks like. Um, the first thing we do is we have a little bootstrap script that we run to prepare a VM for fuzzing. Uh, it's just a really simple Python script. It installs everything that's required, um, and just
11:03
fine-tunes the system. Um, so we'll go through what the Windows, uh, one of that looks like later on in the talk. Uh, we then launch a second Python script, which is a wrapper around the core fuzzer, but what that one does is go away and collects the memory dumps, uh, and submits it to the database if it finds them, et cetera, et cetera, as I just said. We then launch the fuzzer binary, um, and the first thing we do is
11:26
populate that object store. Um, so we generate a bunch of valid handles or file descriptors that we can then use for library and system calls straight away. Uh, okay, so then for a predefined number of iterations, we pick up either a library or system
11:41
call. Uh, so, we'll go away, figure out what the arguments are, and then grab either a fuzz value, fuzz structs, or an object from the object store. Uh, and then we invoke that call. We check to make sure it's succeeded, and if it gives us a, a value back that's useful later on, we'll pop that back into object store. So, you know, library calls or system calls may return a handle or a file descriptor or something
12:03
similar, and we want to keep hold of that value and use it, uh, later on. Uh, at the end, if we didn't get a crash, uh, all we do is just clean up all our temporary files, remove the logs, and just try and revert back to a clean state. Now, currently, all we do is reboot the box. So, this should mostly give us, uh, a clean state to work from for
12:21
the next fuzzing run. Uh, obviously we can't just start the fuzzer again, because if we have done something in a previous fuzzer run that we haven't logged, it's impossible to reproduce that test creation, test crash, uh, and it is useless to us. We're actually also looking at how we can possibly revert back to a, uh, VM snapshot, um, as this will guarantee a clean slate to start from. A few caveats to be aware of,
12:46
uh, if you're gonna take this framework and use it yourselves, uh, we found a number of bug- bugs in the hypervisors, um, which has meant we haven't placed this up in the crowd. I'm pretty sure people like Amazon will get really annoyed with us if we start crashing their hypervisors. Um, so what we're looking at doing is running it under
13:03
keyemu, which is a bit inception-y, but should hopefully work. Um, you also need to look into things like, we're also looking into things on how to protect the fuzzer from itself. So on a number of occasions, somehow the fuzzer has managed to get a handle to itself and kill itself, which is kind of irritating. Um, so, what we're trying to move
13:25
onto is a method of how we monitor the host that's fuzzing, uh, monitor the guessery from the host. So if the fuzzer's killed itself or we've, you know, hit another sleep or done something else stupid, we can detect that and then kill- uh, start the fuzzer off again. Cool. Uh, so I'm actually gonna hand over to Georgie, uh, who's
13:45
gonna go through, uh, Windows case study. Um, so, uh, as James already mentioned, we initially started with the idea of developing a Windows kernel fuzzer, uh, and this
14:02
actually remained our focus despite of repurposing the fuzzer for, um, OS agnostic operations. So, the second half of the talk is dedicated on, um, getting the fuzzer work inefficiently on Windows and basically writing all of these custom modules for the Windows operating system. So all of these operating system tweaks and, uh, object
14:23
store, um, implementation details, uh, that you need to consider when you take the framework and you want to basically use it for fuzzing Windows. I'll be going through several examples, um, for each one of these, uh, bullet points. So basically examples on, uh, how we, uh, implemented, uh, our object store, some examples on what,
14:42
uh, our collection of system calls, uh, looks like in Windows and basically some examples on, uh, the wrappers for the library calls that we have developed. Um, I'll be ending this with basically what's the process of bootstrapping the Windows VM, uh, before we actually start fuzzing. So the attack surface we decided to focus on is, uh, the
15:06
attack surface, uh, in, in Windows operating system. Uh, this, this subsystem implements, uh, mainly 3 components. Uh, the window manager, uh, responsible for, uh, desktops, uh, windows, menus, toolbars, the general user interface elements and the, uh, graphics
15:24
device interface, also known as GDI, um, which is in charge of, uh, visualization on the screen, changing colors and, uh, basically just general graphics. Um, Win32k.sys also implements, um, some wrappers for DirectX calls and this is not something we have looked
15:41
at, uh, until now. And this is probably not something we'll consider in the future. Um, there is counter components in user length in terms of, uh, user mode libraries, um, a bunch of DLLs, um, provided for application developers to actually, uh, interface with the subsystem. So, uh, if you're an application developer, a developer, you
16:01
wouldn't, uh, issue a sys code to the Win32k.sys, uh, kernel mode driver. You would be going on SDN and looking at how you interface with this kernel mode driver using some library calls that will eventually wrap, uh, into, uh, into a system goal. Um, in the Windows operating system, uh, an object is basically a data structure representing some
16:23
sort of, uh, system resource and this can be anything from, uh, file, process, window, um, menu, et cetera. Um, there is roughly 3 types, main types of objects in the Windows operating system. User objects, uh, GDI objects and kernel objects. User
16:40
objects are, uh, implemented to support the window manager, uh, obviously GDI objects implemented to, um, basically manage the graphic device interface and kernel objects, uh, kernel objects are basically there to, um, implement basic operations in the, uh, kernel space such as process management, memory management, uh, IPC communication,
17:00
et cetera. Um, one important thing to, uh, realize when we talk about object is that when an application, uh, wants to manipulate an object, uh, when an application wants to access an object, it needs to acquire a handle to that object. So, um, if you want to do something with any of the system resources, you need a handle to, uh, each one of
17:24
them in order to basically interface with them. Um, and this is how, uh, handles are defined. Object handles are, uh, defined in the, uh, Windows SDK on a really, really low level, um, they're just basically void pointers managed by the operating system. Now,
17:41
the implementation details are hidden from the, uh, application developer and the application developer shouldn't really care about how these handles are implemented and this is just here for, um, for reference. Um, furthermore, uh, numerous aliases, aliases are defined for, uh, more or less any system resource available on the operating system. So, um, this is a snippet from, uh, windef dot h, uh, header file from
18:04
the Windows SDK where a bunch of these declaration, uh, declarations actually happen. Um, there's declaration to a handle, uh, for a handle to, uh, to a window, declaration for a handle to a bitmap, et cetera. So, each one of these system resources will have a sort of specific, uh, handle, um, associated, uh, handle type
18:24
associated with it. Um, so, knowing and realizing how fundamental, um, object handles are in, uh, in the Windows world, it comes as no surprise that we actually decided to preserve object handles in our, uh, object store. Um, the object store
18:42
implementation itself is, um, really straightforward at the moment. It's just, uh, a globally accessible array of 120 elements where we just preserve a bunch of handles to, uh, numerous system resources. Um, handles are retrieved, uh, from this, um, object store when we need a handle, uh, to be passed as an argument to a system or a library
19:03
call. And should a system or a library, library call return successfully another handle, we consider, uh, this handle, uh, and we push it back to the object store. Sorry. Um, if we start running out of, um, let's say, uh, space in our object store, um, in
19:24
this case it's a fixed value of 128. Let's say we start running out of, um, slots in this array. We basically start overwriting some of the handles, um, from the object store. We basically throw out the oldest handles and we repopulate the object store with some new ones. Um, one more thing, uh, to, um, basically, uh, notice is the, uh,
19:44
BH handle struct. Uh, the BH handle struct is our internal representation of, uh, of, of a handle. Um, it has two fields, uh, which is the handle itself, um, as well as, um, the index of the handle in the object store. So, handles will be changing values,
20:02
um, per run. Um, so basically if we grab a handle to, uh, a particular window in one run, this handle will have one value. If we grab the, if we grab a handle to, uh, a identical window in a second run, this handle will have a different value. So, how we, uh, grab the same handle twice, by basically referring to the handle not by its value but
20:24
by its index in, uh, in the object store. Um, we have implemented a number of functions to interface with, uh, with the object store I'm talking about. Um, the first one is basically there to bootstrap the object store, uh, populate the object store with
20:42
some handles before we even start fuzzing. So we can actually use some handles as arguments for library and system calls. Um, the second one is, uh, the function get random handle. This, this function will basically look up the store and randomly pick up a handle from it. Um, it will then wrap the handle in a BH handle struct,
21:01
uh, which, uh, helps us successfully log the location of the handle in the object store when we, uh, issue logging statements. Um, we have another function for wearing the, uh, object store. This one is get specific handle, uh, this one takes one argument, which is basically the index of the handle we want to, uh, extract, uh,
21:21
treat free from the, from the object store. Um, we also have a function for, uh, inserting handles back to the object store. Again, should a library call return successfully a handle, we just push it back to the object store. Um, for populating the knowledge base of system calls. Well, basically for the majority of them, we had to reverse engineer them. Um, we started with, uh, mainly system calls
21:43
implemented in, uh, in the Win32k subsystem. Um, but, um, there's one thing. When I say reverse engineering, I don't really mean reversing the logic of the system call itself or how the system call is implemented under the hood. The only details we're interested in are basically the system call ID, uh, the number of arguments for the
22:04
system call, and the data type for each one of these arguments. Um, optionally, again, uh, the return type for, for the system call. Um, so, for the majority of the system calls, you have to, uh, do some reverse engineering. For some of them, you may also refer to React OS, uh, but, um, this is not necessarily identical to the Windows
22:25
revision you're working on. Um, to implement the Cisco invocation itself, uh, we had to write some assembly snippets, and these are, um, specific to, uh, both, uh, the operating system and the, uh, and the architecture. A little bit more about the assembly snippets in, uh, in just a second. Um, this is what, um, uh, an extract from,
22:46
uh, our collection of system call looks like. Um, James already mentioned, uh, what a system, uh, what our internal, uh, representation of a system call looks like. The Cisco struct has got, uh, three fields. The first one is the system call ID, the second
23:03
one is an array of, uh, data types for each one of the arguments consumed by the system call, and the third and optional field is, uh, basically whether the system call returns any data type we may be potentially interested in. Um, the system call invocation, again, is, um, implemented per architecture and per operating system. Uh, we
23:25
have what we call system call invocation template, um, the prototype for the template is the same across the architectures, um, and this is the call, uh, with the name Buckhan underscore Cisco. Uh, this function, this template function takes 33
23:42
arguments at the moment, uh, the first one being the Cisco ID and the second, uh, basically the rest of these 32 arguments are, uh, arguments for the system call itself. Now, obviously, not every system call would be taking 32 arguments or I don't even know if there is any system call taking 32 arguments at all. The reason we did, uh, a fixed number
24:04
of arguments is because we didn't want to, um, implement, uh, function with a variable number of arguments, a sort of print f like style. So what we do at the moment is we, uh, set the system call ID as the first argument for this, uh, function. We, uh,
24:21
uh, set the actual data that should be passed to the system call and we just pad the rest of the 32, uh, arguments with some dummy data. And then Buckhan Cisco is in charge of, um, setting the registers for the invocation of the system call, uh, pushing the, uh, pushing each one of these 32 arguments on the stack, uh, and then, uh, making
24:41
transition in kernel length. Um, once we're in kernel length, the system call is in charge of basically dispatching the request, uh, taking care of each one and processing each one of the arguments that are actually expected by the system call. Uh, the system call will then simply ignore, uh, the rest of the 32 arguments on the stack. The system call will eventually return back to the Buckhan Cisco wrapper. Buckhan Cisco
25:02
wrapper will clean up the stack and return to the main fuzzing loop. Um, this is just a general reminder on how system call invocation works on Windows. Uh, for x86 platforms we have, um, arguments pushed on the stack in a reverse order. We have EAX set to the system call ID and, uh, then a call is made to the KIFAS system call
25:24
function. And now there is a caveat. This is basically until, this is the case until Windows 7, uh, which is the operating system we, we have been mostly focused on. Um, I think in Windows 8 and Win 10, uh, the KIFAS system call has been basically inlined in the code. Uh, for x64, um, the first 4 arguments are set in
25:44
registers. Uh, these are RCX, RDX, R8 and R9. Uh, if there's any additional arguments that are pushed on the stack, then RAX is set to the system call ID and, uh, the CPU instructions Cisco is made to, uh, basically, uh, force transition into kernel space. Um, so
26:03
much for, uh, system calls. Now, um, several, um, examples on how to implement the OS API knowledge base. Um, the OS API knowledge base, the information that we need for it is, um, publicly available on MSDN. Um, this is based, these are basically the library calls that, again, application developers are expected to be using, um, when making,
26:25
uh, requests with the operating system. Um, the, uh, objects, uh, the, um, OS API calls knowledge base is, uh, implemented as, um, one huge array of function pointers to each one of the library call wrappers that we have implemented. Um, I think until a few
26:43
days ago we had about 500 library call wrappers. So basically 500 functions from, uh, GDI32.dll, uh, User32.dll and some other user mode components. Um, as you can imagine, this is a really tedious process of implementing wrappers for each one of
27:01
these. Uh, we looked at automating this by basically crawling MSDN, collecting function prototypes and, uh, turning these prototypes into library call wrappers in a more or less automated way, but unfortunately we felt miserably with that and we're looking forward to basically improving our approach. But at the moment, again, each one of these
27:22
are, uh, implemented, um, strictly manually. Um, this is, um, I'm gonna give a few examples now. Uh, this is the, uh, destroy carrot function from MSDN. This function takes no arguments and returns, uh, boolean value. Um, and the wrapper for this call is really simple, really straight, straightforward. Uh, basically we log, uh, the,
27:45
um, the call that we're about to make and we make the actual call. That's, that's literally it. So in the log file, we basically end up with the exactly same, uh, C statement that we're making in, uh, in our fuzzer. Uh, something a bit more
28:02
interesting is, uh, the following one, destroy cursor. Um, on the top you have the prototype from MSDN. This one takes a single argument. This argument is, um, basically a handle to a cursor object. Um, and this function returns a boolean again. So, uh, what we do in our wrapper, uh, we declare the handle, uh, but not as a handle, uh, as, uh, we
28:24
declare it as a BH handle struct that wraps the handle itself as well as the index. Um, we, uh, generate a unique, global unique variable ID that will be appended to the variable name when we, uh, make a logging statement. Um, we then, uh, log the declaration for the
28:41
handle, uh, while appending the, uh, variable ID to the end of the, uh, name of the function. We proceed by, uh, grabbing a random handle from the object store and assigning it to the, uh, handle that we are, uh, gonna pass to the library call function. Uh, then we log the handle, uh, but, um, we log the handle by its index rather
29:01
than by, uh, by its, uh, actual value. Uh, and James mentioned this, but the object store at any point of the fuzzer run is populated in a deterministic way, at least in theory. So, um, if we are up to a point where we know the object store has certain handles, we can, um, refer to this, each one of these handles by its index and it should
29:25
be the case of getting the same handles that we got the last time we run with the same seed. Um, so, uh, we, uh, the last thing we do is basically log the final, uh, call that we're about to make. This is the actual call, the, the actual library call, um, and, uh, yeah, we log this with the, um, uh, with the respective
29:45
variables and, uh, and while, again, appending the variable ID at the end of them. Um, and then, again, the last, the last thing is just simply make the call. Um, something a bit more interesting. So, for example, this, uh, example demonstrating how to use the
30:00
helper functions. Uh, the helper functions are, um, uh, functions, uh, that will generate a valid struct, a window specific, window specific struct that is, uh, consumed by a library or a system call. Um, uh, and I'll be talking about the helper functions in just a bit. Um, but basically, this is a function taking two arguments, a
30:21
handle to a device context and a color ref, uh, uh, windows type. Um, so, um, we start with the same thing again. We declare the variables that we're gonna use, uh, within the wrapper. We generate the variable ID. Again, this will be globally unique across the run. Um, we, um, log the handle, um, again, notice that we log the handle as a
30:44
handle, not as a bh handle. Uh, we basically hide the implementation details for a bh handle when it comes to the reproducer test case. Um, we, um, drop a random handle, assign it to, uh, to our variable. Uh, the last, the next thing is log the handle by its index and the next thing is the interesting bit where we actually make a call to a
31:03
helper function. Uh, this one is, uh, get color ref. Uh, and it, uh, each one of the helper functions takes a single argument which is the variable ID. Um, so, get color ref will, uh, basically hide the details for us but it will populate, uh, with mostly valid data, again, uh, this, uh, struct that can later on be used, uh, by, uh, by our library
31:21
call. Um, and again, the last thing is log the statement, uh, log the, uh, call that we're about to make and make the actual call. Um, and now, a, a bit more about the helper functions. Um, there's just a endless number of, uh, custom structs in the Windows operating system, uh, and they are expected by a number of library calls and
31:43
system calls, um, and this is where the helper functions come. Uh, basically for each one of these, well, obviously we cannot implement for each one of them but for the most common ones consumed by the Win32k, um, system and library calls we have implemented helper functions. So basically we have helper functions for, um,
32:00
returning rectangles, points, sizes, uh, Windows, etc. Um, and again, um, these, these are mostly valid and they shouldn't really be, uh, way too, uh, malformed. Um, at the, uh, bottom of the slide you can basically see a snippet from the list of helper functions we have implemented. Um, again, the helper function will return a valid
32:22
struct, uh, the naming convention is get underscore name for the helper, uh, for the, um, for the struct and the single argument that will be consumed is the global unique variable ID. Um, this one is really, um, obvious and really, um, really easy to implement because it's, this is just a typed FD word in, in Windows, um, so
32:43
basically we start by, uh, declaring, uh, the color ref, uh, variable, uh, we, uh, log the declaration by appending the variable ID to the name of the variable, uh, we initialize the variable by calling get underscore first underscore UIN32, this will basically grab, uh, an, an unsigned integer from the first value, uh, store, assign it
33:04
to CR and then we log this value as it was assigned and return the, uh, the struct to the caller which will be then passing this struct to the library call. Um, something a bit more interesting, so, for example, this one is, uh, helper function for
33:21
returning, uh, rectangle, uh, rectangle is a struct with, um, 4 fields, uh, each one of them, uh, type long, um, so what we do is basically pretty much the same apart from initializing each one of the fields separately and for each one of these initializations we, um, we log in, in our log file. Um, case study, um, uh, fuzzing the
33:43
Windows, uh, VM, what do we need to do in order to basically get, uh, uh, a decent, uh, VM, uh, basically the VM in a decent state for our fuzzer to run, uh, in a, in an optimal, uh, way. Um, we start by installing Titan 3.5 and then we have a
34:02
general OS tweaks, um, this includes installing Wind Debugger, uh, installing the Python module for CouchDB communication in order to submit our crashes to the centralized database, um, we perform some minor, uh, tweaks in the registry including disabling error reporting, uh, disabling updates, et cetera. Uh, we enable, uh, kernel memory
34:22
dumps, um, basically this is where we get the information about the crash, um, uh, we enable Spatial Pool for the module, uh, that we're, uh, fuzzing, for the kernel, uh, mode driver that we're fuzzing, which in this case is Win32k.sys. A Spatial Pool is basically the equivalent of PageKeep in, in kernel length and, uh, Spatial Pool will make
34:41
it a lot easier to detect, uh, use-after-free VANs, double-free, uh, and some general pool corruptions as well, so it's very important to enable this. Um, and the last thing, an obvious thing, is to schedule the fuzzer control script to start on logon, um, and, um, reboot the system. Upon rebooting the system, uh, the fuzzer kicks in, the first thing to do is look up the, uh, location, uh, for where we store, uh, the, uh,
35:06
memory dumps. Um, so if there is a memory dump, we drop the memory dump, we run bang analyze using KDXC, um, uh, we store this in a log file that we will let Ron be submitted, we, uh, check for a leftor, uh, leftover, um, fuzzer log from, from a
35:22
previous run, and, and we basically assume the fact that, um, the, this is the log file that caused the last B sold. We bundle those everything, uh, we bundle everything together, uh, which is basically the fuzzer log, the memory dump file, and the output from bang analyze, and we submit all of these all together to, uh, CouchDB, uh, where
35:41
CouchDB will, um, basically, uh, in CouchDB will be able to, um, do some triaging and, um, querying based on the, uh, based on the crash. Um, there was pretty much about it. When it comes to Windows, again, we have done some stuff on, uh, Mac OS X and QNX. QNX, just to prove the, the, the concept that, that it actually
36:02
works and the fuzzer is more or less platform agnostic. Um, we haven't really spent too much time fuzzing Mac OS X and QNX, but we've got some, um, some, uh, again, prototypes for it. Um, when it comes to system calls, um, in our operating systems, they basically follow the same calling convention, which is, uh, system V, AMD 64
36:22
application binary interface. Um, and the object store for, uh, POSIX and Unix operating systems, uh, will, uh, store, uh, file descriptors most of the time, as opposed to handles. And file descriptors are more or less, um, similar to handles, which is basically the most similar thing we can get to handles. Um, and for the crash
36:42
detection, we have both, uh, the same choices, either attach a kernel debugger or rely on the operating system to get some useful information for us in the syslog. Um, this is just an example for a single function, um, wrapping an IO kit library call. Um, it's very much similar to what we do for Windows. The only difference is that we don't have
37:03
handles, we don't have, uh, or Windows specific helper functions. We have IO kit helper functions that will return an IO kit object when it's needed. And, again, very much similar. Uh, when it comes to syscalls on Mac OS X, we're kind of lucky because the X and U system calls are all stored in a single file called, uh, syscall.master, uh, and
37:23
this file can, uh, even, uh, be processed in an automated way to extract all of this, uh, system calls with their IDs and their arguments and basically turn this file into a collection of system calls that can later on be consumed by the framework. Um, some of the results, James already mentioned, uh, we're getting some interesting crashes in
37:42
wordy2k.sys, primarily in Windows 7. Um, why Windows 7? Well, probably because most of our users are on Windows 7, unfortunately. Um, of, as it, when it comes to other operating systems, um, again, we're looking forward to, uh, basically spending more time on there. Uh, the current implementation, um, for a Mac OS X specific and QNX specific
38:02
modules is just a prototype to be fair. Um, we have some crashes in hypervisors, which is something that we never intended to find, so this is basically just an annoying thing happening at the moment rather than, uh, something we can brag about. Um, we also found some interesting bugs in VMware tools and virtualbox guest additions. Um, basically,
38:22
these are, um, vones that may potentially be used for escalating privileges because VMware, VMware tools is obviously running with, um, uh, with, in, with an escalated context. Um, the setup that we're, uh, using, and this is just a setup for the stability runs. We haven't even, um, thought about scaling it at the moment, um,
38:43
because, mostly because we're satisfied with the results, uh, is, uh, host operating system win 10, hypervisor, VMware workstation, guest operating system win 764 bits, um, and the VM specs is pretty modest to be fair, uh, just 2 gigs of RAM and a single CPU per VM. Um, this is just to recap the, uh, results from, uh, what James
39:03
mentioned, uh, number of VM 16, stability run for 48 hours, 65 crashes, 13 of them unique, and this is before we started blacklisting all of the, uh, syscalls, um, causing a lot of problems. Um, breakdown on the type of crashes, we have 4 no pointer
39:20
derives, potentially exploitable in win 7, uh, fortunately for Windows not exploitable in win 8 and win 10. We have some, uh, use after freeze, 2 of them. We have, uh, 4, uh, pool buffer overflows, uh, basically pool, uh, pool corruptions, and, uh, we have 3 under the, uh, category of miscellaneous, basically, uh, 3, um, invalid
39:41
redoxes, uh, redoxes violations we haven't properly 3 hours by now. Um, this is a breakdown on the crashes, uh, the crashes, um, based on, uh, the bug check ID. Uh, the interesting thing here is to notice that a number of these crashes have been caught only thanks to, uh, special pool being enabled for the, uh, win32k.sys kernel mode
40:02
driver. So, should you run without special pool, you end up with at least half, uh, half of these crashes. Um, further work. What we can do to improve the framework and to improve the, um, the Windows specific modules for example. Uh, obviously we want to increase the coverage. Um, how can we increase the coverage? The, the
40:26
average, considering the current architecture, is object tagging. So, if you remember in the object store, we preserve a bunch of handles, but these are handles to any kind of object. So, object tagging would basically involve adding a, uh, another field in the BH
40:41
handle struct and this field will specify the object type for the handle where this handle is pointing to. Um, so when we make a request to the object store, uh, we will be, uh, specifying the type of object that we are expecting to find on the other side of the handle. Um, we have, um, well, obviously we can implement more, uh, more of
41:02
these, uh, library calls. Um, 500 is a good number, but there are so many of them we can, uh, we can implement. Uh, we have experimental implementation for user mode callbacks, uh, based in, uh, based fuzzing. Um, this basically works at the moment, but we have some problems with the logging. So, none of the, none of these, uh, results that I was talking about are, uh, with, uh, user mode callbacks enabled in our
41:25
framework. Um, so once we get this working, I expect even more crashes. Another thing is multithreading. Um, if you, um, can imagine the log file that we currently, uh, currently produce is a huge log file of C statements that are plugged into a main function and
41:42
executed in a, uh, sequentially basically. Um, so this is a problem with multithreading. All of these runs have been from, uh, single-threaded, uh, run of fuzzer. Um, uh, obviously we have to work on, work out how to implement proper logging with multithreading, uh, at the same time. Um, and, um, we, we can also look
42:02
at some, uh, coverage feedback based on, uh, CPU features. Um, so if you know about NCC's Triforce implementation, well, would it be possible to basically get something similar for, uh, for Windows? Uh, under miscellaneous, um, we're always looking forward to improving the logging because basically it's, it's just a really
42:21
tedious and, and slow process of implementing each one of these library calls with the log statements for each one of the C statements that we have in the file. Um, we haven't looked at handling, uh, hypervisor crashes at all. So basically if a hypervisor, uh, crash occurs, um, these days, um, we're just gonna have to, um,
42:40
monitor the database and see that the number of crashes is dropping and then we realize the hypervisor has been down for a few days. Um, test case reducer, we have considered, uh, looking at, uh, C reduce. This is a program, uh, which is basically a test case reducer, language aware test case reducer that can, uh, successfully reduce C files. Um, we haven't really, uh, implemented anything on top of that, but the
43:04
basic idea is that, uh, one VM will be reducing the test case, will be feeding the test, this test case to another VM. This second VM will be, uh, compiling and executing and will providing feedback back to the first VM, which is, uh, constantly reducing the test case. Uh, and just in general, we definitely need to implement, uh,
43:20
this and logging for, uh, for the VM and, and ideally this logging should be, uh, hypervisor agnostic. So basically this monitoring should be working on, um, VMware, VirtualBox, keymuse and et cetera. Um, these are the people we want to thank. These are all people who provided really valuable feedback and, uh, some useful ideas and information when, uh, we implemented the fuzzer. Um, and the basically the core of the
43:46
framework will be available online, um, I think later next week, um, as soon as we get back to the UK basically. Um, and yeah, keep an eye on Twitter, um, we'll be bragging about releasing the framework I guess. Um, but if there's any questions, I'm happy to
44:02
take them at the cafe area because I'm being told, uh, we're running out of time. Uh, but yeah, thanks guys.