Attacking Windows 9x with Loadable Kernel Modules-百科知识库

Attacking Windows 9x with Loadable Kernel Modules - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ a r t i c l e ]　　　　　　　　　　　　　　　　　　　　 [ a u t h o r ]
Attacking Windows 9x with Loadable Kernel Modules　　　　　 Solar Eclipse
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

--------[　Solar Eclipse <solareclipse@phreedom.org>　]

----[　Introduction

This article explains the basics of Windows 9x kernel modules development and
contains the full source of a loadable kernel module (LKM) that performs the
following functions:

1) it captures TCP connections traffic and extracts telnet/pop3/ftp passwords
2) it captures dial-up connections traffic (by capturing the raw data from the
　serial port) and extracts dial-up passwords
3) by accessing the TCP stack directly (bypassing the Winsock interface), it
　emails all the collected authentication information to an evil script
　kiddie sitting in a basement full of stolen hardware
4) it is virtually undetectable with any standard Windows tools
5) it is written entirely in assembly and the executable file size is
　only 7KB

The name of the LKM is Burning Chrome. I wrote it because I had to break into
a computer system owned by a girl called Chrome. Yes, I know it sounds lame.
No, I don't know who William Gibson is. Dude, what is the Matrix?

I assume that you have a basic knowledge of Win32 programming, x86 protected
mode architecture, 32-bit assembly language programming, SoftIce and basic
Internet protocols (telnet/pop3/ftp/smtp).

I will start this article with a short overview of the Windows 9x kernel
design. Then I will describe a template kernel module and will talk about some
of the system services that Windows provides. Finally I will give you the
Burning Chrome source.

----[　Windows 9x Internals

Windows 9x has two separate layers of code: DLL layer and VXD layer.

1) DLL Layer

The DLL layer consists of all system DLLs. It runs as a Ring 3 code. All the
API functions that Windows programs normally call are implemented in the DLL
layer (in KERNEL32.DLL, USER32.DLL, GDI32.DLL and other DLLs). Many of the
DLLs call VXD functions. Some of the API functionality is implemented entirely
in the VXD layer and the DLL functions act only as gates (this is the case
with the registry access functions). Calling DLL functions from the VXD layer
is impossible and this makes most of the Windows API inaccessible to kernel
modules.

I will not discuss the system DLLs any more, because they are not used for
Windows kernel hacking.

2) VXD Layer

The general term VXD stands for Virtual Devi

ce Driver, the "x" being a
placeholder for device names. For example, VKD is a Virtual Keyboard Driver,
VDD is a Virtual Display Driver, etc. The VXD layer is the core of the Windows
OS. It is similar to the Linux kernel and the functions it provides, although
it is not nearly as well documented. The VXD code handles memory management,
task switching, low-level hardware access and other similar tasks. The core OS
services, such as registry access, networking and file access are also
implemented in the VXD layer.

All VXDs run in Ring 0 and have full access to the system. Hacking the Windows
kernel is possible by writing an VXD.

The Windows Driver Development Kit (DDK) is used for writing VXDs. Most
programmers shiver when somebody mentions 'device drivers', but but the VXDs
can be used for many other purposes. Let me quote Andrew Schulman, the author
of "Unauthorized Windows95. A Developer's Guide to Exploring the Foundations
of Windows 95":

　　"...Seen　from　this　perspective,　the　names　Virtual Device Driver and
　　Device　Driver　Kit　are　unfortunate.　They　automatically turn off most
　　Windows developers, who quite sensibly feel that device-driver writing is
　　an　area　they　would rather stay away from. More appropriate names would
　　have been "TSRs for Windows" or "Please Hack Our Operating System". As it
　　is,　the　names VXD and DDK alienate many programmers who would otherwise
　　jump at this stuff.

　　...Admittedly,　very　few Windows programmers will be using VXDs to write
　　hardware　interrupt　handlers　or　device drivers. But a short time spent
　　with　the　DDK　should　convince　you　that　there's　a ton of documented
　　functionality available to VXDs that is otherwise difficult or impossible
　　to　get　under　Windows.　Whenever　a　programmer　says that something is
　　"impossible"　in　Windows,　I　suspect　the　correct reply will be "No it
　　isn't.　Write　a　VXD"　Just　as　TSRs　allowed DOS programmers to do the
　　otherwise-impossible　in　the　1980s,　VXDs　are　going　to　let　Windows
　　programmers go anywhere and do anything in what's left of the 1990s."

Unfortunately (or maybe fortunately) writing VXDs for Windows has not become
as common as writing TSRs for DOS was. The possibilities that the Virtual
Device Drivers offer are big, but writing one is not an easy task.

----[　Your First VXD

VXDs are usually written with the Windows98 DDK, which includes a copy of the
Microsoft Macro Assembler (MASM). It is possible to use C for VXD development,
but using assembly is definitely more fun. Other tools, such as NuMega
DriverWorks make the programmer's job easier, but for this example I will use
only the Win98 DDK. The DDK is available for free download on Microsoft's web
site. Even if they take it down, you wil

l be able to find it on some old copy
of the MSDN or on the net.

Having a copy of the Windows NT4 DDK, Windows 2000 DDK and even the Windows
3.11 DDK will also be nice. Many interesting VXD features are poorly
documented or not documented at all. Although the Windows 98 DDK will be your
primary source of information, sometimes you will find the information you
need in some of the other kits. The Windows 3.11 DDK is useful, because there
are a lots of similarities in the internal architecture of Windows 3.11 and
Windows 95. (Contrary to the Microsoft hype, Windows 3.11 was closer to
Windows 95 than to Windows 3.1. Basically the only major change between 3.11
and 95 was the GUI)

The VXDs are LE executables. You need a special linker to link them (included
in the DDK).

The following source is a template for a very basic VXD. It's just an example
for a module that can be successfully loaded by the system.

<++> example.asm

; EXAMPLE.ASM

; VXDs use 386 protected mode

.386p

; Many system VXDs export services, just like the system DLLs in Windows.
; We can use these services for memory allocations, registry and file
; access, etc.
; All we need to do is include the appropriate include file. There are
; many INC files for the system VXDs that come with the DDK.
; VMM.INC is the only required include file. It contains the declarations
; for many important services exported by VMM32.VXD, as well as many
; macros that are used for VXD programming.

INCLUDE VMM.INC
; All VXDs need a Driver Declaration Block (DDB), that stores information
; about its name, version, control procedure, device ID, init order, etc.
; To build this DDB use the Declare_Virtual_Device macro with the following
; parameters:
;　 - VXD name (needs not be the same as