Code injection without using DLL injection

[PeterBotes]

Hi all, been reading all about DLL injection but it crossed my mind that it would be
nice to not use a DLL or API hook but I have looked and cannot find how or even if this can be done?

What I mean is, somehow get access to code area of a process like minesweeper, search for piece of
code like "retn" instruction or whatever you want and then replace with a jmp instruction to your own
code that was added to the program (malloc'ed)

Anyone know anything about this?

Thanks

Pete

[xorc1zt]

most of dll injection is done with a code injection who load the dll into the process.

[Thorium]

Of course it's possible but it's much more complicated to inject complex code directly. You cant just copy code from your PB process to another process. All the libs are not present at the target process, all fixed references are wrong, missing DLL imports, etc.

Thats why we use DLL injection.
Code injection is only used for small code sequences, typically written in ASM. Like the actualy loading of the DLL on DLL injection.

[Didelphodon]

Essentially it's absolutely doable.

If the targeted process doesn't "defend" itself against it you can use all the typically used memory-functions ending with "...Ex" - so, i.e. VirtualAllocEx and so on.

Assuming that you already have the code you want to inject "available" in your own process these are the steps you'll have to do ...
0.) You need the permissions to do that stuff on the targeted process.
1.) Open the targeted process (=> OpenProcess).
2.) Then allocate memory in the other process (=> VirtualAllocEx).
3.) You need to set executable flags to the allocated region (=> VirtualProtectEx).
4.) Copy your code to the other process (=> WriteProcessMemory).
5.) Create a thread in the other process using the coppied stuff as entry-point (=> CreateRemoteThread).

A more detailed description you'll find at http://www.codeproject.com/KB/threads/w ... #section_3.

I've seen a lot of malware doing this thx to CreateRemoteThread - imho something that shouldn't exist in terms of security.

Cheers,
Didel.

[Thorium]

I've seen a lot of malware doing this thx to CreateRemoteThread - imho something that shouldn't exist in terms of security.

You can do it without CreateRemoteThread. It's not a security risk, using the admin account all the time is a security risk. CreateRemoteThread only works with admin access rights.

And my statements are valid. Copy a piece of PB code that uses any of the PB libs and it will not work, it will just crash. Same goes for stings, references to any strings will be broken.

[Didelphodon]

I've seen a lot of malware doing this thx to CreateRemoteThread - imho something that shouldn't exist in terms of security.

You can do it without CreateRemoteThread. It's not a security risk, using the admin account all the time is a security risk. CreateRemoteThread only works with admin access rights.

And my statements are valid. Copy a piece of PB code that uses any of the PB libs and it will not work, it will just crash. Same goes for stings, references to any strings will be broken.

I haven't said that your statements aren't valid so calm down.

Imho according to the initial question there weren't any specific assumptions like "injection of PB-related code". Furthermore even though Windows Vista or 7 is arround it's still a common behavior of the users out there to stay on the initially default account-type which is definitely a (if not THE) security risk, I agree.

Still I find stuff to modify a "foreign"'s process a potential security risk and that's even the opinion of the people at MSRC. However, I find it interesting that you feel the need to underline that your statements are valid though knowone said they're wrong but actively invalidating mine - just wondering.

Cheers,
Didel.

[PeterBotes]

Wow thanks for all the replies so far.

Just thought I would add some info to help with the answers

it will be on XP platform
code will be in ASM but probably a quite few lines but probably not over 2Kb
I will not be using any libs so no issues here.


Is there an example of this in PB anywhere?
How do I get access to code section?

Also found this, I am not sure exactly what it does but looks intresting.

http://www.purebasic.fr/german/viewtopi ... 11&start=0


Thanks

Pete

[PeterBotes]

OK I am going round in circles here and it is all to do with access to another processes code memory.

I think I understand that I need to allocate some memory in the processes address space probably using VirtualAlloc, this would be where I put my code (codecave)
All I want to do then is make a jmp or call to this code by altering the original processes code. BUT HOW do I change / access the original code as it is protected

Now maybe this is where the CreateRemoteThread comes in. Would I be right in saying,

Create a remote thread
In this thread do the virtualalloc and create the codecave
Then in the same thread alter the original code (as I have access) to jmp / call my codecave?
Finally stop the newly created remote thread

Peter

[Didelphodon]

Sorry, got no time yet, I will post later.

[Thorium]

The code you found calls a procedure in another process with any number of parameters. It does it by allocating memory in the targt process and generates code for the call and writs it in there. Then it executes it with a remote thread.

A code cave is something different. A code cave is unused but allready allocated executable space in memory. You can just wrte your code in there and jump to it.

You can change the memory access rights with VirtualProtectEx.

But after all, its a lot of work that can be drasticly reduced by using DLL injecten. Thats why i wrote that my statements are valid. There is no need to go the hard way as it has many downsides. Its only usefull for small code sequences.

With CreateRemoteThread you create the thread in the targt process with code that is in the target process. So you need to write it in there anyway.

Another mehode is to change the EIP register to your code address with the win debug API.

[ultralazor]

Read the MS PE specification..

All injection techniques cause problems with security products. Patching a binary on disk then loading it doesn't unless the code matches a signature.

Also you don't need to be under an admin account to do the virtualalloc method, but you have to handle imports and maybe ASLR, if loadlibrarya isn't in the import table you have to patch the table, then you can load whatever you want. In image patching there are also issues, you have to rebase the headers and handle relocation entries, if any.

There are structs that help with all this.

[Thorium]

Also you don't need to be under an admin account to do the virtualalloc method

How?
All my programs that use this fail without admin privilegs. Including the code allready posted here from the german forum.

[ultralazor]

Also you don't need to be under an admin account to do the virtualalloc method

How?
All my programs that use this fail without admin privilegs. Including the code allready posted here from the german forum.

cause most of your processes are probably running as administrator and system, those tokens by default have protection on their pages by the kernel. There is no reliable generic injection techniques anymore. I hear it's even more protected against in windows 8 with some type of signing reinforcement.

[xorc1zt]

http://en.wikipedia.org/wiki/Data_Execution_Prevention

[ultralazor]

http://en.wikipedia.org/wiki/Data_Execution_Prevention

It's only enabled on SYSTEM(?) processes without enabling it out of the box. There is also ASLR. There are ways around both even with remotely exploited shellcode.

A reliable generic injection technique uses API to detect DEP on a pid, and also handles ASLR which I believe is done the same way after you do some allocation checks. Unfortunaly nobody has done this outside of exploit kits. The best public-code injection technique to date breaks under a lot of conditions. Nobody has bothered writing one.