All,
I have been trying to figure this out for a couple of days now and I need some help.
For a research project for work I have written some custom malware, the malware itself is not the issue here and I won't share any code, but I do need some help on the actual injector.
I have some problems trying to fully understand how and when I need to perform manual relocations. I am not relocating at the moment and using a random address from virtualallocex, and everything just works. My malware exe runs and I have no issues UNLESS the memory location where the remote process PE is loaded at overlaps with my malware PE preferred base address.
I am not using NtUnmapViewOfSection as it gets detected by AntiVirus and basically is just a crap function that randomly doesn't work, so my plan is to just use a random address provided by VirtualAllocEx and relocate if need be (which I don't understand, see questions hereunder).
This is my current working method (unless target process overlaps with preferredbase):
Download malware exe and place in buffer
CreateProcess to start victim process
Suspend the thread right after (I'm not using CREATE_SUSPENDED flag as this does not work in win10)
Get necessary header info from the buffer (PIMAGE_DOS_HEADER, PIMAGE_NT_HEADERS), also get the ImageBase address from remote process PEB
Allocate memory in target process (VirtualAllocEx), using NULL for lpAddress so virtualAllocEx can choose the location
Write PE headers and sections to the memory location
Protect Memory
Change EAX to new entrypoint
Change PEB to new baseAddress
ResumeThread
Profit
So please help me understand the following:
Why does this work without doing any manual relocations, is there some magic PE loader in the background that does this even though I'm injecting?
Why doesn't it work when the target process overlaps with the preferred base address. The PE image itself is copied in a non-overlapping memory location, so how in the hell is that any different from my working solution when the target process doesn't overlap. It should just do the magic relocation thing from my first question.
Why do I see so many people change the preferredBaseAddress in the image before writing it to memory? To my knowledge this field is only used to map PE to their preferredbaseaddress, if they can't do that the PE loader performs the relocations. Seeing as injection code usually performs its own manual relocations I have no idea why they would change this.
Hopefully somebody can help me understand, because this is driving me nuts :).
Best regards!
1: It is because of the way assembly code works. Most jmp's are relative to the current address, and thus will work no matter where the code is located. The problems arrise as soon as you want to look up variables / resolve dll import addresses from the IAT. This is because these operations require MOV instructions, and generally compilers will hardcore an address as the source operand for these functions. The problem then is that it will be pointing to some random location, and thus will either result in an access violation / undefined behaviour.
What I think is the case for you, is that both the host process, and the payload, have the same preferred base address. This means that it doesn't fail with an access violation, because there just happens to be some random data at that location.
If you always load the payload at it's preferred base address, you won't need to do manual relocations.
2: Not sure what you mean
3: For normal simple applications, you won't have to change the preferred base address. The problem arrises when your payload needs to access it's relocation table (for example, when deploying a rootkit or w/e). It kind of depends on how the virus was built. There shouldn't be any problems if the preferred base address is compared to the actual base address.
To your CREATE_SUSPENDED problem: I had this exact same problem a few weeks back. It seems that as soon as you resume a thread created with CREATE_SUSPENDED, it overwrites it's registers or w/e. I couldn't figure out why this problem arrises. What you can do to overcome this though, is never resume the main thread at all. Instead, simply create a new thread with CreateRemoteThreadEx.
EDIT: After reading one of your other questions, you actually solved this problem for me. I was changing EIP instead of EAX. I didn't know the PE loader called eax instead of just resuming the code at the instruction pointer.
If you ever need any help with this, HMU. I've done a whole ton of research on malware development, and love to share the knowledge.
Related
A client came to me with an application that they lost the source code to. This application is crashing seemingly at random, when loading some files. I suspect that the issue is due to a race condition in which a pointer is deleted and then either not set to NULL or not checked for validity.
When stepping through the assembly using OllyDBG, I found that the crash ALWAYS happens at the same location, so this is kind of re-enforcing my theory. This is the assembly line it sometimes crashes on, keyword sometimes.
MOV EDI,DWORD PTR DS:[EAX]
Is it possible to validate a memory address is valid and exists either through native assembly or through C++ that pulls an address through an inline assembly call (or something like this)?
There is no general standard way in C++ to validate a memory address. Nor is there such assembly instruction that I know of.
On a memory mapped system (such as any modern operating system), you may be able to check whether an address has been mapped for the process using a system specific API. An address being mapped to the process doesn't guarantee that the address is valid from the C++ point of view, but an unmapped address is definitely invalid.
Furthermore, even if could find that an address is valid, that doesn't tell you whether the object you are expecting is in that address or something else.
There are tools for validating memory accesses outside of the C++ language1. There's for example Valgrind and also compiles provide address sanitisers and memory sanitisers. Mostly, these help detect invalid accesses that wouldn't have crashed the program otherwise. But they also often can provide additional information regarding that memory.
1 If you had access to the source.
I suspect that the issue is due to a race condition
Being able to validate a memory address won't solve this problem. What you should do1, is to use a debugger to find out what object is being accessed, find all places where that object is accessed. If any of those places is not holding a mutex that is common to all other places potentially accessing the object at the same time, then there's your bug.
1 If you had access to the source.
lost the source code
If you have a massive budget, then you could try reverse-engineering it and try to figure out what it's doing. I wouldn't hold my breath; it may be best to declare this as a lost cause.
Everyone provided some great responses. Unfortunately, in this situation, the client wasn't willing to pay to have the software re-developed entirely.
I managed to kind of negate the crash... After identifying exactly where the crash occurred I used used code injection to JMP to a custom C++ function. The C++ function employs a __try __except block. Inside of the Try I placed the problem assembly code, and if the problem code causes a crash, the __except catches it. After that, it was just a matter of analyzing what the problem code was doing and when it started doing something else and then jumping to the start of that "something else" part of the problem function when an exception is caught.
It's not exactly detecting if a memory location is valid or not, but rather it's just skipping code if it causes an exception. Hope this helps someone eventually...
Yes, validating a pointer's content is possible. However, verifying that the target is the correct one is more difficult.
In order to validate a pointer you'll need:
Table of valid address ranges (addresses that are implemented and their ranges).
For example, on embedded systems addresses that are decoded may not have memory or devices at all locations.
For OS's that support paging or virtual memory, you'll need to figure out the limits of your program's memory area (as given by the OS). The OS may take portions of your executable and swap them out with code on a hard drive.
For OS's that support virtual memory, you'll have to figure out where in the "virtual" memory that your pointer is allowed to access. Read about memory mapped files.
On some platforms, the address 0x0000 is a valid address. Verify if this is the case on your target platform.
IMHO, pointer content can be validated, but the validation may be very compilicated.
Prefer to use references.
How can I find a memory address that I can afterwards change/read by just using that memory address' value using C++?
For example like how you can find the memory adress of something by just searching up a value in Cheat Engine.
I searched it on Google for about an hour now but I still couldn't find anything that would be useful for me.
I'm using Windows.
Sorry if I have any spelling mistakes or grammar issues, my main language isn't English.
For example like how you can find the memory adress of something by
just searching up a value in Cheat Engine.
So what you want is to know the memory address at which something can be found in a process. For example, let's say that notepad.exe has the bytes 68 65 6c 6c 6f somewhere in memory and we want to figure out where.
Basically we want to scan the memory of a process for a given pattern while that process is running.
There are a few strategies:
we inject a DLL inside notepad.exe and do the scanning from that DLL;
we scan the memory remotely, from another process
There are various pros and cons for each approach. Your question is focused on the second. I'm going to give a high level view of how one might approach this problem.
First, each process has its own address space. What this means is that address A in notepad.exe and address A in paint.exe will point to different things, or may not even be valid in both processes. See this page for more details.
There's also ASLR, which randomizes memory addresses, but that's not such a big problem in this case.
We need a way to work around this and know which memory ranges are valid in the target process. We can do it with VirtualQueryEx. We can start from 0 and go up to the last valid user mode memory address (0x7FFFFFFF for 32-bit processes, 0x7FFFFFFFFFFF for 64-bit processes). If we have a valid range, we read it with ReadProcessMemory. If it is not valid, we check the next page. If we managed to read it, we can now search for our pattern.
We can skip the VirtualQueryEx call and blindly try ReadProcessMemory for every possible page, but, especially for 64-bit processes, this can take quite some time. The information returned by VirtualQueryEx can be used to filter out some ranges, based on what we're looking for.
Note that in order to do this we need to be able to open a handle to the target process with OpenProcess with the PROCESS_QUERY_INFORMATION and PROCESS_VM_READ access rights.
There are a few problems we may encounter: there's a time frame between our query and our read in which the memory layout of the target process can change. We must be prepared for this. Generally speaking, the read will fail and we can just ignore it. Or the target process may be actively trying to stop us: maybe we can't open a handle to it with the required rights, maybe there's some anti-cheating techniques in place, etc. There's no way of knowing until we try.
I've been experimenting with reading/writing to memory of another process in C++ on Os X.
The issue I've been having is that I get a pointer (e.g. server.dylib+0x123AB) but I can't seem to find a way to get the memory address/base address of server.dylib dynamically in c++. Are there any methods that would be recommended to try to find it. It's probably my skill level but I've found that trying to tinker with memory on OsX has been an uphill struggle (there's very little documentation around).
Any advice would be appreciated.
Merlin's answer is somewhat inaccurate. ASLR is not meant to prevent you from getting addresses in runtime - it's meant to prevent you from relying on FIXED addresses (i.e. when code injection). If you can already execute code, you can definitely get addresses (heck, GDB does, why can't you?)
DYLD exposes a very rich API (, and dyld_images.h) which enables you to easily get a list of all the images loaded into a process address space either from within the process or from outside of it. You can also get the "slide" , which is the ASLR offset used. This is, however, assuming you're already running code on that machine - i.e. it won't work when injecting code.
Part of OSX security is a technique known as ASLR (Address Space Layout Randomisation). This ensures that images are loaded into random areas of a process's address space to try to prevent malware exploitation. It is present in both the kernel and user space processes.
You can read more about it ASLR here
If you search google, you'll be able to find more information relevant to OSX, such as this article
If as you say, you're just experimenting, run the target process with gdb and you'll be able to find out the memory address of the dylib, after it has been loaded, which you can then use in your test program.
Standard hacking case. Hack file type injects into a started process and writes over process memory using WriteProcessMemory call. In games this is not something you would want because it can provide the hacker to change the portion of the game and give himself an advantage.
There is a possibility to force a user to run a third-party program along with the game and I would need to know what would be the best way to prevent such injection. I already tried to use a function EnumProcessModules which lists all process DLLs with no success. It seems to me that the hacks inject directly into process memory (end of stack?), therefore it is undetected. At the moment I have came down to a few options.
Create a blacklist of files, file patterns, process names and memory patterns of most known public hacks and scan them with the program. The problem with this is that I would need to maintain the blacklist and also create an update of the program to hold all avalible hacks. I also found this usefull answer Detecting memory access to a process but it could be possible that some existing DLL is already using those calls so there could be false positives.
Using ReadProcessMemory to monitor the changes in well known memory offsets (hacks usually use the same offsets to achieve something). I would need to run a few hacks, monitor the behaviour and get samples of hack behaviour when comparing to normal run.
Would it be possible to somehow rearrange the process memory after it starts? Maybe just pushing the process memory down the stack could confuse the hack.
This is an example of the hack call:
WriteProcessMemory(phandler,0xsomeoffset,&datatowrite,...);
So unless the hack is a little more smarter to search for the actual start of the process it would already be a great success. I wonder if there is a system call that could rewrite the memory to another location or somehow insert some null data in front of the stack.
So, what would be the best way to go with this? It is a really interesting and dark area of the programming so I would like to hear as much interesting ideas as possible. The goal is to either prevent the hack from working or detect it.
Best regards
Time after time compute the hash or CRC of application's image stored in memory and compare it with known hash or CRC.
Our service http://activation-cloud.com provides the ability to check integrity of application against the signature stored in database.
I can use CreateProcess to launch an EXE. I want to have the contents of an EXE in a memory buffer and do CreateProcess (or an equivalent) on it without having to write it to a file. Is there any way to do that?
The backstory : we make games. We send a plain EXE to our distributors, which then wrap it using their favorite DRM and sell it to their users. There have been instances where users find crashes. Most of the crashes take 5 minutes to fix, but the patch must go through the distributor and it may take several days, even weeks. I can't just send the patched EXE to the players because it wouldn't have the distributor's DRM. I'm thinking of distributing the real game EXE inside an encrypted datafile so what gets wrapped (the external EXE) just decrypts and launches the real EXE. This way I could safely distribute a fix without disabling the DRM.
It's actually quite easy. Similar technique has been described in a paper I read like 3 years ago.
Windows allow you to call the CreateProcess function with CREATE_SUSPENDED flag, that tells the API to keep the process suspended until the ResumeThread function is called.
This gives us time to grab the suspended thread's context using GetThreadContext function, then the EBX register will hold a pointer to the PBE(Process Enviroment Block) structure, which we need to determine the base address.
From the layout of the PBE structure we can see that the ImageBaseAddress is stored at the 8th byte, therefore [EBX+8] will give us actual base address of the process being suspended.
Now we need the in-memory EXE and do appropiate alignment if the alignment of memory and in-memory EXE differs.
If the base address of suspended process and in-memory exe matches, plus if the imageSize of the in-memory exe is lesser or equal to the suspended process' we can simply use WriteProcessMemory to write in-memory exe into the memory space of the suspended process.
But if the aforementioned conditions weren't met, we need a little more magic.
First, we need to unmap the original image using ZwUnmapViewOfSection, and then allocate enough memory using VirtualAllocEx within the memory space of the suspended process. Now we need to write the in-memory exe into the memory space of the suspended process using the WriteProcessMemory function.
Next, patch the BaseAddress of the in-memory exe into the PEB->ImageBaseAddress of the suspended process.
EAX register of the thread context holds EntryPoint address, which we need to rewrite with the EntryPoint address of the in-memory exe. Now we need to save the altered thread context using the SetThreadContext function.
Voila! We're ready to call the ResumeThread function on the suspended process to execute it!
You can compile the game as a DLL and put the DLL in the encrypted data file. A DLL can be loaded from memory without writing it to disk. Please see this tutorial (with sample code at the end): Loading a DLL From Memory
What you want to do requires NtCreateProcess, but it's undocumented and therefore brittle. This book apparently covers its use.
Perhaps you could build a patch system? E.g. on launch, program checks for patch DLL in same directory, and loads it if it exists.
Why do you need to create a new process? I would have thought you could run in the context of process which does the unpacking/decryption.
What you want can be achieved with something called a "Packer". Actually launching an exe from memory might be possible, but it's a lot harder than a packer ;)
One of the best known packers is UPX (google it). There are tools to decrypt it, but it should at least give you a starting point to work froim. I'm also fairly certain UPX is open-source.
Look at BoxedAppSDK
It supports launching exe from a memory buffer.
hope it helps.