@dosibox :
le GUID 492350f6-3a01-4f97-b9c0-c7c6ddf67d60 dans l'URL indique que c''est du CC (Current Chnanel).
Sorti de son contexte, "slshim" ne veut rien dire. A part si SL est une abréviation => "System Licensing Shim" ?
Pas compris ta question sur le shim car c'est toi qui a parlé de ohook ?
cf. Windows 10 Trial Watermark
Si tu ne connais pas le langage C n'as jamais de développement système, je doute que tu psuisses comprendre...
Code : Tout sélectionner
How to use slshim
-----------------
Replace slc.dll, sppc.dll, slcext.dll, sppcext.dll and slwga.dll with
appropiate 32/64 bit version of SLShim. After a reboot, windows is
completely cut off from sppsvc - which may scream about it internally,
so you may as well disable it.
Some software, such as Office carries its own copy of sppsvc called
'osppsvc' .. usually found at
%CommonProgramFiles%\Microsoft shared\OfficeSoftwareProtectionPlatform
just replace dll in there with slshim if you don't want to install it
system-wide.
SLShim also runs as a background service to keep kernel policy
cache in sync with our overrides. This service is non-vital if you
don't plan to further tinker with those values, ie after first reboot
when the crtical values are synced, you can manually disable it.
All of the above is configured automatically by the 'install.bat' script, but
the architecture is modular. In particular:
* You can run only the slshim service. It will configure kernel policies, and
nothing else.
* You can replace only office dll.
* It is not recommended to replace just "some" of the 5 files under
Windows\system32. While SLShim is designed to not crash stuff under such
circumstance, it will generally not function as intended (the non-replaced
apis will simply claim the SL service is not available at all).
How to configure SLShim[code]
-----------------------
[HKEY_LOCAL_MACHINE\SYSTEM\Tokens]
----------------------------------
This is the general token configuration used to answer SLGetApplicationPolicy
queries, so called feature killbits. Some tools, such as rdpwrap spoof these
value in process - we do it globally.
Typically, the values are answered 1:1 to template in the registry, but there
are some fields with special meaning:
1) APPids and SKUs
------------------
Generally, SLShim tries to come up with some garbage and throw it at the
API user. This does not always work (office). In that case we need to
precisely list APPID associated SKUID explicitly:
{APPID} = REG_MULTI_SZ {skuid}, {skuid}....
Usually, you need only one SKU per APPID, but occasionaly you may need to
add another (it is a REG_MULTI_SZ) to enable certain feature identified by
that SKU.
2) Wildcards and deadbeef
-------------------------
To avoid enumerating every possible policy setting, we can set a wildcard,
for example:
"office-*"=dword:00000001
Will answer anything matching this pattern with said DWORD. Most of policies
are simple boolean flags "is this feature enabled?" naturally, we answer
yes to everything. This is not always desirable though, Sometimes we want
to answer that the value simply does not exist:
"office-IsPhoneOnly"=dword:deadbeef
(answering 1 would conflict with other settings and the software won't start).
Naturally, exact matches take precedence over wildcard. More generally,
longest match has the highest precedence (in case you set up multiple
layers of wildcard).
Back to dword:deadbeef, it is a special marker - it forces the API to
answer 'nope, this policy does not exist', regardless of wildcard.
This is because we don't actually know the correct value expected,
and API trace shows that indeed, the value does not exist in common
SKU certificates.
Both wildcards and deadbeef is important to discover proper policies
expected by the API user.
3) Populate=DWORD:1
This keyword is not a policy, but a flag used by SLShim itself to
enable API tracing.
If it's set to non-0, whenever a wildcard is matched, all the policy
names asked and values we answered (ie the value from wildcard) will be
written into registry:
"office-30CAC893-3CA4-494C-A5E9-A99141352216"=dword:00000001
"office-AppPrivilege.ProEE-DRM"=dword:00000001
"office-AppPrivilege.ProXML"=dword:00000001
"office-AppPrivilege.VisioDataFeature"=dword:00000001
"office-AppPrivilege.ProEE-Classify"=dword:00000001
.... ton of others
This is useful so you can easily find out which policy is "poison".
Now you can keep assigning 'deadbeef' to those entries, one by one or in
bunch until stuff starts working. Finally you pin point exact 'poison' entries.
It is not recommended to remove the wildcard, as new entries will start
appearing while you're doing this (it's called bisecting). Software asks
for different policies depending on currently presented policies.
Eventually, this is how I found about the dozen of values which can't be
simply DWORD 1 for office 2016:
for example:
"office-PreviewExpireDate"=dword:deadbeef
"office-TrialType"=dword:deadbeef
"office-DemoMode"=dword:deadbeef
"office-DisallowPhone"=dword:deadbeef
Many are self-explanatory. For something entirely new you have no idea
about, you may need to set pure wildcard, for example '*'=dword:deadbeef
(ie log asked entries, but claim those dont exist). And gradually twak it.
And beware, software using ClickToRun uses split-view registry. That is,
all writes are redirected to private registry space, for example:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\SYSTEM\Tokens
This is where the results of 'Populate' may appear, instead of being dumped
into HKLM\SYSTEM\Tokens.
ClickToRun first tries to read value from this space, and if it does not
succeed, it tries the original HKLM\System\...
[HKEY_LOCAL_MACHINE\SYSTEM\Tokens\Kernel]
-----------------------------------------
This key contains "core windows" policy overrides - things which make windows
different between editions. Partial documentation of values found in there can
be found at:
http://www.geoffchappell.com/notes/windows/license/install.htm
http://forums.mydigitallife.info/threads/39411-Windows-Product-Policy-Editor
Changes apply in real time for most value queries made via
SLGetWindowsInformation - which most of windows does, but not all -
Some windows components ask the kernel cache directly about policy settings
they bypass the usual SPPSVC API we hook into. As well as kernel itself consults
its cache for values it needs - such as Kernel-WindowsMaxMemAllowedx86 (PAE).
Such fields are generally prefixed 'kernel-*', but this is not consistent. For
example 'WSLicensingService-EnableLOBApps' (enable metro sideloading) is
through obfuscated kernel API, again, directly bypassing SPPSVC API of ours.
Hilariously, notepad does this too, through inconspicuous call
to WinSqmIncrementDWORD which totally is not just:
SLGetWindowsInformationDWORD('Security-SPP-GenuineLocalStatus')
Good one, Bill.
With win8 onwards, these calls are heavily obfuscated and difficult to emulate
(search MDL for codename 'WARBIRD'). This is why we simply convince kernel
of values of our choice, so everything works as "usual".
We do this by reflecting our overrides back into the persistent kernel cache
which gets loaded on boot (ProductOptions). Contrary to popular belief, it's
not necessary to boot into WinPE to do that, just edit stuff and simple reboot
suffices.
How the cache works exactly:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions
ProductPolicy=BINARY .... big blob
This big blob is just encoded tokens you see under SYSTEM\Tokens\Kernel.
Whenever you change value under \Kernel, it will be updated back into
ProductOptions.
Underscores
-----------
You'll see most of entries in \Kernel ending with underscore - '_'. These
entries are purely informational, are never used, and dumped into the registry
so that we know what policies the kernel cache currently knows about. Once you
find some field in there you want to override, simply remove the underscore
and the value becomes active.
This is a bit similiar to the Populate DWORD, but different in that the dumped
values never interfere with the policies in kernel by default. It would be
dangerous to have those values 'frozen', as certain windows subsystems expect
these entries to be variable, especially kernel components of sppsvc/clipsvc.
seulement 50 % de corrigé 
), y compris des explications claires (e.g. genuine verfication).