I have a dll and i wish to create a detour to one of its exported functions,
The dll is not part of windows.
I need to be able to call the real function after my detour (call the real function from a detoured one)
I know the exact signature of the function.
I already have been able to detour the function, but right now i can't call the real one.
I realize i need to use a trampoline function, I've seen examples online.
the problem is: all those examples show how to detour a windows API function, i need to do the same for a function i get thorough a dll import.
any help would be welcomed
--edit
just to clarify, I have attempted to call the original function by its pointer, but that does not work.
also tried using the method from this stack overflow article
that doesn't even crash but it looks like it goes into to an infinite loop (i assume because in the original function there is a jump to the detoured one)
edit -- solved!
not sure what solved it,
used this as reference.
stopped using getProcadder and instead started using DetourFindFunction instead
cleaned up the code (pretty sure i cleaned out whatever caused the issue)
works,
thanks anyway
I don't use detours(I actually detest it!), but detouring any non hot-patchable function can be done in a generic manner, like so:
Sstep 1:
insert a JMP <your code> at the start of the function, takes 5 bytes, probably a little more to align to the nearest instruction. as an example
the start of the function to hook:
SUB ESP,3C
PUSH EDI
PUSH ESI
//more code
would become:
JMP MyFunction
//more code
one would do this by writing 0xE9 at the first byte then writing the value (function_addr - patch_addr + sizeof(INT_PTR)) in the following DWORD. writing should be done using WriteProcessMemory after setting Read/write/execute permissions with VirtualProtectEx
Step 2:
next, we create an assembly interface:
void __declspec(naked) MyFunc()
{
__asm
{
call Check ;call out filter func
test eax,eax ; test if we let the call through
je _EXIT
sub esp,3c ; its gone through, so we replicate what we overwrote
push edi
push esi
jmp NextExecutionAddress ; now we jump back to the location just after our jump
_EXIT:
retn ; note, this must have the correct stack cleanup
}
}
NextExecutionAddress will need to be filled at run time using ModuleBase + RVA.
To be honest, its way easier, and better(!) to just EAT (Export Address Table) hook the export table of the dll, or IAT (Import Address Table) hook the import tables of whats calling the funcs you want to filter. Detours should have functions for these type of hooks, if not, there are other freely available libs to do it.
The other way would be to use detour to hook every call in the apps using the dll to reroute them to a proxy function in your own code, this has the advantage of allowing one to filter only certain calls, and not everything across a binary(it is possible to do the same using _ReturnAddress, but thats more work), the disadvantage though is capturing the locations to patch(I use ollydbg + a custom patching engine) and it won't work on non-regular calling convention functions(like those made with #pragma aux in Watcom or the optimized calls generated by VC7+).
One important thing to note: if your hooking a multithreaded app, your patches need to be done with the app suspended, or be done attomically use InterlockedExchange, InterlockExchange64 and InterlockedExchangePointer(I use the latter for all IAT/EAT hooks, especially when hooking from a 'third party process')
Looking at the post you link to, the method there is horrible in my opinion, mainly due to the assmebly :P but, how are you calling this pointer you obtain, and how is it obtained?
Related
Is there any way with MSVC to read a specific 64 (or 32) bit register directly in a normal C++ function?
For example, can I read the contents of r10 somehow via any intrinsics or such?
For context:
I'm implementing a variadic function (lets call it my_func), which needs to forward its call to another variadic function, and add one more argument along the way (an ID if you will, any numeric type will do - a 16, 32 or 64 bit integer for example, doesn't matter too much).
I need to do this forwarding in as little instructions as possible, so I can't process the variadic list in the initial function and just forward the va_list or such.
So I've implemented my_func in assembly:
; This function needs to be as compact as possible
my_func PROC
; assume 123 is the ID to be passed along with the arguments that my_func is called with
mov r10, 123
jmp address_of_the_real_target_function
my_func
I just jump to the target function, and pass the ID in a seperate register - R10 in this case.
ARG* the_real_target_function(ARG* arg0, ...)
{
auto id = ReadRegister();
// ... do stuff ...
}
This works well so far - only nuisance being that I needed another assembly helper function to read R10 back in the proper C++ function,
ReadRegister PROC
mov rax, r10
ret
ReadRegister ENDP
which is a bit annoying as that call won't get inlined.
Hence the question - is there any way to read this register directly in C++?
(Otherwise, I was thinking of maybe utilizing SSE registers, which should be readable via intrinsics - but curious if there's a way to do this with just 64 - or 32 - bit registers)
Thanks
--
edit: I believe this is not a duplicate of the linked topic. Listed solutions in there are specific to other compilers, or in case os MSVC, 32-bit only (inline assembly is not supported on x64)
--
edit 2: For more context on why I'm trying to do this.
This is indended to be an Excel Addin (which will host plugins and expose their functions to Excel, basically).
In order to register a function in Excel, I need to bind it to a specific function exported by my DLL. I don't know in advance (= at compile time) how many, or what plugin functions need to be registered and called.
So I need to implement loads of exported functions - thousands. Enough to always have registration slots for all plugins available.
In order to keep the overall size of the DLL in check, I need the registered functions to be very slim, and ideally also be capable of dealing with variadic args (as I don't know what shape the plugin functions have at compile-time; and due to the space-constraints, I want to avoid creating callbacks for any possible aririty of arguments)
And for even more added fun, it needs to work in x64 and x86 - though in the latter case, the function is called by Excel via stdcall convention, so the usual C++ variadic args won't work. But, at least at runtime I can find out the number (and type) of args passed to the function, so I should be able to handle the stack myself.
So bottom line, my idea is to have these slim trampoline functions, which will forward all arguments, plus their ID, to some central handler (as per above in X64; and via stack in X86).
The handler then gets things a bit into order - i.e. creates some standardized iterator for the arguments, calls the actual plugin function registered via that ID etc.
static thread_local variable would take few instructions, so it is not that slim as you may want.
Yet it would be fully portable.
There's less portable but more instruction-efficien way.
Notice Arbitrary data slot in TEB.
So __readfsdword(0x14)/__writefsdword(0x14) on x86 and __readgsqword(0x28)/__writegsqword(0x28) on x64 may do this trick. If, well, no one else is using the same extra space for other purpose.
Intel CPU
Windows 10 64bit
C++
x86 assembly
I have two programs, both written by me in C++. For the sake of simplicity I will refer to them as program A and program B. They do not do anything special really, I am just using them to test things out and have some fun in the process.
The idea is that program A injects code into program B and that injected code will set the parameters of a function in program B and will call a function in program B.
I must say I have learned a lot from this experiment. As I needed to open up a handle to a process with proper permissions and then construct assembly code to inject, call it with CreateRemoteThread and clean up afterwards.
I ve managed to do this and call a function from program B and that function takes one parameter of type UINT64.
I do this by injecting the following assembly code:
b9 paramAddr
e8 funcAddr
c3
By calling this code snippet from program A with CreateRemoteThread in program B I manage to call a function at an address and with a parameter passed. And this works fine. Nothing too complex just call a function that takes one param. One thing to note here is that I have injected the parameter prior to this code and just provided a parameter address to b9.
Now what I am failing to do is call a function in program B from program A that takes two parameters.
Function Example:
myFunction(uint num1, int num2)
The procedure for injection is the same, and all that works just fine windows API provides plenty of well documented functionalities.
What I do not seam to be able to do is pass the two parameters to the function. This is where my troubles begin. I have been looking at x86 assembly function call conventions. And what they do is either just
push param2
push param1
call functAddr
retn
or
perform a mov to esi
Could anyone please clarify,explain and provide a clear example of how to call a function in x86 assembly that takes two parameters or type uint and int.
Thank you all for your time and effort.
Since you are looking for a way to understand and clarify what is happening internally, I recommend to start with generating an assembler file for the specific machine you are working with. If you are using gcc or g++ you can use the -S flag to generate the associated assembler files. For the beginning you can implement a function with two arguments and call that function inside your main function. Using the assembler files, you should get a really good picture of how the stack is filled before your function is called and where your return value is put. In the next step you should compare what you see in the assembler file with the x86 calling convetion.
I have been doing research into Windows internals, and have just recently learned about system calls and I am wondering if it is possible to use these system calls like functions? I understand they aren't really meant to be accessed externally.
For instance: NtUserEmptyClipboard is a system call in Win32k.sys, and it's address is 0x117f
If I wanted to use this call like a function, how could I do so?
What you want to do depends heavily on the architecture you're interested, but the thing to know is, that ntdll.dll is the user-mode trampoline for every syscall - i.e. the only one who actually makes syscalls at the end of the day is ntdll.
So, let's disassemble one of these methods in WinDbg, by opening up any old exe (I picked notepad). First, use x ntdll!* to find the symbols exported by ntdll:
0:000> x ntdll!*
00007ff9`ed1aec20 ntdll!RtlpMuiRegCreateLanguageList (void)
00007ff9`ed1cf194 ntdll!EtwDeliverDataBlock (void)
00007ff9`ed20fed0 ntdll!shortsort_s (void)
00007ff9`ed22abbf ntdll!RtlUnicodeStringToOemString$fin$0 (void)
00007ff9`ed1e9af0 ntdll!LdrpAllocateDataTableEntry (void)
...
So, let's pick one at random, NtReadFile looks neato. Let's disassemble it:
0:000> uf ntdll!NtReadFile
ntdll!NtReadFile:
00007ff9`ed21abe0 4c8bd1 mov r10,rcx
00007ff9`ed21abe3 b805000000 mov eax,5
00007ff9`ed21abe8 0f05 syscall
00007ff9`ed21abea c3 ret
Here, we see that we stuff away rcx, put the syscall number into eax, then call the syscall instruction. Every syscall has a number that is assigned arbitrarily by Windows (i.e. this number is a secret handshake between ntdll and the kernel, and changes whenever Microsoft wants)
None of these instructions are "magic", you could execute them in your app directly too (but there's no practical reason to do so, of course - just for funsies)
EmptyClipboard is one of so-called "Win32 API" and NtUserEmptyClipboard is a corresponding "native API".
http://en.wikipedia.org/wiki/Native_API
Unlike Linux syscall(2), we are rarely supposed to directly call "native API". I heard they are in ntdll.dll rather than win32k.sys. But we should be able to invoke them just like normal functions defined in a normal DLL.
Is there any way to call the Windows Native API functions from the user mode?
I strongly doubt that 0x117f is the address you're looking for. I suspect it might be the value which you need to pass to GetProcAddress. But I don't know for sure, since those things vary across Windows versions (that's why ordinary people use documented functions instead)
The main part of the native API is exported via normal functions from ntdll.dll. You can load this dll into your process and call these functions just like any other API functions. As long as you have the right function prototypes and parameters, the calls will work just fine. What they do internally is transition from usermode to kernelmode and then they use an offset into the system service descriptor table (SSDT) to find the address of the function in kernel mode memory, and then the function is called. There is an open source project http://nativetest.codeplex.com/ that makes calls to the native api that you might refer to.
The functions in win32k.sys are not exposed in ntdll.dll. As far as I can tell they are not exposed anywhere. The address you have listed - I believe - is actually an offset into the SSDT. If you really needed to call this function, you would have to make the transition from usermode to kernelmode yourself, putting all the parameters for the function and the SSDT offset into the right places.
As others have recommended, I would suggest to find the usermode API to help accomplish what you want to do. FWIW, in user32.dll the function EmptyClipboard appears to forward directly to NtUserEmptyClipboard, according to the link /dump output.
1731 DF 0002018A EmptyClipboard = _NtUserEmptyClipboard#0
I have decompiled a dll and I want to replace a call to a function in the DLL with call a custom function created by me (with the same signature) instead.
I have managed to find where the function is called in assembly. Could anybody explain what I need to do now?
Can my custom function be located in a separate dll or does it need to be included in the same dll?
How can I call replace the function call with my new one?
Thanks
Might be easier to just patch the executable module. Add your new code to the end of the text segment and place a jump to your added code at the beginning to the old function. This way you don't have to deal with problems the decompiled version of the DLL may cause.
For example here is the beginning of the existing function you want to replace:
000D0880 push ebp
000D0881 mov ebp,esp
000D0883 sub esp,0E0h
000D0889 push ebx
000D088A push esi
000D088B push edi
000D088C lea edi,[ebp-0E0h]
000D0892 mov ecx,38h
000D0897 mov eax,0CCCCCCCCh
To redirect the call just add a JMP instruction at D0880. We add NOP instructions after the jump just to make the disassembled output cleaner during debug sessions. It's not necessary but it does come in handy.
000D0880 jmp NewFunction
000D0885 nop
000D0886 nop
000D0887 nop
000D0888 nop
000D0889 push ebx
000D088A push esi
000D088B push edi
Now you append your new code to the end of the text segment and calculate the address based on the offset where the segment is loaded. This makes it much easier to debug and manage since you know beforehand exactly where in the text segment your function actually resides.
To call either function from another in-process executable module can also be done. Since you already know the offsets of both the original function and the next function you can calculate their exact location based on the load address of the module.
typedef void (*EXTPROC)(int a, int b);
// Windows loads the dll at 0xC0000
HMODULE hMod = LoadLibrary("some.dll");
// The function is at offset 0x10880 (from start of text segment)
EXTPROC proc = CalculateAddress(hMod, 0x00010880);
// Call proc at 0xd0880
proc(0, 1);
The function CalculateAddress retrieves the base address of the DLL and calculates the actual address of the function and returns pointer to it. The result is the same as in the earlier example - 0xD0880. Now that you have the address you can call it through the function pointer. You can apply the same technique to call the new function you are adding as you know the offset of that function as well.
If you wanted to go the extra mile you could even update the export table with new entries pointing to those offsets and use GetProcAddress to retrieve the address without having to calculate it yourself. This adds a bit more complexity to the patching process since you have to update an additional section in the DLL.
To call a function that exists in a different DLL is a bit more complex as you would need to do a runtime patch of the original function to make it call the address of the external one. For this I recommend looking into the suggestion made by Rich and create a proxy DLL as described in this article.
I don't know assembly so I'm not sure how to go about this.
I have a program which is hooking into another. I have obtained the offset to where the function is located within the hooked program's .exe
#define FuncToCall 0x00447E5D
So now how can I use __asm{} to call that function?
Well short answer is if you do not know assembly you should not be doing this, haha.
But, if you are so intent on wall hacking, I mean, modifying the operation of a legitimate program, you can't just take an address and call it good.
You need to look up the symbol (if in happy linux land) or use sig scanning ( or both D= ) to find the actual function.
Once you do that then its relatively simple, you just need to write a mov and jmp. Assuming you have access to the running process already, and your sig scanner found the right address, this bit of code will get you want you want
mov eax, 0×deadbeef
jmp eax
Now, if this function you want is a class method.. you need to do some more studying. But that bit of assembly will run whatever static function you want.
There is some mess to deal with different calling conventions too, so no commenters try and call me out on that, that is far to advanced for this question.
EDIT:
By the way I do not use call because when using call you have to worry about stack frames and other very messing things. This code will jump to any address and start executing.
If you want to return to your code thats another story, but that WILL get your target function going as long as its the right calling convention, not a class method, etc etc
I think you could also cast that address to a function pointer and call it that way. That might be better.
Thanks for answers, but I figured it out. This is what I'm doing:
#define FuncToCall 0x00447E5D
DWORD myfunc = FuncToCall;
__asm call dword ptr [myfunc];
If it works don't fix it, and by golly it works.
Here is a tricky one:
You can use it with parameters and return value too. It simply forwards everything to the function you intend to call that is given by a pointer (FuncToCall) to the function.
void call_FuncToCall(.......)
{
__asm__
("call label1\n label1:\n"
"pop %eax\n"
"movl FuncToCall, %eax\n"
"leave\n"
"jmp *%eax");
}