"Trap" Technology Exploration ---- Dynamic Chinese WINDOWS Technology Analysis Huaguang Technology Co., Ltd. Research and Development Center Zhang Peak
Keywords: Chinese WINDOWS relocation technology
First, what did you find? The author has been engaged in software development under Windows for many years. It has experienced Windows 2.0, 3.0, 3.1 until the growth process of WindowsNT, 95, and also traversed the evernown window, Great Wall window, dbwin, cstar, richwin and so on. product. From now on, the most affected is also the most successful, and when the four-way divide is pushed, the Chinese Star CSTAR and the Richwin teacher have, and its core technology is naturally not much. Its foreign publicity adopts unique "trap" technology to dynamically modify the Windows code, which has always been an author interested.
Exehdr is a very useful program in MicrosoftVisualc development tools that can check NE (new_executable) format files, using it to analyze the casta's Chinese.dll, will find the same two points: (with cstar 1.20 as an example) C: / cstar> EXEHDR Chinese.dll /V.............................. type offset targetBASE060aseg 2 offset 0000PTR 047eimp GDI.GETCHARABCWIDTHSPTR 059bimp GDI.ENUMFONTFAMILIESPTR 0451imp DISPLAY.14 (EXTTEXTOUT) PTR 0415imp KEYBOARD.4 (TOASCII) PTR 04baimp KEYBOARD.5 (ANSITOOEM) PTR 04c9imp KEYBOARD.6 (OEMTOANSI) PTR 04d8imp KEYBOARD.134 (ANSITOOEMBUFF) PTR 05f5imp USER.430 (LSTRCMP) PTR 04e7imp KEYBOARD.135 (OEMTOANSIBUFF) PTR 0514imp USER.431 (ANSIUPPER) PTR 0523imp USER.432 (ANSILOWER) PTR 05aaimp GDI.56 (CREATEFONT) PTR 056eimp USER.433 (ISCHARALPHA ) PTR 05b9imp GDI.57 (CREATEFONTINDIRECT) PTR 057dimp USER.434 (ISCHARALPHANUMERIC) PTR 049cimp USER.179 (GETSYSTEMMETRICS) PTR 0550imp USER.435 (ISCHARUPPER) PTR 055fimp USER.436 (ISCHARLOWER) PTR 0532imp USER.437 (ANSIUPPERBUFF) PTR 0541 IMP User.438 (ANSILOWERBUF) PTR 05C8Imp GDI.69 (DeleteObject) PTR 058CI mp GDI.70 (ENUMFONTS) PTR 04abimp KERNEL.ISDBCSLEADBYTEPTR 05d7imp GDI.82 (GETOBJECT) PTR 048dimp KERNEL.74 (OPENFILE) PTR 0460imp GDI.91 (GETTEXTEXTENT) PTR 05e6imp GDI.92 (GETTEXTFACE) PTR 046fimp GDI.350 (GETCHARWIDTH ) PTR 0442imp GDI.351 (EXTTEXTOUT) PTR 0604imp USER.471 (LSTRCMPI) PTR 04f6imp USER.472 (ANSINEXT) PTR 0505imp USER.473 (ANSIPREV) PTR 0424imp USER.108 (GETMESSAGE) PTR 0433imp USER.109 (PEEKMESSAGE) 35 RELOCATIONS ******* Innsigned the author's corresponding WindowsAPI function, in the data segment, found relocation information. 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? No doubt, 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 inquire "trap" technology, let's first introduce the module call mechanism for Windows. Windows Run Fit Mode (Real Modem), Standmode and Enhanced Mode (386EnhancedMode), although these modes are different, their core modules are completely consistent. The main three modules have the following relationship: kernel is a Windows system kernel, which does not rely on other modules.
GDI is a Windows graphics device interface module that relies on the kernel module.
User is a Windows User Interface Service Module that relies on all modules such as kernel, GDI modules, and device drivers. These three modules are actually Windows three dynamic connection libraries. In the form of the system, KERNEL has three different forms, kernel.exe (real mode), KRNL286.EXE (standard mode), KRNL386.EXE (386 Enhance mode); GDI module is gdi.exe; USER module is user.exe, although the file name is extension in EXE, but they are actually a dynamic connection library.
At the same time, almost all API functions are hidden in these three modules. Analyze the three modules with Exehdr, you can list the WindowsAPI functions you are familiar with.
Take the GDI module as an example,
C: / windows / system> execdr gdi.exeexports: ord seg offset name ............ 351 1923eextTextOut Exported, Shared Data56 319E1CREATEFONT Exported, Shared Data ........... .
At this point, you have drawn some heads from the Windows complicated system. Here, an important concept-relocation is introduced. A Windows executor calls the API function, or the call to other dynamic libraries, is a dynamic connection that cannot be positioned before the program is loaded. When the program is transferred to memory, these far adjustments need to be repositioned and repositioned. The basis is to relocate the 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, use EXEHDR / V to analyze chinese.dll
6 Type Offset Target ........ Ptr 0442imp GDI.351 ..........
It is shown that the GDI's No. 351 function is called in the 0442h offset of this paragraph. If 0000: ffff is 0000: ffff, only the GDI.351 function is called within this paragraph, otherwise, there is still a call to this function in this paragraph, the location of the call is the content pointed to by 0442h. In fact, the recipient table contains only the chain head of the list of reference locations. So, what function is GDI.351? Also use EXEHDR to make an analysis of GDI.exe, it can be obtained, in the export function of GDI, EXTTEXTOUT. In this way, with the simple and very useful tools of Exehdr, we have swayed a while in the vast ocean of Windows, and the mystery of the "trap" technology will be opened.
Third, Dynamic Chinese WINDOWS principles We know that traditional Chinese windows methods are to directly modify the display, input, printing module code of Windows, or directly develop "Chinese device" driver module with DDK, which is not only a lot of workload, but also The completeness of the system is difficult to ensure that there are many restrictions on performance (this early evergreen window is like this), so that only from the kernel modifies the Windows core code is the most thorough approach. 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 User. 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 MicrosoftVisualc development tools) to check the GDI's CODE1 segment. The first 5 bytes at 6139h are B8FF054555. After running the Richwin4.3forInternet, then view the same place, it has been changed to EA08088F3D, in fact, anti-assembly Just know that these 5 bytes are representative JMP3D8F: 0808, and the handle is a module of 0x3D8F, which is observed with Helpwalk to see the first code segment of the richwin's WSENGINE.DLL (module name Textman). Offset 0808H B8B73D45558BEC1E, is a function where a function starts, which is actually the EXTTEXTOUT function rewritten by Richwin. After exiting the Richwin, use Helpwalk to observe the Code1 code segment of GDI, everything will return to normal! This is completely consistent with the previous analysis conclusions! Then, the next key point is how to dynamically modify the Windows function code, that is, the core of Chinese Windows - "Trap" technology. Fourth, "Trap" technology discusses "traps" technology, but also back to the previous discovery. I found that one of the modified Windows functions can already be explained, but it is still a fan. The data segment stores the variables and constants, if this contains repositioning information, then it is necessary to assign the function to the variable of the FarProc type in the variable description, which is written in the variable description: FarProcarProcfunc = EXTTEXTOUT Sure enough, there is also a relocation information in the data segment of my own program. Thus, when the program is transferred in the memory, the variable FarProcFunc 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 to obtain a desktop segment name with the same base address with the code segment. The function declares that the WordFarPascalaloccstodsalias (WordCode_sel); the parameter is the handle of the code segment, the return value is writable Duan Bai name handle. The function address in Windows is 32-bit. The high character is the memory handle of its module, and the low word is the offset of the function in the module. The obtained writeable data segment is locked, and then reserves the 5 bytes of the function offset, then change it to the steering alternative function (with EAJMP)
* (LPSTR WOFFSET) = 0xEA; * (LPSTR WOFFSET 1) = LPFARPROCREPLACE
The reverse approve is JMPLPFARPROCREPLACE, and finally, the memory is unlocked. This is our "trap" set by Windows, when all calls to this function goes to our specified alternative function. Before the program ends, the 5-byte content retained will be reset, otherwise the system will crash.
Hereinafter, the author writes the source program that enables Windows's EXTTEXTOUT functions into its own function "trap".
// Source Procedure Relocate.c # incrude #include
Bool WinAPI MyExtTextout (HDC HDC, INT X, INT Y, UINT NINT1, Const Rect Far * LPRECT, LPCSTR LPSTR, UINT NINT2, INT FAR * LPINT); Word Far Pascal Alloccstodsalias (Word Code_sel);
TYPROC LPFARPROCREPLACE; // Replace the function address FarProc LPFARPROCWINDOWS; // Windows function address BYTEBOLD; / / Save the original function first byte longlold; // Save the four-byte length of the original function after the original function} func;
Funcfunc = {MyExtTextOut, EXTTEXTOUT};
// Windows Main Function Int Pascal Winmain (Hinstance Hinstance, Hinstance Hprevinstance, LPSTR LPCMDLINSTANCE, LPSTR LPCMDLINSTANCE, LPSTR LPCMDLINS, INT NCMDSHOW) {handle hMemcode; // code segment handle Word HMEMDATA; / / The same base address can be Write Division Word WOFFSET; / / Function Offset LPSTRLPSTR; LPLONG LPLONG; Char LPNOTICE [96];
HMemcode = HiWord ((long) Func.lpfarProcWindows; woffset = loword ((long) func.lpfarProcWindows;
WSPRINTF (LPNOTICE, "Module Handle 0x% 4xH, Offset 0x% 4xH", HMemcode, Woffset; MessageBox (Null, LPNOTICE, Tips ", MB_OK);
// Take the classification section of the class segment with the code section HMEMDATA = Alloccstodsalias (HMEMCODE);
LPSTR = GLOBALLOCK (HMEMDATA);
LPLONG = (LPSTR WOFFSET 1); // Save the first function to replace the header 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;
// Remove the content of the reservation back hmemdata = alloccstodsalias (hmemcode); lpstr = Globalock (HMEMDATA); lplong = (LPSTR WOFFSET 1); * (LPSTR WOFFSET) = func.bold; * llong = func.lold; GlobalUnlock (HMEMDATA);
MessageBox (NULL, "Reverting Round Windows Functions", "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, 0x20, 0x79, 0x40, 0x41, 0x04, 0x47, 0xfe, 0x41, 0x40, 0x79, 0x40, 0x09, 0x20, 0x09, 0x20, 0x09, 0x10, 0x09 0x4e, 0x51, 0x84, 0x21, 0x00, 0x04, 0x00, 0x01, 0x00, 0x00, 0x1f, 0x10, 0x10, 0x10, 0x10, 0x10, 0x1f, 0xf0, 0x00, 0x00, 0x7f, 0xFC 0x40, 0x04, 0x4f, 0xe4, 0x48, 0x24, 0x48, 0x40, 0x0c, 0x10, 0x80, 0x10, 0x11, 0x10, 0x88, 0x11, 0x50, 0x56, 0x20, 0x54, 0x5, 0x57 , 0x06, 0x54, 0x20, 0x55, 0x55, 0x54, 0x20, 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.defnameRelocateExetyPe WindowsCodePreeload Moveable DiscardableDataPreLoad Moveable MultipleHeapsize1024Exports
V. Conclusion The paper analyzes the Chinese WINDOWS method called "trap" technology in principle. To completely, the Chinese WINDOWS should also involve the display, keyboard input, etc., will not be a day. However, as an analysis of the "trap" technology, this paper introduces the general method to change any Windows function call to its own specified function, which can expand into other applications, such as multi-language display, different internal code Switch display, etc. Reference: AndrewschulmandavidMaxeymattpietRek, "Unprecedented Windows Core Technology", Tsinghua University Press, 1993. Wang Zhidong, "Windows Chinese Environment", "Windows Software Application and Development", 1993.5. (Author Address: Zhang Gaofeng Post, Zip Code, Research and Development Center, Weifang Huaguang Technology Co., Ltd., Shandong, China
