Unlock Windows 11 personalization settings by modifying Settings app DLL

Introduction

After doing a research on how to temporarily remove Windows 10 ‘Activate Windows’ watermark, I decided to try to overcome another limitation of unactivated Windows 11.

This limitation (besides watermark in the lower right corner of the screen) is locked / disabled personalization settings inside Settings app. The method described here allows you to fully enable these settings without activating OS.

Debugging methods

Windows Settings app is stored in the following directory:

C:\Windows\ImmersiveControlPanel

Now, since Settings is a program stored in a UWP container, it means that you cannot launch it directly by double-clicking it or load it in a debugger and simply run it (although you can attach a debugger once the app is launched).

Let’s first attach a debugger to a running Settings app, to see what DLL’s are loaded.

We can see that the slc.dll (Software Licensing Client) is loaded, with an interesting function called SLIsWindowsGenuineLocal. We can put a breakpoint on it, and try to navigate around Personalization settings, but nothing happens.

Since we attached debugger after the full app startup, it means that the potential check for an activated Windows already passed early during the Settings app startup, so it didn’t get caught.

There are two methods to overcome this.

First method


Use the Settings app built-in support for a debugging, as mentioned here:

https://www.hexacorn.com/blog/2018/08/12/debugging-dosing-system-settings-win10/

Simply add Debug DWORD value (set it to 1) and launch Settings app which will now be in a suspended mode, waiting for a debugger to be attached to it.

Second method


Use the PLMDebug.exe which comes with the Debugging Tools as a part of the Windows SDK. It is located in the following directory (x64 version):

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

With this you can control the state (suspend, resume, etc…) of the UWP app while you are debugging, and you can use debuggers such as WinDbg, x64dbg etc… (in this example I will use x64dbg).

You will need Settings full package name in order to use PLMDebug, which you can find out using the following Powershell command:

Get-AppxPackage windows.immersivecontrolpanel

Use the following command to enable debugging:

plmdebug.exe /enableDebug windows.immersivecontrolpanel_10.0.6.1000_neutral_neutral_cw5n1h2txyewy "C:\Program Files\x64\x64dbg.exe"

Now, when you click on the Settings app, it will be launched along with the x64dbg attached automatically.

The debugger is attached, but only the core DLL’s are loaded, so you will need to instruct x64dbg to break on system DLL load, and execute the target (F9) until the slc.dll is loaded.

x64prefs

dllload

After the slc.dll is loaded, you can set a breakpoint on SLIsWindowsGenuineLocal function.

Remember to uncheck break on system DLL load inside preferences, to avoid breaking on subsequent DLL’s.

Bypass method

After choosing one of the debugging methods decribed above, the target will now break on a SLIsWindowsGenuineLocal call.

We return from the call, and end up inside SettingsEnvironment.Desktop.dll module from which the call is being made.

If we search for all intermodular calls inside this DLL, we can see that there are two calls to the SLIsWindowsGenuineLocal.

slcall

The second call leads us to a small wrapper function (simple and unobfuscated) which checks if Windows is activated or not.

This small function can be expressed like the following pseudocode:

pseudoc

Entire personalization settings are enabled or disabled, based on the return value of that function.:slightly_smiling_face:

How to use the unlock tool (sunlock11.exe)

This tool is simple, and it works by patching the function described above inside SettingsEnvironment.Desktop.dll so that it always returns true value, tricking Settings app into thinking that the Windows is activated, thus enabling all of the personalization settings.

SettingsEnvironment.Desktop.dll is a “system” file, owned by TrustedInstaller as other files in the System32 directory, so before patching it is necessary to set adequate permissions to be able to write to that DLL. This can be done manually (using takeown and icacls) or by using provided setpm.bat script which will do this automatically for you.

After modifying owner and permissions, run sunlock11.exe. Both the script and the unlock tool require administrative privileges, so make sure that you execute them as administrator.

Project & demo

Visit the link below for a project:

Video demo here:

Disclaimer

This program serves mainly as a reverse engineering demo, and you use it at your own risk. The author of this program cannot be held liable for any damages due to the use of this program. It is advisable not to use it on your main production PC, as it is modifying operating system file.

7 Likes

First thing that came to mind when i saw your post was the bluementals crack that you previously published (surprising that i should remember it, since it was a long time ago), nice to see another post from you, keep it up!

1 Like

I definitely did not think it was gonna be a simple true/false check, makes me wonder if other features are guarded the same way. I did some reverse engineering a couple times before, this make me wanna dive in but in a more practical way.

Really nice post keep it up :slight_smile: !

2 Likes

This topic was automatically closed after 121 days. New replies are no longer allowed.