>>So thanks, everybody. um.  We're here to talk about a bunch of scary low level stuff that nobody knows about, right?  

	So we're going to give a summary of attacks against bio sense secure groups.  A group of here is from Intel Security. The rest of my friends here are from a group called Advanced Threat Research and it's their job to find new attacks and find mitigation so we can deploy stuff and make things better overall, across all sorts of platforms, right?  I'm actually from the products security and response team.  We uh, coordinate a lot of these issues.  

	Been working with our friends at Miter -- presented yesterday and gave an awesome talk.  We have been coordinating a lot of this stuff, and, you know, we'd love to hear about more, even though we'd like to believe that there isn't more, but there's always something. And we'd love to hear from you at secure@Intel.com. 

	Um.  So we're talking about bios, right?  And so bios, um . . . in the beginning, there was what we now call legacy bios and it involves a lot of texts. Textual menus and according to this slide, a lot of blue, comes in various shapes and sizes, but mostly just blue.  Um.  And it had to do all of these things.  

	The system powers on and it has to go and put some instructions in the spy flash to start getting the system ready.  Um, we're going to start running out of cache, we're going to start configuring memory, start running out of memory, we're going to start configuring a bunch of devices and get everything ready to go, run a bunch of option ROMS and eventually we're going to find some kind of hard drive or boot media and we're going to go ahead and find the master boot record and load it and then that thing will start up on operating system, we think. 

And then along came the unified extensible firmware interface and we got icons. 

	>> [Laughter]. 

	>> And it's really interesting because now we also got a new color, black! And then I mean it did all sorts of good things, but really it's more about creating a standardized set of what I would call APIs, right?  Things that you can rely on having happened by the time you run it.  And here's this slide, right, and everyone who has presented on security regarding UFI has put this slide in their presentation, so here it is.  We're doing that, too because it's obligatory right?  

	And what it's really talking about is there's different phases.  It breaks up the whole boot process into these different phases.  And what is really going on is you are building upon the phase before you.  It does all the same stuff that I was talking about.  You start out running out of cache and then you go ahead and set up memory and then you go ahead and configure all these devices and eventually you come to the point where you're going to make a decision about what you're going to boot off of. You go ahead and make that decision, you load up a binary and then that thing is a boot loader and loads up an operating system, right?  

	So um one of the things that UFI does is it gives you, well, two things.  It gives you, it tries to get up to 32 bit virtual very quickly and it just starts to run things.   Just like, you know, regular loading of an executable and then it also gives you these run time services which are standardized APIs that you can call even after the boost, uh, bios has finished its job and you're running at run time. 

	So with this came a standard for secure boot. Right?  And the way this sort of works is that, I'm trying to see my slide here, um, it's basically checking signatures, right?  

	We start with assigned bios because if you could put whatever you wanted in the spy flash, I don't know how many of you guys heard Miter's talk yesterday, but they said it very nicely, right?  Gee, what attacks can I come up with that I could do if I controlled whatever was in the spy flash? Which is the first thing that gets executed when the machine powers on.  

	That would be any attack you can think of.  So.  It's pretty nice, it's pretty nice if you can get there. So we have to start with this ability to ensure that what's there is right. And that's where the signed bios update comes from. And after that you start checking signatures on everything that runs after you. 

	Right.  So we get to the stages we're running a Dispatcher and we'll check a signature before we run it.  We get to the boot loader and we'll check a signature before we run it.  And that allows you to create an operating system secure boot that can then check the signature on all of the drivers before it runs those. 

	And we'll be talking about attacks against all of that. 

	And so, let's start.  Well, so the way we're going to go about this, is we're going to go around this wheel and we're basically going to talk about different facets of attack surface on platform firmware.  And we're going to start with the spy flash.  

	Now like I was saying, it's a pretty nice place. And so what we do on the platform, so the nature of this, first of all, step back. There's a whole bunch of stuff here.  There's, uh . . . We're going to blow through it really fast.  That's why we mentioned we'll be in the hardware village afterward, if you really want to go into some detail and try to understand it with us we'll be happy to walk you through it. 

	So.  Back to spy flash, like I said, it's a really good place to be.  There's two real sort of methods, to protecting it, right?  One is based on system management mode. System Management Mode is a different mode of the CPU.  It executes out of a kind of protected region of memory.  And it's protected such that that you can't read or write this while not in system management mode, all of the sudden you transition into system management mode and there it is. 

	Um.  So one method is to use system management mode to protect it. You set a bunch of, uh, you basically disable write access and then you lock it and if you try to re-enable it, it will generate a system management interrupt and that's what transitions the machine into system management mode and it starts executing the SMI handler.  

	Um.  So you have to set a bunch of bits and a bios control register and that will lock the spy flash from writes and it will also, um, it can also force writes which can only occur when in system management mode.  

	The alternate way if you're not using SMM would be to use the spy protected ranges that are PR 0-4, there's five sort of ranges. And you can basically set up a base and a limit and that region gets protected and you can set it to be write protected.  And it will be that way up until your boot platform. 

	So there's two different methods, you know, you can sort of see what your platform does.  You can go and find the bios control registry, you can read it and say, gee, what bits are set?  

	So you can do that with some tool manually and that's kind of a pain, so we wrote a tool called chip set and Miter has a tool called Pernicious.  You can basically go and see what these bits are set to.  So you can see at the top there you have got bios write enable, right?  And then you want to see that's disabled, so zero. You've got Bios lock enable, you would like to see this is locked and that's what will generate the SMI. 

	And then you have got SNMBW3.  That forces the write to occur when you are in SNM.  

	So then we are checking the other mechanism as well.  The red line down below is talking about what the spy protected ranges are doing. So you've got the range itself and write protect, and it will be checking to see that your covering the entire Bios region.  You can do either one of these things and it can work. 

	So if you don't cover the entire Bios region, then you're allowing somebody to write to that. And if they do that, then you get things like what Uri presented last year at blackhat where you can just sort of write whatever you want there, which could be shell code, it could bejust random junk that breaks the platform, it's bad. 

	We're going to push all of our demos to the end because we've got a lot of stuff and we're afraid of running out of time, so we've got them, we'll get to them at the end. If you are really interested or if we miss stuff, come see us in hardware village and we'll have everything for you there.  

	So here's the nice one, Teddy Reed presenting something really cool recently where he was looking at a bunch of Bios updates and seeing what they were doing and in particularly seeing who wasn't doing that.  This was really interesting.   He calls this one day from hell, which is kind of a good word for it actually. In this update you can actually see the patch is adding the lock bits being set. All right?  

	But remember in the last slide I was actually saying there's a few lock bits you have to set, and there are a couple of things you have to do and it's not actually doing them all, so that's even more interesting. 

	Um.  So the first mechanism was the system management mode, right?  If you use system management mode, then you get a system management interrupt triggered when you try to flip -- when you try to flip the Bios write, the write protection off. 

	What if you could suppress SSMIs?  If you could suppress SSMIs then that system interrupt would not occur. The system would simply have the spy flash unlocked and now you can write to the spy flash. Well, Miter presented a little bit earlier this year an attack where if the SMI lock bit is not set, then you can actually disable SMIs. And that does what I said, it kind of causes a problem. 

	So basically you want to check your platform to see that this is set up and that it's locked, in particularly that it's locked. 

	Remember the other mechanism, you can use the spy flash itself with these protected ranges.  Well, you have to configure those properly, right?  So that's what we were talking about earlier, but, you know, you also have to lock that. So you can set it up and then not lock it and then somebody can change it. So that's what the F lock down bit is all about. Again, you can just check for that. 

	So now let's talk about a different interface.  We talked about spy flash. Let's talk about Bios update as an interface itself.  We're talking about these Bios attacks and we're thinking, this is really complicated, low level stuff people don't know anything about, so you'll never see it, right?  

	Well, Mebroni is an example of this actually being done in malware, right?  So they basically used a particular Bios that did not enforce any sort of protection on its Bios update interface, simply used that Bios update interface to introduce its little boot kit directly into the Bios. 

	Another issue, even if you have tried to protect the interfaces, there's occasionally some data that you don't -- can't really trust.  

	So a few years ago, the talk by invisible things lab showed an issue with an Intel bios where basically the image that gets displayed on your screen when you power up, yeah, that was just an image that was being parsed and it was not really verified in any way, so they found on inner droner flow that allowed them to take control that bios there just by substituting that image.  

	Similarly, a little while ago Miter published an interesting thing with the update packets.  So bios updates often, they break up the update into a bunch of little sections, right?  Which then need to be put together when, after you reboot and you're going to actually install the Bios update. 

	Well, what they found is that when they were putting this together, they were talking the fields of these packets and they were using that in an MEM copy and then they could basically use maliciously formed packets to take control right as you are doing the Bios update itself. 

	So then there's SM RAM.   So I mentioned some of the protections are dealing with system management mode, right?  So system management mode, I think I described it as having, being a separate execution mode that's protected.  Well, it's protected as long as it protects itself, right?  So the first bit that we'll talk about is the sort of legacy or compatibility SM RAM.  And I think this is best done with a picture. 

	So normally you have code executing and you're writing memory addresses and you're usually writing to D ram, but occasionally you find things like memory map bio.  With SM RAM when you are in normal execution mode, you will basically pass through and go straight through the system bus, right?

	When you're in SM -- or when you set up SM ram, you need it to be able to talk to actual D ram, right?  And that is flipped with these, with this particular register, some particular bits in this register.  Basically bios will set it up and say, it will start up open and it will load up SMI handlers there and close it and lock it. So you want to check it is actually closed and locked in SM ram.  

	So after that attack, a few years later, so that was found like back in 2006, I think by both Invisible Things Lab and the Lloyd group.  You have got the same people, a couple years later, figuring out, gee, if I -- if I'm really just running out of ram, the way the processor works is it just caches stuff, so if I can get the instructions that I want to execute in the cache for those addresses, then I could get it to run whatever I want. And that works, right?  

	So Intel introduces these system management range registers which will force the non-cached area for those ranges that would be SM ram. So what you can do is just look at the platform and see, are those things configured?  Is that set up properly?  

	I think I'm going to turn it over here so that the rest of this talk can be in Russian, because I think that would be really helpful to everyone because it's really easy to understand this stuff. 

	>> Hey, everyone. Thanks for coming. Even if you were here for Dan's talk. I don't know if this mic works or not, but, I mean, so I didn't know the dude actually knew that much about bios, yeah, so it was awesome. 

	Okay, I'll continue describing the attacks against SM RAM, it's important.  There are still questions.  You know, why do you need to get into the SM RAM, why do you need to compromise SMI handlers?  If you have S-kernel privileges, for example.  You can do pretty much everything.  Well, there are a couple of reasons to do that. 

	For example, according to Government, you can get more influence. You know?  According to our friends from Miter team, you can be bitten by a tick or a flea. Just imagine, just think about that, none of the other exploits can get you fleas. So on a more serious note, SM ram, first you gotta to code there and it's pretty much protected, so you cannot really get it out there. Plus it can patch the OS, it can patch the head provisor, more importantly it can patch to Bios so it can get persistency.   

	As we showed some time ago, you can get the early compromised device you can bypass, or you can melt the evil main attacks even against the full decryption systems that do use TPM.  Or you can bypass security.  

	So continuing in the line of the attacks, one of the attacks that has been demonstrated using the chip set remapping capability, without going into gory details, basically on the platform you have low MMIO which can be gigabyte and if you have 8 gigabyte of memory, you don't want to waste one gigabyte of memory to the MMIO. So there's a mechanism called Reclaimed.  It intends to reclaim that memory.  

	The way it works, there's a window, if you access like Windows, typically about four gig, it will get remapped by a chip set to the place, to the D ram behind that or lost to that MMIO.   

	So there's -- it has to be locked because if it's not locked then the molar can use that, and the way exploit works is that the attacker can drop this boundary between D ram and MMIO below SM RAM and use that remapping mechanism to remap to the SM ram, so now your SM ram is in the memory covered by MMIO. So obviously the mitigation to that is just use the, you know, lock down the configuration.  

	Don't allow a OS malware to reconfigure. 

	Oh, yep, that's a good nice slide with a nice picture of how it actually works.  This is a normal memory map.  That's how it actually works, the attack.  You drop TOL, you access the memory reclaim range, about four gigabits, and the chip remaps it to above, which is now SM RAM.  You modify the SM handler, you inject a key logger or something like that, and then you return back to that configuration. 

	So your SM has malicious code.  And there's a check for that. So I'll be flying through those type of slides. 

	So the other type of attack and I'll show you a picture, so normal, normal system looks like that, including graphics and graphic stuff.  

	So for example, there's an MMIO bar that points to a graphics translation table. And so they are used to translate access coming to this graphic separator which is the second yellow box. And it translates access to that graphic separator to graphics memory.  However, that can be used to attack SM RAM as well. Assuming the configuration is not locked, as in the previous remapping attack.  For example, the bios forgot to lock the TOL.  You can see how that would be used to attack.  Somebody drops a TOL, similar to the previous attack.   

	But instead of using remapping, the exploit can now -- you can see that SM ram is now in MMIO, so when SMI event occurs, CPU tries to fetch something, but not from D RAM, but from MMIO, but there is nothing there.   So the attacker overlaps the graphic separator on top of that. So there's a double redirection and it redirections the graphic separator, so according to GTT interest that have also been replaced by the attacker, somewhere else, that is the third redirection.  

	I call it in the tradition of Jean Claude VanDamme, I call it triple redirection attack, so using these multiple hubs the attackers to force CPU to fetch the code from some other place outside of the protected range.  So the solution is the same as in the previous attack. It's -- just make sure the attacker cannot do those tricks, cannot do the reconfiguration.  

	So you heard there was a lot of research on DMA attacks and if someone can use DMA let's say from a graphics card or network card, if firmware on the card is compromised, or even from the west kernel exploit that directly asks some of the cards to do the DMA to protected memory, you want to be able to protect the system management mode and a code from those kind of attacks.  And the way it's done in the platforms is there is a protection on the chip set level that basically says there's an enough stream transaction, memory targeting SMN memory which is defined as BoV Tsvg base, which in that case, just lock that, don't allow that. 

	However, it still relies on the platform channel, the bios firm ware to lock down the configuration.  So for example, in the previous attacks if the bios forgets to lock down configuration and allows malware to modify it, the malware could change the base of where the SM ram is from, perspective.  And, therefore, once you do that, now the attack, the DMA attack can work.  So the DMA cycles are below T seg and they are allowed to get through to the memory.  Right?  

	There are two actually variances of this attack though.  One variance is regular DMA from some unknown card, for example, a network card at the bottom of the slide. And there is also another variant through the graphic separator, which is treated as a DMA as well. Yeah, and in a couple of weeks we're releasing a test for the vulnerability in the open source section and you can take a look at that. 

	So other than protecting SM ram, obviously there may be other issues, you know, issues with the hardware configuration that it can be improperly configured, it can be reconfigured by the malware and that can result in certain attacks on bios, secure boot and so on. 

	 One of those attacks was demonstrated in 2007 at POC conference by a person from McAfee and it was a bios swap, but a block/swap attack.  There's a mechanism in trip set that allows you to do full tolerant update of the bib lock.  The bib lock is the top most lock of the spy flash ware.  The bios is where the reset factor is and so on.  

	So normally CVU coming out of reset, it starts fetching instructions from the catch line below for a gig. So FFFFF, zero address.  That's the reset vector.  However, in order to do the full tolerant update, there's a mechanism that allows you to switch where the reset vector is. Basically which block the reset vector will be executed in. 

	To show that on a better picture, so the top most picture is the original boot and the bottom part of the slide is when this top swap mechanism is enabled.  So you can see that any access that targets spy flash a firmware hub or basically anywhere bios firmware is, it gets swapped, so now the reset factor, it's now an alternate bios bib lock, backup bib lock. 

	So obviously if bios allows to do those kinds of tricks to the OS malware, OS malware could enable top swap mode and then because this has to survive the reboot, the malware reboots the system.  The CPU will fetch the instructions from somewhere else.  

	It could be an OS and you'll get an unbootable system or it could be malicious code, if that piece, if that alternate bib block wasn't protected, it could be a malicious virus. 

	So the way to mitigate that is essentially, you know, block malware's capability to modify the bib block. Okay, so now obviously people realize that attacking SM ram through some hardware tricks or configuration tricks is not enough. 

	There's a whole bunch of stuff running in the SM ram those are called SY handlers.  And they have been  developed a couple of decades ago with nobody thinking about security back then, well, not security of SMN. Not that role. there may be bugs there.  One of these types of attacks had been discovered and published in 2008 or 2009, I forgot, so basically you have SM ram and you have a bunch of firmware running. 
	
	And I'm due for a shot, sorry.  

	>>Take your time.  You all know why we're here! 
	
	>> [Applause]. 
	
	>> I just want to point out, as we were walking up here to shot these guys, there was a guy walking out and I said, why are you walking out of this talk?  I thought this would be a pretty good one.  He said oh man, it's over my head.  I'm a colonel programmer from way back. That guy is a pussy. 

	>> Oh, you?  You've got it going on.  All right, how about some love for the new speakers.  

	>> [Applause]. 

	>> where are his shots?!  That was wrong, that was wrong! As you were. 

	>> Okay. So where I was.  Oh man, memory plays tricks on me.  

	So, types of vulnerabilities in the SMI handlers.  The first type was discovered, as there are a lot of SMI handlers, but a lot of the routines that they use, let's say talk to hardware, talk to RTC, talk to registers and so on, they are wrapped in two functions.  But there's a precious space, spyflash is a precious space and so you can not really move that code to the SM ram all the time.  You already have that code in the bios, which is in the D ram. So why not just use it and call it?  And that's what SMI handlers did.  

	You can say call F 0000, segment selector, call segment selector, with some EIP.   And it happens to be translated to a physical address in F segment below one megabyte which is not protected. So that's how it works. Somebody found this out and replaced that function that the SMI handler calls with the malicious code and the SMI handler will do the job for you.  It will just invoke that function.  

	So yeah, that has been published.  And what's interesting is that the vulnerability disclosure just disclosed fourteen issues in one SMI handler out of 30, which amounts for hundreds in one single bios.  And remember that flash ware typically uses the same bios. 

	So, in going to EFI, obviously this type of vulnerability, this is almost away, almost, because EFI bios still want to invoke something from outside of SM RAM and in that particular example, the SMI, the EDK based SMI handler, it wasn't directly calling the function, it was actually reading the function pointer from the ACPI, from the normal Intel memory which is not solid, it's in D RAM, and then calling it. So pretty much the same type of problems, but slightly different. 

	So now I am switching to the attacks against secure boot. We've been researching that area for a year, year and a half, and I'm giving the microphone to Alex who will start with the attacks against secure boot. 
	
	>> My name is Alex. So I would describe a little bit about secure boot and how we secure boot. 

	So basically there's most important thing in secure boot implantation is hierarchy and there is the platform key that you set the vendor key. This you need to verify the exchange key and the change key needs to verify the wide list and set list signature for modules and banner which can load the secure boot, and boot disable. platform key is stored in normal memory and spyflash.  It is a variable which is protected and bios check -- if bios can find the platform key, it will allow, enable the secure boot. If not, bios assumes that secure boot is disabled.  

	So basically this is where we create our exploit from secure boot bypass. For this exploit, you need to have an ability to write and protect mechanism bios, so basically we will talk a little bit about this exploit. So we just as a regular variable, the platform key has a name and body, so if you corrupt the name of the variable, then bios didn't find the variable and you can assume bios is disabled, so you have a secure boot. 

	And as you can check in this slide, in the left hand we have the original down post spyflash platform key, and on the right hand we have the identification like this and we have this corrupt platform key. 

	There is a high level picture of our attack.  So.  We corrupt the platform key to compromise bios enough so that we install boot key to unify partition and compromise the full system. And this is the demo. This part should be joke, but I skip it.  
	
	>> [Laughter].
 
	>> We want to start thinking about how we can bypass a secure boot, and how bios should implement secure boot internal.  This should be the variable of the secure boot enable which is enabled and by here should be different and related to this variable.  And you can check and it should find.  

	So the next very good experiment which we did, it's great too, was full spy flash. One of the secure boot enable and one secure boot disable.  And compare this dump.  So if you are trying to do that, it's not really easy.  But after that we implemented some forensics.  So after that we implement the chip set and you can sparse the spy image, and extract all DLLs, all D drivers, all EFI variables and compare it independently.  

	And to be cached, we're interested in BFI variable, the set up variable, it's a run down variable so you can modify it from Windows EPI. And if you flip back to this, you can very easily disable secure boot. So basically just run very simple Windows EPI function and flip two bits from three you can do that with security boot. So that will be the second demo. And we will continue to talk about this. 
	
	>> The policies, policies is the way of the bios to configure the image verification behavior. So they may choose to skip image verification if the image is loaded from protected spy flash or choose a different behavior in the image verification is failed.  Like, ask a user, or It allows the image execution. So this is how it's implemented in open source, ETK2, so as you can see there, there are fixed values taken from the configuration database, so they cannot be changed in run time.  

	But sometimes bios may choose some flexibility and it decide can be set up. So this is an actual screen shot from an a secure boot image verification violation.  And that variable, did have these values, after some trials and errors, we found the location.  

	So here they are. As you can see this 044 is for optional policy, fixed media policy and removal media policy. 0 is for the all execute, 4 is for deny execution.  So all they need to do is just modify the set up variable and change the subset notice to zero. And we have execution.  

	So this way the secure boot is still enabled, but no verification is performed so you can load whatever you want. And this issue was discovered together with the Miter guys -- this is a slide from their presentation. They do a reverse engineer and this shows the values for the policy are taken from the set up variable. This should be a demo. So a couple of guidelines to bios, how to avoid these issues.  

	So first of all, if you protect the settings, if you decide to move them into EFI variables, make those variables inaccessible and don't expose them to a breaking system and untrusted software. The variables are authenticated, so only you can change and update them. And to check that the user is physically present and modifying those. And, of course, the default and image verification policies to secure those.  Don't use always execute or allow execute and default variables. And image verification handlers should take care not only on secure boot settings and policies, but it should also check if the executed image has a supported format.    

	Currently the only supportive format for this is the Bkav image software. The bios firmware can verify the signature and image only if it's Bkav.   Sometimes bios specifications are defined as executable from us.  Yes.  The two other formats, the first one is the EFI Bitcord, which actually is the same Bkav image wrapping around the EFI Bitcord. And there so-called Terse, executable G.  Which is not a Bkav image.  But the only difference from the Bkav image is G hello. This is much smaller than Bkav and this was done to conserve the precise space in spy flash.  

	So the G images are usually always from spy flash. 

	Let's take a look at the actual implementation inside EFI bios. So the parse spy flash dumped this and we found that the dixit drivers that actually implement the image verification library.  It's core dixit.  E file.  

	So load it into IDA Pro and we found that the function that is left is the image verification heller and what it does is it calls functions that checks that the executable image is a valid Bkav image.  And it returns an error if it's not. And if results in an error, the image verification hierarchy just checks, if the error is set. If not, it will continue execution.  But if the error was returned it just returns zero, which actually is a success.  

	So no verification is performed, it just skipped. So secure boot is still enabled, but no verification is done. So that is simple. Just get the executable and bootkey go to T format by replacing the Bkav heller and replace a break in system orders on the partition and that's it. 
	
	>> All right, we have 5 minutes and I want to show at least one demo because we have four or five demos.  You can catch us later and we can show more demos.  But a couple more issues, so other problems that we have discovered in some of the bios, they enable CSM which is a compatibility support module, which allows you to boot legacy OS on top of the EFI firmware, basically enabling CSM with secure boot.  That's a bad idea.  Secure boot should check signatures, but legacy boot doesn't know about the signatures at all. 

	So the other problems are some of the systems allows the systems restore to secure boot configuration and keys or set them to restore to default, or clear them.  So remember the first attack corrupting PK?  You can clear secure boot configuration which will disable, which will remove platform key.  And guess what will happen?  Secure boot will get disabled.  So some of the bios they actually store a bit that tells them to start this clearing in an unprotected configuration available to the ring three.  

	And this is, was my favorite. This was not really an exploit because we didn't need to do anything. I mean, what we did is on some of the laptops, on specific models of specific vendors, what we figured is we can change the configuration secure bit, we could disable it, but they've implemented a signature hashing scheme where they actually store the hash, the critical configuration somewhere and they check if it's changed.  And they tell the user, hey, it's changed, you know?  

	So what they do is they do it three times, wait for two seconds.  We didn't catch that attack immediately.  We actually figured this out in a week or so. Then they continue booting with the changed settings.  And this is the cryptic message that you should be able to, you know, do something in urgently because somebody is trying to put a boot kit your system, within 2 seconds or 3 seconds.  

	So there are other problems with the bios, specifically for settings, for example, Jonathan Brussard disclosed the vulnerability some time ago that the bios don't clear the keyboard bar first, you tie a bios password, an HDD password, so you have a pre-authentication system password and then it lies around in memory and is available to anyone.  The bios need to clear that.  And we actually have a test you can use to see if your bios system is clearing that. 

	Oh, SMI handlers, we have one minute, so I'll just say a couple words that we do continue research in vulnerability affecting bios and secure booting, we continue coordination with all platform manufacturers and bios vendors, specifically we are in the middle of coordinating multiple issues with EFI based SMI handlers.  So in the last words, so one may think all of these attacks require kernel mode privileges.  And typically yes, you work with the hardware, you work with the bios, you need to talk with the hardware interface, IO ports, P second fixed base, physical memory, so, yes, technically this is a kernel privilege, but what we have co-discovered with the Miter team is there are kernel mode drivers that actually do that for you. 

	So you can ask to write to the physical memory or boards or IO, MMIO or P-sec config and they will do it.  And they are assigned for old versions of Windows that require signatures.  So, yes, that makes all of those attacks, even though that initially required kernel mode privileges as a user mode.  You can compromise bios, you can compromise SMM, you can bypass secure boot, you can enable attack from user mode. 

	There are guidelines.  There's lots of research.  I do want to thank all of the researchers that work in that obscure area, because this is a baseline for the security of the entire platform. You can catch us, I don't have time even for one demo, but we will have videos available of all of the demos from this talk or you can catch us at hardware hacking village.  Thank you. Thanks everyone for coming. 
	
	>> [Applause]. 
	
	>> Do I have one more minute?  No?  We're done. 
	
	>> Yeah. 
	
	>> Oh, so really sorry, we have one more minute, so I'll attempt a live demo of bypassing secure boot on the system we've been actually been presenting.  You can see why we waited until the end of the presentation. 

	So anyway, so secure boot is enabled.  I'm not showing that, although I usually do. So we'll launch the exploit which is BT header exploit. What we did is we just replace the floater.  That's it.  But the bit loader with a different boot kit has a different pattern, that's it.