bcdedit-revert-uefi-gpt-boot-order: Powershell script to modify the UEFI/GPT boot order

This powershell script modifies the UEFI/GPT boot order by finding the first non-Windows entry and moving it to the top of the order. When using UEFI+GPT, the Windows installation (since Windows 7?) creates its own boot device entry (“Windows Boot Manager”, a.k.a. “{bootmgr}”) in the UEFI/GPT boot order list and, obnoxiously, takes the liberty of moving said entry to the top of the list. Under most circumstances, this is fine, and probably desirable. However for systems used for repeated deployment testing, or systems which you want a different bootloader to take priority (such as dual-boot systems, or computer lab systems that can be remotely re-imaged), this is a show stopper. So I needed a way to do this programmatically. This script makes use of the arcane and undocumented {fwbootmgr} identifier implemented by bcdedit to find the first non-Windows boot device entry in the UEFI/GPT boot order list and move it to the top of the list.


Get-USBHistory: get history of a USB flash driving using PowerShell



Firmware-BiosUpgrades: Update BIOS for any make and model (incremental if needed) [using PowerShell]

Update BIOS for any make and model (incremental if needed).
Invoke-BIOSUpgrade.ps1 – Checks the make and model and bios version, then compares that with whats in a corresponding folder (BIOS<make><model>). Does check for Bios password in plain text file BIOSPassword.txt (if exists). It will attempt to suspend bitlocker if enabled. Also sets a SMSTS environment variable SMSTS_BiosRebootRequired, SMSTS_BiosBatteryCharge, SMSTS_BiosBatteryCharge which can be used for a additional sequences. Also set a variable (SMSTS_MutipleBIOSUpdatesNeeded), which allows the bios to update incrementally if needed. This does require to have two steps in the tasksequence to run this script twice (or three times), but one of them should check if this variable is true.



PSRedfishEventListener: Redfish Event Listener in PowerShell

The Redfish specification supports event mechanism through which the target redfish devices can send events from different components in the system to an event listener. This project provides an event listener that is create in native PowerShell.




Detecting Evil Maid attacks with PowerShell

Re: https://firmwaresecurity.com/2018/04/25/donotdisturb-detect-evil-maid-attacks/

the above solution was a Mac-centric solution. Here’s a Microsoft-centric solution, using Powershell:


Grab this version before the Visual Studio or Azure teams ties the code to their products. ๐Ÿ™‚

Lenovo BIOS to UEFI


“Lenovo BIOS to UEFI TS Converter with CG/DG Prep: Allows you to configure SecureBoot/UEFI settings, as well as Virtualization Technology and TPM for Credential Guard and Device Guard. This script is designed to work on both ThinkPad and ThinkCentre machines. This script connects to the WMI instances for Lenovo machines, and then configures the requested settings. This script is designed to be used as part of a task sequence where you want to convert from legacy BIOS to UEFI and at the same time prepare the machine for Credential Guard and Device Guard.”

Kansa: incident response framework for Windows Powershell

I saw one of the speakers of Kansa recently, speaking about their project. Bryan tweeted about that talk:

[…] Kansa is a modular incident response framework in Powershell. It uses Powershell Remoting to run user contributed, ahem, user contributed modules across hosts in an enterprise to collect data for use during incident response, breach hunts, or for building an environmental baseline. […]

Kansa kindof reminds me of a Windows-centric, PowerShell-centric version of OSquery. ๐Ÿ™‚ It runs a remote powershell with various scripts on all the remote systems, and gathers the data into CSVs for analysis. It has multiple plugins. IMO, it needs many new firmware-related plugins (eg, one for the x-UEFI Configuration Database, etc.).

More info:

UEFI Advanced Security Settings for Microsoft Surface devices

A while ago, Mark Morowczynski of Microsoft wrote a blog post, “How to Manage Surface Pro 3 UEFI Through PowerShell”. In the post, he describes advanced UEFI security configuration options for the Microsoft Surface, such as enable/disable cameras, WiFi, Blootooth, Network Boot. There’s also information about using PowerShell to configure UEFI settings, scaling to control “tends of thousands” of Surface devices.

IMO, this is a nice use of UEFI to configure security settings, I hope other OEMs and OS vendors enable this kind of granularity to configure their systems. I also hope malware authors don’t exploit this ability to scale to all Surface devices in an enterprise with a single PowerShell command. ๐Ÿ™‚
More information: