Probably most of you have written this kind of loader b4 but here is my question?
I want to write a loader which fires the app then wait for a debug signal(LOAD_DLL_DEBUG_INFO) and then find out if this is the right dll and then patches one of it's functions.
I have seen stones tut on this but i couldn't understand it.
Please just try to give an actual source code or tutorial coz i know in general what have to be done

interesting topic .. i always have seen loaders for .exe files and never .dll or .ocx is there a possible way to make a memory patch(loader) like Risc process patcher does but in .dll files?? in case NOT.. then what other ways we can take to patch a .dll in memory like using a loader for targets been packed or protected some how.

Of course it is possible. I don't think it exists but it seems to be easy to code...
Just code a program which will run the process you have to patch in memory and who uses the dll ( a loader ) then enumerate the modules using Module32First/Module32Next, find the dll you want to patch, determine the address of the patch ( use the difference between the patch location and the image base of the dll ) and that's all.

SynApsus can you give us a source code?
can we use the rva in a dll as an offset to apply patch?Is this rva different in every machine?
I made a simple patch(in a dll)and it worked both in xp and 98 and i want to know wether it is general or not?

No, I will not provide source code lol. Find it by yourself !
Some tips to help you :
** Reversing
- Find the bytes to modify and notice the RVA where u will have to patch. This RVA can change very easily ! So you will have to substract the imagebase of the dll and the RVA you just noticed ( do all that in the disassembler ! do not substract the RVA you get in the debugger and the image base of the PE header because the image base of a dll can change when loaded, and the datas will be redirected with the relocations ) Keep this number somewhere : IT will never change. ( if we suppose the location of the patch is not in an dynamically allocated space hehe )

** Patching
- Load the process using the Debug Apis and CreateProcess etc
- Freeze it at each LOAD_DLL_DEBUG_EVENT debug event
- check if this loaded dll is the one you want to patch
- if it is, use the lpBaseOfDll member of ur LOAD_DLL_DEBUG_INFO struct
to retrieve the module handle ( real image base in memory atm ) and add it
the number we noticed.
- Now you can use the writeprocessmemory function to write to the dll in the
debuggee process, just when loaded...

lol, I have not given you the source code but not far of it !

this is not so easy for someone who dosen't know about coding at all .... would someone else provide source code/ or a tool able to do this task .. i'm newbie...i don't think i will be able to handle this .. maybe someday with free time i'll learn some coding tricks

Hello,

Please find attached a very basic working prototype 'C' program that should work for you
with some minor changes. It does the basic Create Process / Wait for debug event /
Is this the event I'm looking for? / Continue debug event / cycle.
I used this prototype to memory patch a program (protected by a latter version
of Asprotect) based on the timing/loading of a *.dll similar in context to what
you are looking for.
Once you familiarize yourself with the process, you should not have any trouble
adapting to patch a *.dll vs an *.exe as I have done.
Note: this program was written to run on winxp:
A) makes use of the psapi.dll which allows for enumerating modules within a
process. If you don't have version winnt 4.0 or greater, than you
will probably need to use the toolhelp32 snapshot method as
SynApsus mentions. There is plenty of information out there to
show you how to do this.
B) makes use of DebugActiveProcessStop API only valid for version winxp and
greater. This API allows for the debugger to detach from the process
you loaded (your target app). Sweet.
C) you may need to explicitly include c:\path\psapi.lib (for psapi.dll) in the link step to avoid any reference type errors.
I am partial to this approach as it eliminates the need to use a process dumper, pe editor
tool, worry about CRC checking, or having to rebuild an IAT. The choice
is yours.
I would be very interested in hearing of your success.
Good Luck!