Crash in MemoryLoadLibraryEx(): 0xC0000005: Access violation reading location 0x00000000. about memorymodule HOT 14 OPEN

Hmmm. This interesting virus implementation seems to be able to solve the issue here: https://github.com/devilogic/xvirus/blob/master/EvilKernel/RefixTlsPrivate.c

Update: did more investigation. The code is not thread-safe and does not consider special cases where acceleration is applicable. Nevertheless, I will try to use it as a starting point and see how far I can go.

Update 2: suddenly found that WINE should have the best open-source PE loader implementation. I guess I would implement my loader directly by migrating their code.

Update 3: the WINE implementation is based on POSIX API, might need a huge refractor to make it collaborate with Windows native process management and file management. Working on it. P.S. the virus code is poorly designed and it could have many problems related with TLS handling, e.g. only currently thread has TLS storage allocated...

from memorymodule.

The VS2015 generates a TLS (thread local storage) section for the SampleDLL, so this
https://support.microsoft.com/en-us/kb/118816 could be related.

But this does not explain why it works when the DLL is loaded from a file with LoadLibrary(). The behaviour should be identical, but isn't.

From what I can see there are no TLS callbacks in the DLL, so #25 does not fit.

In http://www.nynaeve.net/?p=186 there is the section

At thread initialization time, allocate and initialize TLS memory blocks for each module
utilizing TLS, allocate the ThreadLocalStoragePointer array for the current thread, and
link the TLS memory blocks in to the ThreadLocalStoragePointer array. Additionally,
TLS initializers and then DLL initializers (in that order) are invoked for the current thread."

I don't see where MemoryModule is doing this.

from memorymodule.

Great. How easy would be to protect code from MemoryModule.

from memorymodule.

Upon further reading the wonderful article series by Ken Johnson, I think that MemoryModule currently behaves just like pre-Vista Windows did with regards to implicit TLS in DLLs.

MemoryLoadLibraryEx() does not allocate the necessary structures, but compiler and linker generated a DLL that expect these to be in place. Mayhem ensues.

http://www.nynaeve.net/?p=187 describes the situation in a slightly discouraging fashion:

This results in one of the absolute worst possible kinds of problems to debug. Now you’ve got one module trampling all over another module’s state, with the guilty module under the (mistaken) belief that the state that it’s referencing is really the guilty module’s own state. If you’re lucky, the process has no implicit TLS using at all (at process initialization time), and the ThreadLocalStoragePointer will not be allocated for the current thread and the initial access to a declspec(thread) variable will simply result in an __immediate null pointer dereference

Emphasis mine. I guess this initial access happens in GetCallable() when the control flow reaches the static variable for the first time.

And because Windows after Vista gained support for implicit TLS in DLLs (http://www.nynaeve.net/?p=189), the regular LoadLibrary() works fine. And if it happens to be called before MemoryLoadLibraryEx() it will (IMHO) allocate everything for the process to access the TLS variables without a glitch.

from memorymodule.

Not really MemoryModule related, but one question is why the compiler generates TLS accesses without any occurrence of "declspec(thread)" in the source. This is because of magic statics which are a new feature in VS2015 (https://www.visualstudio.com/en-us/news/vs2015-vs.aspx):

Thread-Safe "Magic" Statics Static local variables are now initialized in a thread-safe way, eliminating the need for manual synchronization. Only initialization is thread-safe, use of static local variables by multiple threads must still be manually synchronized. The thread-safe statics feature can be disabled by using the /Zc:threadSafeInit- flag to avoid taking a dependency on the CRT.

And if this bites MemoryModule, it also affects VS2015 code running on pre-Vista Windows:

https://connect.microsoft.com/VisualStudio/feedback/details/1715018/dll-usage-of-thread-safe-magic-statics-may-crash-on-windows-xp

from memorymodule.

Does the DLL work in MemoryModule if compiled with the switch /Zc:threadSafeInit- as described in the link?

from memorymodule.

Yes. In my case that's good enough. In other cases where you want to embed some existing dll that's not really helpful though since you can't control how it was compiled.

from memorymodule.

A recent article in the D language blog reminded me of this issue (https://dlang.org/blog/2016/08/12/project-highlight-visual-d/):

Visual Studio is a Win32 application and loads its extensions dynamically as DLLs. D very much relies on Thread Local Storage (TLS) as it is the default for global variables. Under Windows this uses “implicit TLS” built into the binary. Unfortunately, Windows Vista was the first version to support this for dynamically loaded DLLs, but Windows XP was still the most widely used version. It only supports TLS for the DLLs that are loaded implicitly with the application.

Eventually, after a lot of debugging, he managed to work around his Windows XP problems by tricking the system into believing a manually loaded DLL had been implicitly loaded with the application. The result of these efforts can be seen in the DRuntime modules core.sys.windows.dll and core.sys.windows.threadaux. This implementation comes with the drawback that DLLs using it cannot be unloaded. An improved version by Denis Shelomovskii works around this. Given the decline of XP usage, the need for this will eventually fade away.

When those D DLLs are loaded/attached they set up the implicit TLS for their global variables themselves. So even under XP where the Windows loader did not handle implicit TLS they magically work.

And the code for this is in dll.d [1] -- thus it might be a guide on how to do this in MemoryModule.

[1] which even quotes the page from http://www.nynaeve.net mentioned above, I should have googled for that back last year, it would have been the second entry.

from memorymodule.

currently running into a problem with this, as I can not use a mingw compiled binary to "load" (with memorymodule) a mingw compiled binary (the TLSCallback points to a giant (wrong) address upon the first iteration of the while loop inside "executeTLS()". Has there been any progress on fixing the implementation here (to work on modern systems) or should I simply look into trying to figure how to disable TLS support in mingw?

from memorymodule.

I'm not aware of any progress on this issue. If you do not rely on thread safe initialization of local statics (e.g. you do not use threads at all) you could experiment with -fno-threadsafe-statics in gcc/mingw, this is what solved our problem with VS2015.

from memorymodule.

sadly, my targets are complicated (a mixture of multiple languages and a convoluted build system), and while this might work for some of them, the best solution for me would be to actually "fix" memory module to allocate things correctly (sadly this is a bit beyond me at the moment).

from memorymodule.

Would it be possible that some experts here could implement the required change described by http://www.nynaeve.net/?p=189? The blogger has posted the reference implementation along with the blog, although it is somewhat beyond my ability to follow that...

from memorymodule.

Why can't we just parse the whole binary, replace references to (void**)NtCurrentTeb()[11] in the assembly with a function call?

In x86, TLS block array is accessed by something like:

                           .text:00406eb8 64 8b 0d 2c 00 00 00             mov    %fs:0x2c,%ecx

Why can't we just replace that with a function call FF 15 DE AD BE EF, to a function at 0xefbeadde that stores the relevant address to the correct position? This is somewhat similar to the way Apple's dyld handles its TLS.

Most workarounds for Windows seem to "reserve" a specific range of module IDs instead of legitimately acquire a real ID, allowing chaos to happen when enough modules are loaded the right way.

from memorymodule.

I believe https://github.com/bb107/MemoryModulePP implements this

from memorymodule.