Cold River Single Fishing--windows Core Security Programming notes (i)

Chapter One: Kernel Superior guidance

1, if the Driverunload function pointer is not set, a kernel module cannot be unloaded once it is loaded.

2, makefile file content will never need to change.

3. The system must have been interrupted before setting a breakpoint.

4, the driver before loading, set breakpoints inconvenient, manual breakpoint as follows:

#if DBG

_asm int 3

#endif

A new breakpoint can be set after a breakpoint pops up if it is not in the debug state and the direct blue screen is executed

5, WinDbg for the two-machine debugging, SoftICE can be debugged but no longer updated, Wu Rock Peak and other people to develop the syser can also be single-machine debugging, 100% domestic

Chapter Two: Kernel programming environment and its particularity

1. On a 32-bit Windows system that can hold 4GB of memory control, the low 2G is the user space, and the high 2G is the kernel space.

2, the user space is isolated from each process, but the kernel space is shared. That is, the data in the range of high 2G controls that each process sees should be the same.

3, the kernel space is protected by hardware. x86 architecture R0 Layer code can access the kernel space, R3 layer of code to invoke R0 layer features, generally through the operating system provided by a portal (call Sysenter instructions in the port) to achieve.

4, kernel module is already in the kernel space, as R0 code execution, so there is no restriction, you can modify the kernel arbitrarily.

5, the kernel module is actually located in any one process space, but any one piece of code execution, must be in a process space, which is this process? Depending on the source of the request, the process of processing, etc., the PSGETCURRENTPROCESSID function can get the process number of the current process, and the handle returned by the function is actually a process ID

6, not so the code is running in the system process, windows so-called system process is a process called "systems", is the Windows itself generated a special process, the DriverEntry function is called, usually in the system process, This is because Windows typically uses system processes to load kernel modules, and does not mean that kernel code is always running in the system process.

7, use the macro nt_success () to determine whether a return value is successful, Ntstatus value can be found in the WDK header file (such as: ntstatus.h)

NTSTATUS MyFunction ()

{

NTSTATUS status;

Status = ZwCreateFile (...);

if (! Nt_success (status))

{

return status;

}

...

}

8. String

typedef struct _unicode_string{

USHORT Length;

USHORT MaximumLength;

Pwstr Buffer;

}unicode_string *punicode_string;

--------------------------------------------------------------------------------------

unicode_string str = rtl_constant_string (L "First:hello,my salary!");

Dbgprint ("%wz", &str);

--------------------------------------------------------------------------------------

unicode_string str = rtl_constant_string (L "Hello");

Kdprint ("buffer:%ws\nmaxinumlength:%d\nlength:%d", str. Buffer, str. MaximumLength, str. Length));

9. Kernel modules do not generate a process, just fill in a set of callback functions for Windows to invoke, and this set of callback functions must conform to the Windows kernel rules.

10. All functions of a kernel module are provided to Windows by the normal distribution function and the fast IO distribution function.

11. Most "messages" are passed in the form of a request (IRP). The device object is the only entity that can receive requests, and any "request" is sent to a device object.

12, because we always generate a do in the kernel program, and a kernel program is represented by a driver object, so a device object always belongs to a drive object. There are n devices in a drive object that are connected by this pointer as a one-way list.

13. The driver object generates multiple device objects, and Windows sends requests to the device object, but how are these requests handled? In fact, these requests are captured by the distribution function of the driven object. When the Windows kernel sends a request to a device, one of the distribution functions that drives the object is called.

14, such as WriteFile these operations will eventually be translated into the kernel by the IO Manager request (IRP or other equivalent form, such as fast IO call) sent to a device object.

15, an IRP often to pass n devices to be completed, in the transfer process there may be some intermediate transformations, resulting in the request parameter changes. To save this parameter change, we leave a stack space for each transfer to hold the intermediate parameters. So a request is not a simple input and waits for an output, but a lot of transit to complete

16. The IO Manager is the key component that translates the API functions invoked by the user into an IRP or sends an equivalence request to each of the different devices in the kernel.

17. Functions in the common C run-time library can be invoked in kernel programs if they involve only string and memory data (without involving memory management, such as memory allocation and deallocation).

18, any function may have more than one call source, the main trace to the source of the call is as follows:

(1) Import function DriverEntry and unload function driverunload.

(2) Various distribution functions (including normal distribution functions and fast IO distribution functions)

(3) The completion function that is set when the request is processed. That is, the callback function that is called by the system when the request is completed

(4) Other callback functions (such as the characteristic functions of various NDIS drivers)

19. Find out where the possible call source for this code should be, there is a great benefit to the process function reentrant and to consider running the interrupt level

20, when you need to ensure that the function of multithreading security can be easily judged by the following rules:

(1, functions that may run in a multithreaded environment, must be multithreaded security, only run in a single-threaded environment function, it does not require multi-threading security.)

(2) If all the call sources for function a run only in the same single-threaded environment, function A is also only running in a single-threaded environment.

(3) If one of the call sources of function A is likely to run in a multithreaded environment, or if multiple calling sources may be running in different concurrent multiple threading environments, and the call path does not take a single-threaded enforcement of the multiline program, then function A is also likely to run in a multithreaded environment.

(4) If all the call paths in function A that may run in a multithreaded environment have multi-threaded procedures serialized into single-threaded enforcement, then function A is run in a single-threaded environment.

(5, the so-called multi-line program into a single-threaded mandatory measures are referred to as a mutex, spin lock and other synchronous means.

(6) using only the internal resources of the function, functions that are completely non-functional global variables, static variables, or other global resources are multithreaded security.

(7) If all access to a global variable or a static variable is restricted to a single thread access at the same time, the global variables and static variables are used, and the multithreading security of the age function is not affected.

21 The runtime environment of the main calling source of the kernel code

Call source	Operating Environment	Reason
Driverentry,driverunload	Single Thread	These two functions are called by a single thread of the system process. There is no case where multithreading is called at the same time.
Various distribution functions	Multithreading	There is no document to ensure that the distribution function is not called at the same time by multithreading. In addition, the distribution function does not concurrency with DriverEntry, but May and driverunload concurrency
Completion function	Multithreading	The completion function may be called by the location's thread at any time
Various NDIS callback functions	Multithreading	Same as completion function

22, Interrupt level: passive level and dispatch level, dispatch level than passive level, in real programming, many of the more complex features of the kernel API requirements must be performed at the passive level, only relatively simple functions can be executed at the dispatch level. Before invoking any of the kernel APIs, you must review the WDK documentation to understand the interrupt level requirements for this kernel API

23. Determine the possible interrupt level of the code being written:

(1) If there is no special case on the call path (resulting in an increase or decrease in the interrupt level), then the interrupt level of a function execution is the same as the interrupt level of its calling source.

(2) If there is a spin lock on the call path, then the interrupt level will increase, and if there is a free spin lock on the call path, the interrupt level will decrease.

24, Kernel code main call the source of the run interrupt level

Call source	General run Interrupt level
Driverentry,driverunload	Passive class
Various distribution functions	Passive class
Completion function	Dispatch class
Various NDIS callback functions	Dispatch class

25, if the current code does run at the dispatch level, but must also call a kernel API that can only run at the passive level, any reduction of the interrupt level will result in unpredictable consequences for the system.

26. Pre-compiled instructions for specifying the location of the function:

#pragma alloc_text (INIT, DriverEntry)

#pragma alloc_text (PAGE, Ndisprotunload)

#pragma alloc_text (PAGE, Ndisprotunload)

#pragma alloc_text (PAGE, Ndisprotclose)

#pragma alloc_text This macro is used only to specify the location of the executable code of a function in the SYS file after it is compiled. After the kernel module is compiled is a PE-formatted SYS file, which has different sections (section) in the Code snippet (text field), and different sections are loaded into memory and processed differently. The main concern of the reader is the 3 sections, the Init section is characterized by being released after initialization, that is, the memory space is no longer occupied, page section is characterized by the memory space that can be paged out, these controls can be swapped to the hard disk to save memory when the memory is tight. If not processed with the precompiled directives above, the code is in the Pagelk section by default and is loaded in a non-paged swap memory space.

The function DriverEntry obviously only needs to be executed once during the initialization phase, so this function is generally used #pragma alloc_text (INIT, DriverEntry) to be in the space immediately after initialization. To save memory, you can put a lot of functions in the page section. Note, however, that a function placed in the page section cannot be called at the dispatch level, because a call to this function may induce a fault in the pages. However, the processing of the missing pages cannot be done at the dispatch level. For this purpose, a macro paged_code () is generally used for testing. If the current interrupt level is found to be dispatch, the program directly reports the exception so that the programmer can find it early.

#pragma alloc_text (PAGE, Sfattachtomounteddevice)

....

NTSTATUS

Sfattachtomounteddevice (

In Pdevice_object DeviceObject,

In Pdevice_object Sfilterdeviceobject

)

{

Psfilter_device_extension Newdevext =

sfilterdeviceobject->deviceextension;

NTSTATUS status;

ULONG i;

Paged_code ();

...

}

Cold River Single Fishing--windows Core Security Programming notes (i)