[Bug 48993] 64-bit Powershell 2.0 for Windows 2003 installer fails due to missing 'scecli.dll'

WineHQ Bugzilla wine-bugs at winehq.org
Thu Apr 23 00:03:11 CDT 2020


https://bugs.winehq.org/show_bug.cgi?id=48993

Leith Bade <leith at bade.nz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |leith at bade.nz

--- Comment #1 from Leith Bade <leith at bade.nz> ---
Did some poking into this yesterday. After adding the scecli.dll file from the
Windows 7 SP1 installer, further relay tracing reveals that the particular
function update.exe wants is SceConfigureSystem:
--- snip ---
002d:Call KERNEL32.LoadLibraryW(100024908 L"scecli.dll") ret=1000a2524
...
002d:Ret  KERNEL32.LoadLibraryW() retval=64200000 ret=1000a2524
002d:Call KERNEL32.GetProcAddress(64200000,1000248f0 "SceConfigureSystem")
ret=1000a2540
002d:Ret  KERNEL32.GetProcAddress() retval=6420100c ret=1000a2540
--- snip ---

update.exe then continues to generate a temporary file:
002d:Call KERNEL32.GetWindowsDirectoryW(0022a6e0,00000104) ret=1000a255c
002d:Ret  KERNEL32.GetWindowsDirectoryW() retval=0000000a ret=1000a255c
002d:Call KERNEL32.GetTempFileNameW(0022a6e0 L"C:\\windows",1000248e8
L"SEC",00000000,0022a8f0) ret=1000a2579
...
002d:Ret  KERNEL32.GetTempFileNameW() retval=00007b26 ret=1000a2579
002d:Call KERNEL32.CreateFileW(0022a8f0
L"C:\\windows\\SEC7b26.tmp",40000000,00000001,00000000,00000004,00000080,00000000)
ret=1000a25a7
...
002d:Ret  KERNEL32.CreateFileW() retval=00000080 ret=1000a25a7
002d:Call KERNEL32.WriteFile(00000080,1000243b0,00000069,0022a6d8,00000000)
ret=1000a2675
...
002d:Ret  KERNEL32.WriteFile() retval=00000001 ret=1000a2675
002d:Call KERNEL32.WriteFile(00000080,009e2050,00000021,0022a680,00000000)
ret=1000a1d21
...
002d:Ret  KERNEL32.WriteFile() retval=00000001 ret=1000a1d21
002d:Call KERNEL32.WriteFile(00000080,100024778,00000013,0022a018,00000000)
ret=1000a2095
...
002d:Ret  KERNEL32.WriteFile() retval=00000001 ret=1000a2095
...
002d:Ret  KERNEL32.CloseHandle() retval=00000001 ret=1000a26ed
002d:Call msvcrt._vsnwprintf(0022ad10,00000103,100024850
L"%s\\security\\database\\%s.sdb",0022a688) ret=1000a1f3b
002d:Ret  msvcrt._vsnwprintf() retval=00000029 ret=1000a1f3b
002d:Call msvcrt._vsnwprintf(0022ab00,00000103,100024820
L"%s\\security\\logs\\%s.log",0022a688) ret=1000a1f3b
002d:Ret  msvcrt._vsnwprintf() retval=00000023 ret=1000a1f3b
...
002d:Call KERNEL32.DeleteFileW(0022a8f0 L"C:\\windows\\SEC7b26.tmp")
ret=1000a25eb
...
002d:Ret  KERNEL32.DeleteFileW() retval=00000001 ret=1000a25eb
002d:Call KERNEL32.FreeLibrary(64200000) ret=1000a2609
...
002d:Ret  ntdll.LdrUnloadDll() retval=00000000 ret=7b01da92
002d:Ret  KERNEL32.FreeLibrary() retval=00000001 ret=1000a2609
-- snip ---

This file appears to be a security policy template file (which the various
Windows security tools can import and export) which changes the permissions on
various registry keys:
--- snip ---
[Unicode]
Unicode=yes
[Version]
signature="$CHICAGO$"
Revision=1
[Profile Description]
Description=Windows Management Framework Core
[Registry Keys]
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Listener",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Plugin",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Service",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Client",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\CertMapping",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\WinRS",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\WinRS\CustomRemoteShell",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\EventCollector",2,"D:(A;CI;GA;;;BA)(A;CI;GA;;;NS)"
--- snip ---

As for where these values come from it appears update.exe searches for various
special sections in the update.inf file:
--- snip ---
002d:Call setupapi.SetupFindFirstLineA(0081b5a0,1000146a8
"SecurityRegistryAfterInstall",00000000,0022af50) ret=1000a232a
...
002d:Call setupapi.SetupFindFirstLineA(0081b5a0,100014688
"SecurityFileAfterInstall",00000000,0022af50) ret=1000a232a
...
002d:Call setupapi.SetupFindFirstLineA(0081b5a0,100014668
"SecurityServiceAfterInstall",00000000,0022af50) ret=1000a232a
--- snip ---

Having a look at the update.inf reveals there is a SecurityRegistryAfterInstall
section:
--- snip ---
...
[SecurityRegistryAfterInstall] 
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Listener",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Plugin",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Service",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\Client",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\CertMapping",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;NS)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\WinRS",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
"MACHINE\Software\Microsoft\Windows\CurrentVersion\WSMAN\WinRS\CustomRemoteShell",2,"D:P(A;CI;GA;;;BA)(A;CI;GR;;;WD)S:P(AU;CISAFA;GW;;;WD)"
...
[SecurityRegistryAfterInstall]
"MACHINE\Software\Microsoft\Windows\CurrentVersion\EventCollector",2,"D:(A;CI;GA;;;BA)(A;CI;GA;;;NS)"
...
-- snip --

So it appears the purpose of calling SceConfigureSystem is to apply some
security changes to new files or registry keys or services. However it seems
the function itself does not make changes to the system. On a real Windows
machine it looks like there is an RPC service called scesrv.dll that must
actually apply the changes.

Google revealed a file that indicates SceConfigureSystem possibly takes 8
parameters -
https://github.com/tonado/MASM32-SDK/blob/master/include/scecli.inc

So I created a stub function and got this from the relay trace after deducing
three parameters are strings:
--- snip ---
002d:Call scecli.SceConfigureSystem(00000000,0022a8f0
L"C:\\windows\\SEC7b26.tmp",0022ad10
L"C:\\windows\\security\\database\\KB968930.sdb",0022ab00
L"C:\\windows\\security\\logs\\update.log",100000012,000000e0,00000000,00000000,00000000)
ret=1000a2780
...
0x00000000 L"C:\\windows\\SEC7b26.tmp"
L"C:\\windows\\security\\database\\KB968930.sdb"
L"C:\\windows\\security\\logs\\update.log" 0x00000012 0x000000e0 0x00000000
0x00000000 0x00000000: stub
...
002d:Ret  scecli.SceConfigureSystem() retval=00000000 ret=1000a2780
--- snip ---

The first parameter is always zero, perhaps this is an optional pointer or
handle to something.
The second is the path to the security template file to apply.
The third appears to be a path to a security database file to write out. It
seems this is the main file used for security policies in Windows, e.g. the
default system settings are in C:\windows\security\secedit.sdb. It's purpose
here might to be save the changes made by the installer so that they can be
reversed during uninstallation.
The fourth appears to be a path to a log file.
The fifth value appears to be set to 12h.
The sixth value appears to always be set to e0h.

A zero return value appears sufficient to satisfy update.exe and allows it to
finish.

It seems adding a stub function will be enough to fix this bug. Is there a way
to verify the number of arguments on the stack expected by SceConfigureSystem?
Similarly is there a way to know if the remaining arguments should be treated
as pointers, or as integers?

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.



More information about the wine-bugs mailing list