search

DynamoRIO / dynamorio

Dynamic Instrumentation Tool Platform
Other
2.68k stars 566 forks source link

DR loses control of process on `_get_osfhandle` #3088

Open woodruffw opened 6 years ago

woodruffw commented 6 years ago

Hi,

I'm running the latest DynamoRIO cronbuild, on Windows 10. I'm instrumenting a 64-bit Windows 10 application via drrun, using -client_lib to pass my DR client (which is built as a dll).

What I'm seeing looks like a loss of control, specifically on a call to _get_osfhandle in my client. My client and target application run fine together with the call stubbed out, but execution disappears (with no error messages) when it's re-added. WinDBG shows a normal exit, which makes me think that the target application is regaining control and terminating on its own.

Passing -debug to drrun produces the same behavior.

Let me know if logs would help -- I can try to clean some up.

woodruffw commented 6 years ago

I don't know how to confirm this, but my suspicion is that my Windows 10 version (1803) is behind this: 1803 adds NtAllocateVirtualMemoryEx, which probably means unintercepted/instrumented memory allocations.

I opened #3090 as a RFC on adding 1803 support.

derekbruening commented 6 years ago

Xref loss of control with OutputDebugString when run under a debugger (#2389). I assume your symptoms here happen when not under a debugger.

woodruffw commented 6 years ago

Yep, not under a debugger. I'll take a look at #2389.

woodruffw commented 6 years ago

I can also confirm that this isn't related to #3091, at least not directly -- running my target application under those changes doesn't produce any signs of NtAllocateVirtualMemoryEx or NtMapViewOfSectionEx being called (based on the logfiles).

woodruffw commented 6 years ago

Did some more testing, but with no luck. The last thing in my logfile looks suspect, though:

dispatch: target = 0x00007ffa1b663e50
CLEANCALL: insert clean call to 0x00007ff687c85840
CLEANCALL: analyze callee 0x00007ff687c85840
CLEANCALL: decoding callee starting at: 0x00007ff687c85840
CLEANCALL: callee calls out at: 0x00007ff687c85851 to 0x00007ff687c8938e
CLEANCALL: callee calls out is not PIC code, bailout
Fragment 4406, tag 0x00007ffa1b663e50, flags 0x9000030, shared, size 200:
    [ucrtbase.dll!fread_s]

Any thoughts? fread_s is the call that I'm wrapping.

derekbruening commented 6 years ago

I would try to run the client's call to _get_osfhandle in windbg under "wt" which will give a call trace of everything that happens leading up to the exit.