WINDOWS hacker BASICS (5): use memory to obtain computing results

In the previous chapter of the injection code, we used VirtualAllocEx to open up a piece of memory for the other process, and copied the code into the memory of the other process to execute the code of that memory, however, there is a problem here, that is, the Code is not executed in our process, so we cannot directly use the return value or pass in the pointer to obtain the calculation result as in the Process programming, at this time, we may need a lot of communication methods, but this will make our injection code very complicated, so I thought of a method, is to use the memory area opened by VirtualAllocEx for communication.

 

The overall steps are as follows:

1. Start a memory block in the memory of the other party,

2. Copy the code.

3. calculate where our results should be stored based on the Code. For example, we applied for a 100-byte memory, of which 50 bytes is the code, then we should try to put our results in a location after 50 bytes.

4. assuming that our results are placed at the memory offset of 60 based on the above steps, we can move the pointer pointing to the fast memory to 60 bytes backward, so this is where we store the results.

 

The above method is only suitable for storing small data. If large data needs to be transmitted, we still need other means, such as opening up shared memory and using SOCKET.

 

Some people will also say that a memory is specially used to store data. In this way, we can place the memory in this place, instead of confusing the Code with the computing results. But we need to know that because of the memory ing,The virtual memory addresses of different processes pointing to the same physical memory are not necessarily the same,That is to say, we have injected the code from process A into process B. At this time, our process A has A piece of memory to process B VirtualAllocEx, and the address of process A is 1000, our code also writes data to the virtual memory address 1000, but this code is executed in process B. What is the virtual memory address 1000 of process B ?? No one knows

 

Another important thing in this method is to get the address of the current Code run. The register has an EIP, which allows us to see the code of the memory address where the program runs, however, we cannot use or read EIP in the compiler, so we use the call command. After the CPU executes the CALL command, we will push the address of our next code to the stack. In this case, we can obtain the address of the next code.

Call Next

Next: pop eax

In this way, the eax contains the next: pop eax Code address.

But I thought about it later. This method is not very secure because, like the one mentioned above, the virtual addresses corresponding to different processes pointing to the same physical memory are not necessarily the same, the compiler has written the address to death when compiling cal next for us. I tested that the virtual memory addresses of two different processes are the same, but I did not find a clear description, so there is no way to determine, so this method is not very secure

 

I also wanted to use another method: CONTEXT. In windows, GetThreadContxt can get the context of the current thread, but this method cannot get the correct EIP, because if a thread does not stop running, the EIP will change, but I thought about how to get the function call stack when we debug it, we should also find a way to get the function call stack, this method may not be able to get the EIP, but it can get the address of some functions in the thread. Later, it can also put data somewhere in the memory through the function address + offset.