[Bug 5294] Morpheus crashes

Wine Bugs wine-bugs at winehq.org
Tue May 15 07:46:58 CDT 2007


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





------- Additional Comments From focht at gmx.net  2007-15-05 07:46 -------
Hello,

another interesting pick (i downloaded 5.4.x) :-)

--- quote ---
Does that mean the application is copyprotected? 
--- quote ---

Yes, a late ASProtect 2.x SKE version (http://www.aspack.com/asprotect.html).

The minor problem first: You have to use native msxml3 (winetricks), or it will
crash due to unsupported features.

The major problem is the exe protector itself.

It's a pain to debug this in wine due to the way the PEB->BeingDebugged flag is
managed in places critical to debuggers.
Although one of the simple ones (out of several anti debugging checks) it proves
to be annoying in wine environment.
If you simply reset the field (memory) to fool the protector the whole debugging
facility will break.
So patching some sources is the only way to get around (top level SEH and debug
events despite !BeingDebugged).
Ok i stop the little rant :-)

The application consists of two major components which are both protected by
AsProtect: morpheus.exe and M5Shell.dll
The dll proved to be problematic. An inproc ole server.
When i first rebuilt and run the main executable it crashed due to some class
interfaces not registered, probably belonging to M5Shell.dll.
Manually running "regsvr32 M5Shell.dll" failed (this self-register step failed
in setup too - silently)

When the dll is loaded and the initialization routines are run, the protector
decrypts several PE sections in memory.
One of them is the .rsrc section.
When the regsvr32 process calls DllRegisterServer, it tries to register its
interfaces by gathering data from .rsrc section (REGISTRY resource types).
This is done by explicit LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE flag set
and appropriate Find/LoadResource API.

Due to the way wine implements the LOAD_LIBRARY_AS_DATAFILE flag, it fails.
The dll is mapped as "data file" into memory (receives its own base address).
At that point all crucial PE sections are encrypted.
Remember: only when dll initializers are run, either by explicit entry or TLS
callbacks they get properly decrypted.
When Find/LoadResource is applied to the newly loaded dll it finds useless stuff
(of course the data is encrypted).
It dies then.

Offending code:

--- snip dlls/kernel32/module.c ---
static HMODULE load_library( const UNICODE_STRING *libname, DWORD flags )
{
    NTSTATUS nts;
    HMODULE hModule;
    WCHAR *load_path;

    if (flags & LOAD_LIBRARY_AS_DATAFILE)
    {
        /* The method in load_library_as_datafile allows searching for the
         * 'native' libraries only
         */
        if (load_library_as_datafile( libname->Buffer, &hModule )) return hModule;
        flags |= DONT_RESOLVE_DLL_REFERENCES; /* Just in case */
        /* Fallback to normal behaviour */
    }

    load_path = MODULE_get_dll_load_path( flags & LOAD_WITH_ALTERED_SEARCH_PATH
? libname->Buffer : NULL );
    nts = LdrLoadDll( load_path, flags, libname, &hModule );
    HeapFree( GetProcessHeap(), 0, load_path );
    if (nts != STATUS_SUCCESS)
    {
        hModule = 0;
        SetLastError( RtlNtStatusToDosError( nts ) );
    }
    return hModule;
}
--- snip dlls/kernel32/module.c ---

To work around this problem, LOAD_LIBRARY_AS_DATAFILE shall not use
load_library_as_datafile() (CreateFileMappingW/MapViewOfFile).

A quick fix is to comment out "if (load_library_as_datafile( libname->Buffer,
&hModule )) return hModule;" to fall back to standard loader mechanism (of
course imports are already resolved and init routines are run).
That way the application/protector can find its resources and succeed.

With that patch applied, morpheus starts up fine.

There are many applications in the wild which use ASPack/ASProtect and other
protectors which encrypt resource/data sections.
So this information probably applies to other bug reports too.

Regards

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the wine-bugs mailing list