>>  Hello.  Thank you for coming to our talk extreme privileges escalation on Windows 8 UEFI symptoms.
(Applause).
>>  We're from the Mitre corporation.  A federally funded research center let's continue.  Here's outline for today.  We'll talk about the agony of ring three, yes you have a minister of command in Windows 8.  New lands we can explore, more extreme places we'll go.  We'll be talking about how we can get to these other areas, what we can do there, we'll be talking about exploits we used to break into these areas from Windows 8.  We'll be talking about some agents into these extreme areas to do our bidding and then finally we'll offer how you can detect if someone is attacking you at the EFI level.  Windows 8 normally most researchers would be saying awesome I've won.  Give me my money and then that's it.  Presentation is over but there's still limits to ring three.  There's things you can't do that as an administrator there's things you can't do.  At as attackers we want more power, more persistence, more stealth and there are limits to what you can do in ring three even as an administrator so we must escape beyond ring three into other lands that are completely unbounded and modest to everything.  Now that was my introduction.  Some of are you wondering should I have stood in line for this talk.  Definitely you should have come to this talk.  You don't have to take it from me.  Take it from the authority figure.  He said if you can re-flash the firmware that is so awesome that would buy again that's exactly what we're going to do in our presentation.  This presentation you definitely what to be here for this talk.  Now, so, generally what we're talking about here is post exploitation privilege escalation, like I said generally once you have the administrator command from Windows 8 or whatever you're in the post exploitation phase.  There are other places you might want to go to and secure the boundaries in the way to get into those other areas.  The windows kernel, later versions of windows you can't inject arbitrary code into the kernel because there's the Authenticode, there's driver signing, only signed drivers can get into the kernel.  There are ‑‑ technically that's case.  There are some attacks against this where you can put arbitrary code into the kernel.  This attack model has been explored by other researchers as well.  They talk about loading a known loadable design driver.  This has been hashed out.  We don't want to talk more about this.  We want to explore extreme possibilities.  Here a few other options what we can do in the post exploitation phase.  We can go from admin ring three to boot kick the system.  We can go from ring to zero onto the platform firmware or jump into system management mode.  Unfortunately we live in a dark world today where we could do any of these things at least not trivially.  We can't just boot to the system because it will prevent from us doing.  We can't write to the firmware because firmware only accepts signed updates because there are flash protective mechanisms.  And you can't get into the system management mode because not even ring zero can even read system management mode, it's protected by the memory controller hub basically.  Now luckily for you you're coming to this talk and we'll introduce the idea of extreme escalation which lets us go from administrator to ring three to platform firmware.  The important thing is on this diagram these privileges commands are ordered from on the Y axis.  The higher you go the more privileged you are.  Anything more higher up than this diagram.  There's a platform firmware, if you can boot the system you get into ring zero and so forth.  You can always snake your way down this diagram.  Once you get to the platform firmware you're free to take out all these other privileged admins.  Yeah.  What I just said.  All right so it's a Windows 8 system.  Most Windows 8 systems today most all will chip with UEFI firmware which is the replacement for conventional BIOS.  Almost guaranteed you have UEFI running underneath the system happening you turn on your computer so forth and so son.  Now this is the obligatory UEFI diagram and essentially all you have to know about BIOS in the firmware is its job is to turn on the computer and initialize it find the operating system and transfer it to the operating system.  Turn on the computer find the OS transfer.  Transfer control to the OS.  The other important thing about this diagram is that it's advantagous for us to break it to the processor as early as possible because as the boot up proceeds the system becomes more and more locked down.  There's more and more locks placed on the chip set, less things you can do.  The earlier we can break up into the boot of the system the better.  The system will be in an unlocked state and we can do whatever we want if we can get in early enough. By the time the OS gets control the device is the firmware is like very locked down and there's really not a lot you can do even from ring zero:  
Now, Windows 8 has introduced a new special API called set firmware environment variable which lets you set, well, exactly what it says, firmware environment variables.  Think about these as Unix, Linux type environment variables. UEFI is the same thing,  generally they look like the platform language, the boot order and lots of other crazy things with all kinds of crazy environment variables in there firmware.  Windows 8 introduce an API that allows a privilege so admin ring free process to interact with these firmware variables.  So essentially what this looks like is Windows 8 can call this API this set a variable to whatever and many of these variables will be automatically parsed by the UEFI firmware now I went about thinking about I wants to audit UEFI, immediately when I saw this environment variable API & UEFI variables I started to thinking about this is like a lot like Linux environment variable vulnerabilities back in the early 2000's.  Back in the day you could do like set term equals a million A and then call some privilege application X term or something like that is that it would try to parse one of those environment variables and it would miss parse it and there would be a buffer overflow.  It was like privilege escalation in Linux, that's exactly the methodology I had in mind when I started looking at these UEFI variables.  There's lots of these variables and some have complex contents like points, likes of arithmetic on the integers.  This is the type of thing where memory corruption vulnerability occurs.  I want to target this as an attacker. We have already found some vulnerabilities in this variable interface we thought the computer was a set variable there we could discover the intel that allowed bypassing of secure boot but to be frank this vulnerability is probably like a five out of ten on the awesome scale that I attribute in the beginning because it only lets you bipass secure boot, you couldn't re-flash the firmware, you could break the firmware and it only affected a number of a like a subset of UEFI symptoms.  Because it basically came down a weird implimentation that some of these OM's were using.  Five out of ten is kind of cool but we can do better.  This is the BIOS to development system.  We have UEFI and intel provides an open source UEFI references location that's like open source code for how you should program UEFI firmware.  You have these independent BIOS entities like ‑‑ oops running out of power.  So, we have these IBV's you probably heard their names they make BIOs and sell them to Dell and HP for them to use on their own personal systems.  Theoretically American Megatrends Phoenix will use the code and sell or license that development kit to Dell and HP and they'll use those development kits to write their own firmware for their own systems they ship and sell to you.  All right.  So, the point is if I can find a vulnerability in the UEFI open source it will trickle down into all these others that affects all these other Windows 8 systems that are using UEFI.  Okay.  So, UEFI like I said it's open source so it's relatively simple.  Check out the code and then go to town.  Now as attackers we want to zero in okay I'm sorting out this code, where are the boundaries between this more privileged piece of code with attacker control data.  One of the intersections is the UEFI variables.  We know that many of these are controlled while the operating systems by the operating some it's an attacker controlled data and the firmware will parse many when they're created.  Now, also last year at Black Hat we presented a Dell BIOS update routine where normally you can only update Dell with signed BIOs but we found memory corruption vulnerability in the update routine and we re-flashed the Dell computer to an arbitrary malicious BIOS image.  So, we had this experience and it just so happened that UEFI outlined a uniform capsule update mechanism updating UEFI firmware.  This is not directly culpable or so there's no interface accessible to ring three code that says start capsule update.  This UEFI variable existed, UEFI would automatically start the capsule process.  Even though it's not directly exposed it's inadvertently exposed.  What that means is that we had a very good intersection between what we wanted to look at UEFI variables and this is what we have past experience with on our updates.  Capsule update that's good, this is a first good target to attacking UEFI.  So, this is basically how capsule update worked.  You would have a firmware capsule that contains things like a BIOS update.  You can do other things but for the sake of discussion let's say BIOS update.  Operating system will take this capsule right at the memory in case ram is constrained and it will like scatter right to the address space.  Then the operating system creates a special UEFI variable called capsule feed data it's a scatter data list which lynx to the location of all these individual fragments for the capsule in memory.  Now, whenever UEFI gains control it's going to automatically look for the existence of this capsule update variable.  It will go about trying to coalesce this fragmented capsule there was in the address space back into its original form.  So, once it has the UEFI or the capsule coalesce it's going to pour some of its envelopes that are encapsulating the update and verify that it has been signed by the OEM because you don't want to have the firmware just parsing unsigned capsule.  It has to make sure it's originating from the OEM, this is OEM code.  You better verify that capsule as it's coming in.  Once the verification passes assuming it does it will consume the actual contents of the capsule so presumably firmware update but there's also been proposals for running like malware detection independent of the OS its a general capability but in general you'll see it for firmware updates.  All right.  So, with that in mind we knew what are opportunities for actually exploiting this capsule update process.  We know the vulnerabilities have to occur before the pictographic verification.  UEFI will will not proceed, do not pass go do not collect $200.  Vulnerability has to occur before that.  Company we will lessing happens before that.  The parsing, the capsule envelopes, many of the envelopes parsed by UEFI before the signature actually occurred so it has to parse these envelopes to facilitate the signature checking process so vulnerabilities in these envelopes could be used to highjack control of the exploiter in the contents of UEFI.  The third and final option was parsing within a capsule.  This is where the first BIOS vulnerability was found.  In 2009 lapsed from the BIOS re-flash attack that revolved around the unsigned splash screen on your system so with this intel BIOS you could update your splash screen and have your company logo, whatever company you're working for be displayed.  This was unsigned content embedded by the BIOS update.  There were vulnerabilities in the parsing of that unsigned splash screen that allowed them to get control.  These are three main attack vectors, the coalescing, parsing of the envelopes, and parsing unsigned copy within the capsule.  Okay.  So, UEFI code and guess what you're here today so we found lots of bugs obviously.  The bugs took the form of do not do this 101, so like arithmetic before sanity checks and multiplication before allocation.  If you're a veteran you know definitely do not do this.  If you're a veteran bug hunter, you would have zeroed in on these things and you would say I think this is problematic like in this case bug number three, that block is really large.  The multiplication will overflow and it will be unexpected small so these are actually quite obvious like I said veterans will know that.  Yeah, I could have spotted these things easily.  We found a number of bugs.  We were able to chain several together to come up with two different exploits.  Because we're nerds we like chess so we named our chess exploits.  .  While the platform is completely unlocked the and queen's gamut, the king's gamut it's known as a Dixie phase.  Using both of these exploits we were able to get control of the point the in the UEFI done nasty things and break into things that normally ring three codes could not break into.  When I was auditing this code, like I said many of the vulnerabilities are easy to spot.  The developers were aware that there were possible ‑‑ possibly like bad things that that could be occurring.  This says more liabilities, check out, will do later and so forth and so on.  Whatever.  Obviously there was an issue and they didn't bother to fix them.  The presence of these really easy to find vulnerabilities and security critical code that is open source was disturbing to me and we're forced to conclude guess what no one else is looking at the BIOS.  Otherwise you would have found these vulnerabilities years ago or maybe you found them.  But ‑‑ yeah, so other good, you know ‑‑ researchers aren't coming up here and like reporting these bugs or whatever.  So, yeah, okay, these bugs are easy to spot.  Kind of weird.  Interesting observation.  Now, the bugs are easy to spot.  Exploitation was very complicated.  This is despite the fact that code I just showed you runs in an environment that is completely exploit mitigationless.  It runs in protective mode and that means all code is readable, writable, executable, everything is predictable locations, so modern mitigation whatsoever.  Critical but no mitigations.  Despite all this, exploitation was so brutal it took me months and months to actually accomplish even though it only took me a week to find the bugs.  So, at this point in previous presentations I've gone line by line, memory map, blah blah, this is how I did X, Y and Z to exploit the vulnerability.  After five minutes of doing that the audience was asleep.  I'm going to show you this crazy diagram and say if you're a fellow vulnerability researcher exploit developer please read my white paper I spent many days writing a white paper that goes into all the gory details on how I exploited these vulnerabilities.  This is to entice you to read the white paper if you like that sort of thing.  Point being the queen's gamut exploit we achieved a very reliable searchable write primitive which is the holy grail in development.  King's gamut vulnerability was especially interesting the weren't we call the Dixie phase because essentially you end up in a situation where there's a nonterminating loop that's going to overwrite the whole four giga bite address space.  You're covering the address space with values.  You don't need complete control.  How can we escape?  The only way I think to exploit this was have a nonterminating loop overwrite its own code as it was executing.  In this case we wrote a crazy Python encrypted source root and in one of those instance I found a case where I can make it so that the self over the nonterminating loop self override itself with a jump away to a noncorrupted part of the address space that the OS could control and we could have privilege escalation.  This isn't as good as the other one because it corrupts a lot of the space and destabilizes the system and pretty much what you can do after you gain control but it's still kind of interesting so please read the white paper if you're interested in the details.  Now, what else is interesting is that we're able to exploit the queen's gamut vulnerability using only that special Windows 8 UEFI variable.  Part of the exploitation process required me to stage certain things to certain physical addresses with an address space.  Normally in ring three you can't do this.  You won't have access to all of the physical address space you want but I found that by further abusing the Windows 8 UEFI API I could spray the contents of the flash chip and just create many of the these variables and I created.  .  I was able to exploit the first vulnerability that queen's gamut exploited using the Windows 8 UAPI so I didn't have to rely on anything else.  The second one there were some constraints and we had to use a crutch of a third party driver to put things in certain physical addresses, so.  In both cases it was completely unlocked.  System management mode, the flash et cetera so you can do whatever.  So, okay, it was totally crazy.  Some of you guys are like I don't understand this after all.  Let me sort of narrate it step by step this is what it would look like.  We have our dark Jedi.  No for the dark Jedi that is never enough.  He grows his power to the next level he says okay that's great I'm admin but I must go further, must explore other dimensions, get more knowledge, get more power.  So first he says I'm going to spray the contents of the flash chip with all these UEFI variables that is contain shell code and a evil capsule to substantiate the vulnerabilities.  He will have a tactical control data that physical address FFF911000 and he needs that.  Then after he's finished his spray variable type thing he creates the evil capsule update data variable that substantiates that standard capsule of data process in UEFI if it exists and he points that within his sprayed area basically the evil scatter gather list to substantiate the vulnerabilities and this is what ‑‑ platform reset occurs.  This actually is a bit implementation specific anded depends on what hardware you're running on.  In most cases this is got a name like F3 sleep but it can mean other things depending on your hardware.  Once a platform occurs UEFI will regain control, you'll be executing the contents of UEFI.  It will check for the existence of scatter type data and if it exists it will start parse the contents of the list and try to coalesce the capsule and so on.  In this case the evil scatter gather list capsule updated.  Point inside the contents of the sprayed data that our more evil dark Jedi pushed onto the flash chip and in the process of parsing because of those vulnerabilities that I pointed out the attacker gets control of the construction pointer in the context of UEFI.  Since there's no mitigation no execute stack or whatever the attacker can hit instruction point back to the contents of one of the sprayed variables which contains some shell code to do something.  In most cases it will be something like copy yourself in the system admin mode or re-flash the flash chip which normally you can't do but in this case the flash chip is unlocked so you need to override the contents of the flash chip; inject some type of agent into the virus or the firmware.  No physical presence needed.  So, what can they do?  Why would the attacker be incentivized to do these.  Once you're in the platform firmware you can completely break the system by overriding the flash chip so not even ‑‑ it won't even power on.  It can defeat secure boot.  It can establish an undetectable SM root kit.  Or we also gave a talk at Black Hat about further developing a undetectable.  It can insert hyper visor and it can interfere with the hyper visor.  You don't have an SM transfer monitor.  You probably don't anyway.  And then yeah once you're in you can do anything, anything a CPU you can do at this point.  There are no constraints to your power.  All right.  So, normally does anyone like to do video demos,  because demos are safer.  It might not work.  Fifty‑50.  So, 50‑50.  We're doing one of these development boards and these boards are kind of like finicky.  Windows is not designed to run on it.  We hack Windows 8 to run on it so we could exploit the underlying UEFI code.  It may work.  He's like the God, the gatekeeper between the spirit world.  We'll call on him.  Hear my call.  Make our demo work.  So, let's give it a go.  It's like variable grade zero, variable grade one.  This contains the castle as well as the shell code.  He gets the controlled data in a physical address.  You see an error and that's because the flash chip burns out.  Corey is going to work with what you got and it creates the evil capsule update variable to point and sign the contents of this sprayed flash variables.  Go ahead.  Okay.  So one other thing I would like to say is that we're going have to link to the UEFI shell because Windows 8 doesn't know how to  put these systems into S3 sleep.  Normally you can put the platform into S3 sleep but there aren't the right drivers so we'll boot to the UEFI shell to put in it S3 sleep to actually engage the vulnerability.
>>  (Inaudible).
>>  Bouncing on the projector.
>>  Give us just one second.  Okay, so this is the EFI shell over a serial terminal here and Xeno put it ‑‑ okay.  So, we're going to call something that is basically going to tell us is the exploit going to work or not or at least give us some evidence.  You see the spray location FF940C2.  That's great.  I assume this to be a reliable address so everything seems to be great so far.  Here is another place where the demo can go wrong.  We'll try to put the minute board in S3 sleep.  Even from the shell sometimes this is finicky.  Sometimes will it not go into S3 sleep.  Takes sometimes 30 seconds.  Let's all sit here and hopefully the God will be merciful to us.  Otherwise we'll have to reset the system.  Okay.  So, right, if the system boots up if the demo works it will take the shell code and what we'll be doing is making writes to the flash kit that will embed the agent in the system management mode to do our bidding.  It's like a back door methodology that Xeno will talk more about what it's supposed to do and how it works but we'll see.  Okay, so s it wasn't going into S3 sleep.  Luckily the exploit is still waiting there in the variable contents for UEFI to parse and then if we can get it to go into S3 sleep.  If it works you'll see it say something like running from spy flash.  That's how we know it's running from S3 sleep.  There we go.  Finally.  Okay so at this point it has gone into S3 sleep and woke up with an immediate wake and it started to parse our evil capsule.  At this point we've been corrupting the firmware on the flash trip which we're definitely not supposed to do.  Xeno will hook up this programmer just to show you the writes me made to the flash chip.  Normally you can't do this.  Normally to inspect a flash chip you need this special E prompt program.  If you have physical access, yes, you could overwrite the flash chip.  You could connect something like this to it.  The important thing is we're actually making them out of chips so we can do this without ever having physical access to the system.  Xeno is going to the point where we would have inventeded the agent at this point.  Yeah, so you can see where it turned red.  We identified a pattern area on the flash chip for this development board.  We just inject one of our agent that is will copy itself into the system management mode.  That 's one of our writes.  Everyone should be impressed.  Normally you can't do that.
(Applause). 
>>>  So, everyone total unimpressed.  You clapped because I told you to.  Okay so now I'll secure everything.  All right.  So,.
>>  We just showed that we injected an agent into the flash chip.  That's first.  It's going to always exist down at the flash level its going to run every time you boot the system and it can, you know, do sort of anything.  So, looks like we lost a slide here.  But basically the point is we get ‑‑ we get asked the question consequences, what does it matter if you break into BIOS, who cares if people attack firmware, right?  And so the basic point is we always say okay, what can an attacker do?  They can do everything, every single thing.  If there's an attack they can do it because this is the most privileged code on the system.  There's nothing it can't do.  And it turns out it also is down there at the lowest we feel running before all operating systems so you can boot my Linux here, so we just did the exploit from Windows.  We're now going to boot it into Linux instead because we want to show this agent down at the firmware level is persisting and running and continuing down below the system and it doesn't really care who actually is up there at the operating system.  So, what is the watcher?  It's an agent which is sort of minimally simple.  It's like the simplest possible thing you could make if you wanted to make the back door but it's maximally capable because all it does is it scans memory and it tries to find special signatures and memory.  When it finds a signature in memory it treats after the signature ‑‑ what's after the signature as assembly that it should run.  It just jumps into that assembly that's after the signature.  And that means we don't need to build in every capable in the world into the watcher.  We have to have it continuously waiting and watching and scanning your memory.  It doesn't care how an upload gets into your memory, use your imagination, someone shoots some packets at you and your thing says no, I have my firewall on I'm going to drop those packets and not process them.  It doesn't matter.  It has got into the memory and the watcher is waiting for memory and looking for signatures.  Whole bunch of different ways.  Maximally flexible because anything that gets into the memory any way the watcher can find it, watcher can execute it.  I'll just speak a little bit about what we did in terms of design trade‑offs.  So it's scanning memory.  You don't want to scan all of memory.  That's going the take too long.  We want to scan on page boundaries every x1 thousand of memories so watcher is sitting here running in the background scanning for magic signatures.  The controller somehow positioned data into your memory.  It doesn't matter how.  You opened a document that had something attached.  Some java script sprayed some pay load into your memory.  Somehow some way the controller gets content into your memory and then the watcher comes along and finds it and starts executing an arbitrary pay load that can do anything.  So, we will show some simple ‑‑ watcher ‑‑ an important point is the watcher is pretty much an after thought to this presentation.  Corey's attacks on the UEFI.  The watcher was ‑‑ people don't get it that when we say if you break into firmware you win everything, okay.  So, we needed to make it clear because some people only get it when you make it, you know, perfectly clear.  So, to show simple demo, we're into comic books, the watcher is from an alien race which is forbidden to interfere but he always finds a justification to interfere anyway to warn us about attackers and so forth.  But so in this case what we're ‑‑ you can see here we booted into Linux, that's the Linux that comes with the board and so to sort of prove that the watcher is sitting here waiting and watching in the background I'm going to manually invoke a system management interrupt.  We can have it running continuously on the background we ran out of time for doing demos.  Like I said it's an after thought.  We'll manually invoke an SMI and we'll prove that there is someone hidden in the background who is actually executing code.  Right.  And the key point is like we're still on the same system.  We booted into Linux.  This is still the same development system we were booting, hard drive with Windows, flash chip with Linux, same system.  The watcher  is sitting there underneath.  It can subvert any operating system, any hyper visor, it really doesn't care.  So, what I'm going to do is I'm going to make a little EFI art.  This is a Linux application.  It writes to a port that causes system management interrupt and it picks up the watcher and it says watcher go scan memory right now.  If I pass argument eight I'm waking up the watcher and he's not finding anything, I'm not creating magic signatures from the find but if I do IO9 then what I will see is he will find this pay load and he will execute my code if you want.  There we go.  The watcher has infected the system and he's waiting and he's watching and he's executing thing.  The watcher itself printed out watcher go into forbidden, maybe just this once.
(Applause).
>>>  The pay load for this particular example again just to make it blindingly clear, the pay load for this, it could do any sort of shell code I want.  The watcher passed it the address of a print function and so the little bit of assembly all it did was it took in, you know, patched the argument into the print function and then past the pointer to the string and then the string prints it out.  That's an example of the watcher sitting waiting around watching and executing thing.  Now we'll try our 50‑50 probability maybe it will work maybe it won't thing.  It doesn't make it matter how stuff gets in your memory.  Here I just ran an application.  The application you know, create add special buffer with a special signature and then some assembly after the signature to execute I'm going to now try and I'm going to try to send some ping packets that have watcher signatures and watcher shell code in and specifically the ping packets I'm going to send, let's talk about the pay load here, the pay load we want to use is the ultimate nullifier.  Going with the comic book reference, this is the Fantasy 4 comic books, the ultimate nullifier was a device that was extremely powerful.  It could destroy universes and destroys the user as well.  It's kind of the weapon of last resort.  The ultimate nullifier in our world is a break the system sort of pay load.  I'll nullify the first instruction that the CPU ever pulls out of the flash chip and that means that the first instruction is junk.  Then you can't boot the system.  You can't reboot the system into some USB drive and reimage the system.  The first instruction the CPU ever executes is garbage.  It's going to not boot ever again unless you have, you know ‑‑ unless you can go physically attach a flash chip rewriter.  That's again part of the reason why we're using this demo board is because we can easily reflash it, fix things working on demos and so forth.  You can't easily refix things on your personal laptops.  So, ultimate nullifier sent over to the network in ping packet maybe lit work, maybe it won't.  We've been seeing that the networks back here is not so great but Corey, if you...
>>  Okay.  So, I just want to re‑emphasize.  One thing we're having to do, like the IO8, IO9 normally we could program the watcher to be executing in the background by causing the clip to, we don't have time to implement that.  Any time Xeno does the IO8, IO9 we have to make it more weaponized.
>>  Putting up a little local network and then Xeno will have his Mac book.  I'll sends a ping packet through the development board.  Embedded in the packet will be a pay load for the watcher and that pay load for the watcher will be break the system.  The idea here is that some other foreign entity state has broken into all of your computers and installed this watcher.  When hostility break out country break all your systems right before you, launch an attack on you because I want to set you back.  So at this point ‑‑ okay, so we're going to try to see that it is going to work.
>>  All right.
>>  Keep going.  I feel optimistic.  Is the IP address correct?
>>  Yeah, there's always these minor issues that totally screw up our stuff.  Yeah, part of the issue is ‑‑ it's causing crazy packet loss.  So, something we didn't get to work this time.  It did work the last time.  So, 50‑50.  But we're going to run the pay load.  We'll just try to get the watcher to interpret that way.
>>  Actually going to run it as a EFI application.  That last pay load ‑‑ that will be fine.  So, we actually want to run it just sort of in an EFI shell.  These are EFI applications that can be made into the ‑‑ that are made by the BIOS.  We did one pay load from Linux.  This will manually nullify it and we'll read the flash chip and show that we actually bricked it.  All rightly so that was running the nullifier.  It's the kind of thing, the no visible, right.  The important thing is if I pull this power out and I put the power back in again, you're not going to see anything on the screen because this thing is now bricked.  There's no way for it to ever boot ever again unless I come in here with a programmer and attach it and so forth.  So, it will just show that like the bites resect vector have actually been turned to zeros, nullified.  That Black Hat I accidentally wrote to the chip instead of read to the chip so we're going try to not do that this time.  So, the reset vector for intel CP users is also like 32 bits for FFF0.  That's not right.  The reset vector on intel CP U.'s is FFF0.  It alliance the flash chip with the end of the physical address space and so what we see right here is that the original entry vector would have been no op, no op jump backwards and the ultimate nullifer has written four bites of data set it as 0000, there's no valid instruction and it is now nullified dead bricked and it is on‑‑ consumer systems there's pretty much nothing you can do about it.
(Applause).
>>  Running the wrong version of the script over here so whatever.  Okay.  So, we don't really have a lot of time but you can go read these slides later.  The main point is the watcher, as I said, it was an afterthought.  It took a couple weeks to build.  It's minimally simple.  You just have a tiny things that finds and executes stuff and then it just maximally complex in what it can do.  It can execute arbitrary shell code.  The watcher of tomorrow can have improved capabilities but the question is what can you actually do about this.  Can anyone stop attacks like the watcher and the answer is yes, yes, Copernicus can deal with the watcher.  It's basically a system that it does two things.  It tells you whether or not your BIOS is vulnerable to attacks like we talked about and a lot of vendors don't configure the BIOS correctly so the flash chip is open so that means anyone can nullify you at any point if they get kernel privileges and that's why we're trying to raise the awareness of that with Copernicus.  We do both integrity checking and vulnerability checking.  It can jump your BIOS and end speculate have there been modifications that you don't inspect and if I will more time I would show you an example of the different ways test it.  So, I'm just going to blow through this quickly.  The vulnerability disclosure we told intel the bugs back more than six months ago.  We have sort of a six month vulnerability disclosure timeline and read the slide if you want to know more but the one important thing is that we did show this on a single HP system to prove it was actually vulnerable we showed these UEFI systems do trickle down into real systems and as of yesterday HP went live with their advisory saying there's more than 500 different models of HP which are all vulnerable to these exploitable vulnerabilities so go check that out.  You're almost certainly vulnerable.  So in conclusion, we talked about three things today.  We've talked about a whole bunch of other things that at other conferences.  We'll talk about more stuff in the future.  There's a whole bunch of other people doing a bunch of talks about other things.  There's going to be a BIOS summary talk tomorrow.  You should check that out at noon and you'll find out more about all of the different ways that you're hose the down at the BIOS level.  So that we're out of time.  We'll be outside probably back that direction taking questions.  Thanks for your time.
(Applause).
 
"This text is being provided in a rough draft format.  Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the event."