[Bug 33236] Multiple application virtualization schemes rely on LdrLoadDll to behave like native Windows loader (NtOpenFile, NtXXXSection) (VMWare ThinApp 4.x, BoxedApp)
wine-bugs at winehq.org
wine-bugs at winehq.org
Thu May 29 13:05:16 CDT 2014
https://bugs.winehq.org/show_bug.cgi?id=33236
Anastasius Focht <focht at gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Bible Converter Project |Multiple application
|fails to convert anything |virtualization schemes rely
|(VMWare ThinApp 4.x, Wine's |on LdrLoadDll to behave
|LdrLoadDll doesn't behave |like native Windows loader
|like native, needs to call |(NtOpenFile, NtXXXSection)
|NtXXXSection API) |(VMWare ThinApp 4.x,
| |BoxedApp)
--- Comment #6 from Anastasius Focht <focht at gmx.net> ---
Hello folks,
revisiting, still present.
'BoxedApp' virtualization scheme (bug 22797 has some examples) also suffers
from this.
Download: http://www.download3k.ru/DownloadLink1-BoxedApp-SDK.html
The 'Sample1_DLLEmbedding.exe' example app crashes after clicking the 'call
function' button
The 'BoxedApp' application virtualization scheme hooks a large number of native
API:
--- snip ---
"NtOpenFile"
"NtCreateFile"
"NtWriteFile"
"NtReadFile"
"NtDeleteFile"
"NtSetInformationFile"
"NtQueryInformationFile"
"NtClose"
"NtCreateSection"
"NtOpenSection"
"NtFlushVirtualMemory"
"NtQueryAttributesFile"
"NtSetSecurityObject"
"NtMapViewOfSection"
"NtQueryVirtualMemory"
"NtQuerySection"
"NtUnmapViewOfSection"
"NtDuplicateObject"
"NtQueryFullAttributesFile"
"NtQueryVolumeInformationFile"
"NtSetVolumeInformationFile"
"NtQueryDirectoryFile"
"NtLockFile"
"NtUnlockFile"
"NtFlushBuffersFile"
"NtFsControlFile"
"NtNotifyChangeDirectoryFile"
"NtWaitForSingleObject"
"NtWaitForMultipleObjects"
"NtExtendSection"
"NtCreateKey"
"NtDeleteKey"
"NtDeleteValueKey"
"NtEnumerateKey"
"NtEnumerateValueKey"
"NtFlushKey"
"NtLoadKey"
"NtLoadKey2"
"NtNotifyChangeKey"
"NtOpenKey"
"NtOpenKeyEx"
"NtQueryKey"
"NtQueryMultipleValueKey"
"NtQueryValueKey"
"NtReplaceKey"
"NtRestoreKey"
"NtSaveKey"
"NtSetInformationKey"
"NtSetValueKey"
"NtUnloadKey"
"NtRenameKey"
"CreateActCtxW"
"NtQueryObject"
"RtlQueryInformationActivationContext"
"LdrGetDllFullName"
"CreateProcessA"
"CreateProcessW"
"CreateProcessAsUserW"
"WinExec"
"LdrLoadDll"
"LdrUnloadDll"
"NtQueryInformationProcess"
"NtQuerySecurityObject"
"NtAccessCheck"
"CoRegisterClassObject"
"CoRevokeClassObject"
"CoFreeUnusedLibraries"
"CoCreateInstance"
"CoCreateInstanceEx"
"CoGetClassObject"
"CoRegisterSurrogate"
"EncryptFileW"
"DecryptFileW"
--- snip ---
Example: original entry point 'ntdll.LdrLoadDll'
--- snip ---
7BC57D4B 8BFF MOV EDI,EDI
7BC57D4D 55 PUSH EBP
7BC57D4E 8BEC MOV EBP,ESP
7BC57D50 5D POP EBP
7BC57D51 8D4C24 04 LEA ECX,DWORD PTR SS:[ESP+4]
7BC57D55 83E4 F0 AND ESP,FFFFFFF0
7BC57D58 FF71 FC PUSH DWORD PTR DS:[ECX-4]
7BC57D5B 55 PUSH EBP
7BC57D5C 89E5 MOV EBP,ESP
7BC57D5E 56 PUSH ESI
7BC57D5F 53 PUSH EBX
7BC57D60 51 PUSH ECX
7BC57D61 83EC 2C SUB ESP,2C
7BC57D64 E8 A76DFCFF CALL ntdll.__x86.get_pc_thunk.bx
...
--- snip ---
With trampoline:
--- snip ---
7BC57D4B E9 B08267FF JMP 7B2D0000
7BC57D50 5D POP EBP
7BC57D51 8D4C24 04 LEA ECX,DWORD PTR SS:[ESP+4]
7BC57D55 83E4 F0 AND ESP,FFFFFFF0
7BC57D58 FF71 FC PUSH DWORD PTR DS:[ECX-4]
7BC57D5B 55 PUSH EBP
7BC57D5C 89E5 MOV EBP,ESP
7BC57D5E 56 PUSH ESI
7BC57D5F 53 PUSH EBX
7BC57D60 51 PUSH ECX
7BC57D61 83EC 2C SUB ESP,2C
7BC57D64 E8 A76DFCFF CALL ntdll.__x86.get_pc_thunk.bx
...
--- snip ---
'BoxedApp' scheme tries to place the thunks near the dll being hooked:
--- snip ---
...
0023:Call KERNEL32.LoadLibraryA(100c2470 "ntdll.dll") ret=10001480
0023:Ret KERNEL32.LoadLibraryA() retval=7bc10000 ret=10001480
...
0023:Call KERNEL32.GetSystemInfo(0033f6ac) ret=1000115b
0023:Ret KERNEL32.GetSystemInfo() retval=0033f6ac ret=1000115b
...
0023:Call KERNEL32.VirtualQuery(7bc216dc,0033f6d0,0000001c) ret=10001179
0023:Ret KERNEL32.VirtualQuery() retval=0000001c ret=10001179
0023:Call KERNEL32.VirtualAlloc(7bce0000,00000005,00002000,00000040)
ret=100011d4
0023:Ret KERNEL32.VirtualAlloc() retval=00000000 ret=100011d4
0023:Call KERNEL32.VirtualAlloc(7bcd0000,00000005,00002000,00000040)
ret=100011d4
0023:Ret KERNEL32.VirtualAlloc() retval=00000000 ret=100011d4
...
0023:Call KERNEL32.VirtualAlloc(7b2e0000,00000005,00002000,00000040)
ret=100011d4
0023:Ret KERNEL32.VirtualAlloc() retval=00000000 ret=100011d4
0023:Call KERNEL32.VirtualAlloc(7b2d0000,00000005,00002000,00000040)
ret=100011d4
0023:Ret KERNEL32.VirtualAlloc() retval=7b2d0000 ret=100011d4
0023:Call KERNEL32.VirtualAlloc(7b2d0000,00000005,00001000,00000040)
ret=100011f8
0023:Ret KERNEL32.VirtualAlloc() retval=7b2d0000 ret=100011f8
0023:Call ntdll.RtlMoveMemory(00592716,0033f698,00000004) ret=10001231
0023:Ret ntdll.RtlMoveMemory() retval=00592716 ret=10001231
0023:Call ntdll.RtlMoveMemory(7b2d0001,0033f698,00000004) ret=10001254
0023:Ret ntdll.RtlMoveMemory() retval=7b2d0001 ret=10001254
...
0023:Call KERNEL32.VirtualAlloc(7b2c0000,0000000b,00002000,00000040)
ret=100012df
0023:Ret KERNEL32.VirtualAlloc() retval=7b2c0000 ret=100012df
0023:Call KERNEL32.VirtualAlloc(7b2c0000,0000000b,00001000,00000040)
ret=10001306
0023:Ret KERNEL32.VirtualAlloc() retval=7b2c0000 ret=10001306
0023:Call ntdll.RtlZeroMemory(0033f6ec,00000016) ret=10023d70
0023:Ret ntdll.RtlZeroMemory() retval=0033f6ec ret=10023d70
0023:Call ntdll.RtlMoveMemory(0033f65c,7bc216dc,0000000f) ret=10023f01
0023:Ret ntdll.RtlMoveMemory() retval=0033f65c ret=10023f01
0023:Call ntdll.RtlZeroMemory(0033f66c,00000016) ret=10023d70
0023:Ret ntdll.RtlZeroMemory() retval=0033f66c ret=10023d70
0023:Call ntdll.RtlMoveMemory(7b2c0000,0033f65c,00000001) ret=10023f9c
0023:Ret ntdll.RtlMoveMemory() retval=7b2c0000 ret=10023f9c
0023:Call ntdll.RtlZeroMemory(0033f6ec,00000016) ret=10023d70
0023:Ret ntdll.RtlZeroMemory() retval=0033f6ec ret=10023d70
0023:Call ntdll.RtlMoveMemory(0033f65c,7bc216dd,0000000f) ret=10023f01
0023:Ret ntdll.RtlMoveMemory() retval=0033f65c ret=10023f01
0023:Call ntdll.RtlZeroMemory(0033f66c,00000016) ret=10023d70
0023:Ret ntdll.RtlZeroMemory() retval=0033f66c ret=10023d70
0023:Call ntdll.RtlMoveMemory(7b2c0001,0033f65c,00000005) ret=10023f9c
0023:Ret ntdll.RtlMoveMemory() retval=7b2c0001 ret=10023f9c
0023:Call ntdll.RtlMoveMemory(7b2c0007,0033f698,00000004) ret=1000137a
0023:Ret ntdll.RtlMoveMemory() retval=7b2c0007 ret=1000137a
0023:Call KERNEL32.FlushInstructionCache(ffffffff,7b2c0000,0000000b)
ret=10001390
0023:Ret KERNEL32.FlushInstructionCache() retval=00000001 ret=10001390
--- snip ---
Intermediate thunk to native hook dispatcher:
--- snip ---
7B2D0000 E9 1B0AD494 JMP bxsdk32.10010A20
7B2D0005 0000 ADD BYTE PTR DS:[EAX],AL
--- snip ---
The continuation thunk (called from dispatcher):
--- snip ---
7B2C0000 8BFF MOV EDI,EDI
7B2C0002 55 PUSH EBP
7B2C0003 8BEC MOV EBP,ESP
7B2C0005 E9 467D9900 JMP ntdll.7BC57D50
7B2C000A 0000 ADD BYTE PTR DS:[EAX],AL
7B2C000C 0000 ADD BYTE PTR DS:[EAX],AL
--- snip ---
Similar to 'VMWare ThinApp', this virtualization scheme also expects calls to
NtOpenFile and NtCreateSection during module load sequence (see
http://msdn.microsoft.com/en-us/magazine/cc301727.aspx).
Having those (hooked) API called allows the virtualizer to map the dll from its
own internal resources.
Wine doesn't call those API, see internal 'load_dll'.
$ sha1sum boxedappsdk__demo__3_3_5_7.zip
bfbdd0df4526cd34615a8d13a788a6cdc8713041 boxedappsdk__demo__3_3_5_7.zip
$ du -sh boxedappsdk__demo__3_3_5_7.zip
25M boxedappsdk__demo__3_3_5_7.zip
$ wine --version
wine-1.7.19-70-gd6a59f7
Regards
--
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