Screen to get the word core insider
This article only discusses the details of several critical technologies, other programming details, please refer to the source program.
32-bit to 16-bit form replacement
32-bit code with 16-digit data exchange
Dynamically modify the Windows kernel
1. 32bit to 16bit form replacement (Thunk)
The formal replacement refers to techniques that allow for 32-bit code from 16-bit code to call 16-bit code from 32-bit code. The form is replaced to solve the problem that attempts to coexist up the 16-bit code and 32-bit code simultaneously on the same operating system or the same executable, that is, 16-bit code and 32-bit code mixed programming technology. Early DOS programs and WINDOW3.x are 16 programs, while Windows 95 and Windows NT can also run old 16-bit programs, but their mainstream development is 32-bit applications. Unlike Windows NT, Windows95 is not a "pure" 32-bit operating system. In order to have a satisfactory speed and good compatibility with old 16-bit programs, its kernel itself is a 16-bit and 32-bit mixing. Body, therefore also provides convenience for the use of programmers. Microsoft provides universal interface and tools for writing a form replacement, but because of the form of LTW32 is not complicated, some programming techniques are used, and the developing tools that use Microsoft complex development tools are used.
The main problem in form replacement has two points: 116 bits and 32-bit data type size variations, such as one of the 16-bit code to 32-bit code is the length of the integer INT; 2 is the stack operation, The 16-bit mode uses the SS: SP Stack Pointer to control the top, and the ESP register is used in the 32-bit mode to use the ESP register to control the top of the stack.
In the LTW32, the screen scratch function is implemented by 16-bit DLL, so it is only necessary to implement 32-bit to 16-bit forms, and provide a 16-bit DLL call interface for 32-bit code. Call fword PTR is a calling method for 32-bit assembly code, which allows 32-bit code to 16-bit code. As the key to implementation, control the stack of 16-bit side and 32-bit sides is the point of programming.
32-bit call code:
_asm {
Pusha
Call fword PTR [func16bit] / * func16bit is the 48-bit address of 16-bit caller * /
POPA
}
16-bit call code:
Int Dummy;
Static Char Stack [8192]; / * 16-bit code temporary stack * /
Static Word Stack_SEG;
Static Word Prev_Seg;
Static DWORD prev_ofs;
Static Word prev_ds;
_asm {
Push AX;
Push bx;
MOV AX, DS;
MOV BX, SEG DUMMY;
MOV DS, BX;
MOV Stack_SEG, BX;
MOV Prev_DS, AX;
POP bx;
POP AX;
Mov prev_seg, ss;
MOV DWORD PTR Prev_Ofs, ESP; / * Save 32-bit stack pointer * /
MOV SS, Stack_SEG;
MOV SP, OFFSET Stack; / * Set 16-bit stack pointer * /
Add SP, 8192;
}
/ * Add 16-bit code to implement * /
_asm {
MOV SS, Prev_Seg;
MOV ESP, DWORD PTR Prev_OFS; / * Restore 32-bit stack pointer * /
MOV DS, prev_ds;
Lea SP, Word PTR [BP-2];
POP DS;
POP BP;
Dec BP;
DB 66H;
Retf;
}
Since the parameters transmitted in the call are limited, the code involved is not much, the only relatively complex is on the 16-bit side, which temporarily turns to a 16-bit stack, serving the request from the 32-bit caller. At the 16-bit entrance, the 32-bit stack of 32-bit modes must be stored, and it is restored when the 16-bit side is returned. As can be seen from the code, this process is not reincarnating, that is, only one caller is supported at a time, because the caller is only the 32-bit code of the LTW32, so this limit can be met. In addition, when the 16-bit code returns, the 48-bit stack pointer (SS: ESP) of the 32-bit call must be restored instead of 32-bit CS: SP, and must be returned with a 48-bit address (16:32) (66h) RETF) to its 32-bit call. Handling these details, achieving 32-bit to 16-bit forms of replacement is actually very simple.
2. 32-bit code with 16-digit data exchange
32-bit code uses a 16-bit address plus 32-bit linear address (16:32) address form, and 16-bit code uses a 16-bit segment selector to add 16-bit offset (16:16) address form. On the 32-bit side of Windows 95, the address 28h is the system segment, that is, the 4G space of the system can be accessed by CS = 28h or DS = 28H, and the address space of other applications is mapped to the 4G space of the 28H segment. The address space of all 32-bit processes in Windows 95 is 18: 80000000 ~ 28: fffffffh. That is, this area is shared by all 32 digits. This is generally stored in the system DLL, the virtual device driver (VXD), memory map file, 16-bit application, and 16-bit global stacks. The last item is very important, this provides a simple way to 32-bit code exchange data with 16-bit code exchange data. Because the base address of the 16-bit segment selector is the linear address in the system segment it maps, so as long as this linear address can be obtained, the 32-bit code can easily access data of 16-bit programs (LTW32 The 32-bit side uses this method to obtain the screen intercepted information from the 16-bit side.). The linear base address of the 16-bit segment selector can be obtained by using the system call GetSelectorBase (), and the reference source program is implemented. The example of linear address is calculated as follows:
16-digit address: 07f2: 1234h
The linear base of the segment selector 07f2h is: 82F41300H
Segment selector 07f2h size is: 4000H
∵ 82F41300H 1234H = 82F42534
∴ The 32-bit linear address of 28: 82F42534H
3. Dynamically modify the Windows kernel
As mentioned earlier, Windows95 is not a "pure" 32-bit operating system, and the USER and GDI in the kernel module are implemented with 16-bit code. USER32.DLL and GDI32.DLL are just 16-bit USER.EXE and GDI.EXE 32-bit call interface. Therefore, if the screen interception program is implemented with a 32-bit code, only the 32-bit application can be intercepted by User32.dll and GDI32.DLL, and the 16-bit application cannot intercept the call to USER.EXE and GDI.exe, so if If you want to intercepting all applications (including Windows 95 Desktop Explorer) For system calls for screen output, you should implement screen interception functions with 16-bit code. This is why the LTW32 is not "pure" 32-bit application. LTW32 mainly intercepts two systems calling textOut () and extTextOut (), the method is simple, modify the first five bytes of the two functions to a JMP FAR directive, make the call to the screen intercept program for the call of the two functions . This involves a key issue: dynamically modify the Windows code. In a traditional DOS program, dynamically modify the program code has no difficulty, but in Windows, don't, because in Windows, the code can be shared by multiple instances (processes) of the same program, so the system does not allow application dynamics to modify the application Code. On the 16-bit side, memory readable, write properties are associated with segment selectors. Segment selectors can basically be divided into two categories: data segment selectors and code segment selectors. The former is readable, writable, not executable; the latter is readable, executable, not writable. Windows provides system calls for these two types of segment selection phase conversion. Unapproved 16-bit system call AllocCStodsalias () assigns a data segment (DS Alias) with the same linear base and size for a given code segment selector. A given code segment can be modified by a DS alias. The use of alloccstodsalias () is as follows:
Word (FAR Pascal * Alloccstodsalias) (Word)
Alloccstodsalias = getProcAddress
GetModuleHandle ("kernel"), "alloccstodsalias");
The call parameter is a given code selector, and then returns a linear base and dimensions as the original code selection when calling successfully. When you no longer use this DS alias, use the system call freeselector () to release the DS alias.
With the above technique, dynamically modifying Windows code can be realized, thereby changing the execution of the GDI system call textOut () and extTextOut (), intercepting the screen output in real time, providing possibilities to implement the mouse follow-up translation.
Replace the above 32-bit to 16-bit form, 32-bit code and 16-bit code data exchange, dynamically modify the WINDOWS core and other technologies, together with the word lookup algorithm and the phrase analysis algorithm to achieve mouse follow-up translation function .
