我吃你家米了 - 开发

Windows DSE bypass

2026-06-16T00:00:00+02:00

本项目不会提供漏洞驱动利用代码，如欲使用本工具，请自行实现内核原语

本文介绍一种绕过Windows DSE（Driver Signature Enforcement）的方法

原理：

将未签名的驱动通过漏洞驱动的内核读写能力映射到text段足够大的合法驱动中
进行导入表和data段的修复
获取合法驱动的driver object地址，作为后续hook代码的参数
hook漏洞驱动的可以从用户态触发执行的代码，劫持到未签名驱动的driver entry中

具体实现请参考项目代码

项目地址：

https://github.com/include2016/DriverLoader

效果：

GO系列之并发与Context

2026-03-11T00:00:00+01:00

references:

https://go.dev/blog/context

介绍

在go服务中，每一个进来的请求都由自己的goroutine来负责处理，请求处理器经常启动额外的goroutine来访问后端服务，比如服务器或者RPC服务

一般情况下，goroutine在请求处理的时候需要访问该请求相关的一些特定数据，比如身份信息、认证token和请求时效，当请求取消或者超时之后，所有处理该请求的goroutine都应该快速退出，以便系统能够尽快地回收他们所占用的资源

Google开发了一个context包以便更简单便捷地传递只在该请求中有效的一些数据，context可以打破goroutine的API边界，以在更大的范围内共享数据，本文将会提供完整的代码样例以演示context的使用

context

context包的核心就是Context类型，其定义如下：

// A Context carries a deadline, cancellation signal, and request-scoped values
// across API boundaries. Its methods are safe for simultaneous use by multiple
// goroutines.
type Context interface {
    // Done returns a channel that is closed when this Context is canceled
    // or times out.
    Done() <-chan struct{}

    // Err indicates why this context was canceled, after the Done channel
    // is closed.
    Err() error

    // Deadline returns the time when this Context will be canceled, if any.
    Deadline() (deadline time.Time, ok bool)

    // Value returns the value associated with key or nil if none.
    Value(key interface{}) interface{}
}

Context没有Cancel函数，和Done频道是只接收的一个原因，会收到取消信号的函数一般都不会发送信号

Context对象是并发安全的，可以将Context传递给多个goroutine，取消这个Context即可通知所有的goroutine

Deadline函数用于判断是否应该开始工作，如果剩余时间太短，那么就不值当再去执行了，实际的代码可能会使用deadline来为IO操作设置超时时间

Value允许Context携带请求相关的数据，针对这些数据的操作必须为并发安全的

派生context

context包提供了一个函数可以用于从已经存在的context中派生新的context值，这些值来自于一棵树，当一个Context被取消之后，所有的Context派生的context也都会被取消

Background函数是Context树的root，他永远不会被取消

// Background returns an empty Context. It is never canceled, has no deadline,
// and has no values. Background is typically used in main, init, and tests,
// and as the top-level Context for incoming requests.
func Background() Context

WithCancel和WithTimeout返回派生的Context值，他可以早于父Context被取消，和请求关联的Context通常会在handler返回之后被取消

WithCancel is also useful for canceling redundant requests when using multiple replicas（没看懂）

WithTimeout可以设置deadline

WithValue提供了一种将请求范围内有效的值和Context关联起来的手段

// WithValue returns a copy of parent whose Value method returns val for key.
func WithValue(parent Context, key interface{}, val interface{}) Context

例子，Google web search

本例为一个HTTP server，他会处理这样的URL：

/search?q=golang&timeout=1s

他会将这个“golang”请求转发给Google Web Search API并渲染结果，timeout参数告诉服务器在这个时间之后取消该请求

代码被划分到3个包里面：

server包，提供main方法，以及/search的处理代码
userip包，从请求中提取用户IP地址并将其关联到Context中
google包，提供search函数，将请求发送给Google

服务端程序

服务器处理/search?q=golang这样的请求，他注册了handleSearch函数来处理/search端点，处理代码创建一个初始Context，叫做ctx并将其设置为在处理代码返回之后取消

// 使用http库的HandleFunc注册/search模式的路径到handleSearch函数
http.HandleFunc("/search", handleSearch)

如果设置了超时参数就在超时后自动取消

timeout, err := time.ParseDuration(req.FormValue("timeout"))
if err == nil {
    // The request has a timeout, so create a context that is
    // canceled automatically when the timeout expires.
    ctx, cancel = context.WithTimeout(context.Background(), timeout)
} else {
    ctx, cancel = context.WithCancel(context.Background())
}

context.WithTime和context.WithCancel都会返回一个从context.Background()（根Context）派生出来的子context

前者会在超时后自动取消，也可以使用返回的cancel函数主动取消

后者只能使用cancel函数主动取消

下一行代码是defer cancel() // Cancel ctx as soon as handleSearch returns.

这行代码可以保证在该函数返回之前调用cancel函数来取消context，避免资源的泄漏

然后我们需要获取到用户的IP并将其存储在ctx中

userIP, err := userip.FromRequest(req)
if err != nil {
    http.Error(w, err.Error(), http.StatusBadRequest)
    return
}
ctx = userip.NewContext(ctx, userIP)

NewContext使用如下代码存储数据

    return context.WithValue(ctx, userIPKey, userIP)

需要我们自定义一个key

const userIPKey key = 0

key的值我们可以随便写，别在同一个context里面冲突就行

context.WithValue会返回一个新的context，原来的context就变成了新context的父亲，构建在树上，如下所示

context.Background()  root节点
context  儿子节点
新context 孙子节点

当我们访问新context的value时：ctx.Value(key)，那么他就会先查询新context本身是否有这个key，如果没有就往上遍历，直到root节点，也就是说，原来的context被嵌入到了新context中

req = req.WithContext(ctx)
go func() { c <- f(http.DefaultClient.Do(req)) }()

执行完WithContext函数之后，如果ctx中一开始设置了timeout，则http.DefaultClient.Do会在超时的时候返回

context的特别之处

考虑下面这个例子：

package main

import (
    "fmt"
    "time"
)

type StopSignal struct {
    Stop bool
}

func worker(id int, sig *StopSignal) {
    for i := 0; i < 10; i++ {
        if sig.Stop {
            fmt.Printf("worker %d stopped manually\n", id)
            return
        }
        fmt.Printf("worker %d working %d\n", id, i)
        time.Sleep(200 * time.Millisecond)
    }
}

func main() {
    sig := &StopSignal{}

    for i := 1; i <= 3; i++ {
        go worker(i, sig)
    }

    time.Sleep(1 * time.Second)
    sig.Stop = true // stop signal

    time.Sleep(500 * time.Millisecond)
    fmt.Println("main done")
}

我们所创建的3个goroutine全部通过循环检查sig变量来确定自己什么时候应该退出，而如果我们引入context，就会变得简单和高效

package main

import (
    "context"
    "fmt"
    "time"
)

func worker(ctx context.Context, id int) {
    for i := 0; i < 10; i++ {
        select {
        case <-ctx.Done():
            fmt.Printf("worker %d stopped: %v\n", id, ctx.Err())
            return
        default:
            fmt.Printf("worker %d working %d\n", id, i)
            time.Sleep(200 * time.Millisecond)
        }
    }
}

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel()

    for i := 1; i <= 3; i++ {
        go worker(ctx, i)
    }

    // no need to manually signal stop
    time.Sleep(2 * time.Second)
    fmt.Println("main done")
}

所有goroutine会在超时后自动退出

也可以手动取消

package main

import (
    "context"
    "fmt"
    "time"
)

func worker(ctx context.Context, id int) {
    for i := 0; i < 1000; i++ {
        select {
        case <-ctx.Done():
            fmt.Printf("worker %d stopped: %v\n", id, ctx.Err())
            return
        default:
            fmt.Printf("worker %d working %d\n", id, i)
            time.Sleep(200 * time.Millisecond)
        }
    }
}

func main() {
    var (
        ctx    context.Context
        cancel context.CancelFunc
    )
    ctx, cancel = context.WithCancel(context.Background())

    for i := 1; i <= 3; i++ {
        go worker(ctx, i)
    }

    time.Sleep(2 * time.Second)
    cancel()
    // no need to manually signal stop
    time.Sleep(100 * time.Second)
    fmt.Println("main done")
}

Windows内核编程之引用计数

2025-10-10T00:00:00+02:00

本篇文章为个人笔记，仓库暂时为私有状态

代码仓库

我们先进入这个commit状态的代码进行测试

我们启动驱动，然后使用用户模式的程序连接他的miniport，此时会触发miniport的连接回调函数Comm_PortConnect，该函数会创建一个用于保存连接状态的context结构体，并通过PortCtx_CreateAndInsert函数插入到链表中

此时可以看到新的ctx节点被插入

我们在链表head写入写断点来检测节点删除操作

此时我们卸载驱动，可以看到首先是Unload例程调用PortCtx_Uninit来删除链表中的节点并释放对应内存

 # Child-SP          RetAddr               Call Site
00 ffffdb80`aba76840 fffff802`308b215e     UserModeHookHelper!RemoveHeadList+0x7a
01 ffffdb80`aba76880 fffff802`308b1f39     UserModeHookHelper!PortCtx_Uninit+0x3e
02 ffffdb80`aba768c0 fffff802`35e77aba     UserModeHookHelper!MiniUnload+0x19

之后我们在PortCtx_RemoveAndFree函数下断点，放行

断点触发后调用栈如下

 # Child-SP          RetAddr               Call Site
00 ffffdb80`aba76788 fffff802`308b174d     UserModeHookHelper!PortCtx_RemoveAndFree 
01 ffffdb80`aba76790 fffff802`35e77f19     UserModeHookHelper!Comm_PortDisconnect+0x4d 
02 ffffdb80`aba767d0 fffff802`35e7a7ba     FLTMGR!FltpTerminateActiveConnections+0x6d
03 ffffdb80`aba76800 fffff802`308b1f92     FLTMGR!FltUnregisterFilter+0x1aa
04 ffffdb80`aba768c0 fffff802`35e77aba     UserModeHookHelper!MiniUnload+0x72
05 ffffdb80`aba76900 fffff802`35e77d66     FLTMGR!FltpDoUnloadFilter+0x19e
06 ffffdb80`aba76af0 fffff802`32849b1f     FLTMGR!FltpMiniFilterDriverUnload+0x146
07 ffffdb80`aba76b30 fffff802`322b8515     nt!IopLoadUnloadDriver+0xdbd0f
08 ffffdb80`aba76b70 fffff802`32355855     nt!ExpWorkerThread+0x105
09 ffffdb80`aba76c10 fffff802`323fe808     nt!PspSystemThreadStartup+0x55
0a ffffdb80`aba76c60 00000000`00000000     nt!KiStartSystemThread+0x28

此时Unload函数已经将所有的ctx节点释放掉了，那么再在Comm_PortDisconnect函数中引用ctx必然导致use after free进而导致蓝屏，是一个很大的安全隐患

VOID
Comm_PortDisconnect(
    __in PVOID ConnectionCookie
) {
    PCOMM_CONTEXT pPortCtx = (PCOMM_CONTEXT)ConnectionCookie;
    if (!pPortCtx) return;

    Log(L"client process %d disconnected with port context 0x%p\n",
        pPortCtx->m_UserProcessId, pPortCtx);

    // Remove and free via PortCtx module
    PortCtx_RemoveAndFree(pPortCtx);
}

referecnce count do the rescue

现在将代码设置到这个commit

在定义COMM_CONTEXT结构体之初，我就设置了一个m_RefCount字段，但是只有这一个字段是不够的，还需要再添加一个marker字段m_Removed

一开始我也不太理解为什么要同时设置这两个字段，后来copilot给我解释了一下我才明白

m_Removed字段用于告诉调用者当前的ctx已经从list中移除了，其内存马上就要被释放了，不要再使用这个ctx了

m_RefCount作为ctx的引用计数可以确保ctx只有在m_RefCount为0的时候才会被释放

考虑下面这种场景

调用者A得到一个ctx对象，那么他必须给引用计数+1，这样就能确保该对象不会在自己的使用过程中被释放掉
调用者B想要从链表中移除并释放该ctx的内存，那么他需要进行如下操作：
加锁，将m_Remove设置为TRUE
降低引用计数，由于A增加了引用计数，此时的引用计数必不为0，因此无法释放内存
而此时如果我们没有m_RefCount，只有m_Removed字段，那么就会直接释放A正在使用的ctx对象的内存
而m_Removed又可以组织我们对正在准备被删除的对象进行操作

还有一点需要注意的就是，针对我们的miniport断开连接回调，我们需要先检测存储在ConnectionCookie中的ctx是否已经被释放，因为即使是使用了引用计数，这个函数也有可能在ctx被使用之后再被调用，此时获取到的ctx将指向已经被释放的内存，针对该指针的任何引用操作都可能导致预期外的行为

因此我们增加了PortCtx_FindAndReferenceByCookie函数以检查其中的ctx是否已经不存在于ctx链表中

这样就可以避免悬垂指针的问题

Windows RPC学习

2025-09-19T00:00:00+02:00

参考链接：

本文所有压缩包的密码都是1，使用VS2017进行编译

项目文件

reactos_rpcrt4_test_code

使用reactos的rpcrt4.dll作为运行时来调试rpc的内部实现原理

下图中的aaarpcrt4.dll就是reactos项目的rpcrt4.dll，advapi32_vista.dll和kernel32_vista.dll是我从reactos操作系统中拷贝出来的，他俩是reactos的rpcrt4的依赖

reactos的源码无法直接使用，需要对多个文件进行修改，修改后可以正常使用的reactos源码项目

另外，编译环境需要RosBE，把这个下载解压，然后bin目录添加到环境变量重启电脑即可编译reactos项目

服务端实现

RpcServerUseProtseqEp

RPCRT4_get_or_create_serverprotseq

构造一个Protseq字符串，然后调用RPCRT4_get_or_create_serverprotseq，该函数会构造传出参数RpcServerProtseq结构体，maxcall指定最大连接数

进入该函数后，他会尝试遍历一个存储了所有已经存在的RpcServerProtseq列表，如果发现已经存在，就直接使用已经存在的

否则就调用alloc_serverprotoseq创建一个新的

该函数首先通过调用rpcrt4_get_protseq_ops来查询我们指定的protocol sequence是否在他的支持范围内，reactos的rpc运行时只支持下面这3种

protcol sequence name: ncacn_np
protcol sequence name: ncalrpc
protcol sequence name: ncacn_ip_tcp

我们匹配到ncalrpc协议，从protseq_ops结构体列表中返回对应的节点

可以看到该结构体除了第一个字段是协议名称，其他的全部都是成员函数

紧接着调用成员函数alloc来分配一个RpcServerProtseq_np结构体，注意这里的后缀_np，因为我们使用的是ncalrpc协议，这里使用的也是对应的RpcServerProtseq结构体，不过它里面会内嵌一个RpcServerProtseq结构体，字段名为common

ncalrpc对应的alloca函数为

rpcrt4_protseq_np_alloc

然后填充该结构体的各个字段，该结构体的两个list会在此处初始化，分别用于记录listener和connection

还有一个list_entry作为protseqs全局列表的索引被添加进去，这个就是前面RPCRT4_get_or_create_serverprotseq尝试查询是否存在已经创建的协议序列的那个列表

并且还初始化了一个critical section，后面会用到

RPCRT4_use_protseq

首先使用RPCRT4_protseq_is_endpoint_registered检测该段点是否已经被注册过

他查询的是我们前面创建出来的RpcServerProtseq_np的listener列表，也就是查询自己是否已经注册过这个端点

如果发现该段点还未被创建，就调用ops对象的成员函数open_endpoint来注册一个端点

status = ps->ops->open_endpoint(ps, endpoint);

对于ncalrpc端点，对应的函数是rpcrt4_protseq_ncalrpc_open_endpoint，该函数会调用RPCRT4_CreateConnection创建一个RpcConnection对象

根据协议序列，从一个全局数组conn_protseq_list中返回一个预设的connection_ops对象

之后就是对该对象进行初始化，给各个字段进行赋值，其中初始化了两个list_entry，推测为后续提供给某个全局链表使用

返回之后调用ncalrpc_pipe_name函数，传入的参数为端点名称

reactos的ncalrpc并未真正使用windows的lpc机制，而是使用命名管道模拟的

这个函数就是拼接出来一个命名管道路径，返回之后调用rpcrt4_conn_create_pipe创建命名管道

connection->pipe = CreateNamedPipeA(connection->listen_pipe, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
                                        PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE,
                                        PIPE_UNLIMITED_INSTANCES,
                                        RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL);

之后connnection对象被插入到protseq对象的listeners列表中

list_add_head(&protseq->listeners, &Connection->protseq_entry);

RpcServerRegisterAuthInfo

注册认证信息

我们是本地通信，这一部分忽略

其实就是在全局链表中新增了一个rpc_server_registered_auth_info节点

RpcServerRegisterIfEx

就是创建了一个RpcServerInterface对象，然后添加到全局链表server_interfaces中

RpcServerListen

该函数会调用RPCRT4_start_listen

该函数会创建一个事件叫做listen_done_event

然后全局变量listen_count自增，如果是第一次listen，自增之后将等于1，此时将全局变量std_listen设置为1

之后在一个循环中调用RPCRT4_start_listen_protseq，遍历所有的协议序列，逐个监听

if (std_listen)
  {
    EnterCriticalSection(&server_cs);
    LIST_FOR_EACH_ENTRY(cps, &protseqs, RpcServerProtseq, entry)
    {
      status = RPCRT4_start_listen_protseq(cps, TRUE);
      if (status != RPC_S_OK)
        break;

      /* make sure server is actually listening on the interface before
       * returning */
      RPCRT4_sync_with_server_thread(cps);
    }
    LeaveCriticalSection(&server_cs);
  }

传入的参数就是RpcServerProtseq对象

RPCRT4_start_listen_protseq函数会初始化该对象的一些字段包括mgr_mutex和server_ready_event，然后启动一个线程，线程routine是RPCRT4_server_thread

RPCRT4_server_thread

首先是一个死循环

objs = cps->ops->get_wait_array(cps, objs, &count);

这里是一个动态注册的函数，ncalrpc对应的函数就是rpcrt4_protseq_np_get_wait_array

rpcrt4_protseq_np_get_wait_array

在该线程函数中，根据传入的RpcServerProtseq对象，可以定位到RpcServerProtseq_np对象，因为RpcServerProtseq对象是RpcServerProtseq_np的common字段，使用下面的代码即可定位到RpcServerProtseq_np对象的地址

CONTAINING_RECORD(protseq, RpcServerProtseq_np, common);

然后他会遍历protseq的listeners链表

LIST_FOR_EACH_ENTRY(conn, &protseq->listeners, RpcConnection_np, common.protseq_entry)

上面这个宏的含义如下

遍历protseq->listeners链表的每一个节点，每一个节点就是一个list_entry，该list_entry同时位于RpcConnection_np结构体的common.protseq_entry字段，这样只要我们拿到list_entry，减去common.protseq_entry字段在RpcConnection_np结构体中的偏移量，即可得到RpcConnection_np对象的地址，这样我们就可以获取到所有的conn节点

此时connection对象的listen_event字段为空，会尝试执行get_np_event函数

如果有event_cache就返回缓存并清空缓存，没有的话就创建一个

static HANDLE get_np_event(RpcConnection_np *connection)
{
    HANDLE event = InterlockedExchangePointer(&connection->event_cache, NULL);
    return event ? event : CreateEventW(NULL, TRUE, FALSE, NULL);
}

返回后调用NtFsControlFile函数

status = NtFsControlFile(conn->pipe, event, NULL, NULL, &conn->io_status, FSCTL_PIPE_LISTEN, NULL, 0, NULL, 0);

通知指定的pipe等待客户端连接，由于我们指定了event参数，这个调用会立即返回并将status设置为STATUS_PENDING，此时conn->io_status中并未包含任何有意义的值，等待操作真正完成之后，里面才会包含有意义的值

之后将count传出参数自增，需要注意的是count的初始值为1，因为他要预留一个位置用于存储mgr_event，表明当前处于等待连接状态的连接数量

后面会分配内存，大小为count*sizeof(HNADLE)

objs = HeapAlloc(GetProcessHeap(), 0, *count*sizeof(HANDLE));

其中objs[0]将存储RpcServerProtseq_np对象的mgr_event，之后使用跟上面一样的遍历方法对objs依次赋值conn对象的listen_event字段

这样我们就获取到了一个wait_array，用于等待来自客户端的连接

wait_for_new_connection

在上面调用rpcrt4_protseq_np_get_wait_array函数返回之后，我们得到一个wait_array

res = cps->ops->wait_for_new_connection(cps, count, objs);

之后传入RpcServerProtseq对象和wait_array以及array长度，此处为动态注册函数，ncalrpc对应的为rpcrt4_protseq_np_wait_for_new_connection

在该函数中，他会使用WaitForMultipleObjectsEx一次性等待所有的wait_array中的事件，这个函数会阻塞我们当前线程，直到有新的管道连接进来，或者mgr_event处于signaled状态，不要忘了objs数组的第一个成员就是mgr_event，而这个event会在我们的主线程中被signal

那么被主线程signal之后，我们的WaitForMultipleObjectsEx会返回WAIT_OBJECT_0，也就是说等待数组中的第一个事件被signal了，之后我们将返回值设为0并返回

然后将set_ready_event变量设置为TRUE

前面我们提到，我们是在一个死循环里面，此时我们会继续回到循环头部

if (set_ready_event)
    {
        /* signal to function that changed state that we are now sync'ed */
        SetEvent(cps->server_ready_event);
        set_ready_event = FALSE;
    }

那么此时这个条件就满足了，server_ready_event事件就会被signal，此时主线程的wait操作就可以解除阻塞状态，这样主线程就知道RPCRT4_server_thread线程已经准备好接收连接了

此时我们会再次调用到rpcrt4_protseq_np_wait_for_new_connection函数，这次就没有人会signal我们的mgr_event了，只有在pipe有新的连接进来时才会接触server_thread的阻塞

这里有一个需要注意的点，mgr_event是自动重置事件，在signal之后，之前处于wait状态的线程解除阻塞，系统会自动重置mgr_event为non-signaled状态，再次调用wait依然还会阻塞

ps->mgr_event = CreateEventW(NULL, FALSE, FALSE, NULL);

CreateEventW的第二个参数为bManualReset，指定为FALSE即代表自动重置

在客户端调用rpcrt4_conn_open_pipe打开pipe之后，服务端收到连接，WaitForMultipleObjectsEx解除阻塞状态，进入连接处理的逻辑代码

b_handle = objs[res - WAIT_OBJECT_0];

使用上面的代码可以计算出来是哪一个正在listen的pipe handle接收到了连接，res是WaitForMultipleObjectsEx函数的返回值

        LIST_FOR_EACH_ENTRY(conn, &protseq->listeners, RpcConnection_np, common.protseq_entry)
        {
            if (b_handle == conn->listen_event)
            {
                release_np_event(conn, conn->listen_event);
                conn->listen_event = NULL;
                if (conn->io_status.u.Status == STATUS_SUCCESS || conn->io_status.u.Status == STATUS_PIPE_CONNECTED)
                    cconn = rpcrt4_spawn_connection(&conn->common);
                else
                    ERR("listen failed %x\n", conn->io_status.u.Status);
                break;
            }
        }

哪一个连接的event和解除阻塞状态的conn对象的listen_event对得上号，那么就说明这个连接有新的客户端进来了

release_np_event会获取cache_event字段，如果不为空，就关闭eventhandle，返回后将listen_event置空，但是这里直接置空的话，如果后面你需要关闭这个event的句柄，你怎么办？

哦我懂了，在release_np_event函数中，listen_event被交换到了event_cache字段中

然后调用rpcrt4_spawn_connection函数，传入的参数为收到连接的老的连接对象，该函数会使用RPCRT4_CreateConnection根据老的连接对象的属性创建一个新的连接对象，之后调用rpcrt4_conn_handoff函数

rpcrt4_conn_handoff(old_connection, connection);

static inline RPC_STATUS rpcrt4_conn_handoff(RpcConnection *old_conn, RpcConnection *new_conn)
{
  return old_conn->ops->handoff(old_conn, new_conn);
}

动态注册，ncalrpc对应的函数为rpcrt4_ncalrpc_handoff

其实他这个逻辑就是新的连接进来之后就创建出一个新的连接对象来承载新的连接，而老的连接对象的pipehandle字段将用存储一个新创建的pipe实例，相关的事件字段也会被重置，从而可以继续他的监听工作

而每次创建新连接的关键就是调用下面的代码

connection->pipe = CreateNamedPipeA(connection->listen_pipe, PIPE_ACCESS_DUPLEX | FILE_FLAG_OVERLAPPED,
                                        PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE,
                                        PIPE_UNLIMITED_INSTANCES,
                                        RPC_MAX_PACKET_SIZE, RPC_MAX_PACKET_SIZE, 5000, NULL);

你可能会问，我们之前不是已经创建过这个命名管道了吗，为什么这里还可以重复创建，原因就是管道的特殊之处就在于它可以拥有多个实例（instance）

我不知道他这里为什么要记录本地计算机名称

if (!GetComputerNameA(new_conn->NetworkAddr, &len))

最后使用新创建出来的连接对象作为参数，调用RPCRT4_new_client函数，该函数会创建一个线程，线程函数为RPCRT4_io_thread，参数为新连接，此时新连接对象中保存着收到连接的pipe实例的句柄

RPCRT4_receive_fragment

在服务端专门用来处理客户端连接的线程函数RPCRT4_io_thread会接收用户发送过来的数据

通过connect中的connection_ops对象动态注册的receive_fragment成员函数来接收数据包，不过我们当前调试的实例显示connection_ops对象的receive_fragment成员是空的

在这种情况下，RPCRT4_default_receive_fragment函数将会被调用

首先他会尝试读取出一个头部RpcPktCommonHdr

dwRead = rpcrt4_conn_read(Connection, &common_hdr, sizeof(common_hdr));

通过rpcrt4_conn_np_read进行namedpipe的读取操作

核心就是使用NtReadFile对管道进行读取

NtReadFile(connection->pipe, event, NULL, NULL, &connection->io_status, buffer, count, NULL, NULL);

而且这里传入了event参数，是一个异步读操作，会立即返回，实际调试的时候这里返回了一个0x80000005，STATUS_BUFFER_OVERFLOW，我懂了，他提供的buffer长度只是一个header的长度，而实际上客户端写入的数据要远大于一个header的长度，即使返回了bufferoverflow，他依然可以正常读取出一个header的数据，最终返回的io_status.information中存储的就是成功读取出的数据长度

读出的header数据如下

header中的type字段可以用于确定header的类型

 sizeof(Header->request), 0, sizeof(Header->response),
    sizeof(Header->fault), 0, 0, 0, 0, 0, 0, 0, sizeof(Header->bind),
    sizeof(Header->bind_ack), sizeof(Header->bind_nack),
    0, 0, sizeof(Header->auth3), 0, 0, 0, sizeof(Header->http)

0xb对应的就是Header->bind，也就是说客户端发送过来的是bind请求

可以看到，一开始我们读取的是common_hdr，在获取到common_hdr之后，我们得到header类型，根据header类型获取到真正的header长度，然后我们按照这个长度分配buffer，将buffer向前移动sizeof(comon_hdr)，因为前面以前将common_hdr读出来了，再从管道读的话就是之后的内容了

dwRead = rpcrt4_conn_read(Connection, &(*Header)->common + 1, hdr_length - sizeof(common_hdr));

&(*Header)->common + 1其实就是从header开始向前移动一个common_hdr的长度

在之前读取出来的common_hdr中，我们通过frag_len可以知道整个数据包的长度，那么减去现在的头部的长度，如果不等于0，说明后面还有payload

最终该函数读取出了header和payload

process_bind_packet

在确定当前请求为bind请求之后，就通过该函数来处理bind数据包

RPCRT4_find_interface

这个是我很感兴趣的一个函数，他会使用接口的GUID来寻找接口，我倒要看看他究竟是怎么实现的

sif = RPCRT4_find_interface(NULL, &ctxt_elem->abstract_syntax,
                                      &ctxt_elem->transfer_syntaxes[j], FALSE);

他传入了我们接口自定的GUID和传输语法GUID作为参数

查找的方法就是遍历全局链表server_interfaces，根据我们传入的interface GUID进行比对

  LIST_FOR_EACH_ENTRY(cif, &server_interfaces, RpcServerInterface, entry) {
    if (!memcmp(if_id, &cif->If->InterfaceId, sizeof(RPC_SYNTAX_IDENTIFIER)) &&
        (!transfer_syntax || !memcmp(transfer_syntax, &cif->If->TransferSyntax, sizeof(RPC_SYNTAX_IDENTIFIER))) &&
        (check_object == FALSE || UuidEqual(MgrType, &cif->MgrTypeUuid, &status)) &&
        std_listen) {
      InterlockedIncrement(&cif->CurrentCalls);
      break;
    }
  }

最后调用RPCRT4_MakeBinding函数

该函数就是初始化一个RpcBinding结构体

0:005> dt RpcBinding 00000242915AF1C0
aaarpcrt4!RpcBinding
   +0x000 refs             : 0n1
   +0x008 Next             : (null) 
   +0x010 server           : 0n1
   +0x014 ObjectUuid       : _GUID {00000000-0000-0000-0000-000000000000}
   +0x028 Protseq          : 0x00000242`915aefb0  "ncalrpc"
   +0x030 NetworkAddr      : 0x00000242`915af270  "DESKTOP-7PE7PN4"
   +0x038 Endpoint         : 0x00000242`915af2b0  "NCALRPCServer12138"
   +0x040 NetworkOptions   : (null) 
   +0x048 BlockingFn       : (null) 
   +0x050 ServerTid        : 0
   +0x058 FromConn         : 0x00000242`915acb40 _RpcConnection
   +0x060 Assoc            : (null) 
   +0x068 AuthInfo         : (null) 
   +0x070 QOS              : (null) 
   +0x078 CookieAuth       : (null)

在这一切都处理完成之后，服务端需要发回一个ack确认包给客户端

RPCRT4_BuildBindAckHeader

构建完ack包之后，使用RPCRT4_SendWithAuth函数发送给client

发送函数会调用connection_ops对象的write方法，ncalrpc对应的是rpcrt4_conn_np_write函数，该函数的核心调用就是NtWriteFile，现在我们回去调试客户端

QueueUserWorkItem

客户端发送了RPCCALL到服务端，此时服务端的RPCRT4_io_thread线程函数的死循环开始处理PKT_REQUEST类型的数据包

 if (!QueueUserWorkItem(RPCRT4_worker_thread, packet, WT_EXECUTELONGFUNCTION)) {
        ERR("couldn't queue work item for worker thread, error was %d\n", GetLastError());
        HeapFree(GetProcessHeap(), 0, packet);
        status = RPC_S_OUT_OF_RESOURCES;
      } else {
        continue;
      }

他这里使用了用户模式的WorkItem，和windows内核模式的work item一样，用户模式下的workitem同样也运行在当前进程的arbitrary thread context下

将客户端发送过来的数据包packet作为workitem函数RPCRT4_worker_thread的参数，并且指定了WT_EXECUTELONGFUNCTION标志以便于windows thread pool决定是否创建新的线程

而此线程函数只是RPCRT4_process_packet函数的wrapper，该函数会根据packet类型调用对应的函数，此时应该调用PKT_REQUEST数据包的处理函数process_request_packet

其实我现在最想知道的就是他如何处理那个传出参数

根据客户端传过来的procnum从dispatchtable中定位对应的函数

从上图中可以看到，其实派遣表中的6个函数全部都是NdrServerCall2，下面让我们来看看这个函数里面到底暗藏什么玄机

NdrServerCall2是NdrStubCall2的wrapper，根据函数的注释可以知道这个函数的功能是unmarshal客户端传送过来的数据并调用指定的函数

从RpcMsg中可以获取到服务端的派遣函数表

RpcMsg之所以能够索引到这个信息，并不是说客户端发送的数据中包含这些东西，而是在服务端的代码中根据conn对象的guid定位到接口描述信息，然后把这个信息放到了rpcmsg对象的RpcInterfaceInformation字段中

关键点就在此处，服务端为我们分配了contexthandle并将其写入了传出参数的地址中

在NdrContextHandleInitialize函数中，新分配的context handle结构体会被添加到一个全局链表中

list_add_tail(&assoc->context_handle_list, &context_handle->entry);

另外就是他通过RPCRT4_PushThreadContextHandle函数，在当前线程的tdata对象中也存了一个context_handle_list并将我们新创建的context_handle添加了进去

我现在不理解的的点事，服务端和客户端的context handl的值是互不相干的，那么他们是如何对这个context handle进行跟踪的呢？

server context handle定位代码调用栈

0:006> k
 # Child-SP          RetAddr               Call Site
00 0000004b`eeefe770 00007ffc`85255e0d     aaarpcrt4!RpcServerAssoc_FindContextHandle+0x63 [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\rpc_assoc.c @ 495] 
01 0000004b`eeefe7c0 00007ffc`8526ac7f     aaarpcrt4!NDRSContextUnmarshall2+0x1ad [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_contexthandle.c @ 349] 
02 0000004b`eeefe820 00007ffc`8525a2fb     aaarpcrt4!NdrServerContextNewUnmarshall+0x1ef [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 7238] 
03 0000004b`eeefe880 00007ffc`852755b0     aaarpcrt4!NdrContextHandleUnmarshall+0x1cb [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 7044] 
04 0000004b`eeefe8e0 00007ffc`85279080     aaarpcrt4!call_unmarshaller+0xf0 [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 126] 
05 0000004b`eeefe940 00007ffc`8527426f     aaarpcrt4!stub_do_args+0x4b0 [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 1283] 
06 0000004b`eeefe9d0 00007ffc`8527375c     aaarpcrt4!NdrStubCall2+0xa0f [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 1537] 
07 0000004b`eeeff460 00007ffc`8529148c     aaarpcrt4!NdrServerCall2+0x1c [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 1575] 
08 0000004b`eeeff4a0 00007ffc`8528d84d     aaarpcrt4!process_request_packet+0x46c [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\rpc_server.c @ 436] 
09 0000004b`eeeff540 00007ffc`8528e1f7     aaarpcrt4!RPCRT4_process_packet+0xad [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\rpc_server.c @ 515] 
0a 0000004b`eeeff590 00007ffc`986a0cd3     aaarpcrt4!RPCRT4_worker_thread+0x47 [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\rpc_server.c @ 538] 
0b 0000004b`eeeff5e0 00007ffc`9867d79a     ntdll!TpSetPoolStackInformation+0x1a3
0c 0000004b`eeeff6c0 00007ffc`96b47374     ntdll!TpReleaseCleanupGroupMembers+0xada
0d 0000004b`eeeff9c0 00007ffc`9867cc91     KERNEL32!BaseThreadInitThunk+0x14
0e 0000004b`eeeff9f0 00000000`00000000     ntdll!RtlUserThreadStart+0x21

说白了就是将context handle强转为NDR_SCONTEXT对象，然后和const_handle_list中的所有节点进行对比，比对的根据就是NDR_SCONTEXT->uuid

现在的问题是我不知道他是如果将客户端的contexthandle转换为server端可识别的一个合法地址的，需要再回溯一下

从实际调试结果来看，在服务端的RPCRT4_io_thread线程中，RPCRT4_receive_fragment函数接收过来的payload中就已经有了用于索引context handle的GUID了

我在RPCRT4_ReceiveWithAuth函数中增加了下面的代码

这样在payload收到之后我们就可以看到他里面的GUID信息，从debug信息中也可以看到，此时dump出来的guid和一开始给context handle分配的GUID是一致的

所以从本质上来讲，客户端的context handle的值对服务端并没有意义，有意义的是这个GUID，我现在可以大胆推测，客户端那边肯定对context handle和GUID进行了关联，现在我就去看一下他是怎么关联的

RPCRT4_start_listen

上面提到RPCRT4_start_listen通过调用RPCRT4_start_listen_protseq启动了一个新的线程，线程函数为RPCRT4_server_thread

该函数返回后，会调用RPCRT4_sync_with_server_thread

static void RPCRT4_sync_with_server_thread(RpcServerProtseq *ps)
{
  /* make sure we are the only thread sync'ing the server state, otherwise
   * there is a race with the server thread setting an older state and setting
   * the server_ready_event when the new state hasn't yet been applied */
  WaitForSingleObject(ps->mgr_mutex, INFINITE);

  ps->ops->signal_state_changed(ps);

  /* wait for server thread to make the requested changes before returning */
  WaitForSingleObject(ps->server_ready_event, INFINITE);

  ReleaseMutex(ps->mgr_mutex);
}

其中ps->ops->signal_state_changed是rpcrt4_protseq_np_signal_state_changed，动态注册，ncalrpc对应的就是这个函数，这个函数会将上面RPCRT4_server_thread中的wait_array的第一个事件，即mgr_event设置为signaled状态

这里在signal完mgr_event事件之后，会阻塞等待server_ready_event事件，该事件会在RPCRT4_server_thread线程准备好接受连接之后被signal，这也是为什么这个函数叫做RPCRT4_sync_with_server_thread的原因，它可以确保在该函数返回的时候，服务线程已经开始监听连接了

之后主线程会调用RpcMgmtWaitServerListen来等待在RPCRT4_start_listen函数中创建的listen_done_event事件，从而进入阻塞状态

客户端实现

RpcStringBindingComposeA

就是字符串拼接

根据protocol sequence和endpoint拼接出来下面这样的字符串

ncalrpc:[NCALRPCServer12138]

RpcBindingFromStringBinding

传入上面拼接出来的字符串，获取到一个binding handle

在该函数中，会通过RPCRT4_CreateBindingA创建一个RpcBinding对象，并对其进行初始化

最后会创建一个RpcAssoc对象关联到我们的Assoc字段上

然后这个RpcAssoc对象被添加到了全局链表client_assoc_list中

RpcBindingSetAuthInfoExA

我们是本地通信，忽略这一块

NdrClientCall2

可以看到一开始是一堆汇编代码

PUBLIC NdrClientCall2
.PROC NdrClientCall2
    mov [rsp + 18h], r8
    .SAVEREG r8, 18h
    mov [rsp + 20h], r9
    .SAVEREG r9, 20h
    sub rsp, 28h
    .ALLOCSTACK 28h
    .ENDPROLOG

    lea r8, [rsp + 28h + 18h]
    xor r9, r9
    call ndr_client_call

    add rsp, 28h
    ret
.ENDP

对应的调试器中的汇编代码如下：

  589 00007ffe`5b7294d4 4c89442418      mov     qword ptr [rsp+18h],r8
  592 00007ffe`5b7294d9 4c894c2420      mov     qword ptr [rsp+20h],r9
  594 00007ffe`5b7294de 4883ec28        sub     rsp,28h
  598 00007ffe`5b7294e2 4c8d442440      lea     r8,[rsp+40h]
  599 00007ffe`5b7294e7 4d33c9          xor     r9,r9
  600 00007ffe`5b7294ea e8a1edfcff      call    aaarpcrt4!ndr_client_call (00007ffe`5b6f8290)
  602 00007ffe`5b7294ef 4883c428        add     rsp,28h
  603 00007ffe`5b7294f3 c3              ret

我们实际的C代码如下：

    g_pNdrClientCall2(
        (PMIDL_STUB_DESC)&NCALRPCInterface_StubDesc,
        (PFORMAT_STRING)&NCALRPCInterface__MIDL_ProcFormatString.Format[114],
        hBinding,
        szString,
        phContext);

可以看到我们实际上传了5个参数，现在r8\r9都被修改了，我很好奇他怎么访问到我们传入的参数

虽然r8\r9都被修改了，但是他们俩在此之前先存入了栈里面，最后r8还保存了一个栈地址作为第三个参数传入进去了，根据汇编代码我们可以知道

poi(r8)就是原始的a3，poi(r8+8)就是原始的a4，poi(r8+10)就是原始的a5

我们给NdrClientCall2传入的第二个参数其实是一个NDR_PROC_HEADER结构体

如果flag中存在Oi_HAS_RPCFLAGS标志位，则需要重新解释为NDR_PROC_HEADER_RPC结构体

#define Oi_HAS_RPCFLAGS             0x08

处理完成后pFormat指针行前移动sizeof(NDR_PROC_HEADER_RPC)，header已经处理完了，该处理下面的内容了

    if (pProcHeader->Oi_flags & Oi_HAS_RPCFLAGS)
    {
        const NDR_PROC_HEADER_RPC *header_rpc = (const NDR_PROC_HEADER_RPC *)&pFormat[0];
        stack_size = header_rpc->stack_size;
        procedure_number = header_rpc->proc_num;
        pFormat += sizeof(NDR_PROC_HEADER_RPC);
    }

如果不存在Oi_OBJECT_PROC标志位，就调用get_handle_desc_size

#define Oi_OBJECT_PROC              0x04

其实这一部分代码就是在解析NCALRPCInterface__MIDL_ProcFormatString的format字段的144偏移

pFormat += get_handle_desc_size(pProcHeader, pFormat);

这一部分已经属于NDR引擎的范畴了

我们使用的是explicit_handle，handle_type为FC_BIND_PRIMITIVE，对应的结构体如下，这个和微软的文档是完全对的上的

0:000> dt NDR_EHD_PRIMITIVE
aaarpcrt4!NDR_EHD_PRIMITIVE
   +0x000 handle_type      : UChar
   +0x001 flag             : UChar
   +0x002 offset           : Uint2B

根据文档，offset字段描述了handle相对于stack开始位置的偏移

pFormat指针继续向前

我们确实是有两个参数，一个是helloworld字符串，另一个是传出参数context handle

0:000> dt NDR_PROC_PARTIAL_OIF_HEADER poi(pOIFHeader)
aaarpcrt4!NDR_PROC_PARTIAL_OIF_HEADER
   +0x000 constant_client_buffer_size : 0
   +0x002 constant_server_buffer_size : 0x38
   +0x004 Oi2Flags         : INTERPRETER_OPT_FLAGS
   +0x005 number_of_params : 0x2 ''

最后pformat前进到如下位置，然后调用do_ndr_client_call

根据format string的描述，我们的szString参数位于stack的0x8偏移

        RetVal = do_ndr_client_call(pStubDesc, pFormat, pHandleFormat,
                stack_top, fpu_stack, &stubMsg, procedure_number, stack_size,
                number_of_params, Oif_flags, ext_flags, pProcHeader);

这跟我们在刚进入NdrClientCall2的汇编代码时做的验证是一致的

do_ndr_client_call

该函数会调用NdrClientInitializeNew初始化MIDL_STUB_MESSAGE结构体

0:000> dt   MIDL_STUB_MESSAGE 0049`009bedd0
aaarpcrt4!MIDL_STUB_MESSAGE
   +0x000 RpcMsg           : 0x00000049`009be490 _RPC_MESSAGE
   +0x008 Buffer           : 0x00000049`009bede0  ""
   +0x010 BufferStart      : (null) 
   +0x018 BufferEnd        : (null) 
   +0x020 BufferMark       : 0x00000049`009bf410  ""
   +0x028 BufferLength     : 0
   +0x02c MemorySize       : 0x7ffe
   +0x030 Memory           : 0x00000000`00000004  "--- memory read error at address 0x00000000`00000004 ---"
   +0x038 IsClient         : 0x1 ''
   +0x039 Pad              : 0xf4 ''
   +0x03a uFlags2          : 0x9b
   +0x03c ReuseBuffer      : 0n0
   +0x040 pAllocAllNodesContext : (null) 
   +0x048 pPointerQueueState : (null) 
   +0x050 IgnoreEmbeddedPointers : 0n0
   +0x058 PointerBufferMark : (null) 
   +0x060 CorrDespIncrement : 0 ''
   +0x061 uFlags           : 0 ''
   +0x062 UniquePtrCount   : 0
   +0x068 MaxCount         : 0x00000049`42630000
   +0x070 Offset           : 0x9bf040
   +0x074 ActualCount      : 0x49
   +0x078 pfnAllocate      : 0x00007ff6`54ae1069     void*  ncalrpcClt!ILT+100(MIDL_user_allocate)+0
   +0x080 pfnFree          : 0x00007ff6`54ae1096     void  ncalrpcClt!ILT+145(MIDL_user_free)+0
   +0x088 StackTop         : (null) 
   +0x090 pPresentedType   : (null) 
   +0x098 pTransmitType    : 0x00000000`00000008  "--- memory read error at address 0x00000000`00000008 ---"
   +0x0a0 SavedHandle      : 0x00000049`009bf204 Void
   +0x0a8 StubDesc         : 0x00007ff6`54aeb490 _MIDL_STUB_DESC
   +0x0b0 FullPtrXlatTables : (null) 
   +0x0b8 FullPtrRefId     : 0
   +0x0bc PointerLength    : 0
   +0x0c0 fInDontFree      : 0y0
   +0x0c0 fDontCallFreeInst : 0y0
   +0x0c0 fInOnlyParam     : 0y0
   +0x0c0 fHasReturn       : 0y0
   +0x0c0 fHasExtensions   : 0y0
   +0x0c0 fHasNewCorrDesc  : 0y0
   +0x0c0 fIsIn            : 0y0
   +0x0c0 fIsOut           : 0y0
   +0x0c0 fIsOicf          : 0y0
   +0x0c0 fBufferValid     : 0y0
   +0x0c0 fHasMemoryValidateCallback : 0y0
   +0x0c0 fInFree          : 0y0
   +0x0c0 fNeedMCCP        : 0y0
   +0x0c0 fUnused          : 0y000
   +0x0c0 fUnused2         : 0y1010101100010110 (0xab16)
   +0x0c4 dwDestContext    : 2
   +0x0c8 pvDestContext    : (null) 
   +0x0d0 SavedContextHandles : 0x00000000`00000005  -> ???? 
   +0x0d8 ParamNumber      : 0n-1424648832
   +0x0e0 pRpcChannelBuffer : (null) 
   +0x0e8 pArrayInfo       : (null) 
   +0x0f0 SizePtrCountArray : 0x00000000`00000038  -> ??
   +0x0f8 SizePtrOffsetArray : 0x00000001`0000007f  -> ??
   +0x100 SizePtrLengthArray : 0x000001ad`ab160700  -> 0
   +0x108 pArgQueue        : 0x00000000`00000001 Void
   +0x110 dwStubPhase      : 0
   +0x118 LowStackMark     : 0x00000000`00000005 Void
   +0x120 pAsyncMsg        : (null) 
   +0x128 pCorrInfo        : (null) 
   +0x130 pCorrMemory      : (null) 
   +0x138 pMemoryList      : (null) 
   +0x140 pCSInfo          : 0x000001ad`ab160240 CS_STUB_INFO
   +0x148 ConformanceMark  : 0x00000000`00000047  "--- memory read error at address 0x00000000`00000047 ---"
   +0x150 VarianceMark     : 0x000001ad`ab140320  "???"
   +0x158 Unused           : 0n1845411184976
   +0x160 pContext         : 0x00000000`14040010 _NDR_PROC_CONTEXT
   +0x168 ContextHandleHash : 0x00000000`0000000d Void
   +0x170 pUserMarshalList : 0x00000000`50000063 Void
   +0x178 Reserved51_3     : 0n176
   +0x180 Reserved51_4     : 0n1845411185384
   +0x188 Reserved51_5     : 0n0

之后调用client_get_handle获取到handle值

 switch (pProcHeader->handle_type)
    {
    /* explicit binding: parse additional section */
    case 0:
        switch (*pFormat) /* handle_type */
        {
        case FC_BIND_PRIMITIVE: /* explicit primitive */
            {
                const NDR_EHD_PRIMITIVE *pDesc = (const NDR_EHD_PRIMITIVE *)pFormat;

                TRACE("Explicit primitive handle @ %d\n", pDesc->offset);

                if (pDesc->flag) /* pointer to binding */
                    return **(handle_t **)ARG_FROM_OFFSET(pStubMsg->StackTop, pDesc->offset);
                else
                    return *(handle_t *)ARG_FROM_OFFSET(pStubMsg->StackTop, pDesc->offset);
            }
#define ARG_FROM_OFFSET(args, offset) ((args) + (offset))

stack起始位置+偏移获取到参数地址，然后取值得到真正的参数

由于我们启用了HAS_EXTENSIONS标志位，说明我们有一个NDR_PROC_HEADER_EXTS结构体，而该结构体的ext_flag又启用了HasNewCorrDesc标志位，因此我们会进入到这段代码

       if (ext_flags.HasNewCorrDesc)
        {
            /* initialize extra correlation package */
            NdrCorrelationInitialize(stub_msg, NdrCorrCache, sizeof(NdrCorrCache), 0);
            if (ext_flags.Unused & 0x2) /* has range on conformance */
                stub_msg->CorrDespIncrement = 12;
        }

这个东西是微软对NDR标准的扩展，使得它能够支持更多的特性

但是reactos似乎并没有完全实现这个东西，他在这留了一个fixme

client_do_args

client_do_args(stub_msg, format, STUBLESS_CALCSIZE, fpu_stack,
                       number_of_params, (unsigned char *)&retval);

format结构体有好几个，当需要确定参数类型的时候，就需要用到NCALRPCInterface__MIDL_TypeFormatString

重点，TypeFormatString

 PFORMAT_STRING pTypeFormat = (PFORMAT_STRING)&pStubMsg->StubDesc->pFormatTypes[params[i].u.type_offset];

pStubMsg->StubDesc就是NdrClientCall2的第一个参数，在我们的实例中就是NCALRPCInterface_StubDesc，他是一个MIDL_STUB_DESC结构体，pFormatTypes是一个UCAHR指针，所以我们可以直接以数组的形式来对其进行索引，从而获得目标参数的类型信息

然后根据传入的phase（阶段）参数决定下一步的动作为STUBLESS_CALCSIZE，计算size，调用call_buffer_sizer

在该函数中，会根据参数类型调用不同的buffer_sizer函数

m = NdrBufferSizer[pFormat[0] & NDR_TABLE_MASK];
    if (m) m(pStubMsg, pMemory, pFormat);

0:000> dqs NdrBufferSizer l50
00007ffe`5b72efc0  00000000`00000000
00007ffe`5b72efc8  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72efd0  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72efd8  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72efe0  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72efe8  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72eff0  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72eff8  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f000  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f008  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f010  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f018  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f020  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f028  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f030  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f038  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f040  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f048  00007ffe`5b6dc1d0 aaarpcrt4!NdrPointerBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 1607]
00007ffe`5b72f050  00007ffe`5b6dc1d0 aaarpcrt4!NdrPointerBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 1607]
00007ffe`5b72f058  00007ffe`5b6dc1d0 aaarpcrt4!NdrPointerBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 1607]
00007ffe`5b72f060  00007ffe`5b6dc1d0 aaarpcrt4!NdrPointerBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 1607]
00007ffe`5b72f068  00007ffe`5b6dc580 aaarpcrt4!NdrSimpleStructBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 1802]
00007ffe`5b72f070  00007ffe`5b6dc580 aaarpcrt4!NdrSimpleStructBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 1802]
00007ffe`5b72f078  00007ffe`5b6dcfd0 aaarpcrt4!NdrConformantStructBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 4832]
00007ffe`5b72f080  00007ffe`5b6dcfd0 aaarpcrt4!NdrConformantStructBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 4832]
00007ffe`5b72f088  00007ffe`5b6ddbb0 aaarpcrt4!NdrConformantVaryingStructBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 5050]
00007ffe`5b72f090  00007ffe`5b6de9c0 aaarpcrt4!NdrComplexStructBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 3779]
00007ffe`5b72f098  00007ffe`5b6dfbe0 aaarpcrt4!NdrConformantArrayBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 3983]
00007ffe`5b72f0a0  00007ffe`5b6e0210 aaarpcrt4!NdrConformantVaryingArrayBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 4112]
00007ffe`5b72f0a8  00007ffe`5b6df490 aaarpcrt4!NdrFixedArrayBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 5272]
00007ffe`5b72f0b0  00007ffe`5b6df490 aaarpcrt4!NdrFixedArrayBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 5272]
00007ffe`5b72f0b8  00007ffe`5b6e0bd0 aaarpcrt4!NdrVaryingArrayBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 5510]
00007ffe`5b72f0c0  00007ffe`5b6e0bd0 aaarpcrt4!NdrVaryingArrayBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 5510]
00007ffe`5b72f0c8  00007ffe`5b6e18d0 aaarpcrt4!NdrComplexArrayBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 4274]
00007ffe`5b72f0d0  00007ffe`5b6e3bc0 aaarpcrt4!NdrConformantStringBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 2491]
00007ffe`5b72f0d8  00000000`00000000
00007ffe`5b72f0e0  00000000`00000000
00007ffe`5b72f0e8  00007ffe`5b6e3bc0 aaarpcrt4!NdrConformantStringBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 2491]
00007ffe`5b72f0f0  00007ffe`5b6e4430 aaarpcrt4!NdrNonConformantStringBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 2679]
00007ffe`5b72f0f8  00000000`00000000
00007ffe`5b72f100  00000000`00000000
00007ffe`5b72f108  00000000`00000000
00007ffe`5b72f110  00007ffe`5b6e20c0 aaarpcrt4!NdrEncapsulatedUnionBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6094]
00007ffe`5b72f118  00007ffe`5b6e2570 aaarpcrt4!NdrNonEncapsulatedUnionBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6279]
00007ffe`5b72f120  00007ffe`5b6da8c0 aaarpcrt4!NdrByteCountPointerBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6358]
00007ffe`5b72f128  00007ffe`5b6e28e0 aaarpcrt4!NdrXmitOrRepAsBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6411]
00007ffe`5b72f130  00007ffe`5b6e28e0 aaarpcrt4!NdrXmitOrRepAsBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6411]
00007ffe`5b72f138  00007ffe`5b6f2490 aaarpcrt4!NdrInterfacePointerBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_ole.c @ 376]
00007ffe`5b72f140  00007ffe`5b6da010 aaarpcrt4!NdrContextHandleBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6964]
00007ffe`5b72f148  00000000`00000000
00007ffe`5b72f150  00000000`00000000
00007ffe`5b72f158  00000000`00000000
00007ffe`5b72f160  00007ffe`5b6e3370 aaarpcrt4!NdrUserMarshalBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 4505]
00007ffe`5b72f168  00000000`00000000
00007ffe`5b72f170  00000000`00000000
00007ffe`5b72f178  00007ffe`5b6da480 aaarpcrt4!NdrRangeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6565]
00007ffe`5b72f180  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]
00007ffe`5b72f188  00007ffe`5b6d95d0 aaarpcrt4!NdrBaseTypeBufferSize [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 6815]

pMemory此时就是我们的第一个参数，hello字符串，我们此时的类型值为0x22（FC_C_CSTRING），对应的sizer函数是NdrConformantStringBufferSize

计算方式其实就是strlen+1，结果存储到pStubMsg->ActualCount

  case FC_C_CSTRING:
  case FC_C_WSTRING:
    if (fc == FC_C_CSTRING)
    {
      TRACE("string=%s\n", debugstr_a((const char *)pMemory));
      pStubMsg->ActualCount = strlen((const char *)pMemory)+1;
    }

但是这个并不是最终的buffer_len，因为还要考虑对齐的问题，SizeConformance函数会进行对齐处理

static inline void SizeConformance(MIDL_STUB_MESSAGE *pStubMsg)
{
    align_length(&pStubMsg->BufferLength, 4);
    if (pStubMsg->BufferLength + 4 < pStubMsg->BufferLength)
        RpcRaiseException(RPC_X_BAD_STUB_DATA);
    pStubMsg->BufferLength += 4;
}

align_length：

*len = (*len + align - 1) & ~(align - 1);

人家这代码写的就是简洁高效，他等效于下面这个函数

if(*len%align) *len=(*len+align)-(*len+align)%align

但是明显第二种写法要进行更多次运算，而第一种写法采用位运算，要高效的多

通过位运算进行对齐操作是非常常规的写法

但是他这个对齐并不是针对ActualCount字段进行的对齐，有点奇怪哈，bufferlength字段本来就是0，对齐之后还是0，最后加了个4变成4了

后面有对bufferlen进行了一些操作，最后和actualcount加在了一起，然后这个结果也没对齐，不知道为啥，最后的长度值是0x21

然后就是第二个参数，第二个参数是传出参数，不需要计算size

NdrGetBuffer

NdrGetBuffer(stub_msg, stub_msg->BufferLength, hbinding);

hbinding被赋值给stubmsg->RpcMsg->Handle，根据前面计算出来的bufferlen分配内存，然后调用I_RpcNegotiateTransferSyntax

但是他这个buffer分配完内存之后并没有初始化

之后就是调用I_RpcNegotiateTransferSyntax协商通信语法

该函数会调用RPCRT4_OpenBinding，该函数又会调用RpcAssoc_GetClientConnection

return RpcAssoc_GetClientConnection(Binding->Assoc, InterfaceId,
         TransferSyntax, Binding->AuthInfo, Binding->QOS, Binding->CookieAuth, Connection, from_cache);

第一个参数是RpcAssoc结构体，里面存有endpoint信息

0:000> dt RpcAssoc 000001c68bf21560
aaarpcrt4!RpcAssoc
   +0x000 entry            : list
   +0x010 refs             : 0n1
   +0x018 Protseq          : 0x000001c6`8bf21630  "ncalrpc"
   +0x020 NetworkAddr      : 0x000001c6`8bf22700  ""
   +0x028 Endpoint         : 0x000001c6`8bf20fb0  "NCALRPCServer12138"
   +0x030 NetworkOptions   : (null) 
   +0x038 assoc_group_id   : 0
   +0x03c http_uuid        : _GUID {a1df7372-ff69-43ef-94f0-fa2e73cf954c}
   +0x050 cs               : _RTL_CRITICAL_SECTION
   +0x078 free_connection_pool : list
   +0x088 connection_cnt   : 0n0
   +0x090 context_handle_list : list

RpcConnection对象应该就是用来存储即将被创建出来的连接信息的，目前他里面保存的信息是没有什么意义的

最后调用RPCRT4_CreateConnection来创建连接

首先调用rpcrt4_get_conn_protseq_ops返回对应的connection_ops对象，用于对连接进行各种操作

0:000> dt connection_ops 00007ffe5b7356f8
aaarpcrt4!connection_ops
   +0x000 name             : 0x00007ffe`5b733468  "ncalrpc"
   +0x008 epm_protocols    : [2]  "???"
   +0x010 alloc            : 0x00007ffe`5b711790     _RpcConnection*  aaarpcrt4!rpcrt4_conn_np_alloc+0
   +0x018 open_connection_client : 0x00007ffe`5b7117d0     long  aaarpcrt4!rpcrt4_ncalrpc_open+0
   +0x020 handoff          : 0x00007ffe`5b711d60     long  aaarpcrt4!rpcrt4_ncalrpc_handoff+0
   +0x028 read             : 0x00007ffe`5b711ea0     int  aaarpcrt4!rpcrt4_conn_np_read+0
   +0x030 write            : 0x00007ffe`5b712000     int  aaarpcrt4!rpcrt4_conn_np_write+0
   +0x038 close            : 0x00007ffe`5b712120     int  aaarpcrt4!rpcrt4_conn_np_close+0
   +0x040 close_read       : 0x00007ffe`5b7121f0     void  aaarpcrt4!rpcrt4_conn_np_close_read+0
   +0x048 cancel_call      : 0x00007ffe`5b712240     void  aaarpcrt4!rpcrt4_conn_np_cancel_call+0
   +0x050 is_server_listening : 0x00007ffe`5b711d20     long  aaarpcrt4!rpcrt4_ncalrpc_np_is_server_listening+0
   +0x058 wait_for_incoming_data : 0x00007ffe`5b712280     int  aaarpcrt4!rpcrt4_conn_np_wait_for_incoming_data+0
   +0x060 get_top_of_tower : 0x00007ffe`5b7131e0     unsigned int64  aaarpcrt4!rpcrt4_ncalrpc_get_top_of_tower+0
   +0x068 parse_top_of_tower : 0x00007ffe`5b7132a0     long  aaarpcrt4!rpcrt4_ncalrpc_parse_top_of_tower+0
   +0x070 receive_fragment : (null) 
   +0x078 is_authorized    : 0x00007ffe`5b7133e0     int  aaarpcrt4!rpcrt4_ncalrpc_is_authorized+0
   +0x080 authorize        : 0x00007ffe`5b7133f0     long  aaarpcrt4!rpcrt4_ncalrpc_authorize+0
   +0x088 secure_packet    : 0x00007ffe`5b713420     long  aaarpcrt4!rpcrt4_ncalrpc_secure_packet+0
   +0x090 impersonate_client : 0x00007ffe`5b7126d0     long  aaarpcrt4!rpcrt4_conn_np_impersonate_client+0
   +0x098 revert_to_self   : 0x00007ffe`5b712810     long  aaarpcrt4!rpcrt4_conn_np_revert_to_self+0
   +0x0a0 inquire_auth_client : 0x00007ffe`5b713440     long  aaarpcrt4!rpcrt4_ncalrpc_inquire_auth_client+0

这个函数就是创建一个初始化的连接对象，此时还没有真正发起连接

然后作为唯一的一个参数调用RPCRT4_OpenClientConnection函数

在该函数中会调用上面根据协议序列所引到的connection_ops对象的成员函数open_connection_client来建立连接，该函数为动态注册，实际调用的是rpcrt4_ncalrpc_open

首先根据endpoint拼接出pipename

\\.\pipe\lrpc\NCALRPCServer12138

然后调用rpcrt4_conn_open_pipe打开管道

核心其实就是

pipe = CreateFileA(pname, GENERIC_READ|GENERIC_WRITE, 0, NULL,
                       OPEN_EXISTING, dwFlags | FILE_FLAG_OVERLAPPED, 0);

启用了overlapped，表明后续的读写操作都将以异步的形式进行

dwMode = PIPE_READMODE_MESSAGE;
  SetNamedPipeHandleState(pipe, &dwMode, NULL, NULL);

这段代码至关重要，他告诉windows的npdriver管道中的数据将以消息流的形式进行传递，而非字节流，一般用于基于命名管道的RPC实现中

然后就是调用RPCRT4_BuildBindHeader构建一个bind请求头，然后使用RPCRT4_Send发送数据包

之后使用RPCRT4_ReceiveWithAuth接收来自服务端的响应数据包，实际调用的函数是RPCRT4_default_receive_fragment，这个过程和服务端是一样的，在这个函数中我们会从管道中读取数据，解析头部，解析数据

call_marshaller

参数的序列化，和前面的buffersizer一样，marshaller也是一个全局数组，根据pformat选定不懂的marshaller函数

在我们一开始的NdrClientCall2的第二个参数中指定了参数类型相对于pFormat指针的偏移量，使用这个偏移量计算出一个地址，取出来bytes值作为marshaller数组的索引来得到对应的marshaller函数

我们szString对应的marshaller就是NdrConformantStringMarshall

那我们来看一下他是如何序列化我们的字符串"Hello Context World!"的

有点像服务端的sizer函数

array_compute_and_write_conformance(FC_C_CSTRING, pStubMsg, pszMessage,
                                      pFormat, TRUE /* fHasPointers */);

array_compute_and_write_conformance函数上来就是switch-case，根据a1确定类型，对于FC_C_CSTRING类型

pStubMsg->ActualCount = strlen((const char *)pMemory)+1;

使用字符串长度+1来填充stubMsg的actualCount字段

我们上面得到的类型指针，紧跟着的下一个字节也是有特定的意义的

此处我们是0x5C，FC_PAD，无需做特殊处理，stubMsg的MaxCount字段直接就设置为ActualCount字段的值

之后调用WriteConformance(pStubMsg);

static inline void WriteConformance(MIDL_STUB_MESSAGE *pStubMsg)
{
    align_pointer_clear(&pStubMsg->Buffer, 4);
    if (pStubMsg->Buffer + 4 > (unsigned char *)pStubMsg->RpcMsg->Buffer + pStubMsg->BufferLength)
        RpcRaiseException(RPC_X_BAD_STUB_DATA);
    NDR_LOCAL_UINT32_WRITE(pStubMsg->Buffer, pStubMsg->MaxCount);
    pStubMsg->Buffer += 4;
}

对该函数的代码进行理解

地址对齐

static inline void align_pointer_clear( unsigned char **ptr, unsigned int align )
{
    ULONG_PTR mask = align - 1;
    memset( *ptr, 0, (align - (ULONG_PTR)*ptr) & mask );
    *ptr = (unsigned char *)(((ULONG_PTR)*ptr + mask) & ~mask);
}

我直接让chatgpt解释了一下这段代码的作用，说白了这个函数就是把指针向前移动到alignment的倍数的位置，被跳过的地址将会被清0

比如说现在buffer的地址是0x1002，对齐为4，那么经过这个函数的处理，buffer地址会变成0x1004，0x1002\0x1003这两个地址会被清空为0

pStubMsg->Buffer和pStubMsg->RpcMsg->Buffer是同一个东西

NDR_LOCAL_UINT32_WRITE就是以小端序列写入一个UINT32数据，这里是把MaxCount字段写入了buffer中

所谓小端就是低位在前

写入了UINT32，即一个DWORD，buffer要向前移动4

然后是array_write_variance_and_marshall，上面的array_write_variance_and_marshall只写入了一个MaxCount，并未写入我们的hello字符串

首先调用WriteVariance(pStubMsg);

这个函数中的单词Variance并非其字面意义（统计学上的方差），而是NDR标准中的一个术语，特指一个数组或者字符串中的可变部分，即偏移量或者长度这种字段，因此从函数名中我们就可以知道，这个函数大概率是用来写入我的hello字符串长度的

这时再来看这个函数的内容

static inline void WriteVariance(MIDL_STUB_MESSAGE *pStubMsg)
{
    align_pointer_clear(&pStubMsg->Buffer, 4);
    if (pStubMsg->Buffer + 8 > (unsigned char *)pStubMsg->RpcMsg->Buffer + pStubMsg->BufferLength)
        RpcRaiseException(RPC_X_BAD_STUB_DATA);
    NDR_LOCAL_UINT32_WRITE(pStubMsg->Buffer, pStubMsg->Offset);
    pStubMsg->Buffer += 4;
    NDR_LOCAL_UINT32_WRITE(pStubMsg->Buffer, pStubMsg->ActualCount);
    pStubMsg->Buffer += 4;
}

他写入了hello字符串的在buffer中的offset和字符串的长度+1，这两个字段共占用8bytes

然后调用safe_multiply(esize, pStubMsg->ActualCount);，其中esize变量根据我们的参数类型决定，宽字节（FC_C_WSTRING）是2，ascii字符串（FC_C_CSTRING）就是1

之后调用safe_copy_to_buffer进行hello字符串到stubMsg的拷贝操作

memcpy(pStubMsg->Buffer, p, size);

这就是到目前为止pstubmsg的buffer的内容

0:000> db 0001d4`586beac1-15-8-4
000001d4`586beaa0  15 00 00 00 00 00 00 00-15 00 00 00 48 65 6c 6c  ............Hell
000001d4`586beab0  6f 20 43 6f 6e 74 65 78-74 20 57 6f 72 6c 64 21  o Context World!

字符串长度+1（DWORD）

字符串相body部分的偏移（DWORD）

字符串长度+1（DWORD）

字符串内容

处理context handle参数

这个参数和上面的字符串不一样，在我们调用NdrClientCall的时候我们传进来的是一个地址，用于接收服务端给我们分配的contexthandle，也就是说这个参数本质上是一个传出参数

从实际调试结果来看，并未作任何处理

NdrSendReceive

好，现在客户端把Open函数转换成数据包并通过命名管道发送给了服务端，那么我们现在就回去调试服务端的代码

现在来看一下客户端的context_handle和guid是如何关联的，在客户端使用contexthandle时，最终会到达NDRCContextMarshall函数，该函数的第一个参数就是我们在一开始的open函数中获取到的handle_context传出参数，他其实是一个context_handle_entry类型的结构体，这一点在函数

get_context_entry可以得到验证

现在我要看一下这个GUID是如何存储到我们的context handle里面去的，context handle写入调用栈

0:000> k
 # Child-SP          RetAddr               Call Site
00 000000e9`bbafddc0 00007ffc`5a795939     aaarpcrt4!ndr_update_context_handle+0x14e [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_contexthandle.c @ 200] 
01 000000e9`bbafde10 00007ffc`5a7a9e1b     aaarpcrt4!NDRCContextUnmarshall+0x69 [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_contexthandle.c @ 216] 
02 000000e9`bbafde60 00007ffc`5a79a2ea     aaarpcrt4!NdrClientContextUnmarshall+0x8b [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 7098] 
03 000000e9`bbafde90 00007ffc`5a7b55b0     aaarpcrt4!NdrContextHandleUnmarshall+0x1ba [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_marshall.c @ 7040] 
04 000000e9`bbafdef0 00007ffc`5a7b5a2c     aaarpcrt4!call_unmarshaller+0xf0 [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 126] 
05 000000e9`bbafdf50 00007ffc`5a7b800d     aaarpcrt4!client_do_args+0x3ac [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 531] 
06 000000e9`bbafdfc0 00007ffc`5a7b89ae     aaarpcrt4!do_ndr_client_call+0x7ad [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 842] 
07 000000e9`bbafe8d0 00007ffc`5a7e94ff     aaarpcrt4!ndr_client_call+0x71e [c:\users\x\downloads\reactos-master\dll\win32\rpcrt4\ndr_stubless.c @ 994] 
08 000000e9`bbaff150 00007ff7`e9c125f0     aaarpcrt4!NdrClientCall2+0x1b [C:\Users\x\Downloads\reactos-master\output-VS-amd64-sln\dll\win32\rpcrt4\asm\msvc_rpcrt4_asm.asm @ 602] 
09 000000e9`bbaff180 00007ff7`e9c121bb     ncalrpcClt!Open+0x80 [c:\users\x\downloads\reactos_rpcrt4_test_code\ncalrpcclt\ncalrpcinterface_clntstub.c @ 164] 
0a 000000e9`bbaff290 00007ff7`e9c131a4     ncalrpcClt!wmain+0x29b [c:\users\x\downloads\reactos_rpcrt4_test_code\ncalrpcclt\ncalrpcclt.c @ 159] 
0b 000000e9`bbaff850 00007ff7`e9c1304e     ncalrpcClt!invoke_main+0x34 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 91] 
0c 000000e9`bbaff890 00007ff7`e9c12f0e     ncalrpcClt!__scrt_common_main_seh+0x12e [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0d 000000e9`bbaff900 00007ff7`e9c13239     ncalrpcClt!__scrt_common_main+0xe [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 331] 
0e 000000e9`bbaff930 00007ffc`96b47374     ncalrpcClt!wmainCRTStartup+0x9 [d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_wmain.cpp @ 17] 
0f 000000e9`bbaff960 00007ffc`9867cc91     KERNEL32!BaseThreadInitThunk+0x14
10 000000e9`bbaff990 00000000`00000000     ntdll!RtlUserThreadStart+0x21

根据调用栈回溯可知，context handle里面的wire data的guid来自于prcmsg->buffer，就是server端分配好之后给我们发送过来的

逆向tips

procnum

客户端发起调用的时候最终肯定会调用NdrClientCall，该函数的第二个参数是一个地址，这个地址+6取word就是procnum

其实这个参数可以解释为NDR_PROC_HEADER结构体

aaarpcrt4!_NDR_PROC_HEADER_RPC
   +0x000 handle_type      : UChar
   +0x001 Oi_flags         : UChar
   +0x002 rpc_flags        : Uint4B
   +0x006 proc_num         : Uint2B
   +0x008 stack_size       : Uint2B

总结

看rpcrt4的源码，我就只想弄清楚一件事，就是服务端是如何识别context handle的，得出的结论如下：

客户端发送context handle创建请求，服务端分配一个用于标识context handle的guid返回给客户端，客户端将这个guid存储到context handle中
下一次使用context handle发起请求时，会将context handle中存储的guid发送过去，服务端根据guid定位到相应客户端的context handle

另外一点需要提的就是，使用explicit binding handle是没有办法在server端标识client的，他不像context handle一样，客户端和服务端共享一个guid标识符，binding handle对服务端来说只是用于标识一个连接，至于这个连接是哪一个客户端在使用，他是不清楚的，因为server端的hbinding和客户端的hbinding之间不存在映射关系

非要说的话那也只能是在RPCRT4_MakeBinding函数中通过对比客户端发送过来的数据包来确认当前产生的binding是否为目标客户端的，但是这个数据包对比实战的时候不太现实

PE壳--upx

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

cfg如何工作

reference：

在阅读upx源码的时候发现默认不支持开启了cfg的pe文件，比如尝试给notepad.exe加壳就会出现报错

看一下cfg是如何实现的

cfg可以在vs的编译选项中开启

这里有一个使用了间接调用的示例代码

开启cfg

关闭cfg

开启了cfg的pe相比关闭cfg的pe中会多出来这些东西

开启cfg

关闭cfg

这里面有如下三个关键部分

cfg check function pointer，指向一个空函数
cfg function table，内核会用到这个数据
cfg flag

check function pointer你在ida或者pebear中看他是一个空函数，但是它实际上会在pe加载的时候由LdrpCfgProcessLoadConfig函数设置为下面这个函数

不过我们实际测试的话，发现并没有直接调用check function pointer，而是调用的__guard_dispatch_icall_fptr

0:000> dqs test+0020280 l100007ff6`4bd40280  00007ffb`79f1cd00 ntdll!LdrpDispatchUserCallTarget

其实check（LdrpValidateUserCallTarget）函数和dispatch（LdrpDispatchUserCallTarget）函数的实际代码是一样的

module tamper protection

references：

https://windows-internals.com/understanding-a-new-mitigation-module-tampering-protection/

这个东西可以预防process hollowing技术

在eprocess中可以看到这个标志位

1: kd> dx @$curprocess.KernelObject.MitigationFlagsValues 
@$curprocess.KernelObject.MitigationFlagsValues                  [Type: <unnamed-tag>]
    [+0x000 ( 0: 0)] ControlFlowGuardEnabled : 0x1 [Type: unsigned long]
    [+0x000 ( 1: 1)] ControlFlowGuardExportSuppressionEnabled : 0x0 [Type: unsigned long]
    [+0x000 ( 2: 2)] ControlFlowGuardStrict : 0x0 [Type: unsigned long]
    [+0x000 ( 3: 3)] DisallowStrippedImages : 0x0 [Type: unsigned long]
    [+0x000 ( 4: 4)] ForceRelocateImages : 0x0 [Type: unsigned long]
    [+0x000 ( 5: 5)] HighEntropyASLREnabled : 0x1 [Type: unsigned long]
    [+0x000 ( 6: 6)] StackRandomizationDisabled : 0x0 [Type: unsigned long]
    [+0x000 ( 7: 7)] ExtensionPointDisable : 0x0 [Type: unsigned long]
    [+0x000 ( 8: 8)] DisableDynamicCode : 0x0 [Type: unsigned long]
    [+0x000 ( 9: 9)] DisableDynamicCodeAllowOptOut : 0x0 [Type: unsigned long]
    [+0x000 (10:10)] DisableDynamicCodeAllowRemoteDowngrade : 0x0 [Type: unsigned long]
    [+0x000 (11:11)] AuditDisableDynamicCode : 0x0 [Type: unsigned long]
    [+0x000 (12:12)] DisallowWin32kSystemCalls : 0x0 [Type: unsigned long]
    [+0x000 (13:13)] AuditDisallowWin32kSystemCalls : 0x0 [Type: unsigned long]
    [+0x000 (14:14)] EnableFilteredWin32kAPIs : 0x0 [Type: unsigned long]
    [+0x000 (15:15)] AuditFilteredWin32kAPIs : 0x0 [Type: unsigned long]
    [+0x000 (16:16)] DisableNonSystemFonts : 0x0 [Type: unsigned long]
    [+0x000 (17:17)] AuditNonSystemFontLoading : 0x0 [Type: unsigned long]
    [+0x000 (18:18)] PreferSystem32Images : 0x0 [Type: unsigned long]
    [+0x000 (19:19)] ProhibitRemoteImageMap : 0x0 [Type: unsigned long]
    [+0x000 (20:20)] AuditProhibitRemoteImageMap : 0x0 [Type: unsigned long]
    [+0x000 (21:21)] ProhibitLowILImageMap : 0x0 [Type: unsigned long]
    [+0x000 (22:22)] AuditProhibitLowILImageMap : 0x0 [Type: unsigned long]
    [+0x000 (23:23)] SignatureMitigationOptIn : 0x0 [Type: unsigned long]
    [+0x000 (24:24)] AuditBlockNonMicrosoftBinaries : 0x0 [Type: unsigned long]
    [+0x000 (25:25)] AuditBlockNonMicrosoftBinariesAllowStore : 0x0 [Type: unsigned long]
    [+0x000 (26:26)] LoaderIntegrityContinuityEnabled : 0x0 [Type: unsigned long]
    [+0x000 (27:27)] AuditLoaderIntegrityContinuity : 0x0 [Type: unsigned long]
    [+0x000 (28:28)] EnableModuleTamperingProtection : 0x0 [Type: unsigned long]
    [+0x000 (29:29)] EnableModuleTamperingProtectionNoInherit : 0x0 [Type: unsigned long]
    [+0x000 (30:30)] RestrictIndirectBranchPrediction : 0x1 [Type: unsigned long]
    [+0x000 (31:31)] IsolateSecurityDomain : 0x0 [Type: unsigned long]

28和29bit

在nt内核的PspApplyMitigationOptions函数中设置这两个标志位

这两个bit的检查位置在ntdll的LdrpGetImportDescriptorForSnap函数中

就是在这里检查的

需要设置一下这个内存位置的类型，它实际上是_PS_SYSTEM_DLL_INIT_BLOCK结构体，这个符号可以在combase.dll中找到

0:000> dt _PS_SYSTEM_DLL_INIT_BLOCK 
combase!_PS_SYSTEM_DLL_INIT_BLOCK
   +0x000 Size             : Uint4B
   +0x008 SystemDllWowRelocation : Uint8B
   +0x010 SystemDllNativeRelocation : Uint8B
   +0x018 Wow64SharedInformation : [16] Uint8B
   +0x098 RngData          : Uint4B
   +0x09c Flags            : Uint4B
   +0x09c CfgOverride      : Pos 0, 1 Bit
   +0x09c Reserved         : Pos 1, 31 Bits
   +0x0a0 MitigationOptionsMap : _PS_MITIGATION_OPTIONS_MAP
   +0x0b8 CfgBitMap        : Uint8B
   +0x0c0 CfgBitMapSize    : Uint8B
   +0x0c8 Wow64CfgBitMap   : Uint8B
   +0x0d0 Wow64CfgBitMapSize : Uint8B
   +0x0d8 MitigationAuditOptionsMap : _PS_MITIGATION_AUDIT_OPTIONS_MAP

我们把这个内容保存成头文件，然后加载到ntdll的ida项目中

struct _PS_MITIGATION_OPTIONS_MAP
{
  unsigned __int64 Map[3];
};
typedef _PS_MITIGATION_OPTIONS_MAP *PPS_MITIGATION_OPTIONS_MAP;
struct _PS_MITIGATION_AUDIT_OPTIONS_MAP
{
  unsigned __int64 Map[3];
};
typedef _PS_MITIGATION_AUDIT_OPTIONS_MAP *PPS_MITIGATION_AUDIT_OPTIONS_MAP;
struct _PS_SYSTEM_DLL_INIT_BLOCK
{
  unsigned int Size;
  unsigned __int64 SystemDllWowRelocation;
  unsigned __int64 SystemDllNativeRelocation;
  unsigned __int64 Wow64SharedInformation[16];
  unsigned int RngData;
   unsigned int ___u5;
  _PS_MITIGATION_OPTIONS_MAP MitigationOptionsMap;
  unsigned __int64 CfgBitMap;
  unsigned __int64 CfgBitMapSize;
  unsigned __int64 Wow64CfgBitMap;
  unsigned __int64 Wow64CfgBitMapSize;
  _PS_MITIGATION_AUDIT_OPTIONS_MAP MitigationAuditOptionsMap;
};
typedef const _PS_SYSTEM_DLL_INIT_BLOCK *PCPS_SYSTEM_DLL_INIT_BLOCK;

然后直接ctrl+G输入LdrSystemDllInitBlock跳转过去，设置类型为_PS_SYSTEM_DLL_INIT_BLOCK

然后在伪代码中选中qword_18019b3b8按y再回车即可

MitigationOptionsMap就是一个包含3个8bytes的结构体而已，每个8bytes存储着不同的mitigation相关的一些flag

这里的>>44 & 3检查的就是PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK标志位

WinBase.h中定义了这个flag

#define PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK              (0x00000003ui64 << 12)

这个东西在bitmap[1]的高dword上，所以实际上是12+32=44bit，因此上面右移44bit很合理

原作者说在createprocess指定PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK就可以，但是我实际测试发现并没有生效

我只能手动从nt内核给他开启

windwos自带的会开启这个选项的是C:\Windows\System32\SystemSettingsAdminFlows.exe，犹appinfo服务创建，他这个选项是在PspInheritMitigationOptions的下面这个位置开启的

1: kd> k
 # Child-SP          RetAddr               Call Site
00 ffffe08e`a5253a10 fffff803`71501b23     nt!PspInheritMitigationOptions+0xb3
01 ffffe08e`a5253a80 fffff803`71504348     nt!PspAllocateProcess+0x16d7
02 ffffe08e`a52542b0 fffff803`712274e5     nt!NtCreateUserProcess+0x778
03 ffffe08e`a5254a70 00007fff`e78d0dc4     nt!KiSystemServiceCopyEnd+0x25

我让chatgpt分析了一下PspInheritMitigationOptions函数，它其实就是把前两个参数整合到第三个参数里面

前两个都是mitigationmap结构体，也就是长度为3的8bytes数组

经过回溯可以知道mitigation选项来自于ntcreateuserprocess的第11个参数

经过一番探索，最终知道这个mitigation是通过ntcreateuserprocess的a11 PS_ATTRIBUTE_LIST传进来的

通过在PspBuildCreateProcessContext函数par @$ra可以知道是在PS_ATTRIBUTE结构体的Attribute字段为0000000000020010 的时候终止循环的

结合内存值我们就可以确定20010就是mitigation属性，长度为18，实际上就是_PS_MITIGATION_OPTIONS_MAP

那么现在我们就来看一下这个属性是如何构造出来的

referecen:

https://drunkmars.top/2022/05/14/NtCreateUserProcess/

使用这个代码可以创建出开启了tamper保护的进程

其实就是手动构造PPS_ATTRIBUTE_LIST

然后还有一点需要注意的就是，我在测试过程中发现这个注册表路径会在PspAllocateProcess函数的这个地方被检查

我们测试的时候，尽量不要使用出现这里面的二进制程序

下面我们要测试一下这个mitigation是怎么跑到用户模式的那个_PS_SYSTEM_DLL_INIT_BLOCK里面的

LdrSystemDllInitBlock的初始化

references ：

https://bbs.kanxue.com/thread-267302-1.htm

这个东西是在内核的PspSetupUserProcessAddressSpace函数中通过调用PspPrepareSystemDllInitBlock来初始化的

在调用PspPrepareSystemDllInitBlock函数之前，会先切换到目标进程的空间中

在这个函数中，poi(PsNtdllExports)就是ntdll的base

然后我们的tamper在用户模式检查的时候出现在相对于LdrSystemDllInitBlock 0xa8的位置，这里是oword操作，直接包含了

v15来自于

这个就是前面创建进程时PspBuildCreateProcessContext函数的第四个参数，0x150偏移就是mitigation map

这样就完成了对LdrSystemDllInitBlock的初始化

tamper protection的检查

现在我们再来看一下这个东西是怎么检查的

我测来测去，发现这个mitigation根本就没有用，process hollowing还是可以正常工作的

IOCTL Fuzzer

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

references:

https://github.com/koutto/ioctlbf

在代码中我们可以看到他是这样获取ioctl的起始和终止范围的：

beginIoctl = (DWORD)parseHex(singleIoctl) & 0xffffc000;
endIoctl = ((DWORD)parseHex(singleIoctl) & 0xffffc000) | 0x00003fff;

那他为什么这样写呢，这就和ioctl的编码方式有关了

Bits	Field	Meaning
31–16	DeviceType	Type of device
15–14	Access	Required access (read, write, etc.)
13–2	Function	Function code (custom or system)
1–0	Method	Transfer method (buffered, direct, etc)

可以看到从14bit开始就是不会变化的东西了，他们是devicetype和access，这个我们不用管，我们只用爆破低14bit即可，0xffffc000就是低14bit为0的一个值，和他进行与操作就可以把低14bit置0，就得到了起始地址，终止地址就是把低14bit置1，即0x3fff

其实这个ioctl fuzz的原理非常简单，就是确定一个起始和终止范围，然后循环测试每一个iocode，得到每一个iocode对应的input buffer的最小和最大长度，因为deviceiocontrol函数会在正常的时候返回非0值，我们只需要循环测试每一个输入buffer长度并检测返回值即可

注意

并不是所有的驱动都会在失败的时候返回0，存在一些驱动，不管在什么情况下返回的status都不为0

ioctlfuzzer会在filteralwaysok选项开启的时候过滤掉这些iocode，过滤原理就是下面这个循环

for (j = 0; j < 4 && status != 0 && cont; j++) {
                status = DeviceIoControl(deviceHandle,
                    currentIoctl,
                    &bufInput,
                    j,
                    &bufOutput,
                    j,
                    &nbBytes,
                    NULL);

                /*
                if(status == 0)
                    printf("0x%08x (size %d) -> error code %03d \n", currentIoctl, j, GetLastError());
                else
                    printf("0x%08x (size %d) -> status != 0 \n", currentIoctl, j);
                */

}
if (j == 4) {
                //printf("Skip 0x%08x\n", currentIoctl);
                continue;
}

他循环5次，这5次循环中，inputlength依次为0~5，如果5次全部都不为0，说明这个驱动在任何条件下都会返回status！=0

此时就跳过对该IOCODE的input length的测试，我在这个地方添加了一个pause指令，以便引起我的注意，我需要调试看一下，下一步会产生何种反应

另外一点就是，原版的fuzz代码会在fuzz开始前要求我们去指定一个iocode，但是我给他改成直接就从起始范围开始测，如果崩溃了，我们就去调试器分析即可

项目文件

密码是1

Windows Kernel Structure

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

Lookaside Lists

this structure is used for optimization, when fixed-size allocations are needed

we all know that allocate and free memory is expensive, so for this kind of fixed-size allocation, we just don't really free the memory we allocated, we just mark it as available

so when the next time a same size memory is requested to be allocated, we just return this memory block instead of allocating a new fresh memory

this is the purpose of lookaside lists

to use this structure, you need to call windows API to initialize it

NTSTATUS ExInitializeLookasideListEx(
  [out]          PLOOKASIDE_LIST_EX    Lookaside,
  [in, optional] PALLOCATE_FUNCTION_EX Allocate,
  [in, optional] PFREE_FUNCTION_EX     Free,
  [in]           POOL_TYPE             PoolType,
  [in]           ULONG                 Flags,
  [in]           SIZE_T                Size,
  [in]           ULONG                 Tag,
  [in]           USHORT                Depth
);

after that, you can call this API to get a memory block who will have the size and tag you specified in initialization function:

PVOID ExAllocateFromPagedLookasideList(
  [in, out] PPAGED_LOOKASIDE_LIST Lookaside
);

free with this API:

void ExFreeToPagedLookasideList(
  [in, out] PPAGED_LOOKASIDE_LIST Lookaside,
  [in]      PVOID                 Entry
);

destroy lookaside lists with this API:

void ExDeletePagedLookasideList(
  [in, out] PPAGED_LOOKASIDE_LIST Lookaside
);

在命名管道上实现异步IO

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

references：

Named Pipes

基本概念

命名管道的实例

所谓命名管道是一个存在于server和client之间的一个单工/双工通信管道，一个命名管道可以拥有多个实例，这些实例共享同一个管道名称，但是却拥有各自的handle和buffer，并为server/client提供分离的通信管道

如下图所示，该进程中有4个具有相同名称不同句柄的命名管道实例

Windows MiniFilter

2024-05-13T00:00:00+02:00

references：

https://www.apriorit.com/dev-blog/675-driver-windows-minifilter-driver-development-tutorial

前面讲到的windows文件系统过滤驱动代码比较多，而且容易出错，所以微软推出了minifilter框架，来让开发者更专注于业务逻辑，一些重复性的繁杂的代码都整合到了框架中

我们在WPP修改过的FsFilter项目代码上进行修改

另外需要注意的是，MiniFilter项目需要使用C++进行编写，因此文件名需要更改为.cpp

代码编写

之前用的全局变量是g_fsFilterDriverObject，现在我们需要改成MiniFilter句柄

PFLT_FILTER g_minifilterHandle = NULL;

然后需要在DriverEntry函数中注册MiniFilter

NTSTATUS status = FltRegisterFilter(DriverObject, &g_filterRegistration, &g_minifilterHandle);
if (!NT_SUCCESS(status)) 
    return status;

然后启动MiniFilter来拦截IO请求

status = FltStartFiltering(g_minifilterHandle);
if (!NT_SUCCESS(status)) 
    FltUnregisterFilter(g_minifilterHandle);

上面调用FltRegisterFilter注册MiniFilter的时候使用了一个未定义的变量g_filterRegistration这是另一个全局变量，是一个FLT_REGISTRATION结构体

CONST FLT_REGISTRATION g_filterRegistration =
{
    sizeof(FLT_REGISTRATION),      //  Size
    FLT_REGISTRATION_VERSION,      //  Version
    0,                             //  Flags
    NULL,                          //  Context registration
    g_callbacks,                   //  Operation callbacks
    InstanceFilterUnloadCallback,  //  FilterUnload
    InstanceSetupCallback,         //  InstanceSetup
    InstanceQueryTeardownCallback, //  InstanceQueryTeardown
    NULL,                          //  InstanceTeardownStart
    NULL,                          //  InstanceTeardownComplete
    NULL,                          //  GenerateFileName
    NULL,                          //  GenerateDestinationFileName
    NULL                           //  NormalizeNameComponent
};

g_callbacks字段为FLT_OPERATION_REGISTRATION结构体，该结构体描述了针对捕获的IO操作的pre-operation和post-operation

我们这里只写一个pre-operation

CONST FLT_OPERATION_REGISTRATION g_callbacks[] =
{
    {
        IRP_MJ_CREATE,
        0,
        PreOperationCreate,
        0
    },

    { IRP_MJ_OPERATION_END }
};

新建一个文件FsMinifilter.cpp

该文件中将会包含回调函数的定义

MiniFilter中的pre和post opertaion的概念就相当于我们之前写的传统fsfilter中的dispatch和completion例程

我们需要针对IRP_MJ_CREATE操作定义一个pre-operation来输出文件名

FLT_PREOP_CALLBACK_STATUS FLTAPI PreOperationCreate(
    _Inout_ PFLT_CALLBACK_DATA Data,
    _In_ PCFLT_RELATED_OBJECTS FltObjects,
    _Flt_CompletionContext_Outptr_ PVOID* CompletionContext
)
{
    //
    // Pre-create callback to get file info during creation or opening
    //

    DbgPrint("%wZ\n", &Data->Iopb->TargetFileObject->FileName);

    return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

下一步需要实现InstanceFilterUnloadCallback函数，这个会在卸载MiniFilter的时候用到，我们在这个函数中调用FltUnregisterFilter函数来注销MiniFilter

还有另外两个函数InstanceSetupCallback和InstanceQuertTeardownCallback需要定义，这两个函数会在我们的minifilter连接磁盘分区或者和磁盘分区断开连接的时候被用到

这两个函数只是个stub，里面没有实际的代码，只有一个返回语句

NTSTATUS FLTAPI InstanceSetupCallback(
    _In_ PCFLT_RELATED_OBJECTS  FltObjects,
    _In_ FLT_INSTANCE_SETUP_FLAGS  Flags,
    _In_ DEVICE_TYPE  VolumeDeviceType,
    _In_ FLT_FILESYSTEM_TYPE  VolumeFilesystemType)
{
    //
    // This is called to see if a filter would like to attach an instance to the given volume.
    //

    return STATUS_SUCCESS;
}

NTSTATUS FLTAPI InstanceQueryTeardownCallback(
    _In_ PCFLT_RELATED_OBJECTS FltObjects,
    _In_ FLT_INSTANCE_QUERY_TEARDOWN_FLAGS Flags
)
{
    //
    // This is called to see if the filter wants to detach from the given volume.
    //

    return STATUS_SUCCESS;
}

演示

项目地址

可以看到明显代码要少了很多很多，我们只需要实现一下回调函数即可

扩展

这里着重介绍minifilter的context概念，windowd的很多机制中都有各种context

在minifilter这里，context是filter自定义的一些数据，这些数据附着在某些内核对象中

在使用Context之前，需要先调用FltAllocateContext函数来获取一个未初始化的Context对象

函数签名如下：

NTSTATUS FLTAPI FltAllocateContext(
  [in]  PFLT_FILTER      Filter,
  [in]  FLT_CONTEXT_TYPE ContextType,
  [in]  SIZE_T           ContextSize,
  [in]  POOL_TYPE        PoolType,
  [out] PFLT_CONTEXT     *ReturnedContext
);

a1是filter注册函数FltRegisterFilter的返回值，同时它也可以通过filter注册的callback函数的FLT_RELATED_OBJECTS参数获取

a5是传出参数，里面会保存未初始化的Context对象

分配之后，我们就可以在里面存储任何我们想要存储的数据，我们必须把这个Context attach到一个对象上，这个可以通过调用FltSetFileContext函数完成，不同的Context类型拥有对应的Set函数，只需要把File替换为对应的Context类型名即可

函数签名如下：

NTSTATUS FLTAPI FltSetFileContext(
  [in]  PFLT_INSTANCE             Instance,
  [in]  PFILE_OBJECT              FileObject,
  [in]  FLT_SET_CONTEXT_OPERATION Operation,
  [in]  PFLT_CONTEXT              NewContext,
  [out] PFLT_CONTEXT              *OldContext
);

对于所有的类型，a1都是必须要提供的参数，对于FILE类型的Context，我们需要提供一个FILE_OBJECT来将Context附着在上面

NewContext就是我们前面Allocate的Context对象，OldContext是一个可选参数，可以用来取回该FILE_OBJECT上之前附着的Context对象

Context有自己的引用计数，因此在用完之后，需要调用FltReleaseContext函数来进行释放

对于这种需要对引用计数加以关注的对象，使用RAII是最佳实践

后面如果需要使用Context，使用FltGetXxxContext函数即可，这里的Xxx就是Context类型

在minifilter中发起IO请求

我们不能直接在filter的callback中使用诸如ZwCreateFile这样的内核函数，因为我们当前就在IO处理的栈中，再次调用这种函数很容易发生问题

filter manager提供了一些函数来帮助filter进行IO操作，这些函数的名称和ZeCreatefile很像，只是前缀变成了Flt

这个函数的函数签名太长，我就不贴了，可以自己看官方文档

不过大多数情况下，我们选择使用FltCreateFileEx，该函数中有一个传出参数，会保存返回的FILE_OBJECT对象，然后我们可以调用FltReadFile和FltWriteFile等函数对该FILE_OBJECT进行操作，对于这种情况，在操作完成之后，需要使用ObDereferenceObject函数来降低引用计数

下面我们来实现一个文件备份驱动以加深理解

File Backup Driver

我们将要开发的这个驱动拥有自动备份文件的功能，每当这个文件被打开进行写入操作的时候，我们就会先备份一下原始文件，这样可以在将来有需要的时候恢复到上一个状态

我们将以NTFS Stream的形式将备份文件存储在原始文件中，如果需要恢复文件的上一个状态，我们使用Context替换掉当前的Stream以完成备份的恢复

我们定义的Context对象如下：

typedef struct _FileContext {
    Mutex Lock;
    LARGE_INTEGER BackupTime;
    BOOLEAN Written;
}FileContext;

其中第一个字段是一个互斥量，我们使用他来进行同步，因为一个文件可能会被多个线程在几乎同一时刻进行写入，我们需要互斥量来保证只有一个备份生成

我们这里使用的是标准互斥量而不是FastMutex，是因为我们的驱动需要进行IO操作，而IO操作只在IRQL为0（PASSIVE_LEVEL）下才能进行，FastMutex会将IRQL升高到1（APC_LEVEL）从而导致死锁

关于死锁的更详细解释是，IO操作通过向请求线程发送特殊内核APC来完成，而APC在APC_LEVEL下无法执行，一个正在等待FAST_MUTEX的线程的IRQL就是APC_LEVEL，那么IO操作就永远无法完成，死锁就形成了

Write字段是为了保证我们只在用户第一次调用Write函数时对文件进行备份

RAII

在我们备份文件的代码中，我们需要进行上锁，其中用到了RAII特性，一个Autolocker类

#pragma once
template<typename TLock>
class Locker {
public:
    Locker(TLock* lock) :m_lock(lock) {
        m_lock->Lock();
    }
    ~Locker() {
        m_lock->Unlock();
    }
private:
    TLock* m_lock;
};

我们使用do while循环划出来一个作用域（直接用花括号也可以划出来一块作用域）然后在该作用域中实例化一个Autolocker类，此时构造函数被调用，上锁操作随之完成，在出了作用域之后，Autolocker类会自动析构从而完成解锁操作

这里面海涌到了模板，C++真是博大精深，不理解语言特性连代码都看不懂

这里虽然我写的是指针，但是推荐使用引用写法，因为引用可以在编译阶段规避掉空指针引用的问题，有空指针的话编译是无法通过的

文件复制

NTFS文件系统支持Stream，我们可以在原始文件路径后面跟一个:Backup来创建出一个Stream，然后把源文件内容写入这个Stream中

使用FltReadFile和FltWriteFile函数进行源文件的读取和目标文件的写入

最后就是我们当前文件的大小可能会小于上一个版本的备份文件的大小，所以我们还需要设置当前版本备份文件的文件结束指针的位置

FILE_END_OF_FILE_INFORMATION info;
        info.EndOfFile = fileSize;
        status = FltSetInformationFile(FltObjects->Instance, targetFile, &info, sizeof(info),
            FileEndOfFileInformation);

OnPostCleanup

我们的Context是附着在一个文件上的，如果我们不作任何处理的话，只有当这个文件被删除的时候，我们的Context才会被清理掉，但是这个文件有可能永远都不会被删除，因此我们需要在文件关闭的时候清理掉Context

IRP_MJ_CLOSE和IRP_MJ_CLEANUP，两者的区别在于后者意味着对应的FILE_OBJECT已经不再被需要了，该文件的所有句柄都已经关闭，但是FILE_OBJECT的引用计数还没有归零，这是我们清理Context的最佳时机；而前者意味着最后一个句柄被关闭，但是由于缓存的存在，有时并不总是这样

效果演示

项目地址

改进

可以使用SectionObject来进行文件的备份，SectionObject允许我们像操作内存一样操作文件内容，而且无需操心内存的分配，这些工作以及写回到文件的操作都是由内存管理器来自动完成的

Section还支持在进程间以及内核模式和用户模式之间共享内存

下面使用SecionObject改进前面编写的Backup驱动的代码，主要的改动发生在BackupFile函数中

这是改进后的代码，可以看到没有给buffer分配内存

// 改写为使用SectionObject
NTSTATUS BackupFile(UNICODE_STRING path, PCFLT_RELATED_OBJECTS FltObjects) {
    KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Entering BackupFile function call\n"));
    // 在内核里面是没有CopyFile这种现成的API给我们使用的
    LARGE_INTEGER fileSize;
    auto status = FsRtlGetFileSize(FltObjects->FileObject, &fileSize);
    if (!NT_SUCCESS(status)) {
        KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Retrieve file size failed [0x%08X]\n", status));
        return status;
    }
    if (fileSize.QuadPart == 0) {
        KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "File empty [0x%08X]\n", status));
        return FLT_PREOP_SUCCESS_NO_CALLBACK;
    }
    // 我们的基本想法就是分别打开两个stream（srouce），一个是原始stream（target），另一个是用来备份的stream
    // 打开source
    PFILE_OBJECT sourceFile = NULL;
    PFILE_OBJECT targetFile = NULL;
    HANDLE hSourceFile = NULL;
    HANDLE hTargetFile = NULL;
    HANDLE hSection = NULL;
    IO_STATUS_BLOCK statusBlock;
    PVOID buffer = nullptr;
    do {
        OBJECT_ATTRIBUTES sourceFileAttr;
        InitializeObjectAttributes(&sourceFileAttr, &path, OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, NULL, NULL);
        // 使用FltCreateFileEx打开源文件
        // 你妈的这参数也太多了点
        // 我们用户模式下用于打开文件的API通常都会要求提供一个文件路径
        // 而内核模式种对应的API则要求提供一个OBJECT_ATTRIBUTES结构体，里面会包含要打开的文件路径
        // 这里面比较重要的参数有以下几个
        /*
        这两个参数提供了必要的信息以告知IO管理器设备栈中的下一个设备的位置，这样才能正常向目标设备
        发送IO请求
        FltObjects->Filter,
        FltObjects->Instance,
        hSourceFile  传出参数，用于接收该函数返回的句柄
        sourceFile   也是传出参数，用于接受该函数返回的FILE_OBJECT结构体，后面提供给FltReadFile函数使用
        FILE_OPEN    这个标志位就是表示文件一定要是已经存在的
        IO_IGNORE_SHARE_ACCESS_CHECK   这个标志位很重要，因为目标文件已经处于打开状态，且此时我们
        并不知道其是否设置了share相关标志位，所以我们请求IO管理器忽略share的检查
        */
        status = FltCreateFileEx(
            FltObjects->Filter,
            FltObjects->Instance,
            &hSourceFile,
            &sourceFile,
            GENERIC_READ | SYNCHRONIZE,
            &sourceFileAttr,
            &statusBlock,
            NULL, FILE_ATTRIBUTE_NORMAL,
            FILE_SHARE_READ | FILE_SHARE_WRITE,
            FILE_OPEN, FILE_SYNCHRONOUS_IO_NONALERT | FILE_SEQUENTIAL_ONLY,
            NULL, 0, IO_IGNORE_SHARE_ACCESS_CHECK
        );
        if (!NT_SUCCESS(status)) {
            KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "File open failed [0x%08X]\n", status));
            break;
        }
        // 然后我们需要在同一个文件中创建另一个Stream
        UNICODE_STRING targetFileName;
        const WCHAR backupStream[] = L":backup";
        targetFileName.MaximumLength = path.Length + sizeof(backupStream);
        targetFileName.Buffer = (WCHAR*)ExAllocatePoolWithTag(PagedPool, targetFileName.MaximumLength, DRIVER_TAG);
        if (NULL == targetFileName.Buffer) {
            KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Allocate memory from paged pool failed\n"));
            status = STATUS_NO_MEMORY;
            break;
        }
        RtlCopyUnicodeString(&targetFileName, &path);
        RtlAppendUnicodeToString(&targetFileName, backupStream);
        KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Backup file name: %wZ\n", &targetFileName));
        OBJECT_ATTRIBUTES targetFileAttr;
        InitializeObjectAttributes(&targetFileAttr, &targetFileName, OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, NULL, NULL);
        status = FltCreateFileEx(
            FltObjects->Filter,
            FltObjects->Instance,
            &hTargetFile,
            &targetFile,
            GENERIC_WRITE | SYNCHRONIZE,
            &targetFileAttr,
            &statusBlock,
            NULL, FILE_ATTRIBUTE_NORMAL,
            0,
            FILE_OVERWRITE_IF, // 覆盖已经存在的数据
            FILE_SYNCHRONOUS_IO_NONALERT | FILE_SEQUENTIAL_ONLY,
            NULL, 0, 0
        );
        if (!NT_SUCCESS(status)) {
            KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Create backup stream failed [0x%08X]\n", status));
            break;
        }
        // 释放targetFileName.Buffer内存
        ExFreePoolWithTag(targetFileName.Buffer, DRIVER_TAG);
        // 创建SectionObject   这个Section用来映射源文件
        OBJECT_ATTRIBUTES sectionAttr = RTL_CONSTANT_OBJECT_ATTRIBUTES(nullptr , OBJ_KERNEL_HANDLE);
        status = ZwCreateSection(&hSection, SECTION_MAP_READ | SECTION_QUERY,
            &sectionAttr, NULL,
            PAGE_READONLY, SEC_COMMIT, hSourceFile);
        if (!NT_SUCCESS(status)) {
            KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "ZwCreateSection failed [0x%08X]\n", status));
            break;
        }
        // 这些操作都完成之后，我们就可以进行srouce到target的拷贝操作了
        // 使用循环分配小块内存，直到整个文件拷贝完成
        ULONG size = 1 << 20; // 1MB 1*1024*1024
        // 我们无需分配内存，只需要提供一个指针变量作为map函数的传出参数即可
        // buffer = ExAllocatePoolWithTag(PagedPool, size, DRIVER_TAG);
        // if (nullptr == buffer) {
        //  KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Buffer allocate failed"));
        //  status = STATUS_NO_MEMORY;
        //  break;
        // }
        ULONGLONG remainBytes = fileSize.QuadPart;
        ULONG out = 0;
        ULONG readOffset = 0;
        LARGE_INTEGER sectionOffset;
        sectionOffset.QuadPart = 0;
        SIZE_T viewBytes = 0;
        ULONG bytesWritten = 0;
        // 从source中读取数据然后写入到target中
        while (remainBytes) {
            viewBytes = min(size, remainBytes);
            ZwMapViewOfSection(hSection, NtCurrentProcess(), &buffer, 0, 0,&sectionOffset, 
                &viewBytes, ViewUnmap, 0, PAGE_READONLY);

            if (!NT_SUCCESS(status)) {
                KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "ZwMapViewOfSection failed [0x%08X]\n", status));
                break;
            }
            // 写入目标stream
            status = FltWriteFile(
                FltObjects->Instance,
                targetFile,
                0,// 在进行同步IO的时候是没有必要指定offset的，因为IO管理器会自动追踪偏移量
                viewBytes,
                buffer,
                0,
                &bytesWritten,
                NULL, NULL);
            if (!NT_SUCCESS(status)) {
                KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Write bytes to target failed [0x%08X]\n", status));
                break;
            }

            status=ZwUnmapViewOfSection(NtCurrentProcess(), buffer);
            if (!NT_SUCCESS(status)) {
                KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "ZwUnmapViewOfSection failed [0x%08X]\n", status));
                break;
            }
            sectionOffset.QuadPart += bytesWritten;
            remainBytes -= bytesWritten;
        }
        // 还要考虑到一种情况，就是上一个版本的备份文件比这次备份的大，因此我们需要设置文件的结束位置
        FILE_END_OF_FILE_INFORMATION info;
        info.EndOfFile = fileSize;
        status = FltSetInformationFile(FltObjects->Instance, targetFile, &info, sizeof(info),
            FileEndOfFileInformation);
        if (!NT_SUCCESS(status)) {
            KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Set file end pointer failed [0x%08X]\n", status));
            break;
        }
    } while (false);


    status = FsRtlGetFileSize(targetFile, &fileSize);
    if (!NT_SUCCESS(status)) {
        KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Failed to get backup file size [0x%08X]\n", status));
    }
    else {

        KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "Backup file size: [0x%08X]\n", fileSize.QuadPart));
    }
    KdPrintEx((FOR_DEBUG,TRACE_LEVEL_ERROR,"[sourceFile] This is the source file object address [0x%p]\n", sourceFile));
    KdPrintEx((FOR_DEBUG,TRACE_LEVEL_ERROR,"[targetFile] This is the backup file object address [0x%p]\n", targetFile));

    if (hTargetFile)  // 虽然这两个句柄没啥用，但还是要带上的，不然运行到FlrCreateFileEx的时候会BSOD
        FltClose(hTargetFile);
    if (hSourceFile)
        FltClose(hSourceFile);
    if (hSection)
        ZwClose(hSection);
    if (sourceFile)
        ObDereferenceObject(sourceFile);
    if (targetFile)
        g_backupFileObject = targetFile;
    KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "[g_backupFileObject] This is the backup file object address [0x%p]\n", g_backupFileObject));
    KdPrintEx((FOR_DEBUG, TRACE_LEVEL_ERROR, "File backup succeed\n"));
    return status;
}

项目地址

和用户模式进行通信

IoControl可以用于User/Kernel之间的通信，但是这种方式只能由User主动发起，Kernel只能被动接收消息

FilterManager提供了一个通信机制，可以让Kernel直接向User发送消息，这个东西被称作FilterCimmunicationPort，通过FltCreateCommunicationPort函数可以创建一个这样的端口出来

然后通过FltSendMessage来通过该端口发送消息，User也可以使用这套通信机制向Kernel发送消息，这个通信端口是双向的，只不过在UserMode中使用的API名称是FilterSendMessage

下面使用通信端口对前面的BackupDriver进一步改进

项目地址

演示

Windows ETW

2024-05-11T00:00:00+02:00

references:

约定：

IMF ----> instrumentation manifest

ETW全称为Event Tracing for Windows

ETW中有三个重要的概念：

Term	Description
Providers	Applications or components that raise event tracing instrumentation.
Controllers	Applications that start, stop, and configure event tracing sessions.
Consumers	Applications that receive event tracing sessions (in real time) or from a file.

即提供者、控制器、消费者，其实很好理解，提供者负责产生事件，控制器负责控制会话的开启和关闭吗，消费者接受提供者产生的事件

ETW提供了内核API，之前讲到的WPP就使用了ETW

驱动代码可以调用这些API来将自己注册成为一个提供者，产生的日志可以被消费者实时接收或者写入文件

和WPP一样，ETW也可以动态启停，对程序性能的影响非常小

在驱动程序中使用ETW

我们这里还是使用Windows File System Filter Driver中的代码来演示

其实最麻烦的就是写定义xml，下面着重讲一下

IMF就是一个XML文件，里面定义了一堆ETW相关概念的东西，通常以.man作为文件后缀

定义provider

provider标签的5个属性：

name
guid
resourceFileName
messageFileName
symbol

这5个属性必须赋值，语言本地化我们不用管，毕竟我也不是专门开发软件的😏

在一个man文件中可以写16个provider标签，如果多于16个，也可以定义，具体参考微软文档

<provider name="Microsoft-Windows-SampleProvider" 
    guid="{1db28f2e-8f80-4027-8c5a-a11f7f10f62d}" 
    symbol="PROVIDER_GUID" 
    resourceFileName="<path to the exe or dll that contains the metadata resources>" 
    messageFileName="<path to the exe or dll that contains the string resources>"
</provider>

定义频道

使用channel和importChannel标签，前者用于自定义频道，后者用于导入已经存在的频道

<channels>
    <importChannel chid="c1"
                   name="Microsoft-Windows-BaseProvider/Admin"
                   symbol="CHANNEL_BASEPROVIDER_ADMIN"
                   />

    <channel chid="c2"
             name="Microsoft-Windows-SampleProvider/Operational"
             type="Operational"
             enabled="true"
             />
</channels>

自定义频道的name属性的命名规范为provider标签的name属性+反斜杠+channel类型

channel类型一共就4个：

Administrative
Operational
Analytical
Debug

其中chid属性必须为唯一标识符，所以如果让我来写的话我会给他加一个GUID后缀

定义严重级别

win:Critical
win:Error
win:Warning
win:Informational
win:Verbose

通常我们使用这5种级别就够了，没必要自己去定义，这个是windows sdk中帮我们定义的level：

<levels>
    <level name="win:LogAlways" symbol="WINEVENT_LEVEL_LOG_ALWAYS" value="0" message="$(string.level.LogAlways)"> Log Always </level>
    <level name="win:Critical" symbol="WINEVENT_LEVEL_CRITICAL" value="1" message="$(string.level.Critical)"> Only critical errors </level>
    <level name="win:Error" symbol="WINEVENT_LEVEL_ERROR" value="2" message="$(string.level.Error)"> All errors, includes win:Critical </level>
    <level name="win:Warning" symbol="WINEVENT_LEVEL_WARNING" value="3" message="$(string.level.Warning)"> All warnings, includes win:Error </level>
    <level name="win:Informational" symbol="WINEVENT_LEVEL_INFO" value="4" message="$(string.level.Informational)"> All informational content, including win:Warning </level>
    <level name="win:Verbose" symbol="WINEVENT_LEVEL_VERBOSE" value="5" message="$(string.level.Verbose)"> All tracing, including previous levels </level>

    <!-- The following are unused.  They are place holders so that users dont accidentally use those values in their own definitions -->
    <level name="win:ReservedLevel6" symbol="WINEVENT_LEVEL_RESERVED_6" value="6"/>
    <level name="win:ReservedLevel7" symbol="WINEVENT_LEVEL_RESERVED_7" value="7"/>
    <level name="win:ReservedLevel8" symbol="WINEVENT_LEVEL_RESERVED_8" value="8"/>
    <level name="win:ReservedLevel9" symbol="WINEVENT_LEVEL_RESERVED_9" value="9"/>
    <level name="win:ReservedLevel10" symbol="WINEVENT_LEVEL_RESERVED_10" value="10"/>
    <level name="win:ReservedLevel11" symbol="WINEVENT_LEVEL_RESERVED_11" value="11"/>
    <level name="win:ReservedLevel12" symbol="WINEVENT_LEVEL_RESERVED_12" value="12"/>
    <level name="win:ReservedLevel13" symbol="WINEVENT_LEVEL_RESERVED_13" value="13"/>
    <level name="win:ReservedLevel14" symbol="WINEVENT_LEVEL_RESERVED_14" value="14"/>
    <level name="win:ReservedLevel15" symbol="WINEVENT_LEVEL_RESERVED_15" value="15"/>
    <!-- End of reserved values -->
</levels>

如果我们要用的话，直接复制回来就行了，没必要自己瞎折腾

定义任务和操作码

提供者使用任务和操作码来进行事件的分组

一般情况下，使用任务来标识一个软件组件，比如network、database等

使用操作码来标识某个组件执行的操作，如network组件的发包、收包操作，database组件的查询、插入等操作

这个都是自己来定义的，微软并不会强制要求你怎么写，只要你自己觉得符合逻辑即可

task和opcode的定义方法如下：

<tasks>
    <task name="Disconnect" 
          symbol="TASK_DISCONNECT"
          value="1"
          message="$(string.Task.Disconnect)"/>

    <task name="Connect" 
          symbol="TASK_CONNECT"
          value="2"
          message="$(string.Task.Connect)">
    </task>

    <task name="Validate" 
          symbol="TASK_VALIDATE"
          value="3"
          message="$(string.Task.Validate)">
    </task>
</tasks>

<opcodes>
    <opcode name="Initialize" 
            symbol="OPCODE_INITIALIZE" 
            value="12"
            message="$(string.Opcode.Initialize)"/>

    <opcode name="Cleanup" 
            symbol="OPCODE_CLEANUP" 
            value="13"
            message="$(string.Opcode.Cleanup)"/>
 </opcodes>

<localization>
    <resources culture="en-US">
        <stringTable>
            <string id="Provider.Name" value="Sample Provider"/>
            <string id="Task.Disconnect" value="Disconnect"/>
            <string id="Task.Connect" value="Connect"/>
            <string id="Task.Connect.ReadRegistry" value="ReadRegistry"/>
            <string id="Task.Validate" value="Connect"/>
            <string id="Task.Validate.GetRules" value="GetRules"/>
            <string id="Opcode.Initialize" value="Initialize"/>
            <string id="Opcode.Cleanup" value="Cleanup"/>
        </stringTable>
    </resources>
</localization>

定义关键字，用于给事件分类

关键字keyword是一个64-bit的掩码，每一个bit都是一个category，如果一个事件的某个bit置位，那么就表明这个事件归属于该bti位对应的category

其中低48-bit由开发者自定义，高16bit由微软定义，winmeta.xml文件中有对高16bit的说明

这个就是高16bit每个bit位所对应的含义

ETW会话可以通过keyword来过滤掉自己不想搜集的事件，这个就跟WPP中的flag和level是一样的

ETW会话有一对针对keyword的过滤器：

MatchAnyKeyword
MatchAllKeyword

顾名思义，前者就是说只有事件的任意一个bit命中，就写入，后者意思是只有所有的bit都命中才会写入

如果MatchAllKeyword为0，那么只要符合MatchAnyKeyword规则，那么就会写入，如果MatchAllKeyword不为0，那么事件的keyword必须要同时符合两条规则才会被写入

我们可以举一个实际的例子

使用keyword标签来定义关键字，定义之后，后面的event标签就可以使用这里定义的所有关键字：

<keywords>
    <keyword name="Read" mask="0x1" symbol="READ_KEYWORD"/>
    <keyword name="Write" mask="0x2" symbol="WRITE_KEYWORD"/>
    <keyword name="Local" mask="0x4" symbol="LOCAL_KEYWORD"/>
    <keyword name="Remote" mask="0x8" symbol="REMOTE_KEYWORD"/>
</keywords>

定义过滤器

这个过滤器是给ETW会话使用的，过滤规则由会话提供

比如说我们的provider会生成进程相关ed事件，然后我们提供了一个根据进程ID进行事件过滤的过滤器，那么ETW会话就可以通过传给我们一个PID来过滤事件

使用filter标签来定义过滤器：

<filters>
    <filter name="Pid"
            value="1"
            tid="t1"
            symbol="FILTER_PID"/>
</filters>

<templates>
    <template tid="t1">
        <data name="Pid" inType="win:UInt32"/>
    </template>
</templates>

定义Name/Value映射

用于将数字映射成字符串，这个没什么好说的，直接看例子：

<maps>
    <valueMap name="TransferType">
        <map value="1" message="$(string.TransferType.Download)"/>
        <map value="2" message="$(string.TransferType.Upload)"/>
        <map value="3" message="$(string.TransferType.UploadReply)"/>
    </valueMap>
    <bitMap name="DaysOfTheWeek">
        <map value="0x1" message="$(string.DaysOfTheWeek.Sunday)"/>
        <map value="0x2" message="$(string.DaysOfTheWeek.Monday)"/>
        <map value="0x4" message="$(string.DaysOfTheWeek.Tuesday)"/>
        <map value="0x8" message="$(string.DaysOfTheWeek.Wednesday)"/>
        <map value="0x10" message="$(string.DaysOfTheWeek.Thursday)"/>
        <map value="0x20" message="$(string.DaysOfTheWeek.Friday)"/>
        <map value="0x40" message="$(string.DaysOfTheWeek.Saturday)"/>
    </bitMap>
</maps>

<localization>
    <resources culture="en-US">
        <stringTable>
            <string id="Provider.Name" value="Sample Provider"/>
            <string id="TransferType.Download" value="Download"/>
            <string id="TransferType.Upload" value="Upload"/>
            <string id="TransferType.UploadReply" value="Upload-reply"/>
            <string id="DaysOfTheWeek.Sunday" value="Sunday"/>
            <string id="DaysOfTheWeek.Monday" value="Monday"/>
            <string id="DaysOfTheWeek.Tuesday" value="Tuesday"/>
            <string id="DaysOfTheWeek.Wednesday" value="Wednesday"/>
            <string id="DaysOfTheWeek.Thursday" value="Thursday"/>
            <string id="DaysOfTheWeek.Friday" value="Friday"/>
            <string id="DaysOfTheWeek.Saturday" value="Saturday"/>
        </stringTable>
    </resources>
</localization>

定义事件数据模板

虽然我不知道name属性到底有啥用，但是根据文档，name属性是一定要有值的

注意里面的outtype，intype属性很好理解，解释我们调用EventWrite函数的时候传入的参数类型，而outtype是用来指示消费者如何渲染这条数据，不过outtype并不是一定要设置ed属性，如果你不指定，那么消费者会使用intype默认的对应outtype来进行渲染

<templates>
    <template tid="t2">
        <data name="TransferName" inType="win:UnicodeString"/>
        <data name="Day" inType="win:UInt32" map="DaysOfTheWeek"/>
        <data name="Transfer" inType="win:UInt32" map="TransferType"/>
    </template>

    <template tid="t3">
        <data name="TransferName" inType="win:UnicodeString"/>
        <data name="ErrorCode" inType="win:Int32" outType="win:HResult"/>
        <data name="FilesCount" inType="win:UInt16" />
        <data name="Files" inType="win:UnicodeString" count="FilesCount"/>
        <data name="BufferSize" inType="win:UInt32" />
        <data name="Buffer" inType="win:Binary" length="BufferSize"/>
        <data name="Certificate" inType="win:Binary" length="11" />
        <data name="IsLocal" inType="win:Boolean" />
        <data name="Path" inType="win:UnicodeString" />
        <data name="ValuesCount" inType="win:UInt16" />
        <struct name="Values" count="ValuesCount" >
            <data name="Value" inType="win:UInt16" />
            <data name="Name" inType="win:UnicodeString" />
        </struct>
    </template>
</templates>

定义事件

使用event标签定义事件，value属性必须被定义，且需要是唯一的

如果事件中包含自定义的数据，那么就需要之前定义的数据模板，通过设置template属性为对应的templateid来实现

level/keyword/task/opcode用来给事件分类

这里有一个完整的定义文件

里面的symbol属性决定了我们到时候发布事件的时候所要使用的函数名称

另外一点就是所使用的template也决定了传参的形式

本地化消息字符串

这个没什么好讲的，就是localization标签，前面已经见到过很多次了

编译.man文件

使用消息编译器mc.exe来编译我们前面编写的.man文件

mc会创建出来一个头文件，里面包含了man文件中的定义

我们需要在源文件中包含这个头文件，同时mc还会生成.rc文件和一个.bin文件

有两种方法可以将上面的操作自动化：

添加消息编译器任务到驱动项目文件中
使用VS将man文件添加到项目中并配置消息编译器属性

对于第一种方法，可以在vcxproj文件中的MessageCompile标签中进行编辑：

<MessageCompile Include="evntdrv.xml">
  <GenerateKernelModeLoggingMacros>true</GenerateKernelModeLoggingMacros>
  <HeaderFilePath>.\$(IntDir)</HeaderFilePath>
  <GeneratedHeaderPath>true</GeneratedHeaderPath>
  <WinmetaPath>"$(SDK_INC_PATH)\winmeta.xml"</WinmetaPath>
  <RCFilePath>.\$(IntDir)</RCFilePath>
  <GeneratedRCAndMessagesPath>true</GeneratedRCAndMessagesPath>
  <GeneratedFilesBaseName>evntdrvEvents</GeneratedFilesBaseName>
  <UseBaseNameOfInput>true</UseBaseNameOfInput>
</MessageCompile>

代码编写

现在我们修改之前的过滤驱动项目来使用ETW进行tracing

其实我突然发现ETW并不是很适合用来记录调试信息，因为只要传参类型不同，就需要定义额外的template，很麻烦，除非说你定义一个很长的参数列表，来满足所有类型的参数类型，但是这样会导致代码非常臃肿

在编写完man文件之后我们需要修改文件属性

后面的过程我放到了视频中

part1

part2

项目地址

自定义的channel不知道啥原因不好使，使用importChannel，利用现成的channel就可以，而且就是驱动一运行，就会有源源不断的事件写入到event log中，根本不用tracelog

<importChannel  chid="c1"
                name="System"/>

所以是不是说，ETW并不是所谓的动态启停？只要注册了之后，有consumer就会生成事件？

这个我现在也没弄明白

2024-06-14 更新

其实ETW用起来并不复杂，我们并不一定非要把日志写入到系统log中

这里有一个从这个项目中抄来的ETW代码，大家可以参考一下

另外就是原始项目的代码注释中提到了一篇文章，我也顺便来看一下

笑死了，这篇文章通篇都在吐槽微软的屎山代码

不过问题是这个ETW代码只能在用户模式使用，驱动中是不能这么写的

但是Trace部分我们还是可以正常使用的，只需要把Trace项目的GUID修改为驱动项目中etwman.xml中的GUID即可

效果如下：

Windows WPP

2024-05-09T00:00:00+02:00

references:

约定：

TMF --> trace message function

本章我们将会介绍如何使用WPP

WPP的全称为Windows software trace PreProcessor

他可以用来跟踪trace provider的操作，一个trace provider可以是一个内核驱动，也可以是一个用户模式的软件

WPP是WMI event tracing的补充和增强，他简化了追踪trace provider操作的方式

WPP非常高效，可以实时记录二进制日志数据，并且可以转换为human-readable trace log

WPP和ETW都可以用来搜集调试信息，两者的区别在于前者可以保证我们的调试信息不被用户看到，因为WPP产生的二进制日志文件需要使用TMF文件来进行解码，而TMF是通过PDB文件生成的，正常情况下我们是不会发布PDB文件的

WPP软件跟踪过程

WPP的基本过程可以分为下面这几步：

定义control GUID，用于唯一标识一个trace provider
添加WPP相关的C预处理指令和WPP宏来调用源文件中的函数
修改VS项目配置以启动WPP预处理
安装驱动，开启trace session并记录消息

需要注意的是，并不是所有的驱动类型都可以使用WPP，这一点可以通过在DriverEntry中加入WPP宏WPP_INIT_TRACING然后编译代码来进行验证，如果编译通不过，说明该类型的驱动不受WPP支持

WPP trace provider同一时刻只能存在于一个trace session中

在驱动代码中使用WPP

我们需要对原本的驱动代码进行更改，这里我们使用Windows File System Filter Driver中的代码来演示

如果使用了VS提供的KMDF模板，可以知己跳到第五步

第一步，定义control GUID和trace flag

一般的做法是把WPP相关的宏定义放到一个单独的头文件中，然后在所有需要用到WPP trace的源文件中包含这个头文件

wpp.h:

#define WPP_CONTROL_GUIDS                                              \
    WPP_DEFINE_CONTROL_GUID(                                           \
        myDriverTraceGuid, (84bdb2e9,829e,41b3,b891,02f454bc2bd7), \
        WPP_DEFINE_BIT(MYDRIVER_ALL_INFO)        /* bit  0 = 0x00000001 */ \
        WPP_DEFINE_BIT(TRACE_DRIVER)             /* bit  1 = 0x00000002 */ \
        WPP_DEFINE_BIT(TRACE_DEVICE)             /* bit  2 = 0x00000004 */ \
        WPP_DEFINE_BIT(TRACE_QUEUE)              /* bit  3 = 0x00000008 */ \
        )

可以看到trace flag的值是2的次幂，从0开始

在使用TMF的时候，我们会带上trace flag，tracelog.exe可以通过指定trace flag来控制正在运行的驱动中哪些TMF会被执行

形式如下：

DoTraceMessage(TRACE_DRIVER, "Hello World!\n");

当tracelog.exe通过-flag选项指定flag为2的时候，这条语句就会执行，对应的message就会被记录下来

第二步，选择一个函数作为trace message function

所谓trace message function就和dbgprint差不多，就是用来写调试信息的

微软提供了一个默认的函数，DoTraceMessage宏，如果你使用这个默认函数，那么就不需要再定义WPP_LEVEL_ENABLED和WPP_LEVEL_LOGGER宏了

如果你使用自定义的函数，或者转换现存的函数，那么就需要进行以下操作

比如你想把KdPrint函数转换成TMF，那么你需要定义WPP宏来标识并启用这个函数
定义WPP宏来启用这个函数，每一个TMF都必须要有一对宏定义，这对宏用于标识trace provider并指定在什么条件下会产生trace message，形式如下： c WPP_<condition>_LOGGER WPP_<condition>_ENABLED

这里的<condition>就是你的TMF的参数列表，比如你的TMF签名为：

DoTraceLevelMessage(LEVEL, FLAGS, MESSAGE, ...);

那么对应的宏就应该长下面这个样子

#define WPP_LEVEL_FLAGS_LOGGER
#define WPP_LEVEL_FLAGS_ENABLED

默认的TMF是DoTraceMessage：

void  DoTraceMessage(     
    TraceFlagName,    
    Message,     
    [ VariableList ] 
);

它对应的宏就是

WPP_LEVEL_ENABLED
WPP_LEVEL_LOGGER

这就是遗留问题了，虽然DoTraceMessage支持的是trace flag，但是他这里宏定义上写的却是LEVEL，而且实际他也是不支持LEVEL的，而是支持trace flag

如果我们使用上面提到的DoTraceLevelMessage函数作为我们的TMF，那么最终的宏定义应该为：

#define WPP_LEVEL_FLAGS_LOGGER(lvl,flags) \
           WPP_LEVEL_LOGGER(flags)

#define WPP_LEVEL_FLAGS_ENABLED(lvl, flags) \
           (WPP_LEVEL_ENABLED(flags) && WPP_CONTROL(WPP_BIT_ ## flags).Level >= lvl)

只有在达到指定等级之后，才会启用loggger

下面我们需要使用begin_wpp和end_wpp来声明我们的TMF，你没看错，他就是被注释掉的，因为这个不是给编译器用的，是给WPP预处理器用的配置

DTLM是DoTraceLevelMessage的缩写

// begin_wpp config
// FUNC DTLM(LEVEL, FLAGS, MSG, ...);
// end_wpp

可以直接将KdPrint转换成TMF，如下：

// begin_wpp config
// FUNC KdPrint{LEVEL=TRACE_LEVEL_INFORMATION, FLAGS=TRACE_DRIVER}((MSG, ...));
// end_wpp

只有在TRACE_LEVEL_INFORMATION等级和TRACE_DRIVER标志启用时，才会记录日志，此时的KdPrint将不再直接输出到DbgView中，而是记录到日志中

我们也可以直接将KdPrintEx转换为我们的TMF

// begin_wpp config
// FUNC KdPrintEx((Flags, LEVEL, MSG, ...));  
// end_wpp

不过KdPrintEx和KdPrint不太一样，多了几个参数

DbgPrintEx (
    _In_ ULONG ComponentId,
    _In_ ULONG Level,
    _In_z_ _Printf_format_string_ PCSTR Format,
    ...
    );

因此我们要在WPP_CONTROL_GUIDS定义一个ComponentId的BIT，不然tracelog也没法用，对应的WPP宏对有需要更改，FLAGS跑到了LEVEL前面

#define WPP_CONTROL_GUIDS \
    WPP_DEFINE_CONTROL_GUID(GUIDFriendlyName, (DE1AB18A, 8A47, 43FB, B3BB, E503D293A33F),  \
        WPP_DEFINE_BIT(DPFLTR_IHVDRIVER_ID)  )

#define WPP_FLAGS_LEVEL_LOGGER(flags,lvl) \
           WPP_LEVEL_LOGGER(flags)

#define WPP_FLAGS_LEVEL_ENABLED(flags,lvl) \
           (WPP_LEVEL_ENABLED(flags) && WPP_CONTROL(WPP_BIT_ ## flags).Level >= lvl)

第三步，包含头文件wpp.h和自动生成的*.tmh到会用到trace的源文件中

准确来说*.tmh文件还没有生成，只有在我们build驱动的时候才会生出来

build之前需要先在项目属性中开启WPP

我们有多少个.c文件，就会有多少个.tmh文件被生出来，WPP预处理器为每一个源文件都生成了一个.tmh文件

第四步，初始化和clean up WPP

分别对应WPP_INIT_TRACING和WPP_CLEANUP

WPP_INIT_TRACING( DriverObject, RegistryPath );
WPP_CLEANUP(DriverObject);

前者放在DriverEntry里，后者放在Unload里

当然了，如果遇到意外程序提前结束了，也要在退出时先CLEANUP

测试

extra

#define WPP_CONTROL_GUIDS \
    WPP_DEFINE_CONTROL_GUID(GUIDFriendlyName, (DE1AB18A, 8A47, 43FB, B3BB, E503D293A33F),  \
        WPP_DEFINE_BIT(FOR_DEBUG) \
        WPP_DEFINE_BIT(FOR_FILTER_FILENAME) \
        WPP_DEFINE_BIT(FOR_DRIVER_STATUS)  )

这里的BIT我们可以随便定义，不一定非要和KdPrintEx的ComponentID保持一致，这样并不影响KdPrintEx正常工作，而且可以通过-flag选项控制trace log输出

将tracelog的-flag选项分别设置为1、2、4可以控制不同类型的trace log

完美！

项目文件

TraceView

TraceView还支持过滤器，我们可以设置过滤器来过滤掉不想看到的trace message

这里我们discard掉了所有不包含fsfilter字符串的message（不区分大小写），可以看到捕获的文件名并没有显示在TraceView中

TraceViewPlus

推荐使用TraceVIewPlus，用了都说好，界面看着舒服，输出也能很方便导出，直接在这里添加pdb文件，然后启动即可

Windows File System Filter Driver

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

references:

windows提供了分层的驱动模型，过滤驱动位于IO请求和真正的负责处理该IO请求的驱动之间，可以捕获到IRP，从中获取必要的信息并进行必要的操作之后将IRP转发给真正负责处理的驱动

代码编写

main.c

所有的驱动入口函数都是DriverEntry

我们需要将DriverObject作为全局变量存储起来

PDRIVER_OBJECT g_fsFilterDriverObject =  NULL;

extern "C"
NTSTATUS DriverEntry(
    _In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    (RegistryPath);
    NTSTATUS status = STATUS_SUCCESS;
    return status;
}

下面我们需要填充IRP派遣表

NTSTATUS FsFilterDispatchCreate(PDEVICE_OBJECT DeviceObject, PIRP Irp) {
    NTSTATUS status = STATUS_SUCCESS;
    return status;
}

NTSTATUS FsFilterDispatchPassThrough(PDEVICE_OBJECT DeviceObject, PIRP Irp) {
    NTSTATUS status = STATUS_SUCCESS;
    return status;
}

extern "C"
NTSTATUS DriverEntry(
    _In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    (RegistryPath);
    NTSTATUS status = STATUS_SUCCESS;
    for (int i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++) {
        DriverObject->MajorFunction[i] = FsFilterDispatchPassThrough;
    }
    DriverObject->MajorFunction[IRP_MJ_CREATE] = FsFilterDispatchCreate;
    return status;   
}

设置快速IO派遣表

对于普通驱动，是不需要这一步的，但是对于过滤驱动，需要额外初始化一个被称为fast IO dispatch table的东西

FAST_IO_DISPATCH g_fastIoDispatch = {
    sizeof(FAST_IO_DISPATCH),
    FsFilterFastCheckIfPossible,
    ...
}; // 这个结构体的字段超级多

extern "C"
NTSTATUS DriverEntry(
    _In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) {
    (RegistryPath);
    NTSTATUS status = STATUS_SUCCESS;

    DriverObject->FastIoDispatch = &g_fastIoDispatch;
    return status;
}

注册关于文件系统变更的通知回调

我们需要这个通知来在发现新的文件系统时挂载到上面，从而进行IO的过滤操作

// 注册文件系统通知回调
status = IoRegisterFsRegistrationChange(DriverObject, FsFilterNotificationCallback);
if (!NT_SUCCESS(status)) {
    return status;
}

设置卸载例程

 DriverObject->DriverUnload = FsFilterUnload;

驱动卸载例程的实现

void FsFilterUnload(_In_ PDRIVER_OBJECT DriverObject) {
    // 注销通知回调
    IoUnregisterFsRegistrationChange(DriverObject, FsFilterNotificationCallback);
}

然后我们需要清除并deattach所有之前创建并attach到文件系统上的设备

void FsFilterUnload(_In_ PDRIVER_OBJECT DriverObject) {
    // 注销通知回调
    IoUnregisterFsRegistrationChange(DriverObject, FsFilterNotificationCallback);
    ULONG numDevices = 0;
    while (1) {
        IoEnumerateDeviceObjectList(
            DriverObject,
            devList,
            sizeof(devList),
            &numDevices
        );
        if (0 == numDevices) 
            break;
        numDevices = min(numDevices, RTL_NUMBER_OF(devList));
        for (int i = 0; i < numDevices; i++) {
            FsFilterDetachFromDevice(devList[i]);
            ObDereferenceObject(devList[i]);
        }

        // 睡眠一段时间，等待所有的IRP完成
        KeDelayExecutionThread(KernelMode, FALSE, &interval);
    }
}

IrpDispatch.c

我们的过滤驱动的IRP handler只有一个任务，就是把请求传递给更底层的驱动，下一层驱动存储在device extension中

NTSTATUS FsFilterDispatchPassThrough(PDEVICE_OBJECT DeviceObject, PIRP Irp) { 
    PFSFILTER_DEVICE_EXTENSION pDevExt = (PFSFILTER_DEVICE_EXTENSION)DeviceObject->DeviceExtension;
    IoSkipCurrentIrpStackLocation(Irp);
    return IoCallDriver(pDevExt->AttachedToDeviceObject, Irp); 
}

来自用户模式的所有CreateFile的操作都会触发我们的IrpCreate函数的调用

我们可以从FILE_OBJECT中获取到文件名，然后打印到Dbg信息中，之后我们再调用PassThrough将IRP传递下去

NTSTATUS FsFilterDispatchCreate(PDEVICE_OBJECT DeviceObject, PIRP Irp) {

    PFILE_OBJECT pFileObject = IoGetCurrentIrpStackLocation(Irp)->FileObject;
    DbgPrint("%wZ\n", &pFileObject->FileName);
    return FsFilterDispatchPassThrough(DeviceObject, Irp);
}

并不是所有的文件系统驱动都实现了fast IO，因此我们需要先检测一下

可以直接定义一个宏来进行检测

#define VALID_FAST_IO_DISPATCH_HANDLER(_FastIoDispatchPtr,_FieldName)\
(((_FastIoDispatchPtr)!=NULL)&& \
(((_FastIoDispatchPtr)->SizeofFastIoDispatch) >= \
(FIELD_OFFSET(FAST_IO_DISPATCH,_FieldName)+sizeof(void*))) && \
((_FastIoDispatchPtr)->_FieldName!=NULL))

上面的那个宏中的+sizeof(void*)我现在也没看懂，不知道为啥还要加上这个东西，我明白了，这个sizeof(void*)是字段本身的长度，FAST_IO_DISPATCH结构体除了第一个字段之外，其他的字段都是指针

那么这样就可以计算出，Field是否超出了FAST_IO_DISPATCH结构体的真实长度

Fast IO的传递和普通IRP的传递不太一样，前者需要大量的代码，因为每一个Fast IO函数的参数都不太一样

BOOLEAN FsFilterFastIoQueryBasicInfo(
    __in PFILE_OBJECT  FileObject,
    __in BOOLEAN Wait,
    __out PFILE_BASIC_INFORMATION Buffer,
    __out PIO_STATUS_BLOCK  IoStatus,
    __in PDEVICE_OBJECT DeviceObject
) {
    PDEVICE_OBJECT nextDeviceObject = ((PFSFILTER_DEVICE_EXTENSION)DeviceObject->DeviceExtension)->AttachedToDeviceObject;
    return FALSE;
}

VOID FsFilterFastIoDetachDevice(
    __in PDEVICE_OBJECT SourceDevice,
    __in PDEVICE_OBJECT TargetDevice) {
    IoDetachDevice(TargetDevice);
    IoDeleteDevice(SourceDevice);
}

notification.c

常规的文件系统包含了控制设备和volume设备（这个volume device我不知道要怎么翻译）

volume设备attach到storage device stack上，控制设备将自己注册为文件系统

每当有文件系统注册或者注销的时候，我们的过滤驱动注册的通知回调都会被调用

通过这个回调我们可以将过滤驱动在正确的时间attach或者detach到文件系统中

当文件系统注册时，我们attach到他的控制设备上，然后枚举该设备上所有的volume设备并attach上去

当文件系统deactivate时，我们就检查他的控制设备stack，从中找到我们的设备，detach掉，这个操作通过上面的FsFilterFastIoDetachDevice函数完成

attachdetach.c

这个文件中包含了一些针对attache和detach的helper函数

这个attach这里我是真的读不懂，需要去看一下书查一下资料，在微软的官方文档中，找到了这份关于文件系统过滤驱动的资料

文件系统过滤驱动需要调用IoCreateDevice函数来创建一个过滤设备对象以attach到volume或者文件系统stack上

status = IoCreateDevice(
          gFileSpyDriverObject,                     //DriverObject
          sizeof(MYLEGACYFILTER_DEVICE_EXTENSION),  //DeviceExtensionSize
          NULL,                                     //DeviceName
          DeviceObject->DeviceType,                 //DeviceType
          0,                                        //DeviceCharacteristics
          FALSE,                                    //Exclusive
          &newDeviceObject);                        //DeviceObject

上面代码中DeviceObject参数是我们将要attach到的目标设备对象，newDeviceObject是过滤驱动设备对象自己

新创建的newDeviceObject的DeviceExtension将会指向一个MYLEGACYFILTER_DEVICE_EXTENSION结构体，这个结构体是由我们自己定义的，但是有一个要求，就是MYLEGACYFILTER_DEVICE_EXTENSION结构体中必须要包含下面这个字段：

PDEVICE_OBJECT AttachedToDeviceObject;

DeviceName参数必须被设置为NULL，因为过滤驱动是attach到文件系统或者volume driver stack上的，他不需要名称

DeviceType参数的类型必须和要attach到的目标设备类型一致

下面这个是我们自定义的device extension结构体：

typedef struct _FSFILTER_DEVICE_EXTENSION
{
    PDEVICE_OBJECT AttachedToDeviceObject;
} FSFILTER_DEVICE_EXTENSION, *PFSFILTER_DEVICE_EXTENSION;

detach:

VOID FsFilterDetachFromDevice(PDEVICE_OBJECT DeviceObject) {
    PFSFILTER_DEVICE_EXTENSION pDevExt = (PFSFILTER_DEVICE_EXTENSION)DeviceObject->DeviceExtension;
    IoDetachDevice(pDevExt->AttachedToDeviceObject);
    IoDeleteDevice(DeviceObject);
}

检查我们的过滤驱动设备是否已经attach：

BOOLEAN FsFilterIsMyDeviceObject(PDEVICE_OBJECT DeviceObject) {
    return DeviceObject->DriverObject == g_fsFilterDriverObject;
}

安装驱动

sc create FsFilter type= filesys binPath= c:\FSFilter.sys

执行命令sc start FsFilter来启动我们的过滤驱动

之后我们可以使用DeviceTree看到我们的过滤驱动创建了一堆设备，这些设备是在挂在到volume device上的时候创建出来的

我们的驱动也已经趴到了文件系统上面

可以看到我们的过滤驱动已经爬满了各个文件系统

并且在dbgView中可以截获到一堆文件操作：

停止服务后，我们的过滤驱动就自动卸载了，之前attach上的device也全都detach了

项目文件

关闭其他进程中的句柄

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

references：

https://scorpiosoftware.net/2020/03/15/how-can-i-close-a-handle-in-another-process/

很多人熟悉ProcExp的关闭任意进程中句柄的能力，那么他是怎么完成这项任务的呢

标准的CloseHandle函数只能关闭当前进程的句柄

有两条路线，第一个就是使用内核驱动，前提是你可以加载内核驱动的话，ProcExp使用的就是这种方法

另一种是在用户模式下实现，本文将着重介绍

第一个问题就是如何定位到目标句柄，必须要提供某些条件来唯一标识一个句柄，比如这个句柄是一个命名对象（named object）

使用Windows Media Player作为例子，WMP在同一台机器中只能有一个实例，那么WMP大概率使用了一个互斥量来实现这种效果

通过ProcExp可以看到，他确实是有这么一个互斥量

如果我们关掉这个句柄的话，就可以再打开一个WMP

如果我们想通过编程实现，那么就需要先定位到这个句柄，但是Windows文档中并未提供枚举句柄的函数，即使是在当前进程中

不过我们可以使用NativeAPI

使用NtQuerySystemInformation枚举系统中所有的句柄，然后在里面搜索属于WMP进程的句柄
只枚举WMP进程的句柄
注入代码到WMP进程，在里面遍历WMP进程的所有句柄

第二个选项是最合适的

首先定位WMP进程位置，使用TlHelp32来枚举进程

#include <windows.h>
#include <TlHelp32.h>
#include <stdio.h>

DWORD FindMediaPlayer() {
    HANDLE hSnapshot = ::CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    if (hSnapshot == INVALID_HANDLE_VALUE)
        return 0;

    PROCESSENTRY32 pe;
    pe.dwSize = sizeof(pe);

    // skip the idle process
    ::Process32First(hSnapshot, &pe);

    DWORD pid = 0;
    while (::Process32Next(hSnapshot, &pe)) {
        if (::_wcsicmp(pe.szExeFile, L"wmplayer.exe") == 0) {
            // found it!
            pid = pe.th32ProcessID;
            break;
        }
    }
    ::CloseHandle(hSnapshot);
    return pid;
}


int main() {
    DWORD pid = FindMediaPlayer();
    if (pid == 0) {
        printf("Failed to locate media player\n");
        return 1;
    }
    printf("Located media player: PID=%u\n", pid);
    return 0;
}

现在我们已经定位到WMP了，可以枚举这个进程中的所有句柄了

HANDLE hProcess = ::OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_DUP_HANDLE,
    FALSE, pid);
if (!hProcess) {
    printf("Failed to open WMP process handle (error=%u)\n",
        ::GetLastError());
    return 1;
}

#include <memory>

#pragma comment(lib, "ntdll")

#define NT_SUCCESS(status) (status >= 0)

#define STATUS_INFO_LENGTH_MISMATCH      ((NTSTATUS)0xC0000004L)

enum PROCESSINFOCLASS {
    ProcessHandleInformation = 51
};

typedef struct _PROCESS_HANDLE_TABLE_ENTRY_INFO {
    HANDLE HandleValue;
    ULONG_PTR HandleCount;
    ULONG_PTR PointerCount;
    ULONG GrantedAccess;
    ULONG ObjectTypeIndex;
    ULONG HandleAttributes;
    ULONG Reserved;
} PROCESS_HANDLE_TABLE_ENTRY_INFO, * PPROCESS_HANDLE_TABLE_ENTRY_INFO;

// private
typedef struct _PROCESS_HANDLE_SNAPSHOT_INFORMATION {
    ULONG_PTR NumberOfHandles;
    ULONG_PTR Reserved;
    PROCESS_HANDLE_TABLE_ENTRY_INFO Handles[1];
} PROCESS_HANDLE_SNAPSHOT_INFORMATION, * PPROCESS_HANDLE_SNAPSHOT_INFORMATION;

extern "C" NTSTATUS NTAPI NtQueryInformationProcess(
    _In_ HANDLE ProcessHandle,
    _In_ PROCESSINFOCLASS ProcessInformationClass,
    _Out_writes_bytes_(ProcessInformationLength) PVOID ProcessInformation,
    _In_ ULONG ProcessInformationLength,
    _Out_opt_ PULONG ReturnLength);

使用ProcessHandleInformation获取所有的句柄信息

ULONG size = 1 << 10;
std::unique_ptr<BYTE[]> buffer;
for (;;) {
    buffer = std::make_unique<BYTE[]>(size);
    auto status = ::NtQueryInformationProcess(hProcess, ProcessHandleInformation, 
        buffer.get(), size, &size);
    if (NT_SUCCESS(status))
        break;
    if (status == STATUS_INFO_LENGTH_MISMATCH) {
        size += 1 << 10;
        continue;
    }
    printf("Error enumerating handles\n");
    return 1;
}

上面使用了智能指针在内存不够的情况下自动增大

我们还需要调用另一个NativeAPI——NtQueryObject来查询指定句柄的信息

typedef enum _OBJECT_INFORMATION_CLASS {
    ObjectNameInformation = 1
} OBJECT_INFORMATION_CLASS;

typedef struct _UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
} UNICODE_STRING;

typedef struct _OBJECT_NAME_INFORMATION {
    UNICODE_STRING Name;
} OBJECT_NAME_INFORMATION, * POBJECT_NAME_INFORMATION;

extern "C" NTSTATUS NTAPI NtQueryObject(
    _In_opt_ HANDLE Handle,
    _In_ OBJECT_INFORMATION_CLASS ObjectInformationClass,
    _Out_writes_bytes_opt_(ObjectInformationLength) PVOID ObjectInformation,
    _In_ ULONG ObjectInformationLength,
    _Out_opt_ PULONG ReturnLength);

我们现在是外部进程，我们不能直接往NtQueryObject传递从WMP进程中获取的句柄，而是要先将句柄复制出来再传进去，这也是为什么一开始打开WMP进程的时候需要加入PROCESS_DUP_HANDLE权限

auto info = reinterpret_cast<PROCESS_HANDLE_SNAPSHOT_INFORMATION*>(buffer.get());
for (ULONG i = 0; i < info->NumberOfHandles; i++) {
    HANDLE h = info->Handles[i].HandleValue;
    HANDLE hTarget;
    if (!::DuplicateHandle(hProcess, h, ::GetCurrentProcess(), &hTarget, 
        0, FALSE, DUPLICATE_SAME_ACCESS))
        continue;   // move to next handle
}

BYTE nameBuffer[1 << 10];
auto status = ::NtQueryObject(hTarget, ObjectNameInformation, 
    nameBuffer, sizeof(nameBuffer), nullptr);
::CloseHandle(hTarget);
if (!NT_SUCCESS(status))
    continue;

调用完NtQueryObject之后，就可以把复制出来的句柄关掉了，我们需要将获取到的字符串和WMP互斥量的名称进行对比以得到正确的句柄

WCHAR targetName[256];
DWORD sessionId;
::ProcessIdToSessionId(pid, &sessionId);
::swprintf_s(targetName,
    L"\\Sessions\\%u\\BaseNamedObjects\\Microsoft_WMP_70_CheckForOtherInstanceMutex", 
    sessionId);
auto len = ::wcslen(targetName);

auto name = reinterpret_cast<UNICODE_STRING*>(nameBuffer);
if (name->Buffer && 
    ::_wcsnicmp(name->Buffer, targetName, len) == 0) {
    // found it!
}

假设我们现在找到了目标句柄，那么下一步要怎么做呢？

我们可以再次调用DuplicateHandle，但是传入DUPLICATE_CLOSE_SOURCE标志变相达到关闭源句柄的目的

// found it!
::DuplicateHandle(hProcess, h, ::GetCurrentProcess(), &hTarget,
    0, FALSE, DUPLICATE_CLOSE_SOURCE);
::CloseHandle(hTarget);
printf("Found it! and closed it!\n");
return 0;

完整代码：

#include <windows.h>
#include <TlHelp32.h>
#include <stdio.h>
#include <memory>

#pragma comment(lib, "ntdll")

#define NT_SUCCESS(status) (status >= 0)

#define STATUS_INFO_LENGTH_MISMATCH      ((NTSTATUS)0xC0000004L)

enum PROCESSINFOCLASS {
    ProcessHandleInformation = 51
};

typedef struct _PROCESS_HANDLE_TABLE_ENTRY_INFO {
    HANDLE HandleValue;
    ULONG_PTR HandleCount;
    ULONG_PTR PointerCount;
    ULONG GrantedAccess;
    ULONG ObjectTypeIndex;
    ULONG HandleAttributes;
    ULONG Reserved;
} PROCESS_HANDLE_TABLE_ENTRY_INFO, * PPROCESS_HANDLE_TABLE_ENTRY_INFO;

// private
typedef struct _PROCESS_HANDLE_SNAPSHOT_INFORMATION {
    ULONG_PTR NumberOfHandles;
    ULONG_PTR Reserved;
    PROCESS_HANDLE_TABLE_ENTRY_INFO Handles[1];
} PROCESS_HANDLE_SNAPSHOT_INFORMATION, * PPROCESS_HANDLE_SNAPSHOT_INFORMATION;

extern "C" NTSTATUS NTAPI NtQueryInformationProcess(
    _In_ HANDLE ProcessHandle,
    _In_ PROCESSINFOCLASS ProcessInformationClass,
    _Out_writes_bytes_(ProcessInformationLength) PVOID ProcessInformation,
    _In_ ULONG ProcessInformationLength,
    _Out_opt_ PULONG ReturnLength);


DWORD FindMediaPlayer() {
    HANDLE hSnapshot = ::CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    if (hSnapshot == INVALID_HANDLE_VALUE)
        return 0;

    PROCESSENTRY32 pe;
    pe.dwSize = sizeof(pe);

    // skip the idle process
    ::Process32First(hSnapshot, &pe);

    DWORD pid = 0;
    while (::Process32Next(hSnapshot, &pe)) {
        if (::_wcsicmp(pe.szExeFile, L"wmplayer.exe") == 0) {
            // found it!
            pid = pe.th32ProcessID;
            break;
        }
    }
    ::CloseHandle(hSnapshot);
    return pid;
}
typedef enum _OBJECT_INFORMATION_CLASS {
    ObjectNameInformation = 1
} OBJECT_INFORMATION_CLASS;

typedef struct _UNICODE_STRING {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR  Buffer;
} UNICODE_STRING;

typedef struct _OBJECT_NAME_INFORMATION {
    UNICODE_STRING Name;
} OBJECT_NAME_INFORMATION, * POBJECT_NAME_INFORMATION;

extern "C" NTSTATUS NTAPI NtQueryObject(
    _In_opt_ HANDLE Handle,
    _In_ OBJECT_INFORMATION_CLASS ObjectInformationClass,
    _Out_writes_bytes_opt_(ObjectInformationLength) PVOID ObjectInformation,
    _In_ ULONG ObjectInformationLength,
    _Out_opt_ PULONG ReturnLength);

int main() {
    DWORD pid = FindMediaPlayer();
    if (pid == 0) {
        printf("Failed to locate media player\n");
        return 1;
    }
    printf("Located media player: PID=%u\n", pid);
    HANDLE hProcess = ::OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_DUP_HANDLE,
        FALSE, pid);
    if (!hProcess) {
        printf("Failed to open WMP process handle (error=%u)\n",
            ::GetLastError());
        return 1;
    }

    ULONG size = 1 << 10;
    std::unique_ptr<BYTE[]> buffer;
    for (;;) {
        buffer = std::make_unique<BYTE[]>(size);
        auto status = ::NtQueryInformationProcess(hProcess, ProcessHandleInformation,
            buffer.get(), size, &size);
        if (NT_SUCCESS(status))
            break;
        if (status == STATUS_INFO_LENGTH_MISMATCH) {
            size += 1 << 10;
            continue;
        }
        printf("Error enumerating handles\n");
        return 1;
    }

    WCHAR targetName[256];
    DWORD sessionId;
    ::ProcessIdToSessionId(pid, &sessionId);
    ::swprintf_s(targetName,
        L"\\Sessions\\%u\\BaseNamedObjects\\Microsoft_WMP_70_CheckForOtherInstanceMutex",
        sessionId);
    auto len = ::wcslen(targetName);
    auto info = reinterpret_cast<PROCESS_HANDLE_SNAPSHOT_INFORMATION*>(buffer.get());
    for (ULONG i = 0; i < info->NumberOfHandles; i++) {
        HANDLE h = info->Handles[i].HandleValue;
        HANDLE hTarget;
        if (!::DuplicateHandle(hProcess, h, ::GetCurrentProcess(), &hTarget,
            0, FALSE, DUPLICATE_SAME_ACCESS))
            continue;   // move to next handle
        BYTE nameBuffer[1 << 10];
        auto status = ::NtQueryObject(hTarget, ObjectNameInformation,
            nameBuffer, sizeof(nameBuffer), nullptr);
        ::CloseHandle(hTarget);
        if (!NT_SUCCESS(status))
            continue;
        auto name = reinterpret_cast<UNICODE_STRING*>(nameBuffer);
        if (name->Buffer &&
            ::_wcsnicmp(name->Buffer, targetName, len) == 0) {
            // found it!
            ::DuplicateHandle(hProcess, h, ::GetCurrentProcess(), &hTarget,
                0, FALSE, DUPLICATE_CLOSE_SOURCE);
            ::CloseHandle(hTarget);
            printf("Found it! and closed it!\n");
            return 0;
        }
    }

    return 0;
}

进程注入场景下的shellcode混淆

2023-10-29T00:00:00+02:00

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

references:

一直没有找到比较好的shellcode混淆方法，尝试过直接使用OLLVM来编译出asm文件，之后再进行链接，但是总是会报一堆错误，后来尝试了使用PE2SHC来将混淆后的PE直接转换为shellcode进行注入，但是被注入的程序总是会莫名其妙的崩溃，而且使用PE2SHC很容易被杀软识别出来，因为他在最后面添加的那一段PE Loader的代码特征太明显了

为了解决以上的问题，我仔细看了一下ReflectiveDLLInjection项目的源代码，最终形成了下面的解决方案：

在编写shellcode代码的时候除了调用GetModuleHandleA和GetProcAddress这两个kernel32.dll中的API用于加载kernel32.dll并从中获取LoadLibraryA和GetProcAddress这两个函数外，不再直接调用win32 API
不使用除了win32 API之外的函数，如printf等
在链接的时候，指定程序入口为main函数

其中第一点和第二点都是为了在注入shellcode的时候，不在目标进程中额外加载其他dll，因为在我的认知范围内，还没有哪个程序运行的时候不需要加载kernel32.dll，因此我们可以直接使用目标进程现成的kernel32.dll模块

对于第三点，大家可以参考这篇文章，默认情况下VS生成的PE文件的EntryPoint并不是main函数，而是__security_init_cookie，之后它会调用__scrt_common_main_seh，该函数最终会调用main函数，但是我们并不需要前面这些进行初始化和setup的函数，而且他们正是导致目标程序在注入之后崩溃的原因，在shellcode项目中进行如下设置即可

在这种设置下生成的PE文件的导入表只有两个导入函数

在PE Loader中，只有两个地方需要对代码中的内存地址进行修正，一个是导入表，另一个就是base relocation

我们只需要在进行这两步操作的时候，使用目标进程中kernel32.dll模块的地址和PE文件将要加载到目标进程中的内存地址（基地址）即可

思路就是先在注入程序中把PE文件加载好，然后整个拷贝到目标进程中就行了

下面是一个例子，我们的shellcode只干了一件事，就是加载lsasrv.dll，shellcode运行完成后，injector会释放在目标进程中开辟的内存空间，injector接收两个参数，第一个是目标进程的PID，第二个是shellcode的PE文件

injector.exe+PE.exe

这两个文件都已经经过了混淆处理

injector.exe源代码

PE.exe的源码：

#include<Windows.h>

typedef
FARPROC
(NTAPI* PNT_GetProcAddress)(
    HMODULE hModule,
    LPCSTR  lpProcName
    );

typedef
HMODULE
(NTAPI* PNT_LoadLibraryA)(
    LPCSTR lpLibFileName
    );

int main() {
    HMODULE ahndleeeeer = GetModuleHandleA("kernel32.dll");
    DWORD64   _kernel32_base_addr = reinterpret_cast<DWORD64>(ahndleeeeer);
    PNT_LoadLibraryA NT_LoadLibraryA = (PNT_LoadLibraryA)GetProcAddress(ahndleeeeer, "LoadLibraryA");
    PNT_GetProcAddress NT_GetProcAddress = (PNT_GetProcAddress)GetProcAddress(ahndleeeeer, "GetProcAddress");
    NT_LoadLibraryA("C:\\windows\\system32\\lsasrv.dll");
}

理解PE文件的导入表

2023-10-26T00:00:00+02:00

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

references：

如果你不熟悉PE文件中va和rva的概念，可以参考这里

其实PE文件的导入表非常好理解，只要看懂下面这张图就行了

其中最关键的就是IMAGE_IMPORT_DIRECTORY结构体，我们主要关注第一个和最后一个字段

rvaImportLookupTable
rvaImportAddressTable

用最简单的一句话来描述这两个字段就是前者是给PE Loader用来查找导入DLL的函数地址的，后者是给PE文件中的代码用来得到正确的函数地址的

PE Loader通过前者从DLL中获取到正确的函数地址，然后填充到后者中，最终在代码执行的时候，会通过后者来获取函数地址

这里我使用一个很简单的PE文件来举例子，我这个PE文件只有两个导入函数

分别是kernel32.ExitProcess和user32.MessageBoxA

在IDA中打开该PE文件

查看call cs:MessageBoxA对应的16进制为FF15D70F0000，使用defuse.ca反编译得到如下结果

可以看到，这里call指令的操作数是从内存地址rip+0xFD7取出来的一个QWORD，也就是说在编译和链接阶段，生成的PE文件中的代码，并不会直接call导入函数，而是从一个内存地址中取出导入函数的地址，而在PE Loader将PE正确加载到内存之前，这个地址中并没有存储正确的导入函数地址，PE Loader的工作就是根据rvaImportLookupTable找到正确的导入函数地址，然后放到这个地址中

rip总是下一条指令的地址，即0x140001039，那么计算出来的内存地址就是0x140002010，Optional Header中ImageBase字段的值为0x140000000

那么这个地址的rva就是0x2010，和PE-bear中显示的USER32.dll的FirstThunk字段的值是一致的（FirstThunk就是rvaImportAddressTable的第一个entry）

这里有一段摘抄于RDI的代码（有一个地方进行了修改），大家可以结合上面理解一下

// uiValueD就是rvaImportLookupTable的地址，这里通过和0x8000000000000000进行and运算来判断是否通过ordinal来定位导入函数的地址
if (uiValueD && ((PIMAGE_THUNK_DATA)uiValueD)->u1.Ordinal & IMAGE_ORDINAL_FLAG)
{
    // uiLibraryAddress是导入的DLL在内存中的基地址，这里获取到导入DLL的NT Header地址
    uiExportDir = uiLibraryAddress + ((PIMAGE_DOS_HEADER)uiLibraryAddress)->e_lfanew;

    // 获取到导入DLL的DATA_DIRECTORY结构体的地址
    uiNameArray = (ULONG_PTR) & ((PIMAGE_NT_HEADERS)uiExportDir)->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];

    // 获取到导入DLL的导出表的地址
    uiExportDir = (uiLibraryAddress + ((PIMAGE_DATA_DIRECTORY)uiNameArray)->VirtualAddress);

    // 从导出表中获取到导出函数数组地址
    uiAddressArray = (uiLibraryAddress + ((PIMAGE_EXPORT_DIRECTORY)uiExportDir)->AddressOfFunctions);

    // 从前面那张导入表结构体的示意图我们知道，如果使用ordinal的方式来定位导入函数的地址，那么除了最高位，剩下的bit位将用于表示ordinal的值
    // 不过这里不知道为啥进行and运算的是0xFFFF，只有16bit，可能ordinal的值最大也就这么大了吧
    // 获取到ordinal value之后，和导出表的base字段值相减，因为每个entry占4bytes，相减的结果乘以4再加上导出函数数组的地址，就是导出函数相对于DLL基地址的偏移的地址
    uiAddressArray += ((IMAGE_ORDINAL(((PIMAGE_THUNK_DATA)uiValueD)->u1.Ordinal) - ((PIMAGE_EXPORT_DIRECTORY)uiExportDir)->Base) * sizeof(DWORD));

    // 使用基地址+偏移得到导入函数的正确地址，并将该地址放到rvaImportAddressTable中
    DEREF(uiValueA) = (uiLibraryAddress + DEREF_32(uiAddressArray));
}
else
{
    // 根据导入表结构体示意图我们可以知道，如果最高bit位为0，那么uiValueD中保存的就是IMAGE_IMPORT_BY_NAME结构体的rva
    // 和PE文件的基地址相加即可得到IMAGE_IMPORT_BY_NAME结构体的地址
    uiValueB = (uiBaseAddress + DEREF(uiValueD));

    // 通过GetProcAddress获取指定名称的函数地址，并将其放入rvaImportAddressTable中
    DEREF(uiValueA) = (ULONG_PTR)pGetProcAddress((HMODULE)uiLibraryAddress, (LPCSTR)((PIMAGE_IMPORT_BY_NAME)uiValueB)->Name);
}

我把项目文件也放上来，大家可以在VS中进行调试来更好地理解

使用Obfuscator-LLVM对二进制代码进行混淆

2023-10-20T00:00:00+02:00

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

参考文章：

你需要在一台安装了VS2017的机器上进行下面的操作

准备工作，需要先安装python3，然后要安装cmake，然后下载这个文件

解压之后，进入并创建build目录，进入build目录打开cmd，执行如下命令

"C:\Program Files\CMake\bin\cmake.exe" -G "Visual Studio 15 2017 Win64" ..

这条命令会给你生成一堆VS2017项目文件，就在build目录下

打开ALL_BUILD.vcxproj

然后找到obfuscator\include\llvm\CryptoUtils.h，在81行下面添加下面的语句

#define ENDIAN_LITTLE

然后调整到RELEASE，右键ALL_BUILD生成即可

当然如果你不想进行上面这一堆操作，你可以尝试直接使用我编译好的

然后我们打开VS2019

然后关闭VS2019，在vs_installer中进行如下操作

把这两个都安装上之后，启动VS2019

然后把我们上面编译出来的Obfuscator-LLVM拷贝到vs_installer刚才安装的clang-cl.exe所在的目录下

目标目录：

你们应该也是这个目录

编译好的Obfuscator-LLVM二进制文件目录：

把第二张图显示的目录中的所有文件覆盖拷贝到第一张图的目录中

之后进行如下设置：

把diagnostics format选项清空，不然会引起编译错误

添加如下命令行选项：

-D__CUDACC__ -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH -mllvm -bcf -mllvm -bcf_prob=73 -mllvm -bcf_loop=1 -mllvm -sub -mllvm -sub_loop=5 -mllvm -fla -mllvm -split_num=5 -mllvm -aesSeed=DEADBEEFDEADCODEDEADBEEFDEADCODE

然后就可以正常使用了

这是混淆前后的exe在IDA中的拓扑图对比

Windows Message Loop

2022-06-11T00:00:00+02:00

references:

http://www.winprog.org/tutorial/message_loop.html

excellent post

Message

windows message is just integers

#define WM_INITDIALOG                   0x0110
#define WM_COMMAND                      0x0111

#define WM_LBUTTONDOWN                  0x0201
....

messages are often used to communicate between windows

event like keyboard typing, mouse moving, etc will trigger the system send a message to correspond window

if you're the target window, you'll need to handle the message

every message may have 2 param bound with it, wParam and lParam, wParam->16bit, lParam->32bit, they both are 32bit in win32

these 2 param not always be used, depends on message kind

PostMessage and SendMessage can be used to send message

PostMessage will puts message into Message Queue and returns immediately, which means in the time PostMessage returns, the message send by it may or may not been processed

while SendMessage sends message directly to the target window, and will not return until the message been processed

for example, if we want to close a window, we can do this:

SendMessage(hwnd, WM_CLOSE, 0, 0);

Dialog

to control dialog box, you can do this:

hwnd = GetDlgItem(...);
SnedMessage(hwnd, message, ...);

or just this:

SendDlgItemMessage(...);

Message Queue

let's say you are busy on handling WM_PAINT message, at the same time, user types keyboard, what should happen now?

interrupt your drawing or drop the keys that user just input?

either are good solution, so message queue born, when message posted, they are added to message queue and they will not be removed until be handled

this will make sure every message is handled

Message Loop

while(GetMessage(&Msg, NULL, 0, 0) > 0) {
    TranslateMessage(&Msg);
    DispatchMessage(&Msg);
}

GetMessage will retrieve message from message queue, if the queue is empty, it will simply block until there is a message
event triggers message being added to message queue, GetMessage will return a positive value to indicate that there is a message to be processed, the Msg pointer point to a message structure MSG, this structure will be filled by GetMessage, if the message retrieved is WM_QUIT, then 0 is returned, return negative value to indicate there is an error occurred
message retrieved by GetMessage will be past to TranslateMessage as a param, this function will translate virtual key message to character message
then we pass the translated message to DispatchMessage, it will check which window the message is for and looks up windowproc for this window, then it will calls the founded windowproc and sending window handle, message and w/lParam as param to this proc
windowproc is your code, you need to check the message and related params, then do whatever you want! If you're not handling the message, you can just call DefWindowProc to perform default actions (which often means doing nothing)
after you finish message processing, your windowproc returns to DispatchMessage, then you back to the message loop

this is very important concept for windows programming, your windowsproc is not magically called by system, in fact, you're calling your own code indirectly from DispatchMessage function

if you want, you can use GetWindowLong with the window handle that the message is for to lookup your windowproc code and call it directly, without calling DispatchMessage

while(GetMessage(&Msg, NULL, 0, 0) > 0) {
    WNDPROC fWndProc = (WNDPROC)GetWindowLong(Msg.hwnd, GWL_WNDPROC);
    fWndProc(Msg.hwnd, Msg.message, Msg.wParam, Msg.lParam);
}

PostQuitMessage will terminate the message loop, this function put a WM_QUIT to the message queue

here is a demo project you can play with

C# await操作符

2021-12-30T00:00:00+01:00

references:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/await

前言

最近在看一个使用.Net实现的Kerberos库的代码，全是C#代码，里面很多语法都不太懂，这里做一下记录

正文

废话不多说，先上代码：

using System;
using System.Net.Http;
using System.Threading.Tasks;

public class AwaitOperator
{
    public static async Task Main()
    {
        Task<int> downloading = DownloadDocsMainPageAsync();
        Console.WriteLine($"{nameof(Main)}: Launched downloading.");

        int bytesLoaded = await downloading;
        Console.WriteLine($"{nameof(Main)}: Downloaded {bytesLoaded} bytes.");
    }

    private static async Task<int> DownloadDocsMainPageAsync()
    {
        Console.WriteLine($"{nameof(DownloadDocsMainPageAsync)}: About to start downloading.");

        var client = new HttpClient();
        byte[] content = await client.GetByteArrayAsync("https://docs.microsoft.com/en-us/");

        Console.WriteLine($"{nameof(DownloadDocsMainPageAsync)}: Finished downloading.");
        return content.Length;
    }
}

await操作符会将使用async关键字修饰的方法挂起，我不太确定挂起这个说法准不准确，我们拿上面的代码来说，DownloadDocsMainPageAsync方法被调用之后会理解返回到Main方法中，也就是说它不会阻塞Main方法的执行

Main方法会在await操作符出现的地方阻塞，而此时DownloadDocsMainPageAsync方法已经执行了一段时间了，当然在上面的代码中体现不出来，因为在方法调用和真正用到方法返回值之间只有一个简单的输出

此时Main方法会等待DownloadDocsMainPageAsync异步方法的返回值，而在该方法中，它也正在等待GetByteArrayAsync方法的返回值，当这两个方法依次完成异步操作之后，Main方法继续执行剩余的代码

我们可以在Main方法中加一个Sleep来更直观地看到异步执行的效果：

using System;
using System.Net.Http;
using System.Threading;
using System.Threading.Tasks;

public class AwaitOperator
{
    public static async Task Main()
    {
        Task<int> downloading = DownloadDocsMainPageAsync();
        Console.WriteLine($"{nameof(Main)}: Launched downloading.");
        for (var i=0; i<5; i++){
            Console.WriteLine("tick tock...");
            Thread.Sleep(1000);
        }
        int bytesLoaded = await downloading;
        Console.WriteLine($"{nameof(Main)}: Downloaded {bytesLoaded} bytes.");
    }

    private static async Task<int> DownloadDocsMainPageAsync()
    {
        Console.WriteLine($"{nameof(DownloadDocsMainPageAsync)}: About to start downloading.");

        var client = new HttpClient();
        byte[] content = await client.GetByteArrayAsync("https://docs.microsoft.com/en-us/");

        Console.WriteLine($"{nameof(DownloadDocsMainPageAsync)}: Finished downloading.");
        return content.Length;
    }
}

可以看到异步方法被调用之后，并不会立刻返回，而是去执行方法体中的代码，当执行到await修饰的异步方法时会立即返回到主方法，同时异步方法GetByteArrayAsync开始下载数据

最后在Main方法中使用await操作符获取异步方法的返回值

Task类

你在读上面的代码时候可能会产生一个疑问，DownloadDocsMainPageAsync的返回值明明是一个Task<int>类型的，为什么却可以写出下面的代码呢？

int bytesLoaded = await downloading;

这里就体现出await操作符的作用了，在C#中，Task<?>表示一个可以返回?类型返回值的方法

如果我们把await操作符删除掉，就会出现如下错误

只有使用await操作符才可以获取到异步方法中Task<?>中的?类型的返回值

结语

没有系统学习过C#，参考着文档以及示例代码琢磨的，大概率有说的不对的地方，希望大家可以指正

java枚举 enum

2021-12-07T00:00:00+01:00

java中的枚举类有一个隐含的方法：values()

该方法会返回枚举类型的所有值

根据java官方文档的介绍，enum关键字的实现，编译器会在enum创建的时候自动加入几个特殊的方法

其中就有静态方法values()

另外枚举类还自动继承了java.lang.Enum这个类，又因为java不支持多继承，因此枚举类型无法继承任何类

Lombok库的@RequiredArgsConstructor注解

2021-12-07T00:00:00+01:00

该注解会生成带有参数的构造函数

这里的参数指的是所有final修饰的未初始化的字段以及使用了@NonNull注解修饰的字段

生成的构造函数，默认权限修饰符为public

下面为带注解的代码与不带注解的代码对比

@RequiredArgsConstructor
public class RequiredArgsDemo1 {

  private Long id;

  @NonNull
  private String username;

  @NonNull
  private String email;

  private final boolean status;
}

public class RequiredArgsDemo1 {
  private Long id;
  @NonNull
  private String username;
  @NonNull
  private String email;
  private final boolean status;

  public RequiredArgsDemo1(
      @NonNull final String username, 
      @NonNull final String email, 
      final boolean status
      ) {

    if (username == null) {
      throw new NullPointerException("username is marked non-null but is null");
    }
    if (email == null) {
      throw new NullPointerException("email is marked non-null but is null");
    }
    this.username = username;
    this.email = email;
    this.status = status;
  }
}

可以看到，使用了注解的代码相对于原始代码要简洁很多，无需我们再手动编写含参构造函数

Supplier接口

2021-12-07T00:00:00+01:00

该接口位于java.util.function包，在java 8引入，主要用于函数式编程

也就是说，被该接口修饰的变量就是一个方法，该方法不接收任何参数，但是会返回一个Supplier<T>所指定的泛型T

看下面的代码示例：

import java.util.function.Supplier;

class CopperCoin {
    static final String DESCRIPTION = "This is a copper coin.";

    public String getDescription() {
        return DESCRIPTION;
    }
}

public class Main {
    public static void main(String args[]) {
        Supplier<CopperCoin> randomValue = CopperCoin::new;

        System.out.println(randomValue.get().getDescription());
    }
}

注意看这一行：

Supplier<CopperCoin> randomValue = CopperCoin::new;

正常来讲呢，应该是一个lambda表达式的写法：

Supplier<CopperCoin> randomValue = () -> (new CopperCoin());

CopperCoin::new是在java 8中引入的一个特性，可以让你的lambda表达式变得更加简洁

编译器会自动为这种形式的代码生成接口实现代码

在本例中，实现的是Supplier接口的T get()方法

Python2多线程

2021-06-25T00:00:00+02:00

渗透测试过程中，经常需要编写一些python小工具

但是单线程太慢了，多线程可以极快地提高效率

我们可以直接通过一个例子来学习多线程脚本的编写

下面是一个验证域名是否有效的python脚本

#!/usr/bin/python

import Queue
import threading
import time
import os
import sys
import socket
exitFlag = False
f = open(sys.argv[1])
marylines = f.readlines()
f.close()
countttter = threading.Lock()
countttterssss=0
tottttt = len(marylines)
class myThread (threading.Thread):
   def __init__(self, threadID, name, q):
        threading.Thread.__init__(self)
        self.threadID = threadID
        self.name = name
        self.q = q
   def run(self):
        print "Starting " + self.name
        process_data(self.name, self.q)
        print "Exiting " + self.name

def process_data(threadName, q):
   while not exitFlag:
        queueLock.acquire()
        if not workQueue.empty():
            data = q.get()
            queueLock.release()
            print "%s processing %s" % (threadName, data)
            #print data
            try:
                socket.gethostbyname(data.strip())
                filelock.acquire()
                ssssssssssssf = open(sys.argv[3],'a')
                ssssssssssssf.write(data)
                ssssssssssssf.close()
                filelock.release()

            except socket.gaierror:
                print "unable to get address for: ", data
            countttter.acquire()
            global countttterssss
            countttterssss = countttterssss + 1
            print  str(countttterssss) + '-----------------------------' + str(tottttt) + '\n'
            countttter.release()
        else:
            queueLock.release()
       # time.sleep(1)
threadList= []
for fuck in range(0,int(sys.argv[2])):
    threadList.append("Thread-"+str(fuck))
#threadList = ["Thread-1", "Thread-2", "Thread-3"]
#nameList = ["One", "Two", "Three", "Four", "Five"]
queueLock = threading.Lock()
filelock = threading.Lock()
workQueue = Queue.Queue(len(marylines))
threads = []
threadID = 1

# Create new threads
for tName in threadList:
    thread = myThread(threadID, tName, workQueue)
    thread.start()
    threads.append(thread)
    threadID += 1

# Fill the queue
queueLock.acquire()
for word in marylines:
    workQueue.put(word)
queueLock.release()

# Wait for queue to empty
while not workQueue.empty():
    pass

# Notify threads it's time to exit

exitFlag = True

# Wait for all threads to complete
for t in threads:
    t.join()
print "Exiting Main Thread"

关于程序整个流程的解释

首先打开一个文件

进行readline操作，将每一行读取出来，形成一个列表存到marylines变量中

然后根据传入的第二个参数（线程数量），生成以数字进行编号的线程名称（这一部可以省略，因为线程无所谓名称），不进行编号脚本也可以正常工作

然后创建两个锁，一个用来锁队列，一个用来锁文件

创建一个队列，队列长度为marylines列表长度（待处理的域名）

声明一个空的threads列表，用于存储所有的变量，这个在后面join结束进程的时候会用到

在for循环中，启动所有进程同时将进程对象存入threads列表中

给队列加锁，然后往队列里面填充待处理的域名字符串，填充完毕，开锁

在队列空之前一直循环避免程序结束

然后我们来看线程的内容

主函数为process_data

给队列加锁，判断队列空了没

没空则取出来一个域名，然后开锁

打印出当前线程名称以及待处理的域名

用try-catche语句包裹域名解析的代码

使用socket.gethostbyname解析域名，抛出异常则后面的代码不会执行，打印出当前域名无法解析的信息

未抛出异常则给文件加锁，将域名以追加的形式写入到第三个参数指定的文件中

写入完毕，开锁

在try-catche语句外部，

给counter加锁，然后更改counter的值（+1），然后打印出当前counter的值以及总共的值，然后开锁

counter锁在程序最前面进行了声明

最后是判断队列是否为空的else分支：给队列开锁

我试了一下，直接开50个线程，速度还是很快的

symfony之container(容器)

2021-06-07T00:00:00+02:00

前言

symfony是一个php框架，这篇文章我将会介绍symfony的container（容器）

symfony引入容器是为了更好地管理项目中各个类之间的依赖关系

就像java的Spring框架一样，symfony框架也拥有依赖注入功能，而该功能通过container来实现，在symfony中，container是一个包含了许多对象的容器，该容器中的对象会自动处理依赖关系，容器中的对象叫做服务

正文

示例项目源代码：

https://gitee.com/wochinijiamile/smartya/raw/master/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.7z

下载解压之后，进入项目目录，运行composer install，然后再运行composer dump-autoload即可

这是一个权限检查类的程序，包括两个实体类：User和Post，前者代表用户，后者代表票

一个投票人接口以及其实现类：VoterInterface和PostVoter

一个用来管理权限的类：AccessManager，该类有一个decide方法用于决定给定用户是否对指定的post对象拥有特定的权限

Definition

index.php

<?php

require __DIR__.'/../vendor/autoload.php';

use App\Authorization\AccessManager;
use App\Authorization\Voter\PostVoter;
use App\Entity\Post;
use App\Entity\User;
use Symfony\Component\DependencyInjection\ContainerBuilder;

$containerBuilder = new ContainerBuilder();

$postVoter = new PostVoter();
$manager = new AccessManager([$postVoter]);

$containerBuilder->set('post_voter', $postVoter);
$containerBuilder->set('access_manager', $manager);

dump($containerBuilder->get('access_manager'));
dump($containerBuilder->get('post_voter'));

这里使用了symfony的container，初始化一个ContainerBuilder类，即可创建出一个container，然后我们使用set方法将我们的对象放到该容器中，第一个参数就是我们的对象在容器中的名称

使用get即可取出指定名称的对象

但是上面这种写法在往容器中放对象的时候已经实例化了我们的PostVoter类和AccessManager类，但是我们还没有到使用这两个对象的时候，提前初始化被认为是对时间和内存资源的浪费

因此，symfony引入了Definition这个概念，来告诉容器何时以及如何实例化我们放入其中的类

<?php

require __DIR__.'/../vendor/autoload.php';

use App\Authorization\AccessManager;
use App\Authorization\Voter\PostVoter;
use App\Entity\Post;
use App\Entity\User;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Definition;
use Symfony\Component\DependencyInjection\Reference;

$containerBuilder = new ContainerBuilder();

$voterDefinition = new Definition(PostVoter::class);
$containerBuilder->setDefinition('post_voter', $voterDefinition);

$managerDefinition = new Definition(AccessManager::class);
$managerDefinition->addArgument([new Reference('post_voter')]);
$containerBuilder->setDefinition('access_manager', $managerDefinition);

$accessManager = $containerBuilder->get('access_manager');
dump($accessManager);

可以看到，之前实例化类的部分变成了Definition，使用类的FQCN作为参数，另外set方法也被替换成了setDefinition方法

对$managerDefinition额外调用了addArgument方法来设置access_manager在初始化时构造函数的参数，这里用了post_voter的Reference

上面的代码在真正执行$accessManager = $containerBuilder->get('access_manager')这行代码之后完全没有创建任何PostVoter或AccessManager对象

我们可以使用容器的register方法来省略创建Definition对象的步骤：

<?php

require __DIR__.'/../vendor/autoload.php';

use App\Authorization\AccessManager;
use App\Authorization\Voter\PostVoter;
use App\Entity\Post;
use App\Entity\User;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Definition;
use Symfony\Component\DependencyInjection\Reference;

$containerBuilder = new ContainerBuilder();

$containerBuilder->register("post_voter", PostVoter::class);
$containerBuilder->register("access_manager", AccessManager::class)
    ->addArgument([new Reference('post_voter')]);

$accessManager = $containerBuilder->get('access_manager');
dump($accessManager);

作用域

在上面的例子中，post_voter对我们来说是没有太多作用的，他只需要由access_manager来进行管理就行了，我们没必要使用get将其从容器中取出来**

ContainerBuilder提供了private和public服务的概念，我们可以在Definition中进行设置，被设置了private的服务是无法通过容器的get方法进行获取的

用法非常简单，只需要调用setPublic方法即可，参数为布尔型，true则为public，false则为private

$containerBuilder->register("post_voter", PostVoter::class)
    ->setPublic(false);
$containerBuilder->compile();

使用上面的代码即可将post_voter设置为private，compile方法用于使该设置生效

使用symfony的Config组件来管理配置

我们这里使用php文件作为配置文件的文件类型

config/config.php

<?php
// config/config.php

use App\Authorization\AccessManager;
use App\Authorization\Voter\PostVoter;
use Symfony\Component\DependencyInjection\Reference;

$container->register('post_voter', PostVoter::class)
    ->setPublic(false);
$container->register('access_manager', AccessManager::class)
    ->setPublic(true)
    ->addArgument([new Reference('post_voter')]);

在配置文件中$container变量和$loader变量是可以直接访问的

前者是容器，后者是PhpFileLoader对象

上面的配置文件注册了两个服务，并给access_manager设置了构造函数的参数

在index.php中只需要将配置文件加载上来就行了

$containerBuilder = new ContainerBuilder();

$loader = new PhpFileLoader($containerBuilder, new FileLocator(__DIR__.'/../config'));
// we'll create a config/config.php file to handle our configuration
$loader->load('config.php');

$containerBuilder->compile();

dump($containerBuilder);die;

自动配置

通过创建一个Definition的原型，我们可以控制注入进容器中的服务

config.php

<?php
// config/config.php

use App\Authorization\AccessManager;
use App\Authorization\Voter\PostVoter;
use Symfony\Component\DependencyInjection\Reference;

$definition = new Definition();
$definition->setPublic(false);

$loader->registerClasses($definition, 'App\\', '../src/*');

$container->getDefinition(AccessManager::class)
    ->setPublic(true)
    ->addArgument([new Reference(PostVoter::class)]);

可以看到我们设置的Definition原型是所有服务都是隐藏的，无法直接获取，如果想要暴露出来，需要单独使用setPublic设置为公开的

而且，进行完上述配置之后，需要执行compile方法使配置生效，另外，从容器中获取服务的时候要是用FQCN

index.php

$containerBuilder = new ContainerBuilder();

$loader = new PhpFileLoader($containerBuilder, new FileLocator(__DIR__.'/../config'));
// we'll create a config/config.php file to handle our configuration
$loader->load('config.php');

$containerBuilder->compile();

dump($containerBuilder->get(AccessManager::class));
die;

上面的配置文件有一点瑕疵，就是registerClasses方法将APP命名空间以及src目录下的所有类都注册到了容器中，但是有一部分类是没必要注册的，比如Entity目录下的类

这时我们只需要给registerClasses传入第四个参数用于排除不想注册的类即可

$loader->registerClasses($definition, 'App\\', '../src/*', "../src/Entity/*");

service tag

顾名思义就是给服务打上标签

config.php

$definition = new Definition();
$definition->setPublic(false);

$container->registerForAutoconfiguration(VoterInterface::class)
    ->addTag('app.voter');

$loader->registerClasses($definition, 'App\\', '../src/*', "../src/Entity/*");

$container->getDefinition(AccessManager::class)
    ->setPublic(true)
    ->addArgument($container->findTaggedServiceIds('app.voter'));

在上面的代码中，我们使用registerForAutoconfiguration方法给所有实现了VoterInterface接口的类打上了app.voter的标签

当我们需要获取拥有该标签的服务时，只需执行如下代码即可

$container->findTaggedServiceIds('app.voter')

但是，光这样还不行，标签只有在容器编译的时候才会真正打上，此时AccessManager服务中的voter是空的

这个时候我们就需要引入CompilerPass概念了

CompilerPass

compiler pass使得我们可以操作已经注册在容器中的服务定义

在本例中，我们创建一个VoterPass类，该类需要实现Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface接口的process方法，该方法会biaojigaoliang1在容器编译的时候执行biaojigaoliang2

<?php

namespace App\DependencyInjection\Compiler;

use App\Authorization\AccessManager;
use Symfony\Component\DependencyInjection\Argument\TaggedIteratorArgument;
use Symfony\Component\DependencyInjection\Compiler\CompilerPassInterface;
use Symfony\Component\DependencyInjection\ContainerBuilder;

class VoterPass implements CompilerPassInterface
{
    public function process(ContainerBuilder $container)
    {
        $accessManagerDefinition = $container->getDefinition(AccessManager::class);
        $accessManagerDefinition->addArgument(new TaggedIteratorArgument('app.voter'));
    }
}

在上面的代码中，我么使用了TaggedIteratorArgument类来完成对所有打了app.voter标签的服务的注入

然后我们将VoterPass注册到容器中即可

index.php

$containerBuilder = new ContainerBuilder();
$containerBuilder->addCompilerPass(new VoterPass());

另外，还需要将Definition设置为Autoconfigured以实现标签服务的注入

同时在注册类的时候将VoterPass类所处的目录排除

config.php

$definition = new Definition();
$definition
    ->setAutoconfigured(true)
    ->setPublic(false);

$container->registerForAutoconfiguration(VoterInterface::class)
    ->addTag('app.voter');

$loader->registerClasses($definition, 'App\\', '../src/*', '../src/{Entity,DependencyInjection}');

$container->getDefinition(AccessManager::class)
    ->setPublic(true);

这样以来，当我们需要给AccessManager新增Voter的时候，只需要实现VoterInterface接口即可

控制器

在上面的例子中，AccessManager是可以直接被我们访问到的，但是在实际的工作中这并不是一个很好的做法

我们更倾向于使用controller（控制器）来进行访问，这里需要用到autowiring，这个和java的框架Spring Framework是一样的，都拥有根据类型自动注入依赖的功能

autowiring可以最大化的简化配置，它可以根据函数的的类型提示自动注入需要用到的服务

首先需要对config.php进行一些修改

<?php

use App\Authorization\AccessManager;
use App\Authorization\Voter\VoterInterface;
use Symfony\Component\DependencyInjection\Definition;

$privateDefinition = new Definition();
$privateDefinition
    ->setAutowired(true)
    ->setAutoconfigured(true)
    ->setPublic(false);

$publicDefinition = new Definition();
$publicDefinition
    ->setAutowired(true)
    ->setAutoconfigured(true)
    ->setPublic(true);

$container->registerForAutoconfiguration(VoterInterface::class)
    ->addTag('app.voter');

$loader->registerClasses($privateDefinition, 'App\\', '../src/*', '../src/{Entity,DependencyInjection}');

$loader->registerClasses($publicDefinition, 'App\\Controller\\', '../src/Controller/*');

我们只将controller服务暴露了出来，其他被注册的服务全部都是私有的，无法被访问到

src\controller\PostController.php：

<?php

namespace App\Controller;

use App\Authorization\AccessManager;
use App\Authorization\Voter\PostVoter;
use App\Entity\Post;
use App\Entity\User;

class PostController
{
    /** @var AccessManager */
    private $accessManager;

    public function __construct(AccessManager $accessManager)
    {
        $this->accessManager = $accessManager;
    }

    public function index()
    {
        $user = new User('Alex');
        $admin = new User('Admin');
        $admin->addRole(User::ROLE_ADMIN);

        $post = new Post();

        dump($this->accessManager->decide(PostVoter::READ, $post, $user));      // true
        dump($this->accessManager->decide(PostVoter::READ, $post, $admin));     // true

        dump($this->accessManager->decide(PostVoter::WRITE, $post, $user));     // false
        dump($this->accessManager->decide(PostVoter::WRITE, $post, $admin));    // true
    }
}

AccessManager服务会自动注入以进行PostController服务的初始化

然后我们就可以在index.php中调用PostController的index方法了

$containerBuilder->get(PostController::class)->index()

通过服务的setter方法进行服务注入

我们给AccessManager类增加一个set方法

public function setVoters(iterable $voters)
{
    $this->voters = $voters;
}

VoterPass类也要随之改变

public function process(ContainerBuilder $container)
{
    $accessManagerDefinition = $container->getDefinition(AccessManager::class);
    $accessManagerDefinition->addMethodCall('setVoters', [new TaggedIteratorArgument('app.voter')]);
}

可以看到，之前是给AccessManager的构造函数传参，现在直接改成了调用AccessManager的setVoters方法并传递参数，biaojigaoliang1另外还需要删除AccessManager的构造函数biaojigaoliang2，如果不进行更改，是会报错的，因为symfony会尝试使用autowiring对AccessManager进行自动的依赖注入，但是构造函数的参数类型是iterable，进而会导致报错

更好的做法是使用addVoter方法而不是setVoters方法，这样可以在biaojigaoliang1逐一biaojigaoliang2增加Voter的过程中进行一些验证

AccessManager.php

public function addVoter(VoterInterface $voter)
{
    $this->voters[] = $voter;
}

注意，php正加数组元素的方式就是直接赋值$this->voters[] = $voter，xdm可以运行下面这段代码来加深理解

$array = array('test1', 'test2');
$array[] = 'test3';
$array['name'] = 'jack';
var_dump($array);

VoterPass.php

public function process(ContainerBuilder $container)
{
    $accessManagerDefinition = $container->getDefinition(AccessManager::class);
    $voters = $container->findTaggedServiceIds('app.voter');
    foreach ($voters as $serviceId => $tagAttributes) {
        $accessManagerDefinition->addMethodCall('addVoter', [new Reference($serviceId)]);
    }
}

这样写的好处在于，如果你给没有实现VoterInterface的服务也打上了app.voter的标签，那么在调用addVoter方法的时候会抛出异常

高级用法

使用monolog日志服务

新建配置文件config/monolog.php

<?php
use Monolog\Handler\StreamHandler;
use Monolog\Logger;
use Psr\Log\LoggerInterface;
use Symfony\Component\DependencyInjection\Reference;

$container->register(StreamHandler::class, StreamHandler::class)
    ->addArgument(__DIR__.'/../var/app.log');
$container->register(LoggerInterface::class, Logger::class)
    ->addArgument('voter')
    ->addMethodCall('pushHandler', [new Reference(StreamHandler::class)]);

现在日志服务注册完了，我们需要将其注入到PostVoter服务中，我们首先想到的注入方式就是通过PostVoter的构造函数参数提示来自动进行注入

其实有一种更好的方法，我们可以通过Psr\Log\LoggerAwareInterface接口来进行日志服务的注入，所有实现了Psr\Log\LoggerAwareInterface接口的服务都会实现一个setLogger方法，借助该方法我们可以实现日志服务的注入

修改后的config/monolog.php如下：

<?php
use Monolog\Handler\StreamHandler;
use Monolog\Logger;
use Psr\Log\LoggerAwareInterface;
use Psr\Log\LoggerInterface;
use Symfony\Component\DependencyInjection\Reference;

$container->register(StreamHandler::class, StreamHandler::class)
    ->addArgument(__DIR__.'/../var/app.log');
$container->register(LoggerInterface::class, Logger::class)
    ->addArgument('voter')
    ->addMethodCall('pushHandler', [new Reference(StreamHandler::class)]);
$container->registerForAutoconfiguration(LoggerAwareInterface::class)
    ->addMethodCall('setLogger', [new Reference(LoggerInterface::class)]);

使用registerForAutoconfiguration方法来进行日志服务的注入

然后我们的PostVoter服务只需要实现LoggerAwareInterface接口即可

class PostVoter implements VoterInterface, LoggerAwareInterface
{
    use LoggerAwareTrait;
    ...
}

我们甚至都不用自己去实现LoggerAwareInterface接口，只需要一句use LoggerAwareTrait即可

我们在PostVoter类的vote方法中加入如下语句来测试我们的日志服务是否被正常注入

$this->logger->debug(self::class . ' executed.');

可以正常生成日志文件，没有问题

处理参数

在上面的日志服务的配置中，我们需要传递几个参数

symfony的依赖注入允许我们设置参数并将其注入或者应用到我们的app中

创建config/parameters.php文件

<?php
$container->setParameter('root_dir', __DIR__.'/..');
$container->setParameter('app.logger.voter_channel', 'voter');
$container->setParameter('app.logger.file_path', '%root_dir%/var/app.log');

该文件应该在所有配置文件加载之前被加载

public/index.php：

...
$loader->load('parameters.php');
$loader->load('config.php');
$loader->load('monolog.php');
...

在parameters.php配置文件中我们设置了三个参数

应用的根目录
日志的描述性名称
日志文件路径

下面是容器编译前后的参数变化，可以看到编译之后的%root_dir%被替换成了绝对路径

更新我们的config/monolog.php文件

<?php
use Monolog\Handler\StreamHandler;
use Monolog\Logger;
use Psr\Log\LoggerAwareInterface;
use Psr\Log\LoggerInterface;
use Symfony\Component\DependencyInjection\Reference;

$container->register(StreamHandler::class, StreamHandler::class)
    ->addArgument('%app.logger.file_path%');
$container->register(LoggerInterface::class, Logger::class)
    ->addArgument('%app.logger.voter_channel%')
    ->addMethodCall('pushHandler', [new Reference(StreamHandler::class)]);
$container->registerForAutoconfiguration(LoggerAwareInterface::class)
    ->addMethodCall('setLogger', [new Reference(LoggerInterface::class)]);

将以前的硬编码替换城变量

现在我们的应用程序已经像模像样了：

应用参数保存在parameters.php文件中
应用程序的配置保存在config.php中
第三方库的配置在以他们自己命名的配置文件中：monolog.php

装饰服务

上面我们使用了monolog来进行日志的生成，现在我们可以对其进行装饰以生成更加漂亮的日志

新建src/Logger/FancyLoggerDecorator.php装饰器

<?php

namespace App\Logger;

use Psr\Log\LoggerInterface;

class FancyLoggerDecorator implements LoggerInterface
{
    /** @var LoggerInterface */
    private $decoratedLogger;

    public function __construct(LoggerInterface $decoratedLogger)
    {
        $this->decoratedLogger = $decoratedLogger;
    }

    public function emergency($message, array $context = array())
    {
        $this->decoratedLogger->emergency('🆘 '.$message, $context);
    }

    public function alert($message, array $context = array())
    {
        $this->decoratedLogger->alert('🚨 '.$message, $context);
    }

    public function critical($message, array $context = array())
    {
        $this->decoratedLogger->critical('🛑 '.$message, $context);
    }

    public function error($message, array $context = array())
    {
        $this->decoratedLogger->error('❌ '.$message, $context);
    }

    public function warning($message, array $context = array())
    {
        $this->decoratedLogger->warning('⚠️ '.$message, $context);
    }

    public function notice($message, array $context = array())
    {
        $this->decoratedLogger->notice('📝 ' . $message, $context);
    }

    public function info($message, array $context = array())
    {
        $this->decoratedLogger->info('ℹ️ '.$message, $context);
    }

    public function debug($message, array $context = array())
    {
        $this->decoratedLogger->debug('🤖 '.$message, $context);
    }

    public function log($level, $message, array $context = array())
    {
        $this->decoratedLogger->log($level, $message, $context);
    }
}

更改config/monolog.php注入装饰服务并将原始日志服务注入到装饰服务的构造函数的参数中：

...
$container->register(FancyLoggerDecorator::class)
    ->setDecoratedService(LoggerInterface::class)
    ->addArgument(new Reference(FancyLoggerDecorator::class.'.inner'));

被装饰的LoggerInterface的services id会自动转换为装饰服务的名称加上.inner

优化性能

缓存已经编译的配置

在现阶段的代码中，每次我们发起一个请求，容器都会重新创建一次，由于我们的应用程序比较小，看不出来对性能的影响，我们通过下面的代码来演示缓存对性能的提升效果

使用Symfony\Component\DependencyInjection\Dumper\PhpDumper类将容器dump到文件中来进行缓存，另外在容器编译之后，我们设置了一个3s的等待以更明显地显示效果

public/index.php：

<?php

require __DIR__.'/../vendor/autoload.php';

use App\Authorization\AccessManager;
use App\Authorization\Voter\PostVoter;
use App\Controller\PostController;
use App\Entity\Post;
use App\Entity\User;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\Loader\PhpFileLoader;
use Symfony\Component\Config\FileLocator;
use Symfony\Component\DependencyInjection\Dumper\PhpDumper;

$cachedContainerFile = __DIR__ .'/../var/cache/CachedContainer.php';

if (file_exists($cachedContainerFile)) {
    require_once $cachedContainerFile;

    $container = new CachedContainer();
} else {
    $container = new ContainerBuilder();

    $loader = new PhpFileLoader($container, new FileLocator(__DIR__.'/../config'));
    $loader->load('parameters.php');
    $loader->load('config.php');
    $loader->load('monolog.php');

    $container->compile();
    // make the compilation really long to show the difference
    sleep(3);

    $dumper = new PhpDumper($container);
    file_put_contents($cachedContainerFile, $dumper->dump(['class' => 'CachedContainer']));
}

$container->get(PostController::class)->index();

我们将容器内容缓存到了文件中，当下一次请求到达的时候我们会先判断文件是否存在（容器是否被缓存），如果文件存在则直接require_once，否则就重新进行容器的编译

xdm可以自己运行一下代码体验一下，第一次会等待几秒，第二次访问你计划看不到浏览器刷新，因为已经缓存了，所以速度非常快

在缓存的文件var/cache/CachedContainer.php文件中我们可以看到如下代码

...
protected function getPostControllerService()
{
    $a = new \App\Authorization\AccessManager();

    $b = new \App\Authorization\Voter\PostVoter();

    $c = new \Monolog\Logger('voter');
    $c->pushHandler(new \Monolog\Handler\StreamHandler('C:\\Users\\x\\phplearn\\symfony\\container\\config/../var/app.log'));

    $d = new \App\Logger\FancyLoggerDecorator($c);

    $b->setLogger($d);
    $e = new \App\Authorization\Voter\TestVoter();
    $e->setLogger($d);

    $a->addVoter($b);
    $a->addVoter($e);

    return $this->services['App\\Controller\\PostController'] = new \App\Controller\PostController($a);
}
...

上面的代码完全符合我们之前讲的关于容器的知识点

AccessManager和PostVoter、TestVoter作为私有服务被初始化（服务的注册）
日志服务被初始化（$c），voter作为构造函数参数传入，然后根据monolog.php的配置调用pushHandler方法
装饰服务（$d）被初始化，日志服务作为构造函数参数被注入
PostVoter和TestVoter通过setter将日志服务注入
AccessManager服务（$a）将PostVoter和TestVoter服务注入
最后PostController将自己添加到services数组中，service id就是他的FQCN（App\\Controller\\PostController）

但是上面的缓存机制还存在问题，一旦我们的配置更新了，缓存也就失效了，但是我们的app还在继续使用之前缓存的过时的容器

因此我们需要判断一下当前运行环境是生产环境还是开发环境

...
$env = "dev";

if ("prod" === $env && file_exists($cachedContainerFile))
...

增加一个$env变量来表示当前的环境，在if语句中新增一个判断环境的条件即可

最佳的实践是创建一个.env文件，然后使用symfony/dotenv来解析该文件中的变量，从而使得这些变量可以通过$_ENV在任何地方被访问到

...
$dotenv = new Dotenv();
$dotenv->load('../.env');

if ("prod" === $_ENV['env'] && file_exists($cachedContainerFile))
...

.env：

env=prod

通过变量名称进行注入

我们前面注入的都是各种服务，如果想要注入变量怎么办

这一点可以借助Definition原型来实现，通过setBindings方法可以将一个变量名称和现有变量进行绑定

config/config.php：

...
//先给容器设置一个env参数
$container->setParameter('env', $_ENV['env']);
...
$privateDefinition
    ->setAutowired(true)
    ->setAutoconfigured(true)
    ->setPublic(false)
    //将容器中的env参数和$env绑定，这样当privateDefinition定义的任何服务需要使用$env变量时
    //就会解析成容器的env参数，也就是$_ENV['env']
    ->setBindings(['$env' => $container->getParameter('env'),]);
...

然后我们哪一个服务需要env变量就在哪一个服务中添加一个对应的成员即可

src\Authorization\Voter\PostVoter.php：

...
private $env;

public function __construct(string $env)
{
    $this->env = $env;
    dump($this->env);
}

public function vote(string $attribute, $subject, User $user): bool
{
    $this->logger->debug(self::class.' voter executed', ['env' => $this->env]);
    ...
}
...

结语

牛逼

references：

php之autoload(自动加载)

2021-06-06T00:00:00+02:00

前言

php的autoload机制对于大型项目来说尤为重要，因为随着项目体积的增大，需要用到的类也会随之增多，如果全部都靠手动进行include，一则浪费精力，二来会加载很多不必要的类，造成内存资源的浪费

因此php引入了autoload机制，来解决这个问题

引子

php提供了spl_autoload_register方法来让我们注册自己的自动加载方法

被注册的方法将会在php找不到你所使用的类的时候进行调用，然后把相应的类文件include到当前文件中

一个简单的例子

index.php

<?php
function custom_autoload_function($class) {
    include 'lib\\' . $class .'.php';
}

spl_autoload_register('custom_autoload_function');

$obj  = new Fuck();

我们在当前目录下创建lib目录，然后新建Fuck.php

<?php
class Fuck {
    function __construct() {
        echo "fucking autoload test!";
    }
}

上面我们是手动进行的autoload方法的注册，下面我们使用composer的自动加载功能

composer自动加载

大致有四种类型

file
classmap
psr-0
psr-4

下面我们通过实例来进行讲解

在家目录创建~\phplearning\autoload目录，然后执行composer init初始化一个composer项目，全部默认即可

file

修改composer.json如下

{
    "name": "inclu/autoload",
    "autoload": {
        "files": ["lib/Foo.php", "lib/Bar.php"]
    }
}

然后执行composer dump-autoload命令，会自动创建出vendor目录并生成其所需的各种文件

之后，我们只需要在源文件中加入下面这行代码即可：

include 'vendor\autoload.php';

上面composer.json中的file指令添加了一个文件列表，当php找不到你调用的类的时候就会从这个列表中依次查询，直到找到你所需的类

因此我们建立lib目录并创建Foo.php以及Bar.php文件

Foo.php

<?php

class Foo {
    function __construct() {
        echo "Foo autoload test!";
    }
}

Bar.php

<?php

class Bar {
    function __construct() {
        echo "Bar autoload test!";
    }
}

index.php

<?php
include 'vendor\autoload.php';

$obj  = new Foo();
echo "<br />";
$obj  = new Bar();

classmap

classmap指令告诉php去指定的目录中搜索需要加载的类文件

composer.json

{
    "name": "inclu/autoload",
    "autoload": {
        "classmap": ["lib"]
    }
}

再次运行composer dump-autoload

依然可以正常运行

psr-0

php的psr-0规范定义了命名空间的相关规则，详细信息请自行google，在此不做讲解

composer.json

{
    "name": "inclu/autoload",
    "autoload": {
        "psr-0": {
            "Mother\\Fucker\\": "lib"
        }
    }
}

psr-0指令规定了Mother\Fucker命名空间对应lib目录，也就是说，该命名空间下的类都位于lib\Mother\Fucker目录下，可以看到这里命名空间和目录结构有一个明显的一一对应的关系

lib\Mother\Fucker\Fuck.php

<?php
namespace Mother\Fucker;

class Fuck {
    function __construct() {
        echo "motherfucker PSR-0 autoload test!";
    }
}

index.php

<?php
include 'vendor\autoload.php';

use Mother\Fucker\Fuck;

$obj  = new Fuck();

重新运行composer dump-autoload

PSR-4

composer.json

{
    "name": "inclu/autoload",
    "autoload": {
        "psr-4": {
            "Mother\\Fucker\\": "lib"
        }
    }
}

psr-4和psr-0的写法是一样的，只有一点不同，就是，命名空间不需要和目录结构对应

上面的psr-4指令规定了lib目录下的类文件都是在Mother\Fucker命名空间下的

lib\Fuck.php

<?php
namespace Mother\Fucker;

class Fuck {
    function __construct() {
        echo "motherfucker PSR-4 autoload test!";
    }
}

重新运行composer dump-autoload

references：

Conversations代码学习

2021-06-01T00:00:00+02:00

前言

儿童节快乐！！！

源代码:

git clone --depth 1 --branch 2.7.0 https://github.com/iNPUTmice/Conversations.git

克隆到本地之后，使用as打开，gradle sync的过程中可能会遇到各种问题，但是我相信xdm都可以自己解决，或者contact me

另外，要想进行调试的话，你需要一个xmpp server，参考这篇安装文章

welcom activity

这个活动是app第一次启动时首先创建的活动

0x1

第一个知识点是DataBindingUtil.setContentView

位置：

Conversations\src\conversations\java\eu\siacs\conversations\ui\WelcomeActivity.java
line 109~136

使用DataBindingUtil的setContentView进行数据绑定之后，原来的布局文件会转换成一个类，按钮的ID名称随之变成该类的成员变量，名称也会有所变化

生成的类文件根据第二个参数，也就是布局文件的名称决定，本例中生成的类名称为 out\eu\siacs\conversations\databinding\ActivityWelcomeBinding.java

规则就是首字母大写，下划线去掉，然后下换线后面的第一个字母大写后面再加一个Binding

id的名称转换规则就是去掉下划线，首字母小写，下划线后面的字母大写

比如在本例中注册新账户的按钮ID是register_new_account，那么成员变量的名称就应该是registerNewAccount，如果把按钮ID改为register_n_ew_account，那么成员变量的名称就会变成registerNEwAccount

0x2

在点击完使用已有账户的按钮之后，会唤起另一个activity：EditAccountActivity

PyQt多线程与信号机制

2020-11-26T00:00:00+01:00

前言

最近写了一个基于PyQt的程序，在这里记录一下多线程与信号机制的用法

完整项目代码

pycharm配置pyqt开发环境

首先安装pyqt5和pyqt5-tools

python3 -m pip install PyQt5
python3 -m pip install PyQt5-tools

在pycharm的设置中找到External Tools，点击加号进行如下配置：

这里Program就是designer.exe的绝对路径，直接用everything搜索designer.exe即可获取其绝对路径

配置pyuic用于将ui文件编译成py文件：

使用方法如下：

代码示例

import multiprocessing
from shutil import copyfile

from PyQt5 import QtCore, QtGui, QtWidgets
from PyQt5.QtCore import QStringListModel, QThread, pyqtSignal, QBasicTimer
from PyQt5.QtWidgets import QFileDialog, QMessageBox
from main import Ui_MainWindow
import subprocess
import re
import multiprocessing
import sys
import os
import random
import time

step = 0

class DemoThread(QThread):
    timer = pyqtSignal()
    def run(self) -> None:
        while True:
            self.demo()
            global step
            if step >= 5:
                break
        self.timer.emit()

    def demo(self):
        self.sleep(1)
        #something to do
        global step
        step += 1

class ProcessBarWorkThread(QThread):
    timer = pyqtSignal()
    def run(self) -> None:
        while True:
            #每一秒钟发送一次绘制信号
            self.sleep(1)
            self.timer.emit()

class MainWindow(QtWidgets.QMainWindow):
    def __init__(self, parent=None):
        super(MainWindow, self).__init__(parent=parent)
        self.ui = Ui_MainWindow()
        self.setupMyUi(self)
    def setupMyUi(self, MainWindow):
        self.ui.setupUi(MainWindow)
        # 初始化进度条
        global step
        step = 0
        self.ui.progressBar.setValue(0)
        self.ui.pushButton.clicked.connect(self.on_pushButton_click)
################################################CMS扫描模块事件Begin########################################################
    #点击确定开始绘制进度条
    def on_pushButton_click(self):
        self.demoThread = DemoThread()
        #设置接收到信号时触发的方法
        self.demoThread.timer.connect(self.on_demo_finished)
        self.demoThread.start()
        #初始化进度条
        global step
        step = 0
        self.ui.progressBar.setValue(0)
        self.processBarWorkThread = ProcessBarWorkThread()
        #这里使用lambda匿名方法接受进度条控件参数
        self.processBarWorkThread.timer.connect(lambda: self.processBar(self.ui.progressBar))
        self.processBarWorkThread.start()

    #扫描完成，关闭线程
    def on_demo_finished(self):
        self.demoThread.terminate()

    #绘制进度条
    def processBar(self,processBar):
        global step
        processBar.setValue(step/5*100)
        if step >= 5:
            self.processBarWorkThread.terminate()
            QMessageBox.information(self, "info", "演示结束！")

if __name__ == "__main__":
    app = QtWidgets.QApplication(sys.argv)
    w = MainWindow()
    w.show()
    sys.exit(app.exec_())

效果图：

可以看到代码中写了两个线程类：DemoThread和ProcessBarWorkThread，它们两个都继承自QThread

在ProcessBarWorkThread类中，首先使用pyqtSignal初始化一个定时器，然后我们通过sleep方法控制信号发送间隔，本示例程序中是一秒发送一次信号，通过connect方法绑定每次接收到信号时出发的动作

self.processBarWorkThread.timer.connect(lambda: self.processBar(self.ui.progressBar))

processBar方法接受一个QProgressBar类型的对象作为参数来确定要对哪一个进度条控件进行绘制

而另一个线程类：DemoThread是我们的程序中的业务代码，也就是真正干活的线程，我们每完成一定的任务就改变一下全局变量step的值，然后当下一次ProcessBarWorkThread发送信号通知processBar方法进行进度条的绘制时，进度条就会发生变化

这两个线程通信的方式就是使用全局变量step

Windows多线程与信号机制

2020-11-01T00:00:00+01:00

前言

前几天写了一个MFC程序，但是在写进度条的时候遇到了问题

因为我都放在了主线程中，所以就导致在绘制进度条的时候，程序是卡死的，为了解决这个问题，我百度了一波，最终使用了多线程的方式解决了主线程阻塞的问题

基础用法

首先在原有的项目中添加一个头文件：Thread.h，内容如下：

#pragma once
#include <process.h>
#include <Windows.h>
#define WM_USER_MSG WM_USER + 1001
#define WM_USER_FIN WM_USER + 1002

class CThread
{
public:
    static void Run(void *);
public:
    CThread(void);
    ~CThread(void);
};

编写Thread.cpp内容如下：

#include "StdAfx.h"
#include "Thread.h"

void CThread::Run( void* lpVoid )
{
    HWND hWnd = (HWND)lpVoid;

    for (int i=0;i<100;i++)
    {
        ::PostMessage(hWnd,WM_USER_MSG,WPARAM(i),LPARAM(0));
        Sleep(100);
    }

    ::PostMessage(hWnd,WM_USER_FIN,WPARAM(0),LPARAM(0));
    _endthread();
}

CThread::CThread(void)
{
}

CThread::~CThread(void)
{
}

在主窗口的cpp文件中添加如下消息映射：

ON_MESSAGE(WM_USER_MSG, &CMFCApplication1Dlg::OnMsg)
ON_MESSAGE(WM_USER_FIN, &CMFCApplication1Dlg::OnFin)

第一个消息映射是通知主窗口进行进度条的绘制，第二个消息映射时通知主窗口进度条绘制完毕，触发相应的回调函数

在按钮点击事件中编写如下代码：

CProgressCtrl *prog = (CProgressCtrl *)GetDlgItem(IDC_PROGRESS1);
prog->SetRange(0, 100);
_beginthread(&CThread::Run, 0, this->GetSafeHwnd());

最终运行效果：

完整项目解决方案：

https://gitee.com/wochinijiamile/smartya/raw/master/MFCApplication1.rar

传参

上面的示例程序中我们只传了一个参数this->GetSafeHwnd()，_beginthread函数的最后一个参数是一个指针，用于指向传递给第一个参数所指向的函数的参数列表，我去网上搜了一下，都是说使用结构体，但是我在实际操作的时候又总是会遇到这样那样的问题，最后干脆使用了类来传递多个参数

首先新建一个头文件：Share.h，内容如下：

#pragma once
#include <process.h>
#include <Windows.h>

class CShare
{
public:
    HWND hWnd;
    CString para1;
    CString para2;
    CShare(void);
    ~CShare(void);
};

然后再创建用于实现的cpp文件：Share.cpp，内容如下：

#include "StdAfx.h"
#include "Share.h"


CShare::CShare(void)
{
}

CShare::~CShare(void)
{
}

然后在主窗口类的头文件中新增一个CShare类的成员变量，使用如下方式传参即可：

void CMFCApplication1Dlg::OnBnClickedOk()
{
    CProgressCtrl *prog = (CProgressCtrl *)GetDlgItem(IDC_PROGRESS1);
    prog->SetRange(0, 100);
    HWND hwnd = this->GetSafeHwnd();
    CString para1 = _T("我是参数一");
    CString para2 = _T("我是参数二");
    cshare.para1 = para1;
    cshare.para2 = para2;
    cshare.hWnd = hwnd;
    _beginthread(&CThread::Run, 0, &cshare);
}

Thread.cpp中接受参数的代码如下：

void CThread::Run( void* lpVoid )
{

    //强制类型转换
    HWND hWnd = ((CShare*)lpVoid)->hWnd;
    CString para1 = ((CShare*)lpVoid)->para1;
    CString para2 = ((CShare*)lpVoid)->para2;

    AfxMessageBox(para1);
    AfxMessageBox(para2);

    for (int i=0;i<100;i++)
    {
        ::PostMessage(hWnd,WM_USER_MSG,WPARAM(i),LPARAM(0));
        Sleep(100);
    }

    ::PostMessage(hWnd,WM_USER_FIN,WPARAM(0),LPARAM(0));
    _endthread();
}

最终运行效果：

完整项目解决方案：

https://gitee.com/wochinijiamile/smartya/raw/master/wsdfdfghbngm.zip

后记

不足之处还望指出