Operating system type for non-API function Detection

Source: Internet
Author: User
Operating system type for non-API function Detection

From: http://www.xfocus.net/articles/200504/793.html
Creation Time: Update Time:
Article attributes: Translation
Article submission: sfqry (mqphk163_at_163.com)

Operating system type for non-API function Detection
Author: Thomas Kruse, NBW
Source:

The Assembly-programming-Journal, Vol. 1, No. 1 (2004)

Http://www.Assembly-Journal.com
Abstract

Summary
Today nearly all programmers use the advanced programming interface (API) to receive information's about given system

Values. By using this API's, we don't have to take care which operating system is currently available.

Currently, almost all programmers use Extended Program interfaces (APIS) to obtain operating system information. Using the AIP function, we do not need to care about the specific operating system status currently in use.

But sometimes it might be needful to avoid the usage of such API's. This situation is given during development of software

Protections in order to avoid importing funich which-eventually-will point a reverse engineer to a solution.

But sometimes you cannot use API functions. For example, when developing protection software, it prevents the reverse engineer from disclosing the referenced function information.

This essay show up a way to detect the today given operating systems from Microsoft: Windows 95, 98, me-the non NT-based

Operating systems-and Windows NT4, 2000, XP, 2003-the NT-based operating systems.

This article describes how to detect the operating systems currently used, such as Windows 95, 98, me-non-NT kernel, and Windows NT4, 2000, and XP-NT kernel systems.

The shown source code is in Microsoft Explorer style (MASM [3]).

The Code provided here is the Microsoft assembly system (MASM [3]).

Keywords: Microsoft operating systems, software protection, assembly programming, system Internals

Key words: Microsoft operating system software protection Assembler Program System Kernel

The author Thomas Kruse has his main research focus on operating-system independent code optimising and software-protection development. He is associate

Editor of assembly-Journal and codebreakers-Journal.

Thomas Kruse, author of this article, is devoted to the study of operating system code and software protection systems, and is also the editor of assembly-Journal and codebreakers-Journal.

I. Introduction

Introduction

When analyzing the structure of the thread environment block (Teb-also known as thread information block TIB) on

Different operating systems, we find additional data followed by this structure. This additional data seems to have-on non

NT-based operating systems-no logical structure or length definition, where NT-based operating systems store the information

Inside the process environment block (peb). The only way to figure out the meaning of this data for non NT-based operating

Systems is to debug the same application on different operation systems [2].

Analyze the thread environment blocks of different operating systems (Teb --- also called the thread information block TIB). We can see the additional data of this structure. For systems with non-nt kernels, the additional data has no logical structure or length definitions, while for systems with NT kernels, they store information about the process environment block (peb. The only way to determine the meaning of the data in a non-NT kernel system is to debug the same program in different operating systems.

II. Application Start

Program start

There are always ways in detecting an operating system. It cocould be done by using the Windows API function getversionex [1]

And checking the version values returned in structure osversioninfo (Ex) [1], or by accessing register CS. Another way is

Analyzing the registers during start up of an application. There are several rules for them on how operating systems prepare

Several registers before executing the first instruction:

There are many ways to detect the operating system. You can use the Windows API function getversionex [1], and then check the return value or CS register. Another method is to analyze the register value when the program starts running. Before the operating system executes the First Command of the program, many rules can be used to process registers.

Startup values for Windows 95/98/me

Windows 95/98/me startup value)

Eax = Application entry point

Eax = program entry

EBX = 00530000 H, a fixed value

Value

Startup values for Windows NT/2000/XP/2003

Windows NT/2000/XP/2003 boot Value

Eax = NULL

EBX = 7ffdf000h, pointer to (peb)

EBX = 7ffdf000h, peb pointer

By knowing this rules we where able to check the operating system base during start up. But then we need to store the Register

Values of eax and EBX for further usage-or resolve them in a different way.

With the above features, we can determine the operating system type at startup. However, for future use, we need to store eax, EBX, or other methods.

A. Thread environment Block

A. Thread environment Block

The Teb is prepared during application start up and contain pointers to thread related additional data. The Teb structure is

Available on all operating systems. It's size is defined to 34 h bytes. The Teb address cocould be resolved by accessing

Segment register FS in the following way:

Before the program starts, Teb is initialized and contains a thread-based Data Pointer. The Teb structure is valid in all operating systems. It is 34 bytes in size. The Teb address can be obtained using the FS register in combination with the following method:

Assume FS: Nothing

MoV eax, FS: [18 h]

The register eax will contain the base address of this block. The Teb contains-at address 18 h inside the structure-a pointer

To itself:

The eax register contains the Teb address. In the Teb structure, the 18h is the pointer to the Teb.

Pself DWORD? ; 18 h pointer to TEB/TIB

The last entry of Teb is the pointer to process database. On NT-based operating systems this value will point to the address

Of process environment block (see section II-C)

The final content of Teb is a pointer to process data. In the NT kernel system, this value points to the process environment block (refer to the II-C Section)

B. Additional data following Teb

B. Teb additional data

Told in Section I, this additional data has no logical structure and differs on each non NT-based operating system. On Windows

NT, 2000, XP and 2003 this additional data is defined as follows:

As mentioned in Part I, attaching data blocks to each non-NT kernel system has no logical structure or specific definitions ). In Windows NT, 2000, XP, and 2003, the data is as follows:

Nt_teb_addon struct

Lasterrorvalue DWORD? ; 00 H (34 h Teb)

Laststatusvalue DWORD? ; 04 H (38 H Teb)

Countownedlocks DWORD? ; 08 h (3ch Teb)

Harderrorsmode DWORD? ; 0ch (40 h Teb)

Nt_teb_addon ends

Windows 95, 98, me didn't have such a structure; the additional data is scrambled!

Windows 95, 98, and me do not have these data structures. Attaching data is totally confusing!

C. process environment Block

C. process environment Block

Windows NT-based operating systems store process related data inside the process environment block. The address of this

Structure is avaliable by accessing the segment register FS:

The NT kernel system stores process-related data in the process environment block. The address of this structure can be obtained by operating the FS register:

Assume FS: Nothing

MoV eax, FS: [30 h]

The register eax will contain the base address of peb.

The base address of peb is in the eax register.

Pprocess DWORD? ; 30 h pointer to process database

The version information is stored inside the peb structure:

The operating system information is stored in the peb structure:

Osmajorversion DWORD? ; A4h <= 4-> NT/5-> 2 k/XP/2K3

Osminorversion DWORD? ; A8h 0-> 2 k/1-> XP/2-> 2K3

D. NT-based definitions

D. definitions in the NT kernel

Windows NT, 2000, XP and 2003 use fixed addresses to store peb and Teb. The peb is always stored at address 7ffdf000h

And Teb is starting at 7ffde000h. By knowing these two fixed values, it is possible to detect the operating system base.

Windows NT, 2000, XP and 2003 use fixed data storage peb and Teb. Peb is always stored in 7ffdf000h, and Teb always starts from 7ffde000h. You can detect the operating system type by knowing the two fixed data.

III. The trick

Iii. Tips

Section II-B has shown an add-on Structure for NT-based operating systems. The data exists on non NT-based operating

Systems, too. But it is stored in a different way. To resolve correct memory positions-related to detect the Operating System

The II-B section describes the storage of additional data in the NT kernel system. This data also exists in non-NT kernel systems. But the storage method is different. The operating system type can be detected by obtaining the location of the data.

-We use a trick the analyze the additional data.

-We use some techniques to analyze the additional data.

If we take a closer look to the NT Teb addon structure shown in section II-B, we see the entry lasterrorvalue. Nearly

All Windows API's will return an error value which is accessible via getlasterror [1]. In addition to this, it is possible

Manipulate the lasterrorvalue via setlasterror [1] API. By using this API and monitoring the memory area behind the Teb,

The locations for the lasterrorvalue are:

If you take a closer look at the NT Teb additional data in the II-B section, you can find the lasterrorvalue at the entrance. An error value is returned for almost all APIs related to getlasterror [1. You can use some techniques to use the error value returned by setlasterror [1]. To use this API and detect the memory after Teb, the position of lasterrorvalue is listed below:

Windows 95-Teb-base + 60 h

Windows 98-Teb-base + 60 h

Windows ME-Teb-base + 74 h

Now we are able to detect Windows ME or Windows 95/98. First step to our solution, but not the final one. It is possible

Detect a difference between Windows 95 and Windows 98.

Now we can detect Windows ME or Windows 95/98. This is the first step to solve the problem. The differences between Windows 95 and Windows 98 may be detected.

Section II showed the start up values and their rules. The start up value of EBX on non NT-based OS is 00530000 H. Exactly

This value will be found inside the additional data part-close to the now resolved lasterrorvalue. By analyzing it's location,

The result will be:

Section II illustrates the initialization values and their patterns. For non-NT kernel systems, EBX is initially 00530000 H. And this value can be found from the additional data-very close to the lasterrorvalue. To analyze the data, the specific location is listed below:

Windows 95-Teb-base + 58 h

Windows 98-Teb-base + 54 h

Windows ME-Teb-base + 7ch

Now we are able to differ between each non NT-based operating system.

Now we can distinguish between non-NT kernel systems.

Iv. Code Creation

Iv. Create Code

Right now, we where able the detect the version information for each operating system. We want an operating system

Independent code, we need to structure the given information's. Also it shoshould be possible to resolve the version information

Workflow independent. Section VI will show the complete solution in worker er.

Now, we can check the version information of each operating system. To make the code independent from the operating system, we need to organize the required information into a structure. It is also necessary to make the type information independent. Section VI provides a complete assembly solution.

First of all, we get the base addresses of peb and Teb and resolve the operating system base by analyzing them:

First, obtain the base addresses of peb and Teb and analyze them to obtain different operating system information.

Assume FS: Nothing

MoV EBX, FS: [18 h]; get self pointer from Teb

MoV eax, FS: [30 h]; get pointer to peb/Database

. If eax = 7ffdf000h & EBX = 7ffde000h

; Winnt based

. Else

; Win9x based

. Endif; of base check NT/9x

The version information for NT-based operation systems is stored inside peb. We only have to analyze the values

The version information of the NT kernel is stored in peb. We only need to analyze the data:

Osmajorversion and osminorversion:

MoV EBX, [eax + 0a8h]; get osminorversion

MoV eax, [eax + 0a4h]; get osmajorversion

. If eax = 5 & EBX = 0; is it Windows 2000?

. Elseif eax = 5 & EBX = 1; is it Windows XP?

. Elseif eax = 5 & EBX = 2; is it Windows 2003?

. Elseif eax <= 4; is it Windows NT?

. Endif

Non NT-based operating systems cocould be detected by analyzing the additional data area behind Teb, searching the value

00530000 h:

For non-NT kernel operating systems, you can search 00530000 h by analyzing Teb's additional data:

MoV edX, 00530000 h; the value to search

MoV eax, FS: [18 h]; get the Teb base address

MoV EBX, [eax + 58 h]; Teb-base + 58 h (w95)

MoV ECx, [eax + 7ch]; Teb-base + 7ch (WME)

MoV eax, [eax + 54 h]; Teb-base + 54 h (w98)

. If EBX = edX; is it Windows 95?

. Elseif eax = edX; is it Windows 98?

. Elseif ECx = edX; is it Windows ME?

. Endif

V. Conclusions

V. Conclusion

Resolving the operating system by using this technique is only one possibility to avoid the usage of Advanced Programming

Interface functions. Other functions, for example getcommandline [1], isdebuggerpresent [1] or named functions in this essay

Cocould be "rewritten" in the same way. In other words: the reverse engineer isn't able to set breakpoints on API function CILS,

Because they didn't exist. And mixing different operating system solutions together makes life even harder for him.

Using this technology is just a way to avoid using API functions. Many other functions, such as getcommandline [1], isdebuggerpresent [1], or some functions in this article, can be rewritten in the same way. In other words, reverse engineers do not intercept related API functions, because they are not used at all. In addition, if the processing of different operating systems is mixed, it will be more difficult for them to analyze.

Vi. Appendix

Vi. Appendix

. Const

; -- Return values from OS _getos

OS _unknown equ-1

OS _win95 equ 1

OS _win98 equ 2

OS _winme equ 3

OS _winnt equ 4

OS _win2k equ 5

OS _winxp equ 6

OS _win2k3 equ 7

. Code

OS _getos proc

Local _ thereturnvalue: DWORD

Pushad; store all registers

MoV _ thereturnvalue, OS _unknown

Assume FS: Nothing

MoV EBX, FS: [18 h]; get self pointer from Teb

MoV eax, FS: [30 h]; get pointer to peb/Database

. If eax = 7ffdf000h & EBX = 7ffde000h; winnt based

MoV EBX, [eax + 0a8h]; get osminorversion

MoV eax, [eax + 0a4h]; get osmajorversion

. If eax = 5 & EBX = 0; is it Windows 2000?

MoV _ thereturnvalue, OS _win2k

. Elseif eax = 5 & EBX = 1; is it Windows XP?

MoV _ thereturnvalue, OS _winxp

. Elseif eax = 5 & EBX = 2; is it Windows 2003?

MoV _ thereturnvalue, OS _win2k3

. Elseif eax <= 4; is it Windows NT?

MoV _ thereturnvalue, OS _winnt

. Endif

. Else; Win9x based

MoV edX, 00530000 h; the magic value to search

MoV eax, FS: [18 h]; get the Teb base address

MoV EBX, [eax + 58 h]; Teb-base + 58 h (w95)

MoV ECx, [eax + 7ch]; Teb-base + 7ch (WME)

MoV eax, [eax + 54 h]; Teb-base + 54 h (w98)

. If EBX = edX; is it Windows 95?

MoV _ thereturnvalue, OS _win95

. Elseif eax = edX; is it Windows 98?

MoV _ thereturnvalue, OS _win98

. Elseif ECx = edX; is it Windows ME?

MoV _ thereturnvalue, OS _winme

. Endif

. Endif; of base check NT/9x

Popad; restore all registers

MoV eax, _ thereturnvalue

RET; return to caller

OS _getos endp

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.