Jump to content











Photo
- - - - -

Modifying Windows Product/License policies using Grub4Dos


  • Please log in to reply
11 replies to this topic

#1 agni

agni

    Frequent Member

  • Tutorial Writer
  • 244 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted A week ago

Windows product policy contains a lot of useful settings.

 

By modifying the Kernel-NativeVHDBoot native VHD boot can be enabled on all unsupported versions of Windows 7.

 Native VHD Boot on unsupported versions of Windows 7

 

By modifying Kernel-WindowsMaxMemAllowedx86 and Kernel-MaxPhysicalPage to 16384 (from a lower value), 32-bit versions of Windows 7 can potentially access more than 4GB of RAM.

http://reboot.pro/to...iewer/?p=201389

http://reboot.pro/to...e-4#entry201388

 

Erwan built an excellent tool called ProductPolicy Viewer to view and Edit the Product Policy Settings. The discussion was first started here - http://reboot.pro/to...4dos/?p=193727 

 

A few facts about the Windows Product and License Policy

  1. The settings are stored in the registry at SYSTEM\CurrentControlSet\Control\ProductOptions\ProductPolicy
  2. The structure of these settings is not straightforward and is described at http://reboot.pro/to...dows-licensing/
  3. The product policy registry key cannot be modified on an online registry hive. The kernel protects it from modification. 
  4. Erwan's tool - modifies the product policy on an offline registry hive. The modified values have effect only on the first boot after the modification. On subsequent reboots, the modified settings are lost as the software protection policy restores them from Windows\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\ SoftwareProtectionPlatform\tokens.dat .

One option to overcome this problem is to disable the Software Protection Service(sppsvc). However, this causes problems with Windows Activation, installation/uninstallation of Windows Updates etc

 

Other options include running Windows 7 in RAM, so the changes are not persisted. However not everybody runs Windows from RAM, so it's not feasible - http://reboot.pro/to...e-4#entry201388

 

Since Grub4dos can edit files using cat, I started investigating and did hex diff between an unmodified system hive and a system hive modified with ProductPolicy Viewer. I found the corresponding hex entries for Kernel-WindowsMaxMemAllowedx86, Kernel-MaxPhysicalPage and Kernel-NativeVHDBoot.

 

Using my rudimentary grub4dos skills I came up with the below working Grub4Dos entries

 

PAE Patch for Windows 7 Starter - Alternative to patching the kernel

title Windows 7 32 Bit Starter with PAE Patch
find --set-root --ignore-floppies --ignore-cd /Windows/System32/config/system
cat --locate=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x08 --number=1 --replace=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x40 /Windows/System32/config/system
echo Patched Kernel-WindowsMaxMemAllowedx86
cat --locate=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x10 --number=1 --replace=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x40 /Windows/System32/config/system
echo Patched Kernel-MaxPhysicalPage
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr
pause Press any key....

Find string will be different for other versions of Windows, the last hex value will change from \x08 to \x10.

\x08 corresponds to 2GB (0x0800 -> 16*16*8 )  while \x10 corresponds to 4GB (0x1000-> 16*16*16)

 

Win7Starter8GB.png

 

Native VHD Patch for WIndows 7 Starter in a VHD

title Windows 7 Starter with NativeVHD Patch
find --set-root --ignore-floppies /Win7Starter.vhd
map /Win7Starter.vhd (hd0)
map --hook
cat --locate=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x00 --number=1 --replace=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x01 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-NativeVHDBoot
map --unhook
map --unmap=0:0xff
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr

 

Native VHD and PAE patch Windows 7 Starter 32 bit in a VHD

 

title Windows 7 Starter 32-bit with NativeVHD and PAEPatch
find --set-root --ignore-floppies /Win7Starter.vhd
map /Win7Starter.vhd (hd0)
map --hook
cat --locate=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x00 --number=1 --replace=\x56\x00\x48\x00\x44\x00\x42\x00\x6F\x00\x6F\x00\x74\x00\x01 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-NativeVHDBoot
cat --locate=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x08 --number=1 --replace=\x77\x00\x65\x00\x64\x00\x78\x00\x38\x00\x36\x00\x00\x40 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-WindowsMaxMemAllowedx86
cat --locate=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x10 --number=1 --replace=\x61\x00\x6C\x00\x50\x00\x61\x00\x67\x00\x65\x00\x00\x40 (hd0,0)/Windows/System32/config/system
echo Patched Kernel-MaxPhysicalPage
map --unhook
map --unmap=0:0xff
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr

The menu entries are not entirely bug-free. Since the cat command is restricted to 16 chars, I cannot be very specific about the entries I am finding and replacing.

 

The entries patching the files inside VHD are very slow and don't work if the files are already patched - the menu just gets stuck. I am not sure why this is happening.

 

Let me know your thoughts, feedbacks, suggestions etc.



#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13221 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

What is the meaning of "map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)"? :dubbio:

 

As a generic rule, unlike what a lot of people seems to believe, it is IMNSHO much easier (and less prone to issues) to write grub4dos commands in a .g4b batch file, that is then invoked in the menu.lst.

This way the menu.lst is kept "simple" and "human readable". 

 

As well in a batch file, since you can use loops and variables, you can - if needed - workaround the length limit of cat, as you can look for the address (locate without replace) of a given string, then "probe" the following 16 bytes, etc. using skip.

 

As a side note, why don't you use the bootmgr inside the vhd (i.e. (hd0,0)/bootmgr instead of the find --set-root )?

 

 

:duff:

Wonko



#3 agni

agni

    Frequent Member

  • Tutorial Writer
  • 244 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted A week ago

What is the meaning of "map --heads=2 --sectors-per-track=18 --mem (md)0x800+4 (99)"? :dubbio:

 

 

Removed it. I had copied it by mistake from Wimb's menu.lst for booting Firadisk based vhd

 

 

 

As a side note, why don't you use the bootmgr inside the vhd (i.e. (hd0,0)/bootmgr instead of the find --set-root )?

 

 

:duff:

Wonko

 

I am not sure if that will work with native VHD boot.

 

The BCD inside the VHD looks like this

BCDInsideVHD.png

 

The BCD on the main hardisk, which contains the entry to load the VHD looks like this

BCDonDisk.png

 

So I invoke the bootmgr on the harddisk rather than the bootmgr inside the VHD.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13221 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

Yep, it has to be tested, but it should be possible to have the one inside the vhd to work just fine.  of course it needs to be modified with a .vhd entry similar to the one on hard disk.

Of course you will need to actually map the vhd in grub4dos, but since you have to map it anyway to patch it, you would avoid the unmapping.

 

Since you are using the "native" booting the grub4dos map will simply vanish as soon as the HAL kicks in, the "switch" should however happen right when the booting OS already can access the .vhd through its native driver.

 

:duff:

Wonko



#5 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1696 posts
  • Location:Nantes - France
  •  
    France

Posted A week ago

Hi,

 

This is a very interesting approach.

 

Thus, a few question :

-how confident are you that you will systematically find the same pattern in the hive file on other systems?

-how confident are you that you will not modify other parts of the hive file?

-is not the software protection service kicking in anyway a few mns after you have booted since the reg key will not match tokens.dat anymore? question remains, does the service monitor for change introduced by the user in the session or does it regurlarly compare hive vs tokens.dat?

 

Modifying the registry early in the boot process is definitely an interesting concept.

 

Regards,

Erwan



#6 agni

agni

    Frequent Member

  • Tutorial Writer
  • 244 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted A week ago

I am pretty confident about the pattern. however if the same pattern appears multiple times in the hive,then the code replaces the first occurence. So we need a better way to make sure we are modifying the right part of the hive.

This is no different from modifying the hive when it's offline. So everytime it has to be booted using the grub4dos menu. The software protection service is a delayed start service,so once it's starts,I assume it will immediately restore it.

#7 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1696 posts
  • Location:Nantes - France
  •  
    France

Posted A week ago

Ok I get it :

 

So the idea is modify the registry early in the booting process,

boot & and benefit from extra features (vhdboot, memory, ...), 

let the software protection do its job (restore registry) while still enjoying extra features (since we have booted with these features).

 

As a side note, for sometimes, I have been willing to develop a native command line registry editor (similar to reg.exe).

 

By native I mean using native ntdll.dll functions only and therefore launched before the win32 subsystem kicks in (i.e during the kernel initialization).

A bit similar to autochk.exe checking the filesystem.

 

There a few nativent "hello world" out there and the native api's are rather well documented so "in theory", it should be possible to develop a native reg.exe allowing one to modify the registry in a safe and friendly enough way (as opposed to patching bytes in the system hive).

 

The native binaries are called from HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\bootexecute and cannot be executed in a win32 environement (but only in native world).



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13221 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

Ok I get it :

 

So the idea is modify the registry early in the booting process,

boot & and benefit from extra features (vhdboot, memory, ...), 

let the software protection do its job (restore registry) while still enjoying extra features (since we have booted with these features).

 

As a side note, for sometimes, I have been willing to develop a native command line registry editor (similar to reg.exe).

 

By native I mean using native ntdll.dll functions only and therefore launched before the win32 subsystem kicks in (i.e during the kernel initialization).

A bit similar to autochk.exe checking the filesystem.

 

There a few nativent "hello world" out there and the native api's are rather well documented so "in theory", it should be possible to develop a native reg.exe allowing one to modify the registry in a safe and friendly enough way (as opposed to patching bytes in the system hive).

 

The native binaries are called from HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\bootexecute and cannot be executed in a win32 environement (but only in native world).

Actually there is also already a "native" Registry tool, see:

http://reboot.pro/to...egistry-editor/
https://www.codeproj...registry-editor

 

You could take from where Dan Madden left.

 

BUT - long before that - it would make more sense (to me at least) see if hivexsh or libreg can be made to run as a grub4dos program, or - even better - add the Registry as a filesystem to grub4dos, as was hinted here:
http://reboot.pro/to...ch-using-linux/

 

:duff:

Wonko:



#9 agni

agni

    Frequent Member

  • Tutorial Writer
  • 244 posts
  • Location:Bengaluru (Bangalore)
  •  
    India

Posted A week ago

Yes, that will definitely be useful. I would interested in such a native reg tool that can be used to modify the registry.
Let us know if you can develop such a tool. I am willing to contribute as well.

#10 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1696 posts
  • Location:Nantes - France
  •  
    France

Posted A week ago

Actually there is also already a "native" Registry tool, see:

http://reboot.pro/to...egistry-editor/
https://www.codeproj...registry-editor

 

You could take from where Dan Madden left.

 

BUT - long before that - it would make more sense (to me at least) see if hivexsh or libreg can be made to run as a grub4dos program, or - even better - add the Registry as a filesystem to grub4dos, as was hinted here:
http://reboot.pro/to...ch-using-linux/

 

:duff:

Wonko:

 

The Dan Maden example was definitely on my radar.

Thus it is meant for a win32 environement, i need to adapt it to a kernel environement.

 

Registry as a filesystem is a bit of the "graal" and has been mentionned a few times already on this forum :)



#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13221 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago

Registry as a filesystem is a bit of the "graal" and has been mentionned a few times already on this forum :)

Also:
https://github.com/jbruchon/winregfs

:duff:
Wonko

#12 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1696 posts
  • Location:Nantes - France
  •  
    France

Posted 2 days ago

Yes, that will definitely be useful. I would interested in such a native reg tool that can be used to modify the registry.
Let us know if you can develop such a tool. I am willing to contribute as well.

 

See here.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users