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.
Windows Settings app is stored in the following directory:
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.
Use the Settings app built-in support for a debugging, as mentioned here:
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.
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:
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.
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.
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.
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:
Entire personalization settings are enabled or disabled, based on the return value of that function.
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.
Visit the link below for a project:
Video demo here:
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.