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

zhaozj2021-02-08 254

Abstract: Richwin, Chinese Star (CSTAR) is a well-known WINDOWS product,

"Trap" technology is dynamically modifying Windows code, has always been the technical skills, which is like it.

What is realized, this is naturally a core confidential. This article tries to unlock this secret, and simultaneously describe the module of IndOws.

Call mechanism and repositioning concept, and give example source of Windows code using "trap" technology dynamically modified Windows code

sequence.

First, what did you find?

The author has been engaged in software development under Windows for many years.

Windows 2.0, 3.0, 3.1, until the growth process of WindowsNT, 95, also traversed

Evergreen window, Great Wall window, dbwin, cstar, richwin and other Windows Chinese

product. From now on, the most affected is also the most successful, when pushing the four-way persons

Richwin, in addition, Chinese Star CSTAR and Richwin teacher, its core technology

Naturally, it is not much. Its foreign publicity adopts unique "trap" technology dynamics

Modifying Windows code, has always been an author interested in places.

Exehdr is a very useful process in MicrosoftVisualc development tools

Order, it can check the NE (new_executable) format file, use it to analyze Richwin

Wsengine.dll or cstar's Chinese.dll will find two points:

(As a CSTAR 1.20 as an example)

C: / cstar> EXEHDR CHINESE.DLL / V

................................

6 TYPE OFFSET TARGET

Base060ASEG 2 Offset 0000

PTR 047EIMP GDI.GETCHARABCWIDTHS

PTR 059bimp gdi.enumfontfamilies

PTR 0451 Imp Display.14 (EXTTEXTOUT)

PTR 0415 IMP Keyboard.4 (Toascii)

PTR 04BAIMP Keyboard.5 (ANSITOOEM)

Ptr 04c9imp keyboard.6 (Oemtoansi)

PTR 04D8IMP Keyboard.134 (ANSITOEMBUFF)

PTR 05F5IMP User.430 (LSTRCMP)

PTR 04E7imp keyboard.135 (Oemtoansibuff)

PTR 0514 IMP 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 0550 IMP User.435 (ischarupper)

PTR 055FIMP User.436 (IscharLower)

PTR 0532Imp User.437 (ANSIUPPERBUFF)

PTR 0541IMP User.438 (ANSILOWERBUFF)

PTR 05C8IMP GDI.69 (DeleteObject)

PTR 058CIMP GDI.70 (Enumfonts)

PTR 04ABIMP KERNEL.ISDBCSLEADBYTEPTR 05D7IMP GDI.82 (GetObject)

PTR 048DIMP KERNEL.74 (OpenFile)

PTR 0460 IMP GDI.91 (GetTextExtent)

PTR 05E6IMP GDI.92 (GetTextFace)

PTR 046FIMP GDI.350 (GetCharWidth)

PTR 0442Imp GDI.351 (EXTTEXTOUT)

PTR 0604 IMP User.471 (LSTRCMPI)

PTR 04F6IMP User.472 (ANSINEXT)

PTR 0505Imp User.473 (ANSIPREV)

PTR 0424 IMP User.108 (GetMessage)

PTR 0433Imp User.109 (PeekMessage)

35 Relocations

******* Corresponding to WindowsAPI functions for the author

First, in the data segment, the relocation information is discovered.

Second, these relocation information prompts, all and text display

Output and keyboard, string are related. 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 explore the "trap" technology, let's 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 relationships:

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 three dynamic connection libraries in Windows. In the form of the system, KERNEL has three different forms, kernel.exe (real mode), KRNL286.EXE (standard mode), KRNL386.

EXE (386 Enhancement Mode); GDI module is gdi.exe; USER module is User.exe, although the file name is extension in EXE, but they are actually dynamically connected.

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> exehdr gdi.exe

Exports:

ORD seg offset name

..........

351 1923EEXTTEXTOUT Exported, Shared Data

56 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 principle

We know that traditional Chinese version of Windows is to directly modify the display, input, printing module code of Windows, or use DDK to directly develop "Chinese device" driver module, which is not only a lot of workload, but also the system is complete. It is difficult to guarantee that there are many restrictions on performance (this early ever-green window is like this), so that only from the kernel to modify 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 exact Windows. 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

Discuss "Trap" technology, but also back to the two findings. I found that one of the modified Windows functions can already be explained, but it 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:

FarProcfarProcfunc = 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 writable data segment name with the code segment, and its function declares

WordfarPascalaloccstodsalias (WordCode_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-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 Project Relocate.c

#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);

Typedef struct tagfunc

{

FarProc LPFARPROCREPLACE; // Alternative function address

FarProc LPFARPROCWINDOWS; / / WINDOWS function address

Bytebold; / / save the original function first byte

Longlold; / / Save the four-byte length after the original function

} Func;

Funcfunc = {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 address can be written

Word woffset; // function offset

LPSTRLPSTR;

LPLONG LPLONG;

Char lpnotice [96];

HMemcode = HiWord ((long) Func.lpfarProcWindows;

WOFSET = Loword ((long) Func.lpfarProcWindows;

WSPrintf (LPNOTICE, "function is located in the module handle 0x% 4xh, offset 0x% 4xh,

HMemcode, WOFFSET;

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

NameRelocate

EXTYPE WINDOWS

CodepreLoad Moveable Discardable

DataPreload Moveable Multiple

HEAPSIZE1024

Exports

Five, conclude

This article 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.

references:

Andrewschulmandavidmaxeymattpietrek, "Unprecedented Windows Core Technology", Tsinghua University Press, 1993.

Wang Zhidong, "Windows Chinese Environment", "Windows Software Application and Development", 1993.5.

(Author address: Shandong Weifang Huaguang Technology Co., Ltd. Research and Development Center Zhang Gao Feng Zip 261041) "Trap" Technology Exploration ---- Analysis of Dynamic Chinese WINDOWS Technology

Huangguang Technology Co., Ltd. Research and Development Center

Abstract: Richwin, Chinese Star (CSTAR) is a well-known WINDOWS product,

"Trap" technology is dynamically modifying Windows code, has always been the technical skills, which is like it.

What is realized, this is naturally a core confidential. This article tries to unlock this secret and introduce the module of Windows.

Call mechanism and repositioning concept, and give example source of Windows code using "trap" technology dynamically modified Windows code

sequence.

Keywords: Chinese WINDOWS relocation technology