Weaponizing Hypervisors to Beat Car and Medical Device Attacks
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 | ||
| 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/48430 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
00:00
SharewareNotepad-ComputerGradientHyperbelverfahrenGüte der AnpassungSchießverfahrenCybersexComputersicherheitCASE <Informatik>MultiplikationsoperatorProgrammierumgebungARM <Computerarchitektur>DifferenteVerweildauerWhiteboardComputeranimation
02:42
DigitalsignalGemeinsamer SpeicherDatensichtgerätFunktion <Mathematik>Vollständiger VerbandKraftPlastikkarteInfotainmentOffene MengeSoftwareLokales MinimumRobotikSystemplattformSchlussregelKonsistenz <Informatik>GraphikprozessorHardwareBefehlsprozessorPerfekte GruppeLaufzeitsystemBootenIntelSoftwareentwicklerSystemprogrammComputersicherheitCASE <Informatik>Interface <Schaltung>Güte der AnpassungTermComputerarchitekturComputeranimation
03:24
Funktion <Mathematik>SpieltheorieSoftwareFunktionalVirtuelle MaschineBetriebssystemPhysikalisches SystemProgrammfehlerInfotainmentHochdruckProjektive EbeneMalwareNP-hartes ProblemInterface <Schaltung>Rechter WinkelVirenscannerARM <Computerarchitektur>Computeranimation
04:54
UmwandlungsenthalpieDrucksondierungOvalWeb-SeiteSymboltabelleSichtenkonzeptSeitentabelleVerzeichnisdienstTextur-MappingKernel <Informatik>App <Programm>AdressraumInstantiierungKernel <Informatik>UmwandlungsenthalpieHalbleiterspeicherMailing-ListeMathematische LogikInterface <Schaltung>BetriebssystemPolygonzugTaskFunktionalAdressraumProzess <Informatik>SymboltabelleVirtualisierungProjektive EbeneRohdatenCodierung <Programmierung>Open SourceBesprechung/Interview
06:44
PunktHardwarePhysikalisches SystemFahne <Mathematik>BefehlsprozessorSoftwareEinfache GenauigkeitCodeHardwareAdressraumWeb-SeitePhysikalisches SystemIntelURLProgrammVerzeichnisdienstCASE <Informatik>PunktMechanismus-Design-TheorieKontrollstrukturSeitentabelleDatenflussHalbleiterspeicherKartesische KoordinatenProzess <Informatik>SpeicheradresseMAPBetriebssystemVirtualisierungUML
08:53
Graphische BenutzeroberflächeWeb-SeiteRandwertMaßerweiterungSeitentabelleVerzeichnisdienstSpeicheradresseBefehlsprozessorPunktFahne <Mathematik>KontrollstrukturSoftwarePhysikalisches SystemDebuggingTropfenHalbleiterspeicherAnalysisSeitentabelleUmwandlungsenthalpieVerzeichnisdienstWeb-SeiteMaßerweiterungTranslation <Mathematik>Rechter WinkelAdressraumInformationsspeicherungMAPComputerarchitekturVirtualisierungKernel <Informatik>ZweiImplementierungSchnittmengeATMWort <Informatik>MultiplikationsoperatorFront-End <Software>DatenflussSichtenkonzeptBesprechung/InterviewComputeranimationDiagrammFlussdiagramm
11:31
AdressraumKontrollstrukturVirtuelle MaschineVirtuelle RealitätDatenstrukturROM <Informatik>Zeiger <Informatik>Translation <Mathematik>ProgrammierumgebungZweiPublic-domain-SoftwareProgrammierumgebungPhysikalisches SystemSystem FWhiteboardTypentheoriePartitionsfunktionHardwareZeiger <Informatik>PhysikalismusImplementierungVirtuelle MaschineInformationsspeicherungAdressraumVirtualisierungURLTranslation <Mathematik>SichtenkonzeptTabelleRechter WinkelMaßerweiterungMAPHalbleiterspeicherBefehlsprozessorWeb-SeiteKontextbezogenes SystemMultiplikationMereologieDifferenteMultiplikationsoperatorSystem-on-ChipFunktionalMapping <Computergraphik>CodeCASE <Informatik>GamecontrollerSpeicheradresseProjektive EbeneSeitentabelleSoftware Development KitPunktARM <Computerarchitektur>SinusfunktionProdukt <Mathematik>Besprechung/Interview
17:06
ViereckSpeicherabzugDualitätstheoriePlastikkarteGebäude <Mathematik>DateisystemProgrammierumgebungWhiteboardEmulationCLIDebuggingPhysikalisches SystemDatenverwaltungSystemplattformBootenMAPKernel <Informatik>FirmwareTopologieKonfigurationsraumSpezialrechnerSoftwaretestAlgorithmische LerntheorieMinimumWrapper <Programmierung>Rechter WinkelProgrammierumgebungVersionsverwaltungElektronische PublikationWhiteboardClientProgrammbibliothekInstallation <Informatik>CASE <Informatik>Einfache GenauigkeitVirtuelle MaschinePlastikkartePartitionsfunktionURLWurzel <Mathematik>AggregatzustandBootenProgrammNotepad-ComputerGeradeDateiformatSystemplattformDatenverwaltungDebuggingUmwandlungsenthalpieMAPTopologieKonfigurationsraumARM <Computerarchitektur>Kernel <Informatik>AdressraumStandardabweichungReverse EngineeringBefehlsprozessorWeb SiteZweiSimulationBildgebendes VerfahrenRichtungInformationProjektive EbeneNP-hartes ProblemImplementierungExploitVerschlingungEinsQuaderEin-AusgabeRegulärer GraphBootstrap-AggregationPhysikalisches SystemPunktRelativitätstheorieMehrkernprozessorProgramm/Quellcode
22:27
BestimmtheitsmaßDefaultSichtenkonzeptEinfache GenauigkeitROM <Informatik>ARM <Computerarchitektur>StrebeSichtenkonzeptARM <Computerarchitektur>MaßerweiterungHalbleiterspeicherVirtualisierungWhiteboardComputerarchitekturSystemaufrufBefehlsprozessorKartesische KoordinatenDefaultKonfiguration <Informatik>GamecontrollerAnalysisParametersystemKernel <Informatik>PunktKontrollstrukturEinfache GenauigkeitProzess <Informatik>URLWeb-SeitePhysikalisches SystemSpeicheradresseBetriebssystemTouchscreenBestimmtheitsmaßLastTVD-VerfahrenMinkowski-MetrikSystemzusammenbruchSystemplattformCodeAdressraumValiditätImplementierungZweiNichtlinearer Operatorsinc-FunktionDifferente
27:49
Hook <Programmierung>Einfache GenauigkeitARM <Computerarchitektur>EreignishorizontHalbleiterspeicherPhysikalisches SystemInfotainmentFunktionalSystemaufrufGamecontrollerProzess <Informatik>MalwareParametersystemSpeicheradresseSystem FMomentenproblemAggregatzustandSchaltnetzMechanismus-Design-TheorieVirtuelle MaschineTypentheorieFramework <Informatik>Maskierung <Informatik>Komponente <Software>Rechter WinkelMultiplikationsoperatorARM <Computerarchitektur>SystemzusammenbruchWhiteboard
30:53
SharewareMultiplikationsoperatorSystemaufrufTypentheorieHalbleiterspeicherProzess <Informatik>Rechter WinkelWhiteboardKomponente <Software>PerspektiveMereologieVirtuelle MaschineAlgorithmische LerntheorieARM <Computerarchitektur>Programm/QuellcodeJSON
31:39
HypermediaARM <Computerarchitektur>Prozess <Informatik>MalwareBenutzerprofilExploitNabel <Mathematik>CodeRechenwerkSystemaufrufPhysikalisches SystemROM <Informatik>Kernel <Informatik>BestimmtheitsmaßKonditionszahlVirtuelle MaschineEndliche ModelltheorieZweiRechter WinkelKartesische KoordinatenSystemaufrufMailing-ListeFolge <Mathematik>Hook <Programmierung>ÄhnlichkeitsgeometrieWeb-SeiteDifferenteKernel <Informatik>Ordnung <Mathematik>TLSProzess <Informatik>Physikalisches SystemMultiplikationsoperatorComputerunterstützte ÜbersetzungLaufzeitfehlerProgrammfehlerLoopVirenscannerProfil <Aerodynamik>EntscheidungstheorieDatenflussMalwareSystem FInfotainmentAlgorithmische LerntheorieImplementierungQuaderPerspektiveCodeMultiplikationSpieltheorieNabel <Mathematik>CASE <Informatik>GamecontrollerARM <Computerarchitektur>SoftwareKonstruktor <Informatik>FitnessfunktionFehlermeldungRelativitätstheorieHalbleiterspeicherQuadratzahlBestimmtheitsmaßAggregatzustandMetropolitan area networkMomentenproblemBimodulDatenkompressionComputeranimation
39:25
SichtenkonzeptROM <Informatik>Prozess <Informatik>SystemaufrufKernel <Informatik>MultiplikationsoperatorSichtenkonzeptHook <Programmierung>GamecontrollerWeb-SeiteHalbleiterspeicherSystemaufrufMalwareCASE <Informatik>ARM <Computerarchitektur>Prozess <Informatik>ATMForcingHauptidealringBeweistheorieTermsinc-FunktionKartesische KoordinatenLesen <Datenverarbeitung>Virtuelle MaschineKernel <Informatik>InformationSystemzusammenbruchDifferenteAusnahmebehandlungTLSOrdnung <Mathematik>System FAggregatzustandQuaderCodeDefaultAdressraumWellenpaketProxy ServerRechter WinkelBefehlsprozessorQuadratzahlBesprechung/Interview
46:20
Prozess <Informatik>Kernel <Informatik>HypermediaInfotainmentInformationDreizehnRechter WinkelMalwarePhysikalisches SystemQuaderHauptidealringProzess <Informatik>Virtuelle MaschineComputeranimationProgramm/Quellcode
47:20
InfotainmentMachsches PrinzipLemma <Logik>Lokales MinimumSummierbarkeitDatentypDreizehnVirtuelle MaschineBildschirmfensterNormierter RaumWinkelRechnernetzCASE <Informatik>Hook <Programmierung>Virtuelle RealitätSocketTaskPolygonzugStrebeProzess <Informatik>MinimumSystemzusammenbruchPhysikalisches SystemInternet der DingeAdditionSichtenkonzeptBetriebssystemSoftwareHook <Programmierung>SocketOffene MengeMailing-ListeTaskGemeinsamer SpeicherInfotainmentEreignishorizontElektronische PublikationComputeranimationProgramm/Quellcode
49:17
Prozess <Informatik>ParametersystemZeichenketteSoftwareEinfache GenauigkeitMechanismus-Design-TheorieEreignishorizontVirtuelle MaschineDatenverwaltungWeb-SeiteROM <Informatik>Physikalisches SystemIntelARM <Computerarchitektur>ProgrammierumgebungElektronische PublikationVerschlingungWhiteboardBootenSpezialrechnerKernel <Informatik>MalwareSoftwaretestSkriptspracheKonfigurationsraumVersionsverwaltungEreignishorizontSichtenkonzeptMechanismus-Design-TheorieCASE <Informatik>Physikalisches SystemQuaderKonfiguration <Informatik>Elektronische PublikationMultiplikationDatenverwaltungWeb-SeiteMalwareWhiteboardBootenTabelleHash-AlgorithmusGüte der AnpassungParametersystemGemeinsamer SpeicherTropfen
51:16
SystemaufrufAdditionARM <Computerarchitektur>SichtenkonzeptROM <Informatik>MalwareSystemprogrammierungWhiteboardProzess <Informatik>PlastikkarteMaschinelles LernenEndliche ModelltheorieCASE <Informatik>SichtenkonzeptSystemaufrufARM <Computerarchitektur>SpieltheorieMalwarePhysikalisches System
Transkript: English(automatisch erzeugt)
00:00
Alright, we got a talk here on weaponizing hyper- hypervisors by Ali and Dan. Uh, and we have a little tradition here, uh, Def Con for those that are new to speaking at Def Con and do you, do you, does anybody know what that, uh, what that is? So this is called
00:27
Shoot the Noob, um, and uh, you know, those of you who can cheer them on as we, uh, do our shot here for the first time speakers. Hey guys, thank you for coming. Uh,
00:52
really excited to be here. Uh, it's our first time as you saw. Um, I'm Ali Islam, I'm the co-founder and CEO of Neumann. Uh, I've been in the cyber security industry for the last, uh,
01:04
13 plus years and for a long time I, I was working for a company called FireEye. It's another cyber security company. So, um, that's, yeah. Dan, do you wanna? Hey guys, my name is Dan Regalado, um, I'm so excited to be here because you know it's the first
01:21
time in Def Con so, so glad and, and blessed. Y quiero agradecera mi esposa, y mis hermanos and los amigos. Esa banta megicana que esta aqui, señores. May, may, Def Con speak Spanish. Cool. Okay, let's, uh, let's get started. So, here's a quick, uh, overview of
01:47
like, uh, how we organize our talk. So we're gonna introduce some, some of the basic concepts. Uh, these concepts are really important, uh, and kind of a foundation upon which we build our, uh, later detection cases, um, and, you know, other policies. Uh, apart from
02:02
that, uh, then we're gonna explain the embedded, whole embedded environment, the journey, you know, setting up the board and, uh, the environment that we play in. And then we're gonna talk about the very important VMI on ARM. Uh, I'll explain shortly what VMI is. And, uh, finally we'll discuss about, uh, different attacks, uh, use cases, and some
02:24
of the recommendations. Uh, okay. So, uh, why is Hypervisor so important and relevant? Uh, as you can see, uh, all of the major players, automotive grade Linux, Renesas, uh,
02:42
Denso, Alibaba NXP, uh, Perom Robotics, uh, you, I mean, there are a lot of uh, there are many, uh, Greenhill, Intel, they are all have now the Hypervisor in their architecture. And, uh, the traditional use case for Hypervisor is basically the efficient utilization of the resources and, uh, probably the isolation use case. Uh,
03:06
however, um, not many people have explored Hypervisor, uh, for security in terms of, uh, you know, how you can use Hypervisor to build a really good security system. Uh, isolation is there, but not the VMI, uh, that we're gonna talk about. Okay, so, uh, the beauty of
03:27
Hypervisor is that it exposes, uh, an interface which is called, uh, you know, the introspection interface. It's also called virtual machine introspection. What it does, uh, or it allows you to do is, um, you can monitor the whole system from the outside. Uh,
03:43
that's really powerful and, uh, we haven't seen many people using it, especially on the arm. Um, so, you know, we were very excited to start on it and it was a long, very hard journey because, uh, there's not much out there. There are like few projects or papers out there. Um, so, traditionally the anti-virus, we all know that it has a lot of
04:07
issues, it sucks. Um, but mainly, uh, you know, when the any advanced malware comes into the system, uh, the first thing, uh, it does is, uh, basically check if there is an agent inside or if some, somehow it's being monitored. And, um, uh, if you're sitting outside of
04:25
the printing system, you solve that very important problem automatically. So you, so, basically you have that sophisticated invisibility. Uh, apart from that, uh, not having anything inside the operating system also helps with, uh, you know, uh, the different
04:41
certifications because you're not messing up with the device functionality. Imagine, you know, you're securing a car infotainment and then, you know, certainly, you know, there's a bug in your software which kind of messes up everything, right, so you don't want that. Okay, so, let's get started on the, uh, on the VMI. Um, what is, what is VMI or
05:01
what, what kind of, uh, interface hypervisor expose? Basically what you have is raw memory. And, uh, you take the raw memory and you use some of the OS specific knowledge to actually make sense out of it. For example, you, you should really know, like, where kernel is storing what and, um, and then, uh, you know, you kind of like build your
05:23
logic around it to really make sense out of it. For example, if you, if you, uh, take the raw memory and you know where the, uh, Linux task list is stored in the memory, you can go to those offsets and then you can start decoding and, you know, finally, as you can see here, uh, you can, uh, decode this task list and traverse this task list from the, uh,
05:46
raw memory. Uh, to give you an example, uh, for example, if you have to read a kernel symbol value from the raw memory, you know, it looks like a simple thing if you are inside the operating system. However, from a VMI, uh, it's a very complex, uh, process. So,
06:04
what will happen is, um, first of all, uh, you know, once you say, hey, you know, I, I want to read the, uh, value of this virtual address. First of all, VMI, uh, by the way, we are using, uh, libvmi, uh, we highly recommend, uh, it's an open source project. It kind of
06:21
provides the basic functionality, uh, that you need and on top of that we build our own functionality. Some of the basic functionality might be like the, you know, um, I'll explain you shortly, like, once this is done, for example, the caching and, and some of those, uh, capabilities. So, uh, we really recommend using libvmi. So, what will happen, uh, let's say if you have to read the value. Uh, you'll get the virtual address, libvmi will
06:45
first, uh, go and check with the system map, uh, to see, uh, you know, where the virtual address is. And then, um, uh, take that and then, uh, map it to the page directory. Uh, the page directory will, uh, be added to the, some of the bytes from the
07:04
virtual address to map to the page table and finally to the actual physical location in the memory. And then it will come back and give that value back to the VMI application. So, that's the, that's the general flow of how, uh, you know, you can, uh, get the value,
07:22
value out. Uh, also, uh, here you can see that once you go through this process, you're not gonna do that again for this particular, uh, virtual address. So, that's where, again, libvmi comes in. Uh, it has a very efficient caching mechanism. You can do on your own also, but, you know, in case you wanna avoid some of that work, you
07:42
can, uh, just simply use the libvmi. Okay, another very important, uh, concept that is critical to, uh, you know, what, what we're gonna show you today is single stepping. Um, because we're gonna show you eventually how you can, uh, get the system calls out, uh, by
08:01
staying outside of the operating system through VMI and from the raw memory. So, I'm sure you have, uh, all used, uh, debuggers and single stepping in your own use cases including reversing. However, um, there, there, there, there are other, uh, single stepping and break point mechanism that I wanna quickly touch on. The hardware break points is basically,
08:25
um, um, are mainly used for, uh, code that sits in the room. Uh, so, basically, uh, when the code is not in the RAM, you cannot override the break point instruction. So, what you do is, uh, you have these, uh, special registers provided by ARM and Intel. For
08:43
example, on Intel, it's D0 to D3. Um, and you store those, uh, locations, uh, memory location values in those registers. And then, uh, when program counter, uh, comes to that particular memory location or that instruction, it just halts the execution and then you
09:00
can analyze the whole system. Um, another is the software break points, uh, you know, is the most common one. CPU assisted that we use in debuggers, uh, for example, you will set the trap flag in the E flags register and then you'll, uh, uh, let the CPU do the work, uh, once the break point hits, the CPU automatically do the single stepping. But what
09:22
really is single stepping, uh, you know, when we start, what happens in the back end? Uh, so, in the back end, what happens is there is a special in, uh, for example, called int1. Um, when the break point hits, you know, you, you do the whole analysis. However, in the back end, that instruction, uh, the CPU makes sure that it also
09:42
executes the original instruction and then move on and then move on. So, that's very important. And now the third one is the software break points with no CPU systems. So, we're gonna use that, uh, in our implementation and there are reasons for that, uh, that I will explain you once we are done with the basic concepts. But just, just keep that, the concept, the single stepping concept in your mind. Um, apart from that, uh, in our
10:06
implementation, as I said, right, you're playing with the live raw memory. So, you really need to know how the kernel internals, uh, and how the kernel is, you know, organizing the memory and how everything is, uh, working inside. So, you have, you need to have that, uh, basic knowledge. So, uh, we all know that, um, from quite some time, we
10:25
now have the paging, the virtual addressing, uh, since 286, where the real, real addressing mode ended. Um, and then this is a typical, uh, 2 level, uh, paging. We also call it SLAT, second level address translation or, you know, the, uh, and, and it is
10:42
implemented using the extended page table and the virtualization extens- uh, extensions that the newer architectures provide nowadays. Um, so, to quickly, uh, follow the flow, um, like I was saying, for example, if you are going to read a value, this is how it looks like. So, basically, you take the first 10 bytes, uh, add it to the CR3. CR3 is a special
11:07
register which stores the base of the page directory and you add that, um, 10 bytes to the CR3 and then, uh, it takes you to the base of the page table entry and where, uh, then you again take, pick the next 10 bytes and then you add them to get to the right page
11:22
table and finally, you add the 12, uh, 12 bytes which are the offset into a specific memory page, uh, from which then you fetch the value. Okay, this is a, uh, this is a another view of just what I, I just, uh, explained. Uh, so, 2 levels of translation. First,
11:41
from, uh, virtual machine to the VM physical, uh, V-VM virtual to VM physical address and then from VM physical to machine physical. So, basically, you have this hardware on, uh, running right on top of the, by the way, we are talking about the bare metal, the type 1 hypervisor, right? So, so, you have this, uh, hardware, the hypervisor sitting right
12:03
on top of it and then, you know, there are, there are, like, different domains or the VMs. Um, so, the second level of translation is, uh, handled by, uh, a table called extended page tables and there is a pointer EPT. Uh, for example, Zen hypervisor
12:21
stores that, uh, per VM and it is used to, uh, do the translation. Uh, EPT, there's you guys can see what EPT is doing is it is eventually giving you the value from the memory, right? It, it points to the eventual physical location where the, where the value is. And, uh,
12:45
the newer, uh, virtualization extensions, um, uh, for example, Intel and ARM, uh, they have, um, a way where you can store multiple EPT, uh, pointers, uh, per VM. Now, that is very powerful, uh, because, one, you can, uh, for a, each page table, there are permissions,
13:06
right? So, you can assign different permissions to it and, uh, uh, that way, you know, for example, if you assign, if you assign permission execute to one page and then read right to another page, you know, you can play with those permissions. Uh, and I'm gonna show you,
13:22
um, later in the, in our talk, uh, some of the use cases, uh, but for now, I think it's very, uh, critical to, you know, what we're gonna do, uh, uh, what we have implemented in our implementation. The second, um, uh, interesting fact about EPT is like, you can, as I said, you can store more EPT pointers apart from, uh, partition. What you can do is
13:45
you can actually point a EPT to a different memory location. Now, what that means is, basically, for example, if you are, um, you have to translate one virtual address, right? Uh, you can play with that last level of translation and then, you know, at one
14:03
time you are, uh, giving one value, at the other time you are giving another value. So, basically, you are using the same code, you are creating two different behaviors, uh, which is very powerful, um, and there are many use cases for it and, uh, you can see the code snippet in the Zen where it stores the, and the permissions also. Uh, yeah,
14:26
that's the one I was talking about, like, for example, uh, the second EPT is actually pointing to, uh, another, uh, memory location and, uh, I'll, I'll also talk to some of the implementation details, um, you know, it's, it looks, it looks easy but it's not
14:41
that easy. So, for example, you have to create, um, all of the pages in the memory yourself, uh, Zen, Zen hypervisor, for example, have, do have APIs, so, uh, but they're not very well documented so you have to play with them and you create, for example, increased reservation is one that you can use to create pages. So, once you create the
15:02
pages, you have to maintain all the mappings but, uh, you know, Zen provides, uh, uh, functionality to switch between different pointers. And, uh, uh, another very, uh, important aspect of this is, like, um, you know, uh, this switching between different EPTs or you can call them the memory views because essentially what you're doing is you're
15:24
creating different views of, of the memory so you can present one view to one user and other view to other user and, you know, by user, a user can be a malware also. Uh, the, the, the best part is that, uh, the VM exit, uh, VM exit is a very, uh, expensive
15:41
operation, uh, what, what by VM exit means is like when, uh, you know, you're running your domain on top of hypervisor and suddenly the control has to be transferred to the hypervisor. What, what that means is hypervisor has to store all of the virtual CPUs inside that domain, the context of all those virtual CPUs and then get out and get, take the,
16:02
give the control to the hypervisor. But, uh, switching between these EPTs, there's no VM exit. So, it's very fast and I, I will explain later, like, why performance is very critical to, uh, anything you're doing, especially building a detection system using VMI. So, okay, yeah, so, uh, once we understand the basics, uh, we started playing
16:26
with an environment, right? We need to have a board to play with this whole, uh, implementation. In, in our case, we didn't have a, a specific board, so we went to LinkedIn, we used Google, uh, Silenx, you know Silenx, uh, FPGA creators, and turns out
16:44
that this guy has a pretty cool, uh, board, uh, which is, uh, MP SoC CC-102. The problem was that that board is $2,500, just a starter kit. So, we talked to those guys, we tell them, hey, you know what, we have this project in mind, and, kudos to Silenx, they
17:00
just ship us, ship, ship the board to our house, and then, uh, we started playing with, with the whole environment. So, this is a board, it's just a, please, uh, standard, uh, uh, input and output, so we have an SD card to root the root FS, we have Ethernet, UART, it's JTAG, uh, and we have, uh, quad core A53s, that are the arm
17:23
CPUs, uh, dual core R5F, so, this is the board that is very expensive, but don't worry, the, uh, what we are presenting is, is can be used in the, in any other board. So, the first thing that we were learning, guys, because in, in, when, I, I am like, in reverse, or, you know, exploit related guy, this kind of board, I never played with
17:44
it, but it's very challenging because we are running same hypervisor on it, and there is no implementation on this board with the VMI inspection on it, so, it was kind of hard for us because there is no support. So, we learned that there is a peta Linux project, which basically helps you to, uh, uh, deploy the whole, uh, uh, information into the
18:04
board, so that you can put it up. It's pretty cool, the only problem is that, um, it works with the specific images. So, we have our own same hypervisor custom, uh, deployment, so, it was a problem for us. That's the first thing. Second thing is, peta Linux is for
18:21
Xilinx, right? What if tomorrow we want to deploy the same environment in Renesas, NXP, others? So, we don't want to just tie to Xilinx related stuff. So, then we, we went to Jokto. You know, many of you guys know Jokto very well. Well, in my case, was like, uh, I don't have an idea. It, it turns out pretty cool. Uh, the only problem was that the
18:40
rootFS at the end was busybox related. That was a pain in the ass for us because, uh, once we have everything up and running, we really need Python libraries to run our machine learning and stuff, and it was a pain to just compile a single library, like tensorflow for example, and machine learning. So, it was pretty cool, pretty easy to run, but at the end of the day, a busybox, rootFS, rootFS, it was a, a pain for us. So, we
19:03
end up choosing the bootstrap. The bootstrap allows you to have a rootFS, in this case, ARM64, Debian based flavor. So, you have apt-get, you can download all the libraries. So, it was the way for us to go. Very recommended instead of the, of the previous one. Now, in the live environment guys, so, you don't wanna push everything on
19:23
the board, right? Because the board is like the production environment. So, you really wanna have a, a test environment. So, in our case, eh, we, we pick a CH, S CH root, this is a wrapper for CH root. It is pretty cool because we have our Ubuntu Intel x64 environment, as you can see in the picture in the, in the bottom. So, with this, eh,
19:43
Intel based environment via S CH root, you can, you know, eh, using chemo, you can CH root into the environment, you can do your testing, install libraries, connect to internet, everything like you were in the board, but once you test everything, then you can jump into the board. Pretty convenient for us. Eh, now, let's boot the board, right? So,
20:02
what do we need to boot the board? Silence has a specific, eh, debugger, which is called Silence system debug client. What it basically does, it reads a TCL file. That TCL file, just you guys to have an idea, what basically it's doing, it's gonna boot four different files. The P N U F W, which is just to set up the pro, the clock and
20:21
platform management on, on the board. Then the, the first, eh, stage boot loader, which is gonna initialize U boot. Eh, then U boot, which is gonna allow us to boot the hypervisor, in this case, same hypervisor, then the Linux kernel, and finally the Rutefest, eh, and the BS31, which is ARM trusted firmware. We didn't play with these components, eh, we
20:41
just used them with the versions of Silence. Important to mention that if you combine versions, eh, it will never boot the board. So, we have a lot of pain, eh, trying to play with different versions and it was not booting. So, once you reach, eh, this initial state of JTAG, you get into the U boot prompt, and now let's boot the board,
21:00
right? So, the first thing is, you know, the data device 3 blob, eh, that's where all the configuration from the board is, is located. So, the first thing is the root, eh, location, right? Where is your root FS, eh, that you wanna boot on? In our case, it's an SD card partition, as you can see there. Then, the second thing is, eh, we have our
21:20
same hypervisor, we just convert it into U boot format with that command line, and then you start booting up the system. You know, this is the typical U boot, eh, commands, so the first thing is you boot, eh, the same DTB, which is the device 3 blob, in a specific, eh, location, then you boot the, eh, the Linux kernel. That Linux kernel, you see the 80,000 address, that address must be exactly the same address that
21:45
you have in the DTB. Otherwise, when it is booting up, it doesn't, it's not gonna find the Linux kernel address, and therefore it's not, it's not gonna boot. Eh, then you load the same hypervisor, and finally you run the boot M, which is basically telling you, okay, so boot the board, eh, in the address, you know, 140, eh, 100,000, which is, eh, the
22:05
same hypervisor, then the hyphen in the middle is telling that you need to grab the address to boot the first direct, eh, path from the DTB, and finally you have a, eh, the same DTB. With this, eh, we can boot it to the board. This take, this same, eh,
22:20
specific steps guys, for us, eh, it took us many days and months because it was a lot of issues booting the same hypervisor, eh, another important point here guys is that those addresses that you see there loading, if you don't have enough space between them, they are gonna overlap, and then your board is gonna crash, so suddenly we were just, you know,
22:41
booting up, it was crashing, and turns out that, eh, you need to have enough space for every single memory address, but there is no validation on it, so you need to make sure that whatever the same hypervisor is loading in memory, the Linux kernel, that has enough space so that you don't overlap, eh, and you don't, eh, you know, you, you don't get a kernel panic or, or same hypervisor problem. So, let's get the
23:08
damn syscalls out, eh? Uh, basically, uh, I don't know, I mean, it's, it's, it was, uh, it was kind of, uh, almost became a dream for us to see this arm syscalls on the screen
23:21
because, you know, we've been going back and forth, we tried different things, we always get, got stuck because, you know, as I said, it's not very well documented and, you know, uh, there are few research papers out there, so we were like just trying different things, playing with the memory and finally, you know, we figured out, um, or we did our own implementation. So, eh, eh, as you guys remember, I was, I was mentioning
23:44
about what single stepping and, you know, this why single stepping is very important and why, you know, we, we've been, we're gonna use the, uh, known CPU assisted single stepping. Uh, the reason is like, uh, since we were using the Zen hypervisor and Zen
24:01
hypervisor does not support single stepping on arm, so we have to figure out our own way of doing what normally a CPU does and, uh, we found a, a very interesting paper online, uh, we talked to that guy also, Sergei from Germany, uh, so, and then we reviewed some other techniques online and we finally, uh, decided to use this technique. It's, it's a
24:23
very fascinate, fascinating one, uh, so remember EPT helps you create different views of memory, right? And so, first, the first step is, uh, basically you create two views of the memory. By views, I mean like, um, you just take the whole memory, take all the pages,
24:42
you create the copy of those pages and then, you know, you have these two copies in your memory, uh, for those pages. And then, uh, since Zen hypervisor provided this support to have multiple EPTs, so you point one EPT, you know, let's just call one view default view and the other the single stepping view. So, you have two EPTs now, uh, one is
25:02
the default view. Default view is the one where, you know, you'll, you, you, you're gonna run by default when the system starts, that is the view where you're gonna, the control will be and the execution will happen. And then you have another view in the memory waiting, uh, if you wanna switch to that one. So, we have these two views and, uh, I'm
25:22
talking, remember, I'm, now I'm talking in context of the, the sys calls. So, the goal is to, uh, start monitoring the ARM sys calls, um, or the operating system, system calls on an ARM platform, right? So, so, think of it like, okay, you wanna monitor a particular system call, it, the code is in, in the memory somewhere, so you find the location of
25:42
that, uh, uh, that, that API, uh, in the memory. So, you, for the, uh, at the first instruction, you put, uh, one breakpoint. And on ARM is, uh, sorry, so on ARM is, uh, ARM, uh, the breakpoint is this, uh, D40003, uh, it's also called SMC, it's a special
26:05
instruction, on Intel it's INT3, so, uh, you can use the same for Intel also, but you don't have to use the, the, this one for Intel, uh, just to mention that because, uh, Zen actually supports, uh, single stepping on Intel, so you can just use that one. Um,
26:23
so, on the, the first instruction, uh, you put one breakpoint in the default view. And then, um, on the second instruction, you put another breakpoint, but in the single stepping view. Now, what will happen, uh, in, the, the control is in the default view, and,
26:40
uh, you know, you just, uh, once the first breakpoint hits, uh, what you do is you do your analysis, you wanna get the syscall, you know, you note down all the parameters, what process call the syscall, whatever analysis you wanna do, right? And then, you switch the view. You switch the view, and the control will go to the instruction 1 in the
27:03
second view. The instruction 1 will get executed, and then the second breakpoint will hit. When the second breakpoint hits, again you get the control, you switch back to the default view, and then the second instruction gets executed. So, basically that's how you single step, uh, on ARM if you're using the Zen hypervisor, and not many
27:24
hypervisor support ARM, so, Zen is probably your best choice, uh, unless you wanna build your own hypervisor from scratch, that is an option too. So, uh, this technique is, is very fascinating, and, and, you know, as I was saying, this is one of the applications of the views that the underlying architecture, uh, provides through the virtualization
27:44
extensions. So, that's how we, we single step, uh, on ARM in our implementation. And, so let's take a look. Overall, how do you now, um, as a detection or as a monitoring system using VMI, how do you monitor from the outside, right? So, using all the concepts that we
28:02
have, uh, so far shared, right? So, what you will do is, um, uh, first of all, you will, um, put a hook on any, every function or every API, uh, in the memory that you wanna really analyze or, for example, you might wanna always, uh, analyze sleep, because malware
28:22
uses sleep a lot. Um, so, the first step is to, uh, put that breakpoint, go to that memory location and put that instruction, uh, and in combination you have to register an event. Now, a good hypervisor always provides, uh, event mechanism, right? So, you, you wanna, you wanna monitor something, it provides you an event mechanism, and Zen does the
28:43
same. So, you register your event, and then you also register your callback. So, that's the second most important because with the callback function that you're gonna register, what it does is, you're telling the hypervisor, hey, anytime my breakpoint hit, you, you know, give me the control and execute this function. So, in this function, you're gonna do
29:01
everything. For example, you're gonna extract, once the breakpoint hits, you're gonna extract the parameter values of the function, you know, the function name, process name, or whatever you wanna do, you do in this function. The single stepping functionality that I showed you, um, in the previous slide, you will also do in this function. So, that's the second, uh, most important step. Uh, the third step is obviously, you know, you need
29:24
to single step. Remember, so, if you don't single step, what will happen? Uh, the breakpoint will hit, you don't single step, the control will stay there, it will continue to execute the same instruction, the system will get into a very unstable state and,
29:42
you know, imagine you're protecting a car infotainment and then you will, you will crash the system. So, it's very important to make sure, you know, you properly single step. And finally, you know, once you're done monitoring, uh, make sure you remove all your hooks from the memory and, uh, you know, you, you know, you do a very clean
30:01
exit. So, that's how you basically, um, do, uh, the syscall monitoring through VMI. And, uh, on ARM, especially, it was challenging because, uh, you know, as I mentioned, there was no single stepping and there was no documentation, so it took us some time, but, you know, finally we're very happy that, you know, we achieved this. So, let me, let me
30:22
now show you how it looks like, uh, our moment of, uh, happiness. I first saw this, uh, I hope it, okay, so, how do I show it? Okay. So, this is our Xilinx board, uh, we
30:58
have our introspection framework, we call it Newman Introspection Framework, and, uh,
31:03
yeah, these are, these are how the syscall looks like, you know, the process name and everything. Uh, now, see, you know, we're typing and then you see all the syscalls being logged on the upper right. And then now I type top, and then you can see the process name top being tracked. This is happening, everything happening from the ROM memory outside
31:23
the operating system, so that's pretty cool. And now finally, you know, we do a, we do a sleep, and then, uh, you're gonna see the sleep being, uh, shown. And not only shown, because we have other components, uh, it's, it's also being monitored as highlighted here, so, uh, not only we get these syscalls out, we also, uh, send it to
31:42
our machine learning model to, to monitor it. So, that was our, uh, it took us quite some time to achieve that one. And, yeah, that was the. Okay guys, so let's get to the phone part, because, uh, uh, after this whole effort, as you can see, now we know the basics,
32:04
we know how to arm, uh, use, uh, BMI to introspect into the machine learning, uh, everything, right? Now let's see what we can do, uh, from a tax perspective and detection with these components, uh, in, in the world, right? So, the first approach is a
32:23
typical malware, uh, coming into a car, into a medical device, right? How can we tackle that problem from BMI? So, if you have been working on, uh, antivirus companies or sandbox related companies, is, is the typical way to do it is very common, but keep in mind, here guys, we are out of the box. We don't have an agent
32:42
inside, and, and that's a totally different, different beast. So, uh, let's see the first example. In this example, we have a, a, a malware running. So, what we do in this specific scenario is we, we're gonna use machine learning in order to detect attacks. So, what we do is we get, let's say, the infotainment from the car and we profile it.
33:01
Get all the processes running, we feed it into, into our, uh, autoencoder, which is neural network, uh, based, uh, approach. And, and what it's gonna do is it's gonna learn how a healthy sys, how a healthy system looks like, all the processes, all the differences calls being executed. So, once it learns that, eh, when we, when it is
33:22
running a process in the infotainment, it's gonna grab that profile, which is in the left side, the actual profile. That is gonna be feed into the autoencoder. And then he, the autoencoder is gonna create a new profile based on his learning experience. Once it's generated, if the similarity between the reconstructed profile and the, and the, and
33:42
the profile that was running in the, in the, in the device, is, is, it has really low error, which means it's very similar, is when we know we are dealing with a benign process. But what, what happens when we have a malicious process? So, the same process happens, we have this malicious process, we profile it, eh, we create the actual profile, feed it into the autoencoder, the autoencoder is gonna create his own
34:03
reconstruction of the profile, and it's gonna realize that the sequence and the autoencoder is very high, and that way is easy for us via machine learning to detect that there is an anomaly inside the device. Eh, that's eh, pretty simple step one. Second
34:22
approach guys, let's say that we have a, an exploit going on, right? Eh, in the left side, you can see an application running, and the list of all the syscalls going on there. So, you are gonna see always the way it executes. But what happen if suddenly that application is compromised? So, if you, if you see in the right side, eh, eh, at the end, in
34:43
the, in the red, eh, eh, bot, in the red square, eh, you will see that comparing the two applications, the benign one without being exploited is gonna exit the program, but when you look at the second one, it's gonna call exec b. Why exec b? Obviously because it's getting in a shell. So, in this case, we don't need, we don't really
35:02
need machine learning to realize that the flow has been affected, right? We call it sequence based, people call it control flow, same as I, S H I T. So, at the end of the day, eh, you just need to measure the sequence based and realize if there is any alteration. And in this case, one exit properly, and the second one called exec b. So, it, it's easy
35:25
to detect. Eh, now let's talk about the delay. Eh, you, if you guys are familiar with antivirus and eh, and sandboxes, right? Eh, one of the techniques of, of, of the APTs, for example, is to delay execution, so that it executes and then it's gonna wait for
35:41
execution so that an antivirus needs to take a decision in milliseconds to know if it is malicious or not, right? It doesn't, it cannot be a scan in the process all the time. So, by delaying the execution, those engines are gonna give up and they are gonna stop monitoring it, and that's a way to bypass it. So, that scenario is a pain always in
36:02
the, in, in, in the enterprise with antivirus. In our case, it's the same issue, but how we tackle it, eh, comparing with them. So, in our case, for example, we have this pretty simple delay in arm, eh, eh, and it's just a simple loop that is gonna, you know, delay execution for 8 seconds, 8 minutes, and then after that, it's gonna trigger
36:22
the shell. If you remember the previous slide, eh, in that one, we have all the execution at, at the end, we have the exec B to be called. In this case, what happened is that the exec B is, is never gonna be called, and therefore, we're not gonna see any anomaly. So, that's a pretty, pretty challenging, challenge that people have. So, what
36:40
the people does, for example, in the sandboxes, they hook all this sleep or nanosleep or those syscalls, and once they see this syscall triggering, let's say that in, there is an asleep for 5 minutes, they will change at runtime the 5 minutes to zero, so that they force the malware to execute, right? That's one technique, but that is a cat and mouse game because today is asleep, tomorrow is nanosleep, and there's gonna be
37:03
multiple techniques all the time, so you need to keep updating these techniques so that anytime there is new way to bypass it, you need to update it. Uh, in this case, for example, we don't even use an asleep, eh, we don't use a syscall, so in this case, it's just a code that's gonna delay execution, so you don't, you cannot rely on hooking
37:21
syscalls. So, eh, this a, a challenge for everyone. In our case, eh, we tackle it in a different way, eh, one way is you don't wanna, eh, monitor these executions all the time, right? We were talking about wearing a car, we don't wanna delay execution, can you imagine the GPS just slowing down or any application in the car, so we need to
37:43
be safe quickly, but if this application is running and it's sleeping, we cannot wait forever, so we have a way to tag the process so that when the process start running, suddenly goes to sleep, we stop executing and then we monitor it in a way that, eh, we cannot, eh, know when the, the malware wakes up. Eh, there is a way to do it via
38:03
profile based, eh, approach that Ali's gonna explain in a second, but from BMI perspective, eh, same challenge, but we don't wanna follow the syscall implementation in order to understand when there is a delay. In our case, we tag it, the process, we just, you are sleeping, we sleep, we don't do any performance issue, but as soon as you wake
38:23
up, we wake up. So that's a profile based, eh, policy that we're gonna explain in a second. Now, Ali was explaining us that his technique, right, eh, sorry, the technique that he was explaining to hook into the memory, so he was telling us that, you know, you need to put a D4-0003 as an MC hook, right? So that's pretty cool, eh, eh, but it's
38:44
pretty easy to bypass, so I, I mean, eh, if I have a kernel module, I can just go to the syscall, grab the first 4 bytes, and then get the, the, the, the SMC there, and for me as a malware, I'm gonna be able to detect right away that I'm being monitored, right? Eh, at that moment, I'm gonna say, you know what man, I have this
39:02
SMB hook, I'm being monitored, so I'm not gonna execute anything, I wanna wipe the system, or even worse, I can override, if, if the memory, eh, the page allow me, I can override that SMC hook to the, to put it in the, in the original state, and then I can just totally bypass the hooks in the system, and then this whole technique being
39:21
shown by Ali is totally screwed, because it's pretty easy to identify, so I don't know how come Ali come up with this technique, but anyways. Okay, so, let me think how we can, eh, answer Dan. So, you remember the views, right? And I keep saying the views are very powerful, so here's another use case, and we'll, we'll see
39:44
how we can, eh, answer Dan's question. Uhm, in this case, what we are doing is, again, we are creating, eh, you know, two views. Actually, you know, you don't need to create, eh, eh, the whole, the whole memory pages, what, what we are essentially doing is, we are,
40:00
eh, assigning different permissions to different, eh, EPTs. So, we have two EPTs, eh, one is going to be the execute only, the other is going to be the read write only. Now, what will happen? So, let's say, by default, we are in the execute only view, right? And the malware comes and tries to read the hooks that we have placed in the memory. Uhm,
40:25
since the page is execute only, there will be an exception, the control will be transferred to me, and I will see that the malware is trying to be smart, so what I will do is, I will switch the view, eh, which is the clean view, by the way, there is no hooks, hook, hook in, eh, in this view, so that's the, that's the trick. So, I have this view where
40:45
there's no hook. I'll, I'll switch the view, I'll let the malware read the memory pages in this view, and then its, eh, read request will be satisfied, the malware will not know, you know, that there are any hooks or it's being monitored. So, that's how, and then once
41:01
the, the, that read request is done, eh, we'll switch back to the execute view. So, you saw the previous application where, you know, we created these views, eh, to do the single stepping. Now you saw another one where, you know, we use the same capability that, you know, the Intel and the ARM provides to, uh, bypass, uh, or trying, you know,
41:26
malware detecting us, uh, we bypass that. Okay guys, so let's see another, uh, other examples, eh, eh, in this case, we have an anti-VMM, you know, hypervisors are known to be virtual machine monitors is another name. So, what we have here is, eh, I'm, again, I'm
41:44
a malware, right? So, I wanna know if I'm being monitored, if I'm in, I'm, I'm being monitored, so I'm gonna stop executing. So, in this case, eh, since we're switching views, as we explain, that has a cost, has a time in, in terms of performance. So, what a malware can do, uh, and we do, we just do a proof of concept here is, we measure as a baseline
42:04
without, without having the page views switching, we just measure the time. In this case it's 38 nanoseconds, and then once we do that, we now measure the time that it takes to write into the memory. And you will see in that red, eh, color, eh, that the time is highly significant, so that you will realize that, eh, the time to write into memory
42:24
is totally different to the baseline, and this is another technique that we can use to detect that we are being monitored. Just by measuring the time that it takes to write into memory, we can realize it's taking too much time to the baseline, and, and, and this is another way to, to find, eh, ways to bypass, eh, to understand that we are
42:42
being monitored. Now, eh, let's talk about process killing guys. So, when we, when we kill a process, right? Eh, we all know how it works, right? Eh, eh, eh, if you wanna implement it on, on code, you will just need to call the syscall kill, and you pass the PID and the way you wanna kill it, right? That's 90 if you wanna force it, so that's
43:02
the way it works normally in a user mode scenario, and we all know. But, what happened here is, eh, what happened if we wanna implement a simple killing process in VMI? Keep in mind that we don't have any agent inside, so, people or other companies, eh, what they do is they just drop an agent inside, they call kill in the
43:21
user mode, and then you just kill the process. But, in our case guys, we don't have a, an agent inside, and, and we don't wanna have an agent inside, we wanna keep being out of the box. So, how a simple kill process can be done from VMI? So, we have a way to do it here, eh, it doesn't need to be the perfect solution, but the idea here is that
43:41
you guys can see the challenge when you wanna just kill a simple process that is very easy to do, but from the hypervisor. So, what we do is, let's say that we wanna kill the process ID 300. So, what we do is in the kernel, because this whole VMI guys is being executed in the kernel, we are not using user mode syscalls, because it's too high, too consuming, it's a lot of performance issues, so we are just hooking in the
44:03
kernel. So, when this 300 process is running, what we are gonna do from VMI is we're, we're gonna monitor all the syscalls. So, when the syscalls come in from that process, what we're gonna do is we're gonna mess with the stack. That, eh, information that you see in the green is the full stack dumped from a, from a, from a one
44:22
syscall. So, what we do is, you know, there is something that, that is called, eh, safe user state registers. So, when you transfer from user mode to kernel mode, those registers in user mode are stored in the kernel, so that when the kernel resumes execution in user mode, those registers are used again, right? So, what we do in
44:41
kernel is that we get that stack content, we get those same registers, which are not being used by the kernel, and we just nullify them. What, what's gonna happen guys is that when the syscalls come back into the user mode, since those registers are totally nullified, it's gonna cause an exception and it's gonna exit the process. As you can
45:00
see, it's totally a different way, it's, it's not a traditional one, but taking advantage of VMI, we are able to mess up with the stack and then force the process to kill. Important to mention that, eh, it's not easy to do because, eh, in this example you see the yellow box, eh, if you mess with any kernel related information,
45:22
which is in the lower addresses, you're gonna get a crash in the, in the device. So, you wanna make sure that you are really, eh, overriding only, eh, the user mode, eh, register information. So, we learn that from experience and then we come up with this specific offset that is calculated dynamically so that we always overwrite only, eh, user
45:43
mode registers, eh, and the way it works guys is that every time we get a, we set to the, to the device a kill PID 300, it's gonna grab all the syscalls, every time we grab it, it's gonna mess up with the stack, sometimes in the first syscall it, it, it, it get the exception and kills it, some, sometimes in the second and the third one, so,
46:03
sometimes, it, it, it, sometimes it needs to take like 5 or 7 syscalls to be called in order to, in order to be killed. But this simple example guys, as I said, eh, is totally different beast as you can see. It's not, it's not easy to do it at, at the BMI if you wanna be totally aimless. So, let's see, eh, a quick example of, of, of, eh, how we
46:22
kill it, eh, in, in, in, in the device. So, here we have our, our, eh, system, so
46:42
what we're gonna do guys, guys is in the upper left, eh, we're gonna run, eh, simple, eh, malware like Mirai, which is very, eh, very common one. In the upper right, we have our inspector monitoring it, here is the Mirai, we're gonna execute it. As soon as we execute it, Mirai delays itself and it's found a busy box process, eh, pretending to
47:02
be normal, eh, and it is in the 336 PID. So, let's go back to the virtual machine that we're monitoring, we search for that process, 336, and we can see that it is there running, right? 336 is there, we click it on it, and then we can see that the busy box is, is showing up, right? There is busy box. Now, let's try to kill it from BMI. So,
47:20
we go to our, eh, front end, we go and try to find the 336 process, we find it there, and then we click on kill bottom. That's gonna be from BMI sending a, a, a signal to kill it, so then we go back to the BM and search for the Mirai, which is gone already, you know, it disappeared as, as we said, and now let's search for the 336, and you can see that it's totally, eh, killed. Eh, this, eh, is totally, eh, eh, clean,
47:45
we don't crash the system, and this way to do it, which is not the best way, eh, eh, it works for us, eh, eh, and that way we are able to kill from BMI perspective. Okay, okay, so, so, uh, just wanna quickly mention that, you know, once you get hold
48:11
of BMI, you understand it, eh, it's pretty cool, and you can do a lot of other things, eh, eh, with it, eh, it's very powerful. So, eh, one of the things that we did additional, in addition to detection is the policy. So, not only, eh, you can do the
48:25
detection with BMI, but you can also implement policies, again, not putting anything inside the operating system and still maintain these policies. One of the example that I wanna quickly share with you is, eh, a lot of, eh, infotainment or any IoT device, for example, medical device, there are certain processes very limited,
48:42
which are responsible for going out to the internet. So, what you can do is, you can, you know, the task list that I showed you, you can continuously monitor that from the outside, and, and, you know, since socket is a special file, you can just simply see if there is another, eh, socket being opened. That might be slow because you're actively traversing, eh, eh, alternately what you can do is you can hook a connect or a, eh, eh,
49:04
network API, and then, you know, when that API gets called, you will see if this process is allowed to communicate outside or not. So, here's, you know, just a quick, eh, view of, eh, how it, eh, it looks like in our system. Eh, like Dan was mentioning, eh, remediation is another, eh, topic that we are tackling aspect. Once we detect
49:24
something we need to kill, it's not easy to kill from outside, we always have that option to put an agent inside, but we don't wanna do that, we wanna be totally out of the box. So, you wanna try, I mean, the method that we showed you is not one of the, I mean, we, we figured that out on our own, but we, we have another one, you know, that,
49:42
that, that we are exploring right now, so you can try different things, you can make the parameters null and try, try some of those things. Quickly wanna share some of the recommendations with you guys for an end-to-end system. Let's say you're working with some other hypervisor, like in our case, you know, Zen is just the start, we are already working with some, you know, another hypervisor, eh, and that's a custom one. So,
50:03
you really need to have good way of putting the breakpoints, efficient single stepping mechanism, uh, the event mechanism. Now, we didn't talk too much about event mechanism because Zen provides a really good event mechanism, but if you're working with some other hypervisor, you wanna make sure, you know, you have a good event mechanism. Anything that you translate using those page, page, page, page tables, or the
50:23
page walk, uh, you know, you wanna make sure, uh, you cache those in an efficient hash tables. Uh, multiple views is awesome, as you can see, I mean, we have few other use cases which are patent pending, we cannot talk about it, uh, we combine the views, uh, in, you know, with other techniques, uh, to really really improve the performance, and VMI, in VMI monitoring system performance is the key, and finally the
50:44
permission management. Uh, finally guys, we are releasing some, uh, tools, uh, for you guys to play with, um, you can see the, the drop box, you can go and check them out, so we have the ARM and Intel VMI monitoring tools that, you know, you can play with,
51:01
um, uh, we have all the files that we have used to, you know, uh, boot up the Xilinx board, and finally we have the, uh, one malware, ARM 64 based malware that you can use to do an end to end scenario, so do check that out and, and, uh, you know, play with it. Uh, okay, so finally the, the takeaways, uh, in today's world of advanced malware, we
51:23
really need to make sure, you know, we make the hypervisor smart, hypervisor is everywhere, so, you know, you wanna make sure, you know, you, you make it smart, and, uh, you know, agentless is the way to go, because we know that, you know, anytime you have an agent inside, it's, it's, uh, it's a losing game. ARM syscall monitoring is
51:41
obviously, was a great achievement for us, but it's just a start, I mean, we, there's, uh, now there's a lot we can do, so don't just stop at the, you know, syscall monitoring, you know, think of new use cases, and, you know, especially switching between views is very powerful, so you can also think of new use cases around that. And finally, performance is the key, we have a patent pending Newman adaptive, uh, monitoring, and then we,
52:04
we, we use that, uh, uh, in our system, we're gonna talk about it right now, we need another talk for that. Okay, finally, I really wanna thank, um, uh, Sake, Matt, Stefano, Waleed, I don't know if you guys are here, uh, but still, uh, these guys
52:20
really helped us along, uh, uh, our journey, and, um, it wouldn't have been possible what we've achieved without these guys, so thank you guys, thank you.