"Trap" Technology Exploration
- Analysis of dynamic Chinese WINDOWS technology
Four-way, the Chinese Star (CSTAR) is a well-known WINDOWS product, "trap" technology, dynamically modified Windows code, has always been the technical technology. This article starts from Windows module call mechanism and repositioning concept, introduces the implementation of "trap" technology, and gives an example source program that uses "trap" technology to dynamically modify the Windows code.
First, what did you find?
The author has been engaged in software development under Windows for many years. I have experienced Windows 2.0, 3.0, 3.1 until Windows 95, NT growth process, and also traversed with green windows, Great Wall windows, dbwin, cstar, richwin and other Windows Chinese. product. From now on, the most affected is also the most successful, and the Richwin of the four-way persons; in addition, the Chinese Star cstar and the Richwin teacher, and its core technology is natural. Its external publicity uses a unique "trap" technology to dynamically modify the Windows code, which is always interested in the author.
Exehdr is a very useful program in Microsoft Visual C development tool that checks the NE (New-EXE CUTABLE) format file, uses it to analyze Richwin's WSENGINE.DLL or CSTAR's Chinese.dll, will find that Two points (as examples of CSTAR 1.20):
C: / cstar> EXEHDR CHINESE.DLL / V
................................
6 TYPE OFFSET TARGET
Base 060a seg 2 offset 0000
PTR 047E IMP GDI.GETCHARABCWIDTHS
PTR 059B IMP gdi.enumfontfamilies
PTR 0451 Imp Display.14 (EXTTEXTOUT)
PTR 0415 IMP Keyboard.4 (Toascii)
PTR 04BA IMP Keyboard.5 (ANSITOEM)
PTR 04C9 IMP Keyboard.6 (Oemtoansi)
PTR 04D8 IMP Keyboard.134 (ANSITOEMBUF)
PTR 05F5 IMP USER.430 (LSTRCMP)
PTR 04E7 IMP Keyboard.135 (Oemtoansibuff)
PTR 0514 IMP User.431 (ANSIUPPER)
PTR 0523 IMP User.432 (ANSILOWER)
PTR 05AA IMP GDI.56 (CREATEFONT)
PTR 056E IMP User.433 (ISCharalpha)
PTR 05B9 IMP GDI.57 (CREATEFONTINDIRECT)
PTR 057D IMP User.434 (ISCharalPhanumeric)
PTR 049C IMP User.179 (GetSystemMetrics)
PTR 0550 IMP User.435 (ISCHARUPPER)
PTR 055F IMP User.436 (IscharLower)
PTR 0532 IMP User.437 (ANSIUPPERBUFF)
PTR 0541 IMP User.438 (ANSILOWERBUF)
PTR 05C8 IMP GDI.69 (DeleteObject)
PTR 058C IMP GDI.70 (Enumfonts) PTR 04AB IMP KERNEL.ISDBCSLEADBYTE
PTR 05D7 IMP GDI.82 (GetObject)
PTR 048D IMP KERNEL.74 (OpenFile)
PTR 0460 IMP GDI.91 (GetTextextent)
PTR 05E6 IMP GDI.92 (GetTextFace)
PTR 046F IMP GDI.350 (GetCharWidth)
PTR 0442 IMP GDI.351 (EXTTEXTOUT)
PTR 0604 IMP User.471 (LSTRCMPI)
PTR 04F6 IMP User.472 (ANSINEXT)
PTR 0505 IMP User.473 (ANSIPREV)
PTR 0424 IMP User.108 (GetMessage)
PTR 0433 IMP User.109 (PeekMessage)
35 Relocations
(The corresponding Windows API function added to the author in parentheses.)
First, in the data segment, the relocation information is discovered.
Second, these relocation information prompts are all related to text display output and keyboard, string. That is to say, Chinese, Windows, must modify these functions.
In this very special place, what is hidden? Undoubtedly, this is different from the people, and the door to the "trap" technology is not a golden key, but also knocking on the door.
Second, Windows module call mechanism and relocation concept
In order to explore the "trap" technology, let's introduce the module call mechanism for Windows.
Windows runs three types, standard mode and enhanced models, although these models are different, but their core modules are completely consistent, see Figure 1.
The main three modules have the following relationships:
· Kernel is a Windows system kernel, which does not rely on other modules.
· GDI is a Windows graphics device interface module, which relies on the kernel module.
· User is a Windows User Interface Service Module that relies on all modules such as kernel, GDI module, and device drivers.
These three modules are actually three dynamic link libraries for Windows. KERNEL has three systems: Kern El.exe, KRNL286.EXE (standard mode), KRNL386.EXE (386 enhancement mode); GDI module is GDI.EX E; the USER module is User.exe. Although the file name is extension in EXE, they are actually dynamic link libraries.
Figure 1 Module call mechanism for Windows
At the same time, almost all API functions are hidden in these three modules. The three modules can be analyzed by EXEHDR to list a large number of Windows API functions familiar with.
Taking the GDI module as an example, the operation results are as follows:
C: / windows / system> exehdr gdi.exe
Exports:
RD seg offset name
..........
351 1 923e EXTTEXTOUT Exported, Shared Data
56 3 19e1 CreateFont Exported, Shared Data
..........
At this point, the reader has drawn some heads from the complex system of Windows. Here, an important concept-relocation is introduced.
A Windows executor calls the API function or the call to other dynamic libraries, is some dynamic links that cannot be positioned before the program is loaded; when the program is transferred to memory, these far adjustments need to be repositioned, repositioned. Based on the relocation table. Behind each segment of the Windows executor (including dynamic libraries) is usually followed by a reposition table. The relocation contains the module, function serial number, and position positioning in the module.
For example, analyze chinese.dll by ExEhdr / V: 6 Type Offset Target
........
PTR 0442 IMP GDI.351
........
It is shown that the GDI's No. 351 function is called in the 0442h offset of this paragraph. If you are 0000: ffff at 0442H: FFF, it means that only the GDI.351 function is called only in this section; otherwise, there is still a call to this function in this paragraph, the location of the call is 0442H, actually The relocation table contains only the links of the list of the reference location. So, what function is a function? Use Exehdr to analyze GDI.exe, it can be obtained, in the export function in GDI, EXTTEXTOUT.
In this way, with the simple and very useful tool help in Exehdr, we have swayed a while in the vast ocean of Windows, let us continue to go deep into the way.
Third, dynamic Chinese WINDOWS principle
We know that traditional Chinese version of Windows is to directly modify Windows display, input, printing module code, or use DDK to directly develop "Chinese Device" driver module. This is not only a lot of workload, but also the system's completeness is difficult to ensure that there are many restrictions on performance (this is the earlier Early Early window), so only the most thorough ways from the kernel modified Windows core code.
From Windows module call mechanism, we can see that Windows is actually supported by many functions included in several modules such as Kernel, GDI, and US ER. Then, modify the function involving language text processing, so that it can meet the needs of Chinese, is it possible to achieve the purpose of Chinese?
Thus, we can draw this conclusion: Repatriate multiple functions involving text display in its own module, then, then refer to these functions in Windows to your modules. Modify which functions can complete Chinese, which requires in-depth analysis of Windows internal structure, but Chinese.dll has clearly telling us that the reference function listed in the relocation table of its data segment is exactly the Windows modified by cstar. Function! In order to verify this idea, we use Richwin to make a verification.
GDI.exe was analyzed with ExeHDR to derive the EXTTEXTOUT function at the GDI's first code segment 6139h offset (different versions of Windows the code segment and offset may be different). Then, use Helpwalk (also one of the Microsoft Visual C Development Tool) to check the Code1 segment of GDI, 6139h, 5 bytes are B8 FF 05 45 55, after running Ri Chwin 4.3 for Internet, then view the same place It has been changed to EA 08 08 8F 3D. In fact, the anti-assembly will know that these 5 bytes are JMP 3D8F: 0808, and the handle is a module of 0x3D8F, which can observe the first code segment of the Wsengine.dll of Richwin with Helpwalk (module name Textman). Offset 0808H B8 B7 3D 45 55 8B E C 1e, it is a function starting, which is actually the EXTTEXTOUT function rewritten by Richwin. After using the ri chwin, use Helpwalk to observe the GDI's CODE1 code segment. Everything will return to normal! This is completely consistent with the previous analysis conclusions! So, how is the next key point to dynamically modify the Windows function code, which is the core of Chinese Windows - "Trap" technology.
Fourth, "trap" technology
Discuss "Trap" technology, but also back to the two findings. I found that one of the modified Windows functions is already explained, but one of the discovered is still a fan.
The data segment stores content and other content, if this contains relocation information, then it must be assigned to a variable of a FarProc type in the variable description, so written in the variable description:
FarProc FarProcfunc = EXTTEXTOUT;
Sure enough, there is also a relocation information in the data segment of your program. In this way, when the program is transferred to memory, the Variable FarPro CFUNC is already the address of the function EXTTEXTOUT.
To directly modify the content of the code segment, you have encountered a problem, that is, the code segment is not rewritable. At this time, you need to use an unapplicted Windows function AllocCStodsalias, and obtain the tabletable data segment name with the code segment has the same base address, its function declares as: Word Far Pascal Alloccstodsalias (Word Code_sel);
The parameter is the handle of the code segment, and the return value is a handleable data segment.
The function address in Windows is 32 bits. The high byte is the memory handle of its module, and the low byte is the offset of the function in the module. The obtained writeable data segment is locked, and then the 5 bytes of the function offset will be reserved, and then it is changed to the steering alternative function (with EA JMP):
* (LPSTR WOFFSET) = 0xEA;
Four-way, the Chinese Star (CSTAR) is a well-known WINDOWS product, "trap" technology, dynamically modified Windows code, has always been the technical technology. This article starts from Windows module call mechanism and repositioning concept, introduces the implementation of "trap" technology, and gives an example source program that uses "trap" technology to dynamically modify the Windows code.
// Source Project Relocate.c
#include
#include
Bool WinApi MyExtTextout (HDC HDC, INT X, INT Y, UINT NINT1, Const Rectfar * L
Prect, LPCSTR LPSTR, UINT NINT2, INT FAR * LPINT
Word Far Pascal Alloccstodsalias (Word Code_sel);
Typedef struct tagfunc
{
FarProc LPFARPROCREPLACE; // Alternative function address
FarProc LPFARPROCWINDOWS; / / WINDOWS function address
Byte bold; / / save the original function first byte
Long LOLD; / / Save the four-byte length after the original function
} Func;
Func func = {MyExtTextOut, EXTTEXTOUT};
// Windows main function
INT Pascal Winmain (Hinstance Hinstance, Hinstance Hprevinstance, LPSTR LPCMDL
INE, INT ncmdshow) {
Handle hmemcode; // code segment handle
Word HMEMDATA; / / The same base address can be written
Word woffset; // function offset
LPSTR LPSTR;
LPLONG LPLONG;
Char lpnotice [96];
HMemcode = HiWord ((long) Func.lpfarProcWindows;
WOFSET = Loword ((long) Func.lpfarProcWindows;
WSPRINTF (LPNOTICE, "function location module handle 0x% 4xh, offset 0x% 4xh", HMemcode, WOFSET);
MessageBox (NULL, LPNOTICE, "Tips", MB_OK);
// Take the segment of the class section of the same base section
HMEMDATA = Alloccstodsalias (HMemcode);
LPSTR = GLOBALLOCK (HMEMDATA);
LPLONG = (LPSTR WOFFSET 1);
/ / Save the first few bytes to replace the original function
Func.bold = * (LPSTR WOFFSET);
Func.lold = * LPLONG;
* (LPSTR WOFFSET) = 0xEA;
* lplong = func.lpfarProcReplace;
GlobalUnlock (HMEMDATA); MessageBox (NULL, "Change to your own function", "prompt", MB_OK;
// will be reserved back
HMEMDATA = Alloccstodsalias (HMemcode);
LPSTR = GLOBALLOCK (HMEMDATA);
LPLONG = (LPSTR WOFFSET 1);
* (LPSTR WOFFSET) = Func.Bold;
* LPLONG = func.lold;
GlobalUnlock (HMEMDATA);
MessageBox (NULL, "Replacement Round Windows Function", "Tips", MB_OK;
Return 1;
}
// ourselves
Bool WinApi MyExtTextout (HDC HDC, INT X, INT Y, UINT NINT1, CONST RECT FAR *
LPRECT, LPCSTR LPSTR, UINT NINT2, INT FAR * LPINT) {
BYTE Namedot [96] = {
0x09, 0x00, 0xFD, 0x08, 0x09, 0x08, 0x09, 0x10, 0x09, 0x20,
0x79, 0x40, 0x41, 0x04, 0x47, 0xfe, 0x41, 0x40, 0x79, 0x40,
0x09, 0x20, 0x09, 0x20, 0x09, 0x10, 0x09, 0x4e, 0x51, 0x84,
0x21, 0x00, 0x02, 0x00, 0x01, 0x04, 0xFF, 0xfe, 0x00, 0x00,
0x1f, 0xf0, 0x10, 0x10, 0x10, 0x10, 0x1f, 0xf0, 0x00, 0x00,
0x7f, 0xfc, 0x40, 0x04, 0x4f, 0xe4, 0x48, 0x24, 0x48, 0x24,
0x4f, 0xE4, 0x40, 0x0c, 0x10, 0x80, 0x10, 0xfc, 0x10, 0x88,
0x11, 0x50, 0x56, 0x20, 0x54, 0xD8, 0x57, 0x06, 0x54, 0x20,
0x55, 0xfc, 0x54, 0x20, 0x55, 0xfc, 0x5c, 0x20, 0x67, 0xfe,
0x00, 0x20, 0x00, 0x20, 0x00, 0x20
}
Hbitmap hbitmap, holdbitmap;
HDC HMEMDC;
BYTE FAR * LPDOT;
INT I;
For (i = 0; i <3; i )
{
LPDOT = (LPSTR) Namedot i * 32;
HMEMDC = CreateCompaTibleDC (HDC);
Hbitmap = CreateBitmap (16, 16, 1, 1, lpdot);
SetBitmapBits (HbitMap, 32L, LPDOT);
HoldbitMap = SELECTOBJECT (HMEMDC, HBitmap);
Bitblt (HDC, X I * 16, Y, 16, 16, HMEMDC, 0, 0, SRCCopy);
Deletedc (HMEMDC);
DeleteObject (HbitMap);
}
Return True;
}
// Module definition file relocate.def
Name relocate
EXTYPE WINDOWS
Code Preload Moveable Discardable
Data Preload Moveable Multiple
Heapsize 1024
Exports
Five, conclude
