Recent

Author Topic: PE file injection  (Read 4353 times)

BSaidus

  • Hero Member
  • *****
  • Posts: 538
  • lazarus 1.8.4 Win8.1 / cross FreeBSD
PE file injection
« on: October 21, 2020, 08:33:43 pm »
Hello,
For learning reasons I wonder if someone has a tutorials, simple examples on how to inject functions located in DLL into an already executable so the the executable starts executing functions injected then returns to normal execution.

Thanks
lazarus 1.8.4 Win8.1 / cross FreeBSD
dhukmucmur vernadh!

jamie

  • Hero Member
  • *****
  • Posts: 6077
Re: PE file injection
« Reply #1 on: October 21, 2020, 11:36:48 pm »
LOL  :P

You make me laugh  :-\

Build a DLL and load it at run time..
« Last Edit: October 21, 2020, 11:44:42 pm by jamie »
The only true wisdom is knowing you know nothing

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Re: PE file injection
« Reply #2 on: October 22, 2020, 07:50:06 am »
Hello,
For learning reasons I wonder if someone has a tutorials, simple examples on how to inject functions located in DLL into an already executable so the the executable starts executing functions injected then returns to normal execution.

Thanks
I had old project, that implemented "game club" functionality, i.e. enabling execution of applications via network, disabling it and terminating applications, when execution is disabled. Yeah, there are better ways to do it, but I used code injection to achieve this goal. Also for learning purposes. All code itself was in DLL. Only one DLL routine call was injected into EXE, i.e. very small chunk of code. I don't have this project on my computer now - it's somewhere in my archives. If I'll have time, I'll find it.

What I can say, is that due to fact, that all addresses are fixed in PE file and can't be relocated, code injection isn't always possible, as it uses free padding space, that is used for alignment purposes. If exe doesn't have one - code injection won't be possible. And, as I remember, not all applications worked properly after that injections. But majority did.
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: PE file injection
« Reply #3 on: October 22, 2020, 09:23:41 am »
Build a DLL and load it at run time..

BSaidus means injecting code into a third application that is not controlled by them.

For learning reasons I wonder if someone has a tutorials, simple examples on how to inject functions located in DLL into an already executable so the the executable starts executing functions injected then returns to normal execution.

You could take a look at this thread which seems to have done it successfully.

BSaidus

  • Hero Member
  • *****
  • Posts: 538
  • lazarus 1.8.4 Win8.1 / cross FreeBSD
Re: PE file injection
« Reply #4 on: October 22, 2020, 03:26:00 pm »
Thank you for your responses all,

@PascalDragon
  The topic show how to inject code (dll function) to  a running process, what I want is a kind of patch
I Inject code into exe and the code will remain on it.

Thanks.
lazarus 1.8.4 Win8.1 / cross FreeBSD
dhukmucmur vernadh!

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: PE file injection
« Reply #5 on: October 22, 2020, 04:37:15 pm »
For learning reasons I wonder if someone has a tutorials, simple examples on how to inject functions located in DLL into an already executable so the the executable starts executing functions injected then returns to normal execution.
I don't have a tutorial nor examples but, I can point you in the right direction.

You mentioned you want to statically (that is not at run time) inject code into a dll (it doesn't make much, if any, difference whether dll or exe.) 

Three ways to do it come to mind.

The first way and, the simplest one is, if there is enough padding space in the dll/exe code segment(s) then, you can simply add the code into the padding space.  The one problem to be aware of is that,  the code _may_ need to have additional relocation entries added into the relocation table.  This depends on how the injected code is written.

The second way is not hard but it's very "delicate" and, takes a fair amount of work.  Basically, you extend the code segment to make it as large as you need it to be to accommodate the code you want to inject.  Doing it that way means the program that is injecting the code has to re-link the executable because the injected code causes the offsets to other segments in the PE file to no longer be correct.  If the PE file does not have a relocation table, this method cannot/shouldn't be used because there is no list of all the adjustments that must be made to ensure a valid resulting executable.

The third way, likely safest way and most flexible way, is to add a code segment that follows existing code and some of the data segments, that way, the most important offsets in the PE file remain valid and only a subset of the offsets have to be recalculated (those that reference areas after the added/injected code segment.)  This makes re-linking much simpler and possible even if the PE file does not contain a relocations section.

Lastly but, extremely important, you have to have _solid_ knowledge of the PE file format.  As far as an example, search for the source of a "PE rebase" utility.  Rebasing without injecting code is very simple but, that would give you a good idea of what's involved.  Matt Pietrek published a "rebase" utility along with a few others in his book "Windows 95 system programming secrets" and he makes the original disk available for download on his website.  His is written in C, maybe someone knows of a rebase utility written in Pascal they might want to mention.

HTH.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Warfley

  • Hero Member
  • *****
  • Posts: 1499
Re: PE file injection
« Reply #6 on: October 22, 2020, 05:59:17 pm »
There are several different things one could do besides what 440bx already mentioned. The most simple one is to just have a program that contains the other program and first executes it's own code before executing the original program. This is how most malware operates, but you must get creative on how to avoid AVs.

Another option would be to wrap an existing DLL. Search for a library the program uses, on Windows it usually should contain a call to LoadLibrary to initialize that library. LoadLibrary takes the a filename. Patch this filename to referr to the name of your DLL. Then all you need to do in your DLL is to load the original DLL and simply provide for all exported functions a wrapper to the internally loaded original DLL.
I did something similar once (but I just renamed the old DLL in the program directory and added my DLL under the same name). This is how many Game Hacks circumvent the anticheat (by finding whitelisted DLLs and replacing them, not by patching ACs can notice that).

The last option I can think of is to write a stub program like in the first approach I mentioned, but instead of executing the code in two different processes, start the original application and then inject the DLL into the running process like in the thread posted by PascalDragon

mav

  • Jr. Member
  • **
  • Posts: 79
Re: PE file injection
« Reply #7 on: October 22, 2020, 06:11:32 pm »
Ten process injection techniques: A technical survey of common and trending process injection techniques :
  https://www.elastic.co/es/blog/ten-process-injection-techniques-technical-survey-common-and-trending-process
    :) :)

mav

  • Jr. Member
  • **
  • Posts: 79
Re: PE file injection
« Reply #8 on: October 22, 2020, 06:25:49 pm »
I hope it helps...
greetings!!

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Re: PE file injection
« Reply #9 on: October 22, 2020, 09:10:53 pm »
I don't have a tutorial nor examples but, I can point you in the right direction.

You mentioned you want to statically (that is not at run time) inject code into a dll (it doesn't make much, if any, difference whether dll or exe.) 

Three ways to do it come to mind.

The first way and, the simplest one is, if there is enough padding space in the dll/exe code segment(s) then, you can simply add the code into the padding space.  The one problem to be aware of is that,  the code _may_ need to have additional relocation entries added into the relocation table.  This depends on how the injected code is written.

The second way is not hard but it's very "delicate" and, takes a fair amount of work.  Basically, you extend the code segment to make it as large as you need it to be to accommodate the code you want to inject.  Doing it that way means the program that is injecting the code has to re-link the executable because the injected code causes the offsets to other segments in the PE file to no longer be correct.  If the PE file does not have a relocation table, this method cannot/shouldn't be used because there is no list of all the adjustments that must be made to ensure a valid resulting executable.

The third way, likely safest way and most flexible way, is to add a code segment that follows existing code and some of the data segments, that way, the most important offsets in the PE file remain valid and only a subset of the offsets have to be recalculated (those that reference areas after the added/injected code segment.)  This makes re-linking much simpler and possible even if the PE file does not contain a relocations section.

Lastly but, extremely important, you have to have _solid_ knowledge of the PE file format.  As far as an example, search for the source of a "PE rebase" utility.  Rebasing without injecting code is very simple but, that would give you a good idea of what's involved.  Matt Pietrek published a "rebase" utility along with a few others in his book "Windows 95 system programming secrets" and he makes the original disk available for download on his website.  His is written in C, maybe someone knows of a rebase utility written in Pascal they might want to mention.

HTH.
Relocation works for DLLs only, as all EXEs are usually "fixed" now, i.e. they contain hardcoded addresses, that aren't mentioned anywhere, so you can't relocated them. Therefore nothing can be moved inside EXE. That's why third method still isn't guaranteed to work. You still need padding space in Section Table in order to add new section. And it isn't guaranteed to exist.
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: PE file injection
« Reply #10 on: October 22, 2020, 09:20:56 pm »
Relocation works for DLLs only, as all EXEs are usually "fixed" now, i.e. they contain hardcoded addresses, that aren't mentioned anywhere, so you can't relocated them. Therefore nothing can be moved inside EXE. That's why third method still isn't guaranteed to work. You still need padding space in Section Table in order to add new section. And it isn't guaranteed to exist.
No. That is incorrect.  As long as the executable contains a relocation table, the executable can be rebased whether it is a DLL or a .exe.  Many, if not most, exes contain hard coded addresses but they are referenced in the relocation table (if they are created with a relocation table) to enable the loader to load them at an address other than the preferred load address.

If there is no relocation table then, everything is fixed and the loader has no choice but to load them at the preferred load address (which for the executable should never be a problem - which is the reason why some compilers now default to not creating a relocation table for .exes.)


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Mr.Madguy

  • Hero Member
  • *****
  • Posts: 844
Re: PE file injection
« Reply #11 on: October 23, 2020, 07:48:57 am »
No. That is incorrect.  As long as the executable contains a relocation table, the executable can be rebased whether it is a DLL or a .exe.  Many, if not most, exes contain hard coded addresses but they are referenced in the relocation table (if they are created with a relocation table) to enable the loader to load them at an address other than the preferred load address.

If there is no relocation table then, everything is fixed and the loader has no choice but to load them at the preferred load address (which for the executable should never be a problem - which is the reason why some compilers now default to not creating a relocation table for .exes.)
That works, if you want to inject code to your own EXE. And we talk about arbitrary EXE. Because EXE with relocations - is something form Win32s/Win95 era, because 386 support was still required back then and 386 lacked paging. Win64 is different thing. It supports IP+X relative references. But again. It's not guaranteed, that hardcoded addresses aren't used anywhere.
Is it healthy for project not to have regular stable releases?
Just for fun: Code::Blocks, GCC 13 and DOS - is it possible?

balazsszekely

  • Guest
Re: PE file injection
« Reply #12 on: October 23, 2020, 08:32:17 am »
@BSaidus

The attached project(D7) worked very well in the past, I believe it still works with 32 bit exe/dll. It does exactly what you are trying to achieve: injects a dll into an exe(not into a running process). I'm only posting this, because the code is irrelevant nowadays, besides you can find it with google, if you know where to search.
As a conclusion, the code is excelent for learning purposes, but nothing more, exactly what @BSaidus is after :D.   

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: PE file injection
« Reply #13 on: October 23, 2020, 09:09:47 am »
No. That is incorrect.  As long as the executable contains a relocation table, the executable can be rebased whether it is a DLL or a .exe.  Many, if not most, exes contain hard coded addresses but they are referenced in the relocation table (if they are created with a relocation table) to enable the loader to load them at an address other than the preferred load address.

If there is no relocation table then, everything is fixed and the loader has no choice but to load them at the preferred load address (which for the executable should never be a problem - which is the reason why some compilers now default to not creating a relocation table for .exes.)
That works, if you want to inject code to your own EXE. And we talk about arbitrary EXE. Because EXE with relocations - is something form Win32s/Win95 era, because 386 support was still required back then and 386 lacked paging. Win64 is different thing. It supports IP+X relative references. But again. It's not guaranteed, that hardcoded addresses aren't used anywhere.

Relocations still are a thing. In fact when you want to use Address Space Layout Randomization on Windows your executables must be relocatable. MSVC creates relocatable executables by default and for e.g. aarch64-win64 it is required as well (otherwise the executables refuses to launch).

440bx

  • Hero Member
  • *****
  • Posts: 3921
Re: PE file injection
« Reply #14 on: October 23, 2020, 11:49:29 am »
<snip> And we talk about arbitrary EXE. Because EXE with relocations - is something form Win32s/Win95 era, because 386 support was still required back then and 386 lacked paging. Win64 is different thing. It supports IP+X relative references. But again. It's not guaranteed, that hardcoded addresses aren't used anywhere.
What @PascalDragon stated above is exactly right.  While x64 allows addressing using RIP relative offsets, it is still very common for items in an executable to be referenced with absolute addresses which requires a relocations table in order for the .exe to be relocatable. 
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018