[Discuss] New dll injection technique

[.::SCHiM::.]

Hi guys, I'm back with something new again

What it does

So besides the 3 previously known dll injection techniques:

1. CreateRemoteThread & WriteprocessMemory (manual mapping)
2. Windows hooks
3. CreateRemoteThread & LoadLibAddress (most injectors use this method)

I've made a new technique. It's a flavor between 1 & 3, but the CreateRemoteThread is removed. leaving only dead code injection. I'd like to call it: Trap laying

The idea behind this technique is to use pattern detection/analysis to find loops and put jump codes into loops that seem likely to be executed. The jumps all go to a stub that calls LoadLibrary() from kernel32.dll. Then removes the patches, and puts the original code back in place.

Of course you can also just provide an address from which you know it's going to get executed allot of times.

Why do it like this?

If you were going to say that this method is unreliable, risky, a race condition and hard to do , I would tell you that you're absolutely right. But some time ago I needed to inject code into system processes, and all other means of injecting code failed me.

Windows is paranoid about it's system processes, but I found out that you can write and read to and from system processes, so that's why I developed this little tool

How does it work

That's easy, again I'm going to provide you with pseudo code and an explanation:

Injector code:

where Address = Base address of target function
where PatchToStub = a function to relay the code to the dll loader stub and update addresses and data inside the stub

for(int i = 0; Address[i] != JUMP OPCODE, CALL OPCODE, RET OPCODE; i++);
if( Address[i] == RET OPCODE){
       if(Address[i-1] != PUSH OPCODE){
    StartOver();
}
}
PatchToStub(Address[i], StubAddress, DLL name);
StartOver()

Stub code:

where GetCurrentAddress = a function to get the address we're injected at
where LoadDll = a function that looks up the address of LoadLib() api in memory, saved during injection
where RemoveStubs = a function to remove all stubs that point to that location using a structure saved during injection

int i = 0;
GetCurrentAddress(&i);
LoadDll(i); 
RemoveStubs(i)

So first our injector seeks for codes that are likely to be executed more times (or if you have provided an address) and patches them to the stub. The stub (when executed) then loads the dll provided by you and swaps the original code back in place.

So what do you guys think?

Is it useful? Keep in mind that I'm talking about system processes that cannot be injected without having special privileges.

I'm going to make this and things mentioned in my previous post about hooking into a library to support both game and real hacking (guess why I needed it in the first place...)

-SCHiM

[freedompeace]

awesome ! great and clear explanation !
unfortunately there's no thanks or rep on mobile..

I'm going to try this tomorrow !

[.::SCHiM::.]

awesome ! great and clear explanation !
unfortunately there's no thanks or rep on mobile..

I'm going to try this tomorrow !

It's not finished yet but I can give you assembler beta code if you want

[[MPGH]Dave84311]

These aren't really "new" techniques, loaders are common, just difficult and troublesome to implement.

[freedompeace]

These aren't really "new" techniques, loaders are common, just difficult and troublesome to implement.

jus'cos your pro :( !

[why06]

tbh, I would search for standard windows functions, GetMessage() or PeekMessage for starters since that main loop is called in all windows programs one way or the other. That will put you to the main loop, but just hooking any API is usually easier as well. Depends what your doing I guess...

Interesting idea, but it looks as if your scanning method isn't particular robust either, which means it probably takes some insight to get one of your "traps" to hit on the first pass without quite literally laying "traps" everywhere. A dirty, but effective approach, but their are cleaner ways.

[.::SCHiM::.]

[COLOR="Black"][SIZE="2"] without quite literally laying "traps" everywhere.

That was actually my first idea, since I thought I had the liberty to remove them without time/race pressure. To bad that when laying multiple traps race conditions do occur

GetMessage() or PeekMessage for starters since that main loop is called in all windows programs one way or the other. That will put you to the main loop, but just hooking any API is usually easier as well. Depends what your doing I guess...

But how should I go about hooking an API if I can't inject my code into the target process? I assume that one would need to use read + write process memory, which is very annoying to do in assembler...

These aren't really "new" techniques, loaders are common, just difficult and troublesome to implement.

Could you point me to one of these loaders?

[why06]

Use CreateToolhelp32Snapshot Function (Windows) to Find the ProcessID then you can call OpenProcess Function (Windows) to get the process Handle and finally GetProcAddress() to find the address on the API. Now it's a simple matter of Hooking that function by overwriting it with your own code. So just write over all those bytes then put the bytes back where you go them from once your done Loading your DLL.

[.::SCHiM::.]

Use CreateToolhelp32Snapshot Function (Windows) to Find the ProcessID then you can call OpenProcess Function (Windows) to get the process Handle and finally GetProcAddress() to find the address on the API. Now it's a simple matter of Hooking that function by overwriting it with your own code. So just write over all those bytes then put the bytes back where you go them from once your done Loading your DLL.

Yes. I was planning on doing something like that. But will GetProcAddress() work on executables? If it works, you're going to get credit when I release the library

EDIT: It's not working...

[why06]

Yes. I was planning on doing something like that. But will GetProcAddress() work on executables? If it works, you're going to get credit when I release the library

EDIT: It's not working...

My bad. you will have to call GetProcAddress inside of the target executable memory which defeats the point. Since I was talking about hooking an API though you can use SetWindowsHook function to hook a specific function then call LoadLibrary if that seems to be the right process. Then of course remove the hook after injection to evade detection. One way or the other code has to be executed inside the address space of the other process to load the library. I guess really the only easy ways I can think of are some flavor of CreateRemoteThread and SetWindowsHook.