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 ...
It is also easy using x64dbg. When you break on the WriteProcessMemory the handle will be at [esp+0x4] in the memory.
After you write down the handle (in this case 0xDC) you may go to the Handles tab in the x64dbg main window, then Right click -> Refresh. All the handles associated with your debugged process will be listed. Now you need to find the ...
which debugger are you using ?
most debuggers will decipher the handle on the spot
that is you can find out the handle info when you have broken on the WriteProcessMemory() Call itself
here is how you can do it with windbg
i am debugging ollydbg and olllydbg ais debugging calc.exe
ollydbg is setting a breakpoint in calc.exe (uses WriteProcessMemory() )
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 ...
Many programs, especially malware, start a suspended child process (CreateProcess variants), overwrite its code with their own (WriteProcessMemory with or without VirtualAllocEx) and resume the main thread (ResumeThread).
Also look for ReadProcessMemory, it is possible that the call to OpenProcess that you see is actually the same process reading from its ...
Great tool to achieve this in Windows is Application Verifier.
The general idea is that you run your program with different heap inspections, using the verifier. For example - each allocation made on a separate memory page, Freed memory is not just returned to the pool but marked as freed, and any later access to it will cause an excpetion and so on. This ...
I started from scratch, used OllyDbg to find the opcodes as they are in memory and then wrote my heuristics for finding certain opcodes of interest also operate on the image in memory. There were some weird differences such as a certain MOV operating on EBP as opposed to ESI on disk (which I now think is related to thread-local storage, since apparently the ...
Detouring is more or less a patching of the .text section inside of a program. It's practically more or less hacking, you're rerouting a program to do what you want it to do with your own function. Usually by placing the opcode 0xE9 (known as JMP, also added with some 0x90 which is NOP, for alignment) inside of the memory address you're detouring, that JMPs ...
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 ...