MemoryModule icon indicating copy to clipboard operation
MemoryModule copied to clipboard

Crash when throwing exception inside loaded dll.

Open Niblitlvl50 opened this issue 13 years ago • 14 comments
trafficstars

When throwing and catching an exception inside the "memory-loaded" dll the application crashes with "Unhandled exception at ...". Even though the appropriate catch is in place.

This is when using Visual Studio 2010. I've created a repository that demonstrates this problem. Hopefully i am the one who has missed something and the memory loading is working as intended.

Link to repo: https://github.com/Niblitlvl50/DLL-crash-when-loading-dll-into-memory

Thank you.

Niblitlvl50 avatar Jun 15 '12 12:06 Niblitlvl50

Hi

A temporary fix is to disable DEP[1] in the Visual Studio build options. Another possibility is to implement the missing parts of the pe loading process in MemoryModule. I'll provide some code, if I get an allowance from my boss.

[1] DEP: http://en.wikipedia.org/wiki/Data_Execution_Prevention

JesseKlugmann avatar Jul 25 '12 18:07 JesseKlugmann

Hi JesseKlugmann, any updates on this? Could you provide some code, or give some hints what parts are missing and maybe describe how they should be implemented?

fancycode avatar Oct 29 '12 20:10 fancycode

My guess (and I dont know a lot about the subject) is that you have to load the .SAFESEH section of the dll, otherwise the SafeSeh mechanism will terminate the process when an exception occurs, as it cannot verify that the exception handlers are safe. See http://msdn.microsoft.com/en-us/library/9a89h429(v=vs.90).aspx

kovidgoyal avatar Dec 01 '12 03:12 kovidgoyal

@JesseKlugmann do you have any hints or links to documentation how this could be implemented?

fancycode avatar Mar 12 '13 20:03 fancycode

@fancycode

  1. on x32 the problem in inside RtlIsValidHandler (ntdll.dll). It's check if handler address in module. For solve this problem you can disable DEP (that's not so cool because some times you can't do this because you inside another app) OR try to find function RtlInsertInvertedFunctionTable and addr of LdrpInvertedFunctionTable because it's all not exported. And call RtlInsertInvertedFunctionTable(LdrpInvertedFunctionTable, 'imagebase', 'sizeofimage') for manually loaded module.

  2. on x64 problem is in two places

  • first, almost the same as x32. Occurs inside RtlLookupFunctionEntry, because it's module not registered in LdrpInvertedFunctionTable. Solve simple, because on x64 we have exported function RtlAddFunctionTable('addr of exception directory', 'count of handlers', 'imagebase') from ntdll.dll
  • second, inside RtlPcToFileHeader, which search module imagebase of handler addr in list PEB->Ldr->InLoadOrderModuleList. You can forcibly add your module to peb. You already have some implementation of this in https://github.com/fancycode/MemoryModule/tree/jojo_peb_compat

Zorro1 avatar Jun 19 '13 20:06 Zorro1

The "DarkMMap" project found here (https://github.com/DarthTon/DarkMMap) loads libraries from memory and according to the project page, has "Exception handling support (SEH and C++), needs more testing though, but seems reliable". Perhaps someone could take a look at how they implement exception handling support and adopt it to work with MemoryModule.

bigmacattack avatar Dec 30 '13 00:12 bigmacattack

I checked DarkMMap (now deprecated and called Blackbone). It works just fine but doesn't support Windows XP.

I found the relevant code from their library, can someone help incorporate it into MemoryModule? I'm a not too good at Win32...

It's in MMap.cpp:550

///

/// Set custom exception handler to bypass SafeSEH under DEP ///

/// image data /// true on success bool MMap::EnableExceptions( ImageContext* pImage ) { BLACBONE_TRACE( L"ManualMap: Enabling exception support for image '%ls'", pImage->FileName.c_str() ); #ifdef USE64 size_t size = pImage->PEImage.DirectorySize( IMAGE_DIRECTORY_ENTRY_EXCEPTION ); IMAGE_RUNTIME_FUNCTION_ENTRY *pExpTable = reinterpret_cast<decltype(pExpTable)>(pImage->PEImage.DirectoryAddress( IMAGE_DIRECTORY_ENTRY_EXCEPTION ));

// Invoke RtlAddFunctionTable
if(pExpTable)
{     
    AsmJitHelper a;
    uint64_t result = 0;

    pImage->pExpTableAddr = REBASE( pExpTable, pImage->FileImage.base(), pImage->imgMem.ptr<ptr_t>() );
    auto pAddTable = _process.modules().GetExport( _process.modules().GetModule( L"ntdll.dll", LdrList, pImage->PEImage.mType() ),
                                                   "RtlAddFunctionTable" );

    a.GenPrologue();
    a.GenCall( static_cast<size_t>(pAddTable.procAddress), { pImage->pExpTableAddr, 
                                                              size / sizeof(IMAGE_RUNTIME_FUNCTION_ENTRY),
                                                              pImage->imgMem.ptr<size_t>() } );
    _process.remote().AddReturnWithEvent( a );
    a.GenEpilogue();

    if (_process.remote().ExecInWorkerThread( a->make(), a->getCodeSize(), result ) != STATUS_SUCCESS)
        return false;

    if (pImage->flags & CreateLdrRef)
        return true;
    else
        return (MExcept::CreateVEH( pImage->imgMem.ptr<size_t>(), pImage->PEImage.imageSize() ) == STATUS_SUCCESS);
}
else
    return false;

#else bool safeseh = false; _process.nativeLdr().InsertInvertedFunctionTable( pImage->imgMem.ptr<void*>(), pImage->PEImage.imageSize(), safeseh );

if ((pImage->flags & PartialExcept) || safeseh)
    return true;
else
    return (MExcept::CreateVEH( pImage->imgMem.ptr<size_t>(), pImage->PEImage.imageSize() ) == STATUS_SUCCESS);

#endif

}

Tsury avatar Jun 24 '14 15:06 Tsury

Could you please create a pull request for the changes or provide a proper diff?

fancycode avatar Jun 24 '14 16:06 fancycode

This is just code I found on Blackbone's repository which I found relevant. I lack the knowledge to actually add it to your library.

Here's a direct link to the relevant code: https://github.com/DarthTon/Blackbone/blob/master/src/BlackBone/MMap.cpp#L550-L595

I think that using your knowledge and Zorro1's advice, you can manage to merge it into your library.

Tsury avatar Jun 24 '14 17:06 Tsury

Hi, have you had any luck implementing try/catch support? I tried to understand the code linked to above (Blackbone) but it deals with a lot of assembly that I can't really follow.

Thanks

ghost avatar Sep 20 '14 14:09 ghost

I found an article on how SEH and VEH exceptions are handled and it seems to expand on what Zorro1 posted.

https://hackmag.com/uncategorized/exceptions-for-hardcore-users/

I will be trying to figure this out but in the mean time maybe someone else can use what I found.

ghost avatar Aug 12 '16 22:08 ghost

Hello, I'm also interessted in a solution.

GR-C avatar Aug 23 '16 15:08 GR-C

I have located another possible source for a solution. It is designed to load windows DLLs on linux and it supports exception handling.

https://github.com/taviso/loadlibrary

ghost avatar May 24 '17 17:05 ghost

I have found a working solution to the problem!

https://github.com/nettitude/SimplePELoader

I have confirmed that an exception can be thrown and caught within the loaded library. I have also confirmed that an exception can be thrown inside the library and caught in the executable that loaded it. This is explicitly handled on 64 bit builds but has not be implemented for 32 bit builds. However the disabling DEP solution is a viable workaround for 32 bit builds.

Notes:

  1. You cannot use the '/EHsc' compiler flag without causing a crash
  2. You must use the '/NXCOMPAT:NO' linker flag on 32 bit builds

Edit:

This solution will only allow you to catch exceptions with a catch all block on 64 bit builds.

catch(...){
// You can do whatever you want here.. but you can't know what the exception is
}

The moment you try to define the exception the program will crash as usual.

ghost avatar Jul 20 '17 00:07 ghost