http://bugs.winehq.org/show_bug.cgi?id=23999
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation CC| |focht@gmx.net Component|-unknown |ntdll Summary|EMS SQL Manager 2010 Lite |EMS SQL Manager 2010 Lite |for PostgreSQL crashes |for PostgreSQL crashes |after 10 min |after 10 min (needs | |NtQueryVirtualMemory with | |MemorySectionName info | |class)
--- Comment #4 from Anastasius Focht focht@gmx.net 2010-08-17 14:16:19 --- Hello,
although that app seems to be protected by a commercial protection system it might be possible that "home-grown" code is the culprit here.
--- snip --- Scanning -> C:\Program Files\EMS\SQL Manager Lite for PostgreSQL\PgManager.exe File Type : 32-Bit Exe (Subsystem : Win GUI / 2), Size : 6485952 (062F7C0h) Byte(s) -> File Appears to be Digitally Signed @ Offset 062E200h, size : 015C0h / 05568 byte(s) -> File has 512 (0200h) bytes of appended data starting at offset 062E000h [File Heuristics] -> Flag : 00000000000001001100000000100110 (0x0004C026) [!] ASProtect SKE v2.3 - v2.5 detected ! --- snip ---
There is more than one bug present ... The first bug is an ntdll.NtQueryVirtualMemory(), MemorySectionName info class insufficiency (lookup image name by address).
There is a watch-guard thread (0x2d) that verifies that parts of the in-memory app PE image have not been modified (patched) by looking at disk image. Due to non-implemented MemorySectionName info class, it fails to do so hence another (error reporting) thread is spawned that goes haywire (which is in theory another bug).
--- snip --- ... 002b:Call KERNEL32.CreateThread(00000000,00000000,033d0000,03370000,00000000,00000000) ret=0336c015 002b:Ret KERNEL32.CreateThread() retval=00000078 ret=0336c015 ... 002d:Call ntdll.ZwDelayExecution(00000000,035de240) ret=033d1cab ... 002d:Ret ntdll.ZwDelayExecution() retval=00000000 ret=033d1cab 002d:Call KERNEL32.VirtualAlloc(00000000,00000014,00003000,00000004) ret=033d1cbc 002d:Ret KERNEL32.VirtualAlloc() retval=038e0000 ret=033d1cbc 002d:Call ntdll.RtlAllocateHeap(00110000,00000000,00000620) ret=033d2e65 002d:Ret ntdll.RtlAllocateHeap() retval=001c3128 ret=033d2e65 002d:Call ntdll.ZwQueryVirtualMemory(ffffffff,00400000,00000002,001c3128,0000030c,00000000) ret=033d2ea4 002d:fixme:virtual:NtQueryVirtualMemory (process=0xffffffff,addr=0x400000) Unimplemented information class: MemorySectionName 002d:Ret ntdll.ZwQueryVirtualMemory() retval=c0000003 ret=033d2ea4 002d:Call ntdll.RtlFreeHeap(00110000,00000000,001c3128) ret=033d3b85 002d:Ret ntdll.RtlFreeHeap() retval=00000001 ret=033d3b85 002d:Call KERNEL32.OpenThread(0000005a,00000000,0000002b) ret=033b3799 002d:Ret KERNEL32.OpenThread() retval=00000094 ret=033b3799 002d:Call KERNEL32.SuspendThread(00000094) ret=033b37bc 002d:Ret KERNEL32.SuspendThread() retval=00000000 ret=033b37bc 002d:Call KERNEL32.GetThreadContext(00000094,035dcf34) ret=033b37f3 002d:Ret KERNEL32.GetThreadContext() retval=00000001 ret=033b37f3 002d:Call KERNEL32.VirtualAlloc(00000000,0000000c,00003000,00000040) ret=033b3827 002d:Ret KERNEL32.VirtualAlloc() retval=038f0000 ret=033b3827 002d:Call KERNEL32.CreateThread(00000000,00000000,033c0000,038e0000,00000000,00000000) ret=033b387c 002d:Ret KERNEL32.CreateThread() retval=000000a4 ret=033b387c ... 002e:Starting thread proc 0x33c0000 (arg=0x38e0000) 002e:trace:seh:raise_exception code=c0000096 flags=0 addr=0x683f43cb ip=683f43cb tid=002e --- snip ---
If that MemorySectionName stuff gets implemented one day it could also be of help to psapi (GetMappedFileName).
Regards