DCoder's answer is a good one. To expand somewhat, I most often use DLL injection in the context of forcing an existing process to load a DLL through CreateRemoteThread. From there, the entrypoint of the DLL will be executed by the operating system once it is loaded. In the entrypoint, I will then invoke a routine that performs in-memory patching of all ...
DLL Injection works by tricking/forcing the target process into loading a DLL of your choice. After that, the code in that DLL will get executed as part of the target process and will be able to do anything the process itself can. The fun part will be to figure out how to get your code called by the target process.
DLLs can be injected by:
Very easy, if I got you right:
Make an Ida project from the DLL, i.e. drag and drop the dll into the blank Ida page.
In Menu Debugger, Process Options, put the path to your exe into the textbox "Application", Into "input file" put the path to your DLL. Confirm with OK.
Start with menu Debugger, Start Process or F9.
Your breakpoint should be hit.
What you're trying to do is very hard if the attacker is an experienced game hacker and the specifics of the cheat is unknown.
In general if you want to inject a DLL which is harder to detect and won't show up on the module list of the process you use something called manual mapping. What this does is that it emulates the behavior of LoadLibrary without ...
There are multiple ways that you can use which might work (and see below for the reasons why they might not). Here are two:
A process can debug itself, and then it will receive notifications of DLL loading.
A process can host a TLS callback, and then it will receive notifications of thread creation. That can intercept thread creation such as what is ...
One thing you need to keep in mind is that code in your process and the code in the target process reside in different address spaces. So any address in your program is not necessary valid in the target process and vice versa.
This means the code that you inject cannot make any assumptions about addresses of functions or variables. Even your inject function'...
The reason why there aren't engines to hook the end of a function is because it's hard to determine where that is, or if it even exists. A function has a single entry point, but it can have multiple exit points, including none at all (consider exit()).
The exit point can have multiple types, too - return, throw(), longjmp(), C++EH, etc.
The general idea to ...
If you want to use a function in the application the bottom line is that you need to know where it's located. Without ASLR you can hardcode the address of the function into your DLL, and use a function pointer to call it. If you want to modify data from a function in a loaded library then you would need to hook that function, and call your own code for its ...
How do I find the base offset of process (I assume I can do in the DLL using something like GetModuleHandle("HackMe.exe"))?
A process doesn't have a base offset; I believe you mean the base address of the primary module. To get that address, you would use GetModuleHandle(NULL).
Is there a way to see the base offset in OllyDbg (not that useful I ...
An easy way to do this is to modify the IAT (Import Address Table/Import Directory) which can be done with a tool such as LordPE.
From the main screen choose PE Editor and select the executable (or DLL) that you wish to modify:
Then click Directories:
Click the Ellipsis button next to Import Table:
Right Click and choose add import:
Now add your dll and ...
Is there any way to detect from the driver that this process is protected ?
Disclaimer: This following procedure depends on undocmented data structure which is extracted from PDB symbol of combase.dll file. As usual this may not work in future Windows OS version.
This is the sample C code to detect protected process. The program accepts a valid process ID ...
Microsoft Detours makes this very easy. You'd effectively write the following code (to be safe, you'd want to make other calls such as DetourUpdateThread() as well):
And then have code such as the following as your hook:
int Function(int x)
Patching game's executable + using loading order trick
You should check the integrity of the games executable files before loading as there are way to patch it to load malicious Dll files, overlays if those were added (virus like)
Check game directory for unknown dll files - strange names, dlls that mimic system library files
Another thing is - some loader ...
You could create a loader which simply creates your target app in suspended state and loads dll into virtual address space of that process. That way the dll you injected would run before entrypoint of the target app.
A much simpler approach is to identify the point at which the code has actually generated the data you need. When you find that location, replace the next several bytes with a call or an far call to your own code. Make careful note of the bytes that you are overwriting. (As an aside, I recommend a call or far call rather than a jmp so that I don't have to ...
Yes, it is possible. There are a couple of generic approaches you can take for detecting injected processes (not just dlls). The first is to enumerate DLLs that are injected by the OS via registry key. The two known key/value are AppCertDLL & AppInitDLLs. The second is to search for all memory that is marked as RWX and then parse out the memory for clues ...
please look at the following:
PyDBG - it's a python wrapper around Win Debug API and much more. The framework enables one to literally inspect every aspect of the running process by registering event handlers for BPs, memory executions/reads/writes, stack inspection, etc.. You can change whatever you want in the process you are debugging.
how do i avoid getting detected
You can't know how to avoid getting detected if you don't know how the detection works. I'd recommend finding and reverse engineering the detection logic so that you can either disable it (patch it out) or better understand how to avoid detection.
That said, if you're looking for a generic alternative to "standard" DLL ...
Executable relocations, whether performed for optimization or security, will only relocate the image (executable, shared object) as a whole.
For that reason, to bypass ASLR for example, any single address within a chosen shared object is sufficient. Given, of course, you know the precise version and build of the shared object. Knowing the specific build ...
If you compare pseudocode returned by decompiler with your own C code you will notice one very important difference - in decompiler's output it is merely a comment, but it's very important. I'm talking about following lines:
int v7; // [sp+10h] [bp-42Ch]@1
char v8; // [sp+14h] [bp-428h]@1
int v9; ...
Have you considered using the DLL only for providing "stub" methods, that you could call using CreateRemoteThread, and have the DLL methods transform the arguments into what the method you ultimately want to call takes?
I know this is not really a solution to how the program detects other threads running. But with some luck, the fact that your threads ...
You can certainly hook dlls similarly to how you'd hook any other function. To get the address of a dll function, you'd need to call two windows APIs.
First, you'll need to get the address/handle (these are the same when discussing loaded modules) of the module you're trying to hook. A simple method to get that is to call either LoadLibrary or ...
One way of doing this :
Localize lua_gettop in your target binary with IDA (which should be called very frequently). You can get it by downloading Lua sources, and look for error messages in your target binary. You should be able to reconstruct little by little the Lua runtime by looking at XRefs of lua functions containing error messages.
Hook lua_gettop, ...
At one particular instance it showed a debug error saying: "The
process was not able to resume execution because the ESP value was
changed", or something similar.
typedef void(__cdecl* ChatFunc)(char*);
ChatFunc Chat = (ChatFunc)0x00450C60;
It sounds like the function at 0x00450C60 is not a __cdecl function and/or it doesn't take exactly one ...
Aphex has demo's written in Delphi with a few code injection examples. Should compile with Delphi 2007...maybe even with Delphi 7.
Remote Procedure Injection
Most examples rely on Aphex's AfxCodeHook library (with source), and this is where the heavy lifting is done. Even without a copy of ...
There are ways to do it without resorting to hooking or drivers.
For example alternate data streams (ADS), or creating files with "illegal", i.e. reserved, names (NUL, CON ... trailing ., alternative casing to an existing file). Yep, that's right a trailing dot in a file name is illegal in Win32, but the most frequently used file system (NTFS) has no ...
Shortly after posting the question I took a closer look at my code for parsing the exports and came to the realization, that I made an incorrect assumption.
In the export directory entries, if a function entry point to the export section, you can find a string there, which depicts the forwarder export name. An example of that is visible in the last screensot ...
You can take one of the following approaches:
call eax usually means there is an indirect call. try to find what and where eax is defined. Maybe only by looking at it, you will found the problem. If you find the origin but not understand the problem, you can try to patch it, to something like: mov eax, <known_function_address>
Maybe you can change a ...
Yes, it is possible to perform the necessary loading steps in the injector process (i.e., resolving the import addresses) before injecting the DLL, and some injectors/malware do that. See for example address 0x18007CD00 in my ComRAT IDB.
However, doing it that way is more cumbersome, as some of the neccessary DLLs might not already be loaded by the target ...
Since I cannot add a comment I will post it here:
Well it doesn't actually point to the end, does it?
It should point to the memory where the actual byte array starts. Note that I first write the testString into the memory of my second program then the bytecode.
Then I do remoteCave = (LPVOID)((DWORD)remoteString + stringlen) which should then be ...