Wednesday, February 1, 2017

The True Story of Windows 10 and the DMA-protection



Now the story continued when things like this showed up:

Quote from:

New Bitlocker features in Windows 10, version 1507









  1. Set the DMA protection on



    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PnP\Pci
      • DisableExternalDMAUnderLock (DWORD) = 1

    1. Have UEFI+SecureBoot+TPM+NoAdminRights
                                                               i.      Or MDM of course if you have one…
    1. Use Group Policy to disable FireWire
                                                               i.      See the old article:
                                                             ii.      But block these ClassIDs:
          • {7ebefbc0-3200-11d2-b4c2-00a0C9697d07}
          • {c06ff265-ae09-48f0-812c-16753d7cba83}
          • {d48179be-ec20-11d1-b6b8-00c04fa372a7}
          • {6bdd1fc1-810f-11d0-bec7-08002be2092f}


And remember my training videos on PluralSight and my Dojo at



  1. Ok, so someone had to be first to ask so no throwing, but for a., how critical is the NoAdminRights part. If you do absolutely everything and the user still has admin rights, is it all for nothing?

    1. Well in Security I'd say it's never for nothing. It's always better to increase Security than not. But the #1 rule since 1993 has been that there can't be good Security in Windows unless you don't run admin rights.

  2. Sami.
    Are you able to clarify how the Windows Hardware Compatibility Requirement System.Fundamentals.Firmware.NoExternalDMAOnBoot protects(or not) systems? Just for completeness sake.
    Many thanks

    1. This one is something that Windows has always really adheared to as Windows hasn't been able to use DMA-enabled devices for booting anyway. Mac OSX has supproted booting from FireWire or ThunderBolt but not Windows. The real trouble really starts when the OS is alive but this requirement is important to have. We need to protect more against DMA when the Computer is a the logon state rather than physically off. There is more of this in the documentation of MSDN:

  3. There is a lot more wrong with Bitlocker:

    2008: Vijay Bharadwaj and Neils Ferguson of Microsoft Corporation Comment on NIST standardization of XTS
    > In our opinion, one serious shortcoming of the proposal is that it does not contain a clear statement of what application-level security goals XTS aims to achieve.
    > The proposal appears to miss the effect of temporal effects on the security of XTS. It is possible for an attacker to observe a disk for a period of time and thereby gain a significant advantage in cryptanalysis.
    > An attack on large data units [...] This shows that large data units significantly weaken the system.
    > AES in XTS mode works with 16-byte blocks, and this allows for very fine-grained ciphertext manipulation attacks. We believe this is a significant problem in practice.
    > In a code modification attack the attacker randomizes a block of code and tries to corrupt the code in such a way as to introduce a security hole in the system whilst keeping the system functional.
    > The small block size of XTS-AES makes this attack rather easy. A larger block size makes it significantly harder.
    > A modern operating system has thousands of settings that are important for the security of the system.
    > Again, a larger block size significantly increases the security in two ways.
    Complete comment here:

    2016: XTS is default for Bitlocker in Windows 10
    > no argument given why it would be "more secure"
    > it saves you two percent of time when converting 10 GB of data

    1. Don't know who you are but I have two comments:
      1. I'll pay you 100€ to show me how you would hack BitLocker.
      2. What's your replacement for BitLocker? What do you use?

    2. Sorry, I had not set up my Blogger account yet, that's why my name was displayed as "Unknown".

      Second question first: The problem is not Bitlocker itself, but its default settings. I'm not using Windows, but if I did, I would switch it back to CBC mode and be aware that data is encrypted but not authenticated.

      Attack would take a lot of preparation, but it could look something like this:

      0. Perform some Windows installations in order to determine which disk blocks are probably used for interesting files (system executables, DLLs etc.).
      1. When I have access to the victim's laptop, I copy the encrypted disk. At this point I cannot decrypt anything.
      2. I wait for some time until some cricial security issues have been discovered and patched.
      3. When I have access to the victim's laptop again, I surgically implant disk blocks from my image file in oder to reset particular binaries to the vulnerable versions. This is particularly easy with XTS because of the small size of unchained blocks.
      4. When the victim is using his laptop again, I exploit the known vulnerability to take over.

      PS: You don't have to pay me, because I am not willing to invest the time for a proof of concept.

    3. 1. Yes, agreed.
      2. Luckily you are like the others I've asked

    4. It is not an easy attack. You have to prepare, you only have one try and have to be careful to not write rubbish to the disk.

      I totally agree that the DMA issue that you are highlighting is much more relevant for most users, because it can be done with a stolen laptop without too much preparations.

      The original point was a different one: Microsoft experts were very critical of XTS cipher mode, yet they have chosen it as their default.


      Cyber Security Projects for CSE

      JavaScript Training in Chennai

      Project Centers in Chennai for CSE

      JavaScript Training in Chennai

  5. You have shared the legal things about the windows 10 and its dma protection, It is good for our knowledge. If you are looking for home and office based MS Office Project 2016 Online, visit on softwareempire.

  6. Sami, this will be of interest: since Win10 v1703, there's the "Disable new DMA devices when this computer is locked"-GPO as you know. This GPO however produces weird results on win10 v1709 (RTM and 16299.19)! For me and several others that I read about, you need to disable the policy in order for other devices to work - for me it was the sound card, for other it included wifi ("code 10 - device cannot start")! This is reproducible and did not happen with v1703 on the same hardware. Please try it for yourself.

    ->This needs be be reported to Microsoft - you have connections, will you tell the developers? If you need hardware to reproduce: for me it was an Asrock Motherboard H97 Pro4 with onboard soundcard by realtek.

    1. Thanks for the notice. I've forwarded this to Microsoft.

    2. Microsoft asked for you to report this through the Feedback Hub as well, so please do so.

    3. Microsoft's official response to that:

      This is a big problem, as this setting is definitely an important one, but many companies will also need to upgrade to 1709, and don't want to wait on firmware updates that may never arrive.

    4. Based on the wording of this response, is it safe to assume that while the GPo results in the devices breaking (machine bricking in my case), the registry key listed in this article does not?

    5. The GPO sets the same registry setting, and nothing else, so it should be the same result. Mine broke down when ever I set it via MDM, GPO or manually.

  7. Hi Sami,

    I think MS messed up something in 1709 with this setting, please have a look at this Thread and my response..


  8. Looks like in RS4 everything is fixed now. Another question I have is how to turn on "Kernel DMA Protection", when you open MSINFO32 on Windows 10, for us it is turned off, allthough Device Guard is ON.

  9. Office coordinator skills should have education and experience in this field. It is necessary to have strong interpersonal and organizational skills to apply for job. If you want to get office management skills then you can visit our website. Learn more:
