https://bugs.winehq.org/show_bug.cgi?id=48993
Leith Bade leith@bade.nz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leith@bade.nz
--- Comment #1 from Leith Bade leith@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?