Other improvements are:

• Makes the pcbData parameter in DetourFindPayload and DetourFindPayloadEx optional, so that if an application only needs to search for the presence of a payload, they can ignore the size by passing nullptr.
• Makes the pvData parameter in DetourCopyPayloadToProcess const, so that a pointer to a const C++ object can be passed instead of the object needing to be const_casted or being non-const.
• Adds DetourCopyPayloadToProcessEx, which has the same interface than DetourCopyPayloadToProcess, but it returns the address of the payload in the remote module, if the program later wants to write to it.

Fixes #79

From basic testing, it seems to work for me. I can apply corrections and add a sample if required (although finding a trivial use case for those APIs would be required)

I noticed that Detours failed to inject a DLL into an IL-only .NET application. I'm pretty sure this worked in the past (right now, this is only triggered on Windows 10 machines but not on Windows 7).

These two commits resolve the issue. Instead of sticking with the approach of enumerating the modules, I went for a simpler mechanism for detecting if the running process is 32bit or 64bit. This seems to work well. See the commit logs for all the gory details.

Any feedback would be much appreciated!

I needed to compile Detours with VS 2005, which doesn't include IsWow64Process in its Windows SDK, so added a small wrapper function around it using GetModuleHandleW and GetProcAddress.

Used the example on MSDN as a reference.

Hey Peeps,

I have VS2017 installed latest updates with the C++ tools installed. I might be missing dependencies however when I open up the Developer Command Prompt and make the project it compiles fine for x86. I did try make all and it certainly tries but when it gets to x64 it seems to error out on: iping_d.obj : error LNK2001: unresolved external symbol _iping_ProxyFileInfo Would I be able to get any advice on this why it pops up when making for x64 and not x86 or am I being so stupid I'm not seeing what is wrong.

I'm trying to detour LoadLibrary at process creation: imagine running an exe that references some DLL that isn't in the search path. I need to be able to detour LoadLibrary in that process, early enough that my detour ends up providing the right path to load the missing DLL from.

I've read the doc for DetourCreateProcessWithDllEx, specifically this paragraph:

Execution in the process is then resumed. When execution resumes, the Windows process loader will first load the target DLL and then any other DLLs in the application's import table, before calling the application entry point.

What I can't figure out is how to ensure that my detour DLL not only gets loaded first, but also has its DllMain run before the nt loader tries to resolve the rest of the DLL dependencies.

Is this possible? Any tips on how to achieve this?

I also noticed there is a requirement of having an ordinal @1 which I do, but I couldn't find mention of any requirements on the signature of this export, if there are any, and whether this export is supposed to be called? (it doesn't seem like it is called, at least not before all the dependencies are resolved).

Hi: I've been learning to use Detours recently, but I have a question: Can Detours hook functions defined by myself? For example, there is a function in the header file written by myself: void runcmd(const char *) If I get this header file, is it possible for me to hook this function using Detours? Thank U!

What the title says. MinGW doesn't support __try and __except, so it's just defined out here as it doesn't seem there's a better way to handle it.

Note: Includes #107

Window 10 VS2017 15.8.9 SDK 10.0.17763.0 VC++ 15.8 v14.15

git clone https://github.com/Microsoft/Detours.git
cd Detours
nmake

Got an error:

if not exist ..\..\bin.X64\key.snk sn -k ..\..\bin.X64\key.snk
'sn' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'if' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.

I'm trying to hook the WINAPI GetKeyboardState but the process throws an exception as soon I type something:

Commenting on these lines I still get an exception:

//lpKeyState[VK_CONTROL] = 0;
//lpKeyState[VK_LCONTROL] = 0;

I have tested hooking other APIs and they did work 'correctly'. I'm doing something wrong?

    #include "pch.h"
    #include "detours.h"
    #include "dllmain.h"
    
    
    BOOL(WINAPI* GetKeyboardState_Hook)(PBYTE) = GetKeyboardState;
    
    BOOL WINAPI HookedGetKeyboardState(PBYTE& lpKeyState) {
    
    	if (lpKeyState == NULL)
    		return 1;
    
    	//lpKeyState[VK_CONTROL] = 0;
    	//lpKeyState[VK_LCONTROL] = 0;
    
    	return GetKeyboardState(lpKeyState);
    }
    
    
    
    BOOL APIENTRY DllMain(HMODULE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved)
    {
        switch (ul_reason_for_call)
        {
        case DLL_PROCESS_ATTACH:
        {
            Sleep(1000);
            DetourTransactionBegin();
            DetourUpdateThread(GetCurrentThread());
            DetourAttach(&(PVOID&)GetKeyboardState_Hook, HookedGetKeyboardState);
    
            LONG lError = DetourTransactionCommit();
            if (lError != NO_ERROR) {
                MessageBox(HWND_DESKTOP, L"Failed to detour", L"", MB_OK);
                return FALSE;
            }
        }
        break;
    
        case DLL_PROCESS_DETACH:
        {
            DetourTransactionBegin();
            DetourUpdateThread(GetCurrentThread());
            DetourDetach(&(PVOID&)GetKeyboardState_Hook, HookedGetKeyboardState);
    
            LONG lError = DetourTransactionCommit();
            if (lError != NO_ERROR) {
                MessageBox(HWND_DESKTOP, L"DLL_PROCESS_DETACH", L"", MB_OK);
                return FALSE;
            }
        }
        break;
        }
    
        return TRUE;
    }

Addresses https://github.com/microsoft/Detours/issues/70 by utilizing the HeapLock/HeapUnlock APIs as discussed in the issue.

Microsoft Reviewers: Open in CodeFlow

A few minor changes:

1. Expose detour_is_imported via a new public function DetourIsFunctionImported
2. Make certain runtime checks happy by masking pbTarget before casting to smaller type
3. Enable user to compile with a different number of supported section headers (leaves default at 32)

Microsoft Reviewers: Open in CodeFlow

Describe the bug When I click on Wiki then API Reference I expect to see it, but I get a the awesome "Not Found" page.

It takes me here: https://github.com/microsoft/Detours/Reference Not here: https://github.com/microsoft/Detours/wiki/Reference

brings CImage in line with DETOUR_EXE_RESTORE and better aligns Microsoft documentation describing limit of 96 sections

Addresses https://github.com/microsoft/Detours/issues/268

Microsoft Reviewers: Open in CodeFlow

Bug Description: Detours allocates IMAGE_NUMBEROF_DIRECTORY_ENTRIES (i.e., 16) entries in the m_SectionHeaders array (https://github.com/microsoft/Detours/blob/master/src/image.cpp#L260). 16 is the correct limit for the DataDirectory[] member of the IMAGE_OPTIONAL_HEADERs. However, Microsoft documentation specifies that the Windows loader can accept up to 96 sections (https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#coff-file-header-object-and-image). I believe this discrepancy is a bug, and it is causing some real world issues with DetourOpenBinary.

PEs compiled with mingw will contain DWARF sections unless the user strips the binary. In practice, there appear to be 8 DWARF sections included by mingw. For x64 binaries, there are also the .pdata and .xdata sections for exception information. On x64 PE binaries compiled with mingw gcc 7.3, there are 17 sections by default. As a result, when DetourOpenBinary is called, it fails in CImage::Read (https://github.com/microsoft/Detours/blob/master/src/image.cpp#L1088).

While stripping the DWARF sections from the binary is a workaround, I believe the appropriate solution is to bring the Detours sections limit in line with published Microsoft documentation and allow up to 96 sections. Looking through winnt.h there doesn't appear to be a good macro for this. Is anyone aware of an existing variable/macro that could be used for this instead of a magic number?

Command-line test case

C:\> x86_64-w64-mingw-gcc helloworld.c -o helloworld.exe
C:\> x86_64-w64-mingw-gcc -shared library.c -o library.dll
C:\> setdll64.exe /d:library.dll helloworld.exe
Adding library.dll to binary files.
  helloworld.exe:
DetourBinaryOpen failed: 192

C:\> x86_64-w64-mingw-strip helloworld.exe
C:\> setdll64.exe /d:library.dll helloworld.exe
Adding library.dll to binary files.
  helloworld.exe:
    library.dll
    KERNEL32.dll -> KERNEL32.dll

Detours version Version 4.0.1 of Detours (https://github.com/microsoft/Detours/commit/734ac64)

Building and running the sample client bin.X64\cping.exe /i /l localhost, I got a divide by zero exception at this line:

s_rllCycles[E_DCOM] /= s_rllCounts[E_DCOM];

Not sure why. Some issue with incorrect CPU-speed calculation? But I patched it like this:

--- a/samples/cping/cping.cpp 2022-12-24 09:26:38
+++ b/samples/cping/cping.cpp 2022-12-24 12:55:27
@@ -384,14 +384,19 @@
     DumpCycles(E_NET);
 #endif

-    s_rllCycles[E_DCOM] /= s_rllCounts[E_DCOM];
-    s_rllCycles[E_RPC] /= s_rllCounts[E_DCOM];
-    s_rllCycles[E_UDP] /= s_rllCounts[E_DCOM];
-    s_rllCycles[E_NET] /= s_rllCounts[E_DCOM];
-    s_rllTotals[E_DCOM] /= s_rllCounts[E_DCOM];
-    s_rllTotals[E_RPC] /= s_rllCounts[E_DCOM];
-    s_rllTotals[E_UDP] /= s_rllCounts[E_DCOM];
-    s_rllTotals[E_NET] /= s_rllCounts[E_DCOM];
+#define SAFE_DIV(res, div) do {             \
+                             if (div)       \
+                                res /= div; \
+                           } while (0)
+
+    SAFE_DIV (s_rllCycles[E_DCOM], s_rllCounts[E_DCOM]);
+    SAFE_DIV (s_rllCycles[E_RPC], s_rllCounts[E_DCOM]);
+    SAFE_DIV (s_rllCycles[E_UDP], s_rllCounts[E_DCOM]);
+    SAFE_DIV (s_rllCycles[E_NET], s_rllCounts[E_DCOM]);
+    SAFE_DIV (s_rllTotals[E_DCOM], s_rllCounts[E_DCOM]);
+    SAFE_DIV (s_rllTotals[E_RPC], s_rllCounts[E_DCOM]);
+    SAFE_DIV (s_rllTotals[E_UDP], s_rllCounts[E_DCOM]);
+    SAFE_DIV (s_rllTotals[E_NET], s_rllCounts[E_DCOM]);

PR for Bug: Error process of GetQueuedCompletionStatus in syelogd.cpp. https://github.com/microsoft/Detours/issues/264

Microsoft Reviewers: Open in CodeFlow