"Trap" Technology Exploration - Analysis of Dynamic Chinese WINDOWS Technology

"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.............................. 00 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 (ANSITOOEM) PTR 04c9 imp KEYBOARD.6 (OEMTOANSI) PTR 04d8 imp KEYBOARD.134 (ANSITOOEMBUFF) 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 (ANSIuppe RBUFF) PTR 0541 imp USER.438 (ANSILOWERBUFF) 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 PTR 0505 Imp User.473 (ANSIPREV) PTR 0424 IMP USER.108 (GetMessage) PTR 0433 IMP USER.109 (PEEKMESSAGE) 35 Relocations (Package Plus the corresponding Windows API function plus the author. " )

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 ..... .......-in this, the reader has been able to draw some heads from the complicated 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 with ExehDR / V:

6 Type Offset Target ........ PTR 0442 IMP GDI.351 ........ It shows that the GDI's No. 351 function is called at 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, it is necessary to use an unprecedable Windows function AllocCStodsalias, and obtain the tabletable data segment name with the same base address with the code segment, and its function is declared 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 Relocate.c # include #include BOOL WINAPI MyExtTextout (HDC HDC, INT X, INT Y, UINT NINT1, Const Rectfar * LPRECT, LPCSTR LPSTR, UINT NINT2, INT FAR * lpInt); WORD FAR PASCAL AllocCStoDSAlias ​​(WORD code_sel); typedef struct tagFUNC {FARPROC lpFarProcReplace; // address substitution function FARPROC lpFarProcWindows; // Windows function address bYTE bOld; // save the original function of the first byte LONG lOld; // save the original function of the four-byte values ​​contact} FUNC; FUNC Func = {MyExtTextOut, ExtTextOut}; // Windows main function int PASCAL WinMain (hINSTANCE hInstance, hINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {HANDLE hMemCode; // Code segment handle Word HMEMDATA; / / The same base number Word woffset; // function offset LPSTR LPSTR; LPLONG LPLONG; char lpNotice [96]; hmemcode = half ((long) func.lpfarProcWindows; woffset = LOWORD ((long) ((long); WSPrintf (LPNOTICE, "function location module handle 0x% 4xh, offset 0x% 4xH", HMemcode, Woffset; MessageBox (Null, LPNOTICE, Tips ", MB_OK); / / Take the code segment has the tablet paragraph of the same base address. HMEMDATA = AllocCstodsalias (hmemcode); lpstr = Globalock (HMEMDATA); LPLONG = (LPSTR WOFFSET 1); // Save the original function to replace the first few Byte func.bold = * ( LPSTR WOFSET; FUNC.LOLD = * LPLONG; * (LPSTR WOFFSET) = 0xEA; * LPLONG = Func.lpfarProcRecRecreplace; GlobalUnlock (HMEMDATA); MessageBox (Null, "Change to your own function", "Tips", MB_OK ); // change the reserved content back hmemdata = alloccstodsalias (hmemcode); lpstr = globalock (hmemdata); lplong = (LPSTR WOFFSET 1); * (LPSTR WOFFSET) = func.bold; * lplong = func. LOLD; GLOBALUNLOCK (HMEMDATA); MessageBox (NULL, "Rehabilitation Windows Functions", "Tips", MB_OK); Return 1;} // 自己 自己 自己 b b (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, 0x02, 0x00, 0x01, 0x04, 0x0, 0xfe, 0x00, 0x00, 0x1f, 0x10, 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, 0x11, 0x10, 0x56, 0x20, 0x54 0xD8, 0x57, 0x55, 0x54, 0x54, 0x20, 0x55, 0x54, 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 = cretecompatibleDC (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.defname relocateExetyPE Windowscode Preload Image, DiscardableData Preload Moveable, Discard ,Data, 1024Exports, 5. Conclusion The dynamic Chinese Windows method called "Trap" technology is analyzed. Methods can be expanded into other applications, such as multilingual display, switching display of different internal code systems, etc.