windows内核

Introduction to Registry Filtering in Vista(OSR)

垃圾一堆 — Thu, 19 Jun 2008 15:42:00 GMT

Guest Article - Introduction to Registry Filtering in Vista (Part I)
(By: The NT Insider, Vol 15, Issue 1, March- April 2008 | Published: 28-May-08| Modified: 28-May-08)

By Jerry Kelley

The Registry Filtering Model (RFM) provides the developer with a framework to develop registry filters quickly and safely. Before the RFM, filter developers had to resort to potentially unsafe hacks to hook the registry service calls. With the RFM, a skeleton filter can be assembled in short order by anyone with any familiarity of filtering. This is the first of two articles which will present a whirlwind tour of the RFM in Vista. In this article, I'll show you how to put together a simple filter from which you can build upon to add functionality to suit your needs.

What can it do for me?
Let's get started by going over what the RFM actually does for the developer. It provides a framework whereby a driver can be developed that provides callbacks for registry IO that it's interested in. These callbacks are registered with the RFM and are called whenever specific registry IO is processed. All of the RFM interfaces that the driver uses are provided by the Configuration Manager (CM). In addition to managing the callbacks, the RFM also provides for three types of contexts that a driver can use to associate private information with an object or operation. Those who know the file system Filter Manager should already be acquainted with these features. The Filter Manager does provide a broader API than the RFM but, to be fair, it's been out there longer and file system filters are among the hardest drivers to develop so a lot of effort has gone into the Filter Manager to ease their burden.

Not exactly the new kid in town
You may have noticed that the RFM has been around since XP. The API was very limited in XP and expanded in Server 2003. The biggest change in Server 2003 was that the RFM added support for pre and post operation callbacks meaning the driver gets a callback before and after the CM processes an operation. (In XP, only a single operation callback is available which just announces the IO). Vista added callbacks for key flush, load, and unload as well as key security query and set.

Altitude is everything
Registry filters are assigned altitudes by the type of application they perform. An altitude arranges the layering of filters so that no matter when they load, they'll load within a pre-determined level based on their function. The altitude categories are the same as those for the file system minifilters and vendors who already have altitudes for their minifilters will use them for their registry filters as well. Altitudes can be requested from Microsoft via the WHDC Minifilter Altitude Allocation Web site.

Callbacks, of course
Before we discuss registering with CM for callbacks, let's take a look at the format of the callback routines. All of the callbacks are of the PEX_CALLBACK_FUNCTION type definition in WDM.H. The three input values represent, respectively, the registration context, the operation type, and a pointer to the operation's information structure. The PEX_CALLBACK_FUNCTION is shown in Figure 1.

typedef NTSTATUS (*PEX_CALLBACK_FUNCTION)(

IN PVOID CallbackContext,

IN PVOID Argument1,

IN PVOID Argument2

);

Figure 1 - Callback Routine Template

The callback context is really a registration context created when a filter registers with CM (This will be discussed further when we talk about registration). When a filter registers at an altitude it can set a private context that the filter can use to identify a specific registration. Argument1 is not really a pointer but an enumeration value of the REG_NOTIFY_CLASS type. This value indicates the specific registry operation. Sample enumeration values include RegNtPreDeleteKey, RegNtPostDeleteKey, RegNtPreCreateKeyEx, and RegNtPostCreateKeyEx. Be sure to treat it as an enumeration and not a pointer since it'll never hold a valid pointer value.

Argument2 is a pointer to an operation-specific structure. There are distinct pre-op and post-op structures that your filter will have to deal with. The pre-op structure depends on the operation. As an example, consider pre-create (CreateKeyEx), Argument2 is a REG_CREATE_KEY_INFORMATION pointer (See Figure 2).

typedef struct _REG_CREATE_KEY_INFORMATION {

PUNICODE_STRING CompleteName;

PVOID RootObject;

PVOID ObjectType;

ULONG CreateOptions;

PUNICODE_STRING Class;

PVOID SecurityDescriptor;

PVOID SecurityQualityOfService;

ACCESS_MASK DesiredAccess;

ACCESS_MASK GrantedAccess;

PULONG Disposition;

PVOID *ResultObject;

PVOID CallContext;

PVOID Reserved;

} REG_CREATE_KEY_INFORMATION, REG_OPEN_KEY_INFORMATION,

*PREG_CREATE_KEY_INFORMATION, *PREG_OPEN_KEY_INFORMATION;

Figure 2 - REG_CREATE_KEY_INFORMATION Structure

In the pre-query key callback Argument2 provides a pointer to a REG_QUERY_KEY_INFORMATION structure (See Figure 3).

typedef struct _REG_QUERY_KEY_INFORMATION {

PVOID Object;

KEY_INFORMATION_CLASS KeyInformationClass;

PVOID KeyInformation;

ULONG Length;

PULONG ResultLength;

PVOID CallContext;

PVOID ObjectContext;

PVOID Reserved;

} REG_QUERY_KEY_INFORMATION, *PREG_QUERY_KEY_INFORMATION;

Figure 3 - REG_QUERY_KEY_INFORMATION Structure

You'll notice that REG_OPEN_KEY_INFORMATION is the same as REG_CREATE_KEY_INFORMATION. The pre-op structure for create-key and open-key are overloaded but the pre-op structures for the rest of the operations are not. These structures are defined in WDM.H and documented in the WDK documentation.

The pre-op structures all contain several common members that help the filter identify the target of the operation. Some contain only these values because nothing else is needed. Take delete-key for example. In Figure 4, the REG_DELETE_KEY _INFORMATION structure has only three members (ignoring Reserved) and this is all that's required to define the key to be deleted.

typedef struct _REG_DELETE_KEY_INFORMATION {

PVOID Object;

PVOID CallContext;

PVOID ObjectContext;

PVOID Reserved;

} REG_DELETE_KEY_INFORMATION, *PREG_DELETE_KEY_INFORMATION;

Figure 4 - REG_DELETE_KEY_INFORMATION Structure

The first three parameters are common to all pre-op structures except for create and open. To be exact, CallContext is used in all structures including create and open but Object does not exist until the create (or open) completes and ObjectContext is not valid unless it has been set on the registry object. Other pre-op structures may have more members but they all will have at least these three.

All post-op routines are passed a pointer to a REG_POST_OPERATION_INFORMATION structure providing common completion information regardless of the operation type. Figure 5 contains the definition of the REG_POST_OPERATION_INFORMATION structure.

typedef struct _REG_POST_OPERATION_INFORMATION {

PVOID Object;

NTSTATUS Status;

PVOID PreInformation;

NTSTATUS ReturnStatus;

PVOID CallContext;

PVOID ObjectContext;

PVOID Reserved;

} REG_POST_OPERATION_INFORMATION,*PREG_POST_OPERATION_INFORMATION;

Figure 5 - REG_POST_OPERATION_INFORMATION Structure

Notice the three primary fields discussed previously - Object, CallContext, and ObjectContext. These give us the registry object and context information we need to properly identify the operation target. The Status field is the actual status from CM for the operation while ReturnStatus is what will be returned to the caller. Because a filter may choose to return a status other than Status the ReturnStatus member is where the filter can set the status it wants returned to the caller. This is covered in the section on completion processing. The PreInformation member is a pointer to the pre-op structure and provides the post-op routine with the original values defining the operation.

There's one more callback to cover, the context cleanup callback. This callback must be provided if your filter sets contexts on registry objects. This callback is executed when a registry object's handle is closed or the filter unregisters. In the unregister case, the filter will get a callback for every outstanding registry context assignment. This callback is where the filter releases any registry context resources. It is a PEX_CALLBACK_FUNCTION just like the rest of the other callbacks.

Callback templates
The callbacks have been discussed as far as their function prototype and structures passed so now we'll look at a template for a pre-op callback and then a post-op callback. For these examples I'm using CreateKeyEx but the template applies to any operation. The pre-op template shown in Figure 6 breaks down to enclosing the buffer access in a try/except block, casting Argument2 to a REG_CREATE_KEY_INFORMATION pointer, processing it and returning.

NTSTATUS PreCreateKeyExCallback(

IN PVOID CallbackContext,

IN PVOID Argument1,

IN PVOID Argument2

)

{

__try

{

PREG_CREATE_KEY_INFORMATION pPreInfo =

(PREG_CREATE_KEY_INFORMATION)pInfo;

// perform pre-op processing

}

__except(EXCEPTION_EXECUTE_HANDLER)

{

NTSTATUS Status = GetExceptionCode();

// handle the exception as required

}

return STATUS_SUCCESS;

}

Figure 6 - Pre-Op Template

The post-op template in Figure 7 is similar to the pre-op template but adds an extra step where a pointer to the pre-op structure is extracted to a local as a shortcut. The processing is left to the filter implementation.

NTSTATUS PostCreateKeyExCallback(

IN PVOID CallbackContext,

IN PVOID Argument1,

IN PVOID Argument2

)

{

NTSTATUS Status = STATUS_SUCCESS;

__try

{

PREG_POST_OPERATION_INFORMATION pPostInfo =

(PREG_POST_OPERATION_INFORMATION)pInfo;

PREG_CREATE_KEY_INFORMATION pPreInfo =

(PREG_CREATE_KEY_INFORMATION)pPostInfo->PreInformation;

// perform post-op processing

}

__except(EXCEPTION_EXECUTE_HANDLER)

{

Status = GetExceptionCode();

// handle the exception as required

}

return STATUS_SUCCESS;

}

Figure 7 - Post-Op Template

The pre and post-op callbacks have to be careful when using the buffer pointer in Argument2 since this can be a user-space pointer. With that in mind, all access to the buffer must take place in a try/except block. The processing depends on the filter's application, so just remember to use the Argument2 pointer safely.

The power of the registry IO handler
Now that we've looked at the callback templates and the structures used, we can take that a step further and talk about what a registry filter can do - or to be more precise - what a registry IO handler can do. In this case, the term handler refers to the pre-op and post-op callback pair. A handler considers the pre and post routines as a unit which processes a single registry IO operation. With that model in mind, we can quickly describe the primary functions of a registry filter; monitoring, blocking, and modifying.

The monitoring filter is passive in that it does not interfere with any of the registry IO other than to "sniff" it and possibly record it for an application. This is a common use of registry filtering and is found in many applications. The blocking filter uses criteria to determine if registry IO should be allowed. In this type of filter, the pre-op routine does the vast majority of the work since the idea is to stop IO before it can be passed on to CM. The criteria could be user, process, operation type, and so on. The final type of filter considered is one that modifies operations. There can be modifications made to the target of the operation or to the data itself. A typical modification is to the target in order to redirect the operation somewhere else in the registry. Another example is modifying the data of a value to encrypt or decrypt it.

What the Ex?
CreateKeyEx (and OpenKey by reference) were used in previous examples and we are discussing the Vista RFM implementation but let's diverge just for a moment to see just how different the "Ex" versions are from their predecessors. The "Ex" versions appeared in Server 2003 and replaced the "non-Ex" versions in XP. These "Ex" versions live up to their name by adding a wealth of new parameters describing the create or open. We've seen the REG_CREATE_KEY_I NFORMATION structure already; now let's look back at the REG_PRE_CREATE_KEY_INFORMATION used by CreateKey in Figure 8.

typedef struct _REG_PRE_CREATE_KEY_INFORMATION {

PUNICODE_STRING CompleteName;

} REG_PRE_CREATE_KEY_INFORMATION, *PREG_PRE_CREATE_KEY_INFORMATION;

Figure 8 - REG_PRE_CREATE_KEY_INFORMATION Structure

It's quite a bit thinner than REG_CREATE_KEY_ INFORMATION and the same is true for the structure used by OpenKey when compared to OpenKeyEx. The other thing about these older routines is that they have their own post-op structures. Figure 9 shows the REG_POST_CREATE_KEY_ INFORMATION structure.

typedef struct _REG_POST_CREATE_KEY_INFORMATION {

PUNICODE_STRING CompleteName;

PVOID Object;

NTSTATUS Status;

} REG_POST_CREATE_KEY_INFORMATION, *PREG_POST_CREATE_KEY_INFORMATION;

Figure 9 - _POST_CREATE_KEY_INFORMATION Structure

Compare REG_POST_CREATE_KEY_INFORMATION with REG_POST_OPERATION_INFORMATION and you'll again see that the "Ex" API's provide much more information to the filter.

Be sure to get registered
Once your callbacks have been defined you're almost ready to register with CM to start receiving notifications. The registration routine takes a PEX_CALLBACK_ FUNCTION that it calls for all registry IO sent to your filter. This callback is the central point from which you'll pass on the calls to your IO callbacks which we have discussed so far. Using a single dispatch callback is relatively easy to implement. To begin with, define an array of PEX_CALLBACK_ FUNCTION entries that'll contain pointers to each operation callback you have implemented. The array definition is shown in Figure 10.

PEX_CALLBACK_FUNCTION g_pCallbackFcns[MaxRegNtNotifyClass];

Figure 10 - Defining the Callback Array

Initialize the array such that each callback pointer is located based on its REG_NOTIFY_CLASS enumeration value. Figure 11 shows the initialization for a filter that only monitors creates, opens, and deletes. Your filter can use whatever combination of operation monitoring it needs for your application.

memset(g_pCallbackFcns, 0, sizeof(g_pCallbackFcns));

g_pCallbackFcns[RegNtPreCreateKeyEx] = PreCreateKeyExCallback;

g_pCallbackFcns[RegNtPostCreateKeyEx] = PostCreateKeyExCallback;

g_pCallbackFcns[RegNtPreOpenKeyEx] = PreOpenKeyEx;

g_pCallbackFcns[RegNtPostOpenKeyEx] = PostOpenKeyEx;

g_pCallbackFcns[RegNtPreDeleteKey] = PreDeleteKeyCallback;

g_pCallbackFcns[RegNtPostDeleteKey] = PostDeleteKeyCallback;

Figure 11 - Initializing the Callback Array

With the array defined, the dispatch callback simply has to cast Argument1 to a USHORT and use it as an index into the array to obtain the callback pointer. Be sure to check for a NULL entry in the array before attempting to use the callback. Figure 12 shows how the dispatch callback could be implemented.

NTSTATUS DispatchCallback(

IN PVOID CallbackContext,

IN PVOID Argument1,

IN PVOID Argument2

)

{

USHORT Class = (USHORT)Argument1;

if (NULL == g_pCallbackFcns[Class])

{

return STATUS_SUCCESS;

}

return (*(g_pCallbackFcns[Class]))(CallbackContext, Argument1, Argument2);

}

Figure 12 - The Dispatch Callback Function

If you don't handle a specific type of IO (the array entry is NULL) you must return STATUS_SUCCESS. This is required because the operation must continue and should not be interrupted just because your filter doesn't care about a particular type of IO.

We're now ready to notify CM that we want to filter registry IO. You can register your filter whenever makes the most sense for your application. Many filters will register in DriverEntry while others will register later. When you register, it's for all registry IO since you provide a single callback to CM. Therefore, the callback array should have NULL entries for any IO class (operation) you don't care about. This is why the dispatch callback must check for NULL entries (besides being a prudent practice anyway).

In addition to a pointer to the dispatch callback, the registration API takes a string description of the altitude, a pointer to the filter's driver object, a pointer to a registration context for the filter, and a pointer to a variable to receive a special cookie identifying the registration. The string description of the altitude is simply a UNICODE_STRING of the altitude. The registration context is optional and opaque to CM. It is a means for the filter to associate information regarding a particular registration. This context is passed into each callback in the CallbackContext parameter. The cookie is a LARGE_INTEGER that is opaque to the filter and used by CM to identify a registration. It is required by certain CM routines and thus the filter must maintain this value. A typical usage of CmRegisterCallbackEx is shown in Figure 13.

RtlInitUnicodeString(&altitudeString, L"360055");

NTSTATUS Status = CmRegisterCallbackEx(

DispatchCallback,

(PCUNICODE_STRING)&altitudeString,

pDriver,

&g_RegistrationContext1,

&g_RegistrationContext1.Cookie,

Null

);

Figure 13 - Calling CmRegisterCallbackEx

A filter can register at more than one altitude provided it has been assigned multiple altitudes. It's up to the filter designer to determine how to differentiate IO at each altitude. You can still use the same dispatch callback and callback array but specify a different registration context for each altitude registered. When any of the callbacks are called, the altitude is determined by the callback using the registration context. Of course, a filter could define a separate dispatch callback and set of callbacks for each altitude but, depending on the application, this may result in a lot of duplicate code and more code to be debugged and maintained.

When the filter no longer needs to filter registry IO it must unregister with CM. This would typically be done in the driver's unload routine but depending on the functionality of the filter it could occur anywhere. A filter unregisters by calling CmUnRegisterCallback. This routine takes only the cookie that the filter received when it registered with CM. Continuing our example from Figure 13; Figure 14 depicts unregistering the same filter.

NTSTATUS Status = CmUnRegisterCallback(g_RegistrationContext1.Cookie)

Figure 14 - Calling CmUnRegisterCallback

As covered so far, there are several types of contexts available to a filter. Contexts allow a driver to associate private information with a distinct object or operation that is typically managed by another subsystem such as a service in the operating system. This means, for example, a driver can allocate and initialize a private blob of information that it attaches to an object, like a registry object in this case, and (nearly) every time the driver gets the object from operating system the context comes with it. So why is this useful? Well, those of us who developed file system filters prior to the Filter Manager can attest to the magnitude of overhead necessary to, say, track all open file and stream objects. Once we had context support it was so much easier to just allocate our private contexts and attach them to file system objects. Anytime we processed IO we just had to retrieve our contexts and we had the information that we used to have to track ourselves in trees or lists.

There are three types of contexts available to a registry filter:

Registration
Registry object
Registry operation

When we looked at registration earlier you'll recall we could pass a pointer to our initialized registration context. A filter uses this context to store per-registration information. This context is passed as the first parameter to every callback. This gives all callbacks access to the filter's private registration context to use as determined by the filter.

A registry filter can set a context on a registry object with a call to CmSetCallbackObjectContext (See Figure 15 for the prototype). This is very useful because registry objects are the central focus of registry IO (surprise) and with a context on each object the filter can easily track per-object information and status. For example, a registry object context could store the root and path, create/open options and the process and thread that created/opened it. The context is typically set in the create/open post-op if the create/open was successful. However, CmSetCallbackObjectContext can be called anytime from post-create (or post-open) to prior to the handle close pre-op to set the context. Once the context has been successfully set on the object, the filter will receive a RegNtCallbackObjectContextCleanup notification when the object's handle has been closed or the filter has unregistered. Therefore, if you're going to use object contexts you must register a context cleanup callback that releases your resources for the context.

NTSTATUS CmSetCallbackObjectContext(

IN OUT PVOID Object,

IN PLARGE_INTEGER Cookie,

IN PVOID NewContext,

OUT OPTIONAL PVOID *OldContext

);

Figure 15 - CmSetCallbackObjectContext Prototype

The filter can track the context but it is passed to every pre-op callback in the ObjectContext member of the REG_Xxx_KEY_INFORMATION structure. If a filter registers at more than one altitude, different contexts for the same registry object can be assigned for each registration by using the cookies to delineate the assignments. CmSetCallbackObjectContext also lets you replace a context on a registry object. If you call CmSetCallbackObjectContext and a context already exists, it will remove the old context, attach the new one, and return a pointer to the old one in OldContext. If OldContext comes back non-NULL the filter is responsible for cleaning it up.

The registry operation context covers the scope between the pre-op and the post-op callbacks. It is passed from the pre-op to the post-op of a single operation. It does not span across operations and is not propagated beyond the operation by CM. The filter uses this context to pass private information from a pre-op to a post-op routine. This means the filter will allocate a context in the pre-op and free it in the post-op. The context is set in the CallContext member of REG_Xxx_KEY_ INFORMATION in the pre-op and retrieved from the CallContext member of REG_POST_OPERATION_ INFORMATION in the post-op.

Modification of Registry IO Calls
We're almost done with this discussion of registry filters but we have an important subject left to cover: modifying registry IO calls. There are generally four distinct areas of modifications and they can be combined:

Input parameters
Output parameters
Return value
Completion processing

The filter's pre-op callback can modify input parameters in the REG_Xxx_KEY_INFORMATION structure and pass the new value(s) on. Likewise, the post-op callback can alter values in REG_POST_OPERATION_INFORMATION and return the modified information (Think of redirection as an example). In the case where the filter's post-op wants to change the return value to the caller, it sets the ReturnStatus member of REG_POST_OPERATION_INFORMATION with the status value that it wants the caller to receive and returns STATUS_CALLBACK_BYPASS. This halts further processing on the operation and immediately returns ReturnStatus to the caller. The caveat here is that the filter is responsible for cleanup of any CM objects if the status is changed from a success to a failure. If it is changed from failure to success the filter will need to provide proper parameter values in REG_POST_OPERATION_ INFORMATION. If the filter wants to fail the operation, it sets ReturnStatus to the error status to be returned to the caller and returns an error status other than STATUS_CALLBACK_BYPASS (STATUS_CALLBACK_ BYPASS is defined as an error value by the way).

A filter can handle the operation completely and bypass the intended operation path. To do this, the pre-op callback processes the operation however it wants and returns STATUS_CALLBACK_BYPASS. The post-op callback is not called in this case because CM will immediately return STATUS_SUCCESS to the caller without calling any other registry filters or CM routines beyond what is necessary to complete the operation. The filter must set the corresponding REG_Xxx_KEY_INFORMATION structure with proper parameters to be returned to the caller.

More to Come
This article has covered a lot of material in a relatively short amount of space. The WDK provides fairly good coverage of this information but there are some crucial elements left out - I know because I had to fill in a lot of these holes to get my first registry filter working. I have tried to provide enough coverage for a developer to become familiar with the concepts and components of a registry filter. The next article will cover transactions and how to build a non-durable resource manager since the RFM doesn?t provide one (Your filter will need one to support transactions and there is no known public documentation on how to build one).

Jerry Kelley is a file system filter driver developer working on software virtualization systems for a major security software corporation in the U.S. He has twenty-five years of development experience including embedded systems with the last nine years in filter development. He can be reached at jerryjkelley@msn.com.

线程调度的部分资料（乱）

垃圾一堆 — Thu, 23 Aug 2007 09:28:00 GMT

PART 1: Kernel Object

//每一位表示对应这个特权级的队列中是否有线程(主要在KiSwapThread用,详细代码见PART3)
ULONG KiReadySummary = 0

- Referenced by KeSetAffinityThread(),KiFindReadyThread(),KiReadyThread(),
KiScanReadyQueues(), KiSetPriorityThread(), and NtYieldExecution().

//
LIST_ENTRY KeBugCheckCallbackListHead

//
LIST_ENTRY KiDispatcherReadyListHead[MAXIMUM_PRIORITY]

- Referenced by KeSetAffinityThread(), KiFindReadyThread(), KiInitSystem(),
KiReadyThread(), KiScanReadyQueues(), KiSetPriorityThread(),
and NtYieldExecution().

//
LIST_ENTRY KiProfileListHead

- Referenced by KeStartProfile(), and KiInitSystem().

LIST_ENTRY KiProfileSourceListHead

- Referenced by KeStartProfile(), KeStopProfile(), and KiInitSystem().

//
LIST_ENTRY KiProcessOutSwapListHead

- Referenced by KeDetachProcess(), KeSwapProcessOrStack(), KeTerminateThread(),
KeUnstackDetachProcess(), KiInitSystem(), KiOutSwapKernelStacks(), and
KiOutSwapProcesses().

LIST_ENTRY KiProcessInSwapListHead

- Referenced by KeSwapProcessOrStack(), KiAttachProcess(), KiInitSystem(),
KiInSwapProcesses(), KiOutSwapProcesses(), and KiReadyThread().

LIST_ENTRY KiStackInSwapListHead

- Referenced by KeSwapProcessOrStack(), KiInitSystem(), KiInSwapKernelStacks(),
and KiReadyThread().

//
LIST_ENTRY KiTimerTableListHead[TIMER_TABLE_SIZE]

- Referenced by KeCheckForTimer(), KeSetSystemTime(), KiInitSystem(),
KiInsertTimerTable(), KiTimerExpiration(), and VerifierKeInitializeTimerEx().

//
LIST_ENTRY KiWaitInListHead

- Referenced by KiInitSystem(), and KiOutSwapKernelStacks().

LIST_ENTRY KiWaitOutListHead

- Referenced by KiInitSystem(), and KiOutSwapKernelStacks().

PART 2: Kernel Object of KPROCESS

LIST_ENTRY _KPROCESS::ThreadListHead

- Referenced by ExpGetProcessInformation(), KeDetachProcess(), KeFreezeAllThreads(),
KeTerminateThread(), KeThawAllThreads(), and KeUnstackDetachProcess().

LIST_ENTRY _KPROCESS::SwapListEntry

- Referenced by KeDetachProcess(), KeTerminateThread(), KeUnstackDetachProcess(),
KiOutSwapKernelStacks(), KiOutSwapProcesses(), and KiReadyThread().

LIST_ENTRY _KPROCESS::ReadyListHead

- Referenced by KiInSwapProcesses(), KiOutSwapProcesses(), and KiReadyThread().

PART 3:

/*------------------------- MmInitSystem -------------------------

- MmInitSystem启动两个线程: KeBalanceSetManager 和 KeSwapProcessOrStack;

- 平衡集管理器(balance set manager)

- 交换管理器(KeSwapProcessOrStack)

- 其实它还启动了MiModifiedPageWriter(将某些页面置入pagefile中)

-----------------------------------------------------------------*/
01337         //
01338         // Start the modified page writer.
01339         //
01340
01341         InitializeObjectAttributes( &ObjectAttributes, NULL, 0, NULL, NULL );
01342
01343         if (!NT_SUCCESS(PsCreateSystemThread(
01344                         &ThreadHandle,
01345                         THREAD_ALL_ACCESS,
01346                         &ObjectAttributes,
01347                         0L,
01348                         NULL,
01349                         MiModifiedPageWriter,
01350                         NULL
01351                         ))) {
01352             return FALSE;
01353         }
01354         ZwClose (ThreadHandle);
01355
01356         //
01357         // Start the balance set manager.
01358         //
01359         // The balance set manager performs stack swapping and working
01360         // set management and requires two threads.
01361         //
01362
01363         KeInitializeEvent (&MmWorkingSetManagerEvent,
01364                            SynchronizationEvent,
01365                            FALSE);
01366
01367         InitializeObjectAttributes( &ObjectAttributes, NULL, 0, NULL, NULL );
01368
01369         if (!NT_SUCCESS(PsCreateSystemThread(
01370                         &ThreadHandle,
01371                         THREAD_ALL_ACCESS,
01372                         &ObjectAttributes,
01373                         0L,
01374                         NULL,
01375                         KeBalanceSetManager,
01376                         NULL
01377                         ))) {
01378
01379             return FALSE;
01380         }
01381         ZwClose (ThreadHandle);
01382
01383         if (!NT_SUCCESS(PsCreateSystemThread(
01384                         &ThreadHandle,
01385                         THREAD_ALL_ACCESS,
01386                         &ObjectAttributes,
01387                         0L,
01388                         NULL,
01389                         KeSwapProcessOrStack,
01390                         NULL
01391                         ))) {
01392
01393             return FALSE;
01394         }

/*---------------------- KeBalanceSetManager ---------------------

- KeBalanceSetManager也一直循环着并等待着一个MmWorkingSetManagerEvent事件
(当内存低时调整工作集的大小)和另一个定时器.

- 定时器事件处理程序周期性地将KiStackOutSwapRequest设置为TRUE，
并且触发KiSwapEvent信号通知KeSwapProcessOrStack线程, KeSwapProcessOrStack线程
不得不将长时间等待某个东西的线程的内核堆栈交换出去.

- KeBalanceSetManager也调用KiScanReadyQueues
来提高在就绪队列中线程(KiDispatcherReadyListHead数组)的优先级.

- 对于每一个提高了优先级的线程, KiReadyThread将会被调用,
所以马上将PRCB.NextThread设置为提高了优先级的线程也是很有可能的
(KiReadyThread 会抢占原先的NextThread).

-----------------------------------------------------------------*/

00141 VOID
00142 KeBalanceSetManager (
00143     IN PVOID Context
00144     )
00145
00146 /*++
00147
00148 Routine Description:
00149
00150     This function is the startup code for the balance set manager. The
00151     balance set manager thread is created during system initialization
00152     and begins execution in this function.
00153
00154 Arguments:
00155
00156     Context - Supplies a pointer to an arbitrary data structure (NULL).
00157
00158 Return Value:
00159
00160     None.
00161
00162 --*/
00163
00164 {
00165
00166     LARGE_INTEGER DueTime;
00167     KTIMER PeriodTimer;
00168     KIRQL OldIrql;
00169     ULONG StackScanPeriod;
00170     ULONG ExecutionTimeLimitPeriod;
00171     NTSTATUS Status;
00172     KWAIT_BLOCK WaitBlockArray[MaximumObject];
00173     PVOID WaitObjects[MaximumObject];
00174
00175     //
00176     // Raise the thread priority to the lowest realtime level.
00177     //
00178
00179     KeSetPriorityThread(KeGetCurrentThread(), LOW_REALTIME_PRIORITY);
00180
00181     //
00182     // Initialize the periodic timer, set it to expire one period from
00183     // now, and set the stack scan period.
00184     //
00185
00186     KeInitializeTimer(&PeriodTimer);
00187     DueTime.QuadPart = - PERIODIC_INTERVAL;
00188     KeSetTimer(&PeriodTimer, DueTime, NULL);
00189     StackScanPeriod = STACK_SCAN_PERIOD;
00190     ExecutionTimeLimitPeriod = EXECUTION_TIME_LIMITS_PERIOD;
00191     //
00192     // Compute the stack protect time based on the system size.
00193     //
00194
00195     if (MmQuerySystemSize() == MmSmallSystem) {
00196         KiStackProtectTime = SMALL_SYSTEM_STACK_PROTECT_TIME;
00197
00198     } else {
00199         KiStackProtectTime = STACK_PROTECT_TIME;
00200     }
00201
00202     //
00203     // Initialize the wait objects array.
00204     //
00205
00206     WaitObjects[TimerExpiration] = (PVOID)&PeriodTimer;
00207     WaitObjects[WorkingSetManagerEvent] = (PVOID)&MmWorkingSetManagerEvent;
00208
00209     //
00210     // Loop forever processing balance set manager events.
00211     //
00212
00213     do {
00214
00215         //
00216         // Wait for a memory management memory low event, a swap event,
00217         // or the expiration of the period timout rate that the balance
00218         // set manager runs at.
00219         //
00220
00221         Status = KeWaitForMultipleObjects(MaximumObject,
00222                                           &WaitObjects[0],
00223                                           WaitAny,
00224                                           Executive,
00225                                           KernelMode,
00226                                           FALSE,
00227                                           NULL,
00228                                           &WaitBlockArray[0]);
00229
00230         //
00231         // Switch on the wait status.
00232         //
00233
00234         switch (Status) {
00235
00236             //
00237             // Periodic timer expiration.
00238             //
00239
00240         case TimerExpiration:
00241
00242             //
00243             // Attempt to initiate outswaping of kernel stacks.
00244             //
00245
00246             StackScanPeriod -= 1;
00247             if (StackScanPeriod == 0) {
00248                 StackScanPeriod = STACK_SCAN_PERIOD;
00249                 KiLockDispatcherDatabase(&OldIrql);
00250                 if (KiStackOutSwapRequest == FALSE) {
00251                     KiStackOutSwapRequest = TRUE;
00252                     KiUnlockDispatcherDatabase(OldIrql);
00253                     KeSetEvent(&KiSwapEvent, 0, FALSE);
00254
00255                 } else {
00256                     KiUnlockDispatcherDatabase(OldIrql);
00257                 }
00258             }
00259
00260             //
00261             // Adjust the depth of lookaside lists.
00262             //
00263
00264             ExAdjustLookasideDepth();
00265
00266             //
00267             // Scan ready queues and boost thread priorities as appropriate.
00268             //
00269
00270             KiScanReadyQueues();
00271
00272             //
00273             // Execute the virtual memory working set manager.
00274             //
00275
00276             MmWorkingSetManager();
00277
00278             //
00279             // Enforce execution time limits
00280             //
00281
00282             ExecutionTimeLimitPeriod -= 1;
00283             if (ExecutionTimeLimitPeriod == 0) {
00284                 ExecutionTimeLimitPeriod = EXECUTION_TIME_LIMITS_PERIOD;
00285                 PsEnforceExecutionTimeLimits();
00286                 }
00287
00288             //
00289             // Set the timer to expire at the next periodic interval.
00290             //
00291
00292             KeSetTimer(&PeriodTimer, DueTime, NULL);
00293             break;
00294
00295             //
00296             // Working set manager event.
00297             //
00298
00299         case WorkingSetManagerEvent:
00300
00301             //
00302             // Call the working set manager to trim working sets.
00303             //
00304
00305             MmWorkingSetManager();
00306             break;
00307
00308             //
00309             // Illegal return status.
00310             //
00311
00312         default:
00313             KdPrint(("BALMGR: Illegal wait status, %lx =\n", Status));
00314             break;
00315         }
00316
00317     } while (TRUE);
00318     return;
00319 }

/*---------------------- KeSwapProcessOrStack ---------------------

- 将内核堆栈交换出去(由BOOLEAN KiStackOutSwapRequest指定)
- 将进程交换出去 (需要交换出去的进程存放在KiProcessOutSwapListHead中）
- 将进程交换进来 (需要交换出去的进程存放在KiProcessInSwapListHead中）
- 将内核堆栈交换进来(需要交换进来的线程存放在KiStackInSwapListHead中).

-----------------------------------------------------------------*/

00321 VOID
00322 KeSwapProcessOrStack (
00323     IN PVOID Context
00324     )
00325
00326 /*++
00327
00328 Routine Description:
00329
00330     This thread controls the swapping of processes and kernel stacks. The
00331     order of evaluation is:
00332
00333         Outswap kernel stacks
00334         Outswap processes
00335         Inswap processes
00336         Inswap kernel stacks
00337
00338 Arguments:
00339
00340     Context - Supplies a pointer to the routine context - not used.
00341
00342 Return Value:
00343
00344     None.
00345
00346 --*/
00347
00348 {
00349
00350     KIRQL OldIrql;
00351     NTSTATUS Status;
00352
00353     //
00354     // Raise the thread priority to the lowest realtime level + 7 (i.e.,
00355     // priority 23).
00356     //
00357
00358     KeSetPriorityThread(KeGetCurrentThread(), LOW_REALTIME_PRIORITY + 7);
00359
00360     //
00361     // Loop for ever processing swap events.
00362     //
00363
00364     do {
00365
00366         //
00367         // Wait for a swap event to occur.
00368         //
00369
00370         Status = KeWaitForSingleObject(&KiSwapEvent,
00371                                        Executive,
00372                                        KernelMode,
00373                                        FALSE,
00374                                        NULL);
00375
00376         //
00377         // Raise IRQL to dispatcher level and lock dispatcher database.
00378         //
00379
00380         KiLockDispatcherDatabase(&OldIrql);
00381
00382         //
00383         // Loop until all of the four possible actions cannot be initiated.
00384         //
00385
00386         do {
00387
00388             //
00389             // If a request has been made to out swap kernel stacks, then
00390             // attempt to outswap kernel stacks. Otherwise, if the process
00391             // out swap list is not empty, then initiate process outswapping.
00392             // Otherwise, if the process inswap list is not empty, then start
00393             // process inswapping. Otherwise, if the kernal stack inswap list
00394             // is not active, then initiate kernel stack inswapping. Otherwise,
00395             // no work is available.
00396             //
00397
00398             if (KiStackOutSwapRequest != FALSE) {
00399                 KiStackOutSwapRequest = FALSE;
00400                 KiOutSwapKernelStacks(OldIrql);
00401                 continue;
00402
00403             } else if (IsListEmpty(&KiProcessOutSwapListHead) == FALSE) {
00404                 KiOutSwapProcesses(OldIrql);
00405                 continue;
00406
00407             } else if (IsListEmpty(&KiProcessInSwapListHead) == FALSE) {
00408                 KiInSwapProcesses(OldIrql);
00409                 continue;
00410
00411             } else if (IsListEmpty(&KiStackInSwapListHead) == FALSE) {
00412                 KiInSwapKernelStacks(OldIrql);
00413                 continue;
00414
00415             } else {
00416                 break;
00417             }
00418         } while (TRUE);
00419
00420         //
00421         // Unlock the dispatcher database and lower IRQL to its previous
00422         // value.
00423         //
00424
00425         KiUnlockDispatcherDatabase(OldIrql);
00426     } while (TRUE);
00427     return;
00428 }

/*------------------------ KiSwapThread -------------------------

-----------------------------------------------------------------*/
;++
;
; VOID
; KiSwapThread (
;    VOID
;    )
;
; Routine Description:
;
;    This routine is called to select the next thread to run on the
;    current processor and to perform a context switch to the thread.
;
; Arguments:
;
;    None.
;
; Return Value:
;
;    Wait completion status (eax).
;
;--

cPublicFastCall KiSwapThread, 0
.fpo (0, 0, 0, 4, 1, 0)

;
; N.B. The following registers MUST be saved such that ebp is saved last.
; This is done so the debugger can find the saved ebp for a thread
; that is not currently in the running state.
;

        sub     esp, 4*4
        mov     [esp+12], ebx           ; save registers
        mov     [esp+8], esi            ;
        mov     [esp+4], edi            ;
        mov     [esp+0], ebp            ;

        mov     ebx, PCR[PcSelfPcr]     ; get address of PCR
        mov     edx, [ebx].PcPrcbData.PbNextThread ; get next thread address
        or      edx, edx                ; check if next thread selected
        jnz     Swt140                  ; if nz, next thread selected

;
; Find the highest nibble in the ready summary that contains a set bit
; and left justify so the nibble is in bits <31:28>
;

        mov     ecx, 16                 ; set base bit number
        mov     edi, _KiReadySummary    ; get ready summary
        mov     esi, edi                ; copy ready summary
        shr     esi, 16                 ; isolate bits <31:16> of summary
        jnz     short Swt10             ; if nz, bits <31:16> are nonzero
        xor     ecx, ecx                ; set base bit number
        mov     esi, edi                ; set bits <15:0> of summary
Swt10: shr     esi, 8                  ; isolate bits <15:8> of low bits
        jz      short Swt20             ; if z, bits <15:8> are zero
        add     ecx, 8                  ; add offset to nonzero byte
Swt20: mov     esi, edi                ; isolate highest nonzero byte
        shr     esi, cl                 ;
        add     ecx, 3                  ; adjust to high bit of nibble
        cmp     esi, 10h                ; check if high nibble nonzero
        jb      short Swt30             ; if b, then high nibble is zero
        add     ecx, 4                  ; compute ready queue priority
Swt30: mov     esi, ecx                ; left justify ready summary nibble
        not     ecx                     ;
        shl     edi, cl                 ;
        or      edi, edi                ;

;
; If the next bit is set in the ready summary, then scan the corresponding
; dispatcher ready queue.
;

Swt40: js      short Swt60             ; if s, queue contains an entry
Swt50: sub     esi, 1                  ; decrement ready queue priority
        shl     edi, 1                  ; position next ready summary bit
        jnz     short Swt40             ; if nz, more queues to scan

;
; If the next bit is set in the ready summary, then scan the corresponding
; dispatcher ready queue.
;

PE加载器的实现

垃圾一堆 — Mon, 30 Jul 2007 02:36:00 GMT

对于加壳软件的开发者,掌握PE Loader的实现是最基本的技术;因为壳运行结束后,你要仿照PE加载器去Load映象体,我曾看过UPX的开源代码,全手工打造PE,实现的也是极其复杂,是学习加壳,脱壳和开发加壳软件的上乘资料.

在ReatOs和Nt4.0上找到了其实现,前者实现的比较清晰,不过还是看看Nt4.0的实现吧

//KiThreadStartup->向Kernel APC插入LdrInitializeThunk->向User APC插入
//LdrInitializeThunk;详请参见PspCreateThread的实现
//
//注:Kernel APC与User APC的区别:
//           1)前者是在APC_LEVEL上运行,后者是在PASSIVE_LEVEL上运行
//           2)只有KTHREAD中的AlertAble或KTHREAD-ApcState-UserApcPending
//               为1的情况下,User APC中的Routine才会被执行
//
//ring0下启动ring3下的程序就是通过kernel下操作User APC实现的(向Explorer.exe中插入一个User APC)
//详请参考: http://www.codeproject.com/useritems/KernelExec.asp

//扯远了,还是来看看LdrInitializeThunk和LdrInitialize的实现吧
;++
;
; VOID
; LdrInitializeThunk(
;    IN PVOID NormalContext,
;    IN PVOID SystemArgument1,
;    IN PVOID SystemArgument2
;    )
;
; Routine Description:
;
;    This function computes a pointer to the context record on the stack
;    and jumps to the LdrpInitialize function with that pointer as its
;    parameter.
;
; Arguments:
;
;    NormalContext - User Mode APC context parameter (ignored).
;
;    SystemArgument1 - User Mode APC system argument 1 (ignored).
;
;    SystemArgument2 - User Mode APC system argument 2 (ignored).
;
; Return Value:
;
;    None.
;
;--

cPublicProc _LdrInitializeThunk , 4

NormalContext equ [esp + 4]
SystemArgument1 equ [esp + 8]
SystemArgument2 equ [esp + 12]
Context equ [esp + 16]

        lea     eax,Context             ; Calculate address of context record
        mov     NormalContext,eax       ; Pass as first parameter to
if DEVL
        xor     ebp,ebp                 ; Mark end of frame pointer list
endif
IFDEF STD_CALL
        jmp     _LdrpInitialize@12      ; LdrpInitialize
ELSE
        jmp     _LdrpInitialize         ; LdrpInitialize
ENDIF

stdENDP _LdrInitializeThunk

_TEXT   ends
        end

VOID
LdrpInitialize (
    IN PCONTEXT Context,
    IN PVOID SystemArgument1,
    IN PVOID SystemArgument2
    )

/*++

Routine Description:

    This function is called as a User-Mode APC routine as the first
    user-mode code executed by a new thread. It's function is to initialize
    loader context, perform module initialization callouts...

Arguments:

    Context - Supplies an optional context buffer that will be restore
              after all DLL initialization has been completed. If this
              parameter is NULL then this is a dynamic snap of this module.
              Otherwise this is a static snap prior to the user process
              gaining control.

SystemArgument1 - Supplies the base address of the System Dll.

SystemArgument2 - not used.

Return Value:

None.

--*/

{
    NTSTATUS st, InitStatus;
    PPEB Peb;
    PTEB Teb;
    UNICODE_STRING UnicodeImageName;
    MEMORY_BASIC_INFORMATION MemInfo;
    BOOLEAN AlreadyFailed;
    LARGE_INTEGER DelayValue;

SystemArgument2;

    AlreadyFailed = FALSE;
    Peb = NtCurrentPeb();
    Teb = NtCurrentTeb();

    if (!Peb->Ldr) {
#if defined(MIPS) || defined(_ALPHA_)
        ULONG temp;
#if defined(MIPS)
        Peb->ProcessStarterHelper = (PVOID)LdrProcessStarterHelper;
#endif
        //
        // Set GP register
        //
        LdrpGpValue =(ULONG)RtlImageDirectoryEntryToData(
                Peb->ImageBaseAddress,
                TRUE,
                IMAGE_DIRECTORY_ENTRY_GLOBALPTR,
                &temp
                );
        if (Context != NULL) {
            LdrpSetGp( LdrpGpValue );
#if defined(_MIPS_)
            Context->XIntGp = (LONG)LdrpGpValue;
#else
            Context->IntGp = LdrpGpValue;
#endif
        }
#endif // MIPS || ALPHA

        NtGlobalFlag = Peb->NtGlobalFlag;
#if DBG
        if (TRUE)
#else
        if (Peb->BeingDebugged || Peb->ReadImageFileExecOptions)
#endif
        {
            PWSTR pw;

            pw = (PWSTR)Peb->ProcessParameters->ImagePathName.Buffer;
            if (!(Peb->ProcessParameters->Flags & RTL_USER_PROC_PARAMS_NORMALIZED)) {
                pw = (PWSTR)((PCHAR)pw + (ULONG)(Peb->ProcessParameters));
                }
            UnicodeImageName.Buffer = pw;
            UnicodeImageName.Length = Peb->ProcessParameters->ImagePathName.Length;
            UnicodeImageName.MaximumLength = UnicodeImageName.Length;

            st = LdrQueryImageFileExecutionOptions( &UnicodeImageName,
                                                    L"GlobalFlag",
                                                    REG_DWORD,
                                                    &NtGlobalFlag,
                                                    sizeof( NtGlobalFlag ),
                                                    NULL
                                                  );
            if (!NT_SUCCESS( st )) {
                UnicodeImageName.Length = 0;

                if (Peb->BeingDebugged) {
                    NtGlobalFlag |= FLG_HEAP_ENABLE_FREE_CHECK |
                                    FLG_HEAP_ENABLE_TAIL_CHECK |
                                    FLG_HEAP_VALIDATE_PARAMETERS;
                    }
                }
        }

#if DBG && FLG_HEAP_PAGE_ALLOCS

if ( NtGlobalFlag & FLG_HEAP_PAGE_ALLOCS ) {

            //
            // Turn on BOOLEAN RtlpDebugPageHeap to indicate that
            // new heaps should be created with debug page heap manager
            // when possible. Also force off other heap debug flags
            // that can cause conflicts with the debug page heap
            // manager.
            //

RtlpDebugPageHeap = TRUE;

            NtGlobalFlag &= ~( FLG_HEAP_ENABLE_TAGGING |
                               FLG_HEAP_ENABLE_TAG_BY_DLL
                             );

}

#endif // DBG && FLG_HEAP_PAGE_ALLOCS

    }
#if defined(MIPS) || defined(_ALPHA_)
    else
    if (Context != NULL) {
        LdrpSetGp( LdrpGpValue );
#if defined(_MIPS_)
        Context->XIntGp = (LONG)LdrpGpValue;
#else
        Context->IntGp = LdrpGpValue;
#endif
    }
#endif // MIPS || ALPHA

ShowSnaps = (BOOLEAN)(FLG_SHOW_LDR_SNAPS & NtGlobalFlag);

    //
    // Serialize for here on out
    //

    Peb->LoaderLock = (PVOID)&LoaderLock;
    if ( !RtlTryEnterCriticalSection(&LoaderLock) ) {
        if ( LoaderLockInitialized ) {
            RtlEnterCriticalSection(&LoaderLock);
            }
        else {

            //
            // drop into a 30ms delay loop
            //

            DelayValue.QuadPart = Int32x32To64( 30, -10000 );
            while ( !LoaderLockInitialized ) {
                NtDelayExecution(FALSE,&DelayValue);
                }
            RtlEnterCriticalSection(&LoaderLock);
            }
        }

    if (Teb->DeallocationStack == NULL) {
        st = NtQueryVirtualMemory(
                NtCurrentProcess(),
                Teb->NtTib.StackLimit,
                MemoryBasicInformation,
                (PVOID)&MemInfo,
                sizeof(MemInfo),
                NULL
                );
        if ( !NT_SUCCESS(st) ) {
            LdrpInitializationFailure(st);
            RtlRaiseStatus(st);
            return;
            }
        else {
            Teb->DeallocationStack = MemInfo.AllocationBase;
        }
    }

    InitStatus = STATUS_SUCCESS;
    try {
        if (!Peb->Ldr) {
            LdrpInLdrInit = TRUE;
#if DBG
            //
            // Time the load.
            //

            if (LdrpDisplayLoadTime) {
                NtQueryPerformanceCounter(&BeginTime, NULL);
            }
#endif // DBG

            try {
                //
                //This function initializes the loader for the process.
                //This includes:

// - Initializing the loader data table

// - Connecting to the loader subsystem

                //    - Initializing all staticly linked DLLs

                InitStatus = LdrpInitializeProcess( Context,
                                                    SystemArgument1,
                                                    UnicodeImageName.Length ? &UnicodeImageName : NULL
                                                  );
                }
            except ( EXCEPTION_EXECUTE_HANDLER ) {
                InitStatus = GetExceptionCode();
                AlreadyFailed = TRUE;
                LdrpInitializationFailure(GetExceptionCode());
                }
#if DBG
            if (LdrpDisplayLoadTime) {
                NtQueryPerformanceCounter(&EndTime, NULL);
                NtQueryPerformanceCounter(&ElapsedTime, &Interval);
                ElapsedTime.QuadPart = EndTime.QuadPart - BeginTime.QuadPart;
                DbgPrint("\nLoadTime %ld In units of %ld cycles/second \n",
                    ElapsedTime.LowPart,
                    Interval.LowPart
                    );

                ElapsedTime.QuadPart = EndTime.QuadPart - InitbTime.QuadPart;
                DbgPrint("InitTime %ld\n",
                    ElapsedTime.LowPart
                    );
                DbgPrint("Compares %d Bypasses %d Normal Snaps %d\nSecOpens %d SecCreates %d Maps %d Relocates %d\n",
                    LdrpCompareCount,
                    LdrpSnapBypass,
                    LdrpNormalSnap,
                    LdrpSectionOpens,
                    LdrpSectionCreates,
                    LdrpSectionMaps,
                    LdrpSectionRelocates
                    );
            }
#endif // DBG

            if (!NT_SUCCESS(InitStatus)) {
#if DBG
                DbgPrint("LDR: LdrpInitializeProcess failed - %X\n", InitStatus);
#endif // DBG
            }

        } else {
            if ( Peb->InheritedAddressSpace ) {
                InitStatus = LdrpForkProcess();
                }
            else {

#if defined (WX86)
                if (Teb->Vdm) {
                    InitStatus = LdrpInitWx86(Teb->Vdm, Context, TRUE);
                    }
#endif

                 //    This function is called by a thread that is terminating cleanly.
                 //It's purpose is to call all of the processes DLLs to notify them
                 //that the thread is detaching.

                LdrpInitializeThread();
                }
        }
    } finally {
        LdrpInLdrInit = FALSE;
        RtlLeaveCriticalSection(&LoaderLock);
        }

NtTestAlert();

if (!NT_SUCCESS(InitStatus)) {

        if ( AlreadyFailed == FALSE ) {
            LdrpInitializationFailure(InitStatus);
            }
        RtlRaiseStatus(InitStatus);
    }

}

详细实现参见:
nt4\private\ntos\dll\ldrinit.c
nt4\private\ntos\dll\ldrapi.c
nt4\private\ntos\dll\ldrsnap.c

reatos实现参见:
ReactOS030\dll\ntdll\ldr\startup.c
ReactOS030\dll\ntdll\ldr\utils.c
ReactOS030\dll\ntdll\ldr\elf.c

Ring0Prolog

垃圾一堆 — Mon, 07 May 2007 08:37:00 GMT

1 Undocumented Windows NT中通过callgate实现的无驱动进如ring0的代码中的两个宏汇编代码
直接仿制于NT系统代码（_KiSystemService），随NT版本而变。

Ring0Prolog macro
PUSHAD
PUSHFD
PUSH FS

;FS:0即指向FFDFF000h这个重要结构，用户态与核心态的FS值不同，下面是例行公事而已
MOV     EBX,00000030h
MOV     FS,BX
SUB     ESP, 50h
MOV     EBP,ESP

;Setup the exception frame to NULL
MOV     EBX,DWORD PTR CS:[0FFDFF000h]
MOV     DWORD PTR DS:[0FFDFF000h], 0FFFFFFFFh
MOV     DWORD PTR [EBP],EBX

;CS:[FFDFF124h]存有大家再熟悉不过的线程核心块KTHREAD，其中偏移128h处为TrapFrame
;Save away the existing KSS EBP
MOV     ESI, DWORD PTR CS:[0FFDFF124h]
MOV     EBX,DWORD PTR [ESI+00000128h]
MOV     DWORD PTR [EBP+4h],EBX
MOV     DWORD PTR [ESI+00000128h],EBP

;块偏移137h处为PreviousMode，简单说供核心函数区分是用户态还是核心态请求，直接决定了某些函数调
;用的成功与否。137与上面的128都是nt上的偏移，2000/XP下是不同的，所以这段代码平台相关
;Save away the kernel time and the thread mode (kernel/user)
MOV EDI,DWORD PTR [ESI+00000137h]
MOV DWORD PTR [EBP+8h],EDI

;Set the thread mode (kernel/user) based on the code selector
MOV     EBX,DWORD PTR [EBP+7Ch]
AND     EBX,01
MOV     BYTE PTR [ESI+00000137h],BL

STI
endm

Ring0Epilog macro
;Restore the KSS EBP
MOV     ESI,DWORD PTR CS:[0FFDFF124h]
MOV     EBX,DWORD PTR [EBP+4]
MOV     DWORD PTR [ESI+00000128h],EBX

;Restore the exception frame
MOV EBX,DWORD PTR [EBP]
MOV DWORD PTR FS:[00000000],EBX

;Restore the thread mode
MOV     EBX,DWORD PTR [EBP+8h]
MOV     ESI,DWORD PTR FS:[00000124h]
MOV     BYTE PTR [ESI+00000137h],BL
ADD     ESP, 50h
POP     FS
POPFD
POPAD
endm

EPROCESS的开头部分就是KPROCESS，名字上的所区别可以表明二者的主要定义与使用者的不同：K***意为微内核使用（kernel），在调度等代码使用，所需结构简单，只要一部分；E***意为执行体使用，需要额外的部分，比如活动进程链供任务枚举。KTHREAD、ETHREAD类似。至于ETHREAD、EPROCESS的联系有结构定义很容易看到，还有TEB/PEB，ETHREAD/EPROCESS等。

2 关于nt内存管理
//PDE-PTE(和硬件页表项的格式相同)，页目录的自映射问题告诉我们PDE与PTE的格式相同！
ULONG LinearAddressToPhysicalAddress(ULONG lAddress)
{
unsigned int *pAddr;
unsigned int *PageDirectoryEntry=(unsigned int *)0xC0300000;
unsigned int *PageTableEntry=(unsigned int *)0xC0000000;

if((!(PageDirectoryEntry[lAddress>>22]&0xFFFFF000))
  &&(!(PageDirectoryEntry[lAddress>>22]&0x00000001)))
  return 0;

pAddr=(unsigned int *)((int)PageTableEntry+((lAddress&0xFFFFF000)>>10));
if((*pAddr)&1)
  return ((*pAddr) &0xFFFFF000) |(lAddress&0x00000FFF);
return 0;
}

3 \Device\PhysicalMemory对象

\Device\PhysicalMemory对象有下面的权限：
user SYSTEM: Delete, Change Permissions, Change Owner, Query Data,
             Query State, Modify State
user Administrator: Query Data, Query State
详见：http://www.xfocus.net/articles/200208/430.html

在壳中没导出而在原始文件导出的函数，是否可以调用？

垃圾一堆 — Fri, 27 Apr 2007 04:57:00 GMT

题目太罗嗦，不知所云！我先解释一下
<一dll导出一个函数Add,用加壳工具对它进行加壳，加壳时让此加壳工具把原来的导出表hide，现一exe想动态调用加过壳的dll中的Add函数，可以吗？>

动态连接函数的方法： LoadLibrary，GetProcAddress，壳在我们LoadLibrary返回时就把原始文件Fix好在内存中了!
cmpb [esp + 8], 1//是DLL_PROCESS_ATTACH才Fix
jnz reloc_end_jmp
那GetProcAddress可以找到在壳中没导出而在原始文件导出的函数吗？
(Add函数在原始文件中导出了，但加过壳后就被hide了)
代码伺候：(reactos的代码)

GetProcAddress( HMODULE hModule, LPCSTR lpProcName )
{
ANSI_STRING ProcedureName;
FARPROC fnExp = NULL;

if (HIWORD(lpProcName) != 0)
{
  RtlInitAnsiString (&ProcedureName,
                     (LPSTR)lpProcName);
  LdrGetProcedureAddress ((PVOID)hModule,
                          &ProcedureName,
                          0,
                          (PVOID*)&fnExp);
}
else
{
  LdrGetProcedureAddress ((PVOID)hModule,
                          NULL,
                          (ULONG)lpProcName,
                          (PVOID*)&fnExp);
}

return fnExp;
}

NTSTATUS NTAPI
LdrGetProcedureAddress (IN PVOID BaseAddress,
                        IN PANSI_STRING Name,
                        IN ULONG Ordinal,
                        OUT PVOID *ProcedureAddress)
{
   if (Name && Name->Length)
     {
       TRACE_LDR("LdrGetProcedureAddress by NAME - %Z\n", Name);
     }
   else
     {
       TRACE_LDR("LdrGetProcedureAddress by ORDINAL - %d\n", Ordinal);
     }

DPRINT("LdrGetProcedureAddress (BaseAddress %p Name %Z Ordinal %lu ProcedureAddress %p)\n",
BaseAddress, Name, Ordinal, ProcedureAddress);

   if (Name && Name->Length)
     {
       /* by name */
       *ProcedureAddress = LdrGetExportByName(BaseAddress, (PUCHAR)Name->Buffer, 0xffff);
       if (*ProcedureAddress != NULL)
         {
           return STATUS_SUCCESS;
         }
       DPRINT("LdrGetProcedureAddress: Can't resolve symbol '%Z'\n", Name);
     }
   else
     {
       /* by ordinal */
       Ordinal &= 0x0000FFFF;
       *ProcedureAddress = LdrGetExportByOrdinal(BaseAddress, (WORD)Ordinal);
       if (*ProcedureAddress)
         {
           return STATUS_SUCCESS;
         }
       DPRINT("LdrGetProcedureAddress: Can't resolve symbol @%lu\n", Ordinal);
     }
   return STATUS_PROCEDURE_NOT_FOUND;
}

/**********************************************************************
* NAME                                                         LOCAL
*      LdrGetExportByName
*
* DESCRIPTION
*
* ARGUMENTS
*
* RETURN VALUE
*
* REVISIONS
*
* NOTE
* AddressOfNames and AddressOfNameOrdinals are paralell tables,
* both with NumberOfNames entries.
*
*/
static PVOID
LdrGetExportByName(PVOID BaseAddress,
                   PUCHAR SymbolName,
                   WORD Hint)
{
   PIMAGE_EXPORT_DIRECTORY      ExportDir;
   PDWORD                       * ExFunctions;
   PDWORD                       * ExNames;
   USHORT                       * ExOrdinals;
   PVOID                        ExName;
   ULONG                        Ordinal;
   PVOID                        Function;
   LONG minn, maxn;
   ULONG ExportDirSize;

DPRINT("LdrGetExportByName %p %s %hu\n", BaseAddress, SymbolName, Hint);

   ExportDir = (PIMAGE_EXPORT_DIRECTORY)
     RtlImageDirectoryEntryToData(BaseAddress,
                                  TRUE,
                                  IMAGE_DIRECTORY_ENTRY_EXPORT,
                                  &ExportDirSize);
   if (ExportDir == NULL)
     {
        DPRINT1("LdrGetExportByName(): no export directory!\n");
        return NULL;
     }

   //The symbol names may be missing entirely
   if (ExportDir->AddressOfNames == 0)
   {
      DPRINT("LdrGetExportByName(): symbol names missing entirely\n");
      return NULL;
   }

   /*
    * Get header pointers
    */
   ExNames = (PDWORD *)RVA(BaseAddress,
                           ExportDir->AddressOfNames);
   ExOrdinals = (USHORT *)RVA(BaseAddress,
                              ExportDir->AddressOfNameOrdinals);
   ExFunctions = (PDWORD *)RVA(BaseAddress,
                               ExportDir->AddressOfFunctions);

   /*
    * Check the hint first
    */
   if (Hint < ExportDir->NumberOfNames)
     {
        ExName = RVA(BaseAddress, ExNames[Hint]);
        if (strcmp(ExName, (PCHAR)SymbolName) == 0)
          {
             Ordinal = ExOrdinals[Hint];
             Function = RVA(BaseAddress, ExFunctions[Ordinal]);
             if (((ULONG)Function >= (ULONG)ExportDir) &&
                 ((ULONG)Function < (ULONG)ExportDir + (ULONG)ExportDirSize))
               {
                  DPRINT("Forward: %s\n", (PCHAR)Function);
                  Function = LdrFixupForward((PCHAR)Function);
                  if (Function == NULL)
                    {
                      DPRINT1("LdrGetExportByName(): failed to find %s\n",SymbolName);
                    }
                  return Function;
               }
             if (Function != NULL)
               return Function;
          }
     }

   /*
    * Binary search
    */
   minn = 0;
   maxn = ExportDir->NumberOfNames - 1;
   while (minn <= maxn)
     {
        LONG mid;
        LONG res;

mid = (minn + maxn) / 2;

        ExName = RVA(BaseAddress, ExNames[mid]);
        res = strcmp(ExName, (PCHAR)SymbolName);
        if (res == 0)
          {
             Ordinal = ExOrdinals[mid];
             Function = RVA(BaseAddress, ExFunctions[Ordinal]);
             if (((ULONG)Function >= (ULONG)ExportDir) &&
                 ((ULONG)Function < (ULONG)ExportDir + (ULONG)ExportDirSize))
               {
                  DPRINT("Forward: %s\n", (PCHAR)Function);
                  Function = LdrFixupForward((PCHAR)Function);
                  if (Function == NULL)
                    {
                      DPRINT1("LdrGetExportByName(): failed to find %s\n",SymbolName);
                    }
                  return Function;
               }
             if (Function != NULL)
               return Function;
          }
        else if (minn == maxn)
          {
             DPRINT("LdrGetExportByName(): binary search failed\n");
             break;
          }
        else if (res > 0)
          {
             maxn = mid - 1;
          }
        else
          {
             minn = mid + 1;
          }
     }

DPRINT1("LdrGetExportByName(): failed to find %s\n",SymbolName);
return (PVOID)NULL;
}

DPRINT("LdrGetExportByName %p %s %hu\n", BaseAddress, SymbolName, Hint);

   //The symbol names may be missing entirely
   if (ExportDir->AddressOfNames == 0)
   {
      DPRINT("LdrGetExportByName(): symbol names missing entirely\n");
      return NULL;
   }

   /*
    * Binary search
    */
   minn = 0;
   maxn = ExportDir->NumberOfNames - 1;
   while (minn <= maxn)
     {
        LONG mid;
        LONG res;

mid = (minn + maxn) / 2;

DPRINT1("LdrGetExportByName(): failed to find %s\n",SymbolName);
return (PVOID)NULL;
}

通过代码可以得出：可以正常调用！

ps：以前发现过有壳可以hide导出表的，但刚才没找到这样的壳了，等会继续找，证明这个结论！

Zw与Nt的区别

垃圾一堆 — Thu, 19 Apr 2007 09:57:00 GMT

某些Zw*和Nt*函数既在ntdll.dll中导出又在ntoskrnl.exe中导出，他们有什么区别呢？
我们分三部分比较：
step 1: ntdll.dll中的Zw*和Nt*有什么区别？
step 2: ntoskrnl.exe中的Zw*和Nt*有什么区别？
step 3: ntdll.dll中的Zw*与ntoskrnl.exe中的Zw*有什么区别?
        ntdll.dll中的Nt*与ntoskrnl.exe中的Nt*有什么区别?
在下面的讨论中我们以ZwCreateFile和NtCreateFile为例

讨论前：我先贴点Kd给我们的答案
Part1:
kd> u Ntdll! ZwCreateFile L4
ntdll!ZwCreateFile:
77f87cac b820000000       mov     eax,0x20
77f87cb1 8d542404         lea     edx,[esp+0x4]
77f87cb5 cd2e             int     2e
77f87cb7 c22c00           ret     0x2c
kd> u Ntdll! NtCreateFile L4
ntdll!ZwCreateFile:
77f87cac b820000000       mov     eax,0x20
77f87cb1 8d542404         lea     edx,[esp+0x4]
77f87cb5 cd2e             int     2e
77f87cb7 c22c00           ret     0x2c

Part2:
kd> u Nt!ZwCreateFile L4
nt!ZwCreateFile:
8042fa70 b820000000       mov     eax,0x20
8042fa75 8d542404         lea     edx,[esp+0x4]
8042fa79 cd2e             int     2e
8042fa7b c22c00           ret     0x2c
kd> u Nt!NtCreateFile L14
nt!NtCreateFile:
804a7172 55               push    ebp
804a7173 8bec             mov     ebp,esp
804a7175 33c0             xor     eax,eax
804a7177 50               push    eax
804a7178 50               push    eax
804a7179 50               push    eax
804a717a ff7530           push    dword ptr [ebp+0x30]
804a717d ff752c           push    dword ptr [ebp+0x2c]
804a7180 ff7528           push    dword ptr [ebp+0x28]
804a7183 ff7524           push    dword ptr [ebp+0x24]
804a7186 ff7520           push    dword ptr [ebp+0x20]
804a7189 ff751c           push    dword ptr [ebp+0x1c]
804a718c ff7518           push    dword ptr [ebp+0x18]
804a718f ff7514           push    dword ptr [ebp+0x14]
804a7192 ff7510           push    dword ptr [ebp+0x10]
804a7195 ff750c           push    dword ptr [ebp+0xc]
804a7198 ff7508           push    dword ptr [ebp+0x8]
804a719b e8b284ffff       call    nt!IoCreateFile (8049f652)
804a71a0 5d               pop     ebp
804a71a1 c22c00           ret     0x2c

1) Part1 输出的是Ntdll.dll中ZwCreateFile和NtCreateFile的汇编代码，我们发现实现是一样的;
eax是中断号，edx是函数的参数起始地址([Esp]是返回地址)；从而我可以大胆的说：Ntdll.dll中ZwCreateFile和NtCreateFile功能是一样的作用：都是调用int 2E中断；

IDA给我们的答案：
.text:77F87CAC ; Exported entry 92. NtCreateFile
.text:77F87CAC ; Exported entry 740. ZwCreateFile
.text:77F87CAC
.text:77F87CAC
.text:77F87CAC                 public ZwCreateFile
.text:77F87CAC ZwCreateFile    proc near               ;
.text:77F87CAC
.text:77F87CAC arg_0           = dword ptr 4
.text:77F87CAC
.text:77F87CAC                 mov     eax, 20h        ; NtCreateFile
.text:77F87CB1                 lea     edx, [esp+arg_0]
.text:77F87CB5                 int     2Eh             ; DOS 2+ internal - EXECUTE COMMAND
.text:77F87CB5                                         ; DS:SI -> counted CR-terminated command string
.text:77F87CB7                 retn    2Ch
.text:77F87CB7 ZwCreateFile    endp

原来在ntdll中NtCreateFile只是ZwCreateFile的别名。

2) Part2 输出的是Ntoskrnl.exe中ZwCreateFile和NtCreateFile的汇编代码，也许令你很失望，汇编代码不一样；ZwCreateFile中eax是中断号，edx是函数的参数起始地址，然后调用int 2E中断； NtCreateFile只是把参数入栈去调用IoCreateFile；
他们的区别是:NtCreateFile是实现代码，而ZwCreateFile仍通过中断来实现功能，2E软中断的20h子中断号的处理程序是NtCreateFile；这样一说他们是没区别了？错！NtCreateFile是在ring0下了，而ZwCreateFile是通过int 2E进入ring0的，而不论ZwCreateFile处于什么模式下。

3) 从而我们得出:
   ntdll.dll中ZwCreateFile与ntoskrnl.exe中ZwCreateFile的区别是：前者是user Mode application called，后者是Kernel Mode driver Called;
   ntdll.dll中NtCreateFile与ntoskrnl.exe中NtCreateFile区别是：前者在ring3下工作，后者在ring0下工作；前者通过中断实现，后者是前者的中断处理程序。

注：以前弄的东西，今天才写的，不知道有没有问题，望见谅！如果还有不清楚的参见：http://www.osronline.com/article.cfm?article=257 （Osronline/The Nt Insider/The Nt Insider 2003 Archive）

小议PE病毒技术

垃圾一堆 — Tue, 17 Apr 2007 08:53:00 GMT

Win32 PE病毒和普通Win32 PE程序一样需要调用API函数，但是普通的Win32 PE程序里面有一个导入函数表，该导入函数表对应了代码段中所用到的api函数在动态连接库中的真实地址（由PE Loader去填充这个地址的）。这样，调用api函数时就可以通过该导入函数表找到相应api函数的真正执行地址。

但是对于Win32 PE病毒来说，他只有一个代码段，他并不存在引入函数段。既然如此，病毒就无法象普通PE程序那样直接调用相关API函数，而应该先找出这些API函数在相应动态链接库中的地址。

我们知道通过LoadLibrary和GetProcAddress可以很方便的得到函数的地址，从而方便的去Call，而这两个函数是在kernel32.dll中被导出的，所以我们必须先得到kernel32.dll的基地址，然后再去找
nStart:
    pop ebp
    sub ebp, offset nStart

    ;得到kernel32加载的地址
    mov   dword ptr [ebp+appBase],ebp
    mov   eax,[esp]               ;返回地址
    xor   edx,edx

Get_K32Base:
    dec   eax                                         ;逐字节比较验证，速度比较慢，不过功能一样
    mov   dx,word ptr [eax+IMAGE_DOS_HEADER.e_lfanew] ;就是ecx+3ch
    test dx,0f000h                                   ;Dos Header+stub不可能太大,超过4096byte
    jnz   Get_K32Base                                 ;加速检验，下一个
    cmp   eax,dword ptr [eax+edx+IMAGE_NT_HEADERS.OptionalHeader.ImageBase]
    jnz   Get_K32Base                                 ;看Image_Base值是否等于ecx即模块起始值
    mov   [ebp+k32Base],eax                           ;如果是,就认为找到kernel32的模块装入地址


//这个是通过逐字节比较验证，速度比较慢，我们可以知道通过一页一页去比较，这个暂且不讨论

注意这一句 mov   eax,[esp] 为什么此时[Esp]是在Kernel32.dll中内？？
也就是为什么我们进入EntryPoint时esp是指向kernel32.dll的呢?(OS2003中此时的ESP = 0x77EIF38C)

我们来看看进程创建的整个过程
1 CreateProcessA         call CreateProcessInternalA
2 CreateProcessInternalA call CreateProcessInternalW
3 CreateProcessInternalW call BasepInitializeContext
4 BasepInitializeContext mov dword ptr [eax+0B8h], offsetBaseProcessStart;//这里其实类似一个回调

//其实BaseProcessStart是我们程序在内核中真正启动地址！
5 BaseProcessStart所做的动作是：建立SEH，NtSetInformationThread（启动线程）, ebp+8其实是我们的EntryPoint

具体阅读汇编代码和ReactOS代码（或者Nt4.0代码）

======================================================================

.text:77E48939 CreateProcessA proc near               ; CODE XREF: LoadModule+13Dp
.text:77E48939
.text:77E48939 lpApplicationName= dword ptr 8
.text:77E48939 lpCommandLine   = dword ptr 0Ch
.text:77E48939 lpProcessAttributes= dword ptr 10h
.text:77E48939 lpThreadAttributes= dword ptr 14h
.text:77E48939 bInheritHandles = dword ptr 18h
.text:77E48939 dwCreationFlags = dword ptr 1Ch
.text:77E48939 lpEnvironment   = dword ptr 20h
.text:77E48939 lpCurrentDirectory= dword ptr 24h
.text:77E48939 lpStartupInfo   = dword ptr 28h
.text:77E48939 lpProcessInformation= dword ptr 2Ch
.text:77E48939
.text:77E48939                 push    ebp
.text:77E4893A                 mov     ebp, esp
.text:77E4893C                 push    0
.text:77E4893E                 push    [ebp+lpProcessInformation]
.text:77E48941                 push    [ebp+lpStartupInfo]
.text:77E48944                 push    [ebp+lpCurrentDirectory]
.text:77E48947                 push    [ebp+lpEnvironment]
.text:77E4894A                 push    [ebp+dwCreationFlags]
.text:77E4894D                 push    [ebp+bInheritHandles]
.text:77E48950                 push    [ebp+lpThreadAttributes]
.text:77E48953                 push    [ebp+lpProcessAttributes]
.text:77E48956                 push    [ebp+lpCommandLine]
.text:77E48959                 push    [ebp+lpApplicationName]
.text:77E4895C                 push    0
.text:77E4895E                 call    CreateProcessInternalA
.text:77E48963                 pop     ebp
.text:77E48964                 retn    28h
.text:77E48964 CreateProcessA endp

======================================================================
.text:77E48A6D CreateProcessInternalA proc near        ; CODE XREF: WinExec+3Fp
.text:77E48A6D                                         ; WinExec+A4p ...
.text:77E48A6D
.text:77E48A6D ; FUNCTION CHUNK AT .text:77E488A4 SIZE 00000023 BYTES
.text:77E48A6D ; FUNCTION CHUNK AT .text:77E488F6 SIZE 0000000B BYTES
.text:77E48A6D ; FUNCTION CHUNK AT .text:77E48967 SIZE 00000101 BYTES
.text:77E48A6D
.text:77E48A6D                 push    98h
.text:77E48A72                 push    offset dword_77E542F0
.text:77E48A77                 call    sub_77E116F6
.text:77E48A7C                 xor     ebx, ebx
.text:77E48A7E                 cmp     [ebp+10h], ebx
.text:77E48A81                 jz      loc_77E488A9
.text:77E48A87                 push    dword ptr [ebp+10h]
.text:77E48A8A                 lea     eax, [ebp-44h]
.text:77E48A8D                 push    eax
.text:77E48A8E                 call    sub_77E19AA8
.text:77E48A93                 test    eax, eax
.text:77E48A95                 jz      loc_77E488A4
.text:77E48A9B
.text:77E48A9B loc_77E48A9B:                           ; CODE XREF: CreateProcessInternalA-1B8j
.text:77E48A9B                 mov     [ebp-4Ch], ebx
.text:77E48A9E                 mov     [ebp-34h], ebx
.text:77E48AA1                 push    11h
.text:77E48AA3                 pop     ecx
.text:77E48AA4                 mov     esi, [ebp+2Ch]
.text:77E48AA7                 lea     edi, [ebp-0A8h]
.text:77E48AAD                 rep movsd
.text:77E48AAF                 mov     [ebp-0A4h], ebx
.text:77E48AB5                 mov     [ebp-0A0h], ebx
.text:77E48ABB                 mov     [ebp-9Ch], ebx
.text:77E48AC1                 mov     [ebp-4], ebx
.text:77E48AC4                 xor     esi, esi
.text:77E48AC6                 inc     esi
.text:77E48AC7                 mov     [ebp-4], esi
.text:77E48ACA                 cmp     [ebp+0Ch], ebx
.text:77E48ACD                 jnz     loc_77E48A4D
.text:77E48AD3
.text:77E48AD3 loc_77E48AD3:                           ; CODE XREF: CreateProcessInternalA-12j
.text:77E48AD3                 cmp     [ebp+28h], ebx
.text:77E48AD6                 jnz     short loc_77E48B4E
.text:77E48AD8
.text:77E48AD8 loc_77E48AD8:                           ; CODE XREF: CreateProcessInternalA+F5j
.text:77E48AD8                 mov     eax, [ebp+2Ch]
.text:77E48ADB                 mov     eax, [eax+4]
.text:77E48ADE                 cmp     eax, ebx
.text:77E48AE0                 jnz     loc_77E489E3
.text:77E48AE6
.text:77E48AE6 loc_77E48AE6:                           ; CODE XREF: CreateProcessInternalA+18Aj
.text:77E48AE6                 mov     eax, [ebp+2Ch]
.text:77E48AE9                 mov     eax, [eax+8]
.text:77E48AEC                 cmp     eax, ebx
.text:77E48AEE                 jnz     loc_77E48971
.text:77E48AF4
.text:77E48AF4 loc_77E48AF4:                           ; CODE XREF: CreateProcessInternalA-8Fj
.text:77E48AF4                 mov     eax, [ebp+2Ch]
.text:77E48AF7                 mov     eax, [eax+0Ch]
.text:77E48AFA                 cmp     eax, ebx
.text:77E48AFC                 jnz     short loc_77E48B71
.text:77E48AFE
.text:77E48AFE loc_77E48AFE:                           ; CODE XREF: CreateProcessInternalA+16Bj
.text:77E48AFE                 mov     [ebp-4], ebx
.text:77E48B01                 mov     eax, [ebp-40h]
.text:77E48B04                 cmp     eax, ebx
.text:77E48B06                 jz      loc_77E488F6
.text:77E48B0C
.text:77E48B0C loc_77E48B0C:                           ; CODE XREF: CreateProcessInternalA-171j
.text:77E48B0C                 push    dword ptr [ebp+34h]
.text:77E48B0F                 push    dword ptr [ebp+30h]
.text:77E48B12                 lea     ecx, [ebp-0A8h]
.text:77E48B18                 push    ecx
.text:77E48B19                 push    dword ptr [ebp-34h]
.text:77E48B1C                 push    dword ptr [ebp+24h]
.text:77E48B1F                 push    dword ptr [ebp+20h]
.text:77E48B22                 push    dword ptr [ebp+1Ch]
.text:77E48B25                 push    dword ptr [ebp+18h]
.text:77E48B28                 push    dword ptr [ebp+14h]
.text:77E48B2B                 push    eax
.text:77E48B2C                 push    dword ptr [ebp-4Ch]
.text:77E48B2F                 push    dword ptr [ebp+8]
.text:77E48B32                 call    CreateProcessInternalW//-------@*@*@*@*@*@*@*@*@*@*@*@*@*@-------
.text:77E48B37                 mov     [ebp-1Ch], eax
.text:77E48B3A
.text:77E48B3A loc_77E48B3A:                           ; CODE XREF: CreateProcessInternalA-Aj
.text:77E48B3A                 or      dword ptr [ebp-4], 0FFFFFFFFh
.text:77E48B3E                 call    sub_77E48C0F
.text:77E48B43                 mov     eax, [ebp-1Ch]
.text:77E48B46
.text:77E48B46 loc_77E48B46:                           ; CODE XREF: CreateProcessInternalA:loc_77E488A4j
.text:77E48B46                 call    sub_77E11736
.text:77E48B4B                 retn    30h

======================================================================
CreateProcessInternalW+A50:
.......(省略)
.text:77E22A5A                 lea     ecx, [ebp-344h]
.text:77E22A60                 push    ecx
.text:77E22A61                 push    eax
.text:77E22A62                 push    dword ptr [ebp-1F0h]
.text:77E22A68                 push    dword ptr [ebp-28h]
.text:77E22A6B                 call    sub_77E1AA15
.text:77E22A70                 mov     [ebp-250h], eax
.text:77E22A76                 cmp     eax, ebx
.text:77E22A78                 jl      loc_77E23707
.text:77E22A7E                 push    ebx
.text:77E22A7F                 push    dword ptr [ebp-33Ch]
.text:77E22A85                 push    dword ptr [ebp-1FCh]
.text:77E22A8B                 push    edi
.text:77E22A8C                 lea     eax, [ebp-9A0h]
.text:77E22A92                 push    eax
.text:77E22A93                 call    sub_77E1ABE7//-------@*@*@*@*@*@*@*@*@*@*@*@*@*@-------
.......(省略)

======================================================================
BasepInitializeContext://ReactOs代码上是这样命名的

.text:77E1ABE7 sub_77E1ABE7    proc near               ; CODE XREF: CreateRemoteThread+63p
.text:77E1ABE7                                         ; CreateProcessInternalW+A50p ...
.text:77E1ABE7
.text:77E1ABE7 arg_0           = dword ptr 8
.text:77E1ABE7 arg_4           = dword ptr 0Ch
.text:77E1ABE7 arg_8           = dword ptr 10h
.text:77E1ABE7 arg_C           = dword ptr 14h
.text:77E1ABE7 arg_10          = dword ptr 18h
.text:77E1ABE7
.text:77E1ABE7 ; FUNCTION CHUNK AT .text:77E1AB94 SIZE 0000004E BYTES
.text:77E1ABE7
.text:77E1ABE7                 push    ebp
.text:77E1ABE8                 mov     ebp, esp
.text:77E1ABEA                 mov     eax, [ebp+arg_0]
.text:77E1ABED                 mov     ecx, [ebp+arg_8]
.text:77E1ABF0                 push    ebx
.text:77E1ABF1                 mov     [eax+0B0h], ecx
.text:77E1ABF7                 mov     ecx, [ebp+arg_4]
.text:77E1ABFA                 push    esi
.text:77E1ABFB                 mov     esi, [eax]
.text:77E1ABFD                 mov     [eax+0A4h], ecx
.text:77E1AC03                 push    20h
.text:77E1AC05                 pop     ecx
.text:77E1AC06                 mov     [eax+94h], ecx
.text:77E1AC0C                 mov     [eax+98h], ecx
.text:77E1AC12                 mov     [eax+0C8h], ecx
.text:77E1AC18                 mov     ecx, [ebp+arg_C]
.text:77E1AC1B                 xor     ebx, ebx
.text:77E1AC1D                 add     ecx, 0FFFFFFFCh
.text:77E1AC20                 cmp     [ebp+arg_10], 1
.text:77E1AC24                 lea     edx, [eax+0C4h]
.text:77E1AC2A                 mov     [eax+8Ch], ebx
.text:77E1AC30                 mov     dword ptr [eax+90h], 38h
.text:77E1AC3A                 mov     dword ptr [eax+0BCh], 18h
.text:77E1AC44                 mov     dword ptr [eax], 10007h
.text:77E1AC4A                 mov     dword ptr [eax+0C0h], 3000h
.text:77E1AC54                 mov     [edx], ecx
.text:77E1AC56                 jz      short loc_77E1AC72
.text:77E1AC58                 cmp     [ebp+arg_10], 2
.text:77E1AC5C                 jz      loc_77E1AB94
.text:77E1AC62                 mov     dword ptr [eax+0B8h], offset loc_77E1F35F//-------@*@*@*@*@*@*@*@*@*@*@*@*@*@-------
.text:77E1AC6C
.text:77E1AC6C loc_77E1AC6C:                           ; CODE XREF: sub_77E1ABE7-40j
.text:77E1AC6C                                         ; sub_77E1ABE7-17j ...
.text:77E1AC6C                 pop     esi
.text:77E1AC6D                 pop     ebx
.text:77E1AC6E                 pop     ebp
.text:77E1AC6F                 retn    14h

======================================================================
BaseProcessStart:
.text:77E1F35F loc_77E1F35F:                           ; DATA XREF: sub_77E1ABE7+7Bo
.text:77E1F35F                 xor     ebp, ebp
.text:77E1F361                 push    eax
.text:77E1F362                 push    0
.text:77E1F364                 nop
.text:77E1F365                 nop
.text:77E1F366                 nop
.text:77E1F367                 nop
.text:77E1F368                 nop
.text:77E1F369                 push    0Ch
.text:77E1F36B                 push    offset dword_77E522E0
.text:77E1F370                 call    sub_77E116F6(SEH)
.text:77E1F375                 and     dword ptr [ebp-4], 0
.text:77E1F379                 push    4
.text:77E1F37B                 lea     eax, [ebp+8]
.text:77E1F37E                 push    eax
.text:77E1F37F                 push    9
.text:77E1F381                 push    0FFFFFFFEh
.text:77E1F383                 call    ds:NtSetInformationThread
.text:77E1F389                 call    dword ptr [ebp+8];//我们程序的入口,(push 0x77E1F38C; jmp dword ptr [ebp+8])
.text:77E1F38C                 push    eax
                               call    exitthread;//我们程序正常退出时还要调用ExitThread！

Smss.exe进程分析

垃圾一堆 — Tue, 17 Apr 2007 08:05:00 GMT

传说中的会话管理服务器进程,它是windows操作系统启动时引导的最重要的系统进程,它负责启动csrss.exe和winlogon.exe进程,并对它们进行监控,如果发现其中一个挂掉,它马上叫你当机,所以要想结束csrss.exe/winlogon.exe，先结束Smss.exe，源码前一目了然(摘自windows nt 4.0代码)

//1 Module Info : 变量定义,提高当前进程的优先级(11级)

     NTSTATUS Status;
    KPRIORITY SetBasePriority;
    UNICODE_STRING InitialCommand, DebugInitialCommand, UnicodeParameter;
    HANDLE ProcessHandles[ 2 ];
    ULONG Parameters[ 4 ];
    ULONG Response;
    PROCESS_BASIC_INFORMATION ProcessInfo;
    BOOLEAN WasEnabled;

    SetBasePriority = FOREGROUND_BASE_PRIORITY+2;//#define FOREGROUND_BASE_PRIORITY 9
    Status = NtSetInformationProcess( NtCurrentProcess(),
                                      ProcessBasePriority,
                                      (PVOID) &SetBasePriority,
                                       sizeof( SetBasePriority )
                                    );
    ASSERT(NT_SUCCESS(Status));

    if (ARGUMENT_PRESENT( DebugParameter )) {
        SmpDebug = DebugParameter;
        }

//2 Module Info : 获取Csrss.exe和winlogon.exe进程的句柄,并对它们进行监控

try {
        Status = SmpInit( &InitialCommand, &ProcessHandles[ 0 ] );//返回crsss.exe进程的句柄
        if (!NT_SUCCESS( Status )) {
            KdPrint(( "SMSS: SmpInit return failure - Status == %x\n" ));
            RtlInitUnicodeString( &UnicodeParameter, L"Session Manager Initialization" );
            Parameters[ 1 ] = (ULONG)Status;
            }
        else {
            SYSTEM_FLAGS_INFORMATION FlagInfo;

            NtQuerySystemInformation( SystemFlagsInformation,
                                      &FlagInfo,
                                      sizeof( FlagInfo ),
                                      NULL
                                    );
            if (FlagInfo.Flags & (FLG_DEBUG_INITIAL_COMMAND | FLG_DEBUG_INITIAL_COMMAND_EX) ) {
                DebugInitialCommand.MaximumLength = InitialCommand.Length + 64;
                DebugInitialCommand.Length = 0;
                DebugInitialCommand.Buffer = RtlAllocateHeap( RtlProcessHeap(),
                                                              MAKE_TAG( INIT_TAG ),
                                                              DebugInitialCommand.MaximumLength
                                                            );
                if (FlagInfo.Flags & FLG_ENABLE_CSRDEBUG) {
                    RtlAppendUnicodeToString( &DebugInitialCommand, L"ntsd -p -1 -d " );
                    }
                else {
                    RtlAppendUnicodeToString( &DebugInitialCommand, L"ntsd -d " );
                    }

                if (FlagInfo.Flags & FLG_DEBUG_INITIAL_COMMAND_EX ) {
                    RtlAppendUnicodeToString( &DebugInitialCommand, L"-g -x " );
                    }

                RtlAppendUnicodeStringToString( &DebugInitialCommand, &InitialCommand );
                InitialCommand = DebugInitialCommand;
                }

            Status = SmpExecuteInitialCommand( &InitialCommand, &ProcessHandles[ 1 ] );//返回winlogon进程句柄
            if (NT_SUCCESS( Status )) {
                Status = NtWaitForMultipleObjects( 2,
                                                   ProcessHandles,
                                                   WaitAny,
                                                   FALSE,
                                                   NULL
                                                 );
                }

            if (Status == STATUS_WAIT_0) {
                RtlInitUnicodeString( &UnicodeParameter, L"Windows SubSystem" );
                Status = NtQueryInformationProcess( ProcessHandles[ 0 ],
                                                    ProcessBasicInformation,
                                                    &ProcessInfo,
                                                    sizeof( ProcessInfo ),
                                                    NULL
                                                  );

                KdPrint(( "SMSS: Windows subsystem terminated when it wasn't supposed to.\n" ));
                }
            else {
                RtlInitUnicodeString( &UnicodeParameter, L"Windows Logon Process" );
                if (Status == STATUS_WAIT_1) {
                    Status = NtQueryInformationProcess( ProcessHandles[ 1 ],
                                                        ProcessBasicInformation,
                                                        &ProcessInfo,
                                                        sizeof( ProcessInfo ),
                                                        NULL
                                                      );
                    }
                else {
                    ProcessInfo.ExitStatus = Status;
                    Status = STATUS_SUCCESS;
                    }

KdPrint(( "SMSS: Initial command '%wZ' terminated when it wasn't supposed to.\n", &InitialCommand ));
}

            if (NT_SUCCESS( Status )) {
                Parameters[ 1 ] = (ULONG)ProcessInfo.ExitStatus;
                }
            else {
                Parameters[ 1 ] = (ULONG)STATUS_UNSUCCESSFUL;
                }
            }
        }
    except( SmpUnhandledExceptionFilter( GetExceptionInformation() ) ) {
        RtlInitUnicodeString( &UnicodeParameter, L"Unhandled Exception in Session Manager" );
        Parameters[ 1 ] = (ULONG)GetExceptionCode();
        }

//3 Module Info : 当机代码!呵呵,其实就是通知操作系统,发生了一个硬件中断

Status = RtlAdjustPrivilege( SE_SHUTDOWN_PRIVILEGE,
                                 (BOOLEAN)TRUE,
                                 TRUE,
                                 &WasEnabled
                               );//提高当前的权限,可以执行shutdown指令

if (Status == STATUS_NO_TOKEN) {

        //
        // No thread token, use the process token
        //

        Status = RtlAdjustPrivilege( SE_SHUTDOWN_PRIVILEGE,
                                     (BOOLEAN)TRUE,
                                     FALSE,
                                     &WasEnabled
                                   );
        }

Parameters[ 0 ] = (ULONG)&UnicodeParameter;

    Status = NtRaiseHardError( STATUS_SYSTEM_PROCESS_TERMINATED,
                               2,
                               1,
                               Parameters,
                               OptionShutdownSystem,
                               &Response
                             );//看看,字面意思就知道发生什么了,唤起硬件错误

    //
    // If this returns, giveup
    //

NtTerminateProcess( NtCurrentProcess(), Status );

windows内核

Introduction to Registry Filtering in Vista(OSR)

线程调度的部分资料（乱）

PE加载器的实现

Ring0Prolog

在壳中没导出而在原始文件导出的函数，是否可以调用？

Zw*与Nt*的区别

小议PE病毒技术

Smss.exe进程分析

Zw与Nt的区别