Principle of Windows CE cross-process memory injection

Directory

• • Principle of Windows CE cross-process memory injection
• • I. Prerequisites for Program Implementation
• • 2. Basic principles of Program Implementation

Edit the returned directory Principle of Windows CE cross-process memory injection

RecentlyProgramI have studied the memory layout of wincowsce for the design purpose. As I found that there are few documents in China in this regard, I formed this example document at the end of the study, hope to attract others.

Edit the returned directoryI. Prerequisites for Program Implementation

Because form messages in windows are always delivered to the specified form message function of a specific process. Therefore, the following two parts must be implemented to obtain messages in the form of other processes in the local process (your own application:

1. MountCodePut it in the address space of the target process.

2. Execute this code and obtain the message of the target process form.

These two steps seem simple, but they are difficult to implement. Windows CE, as an embedded mobile device operating system, is significantly different from Windows 98/2000/XP and other desktop operating systems in terms of kernel design and API support. This directly causes the conventional desktop system to completely fail in CE by using global mouse hook injection, remote thread injection, and other methods. However, the remotexxx and other remote debugging programs provided by Microsoft in development tools make me clear that this goal is not an impossible task. Since Microsoft can do this, that is to say, there must be a complete cross-Process Memory Access/code injection mechanism within ce.

Edit the returned directoryIi. Basic principles of Program Implementation

After two days of Google searching, I found an interesting API function called performcallback4, which was not declared in Microsoft documents on the Internet, it is said that this function can execute a function in a specified process in its own application, so cool! This seems to be exactly what I need. Although it is rumored that this function is not supported by wm5 on the Internet, it is just a rumor after practice!

Definition of the performcallback4 function:

[Dllimport ("coredll. dll")]

Public static extern uint callback mcallback4 (ref callbackinfo,

Intptr ni_pvoid1, intptr ni_pvoid2, intptr ni_pvoid3 );

 

The callbackinfo structure of the function is defined as follows:

[Structlayout (layoutkind. Sequential)]

Public struct callbackinfo

{

Public intptr hproc; // remote target process

Public intptr PFN; // pointer to the function address of the remote target process

Public intptr pvarg0; // The first parameter required by the function

} // End struct

 

Ni_pvoid1, ni_pvoid2, and ni_pvoid3 of objective mcallback4 are the other three parameters passed to the remote target process for function execution.

As for putting code into the memory space of the target process, we can use a feature of Ce design:

1. To save memory usage, Ce maps the dynamic link library (DLL) called by all programs to the same memory address.

2. in CE's memory layout, there is an slot0 memory location, which is occupied by the processes being executed, each specific time slice, only one process can occupy the memory space. When a process requires execution, the system does not directly execute the code at the memory location of the process, but copies the Execution Code of the process to the memory location of slot0 to generate a copy for execution. That is to say, when a process is executed, there will be two identical versions of the Code executed by the process: the code that is being executed in slot0 and the code in the memory of the process itself.

With this feature, we can conclude that if process a Loads Test through the loadlibrary function. and process B also loads the same test using the loadlibrary function. DLL, this test. when all DLL functions are executed in process a and process B, the same address is obtained relative to the Process Execution Code in slot0.

3. In Ce, the system divides 33 slots into memory, and slot0 is retained to the running process, then, when the process starts, all the code will be put in a slot other than slot0 (this is the reason why the notorious CE system has a maximum of 32 program execution restrictions in memory). During process execution, the memory access of each application can only access the address in the slot0 memory space and the address in the slot memory space of the process by default. To allow device drivers to access other application data they need, Ce provides two functions to break this restriction. setkmode and setprocpermission, The setkmode function tells the system, whether the currently running process needs to be executed in kernel mode. The setprocpermission function can accept a single bit mask, and each bit of code has a single slot Access Control. 1 indicates that the slot's memory content can be accessed. 0 indicates that the slot's memory content cannot be accessed. The two functions are available in the msdn help documentation. For more information, see the msdn documentation.