   Overloading DLL Function?
  I have a function that I load from a DLL that gets a message from a server. That function then automatically sends a message to delete that message from the server (i.e, to stop waiting for a listening client).However, I'd like that function to get the message from the server, and preserve that message for other clients that are listening.Is there a way to get the assembly code for that function and then overwrite it with my own in which it doesn't make the "delete" call?I believe something like this is possible, because I've seen an application that uses this same interface do it, and he has some kind of binary file that seems to overwrite that call. There's the possibility that he's doing it another way, but I think it's more likely to be something like I've stated.Thanks,Jengerer   
  It would probably easier to reverse engineer the protocol with which the dll communicates with the server. You can attempt this by capturing the network traffic and observing the captured data for relevant packets. However:This may be illegal, depending on your country's laws and the license agreement of the DLL (and the service)The protocol could be encrypted. This would make it more difficult to reverse engineer since the packet data wouldn't be in a clear format.It is also possible to inject code to the address space of a process. This can be done in several ways:DLL proxying, a technique in which a DLL to be loaded by a process gets replaced by a custom DLL that implements all the same entrypoints as the original DLL. The custom DLL can then interpret the calls from the hosting app and either forward them to the original DLL or discard them as the programmer sees fit.Debugging, by using OpenProcess, ReadProcessMemory, WriteProcessMemory etc.. You need very solid understanding of how the operating system loads and executes opcodes, and of the code format itself.Driver proxying, in which you write a driver layer over the network interface and interpret the calls from the app. This is also difficult, but for slightly different reasons than the previous technique.This is not an exhaustive list, but these are the commonly feasible approaches.   ;Quote:Original post by Nik02DLL proxying, a technique in which a DLL to be loaded by a process gets replaced by a custom DLL that implements all the same entrypoints as the original DLL. The custom DLL can then interpret the calls from the hosting app and either forward them to the original DLL or discard them as the programmer sees fit.Wow, thanks for the great reply. I think the option that I quoted is likely what I need to be able to pull this off (debugging seems like a feasible, but much more risky option). Are there any online or offline resources I could use to help me better understand DLL proxying and how I'd go about implementing it?Thanks again,Jengerer   ;  How much control do you have over the DLL?  Obviously no source, but can you be certain it won't change version on you?  If not, it should be pretty easy just to wipe out the relevant code that sends the message out by figuring out the relevant addresses and writing over them with nop's.   ;Quote:Original post by AmrazekHow much control do you have over the DLL?  Obviously no source, but can you be certain it won't change version on you?  If not, it should be pretty easy just to wipe out the relevant code that sends the message out by figuring out the relevant addresses and writing over them with nop's.It's highly likely that the changes made to the DLL won't affect this, and even if it does, I can just pop out a new version that handles the newer one. Could you elaborate on how I'd wipe out the relevant code?   ;  I tinkered a little bit testing it out and it should actually be pretty easy to do, depending on how the DLL is layed out.I wrote a little function with some functionality I wanted, and some I didn't:(DLL)PLUGINFNintTargetFunction(int input) {input += 10;input *= 2;return input;}I wanted to keep the addition but remove the multiplication.intnormalOut = TargetFunction(10); // normalOut should equal 40// attempt to modify TargetFunction.  Goal: remove multiplication// Locate addressHMODULEhDll = GetModuleHandle("MyPlugin.dll");BYTE*pFunctionStart = (BYTE*)hDll + 0x113E0;// found base offset using depends or hex editor.  Actually// the original address for this function// is an import jump to offset 0x113E0// base+113E0 runs to a ret at base+11418. SIZE_TtargetFunctionSize = 0x11418 - 0x113E0;// length of original function// wipe out the bits of the function which result in the // multiplication being done (0x1140A -> 0x1140F)DWORD dwBack = 0;VirtualProtectEx(GetCurrentProcess(), (LPVOID)pFunctionStart, targetFunctionSize, PAGE_EXECUTE_READWRITE, &dwBack);SIZE_T nbWritten = 0;BYTE nopBuf[1] = {0x90};for (int offset = 0; offset < (0x1140F - 0x1140A); ++offset) {BYTE*p = ((BYTE*)hDll + 0x1140A + offset);WriteProcessMemory(GetCurrentProcess(), (LPVOID)p, nopBuf, 1, &nbWritten);}VirtualProtectEx(GetCurrentProcess(), (LPVOID)pFunctionStart, targetFunctionSize, dwBack, &dwBack);// see what happensintmodifiedOut = TargetFunction(10); // returned 20, mission accomplishedThis is pretty brute-force though.  Actually, if you were to do this in a live program I'd VirtualAllocEx some memory, copy the entire function over there and modify it there.  Then use something like microsoft detours to make sure you get the function rerouted properly.  Now that brings up yet another idea: you could actually save the current version's asm code just in a BYTE array, copy from there instead of the actual function so you're always modifying the same version of the function, and then detour the (possibly different) function in the DLL after patching up any invalid pointers or jumps in the original code.  That'd be pretty clever too, but might backfire if any functionality that function requires in the DLL changes   ;Quote:Original post by Amrazek/snipWow, that's awesome, thanks. That suggestion to save the function bytes to file is definitely a good idea. I'm going to try to find the offset for the function and its size, and then I'll tinker around and hopefully get it working. Thanks again.   ;  Note that the HMODULE internal representation might change in future versions of Windows, since the type is meant to be used as an abstract handle. As of now, it is indeed implemented as the actual address of a module in the virtual address space of the current process. In practice, I believe that Microsoft is not going to drastically alter this situation in the near future.Also, 64-bit Windows implement address space layout randomization so the DLL procedure addresses are potentially a moving target. That said, this behavior is off by default for custom libraries.It is of course possible to use GetProcAddress given a procedure name, though, and this is a supported approach.   ;Quote:Original post by Nik02Also, 64-bit Windows implement address space layout randomization so the DLL procedure addresses are potentially a moving target.So since the addresses may shift around, would it be best to save the altered version of the function bytes to a file, use GetProcAddress when the application opens up, and rewrite it each time (or write over a copied version)?The only problem with GetProcAddress is that since I'm not seeing the actual assembly of the function, I can't tell what the size of the function is, or what's happening in the actual function.I tried throwing a breakpoint onto the line in my application that calls that function, and then when I view the disassembly, this is what I see./* Get the message. */...m_pCoordinator->RetrieveMessage(messageID, messageBuffer, iSize, sizeReal);00426B69  mov    edx,dword ptr [sizeReal] 00426B6C  push   edx  00426B6D  mov    eax,dword ptr [iSize] 00426B70  push   eax  00426B71  mov    ecx,dword ptr [messageBuffer] 00426B74  push   ecx  00426B75  mov    edx,dword ptr [messageID] 00426B78  push   edx  00426B79  mov    eax,dword ptr [this] 00426B7C  mov    ecx,dword ptr [eax+10h] 00426B7F  mov    edx,dword ptr [this] 00426B82  mov    eax,dword ptr [edx+10h] 00426B85  mov    edx,dword ptr [ecx] 00426B87  mov    ecx,eax 00426B89  mov    eax,dword ptr [edx+8] 00426B8C  call   eax  }But then I realized that since I threw the breakpoint on the function, it likely never actually finished calling RetrieveMessage, and stopped the function at the call, so this is simply just the assembly for calling the function. Even if I try throw the breakpoint after the function call, I get the same assembly for that part.Then I tried opening the DLL through OllyDbg to attempt to find it, but I can't seem to even be able to locate the function in there (I haven't used it very much, so it could be a product of inexperience).[Edited by - jengerer on April 10, 2010 10:59:18 AM];Quote:Original post by Nik02Also, 64-bit Windows implement address space layout randomization so the DLL procedure addresses are potentially a moving target. That said, this behavior is off by default for custom libraries.It is of course possible to use GetProcAddress given a procedure name, though, and this is a supported approach.My technique should still work even with random layout, as the addresses used are offsets within the DLL and not real addresses by themselves. @jengerer, that looks like the assembly to call the function in your DLL.  Checking out ecx should lead you to the RetrieveMessage function (you can see it putting arguments on the stack in reverse).  I assume RetrieveMessage is the target, so you'll be interested in all asm instructions from the address in eax in your calling code to a return statement of some kind.I found OllyDbg confusing too, and actually used the disassembler in a program called Cheat Engine to do the work.   