search

DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.63k stars 557 forks source link

Error loading a client in Windows 7 using python27.dll #1866

Open 0ca opened 8 years ago

0ca commented 8 years ago

Hi,

I am trying to develop a DynamoRio client that exports a python API for Windows. Like this: https://github.com/JonathanSalwan/Triton/tree/master/src/tracer/pin

But I am having problems using the python library in a DynamoRio client.

I modified the bbcount.c example to include and call one function of python:

#include <stddef.h> /* for offsetof */
#include "dr_api.h"
#include "drmgr.h"
#include "drreg.h"
#include <Python.h>

#ifdef WINDOWS
# define DISPLAY_STRING(msg) dr_messagebox(msg)
#else
# define DISPLAY_STRING(msg) dr_printf("%s\n", msg);
#endif

#define NULL_TERMINATE(buf) buf[(sizeof(buf)/sizeof(buf[0])) - 1] = '\0'

#define TESTALL(mask, var) (((mask) & (var)) == (mask))
#define TESTANY(mask, var) (((mask) & (var)) != 0)

/* we only have a global count */
static int global_count;

#ifdef SHOW_RESULTS
/* some meta-stats: static (not per-execution) */
static int bbs_eflags_saved;
static int bbs_no_eflags_saved;
#endif

static void
event_exit(void)
{
#ifdef SHOW_RESULTS
    char msg[512];
    int len;
    len = dr_snprintf(msg, sizeof(msg)/sizeof(msg[0]),
                      "Instrumentation results:\n"
                      "%10d basic block executions\n"
                      "%10d basic blocks needed flag saving\n"
                      "%10d basic blocks did not\n",
                      global_count, bbs_eflags_saved, bbs_no_eflags_saved);
    DR_ASSERT(len > 0);
    NULL_TERMINATE(msg);
    DISPLAY_STRING(msg);
#endif /* SHOW_RESULTS */
    drreg_exit();
    drmgr_exit();
}

static dr_emit_flags_t
event_app_instruction(void *drcontext, void *tag, instrlist_t *bb, instr_t *inst,
                      bool for_trace, bool translating, void *user_data)
{
#ifdef SHOW_RESULTS
    bool aflags_dead;
#endif

    if (!drmgr_is_first_instr(drcontext, inst))
        return DR_EMIT_DEFAULT;

#ifdef VERBOSE
    dr_printf("in dynamorio_basic_block(tag="PFX")\n", tag);
# ifdef VERBOSE_VERBOSE
    instrlist_disassemble(drcontext, tag, bb, STDOUT);
# endif
#endif

#ifdef SHOW_RESULTS
    if (drreg_are_aflags_dead(drcontext, inst, &aflags_dead) == DRREG_SUCCESS &&
        !aflags_dead)
        bbs_eflags_saved++;
    else
        bbs_no_eflags_saved++;
#endif

    /* We demonstrate how to use drreg for aflags save/restore here.
     * We could use drx_insert_counter_update instead of drreg.
     * Xref sample opcodes.c as an example of using drx_insert_counter_update.
     */
    if (drreg_reserve_aflags(drcontext, bb, inst) != DRREG_SUCCESS)
        DR_ASSERT(false && "fail to reserve aflags!");
    /* racy update on the counter for better performance */
    instrlist_meta_preinsert
        (bb, inst,
         INSTR_CREATE_inc(drcontext, OPND_CREATE_ABSMEM
                          ((byte *)&global_count, OPSZ_4)));
    if (drreg_unreserve_aflags(drcontext, bb, inst) != DRREG_SUCCESS)
        DR_ASSERT(false && "fail to unreserve aflags!");

#if defined(VERBOSE) && defined(VERBOSE_VERBOSE)
    dr_printf("Finished instrumenting dynamorio_basic_block(tag="PFX")\n", tag);
    instrlist_disassemble(drcontext, tag, bb, STDOUT);
#endif
    return DR_EMIT_DEFAULT;
}

DR_EXPORT void
dr_client_main(client_id_t id, int argc, const char *argv[])
{
    if (argc ==3)  //So it is never called
        PyCallable_Check(NULL);
    drreg_options_t ops = {sizeof(ops), 1 /*max slots needed: aflags*/, false};
    dr_set_client_name("DynamoRIO Sample Client 'bbcount'",
                       "http://dynamorio.org/issues");
    if (!drmgr_init() || drreg_init(&ops) != DRREG_SUCCESS)
        DR_ASSERT(false);

    /* register events */
    dr_register_exit_event(event_exit);
    if (!drmgr_register_bb_instrumentation_event(NULL, event_app_instruction, NULL))
        DR_ASSERT(false);

    /* make it easy to tell, by looking at log file, which client executed */
    dr_log(NULL, LOG_ALL, 1, "Client 'bbcount' initializing\n");
#ifdef SHOW_RESULTS
    /* also give notification to stderr */
    if (dr_is_notify_on()) {
# ifdef WINDOWS
        /* ask for best-effort printing to cmd window.  must be called at init. */
        dr_enable_console_printing();
# endif
        dr_fprintf(STDERR, "Client bbcount is running\n");
    }
#endif
}

And after this change the client is not working anymore: drrun.exe -c ..\samples\bin\bbcount.dll -- notepad.exe

I get the following error:

Application C:\Windows\System32\notepad.exe (1160). 
Unable to load client library: bbcount.dll 
Unable to locate imports of client library.

It seeems that DynamoRio has some problems loading python27.dll.

A very similar unsolved error: https://groups.google.com/forum/embed/#!topic/dynamorio-users/YfsrzBoNpPw

I think these error in the log are the most representative:

privload_process_imports: unable to load import lib SHELL32.dll
privload_load_finalize: failed to process imports python27.dll

The log generated:

global log file fd=88
DynamoRIO version 6.1.0, build 6, (c) DynamoRIO developers
Running: C:\Windows\system32\arp.exe
App cmdline: arp.exe
DynamoRIO built with: -DINTERNAL -DDEBUG -DDRSTATS_DEMO -DX86 -DX64 -DWINDOWS -DCLIENT_INTERFACE -DAPP_EXPORTS -DKSTATS -DANNOTATIONS -DNOLIBC -DASSEMBLE_WITH_MASM -DHAVE_MEMINFO -DHAVE_MEMINFO_QUERY -DWINDOWS_PC_SAMPLE -DDYNAMORIO_IR_EXPORTS -DCUSTOM_TRACES -DCLIENT_SIDELINE -DDR_APP_EXPORTS -DDEBUG_MEMORY -DSTACK_GUARD_PAGE -DHEAP_ACCOUNTING -DDEADLOCK_AVOIDANCE -DSHARING_STUDY -DHASHTABLE_STATISTICS
DynamoRIO built on: Feb  1 2016 23:48:46
DYNAMORIO_OPTIONS: -code_api -probe_api "-loglevel" "2" -client_lib "C:\Users\default.WIN-18AK2O7UHSG\Downloads\DynamoRIO-Windows-6.1.0-RC1\DynamoRIO-Windows-6.1.0-RC1\samples\bin\bbcount.dll;0;"
...
After removing, module lists are:
PEB LoaderData:
    Length = 88
    Initialized = 1
    SsHandle = 0x0000000000000000
InLoadOrder:
    0  0x00000000ff160000 0x00000000ff16417c 0xa000 C:\Windows\system32\arp.exe arp.exe
    1  0x00000000773a0000 0x0000000000000000 0x1a9000 C:\Windows\SYSTEM32\ntdll.dll ntdll.dll
    2  0x0000000077180000 0x0000000077195ea0 0x11f000 C:\Windows\system32\kernel32.dll kernel32.dll
    3  0x000007fefd630000 0x000007fefd6330e0 0x6b000 C:\Windows\system32\KERNELBASE.dll KERNELBASE.dll
    4  0x000007fefef80000 0x000007fefef825a0 0x9f000 C:\Windows\system32\msvcrt.dll msvcrt.dll
    5  0x000007fef9a70000 0x000007fef9a75390 0xb000 C:\Windows\system32\snmpapi.dll snmpapi.dll
    6  0x000007fefdf50000 0x000007fefdf51070 0x4d000 C:\Windows\system32\WS2_32.dll WS2_32.dll
    7  0x000007feff470000 0x000007feff4bed50 0x12d000 C:\Windows\system32\RPCRT4.dll RPCRT4.dll
    8  0x000007fefee10000 0x000007fefee11504 0x8000 C:\Windows\system32\NSI.dll NSI.dll
    9  0x000007fefdae0000 0x000007fefdb00760 0xdb000 C:\Windows\system32\ADVAPI32.dll ADVAPI32.dll
    10  0x000007fefe040000 0x000007fefe0460e8 0x1f000 C:\Windows\SYSTEM32\sechost.dll sechost.dll
    11  0x000007fefb150000 0x000007fefb1598bc 0x27000 C:\Windows\system32\IPHLPAPI.DLL IPHLPAPI.DLL
    12  0x000007fefb100000 0x000007fefb101198 0xb000 C:\Windows\system32\WINNSI.DLL WINNSI.DLL
    13  0x00000000772a0000 0x00000000772ba2c8 0xfa000 C:\Windows\system32\USER32.dll USER32.dll
    14  0x000007feff020000 0x000007feff02b03c 0x67000 C:\Windows\system32\GDI32.dll GDI32.dll
    15  0x000007feff090000 0x000007feff091080 0xe000 C:\Windows\system32\LPK.dll LPK.dll
    16  0x000007feff300000 0x000007feff37a874 0xc9000 C:\Windows\system32\USP10.dll USP10.dll
    17  0x000007fefd180000 0x000007fefd181118 0x57000 C:\Windows\system32\apphelp.dll apphelp.dll
    18  0x000007feee160000 0x000007feee16b030 0x467000 C:\Windows\AppPatch\AppPatch64\AcXtrnal.DLL AcXtrnal.DLL
    19  0x000007fefdbc0000 0x000007fefdbc1010 0x2e000 C:\Windows\system32\IMM32.DLL IMM32.DLL
    20  0x000007feff5a0000 0x000007feff5a1064 0x109000 C:\Windows\system32\MSCTF.dll MSCTF.dll
...

The complete log 300kb is here: https://www.sendspace.com/file/o7lb4p

Platform: Windows 7 SP1 x64 bits Version: DynamoRIO-Windows-6.1.0-RC1

Any ideas?

derekbruening commented 8 years ago

This is the failure:

privload_call_entry: calling SHUNIMPL.dll entry 0x0000000071fd10ac for 1
privload_load_finalize: entry routine failed

The question is, why does the private copy of SHUNIMPL.dll's entry function fail?

0ca commented 8 years ago 
SHUNIMPL.#210: unable to load forworder for SHUNIMPL.dll

Maybe the problem is importing a exported forwarded function? (About DLL forwarding https://blogs.msdn.microsoft.com/oldnewthing/20121116-00/?p=6073)

0ca commented 8 years ago

The dll is now exporting any forwarded function: https://www.sendspace.com/file/kmuzfb So I don't know.

derekbruening commented 8 years ago

I would suggest comparing the execution of SHUNIMPL.dll's entry function natively to the private invocation by DR's private loader, under a debugger.

0ca commented 8 years ago

I tried the same in Windows 7 SP1 x86 and I got the same error.

I'm new with DynamoRio so debug the private loader sounds a bit scary xD

0ca commented 8 years ago

The DLLEntryPoint's code of the dll SHUNIMPL.dll is very small

BOOL __stdcall DllEntryPoint(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
{
  BOOL result; // eax@3

  result = 1;
  if ( fdwReason == 1 )
  {
    DisableThreadLibraryCalls(hinstDLL);
    if ( !FindAtomW(L"FailObsoleteShellAPIs") )
      result = 0;
  }
  return result;
}

If it is returning 0 is because it doesn't find the Atom FailObsoleteShellAPIs, right?

0ca commented 8 years ago

So when I load manually this DLL, SHUNIMPL.dll, in Windows 7 x86 the DllEntryPoint fails, returns 0.

I am not sure why the DR's private loader is loading SHUNIMPL.dll. I think it is doing that because SHLWAPI.dll (imported from kernelbase.dll) is exporting some functions that are forwarded to SHUNIMPL.dll.

I added some comments to the log:

//DR loads SHLWAPI.DLL....
privload_process_imports: SHLWAPI.dll imports from KERNELBASE.dll
privload_process_imports: SHLWAPI.dll has new bind imports
get_allocation_size_ex pc=0x00190000 base=0x00190000 region=0x00190000 size=0x1000
    import LoadStringByReference @ 0x001a5d4c => IAT 0x006314d0
privload_set_security_cookie: SHLWAPI.dll dirsz=0x40 configsz=0x48 init cookie=0xbb40e64e
  new cookie value: 0xa144a849
privload_call_entry: calling SHLWAPI.dll entry 0x00649ba6 for 1
redirect_RtlAllocateHeap 0x239cec14 0x80
privload_load_finalize: loaded SHLWAPI.dll @ 0x00630000-0x00687000 from C:\Windows/system32/SHLWAPI.dll
//Loading imports
...
...
...
get_allocation_size_ex pc=0x00630000 base=0x00630000 region=0x00630000 size=0x1000
    import PathFindOnPathW @ 0x00632ca4 => IAT 0x017715a4
//Now DR is loading a forwarded import SHUNIMPL.#210
get_allocation_size_ex pc=0x00630000 base=0x00630000 region=0x00630000 size=0x1000
    forwarder SHUNIMPL.#210 => SHUNIMPL.dll #210
//Now DR load the DLL where the API is forwarded
privload_locate_and_load: looking for C:\Users\test\Desktop\DynamoRIO-Windows-6.0.0-6\samples\build\bin/SHUNIMPL.dll
privload_locate_and_load: looking for C:\Users\test\Desktop\DynamoRIO-Windows-6.0.0-6\ext\lib32\debug/SHUNIMPL.dll
privload_locate_and_load: looking for C:\Users\test\Desktop\DynamoRIO-Windows-6.0.0-6\drmemory/drmf\lib32\debug/SHUNIMPL.dll
privload_locate_and_load: looking for C:\Windows/system32/SHUNIMPL.dll
privload_load: loading C:\Windows/system32/SHUNIMPL.dll
...
...
...
//DR crash when the the DllEntryPoint of SHUNIMPL is called
privload_call_entry: calling SHUNIMPL.dll entry 0x0000000071fd10ac for 1
privload_load_finalize: entry routine failed

But when I load in Windows 7 SHLWAPI.dll it doesn't try to load SHUNIMPL.dll. Windows doesn't load the DLL when it finds a forwarded export. But the DR's private loader is loading the DLLs when it finds a export forwarded function.

I uploaded here a extended log, loglevel 3, so you can verify it: https://www.sendspace.com/file/drygbh

Is it possible to configure or modify DR to not load the DLLs when it finds a exported forwarded function?

Thanks in advance!

0ca commented 8 years ago

This is the line: https://github.com/DynamoRIO/dynamorio/blob/896ffafb2476963f003bcb02c93ba40dfa968d37/core/win32/loader.c#L1261

Ps: There is a small typo in https://github.com/DynamoRIO/dynamorio/blob/896ffafb2476963f003bcb02c93ba40dfa968d37/core/win32/loader.c#L1265:

LOG(GLOBAL, LOG_LOADER, 1, "%s: unable to load forworder for %s\n"
LOG(GLOBAL, LOG_LOADER, 1, "%s: unable to load forwarder for %s\n"

But I don't know why it is printing garbage:

SHUNIMPL.#210: unable to load forworder for p¨<9c>#
derekbruening commented 8 years ago

You were running 64-bit originally, does the 64-bit shunimpl.dll entry also fail (you said "Windows 7 x86" above)? Does loading the 64-bit python27.dll by itself load shunimpl.dll?

What does Dependency Walker or "dumpbin /imports" say about python27.dll and its imports? I.e., what do other tools say about this forwarder?

derekbruening commented 8 years ago

Is this really a delay-load import that DR mis-parsed? Is the forwarder being mis-parsed?

derekbruening commented 8 years ago

I took a look: I can reproduce this, and it looks like the bug is that DR has the exports index off by one.

The log:

privload_load_finalize: loaded SHLWAPI.dll @ 0x0000000002d90000-0x0000000002e01000 from C:\Windows/system32/SHLWAPI.dll
        import StrTrimW @ 0x0000000002d9b090 =&gt; IAT 0x000000000242ea80
        <...>
        import PathIsRootA @ 0x0000000002dba000 =&gt; IAT 0x000000000242eb28
        import <ordinal> @ 0x0000000002d9bb28 =&gt; IAT 0x000000000242eb30
        import PathAppendA @ 0x0000000002d95710 =&gt; IAT 0x000000000242eb38
        forwarder SHUNIMPL.#210 =&gt; SHUNIMPL.dll #210
privload_load: loading C:\Windows/system32/SHUNIMPL.dll
privload_call_entry: calling SHUNIMPL.dll entry 0x0000000071fd10ac for 1
privload_load_finalize: entry routine failed
SHUNIMPL.#210: unable to load forworder for SHUNIMPL.dll
privload_load_finalize: failed to process imports SHELL32.dll
privload_process_imports: unable to load import lib SHELL32.dll
privload_load_finalize: failed to process imports python27.dll
privload_process_imports: unable to load import lib python27.dll
privload_load_finalize: failed to process imports bbcount.dll

C:\python_27_amd64\files\python27.dll imports from shell32.dll which imports from shlwapi.dll which contains the forwarder

According to dumpbin, the shell32 import list from shwlapi after PathAppendA is just another ordinal:

           <...>
           7FF741AA0F0    66 PathIsRootA
           7FF741A7D78       Ordinal   445
           7FF74185790    33 PathAppendA
           7FF7419C168       Ordinal   597
           7FF7419C290       Ordinal   596
           7FF74186574    AB SHCreateStreamOnFileW
           7FF7419E50C       Ordinal   214
           <...>
           7FF74194BCC       Ordinal   621
           <...>

And that ordinal in shlwapi is: 597 1D 0001C0BC IStream_WriteStr

0:000> .frame 4
04 00000000`0018eb70 00000000`15457a95 dynamorio!privload_process_one_import+0x690 [c:\src\dr\git\src\core\win32\loader.c @ 1269]
0:000> dv
            mod = 0x00000000`bf9ec4a0
         impmod = 0x00000000`bf9ec6c0
         lookup = 0x00000000`027ecc70
        address = 0x00000000`0275fb40
           func = 0x00000000`00000000
        impfunc = 0x00000000`15540890 "<ordinal>"
        forwmod = 0x00000000`00000000
      forwarder = 0x00000000`01fd4e70 "SHUNIMPL.#210"
       forwfunc = 0x00000000`01fd4e79 "#210"
            dst = 0x00000000`00000000 ""
   last_forwmod = 0x00000000`bf9ec6c0
       forwpath = 0x00000000`00000000 ""

dynamorio!get_proc_address_common+0x8da:
00000000`1543a78a 488b442458      mov     rax,qword ptr [rsp+58h] ss:00000000`002ae6b8={SHLWAPI_2000000 (00000000`02000000)}
0:000> dv
            ord = 0x255
           func = 0x00000000`02054e70 "SHUNIMPL.#210"
0:000> dc 02054e70 
00000000`02054e70  4e554853 4c504d49 3132232e 48530030  SHUNIMPL.#210.SH
00000000`02054e80  4d494e55 232e4c50 00323533 4e554853  UNIMPL.#352.SHUN
00000000`02054e90  4c504d49 3533232e 48530031 4d494e55  IMPL.#351.SHUNIM
00000000`02054ea0  232e4c50 00333533 4e554853 4c504d49  PL.#353.SHUNIMPL
00000000`02054eb0  3533232e 48530034 4d494e55 232e4c50  .#354.SHUNIMPL.#
00000000`02054ec0  00353533 4e554853 4c504d49 3533232e  355.SHUNIMPL.#35

shunimpl's ord #210: 210 00001B34 [NONAME]

Dependency Walker: For shlwapi's exports: it agrees that 0x255 is IStream_WriteStr, entry 0x1c0bc, hint 0x1d. For ordinal 0x256, it lists it as a forward to "SHUNIMPL.#210".

So we're off by one? Indeed:

0:000> U @@(module_base + functions[0x254]) L1
SHLWAPI_2000000!IStream_WriteStr:
00000000`0201c0bc 48895c2418      mov     qword ptr [rsp+18h],rbx

0:000> U @@(module_base + functions[0x2]) L1
SHLWAPI_2000000!Ordinal3:
00000000`02027f6c 48895c2410      mov     qword ptr [rsp+10h],rbx
0:000> U @@(module_base + functions[0x1]) L1
SHLWAPI_2000000!ParseURLW:
00000000`0200d2e8 48895c2418      mov     qword ptr [rsp+18h],rbx
0:000> U @@(module_base + functions[0x0]) L1
SHLWAPI_2000000!ParseURLA:
00000000`02038f24 48895c2418      mov     qword ptr [rsp+18h],rbx

So all of them are off by one.

0:000> dt exports
Local var @ 0x2ae6b0 Type _IMAGE_EXPORT_DIRECTORY*
0x00000000`02050b30 
   +0x000 Characteristics  : 0
   +0x004 TimeDateStamp    : 0x4ce7a0c9
   +0x008 MajorVersion     : 0
   +0x00a MinorVersion     : 0
   +0x00c Name             : 0x52272
   +0x010 Base             : 1
   +0x014 NumberOfFunctions : 0x39d
   +0x018 NumberOfNames    : 0x171
   +0x01c AddressOfFunctions : 0x50b58
   +0x020 AddressOfNames   : 0x519cc
   +0x024 AddressOfNameOrdinals : 0x51f90

It looks like we're supposed to subtract the Base field from the index. This must be the first dll with a non-zero Base we have ever seen.

0ca commented 8 years ago

Awesome analysis!

So without the off-by-one the forwarded export 0x255 is not reached and the DLL SHUNIMPL is never loaded, right?

derekbruening commented 8 years ago

Yes, 0x255 is not imported and so shunimpl is not loaded.

With this fixed, my python27.dll ends up wanting to load a SxS lib which we do not support:

privload_process_imports: python27.dll imports from MSVCR90.dll
privload_locate_and_load: looking for C:\src\dr\git\build_x64_dbg_tests\api\bin/MSVCR90.dll
privload_locate_and_load: looking for C:\src\dr\git\build_x64_dbg_tests\ext\lib64\debug/MSVCR9
0.dll
privload_locate_and_load: looking for C:\src\dr\git\build_x64_dbg_tests\drmemory/drmf\lib64\de
bug/MSVCR90.dll
privload_locate_and_load: looking for C:\Windows/system32/MSVCR90.dll
privload_locate_and_load: looking for C:\Windows/MSVCR90.dll
SYSLOG_ERROR: Application C:\src\dr\git\build_x64_dbg_tests\suite\tests\bin\common.eflags.exe 
(1224). Unable to load client library: MSVCR90.dll
        Cannot find library.

It's in C:\windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_08e61857a83bc251

> git grep -A 3 SxS
api/docs/intro.dox:Our private loader does not yet support locating SxS (side-by-side)
api/docs/intro.dox-libraries, so using \p /MD will most likely not work unless using a
api/docs/intro.dox-version of the Visual Studio compiler other than 2005 or 2008.

Unless someone wants to contribute manifest parsing and SxS support (which does not seem worthwhile as it's no longer used by VS), the workaround is to copy that lib into a dir on our search path (see the log above for where it's looking). Then it works, on apps that load user32 (it will not work on apps that don't: that's #1299 which is not easy to solve though someone is welcome to try).

0ca commented 8 years ago

Perfect!

Is the fix in the repository? I want to test it :)

0ca commented 8 years ago

Hey,

I tried the workarround (copy the sxs, msvcr90.dll, to system32) and now I get a different error, MSVCR90.dll is loaded but after that DR is trying to access to a random file and crashes?: image

I checked the log but it doesn't have too much information about why it is crashing. These are the last log's lines:

privload_call_entry: calling python27.dll entry 0x69b8521a for 1
redirect_RtlAllocateHeap 0x1c1a482c 0x80
redirect_GetModuleHandleW: kernel32.dll => 0x004b0000
redirect_GetProcAddress: 0x004b0000GetCurrentActCtx
get_allocation_size_ex pc=0x004b0000 base=0x004b0000 region=0x004b0000 size=0x1000
drwinapi_redirect_getprocaddr: GetCurrentActCtx => 0x004ebf9d
redirect_GetProcAddress: 0x004b0000ActivateActCtx
get_allocation_size_ex pc=0x004b0000 base=0x004b0000 region=0x004b0000 size=0x1000
drwinapi_redirect_getprocaddr: ActivateActCtx => 0x004f5911
redirect_GetProcAddress: 0x004b0000DeactivateActCtx
get_allocation_size_ex pc=0x004b0000 base=0x004b0000 region=0x004b0000 size=0x1000
drwinapi_redirect_getprocaddr: DeactivateActCtx => 0x004f5942
redirect_GetProcAddress: 0x004b0000AddRefActCtx
get_allocation_size_ex pc=0x004b0000 base=0x004b0000 region=0x004b0000 size=0x1000
drwinapi_redirect_getprocaddr: AddRefActCtx => 0x004ebffb
redirect_GetProcAddress: 0x004b0000ReleaseActCtx
get_allocation_size_ex pc=0x004b0000 base=0x004b0000 region=0x004b0000 size=0x1000
drwinapi_redirect_getprocaddr: ReleaseActCtx => 0x004f7347

Complete log: https://www.sendspace.com/file/f9zap0

I am executing arp.exe, it is importing user32.dll so the error isn't related with https://github.com/DynamoRIO/dynamorio/issues/1299. I also tried with notepad.exe with the same result.

If in my client I don't import python everything works perfectly.

Any ideas?

0ca commented 8 years ago

Ok, it seems that the error is inside the DllEntryPoint of python27.dll.

I tried with another version of python27.dll compiled with VS 2010 (MSVCR100) and I got the same error. http://www.p-nand-q.com/python/building-python-27-with-visual_studio.html

Last log's lines:

privload_call_entry: calling python27.dll entry 0x014a015b for 1
redirect_RtlAllocateHeap 0x19d44478 0x80
redirect_GetModuleHandleW: kernel32.dll => 0x00480000
redirect_GetProcAddress: 0x00480000GetCurrentActCtx
get_allocation_size_ex pc=0x00480000 base=0x00480000 region=0x00480000 size=0x1000
drwinapi_redirect_getprocaddr: GetCurrentActCtx => 0x004bbf9d
redirect_GetProcAddress: 0x00480000ActivateActCtx
get_allocation_size_ex pc=0x00480000 base=0x00480000 region=0x00480000 size=0x1000
drwinapi_redirect_getprocaddr: ActivateActCtx => 0x004c5911
redirect_GetProcAddress: 0x00480000DeactivateActCtx
get_allocation_size_ex pc=0x00480000 base=0x00480000 region=0x00480000 size=0x1000
drwinapi_redirect_getprocaddr: DeactivateActCtx => 0x004c5942
redirect_GetProcAddress: 0x00480000AddRefActCtx
get_allocation_size_ex pc=0x00480000 base=0x00480000 region=0x00480000 size=0x1000
drwinapi_redirect_getprocaddr: AddRefActCtx => 0x004bbffb
redirect_GetProcAddress: 0x00480000ReleaseActCtx
get_allocation_size_ex pc=0x00480000 base=0x00480000 region=0x00480000 size=0x1000
drwinapi_redirect_getprocaddr: ReleaseActCtx => 0x004c7347

The code of the DllEntryPoint in Python27 isn't too complex.

main load

Reading the log it seems that the load_api function is executed without errors, maybe the crash happens when the code calls GetCurrentActCtx?

Detailed log, loglevel 10 (is this the max?): https://www.sendspace.com/file/fbwphc

0ca commented 8 years ago

So the problem is still there, it was fixed the load of SHLWAPI.dll, but it can't be loaded python27.dll.

Can anyone re-open the issue? Thanks!

illera88 commented 8 years ago

I'm having the same problem. @derekbruening can you take a look at it when you have some time?

Thank you in advance

illera88 commented 8 years ago

Hi @derekbruening . Sorry to bother again. Is there any plan to fix this bug?

thank you.

derekbruening commented 8 years ago

We would love to see it fixed but at this point we are short on resources. The best bet is for a new contributor to take a stab at analyzing and adding support for loading these libraries.

illera88 commented 8 years ago

I tried to get the core failure of this bug but I could't find it. I was hoping you can help us out here.

Regards

toshipiazza commented 7 years ago

I don't know if I have the same errors as @illera88 saw since it's been more than a year, but with debug I currently see the following message, then a crash:

$ ../dynamorio-suite/build_debug-internal-32/bin32/drrun.exe -c ./build32/Debug/bbcount.dll -- ping.exe
<Starting application C:\Windows\SysWOW64\ping.exe (1768)>
<unknown API-MS-Win pseudo-dll api-ms-win-core-atoms-l1-1-0.dll>
<Application C:\Windows\SysWOW64\ping.exe (1768). Unable to load client library: import GlobalGetAtomNameA not found in KERNELBASE.dll.>
./run32.sh: line 2:  7624 Segmentation fault      ../dynamorio-suite/build_debug-internal-32/bin32/drrun.exe -c ./build32/Debug/bbcount.dll -- ping.exe
$ ../dynamorio-suite/build_debug-internal-64/bin64/drrun.exe -c ./build64/Debug/bbcount.dll -- ping.exe
<Starting application C:\Windows\system32\ping.exe (6176)>
<unknown API-MS-Win pseudo-dll api-ms-win-core-atoms-l1-1-0.dll>
<Application C:\Windows\system32\ping.exe (6176). Unable to load client library: import GlobalDeleteAtom not found in KERNELBASE.dll.>
./run64.sh: line 2:  6580 Segmentation fault      ../dynamorio-suite/build_debug-internal-64/bin64/drrun.exe -c ./build64/Debug/bbcount.dll -- ping.exe

Some notes:

(By the way, I'm on Windows 8.1, didn't realize at the top that the original issue pertained to Win7)

Looks like in both cases, we're just missing the pseudo-dll api-ms-win-core-atoms-l1-1-0.dll

toshipiazza commented 7 years ago

Once I add in an appropriate patch to handle the unknown pseudo-dlls (there were a few of them), I see the following error:

$ ../dynamorio-suite/build_debug-internal-64/bin64/drrun.exe -debug -c ./build64/Debug/bbcount.dll -- ping.exe
<Starting application C:\Windows\system32\ping.exe (4060)>
<Received asynch event for unknown thread 6912>
Segmentation fault

I haven't seen this before, not sure what's going on. @derekbruening any thoughts?

derekbruening commented 7 years ago

The private python is creating threads I would guess. There are DR mechanisms for handling early app threads and I would have expected DR to mis-identify private python threads as app threads, but the "unknown thread" sounds like something slightly different. In any case, these would have to labeled as client threads and someone would have to think through how to handle their actions, if this is what's happening.