[Bug 23999] EMS SQL Manager 2010 Lite for PostgreSQL crashes after 10 min (needs NtQueryVirtualMemory with MemorySectionName info class)

wine-bugs at winehq.org wine-bugs at winehq.org
Tue Aug 17 14:16:21 CDT 2010


http://bugs.winehq.org/show_bug.cgi?id=23999


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |obfuscation
                 CC|                            |focht at 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 at 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

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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