Creating a Loader to modify a DLL file

i just set it to load the exe and then set the patch data to the offest of the .dll

Hello,

I don't understand the problem here.

The dll will be loaded in the SAME context than the EXE file.
Therefore, you could patch the dll if you could control the EXE file code.

But what you can just do, is CreateProcess the EXE file, and then, instead of providing a VA inside the Target EXE (which you don't want to do, since you want to patch the dll), you just provide a VA inside the DLL to WriteProcessMemory, and since , the dll is in the same Address space (context) than the EXE file, you writeprocessmemory will work, and thus, you will be patching your protected dll without problems.

Cheers.

I just use this trick

just use Process Patcher v3.60
Search memory address you want to patch and create Process Patcher v3.60
it's will patch memory on the fly.

see my attachment in powerbasic source (to enable official counter-strike 1.6 bots.)

I use this trick, convert Process Patcher v3.60 to hex and store inside the source code. see the source for detail.

this how i create loader/launcher.

You can use CreateProcess to create The Process itself..Depending on the OS the Dlls are loaded by then,or arent. For an NT based OS i would Create the Process, put an EBFE on the Entrypoint, execute it and catch it to make sure all Dlls are proper loaded. The you loop the loaded Modules with the ToolHelp Functions and compare the Dllnames with the Name of the Dll you seek. The Toolhelp Functions will also return the BaseAdress, so you can use that with a Distance Value to patch your Stuff.

[vrclr27]

There are also some interesting articles on this subject in:
help://bib.universitas-virtualis.org

Sorry, not in the library but part of the CodeBreaker Mag. at same location

[Newbie_Cracker]

OK guys, lets ask the question a little different.
Think we have a program and its serial-check routine, is in a DLL which is in its resource. Program runs and after a few seconds, loads the DLL and read a function from it.
Using constant address for writing to memory is not possible. Because the addresses change.

Now, how could we get some RVA in DLL to calculate the patch address?
I can get DLL ProcessID after showing some window, but couldn't get one of its fucntion address or its OEP in memory.

[Shub-Nigurrath]

I did it simpler. I coded a stub for the real dll: a new dll exposing the same methods of the original dll, eventually through export forwarding if you don't know the original DLL prototypes.

from matt Pietrek..

Export Forwarding
A particularly slick feature of exports is the ability to "forward" an export to another DLL. For example, in Windows NT®, Windows® 2000, and Windows XP, the KERNEL32 HeapAlloc function is forwarded to the RtlAllocHeap function exported by NTDLL. Forwarding is performed at link time by a special syntax in the EXPORTS section of the .DEF file. Using HeapAlloc as an example, KERNEL32's DEF file would contain:

EXPORTS
•••
HeapAlloc = NTDLL.RtlAllocHeap

How can you tell if a function is forwarded rather than exported normally? It's somewhat tricky. Normally, the EAT contains the RVA of the exported symbol. However, if the function's RVA is inside the exports section (as given by the VirtualAddress and Size fields in the DataDirectory), the symbol is forwarded.
When a symbol is forwarded, its RVA obviously can't be a code or data address in the current module. Instead, the RVA points to an ASCII string of the DLL and symbol name to which it is forwarded. In the prior example, it would be NTDLL.RtlAllocHeap.

The what I did is to code my DllMain and insert the patching code into the DLL_PROCESS_ATTACH case.

The patched code does these things:
-load the original renamed library (with a leading _ )
-initialize the exports I would to overwrite (if any) through GetProcAddress.
-patch the memory of the DLL (through the handle returned by loadLibrary).
-exit from Dllmain

in the case I wanted to change some of the original Dll's export behaviour I also coded a function with the same prototype of the original one, which do required tricks and after call the original export.

Doing this way I was able to easily code a loader for a asprotected dll which pathces in memory all the nags and insert some missing code, stolen by asprotect.