RtlFreeHeap ( ntdll.dll ) heap corruption exception after SXS error

[Serge Billault]

I cant find any solution to the aforementioned problem, even thought i searched in the opened/closed issues of Dynamorio GITHUB history

* Platform: Windows 64bits - RAM: 16G.

* IDE: MSVS Community 2015 ( launched as administrator )

* DynamoRio: windows X64 RC.7.0.1

* Process being injected: Windows 64 bits executable Release

* Debug command: $(SolutionDir)Dependencies\DR\bin64\drrun.exe

* Debug command line args: "-stderr_mask 15 -msgbox_mask 15  -c $(TargetPath) -- <process name>.exe"

* Debug Working dir:$(ProjectDir)

* Project configuration > C/C++ > Code generation: Multi-threaded Debug (/MTd)

* Replacement method: drwrap_replace_native( ..., override = false );

* Replaced functions all use a single custom heap for HeapAlloc/GlobalAlloc/LocalAlloc

* Heap is created with: dr_custom_alloc( dr_get_current_drcontext(), DR_ALLOC_NON_HEAP | DR_ALLOC_NON_DR, arena_sze, DR_MEMPROT_READ | DR_MEMPROT_WRITE | DR_MEMPROT_EXEC, NULL );

* User adr and sizes are aligned on 16 bytes

* Whole heap check of the custom heap before and after each call to any replaced function

* Calling the original(are they ? or are they replaced by DR ?) functions HeapFree, HeapRealloc etc if the adr is not hosted by the custom heap, same for global and local functions

* Functions calls pattern in the body of the replacement functions:

replacement_function()

{

 dr_switch_to_app_state( dr_get_current_drcontext() );

   ret_type ret_val = replacement implementation

 drwrap_replace_native_fini( dr_get_current_drcontext() );

 dr_switch_to_dr_state( dr_get_current_drcontext() );

 return ret_val;

}

* Number of Screenshots: 3

- Screenshot 1 > replaced functions

- Screenshot 2 > result when debugging without attaching to the target process

- Screenshot 3 > result when debugging by attaching to the target process

Screenshot 1 of 3 - replaced functions

[img]https://i.imgur.com/VlXLFOC.jpg[/img]

Screenshot 2 of 3 - result when debugging without attaching to the target process

[img]https://i.imgur.com/znMThip.jpg[/img]

Screenshot 3 of 3 - result when debugging by attaching to the target process

[img]https://i.imgur.com/eJrkyDv.jpg[/img]

* Questions:

1) Does anyone have a solid idea on what is causing that (i check my whole heap before and after each call to any replaced function) ?

2) Is it possible to make DynamoRio execute my replacement functions only for the target application, not for the modules loaded by the application ?

3) Anything I am doing wrong, please tell me so that I can exclude it from the possible causes for my problem...

[Serge Billault]

Le lundi 17 septembre 2018 06:54:05 UTC+2, Serge Billault a écrit :

I cant find any solution to the aforementioned problem, even thought i searched in the opened/closed issues of Dynamorio GITHUB history

* Platform: Windows 10  ( update 1503+ ) - 64bits - RAM: 16G.

[Serge Billault]

If it help, I retrieved the exact version of my OS:

Microsoft Windows Family Edition - Version 1803 (OS version 17134.285)

[Serge Billault]

After further investigations it seems the problem comes from RtlFreeHeap() attempting to free a block allocated in another memory region than expected. So I need to also replace RtlXXXHeap functions to avoid the kind of conflicts that the replacements of HeapAlloc/GlobalAlloc/LocalAlloc were causing when replacing only one of the 3 functions sets instead of the 3 alltogether.

But dynamoRio wont permit it. GameOver for my first try at dynamoRIO to install a simple custom memory manager ?...

What other utilities aside from dynamoRIO exist that would allow me to replace functions that should be replaceable ? If i turn to other tools and they all end up having the same flow, what then ?....

[Derek Bruening]

Replacing Windows heap interfaces is surprisingly complex.  The Dr. Memory tool does it.  It intercepts the libc layer, win api layer, and Rtl layer, and tracks weird syscalls that allocate memory such as NtMapCMFModule.  We wanted to extract its heap interception into a library usable by other tools (filed as https://github.com/DynamoRIO/drmemory/issues/824) but unfortunately never had the resources to work on that.

> Is it possible to make DynamoRio execute my replacement functions only for the target application, not for the modules loaded by the application ?

Not using the existing drwrap, but you could do it using raw DR.  You would need a different strategy for replacing than drwrap's callee-focused approach.

--
You received this message because you are subscribed to the Google Groups "DynamoRIO Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dynamorio-use...@googlegroups.com.
To post to this group, send email to dynamor...@googlegroups.com.
Visit this group at https://groups.google.com/group/dynamorio-users.
For more options, visit https://groups.google.com/d/optout.

[Serge Billault]

I have been able to replace the RtlXXXHeap functions set. So either the overriden replacement was not critical for its owner to continue working, or either it was replaced because it cannot work if the function set is not overriden by a client.

That said, the application continues to call ntdll::RtlFreeHeap(), so it means that the block was left to be handled by its legitimate owner via a call to the original RtlFreeHeap().

At this point the problem is then either in the application (but if i deactivate all my replacements the app work), or in dynamoRIO (wich would mean that the alloc occured in dynamoRIO memory arena, then the block passed through my RtFreeHeap, and redirected from there to the original RtlFreeHeap when it should have been redirected to dynamoRIO RtlFreeHeap). In other words i suspect a possible problem of that nature (althought I am not quite convinced):

1) The app rtl alloc is intercepted by DR and allocated in DR memory (i will add a dr_memory_is_XXX kind of check)

2) My replacements take effect later on, but before the corresponding free

3) Upon intercepting the free I redirect it to the original free instead of passing ot to DR free

[Serge Billault]

I now know 2 more things:

- ntdll!RtlFreeHeap() is called directly instead of my replacement function on a block that have been allocated by me (it has a mem block header)

- The mem block header have been overwritten between a heap check and the call to ntdll!RtlFreeHeap()

[Serge Billault]

- I have verified that in the branch where I free an internally allocated block everything is fine.

- I have placed an assert in the branch where I call the original RtlFreeHeap() that is never hit.

So this direct call to RtlFreeHeap() which is supposed to have been replaced do not come from my client...

[Serge Billault]

After taking notice of the following lines in DR source files:

* to RtlFreeHeap and subsequent heap corruption by redirecting the frees,

* since sometimes creation is by direct RtlAllocateHeap.

*/

{ "RtlFreeUnicodeString", (app_pc)redirect_RtlFreeUnicodeString },

{ "RtlFreeAnsiString", (app_pc)redirect_RtlFreeAnsiString },

{ "RtlFreeOemString", (app_pc)redirect_RtlFreeOemString },

/* We don't redirect the creation but we avoid DR pointers being passed I have begun replacing memory freeing functions as well in my client dll, but I now have on Windows 10 Family version 1803 (OS version 17134.285): - "0xC0000005: Access violation reading location 0x0000000000000058" in ">    - in: dynamorio.dll!fixup_last_cti(_dcontext_t * dcontext=0x00007ff6d5bc2370, _instr_list_t * trace=0x00007ff6d5bc2380, unsigned char * next_tag=0x00007ffd2ff04c18, unsigned int next_flags=33556016, unsigned int trace_flags=16777220, _fragment_t * prev_f=0x0000000000000000, _linkstub_t * prev_l=0x0000000000000000, char record_translation='\0', unsigned int * num_exits_deleted=0x00007ff6d5bbee90, _instr_t * start_instr=0x0000000000000000, _instr_t * end_instr=0x0000000000000000) Line 6260    C"

[Serge Billault]

Upon re-enabling avast anti virus "suspicious actions agent" the "fixup_last_cti"problem reverted back to a call to RtlFreeHeap() bypassing my replacement function (Windows 10 Family version 1803 (OS version 17134.285))