Exetools  

Go Back   Exetools > General > Source Code

Notices

Reply
 
Thread Tools Display Modes
  #1  
Old 08-21-2017, 16:58
atom0s's Avatar
atom0s atom0s is online now
Family
 
Join Date: Jan 2015
Location: 127.0.0.1
Posts: 433
Rept. Given: 26
Rept. Rcvd 130 Times in 67 Posts
Thanks Given: 54
Thanks Rcvd at 840 Times in 307 Posts
atom0s Reputation: 100-199 atom0s Reputation: 100-199
Here is another way you can make a proxy fairly easy and slim. Since you do not need to know the actual function prototype/parameters when exporting things that are just using direct jumps via inline asm, you can mix and abuse macros with inline asm to export things easy.

PHP Code:
#include <Windows.h>

HMODULE g_ModuleHandle nullptr;       // This proxies module handle.
HMODULE g_RealModuleHandle nullptr;   // The real modules handle being proxied.

/**
 * Obtains the original export from the real module.
 */
BOOL APIENTRY GetRealExport(const charnameFARPROCout)
{
    
// Ensure the real module is loaded..
    
if (g_RealModuleHandle == nullptr)
        return 
FALSE;

    
// Todo: Add any type of function caching if you want here..

    // Obtain the real export function..
    
*out = ::GetProcAddress(g_RealModuleHandlename);
    return (*
out == nullptr);
}

/**
 * Generates an export function wrapper for the given exported function by name.
 */
#define EXPORTORIG(n)                               \
    
FARPROC orig_##n = nullptr;                     \
    
__declspec(nakedvoid __stdcall real_##n() {   \
        
GetRealExport(#n, &orig_##n);               \
        
__asm jmp orig_##n                          \
    
}

EXPORTORIG(Direct3DCreate9);

/**
 * Initialize the proxy for use.
 */
BOOL APIENTRY InitializeProxy(HINSTANCE hinstDLL)
{
    
// Store the modules handle..
    
g_ModuleHandle hinstDLL;

    
// Build the path to the original module..
    
char path[MAX_PATH] = { };
    ::
GetSystemDirectory(pathMAX_PATH);
    
strcat_s(path"\\d3d9.dll");

    
// Load the original module..
    
g_RealModuleHandle = ::LoadLibrary(path);
    if (
g_RealModuleHandle == nullptr)
        return 
FALSE;

    return 
TRUE;
}

/**
 * Entry point.
 */
BOOL APIENTRY DllMain(HINSTANCE hinstDLLDWORD fdwReasonLPVOID lpvReserved)
{
    switch (
fdwReason)
    {
    case 
DLL_PROCESS_ATTACH:
        ::
DisableThreadLibraryCalls(hinstDLL);
        return 
InitializeProxy(hinstDLL);
    }
    return 
TRUE;

And in the .def file:

PHP Code:
LIBRARY
EXPORTS
    Direct3DCreate9 
real_Direct3DCreate9 
Beings that this is using a macro for the dirty work/heavy lifting you can easy create a template/skeleton project to auto-generate the entire proxy dll for you like this just by having it read the original exports from the target file and generating the rest.

Note, this method as-is will have issues with exports that are by ordinal and not by name. You would have to tweak the generated names a tad to work with ords instead.
Reply With Quote
The Following 5 Users Say Thank You to atom0s For This Useful Post:
copyleft (03-10-2020), Indigo (07-19-2019), retro (03-30-2024), tonyweb (08-26-2017)
  #2  
Old 08-21-2017, 17:30
zeffy zeffy is offline
Friend
 
Join Date: Jul 2017
Posts: 44
Rept. Given: 3
Rept. Rcvd 7 Times in 6 Posts
Thanks Given: 215
Thanks Rcvd at 163 Times in 47 Posts
zeffy Reputation: 7
Thank you for sharing your code atom0s! I've used something very similar to it before I created these template projects. The reason I opted to use complete ASM instead of inline is because it isn't supported by VC in x64 builds, only x86.

Additionally, calling your InitializeProxy (and thus LoadLibrary) from DllMain can cause the process to deadlock under certain conditions. For this reason, MSDN specifically advises people not to call LoadLibrary from DllMain. Although I've never encountered it happen in practice, that could change in the future or in edge cases. That's why I opted to delay the loading until one of its functions is actually called. Either approach works though.
Reply With Quote
The Following User Says Thank You to zeffy For This Useful Post:
Indigo (07-19-2019)
  #3  
Old 08-21-2017, 17:34
atom0s's Avatar
atom0s atom0s is online now
Family
 
Join Date: Jan 2015
Location: 127.0.0.1
Posts: 433
Rept. Given: 26
Rept. Rcvd 130 Times in 67 Posts
Thanks Given: 54
Thanks Rcvd at 840 Times in 307 Posts
atom0s Reputation: 100-199 atom0s Reputation: 100-199
Quote:
Originally Posted by zeffy View Post
Thank you for sharing your code atom0s! I've used something very similar to it before I created these template projects. The reason I opted to use complete ASM instead of inline is because it isn't supported by VC in x64 builds, only x86.

Additionally, calling your InitializeProxy (and thus LoadLibrary) from DllMain can cause the process to deadlock under certain conditions. For this reason, MSDN specifically advises people not to call LoadLibrary from DllMain. Although I've never encountered it happen in practice, that could change in the future or in edge cases. That's why I opted to delay the loading until one of its functions is actually called. Either approach works though.
I generally do the same with late loading, generally via exporting an 'Install' function from the main hook and using a loader to invoke it. The example above was just a quick throw together to show off the macro method of making a fast proxy.
Reply With Quote
The Following 2 Users Say Thank You to atom0s For This Useful Post:
Indigo (07-19-2019), zeffy (08-21-2017)
  #4  
Old 08-23-2017, 15:46
zeffy zeffy is offline
Friend
 
Join Date: Jul 2017
Posts: 44
Rept. Given: 3
Rept. Rcvd 7 Times in 6 Posts
Thanks Given: 215
Thanks Rcvd at 163 Times in 47 Posts
zeffy Reputation: 7
Talking

Quote:
Originally Posted by atom0s View Post
I generally do the same with late loading, generally via exporting an 'Install' function from the main hook and using a loader to invoke it. The example above was just a quick throw together to show off the macro method of making a fast proxy.
That's a neat idea about exporting an 'Install' function!

I've actually been working on simplifying my project using macros similar to how you did (except in the assembly), which has made it much easier to maintain compared to before. I also fixed the "random" crashing bug that I referred to earlier (which was caused by stack corruption and some of the volatile registers getting mutilated by my proc resolver function ). If you or anyone else is interested in taking a look, here's an example of the changes I've made:
https://github.com/zeffy/proxydll_te...inmm/winmm.asm

Edit: OK I really fixed the register mutilation now... I was restoring r8 to r9 and r9 to r8 in the last commit.

Last edited by zeffy; 08-31-2017 at 10:10. Reason: really fixed now
Reply With Quote
The Following 3 Users Say Thank You to zeffy For This Useful Post:
Hypnz (08-23-2017), Indigo (07-19-2019), niculaita (08-23-2017)
Reply

Tags
dll, hijacking

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Windows Handle Hijacking TechLord General Discussion 2 05-15-2017 20:11


All times are GMT +8. The time now is 07:36.


Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX, chessgod101
( Since 1998 )