Cool_Tools/ExplorerPatcher
1
0
Fork 0
mirror of https://github.com/valinet/ExplorerPatcher.git synced 2024-11-27 17:00:59 +01:00
Code Releases Wiki Activity
eb1f1ec95b
ExplorerPatcher/ep_extra/worker.c

83 lines
2.3 KiB
C
Raw Normal View History

ep_extra: Implemented an `ep_extra`-based loader ExplorerPatcher includes a mechanism which allows the user to load a single DLL, named `ep_extra.dll` and placed in `C:\Windows` when `explorer.exe` loads. This was long requested by some users who wanted to perform their own code/initializations/hooks when `explorer` started. In the mean time, I thought `ep_extra.dll` would work nicely as a loader for any number of modules. I could've included this functionality in the main ExplorerPatcher code, but I decided to take it up as a challenge instead and offer a robust implementation without changing ExplorerPatcher's main code. Thus, when using this as `ep_extra.dll`, it will also load DLLs that match the `ep_extra_*.dll` pattern. These DLLs must export a function called `setup` which the loader will execute on the thread that is loading the DLLs. Although not currently checked, return 0 from this function if your initialization succeeded, or some error code when it fails. What's up with the assembly and shell codes and weird threads that I create? Well, I realized I kind of did a mistake when coding ExplorerPatcher, in that I should have loaded and executed `ep_extra` on a seprate thread, not in `explorer`'s main thread. But since I said I'd do this challenge without changing EP, this was my solution towards having this `ep_extra` loader do its work, load the other DLLs, if any, and then unload itself from memory safely and (almost) cleanly without disturbing the main application right after it does its job. This way, you can update it seamlessly when `explorer` is running, which is much more convenient than having to kill `explorer`, replace the DLL, and then manually reload `explorer`. I don't know if this is the best way, but it is the way I thought about when realizing that I cannot call `FreeLibrary` simply, since the "next line" (which would have been a "return") is well outside of valid memory at that point. `FreeLibraryAndExitThread` also can't be used since I do not want to exit `explorer`'s main thread which the loader's function is called on.
2023-03-01 19:27:44 +01:00
#include <Windows.h>
#include <Shlwapi.h>
#pragma comment(lib, "Shlwapi.lib")
#include <stdio.h>
HMODULE hModule = NULL;
HANDLE sigFinish = NULL;
void* pFinishProc = NULL;
void done() {
WaitForSingleObject(sigFinish, INFINITE);
FreeLibraryAndExitThread(hModule, 0);
}
void* worker() {
wchar_t pattern[MAX_PATH];
GetWindowsDirectoryW(pattern, MAX_PATH);
wcscat_s(pattern, MAX_PATH, L"\\ep_extra_*.dll");
WIN32_FIND_DATA data;
HANDLE hFind = FindFirstFileW(pattern, &data);
if (hFind != INVALID_HANDLE_VALUE) {
do {
wprintf(L">> Found ep_extra library: \"%s\"\n", data.cFileName);
GetWindowsDirectoryW(pattern, MAX_PATH);
wcscat_s(pattern, MAX_PATH, L"\\");
wcscat_s(pattern, MAX_PATH, data.cFileName);
HMODULE hLib = LoadLibraryW(pattern);
if (hLib) {
FARPROC proc = (FARPROC)(GetProcAddress(hLib, "setup"));
if (proc) {
Version: 22621.1344.53.1
2023-03-01 20:29:35 +01:00
if (proc()) FreeLibrary(hLib);
ep_extra: Implemented an `ep_extra`-based loader ExplorerPatcher includes a mechanism which allows the user to load a single DLL, named `ep_extra.dll` and placed in `C:\Windows` when `explorer.exe` loads. This was long requested by some users who wanted to perform their own code/initializations/hooks when `explorer` started. In the mean time, I thought `ep_extra.dll` would work nicely as a loader for any number of modules. I could've included this functionality in the main ExplorerPatcher code, but I decided to take it up as a challenge instead and offer a robust implementation without changing ExplorerPatcher's main code. Thus, when using this as `ep_extra.dll`, it will also load DLLs that match the `ep_extra_*.dll` pattern. These DLLs must export a function called `setup` which the loader will execute on the thread that is loading the DLLs. Although not currently checked, return 0 from this function if your initialization succeeded, or some error code when it fails. What's up with the assembly and shell codes and weird threads that I create? Well, I realized I kind of did a mistake when coding ExplorerPatcher, in that I should have loaded and executed `ep_extra` on a seprate thread, not in `explorer`'s main thread. But since I said I'd do this challenge without changing EP, this was my solution towards having this `ep_extra` loader do its work, load the other DLLs, if any, and then unload itself from memory safely and (almost) cleanly without disturbing the main application right after it does its job. This way, you can update it seamlessly when `explorer` is running, which is much more convenient than having to kill `explorer`, replace the DLL, and then manually reload `explorer`. I don't know if this is the best way, but it is the way I thought about when realizing that I cannot call `FreeLibrary` simply, since the "next line" (which would have been a "return") is well outside of valid memory at that point. `FreeLibraryAndExitThread` also can't be used since I do not want to exit `explorer`'s main thread which the loader's function is called on.
2023-03-01 19:27:44 +01:00
}
else FreeLibrary(hLib);
}
} while (FindNextFileW(hFind, &data));
FindClose(hFind);
}
sigFinish = CreateEventW(NULL, FALSE, FALSE, NULL);
if (sigFinish) {
BYTE payload[] = {
0x48, 0xB9, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // mov rcx, sigFinish
0x48, 0xB8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // mov rax, SetEvent
0xFF, 0xD0, // call SetEvent
0xC9, // leave
0xC3 // ret
};
*(INT64*)(payload + 2) = sigFinish;
*(INT64*)(payload + 12) = SetEvent;
pFinishProc = VirtualAlloc(NULL, sizeof(payload), MEM_COMMIT, PAGE_EXECUTE_READWRITE);
if (pFinishProc) {
memcpy(pFinishProc, payload, sizeof(payload));
SHCreateThread(done, 0, CTF_NOADDREFLIB, NULL);
return pFinishProc;
}
}
return NULL;
}
BOOL WINAPI DllMain(
_In_ HINSTANCE hinstDLL,
_In_ DWORD fdwReason,
_In_ LPVOID lpvReserved
)
{
switch (fdwReason)
{
case DLL_PROCESS_ATTACH:
DisableThreadLibraryCalls(hinstDLL);
hModule = hinstDLL;
break;
case DLL_THREAD_ATTACH:
break;
case DLL_THREAD_DETACH:
break;
case DLL_PROCESS_DETACH:
break;
}
return TRUE;
}
Copy Permalink