Start here--specifically, the third technique: "The CreateRemoteThread & WriteProcessMemory Technique". To quote:
Another way to copy some code to another process's address space and then execute it in the context of this process involves the use of remote threads and the WriteProcessMemory API. Instead of writing a separate DLL, you copy the code to ...
These two symbols aren't exported in the usual way (i.e. via the export table). Instead, they are public symbols inside the run-time library itself. The startup code that runs before _main() performs the command-line resolution, assigning parameters into the __wargv array, and storing the count in __argc. The relative addresses are fixed for the file, but ...
Unfortunately, as a beginner, there's a LOT for you to learn where this topic is concerned. It's not that it's particularly outside of your grasp to understand, but rather that it's going to take quite a bit of time.
Without seeing the file or knowing the game, there are any number of solutions that could be happening. So instead of playing guesswork there, ...
Most of the times when a malware does something like that it's simply to make debugging it harder. Therefore, you can easily breakpoint on the injection procedure and redirect it to another process. Make sure you redirect both the memory writes/injections and the code execution.
Redirecting it to the same process might work, but it may also cause issues. It ...
how I'd go from a static address in IDA, to an actual address ... in another C++ program
When executable file is loaded in IDA, it is loaded with the preferred image base taken from executable's header. It can be viewed, for example, through menu Edit -> Segments -> Rebase program.... Value there is an image base.
Another way taken from here: go to ...
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, ...
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 ...
So your definition of a "snapshot" is somewhat vague. Hopefully my answer matches your idea:
Did you already take a look at the OllyDumpEx Plugin?
This plugin is process memory dumper for OllyDbg and Immunity
Debugger. Very simple overview: OllyDumpEx = OllyDump + PE Dumper -
obsoleted + useful features
Of course you can simply dump the raw memory ...
Yes, you need to look into reverse engineering discipline.
There's a lot of books written on this topic, for example:
By reading those books, you'll get acknowledged with need tools and instruments, also as reversing techniques.
If you'll have any more questions after reading those books, please come back and ask.
As I understand, you want to replace the function with code such that it returns a pointer to the ASCII string "kowewqzb".
Since the function in question is quite long you have sufficient space to write an inline patch both for ARM32 and ARM64.
For ARM32, you can use the following piece of code
adr r0, str
Here's the rest of the function where the crash happens:
_KiUserApcDispatcher@16 proc near
lea eax, [esp+2DCh]
mov ecx, large fs:0
mov edx, offset _KiUserApcExceptionHandler@16 ; KiUserApcExceptionHandler(x,x,x,x)
mov [eax], ecx
mov [eax+4], edx
mov large fs:0, eax
lea edi, [esp+0Ch]
As you can ...
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 ...
You can recursively follow dependencies to figure out which DLLs were loaded directly by the Windows loader. You may create an imported modules list. Fill imported module list with every module you find in the main PE's import table. Then recursively parse the import tables of all DLLs you found that way. You'll have a list with all DLLs imported. Then, just ...
Most of the time when a malware has injected itself into another process,it will call "SetThreadContext" to set the CONTEXT structure.You can easily get the "oep" of the target process through the "eax" member in the CONTEXT structure.The "oep" stands for the original address when target process resumes,you can make a loop at the "oep" so that the ...
In general you cannot expect a function written in C/C++ to result in a single compact, copyable chunk of object code inside your executable. To achieve that you need to tweak the compiler settings and take the function's address in plain view of the compiler, to make it emit the actual code of the function instead of inlining it. Or use an equivalent ...
In your DLL you simply need to do the following:
In the DLL initialization code, run the DirectX function you need. If using VB6 (why?) you need to add the DllEntryPoint function: http://www.windowsdevcenter.com/pub/a/windows/2005/04/26/create_dll.html
Put your DLL in the AppInit_DLLs registry key: http://support.microsoft.com/kb/197571/en-us
And that's ...
It should also be storing address of GetProcAddress() at <lpparm+4>
it should store a string the name of module at <lpparam+14>
it should store a string the name of proc for getProcAddress at <lpparm+46>
at [esp+8] it accesses the lpparam which was written to the remote process so you may need to find this WriteProcessMemory Also and ...