M$ causes more trouble for PE developers with UCPD driver

Have a question or found something out about an application? Post here
Post Reply
User avatar
Homes32
Code Baker
Posts: 291
Joined: Sun 06 Jun, 2021 8:10 pm

M$ causes more trouble for PE developers with UCPD driver

Post by Homes32 »

Recently, I noticed PhoenixPE's StartAllBack script failing during a RegWrite operation intended to disable useless Widets from showing on the taskbar in WinPE.

Code: Select all

RegWrite,HKLM,0x4,"Tmp_Default\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced","TaskbarDa",0
[Error] [E] RegWrite - System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
at Microsoft.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
at Microsoft.Win32.RegistryKey.SetValueCore(String name, Object value, RegistryValueKind valueKind)
at PEBakery.Core.Commands.CommandRegistry.RegWrite(EngineState s, CodeCommand cmd)
at PEBakery.Core.Engine.ExecuteCommand(EngineState s, CodeCommand cmd)
(RegWrite,HKLM,0x4,"Tmp_Default\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced","TaskbarDa",0) (Line 114)
This looked similar to issues that affected Firefox and Chrome back in June where we were suddenly being prevented from setting FF or Chrome as the default browser for PhoenixPE. (https://github.com/PhoenixPE/PhoenixPE/ ... 2f0c013786)

After some research it appears that with a recent patch our evil overlord as updated their ironically named User Choice Protection Driver (UCPD for short) running on the HOST system to specifically target and block any modification of the TaskbarDa key in addition to the previously blocked default pdf viewer and the default browser choice. I also found an nice article that explains how the UCPD driver is implementing the blocks and how to disable it, should you be interested in the technical aspects.

Perhaps most frustrating is either due to the arrogance of the mighty corporation or sheer sloppiness of pattern matching reminiscent of the epic Sony Rootkit fail, the driver blocks access to these keys in offline/user mounted registry hives! Not just the key in the running Windows instance (HKCU). :frusty:

No doubt in the future we can expect more surprises as M$ pushes out updates that block more and more settings from being changed in order for them to Choose for us the settings we are allowed to use?
Last edited by Homes32 on Thu 31 Oct, 2024 9:23 pm, edited 1 time in total.
HardSell
Registered User
Posts: 117
Joined: Sat 21 Oct, 2023 12:37 pm

Re: M$ causes more trouble for PE developers with UCPD driver

Post by HardSell »

In Regards to Windows PE and the intended uses we develop these Projects for, Windows 10 is all Good...
Having or using the latest and greatest Windows OS is not required for our purpose...
But it is also in a developer's DNA to accept the challenge to see if we can overcome those challenges..
User avatar
Homes32
Code Baker
Posts: 291
Joined: Sun 06 Jun, 2021 8:10 pm

Re: M$ causes more trouble for PE developers with UCPD driver

Post by Homes32 »

HardSell wrote: Mon 23 Sep, 2024 12:46 pm In Regards to Windows PE and the intended uses we develop these Projects for, Windows 10 is all Good...
Having or using the latest and greatest Windows OS is not required for our purpose...
But it is also in a developer's DNA to accept the challenge to see if we can overcome those challenges..
That is true, however the issue in this case is that its the HOST computer used to build the WinPE thats targeted and affected by the UCPD driver and causes the build issues, not the target PE. In this case both Win10 and Win11 HOSTS are affected by the driver M$ has gifted us with. Having up to date patching on our day to day host PC's is essential to security, unlike a WinPE host that is purpose built with only essential services and normally used in isolated and temporary environments.
Post Reply