写这篇帖子主要是为记录ObRegisterCallbacks函数的相关分析，如有错误，欢迎批评指正。
给出的为C伪代码，仅展示逻辑，不保证安全性。

C的伪代码如下

这是原始汇编代码

逆向ObUnRegisterCallbacks的思路
函数开头保存了一些寄存器的值，包括rbx、rbp、rsi、rdi，以及r12到r15，这说明函数会使用这些寄存器，并在结束时恢复它们。接着分配了0x20字节的栈空间，一般用于局部变量。
然后检查输入参数。这是内核函数的通用操作，可以看一下。
movzx eax, word ptr [rcx]，这里rcx是第一个参数，可能是一个指向OB_CALLBACK_REGISTRATION结构的指针。接着用0xFF00进行按位与操作，判断是否设置了特定标志。如果不符合条件，跳转到错误处理部分，返回错误码0xC000000D（STATUS_INVALID_PARAMETER）。

接下来，函数读取r15+2处的字（可能是OperationCount），如果为零，同样跳转到错误处理。这里检查是否有有效的操作类型数量。

然后，函数计算需要分配的内存大小，使用ExAllocatePoolWithTag分配内存，标签是0x6C46624F，可能是'ObCf'的ASCII表示，ObjectCallbackFunction嘛。如果分配失败，返回0xC000009A（STATUS_INSUFFICIENT_RESOURCES）。

分配内存后，用memset清零，这里用RltZeroMemory替代，并设置结构体的各个字段。
然后，通过循环处理每个回调操作，验证每个回调的Altitude和回调函数是否有效，特别是调用MmVerifyCallbackFunctionCheckFlags来验证回调函数的标志位。

在处理每个回调项时，会为每个操作分配一个回调块，并将其插入到全局回调链表中，使用ObpInsertCallbackByAltitude确保按Altitude排序。如果插入失败，函数需要回滚已分配的资源，并返回相应的错误码。
KeEnterCriticalRegion这些就是APC相关函数

内核中也在用ExAllocatePoolWithTag嘛，WDK还非要用ExAllocatePool2:)
几个函数中最引人注目的应该是MmVerifyCallbackFunctionCheckFlags吧，负责对回调合法性的检验，下面有对其分析。

原始汇编代码

分析思路
首先看开头部分。代码开始保存寄存器和分配栈空间，接着初始化esi为0，把rcx（第一个参数）赋值给rbx。比较si和[rbx+2]的值，如果si大于等于的话，跳转到释放内存的部分。这可能是在检查回调项的数量是否处理完毕。

接下来，循环部分处理每个回调项。使用shl rax,6和add rdi,rax来计算每个回调项的位置，大概是每个项的大小为0x40（64字节）。然后调用ExWaitForRundownProtectionRelease，这可能是在等待引用计数归零。然后获取当前线程，减少资源计数，进入临界区，获取PushLock，操作链表来移除回调项，释放锁，离开临界区。循环直到所有项处理完，最后释放内存。

然后看ObpCallPostOperationCallbacks部分。这部分在遍历链表，调用每个回调的后期处理函数。通过比较链表是否为空来决定是否继续。取出链表中的每个节点，进行验证，调用guard_dispatch_icall执行回调函数，释放资源，并释放内存。最后释放对象引用，离开临界区。
这个逆向还原度可能没上一个高。

分析思路
开头是保存寄存器的指令，把rbx、rbp、rsi压入栈中，然后push rdi，接着调整rsp分配栈空间。这些操作通常在函数开头。
接下来，mov edi, edx 和 mov rsi, rcx，这里应该是将传入的参数保存到edi和rsi中，然后调MiGetSystemRegionType，结果保存在eax中。比较eax和1，如果相等就跳转到地址fffff800`23faf75e，将eax清零然后跳转到结尾返回。这说明如果MiGetSystemRegionType返回1，函数直接返回0。

如果比较结果不相等（即eax不等于1），则继续执行后面的代码。这里从地址fffff800`23faf6f3开始，读取gs:[188h]，也就是当前线程的KTHREAD结构，保存到rbp。然后xor ebx, ebx，将ebx清零，用来作为返回值或者中间变量。接着对[rbp+1E4h]处的字减1，这可能是线程的某个计数器，比如资源计数或递归计数。然后mov dl,1，准备调用ExAcquireResourceSharedLite，传入rcx为PsLoadedModuleResource，dl为1（表示等待资源可用）。

接下来调用MiLookupDataTableEntry，参数是rsi（原rcx，即第一个参数）和edx（此时为0）。检查返回的rax是否为NULL，如果是，跳到后面释放资源的部分。否则，测试edi（原edx，第二个参数）是否为0，如果是，设置ebx为1。否则，检查rax+68h处的值与edi是否相交，如果相交则ebx保持0，否则设为1。之后释放资源，调用ExReleaseResourceLite，然后恢复线程状态，返回ebx的值。
MiLookupDataTableEntry
MiLookupDataTableEntry的原型返回一个指向数据表条目结构的指针，该结构包含Flags字段在偏移0x68处。
如何确定就是Flags呢？
Windbg里dt一下LDR_DATA_TABLE_ENTRY

只要Flags给一个非0值，就会检查，而ObRegisterCallbacks传的是硬编码0x20，这便是许多帖子都说要将DriverSection的Flag值设为0x20的原因。
因此绕过方法就是Flags值设为0x20。这个更改是通过修改LDR_DATA_TABLE_ENTRY的结构体实现的，后面有分析和示例代码

这个Altitude在微软的说明文档中也是模棱两可，测试开发填321000应该可以吧（怀疑），正式的应该要向微软申请。
Altitude的具体就没逆了

这几个的分析思路和ObRegisterCallbacks一致
以下的结构体完全依照Windbg的符号分析

这便是绕过MmVerifyCallbackFunctionCheckFlags的突破口，将Flags的值设为0x20，示例如下

效果

这个在一些其他函数中有引用，所以分析一下结构即可

这个在ObUnRegisterCallbacks有用到

以上的测试分析基于Win10 build19041进行，欢迎各位指正

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！