RE:loaders

[hobgoblin]

Hi guys,
I'm trying to make a loader for a program. I have in the past used R!sc's loader maker, but it doesn't seem to work too well on my XP system. What kind of loader maker do you think is the best (recommend as the best) on XP systems?
TIA for input,
hobgoblin

[Kameo]

i used to make my own masm loader but if you want a quick & powerfull tool you should try TPE aka Tola's Patch Engine.
You can perform :
- a stand alone seek n' destroy patch
- a registry patch (keyfile)
- a process loader
and much more with nice gfx and even your own design's template.

Definitely a must have, more info here
hxxp://www.void.gulli.com/tpe/info.php

and there goes the archive, enjoy ^_^

@Kameo
Thnx for the tool

@hobgoblin

I downloaded one universal loader from here:
h**p://k3nny.wz.cz/index.php?stranka=download

Regards,
ferrari

[hobgoblin]

Thanks guys.
regards,
hobgoblin

I really like the Abel loader generator hxxp://www.cheatsmaximal.net/tools3.php

[bolo2002]

know a patcher who's working with arma or aspr?

loader->aspr->unpack aspr in mem->patch bytes->start

never found a working one...

Check yoda process patcher
h**p://y0da.cjb.net

[Zigmund]

I advice you to write the loader by your own...
It's not hard...
Read more in MSDN about
CreateProcess function.
When target process will be created by your loader with CREATE_SUSPENDED flag you whould patch what you want and then resume target process (and his threads).

from _www.woodmann.net/forum/ ... "Asprotect patching exposed"

"Case 1. utilized one of the application's dll files to do my memory patching. Yes, the dll file was also protected with Asprotect, but it seems that the level of protection for dll's is not the same as for the module.exe file.

Case 2. utilized a system dll (msimg32.dll) called by the application to apply the memory patch.

In both cases, the methodology of applying the patch was the same. The timing is one key issue. Having an application that supplies it's own means to patch it (dll) is a good thing. When this option is not available, as in the second case, you can still find a way. Seems, in case 2, the application looks for a couple of system dll's in it's own program folder first, before looking in the usual system32 folder. I found this out by using NTFILMON (a wonderful utility supplied by the folks at www.sysinternals.com). So I used this to my advantage, and copied the rather small 5k system dll (msimg32.dll) into the program folder and applied the patch to it.

As I said before, the timing is the key. Both dll's don't come into play (load), until after both apps have gone through the unpacking/protection schemes of
Asprotect. This allows for more liberal usage of the registers and call stack
without worry of Asprotect, if you need to do so.

Case 1.
Overlay the beginning of the *.dll asprotect code (.aspr section) with:

JMP (*.DLL ADDRESS / bottom of the .aspr code section) to our patches:
NOP
NOP
...
our patches: (in most cases replacing a JNZ instruction with a JMP)
located near the bottom of the *.dll code, but first,
PUSH EDI; save the register
followed by a series of:
LEA EDI,DWORD PTR SS:[MODULE.EXE ADDRESS]
MOV BYTE PTR SS:[EDI],0EB
where module.exe address is the address(es) of the module we are
memory patching too. Note: we are also doing the same here with the
effected *.dll.
...
then,
replace the overlayed bytes at the top of our *.dll
MOV BYTE PTR DS:[<ModuleEntryPoint>],???
MOV BYTE PTR DS:[*.DLL ADDRESS],???
MOV DWORD PTR DS:[*.DLL ADDRESS],???
where ??? is whatever instructions were originally overlayed
then,
POP EDI; restore the register
then,
JMP Copy_of_.<ModuleEntryPoint>
we jump back to the top of the *.dll file and execute the original
code.
This is a one-time patch, where once the *.dll is called and our
memory patching has been executed, the *.dll's original code
that has been restored will execute. Our memory patched code
will execute only once.

Case 2. Samething, however your patches can be applied to the more
normal text/code section (i.e. there is no .aspr section).

There is no need to use procdump or any utility to expand
the code. The changes I describe (using any hex editor) can be made
directly. I have one caveat. In case 1, I hard coded a base address on the *.dll file using a pe editor. In the second case, the system *.dll file had a hard coded base address. So I admit, I used direct addressing in my lea instructions.
So the issue of relocatability still needs to be addressed, also, the memory
addresses of *.dll files on different operating systems. I am using winxp
pro. That's where you folks come in. The point being, that sometimes we
can make use of already linked *.dll files and not have to use an external
program (loader?) to memory patch the code...."

i have never been able to make aworking loader with TOLA's Patchengine , neither using window caption or class name ...does anyone knows how to use it?

i have tried even on program which are no packed but always some message error appears on the loader when executed ..does it really works?