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 ...
Disclaimer: I'm going to expose my workflow when I see similar things. I'm not telling you that this is the best one or the faster, and I'm sure you have a lot of other way to deal with this. But this should give you an insight on how you can do this.
As your question is really wide and does not contain any details (malware name, hash, or what 'failed to ...
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() )
When executing ELF files, the OS loader does not care about sections but only segments (aka program headers). You need to ensure your code belongs to an executable segment.
As can be seen, section .fini starts at 11e8 and has the size of d.
The next section - .rodata starts at 2000. Does that mean that the
space between 11e8 + d and 2000 does not belong to ...
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, ...
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 ...
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 ...
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 ...
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.
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 ...
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 ...
The x86/x64 instruction set is variable length and there are no obvious instruction boundaries. You can make use of a length disassembler to figure out how long each instruction is. There are a bunch of them available, here’s a few I found by a quick search:
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
CreateRemoteThread takes 7 arguments and the 4th of them is called lpStartAddress.
Now, from MSDN docs:
A pointer to the application-defined function of type LPTHREAD_START_ROUTINE to be executed by the thread and represents the starting address of the thread in the remote process. The function must exist in the remote process. For more ...
Obviously you should resolve the address in IAT.
This is a manually mapped dll code, you can take a look.
typedef HMODULE(WINAPI* pLoadLibraryA)(LPCSTR);
typedef FARPROC(WINAPI* pGetProcAddress)(HMODULE, LPCSTR);
typedef BOOL(WINAPI* PDLL_MAIN)(HMODULE, DWORD, PVOID);
For any external functions used (e.g. libc functions), there will exist a stub in the binary's PLT for said function. When the program calls the function, it jumps to the PLT stub, which correctly handles finding the address of the function the first time it is called.
For your purposes, you can read the PLT addresses or offsets from the binary, and use that ...
So silly me, the function n_GetLocalPlayer() needed to be dereferenced and then the result from the offset dereferenced again. It works now. Here's the format:
playerData* lpData = reinterpret_cast<playerData*>((*((DWORD *)n_GetLocalPlayer() + 280)));
Some may favor miasm over other frameworks (see for instance the Advanced Binary Deobfuscation material). Examples:
Analyzing Shellcodes with Miasm for Fun and Profit
The Qiling emulator has been used for binary analysis and in conjunction with AFL++. Examples:
Moving From Dynamic Emulation of UEFI Modules To Coverage-Guided Fuzzing of ...
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 ...