云散皆星河的博客

我写了半个用户态杀软--R3 ShieldCore!!!

2026-10-06T23:00:00+08:00

我写了半个用户态杀软--R3 ShieldCore!!!

它叫 R3 ShieldCore,Windows 上的用户态行为拦截引擎,代码在 https://github.com/yunsjxh/R3ShieldCore 做的事一句话:把一份 DLL 注入进机器上几乎每一个进程,在进程里把用户态 API 换掉,在行为落地之前拦下来。

叫它"半个杀软"是因为它只占了用户态这一半——注入、hook、拦 API 调用,都在用户态;另一半在内核和硬件,它够不着。

约 110 处 inline hook,分给 17 个 guard,处理 18 类对象,纯 C++20。

注入:把同一份 DLL 放进每个进程

枚举进程用的是 NtGetNextProcess,一路 next 到 STATUS_NO_MORE_ENTRIES,带 SYNCHRONIZE | DllInject::ProcessAccess 权限。注不注进去,先过 ShouldSkipProcessInjection。

关键是判断这个进程有没有开始跑。没跑起来的进程,主线程的指令指针还停在 RtlUserThreadStart,这时候适合用 APC 投递;跑起来了的,只能起远程线程。判断方式是拿 NtGetNextThread 数线程:

cpp

NtGetNextThread(hProcess, nullptr, access, 0, 0, &thread1);
NTSTATUS status = NtGetNextThread(hProcess, thread1.get(), access, 0, 0, &thread2);
if (status == STATUS_NO_MORE_ENTRIES) {
    // 就一个线程。挂起它，看指令指针
    SuspendThread(thread1.get());
    GetThreadContext(thread1.get(), &c);
    if (c.Rip == pRtlUserThreadStart) {   // 还没跑起来
        // 走 APC 路
    }
}

为什么要看这个,而不是无脑起远程线程?因为会踩到一个真实故障:控制台程序如果被我们在它还没通知 csrss.exe 之前就触发了控制台初始化(KERNELBASE!ConsoleCommitState 早于 CsrClientCallServer),csrss 会返回 access denied,父进程的 CreateProcess 直接失败。所以没跑起来的必须走 APC,让它自己线程去执行,别抢跑。

APC 那条路会建一个互斥体(ProcessInitAPCMutex)去重,防止轮询路和同步路把同一个进程注两遍。32 位进程里还得跨架构去取 64 位 ntdll 的 RtlUserThreadStart,靠 wow64ext。

送进去的不是 DLL 路径加一句 LoadLibrary。是一段位置无关的反射 shellcode:靠 PEB 遍历自己把 LoadLibraryW、GetProcAddress 摸出来,再把 DLL 装起来,全程不依赖目标进程给任何东西。

新进程不能有盲区

轮询路有个天生的问题:进程已经跑起来了才轮到我们,中间那段就是盲区。所以还有一条同步路——在父进程里 hook CreateProcessInternalW(先找 kernelbase.dll,退而求其次 kernel32.dll),强制给创建标志或上 CREATE_SUSPENDED:

cpp

DWORD dwNewCreationFlags = dwCreationFlags | CREATE_SUSPENDED;
bRet = pThis->originalCreateProcessInternalW(..., dwNewCreationFlags, ...);

子进程建出来、主线程还挂着,这时候注入,成功才 ResumeThread;失败就 TerminateProcess 加关句柄、把 PROCESS_INFORMATION 清空、返回 FALSE。让一个一条钩子都没装的进程跑起来,是比杀掉它更坏的结局。

这里踩过一个坑。原函数在自己内部也要往刚建出来的子进程里写东西——RTL_USER_PROCESS_PARAMETERS,也就是环境块、命令行、当前目录,走的是 NtWriteVirtualMemory。而如果本进程被全量注入了,那次写会被我们自己的钩子判成"跨进程写内存 = 高危",BLOCK 模式下当场拒掉,于是原函数回滚、返回 FALSE、GetLastError() 是 5,根本走不到注入那一步。实测调用栈:

#0 KERNELBASE!NtWriteVirtualMemory   <- 被自己拦下的那一次
#5 KERNEL32!CreateProcessA
#4 KERNELBASE!CreateProcessInternalW <- 原函数

解法是开一个"CreateProcess 窗口":窗口内,由本线程建出来的子进程,对跨进程写内存、改页保护、建远程线程这几样一律透传;窗口一关立即失效。这个窗口对象是 POD,手工 Enter/Leave 配对——不能用 RAII,因为函数体里有 __try/__finally,带析构函数的对象一进来 MSVC 就报 C2712。

还有个"瘦会话"的设计。explorer.exe、svchost.exe、runtimebroker.exe 这三个进程一个 guard 都不装,只装 CreateProcessInternalW。目的是让它们拉起的子进程能走上面那条同步路,盲区趋近于零——"双击运行一个启动即写 MBR 的样本",只有这条路能赢。代价是这三个进程自己不受监控,这是故意的:explorer.exe 的文件 I/O 频率极高(开目录、缩略图、拖放),全量 hook 在 BLOCK 模式下必炸,而且 DLL 里任何一个 bug 都会让整个桌面挂掉。

进了进程,把 API 换掉

DLL 落地后的流程是 MH_Initialize → 设定线程冻结方式 → 各 guard 依次 MH_CreateHook + MH_QueueEnableHook 排队 → 最后一次 MH_ApplyQueued 全部生效。用"排队再一次性生效"而不是逐个立刻挂上,是为了避免钩子挂到一半的中间态。

线程冻结方式分两种:APC 路进来时本进程还没别的线程在跑,用 MH_FREEZE_METHOD_NONE_UNSAFE;其余情况用 MH_FREEZE_METHOD_FAST_UNDOCUMENTED,靠 MinHook 的未文档化手法把别的线程冻住再改代码。

挂点大致分布是:

ntdll:NtCreateKey / NtSetValueKey / NtCreateFile / NtWriteFile / NtOpenProcess / NtCreateThreadEx / NtWriteVirtualMemory / NtProtectVirtualMemory / NtAllocateVirtualMemory 等
user32:SetWindowsHookEx / SendInput / BlockInput / ClipCursor
ws2_32:connect / WSAConnect / sendto / bind
advapi32:服务相关那一批
combase / ole32:CoCreateInstance / CoGetClassObject

WMI、计划任务、摄像头设备这三类是纯 COM 接口,没有可挂的导出函数,只能去改 vtable 指针,和 MinHook 是两套手艺。

17 个 guard 的安装顺序不能乱:RegistryGuard 必须先装,因为其余 16 个都是先问它的 IsBypassed() 结论来决定自己挂不挂;而且共享通道也是它开的。通道开不起来的时候,这个进程直接跳过全部 hook,而不是装一半——装了一半的防护比没装更难查。

拿 NtCreateKey 举例(registry_guard.cpp):

cpp

NTSTATUS NTAPI NtCreateKey_Hook(PHANDLE KeyHandle, ACCESS_MASK DesiredAccess,
    const RG_OBJECT_ATTRIBUTES* ObjectAttributes, ULONG TitleIndex,
    RG_UNICODE_STRING* Class, ULONG CreateOptions, PULONG Disposition)
{
    InterlockedIncrement(&g_activeHooks);

    R3ShieldCore::Event event;
    Action action = Action::Pass;
    NTSTATUS status = STATUS_UNSUCCESSFUL;

    __try {
        action = Evaluate(R3ShieldCore::Op::CreateKey, nullptr,
            ObjectAttributes ? ObjectAttributes->ObjectName : nullptr, nullptr,
            DesiredAccess, event, true);
    }
    __except (EXCEPTION_EXECUTE_HANDLER) {
        action = ExceptionAction(event);
    }

    if (action == Action::Block) {
        event.Status = static_cast<ULONG>(STATUS_ACCESS_DENIED);
        Publish(event);
        status = STATUS_ACCESS_DENIED;
    }
    else {
        status = pOriginalNtCreateKey(KeyHandle, DesiredAccess, ObjectAttributes,
            TitleIndex, Class, CreateOptions, Disposition);
        if (action == Action::Record) {
            event.Status = static_cast<ULONG>(status);
            if (status >= 0 && KeyHandle) {
                __try { RefineKeyPath(*KeyHandle, event); }
                __except (EXCEPTION_EXECUTE_HANDLER) {}
            }
            Publish(event);
        }
    }

    InterlockedDecrement(&g_activeHooks);
    return status;
}

骨架就四件事:Evaluate 判、Block 就直接返 STATUS_ACCESS_DENIED 不往下走、Record 就先调原函数再补路径再上报、首尾一对计数。

这段代码我试过抽象。想用模板把这一百来个函数收敛成一个,省掉那 130 处手工记账,结果 MSVC 在 __try 上直接甩 C2712——异常处理和带析构函数的 C++ 对象不能共处一个函数。所以每个 hook 都是手写、长得一模一样。注释里写了原因,免得下次再有"优化一下"的冲动。

顺带说一个判据上的规矩:多层过滤的顺序是先判断是不是文件对象 → 再判高危 → 最后才走豁免。高危路径往往正好落在豁免范围里,先走豁免就会被当噪音放过去。这个顺序在 registry_guard.cpp 和 file_guard.cpp 里反复标着。

事件从别的进程传回来

引擎和注入的 DLL 之间有两块共享内存,职责分得很开:

Policy:引擎写,DLL 用 FILE_MAP_READ 只读打开。里面是模式、开关位、各种名单、统计。
Events:环形缓冲,各进程写、引擎单消费者读。

Policy 只读不是随手写的——早先有个字段是"高危命中计数",让 hook 侧去递增,结果被注入的进程一写就 0xC0000005,异常被 __except 吞掉变成"静默放行",症状是"高危既不拦也不记"。所以凡是 hook 侧要递增的计数,一律放在 Events 那边的 ChannelHeader 里,那个映射才是可写的。

ChannelHeader 卡在 32 字节(static_assert 钉死),后面直接跟着 Event[Capacity]。发布一条事件的协议是:

cpp

LONG index = InterlockedIncrement(&channel->WriteIndex) - 1;
// 消费者没追上就丢弃 —— 绝不阻塞调用方
bool dropped = (index - channel->ReadIndex) >= channel->Capacity;
Event* slot = ChannelEventAt(channel, index);
if (dropped) { memset(slot, 0, sizeof(Event)); InterlockedIncrement(&channel->DroppedCount); }
else         { memcpy(slot, &event, sizeof(Event)); }
slot->Sequence = 0;
MemoryBarrier();
InterlockedExchange(&slot->Sequence, index + 1);   // 消费者只认 Sequence == index+1

生产者任何时候都不阻塞——hook 跑在别人的业务线程上,卡一下就是卡别人整个程序,所以缓冲满了就丢,记 DroppedCount。丢弃的那格也得占位,不占的话消费者会永远卡在那个序号上、此后一条都读不出来。

消费者这边的套圈处理更绕一点。如果 writeIndex - readIndex > Capacity,说明生产者已经把那一圈覆盖了、Sequence 再也不可能等于 readIndex + 1,这时必须主动把 readIndex 推到 writeIndex - Capacity,跳过这段已丢的事件。不推的话消费者就永久死锁在那儿。

Event 结构里字段挺多,挑几个有意思的:ObjectType 决定 Op 该按哪套枚举解释(注册表、文件、进程各有各的 Op 空间,共用同一个结构、同一条通道、同一套 UI);TargetProcessId / CreatorProcessId 专门用来区分进程创建里的"谁建的"和"建了谁";网络那些事件单独有 TargetPort / NetProtocol / LocalAddress,不把 IP 和端口拼成一个字符串,因为 UI 要分列,而且 IPv6 的 :: 跟端口分隔符会打架。

Event::Flags 是 32 位,到 0x80000000 就用满了。所以从某个版本起新语义一律走尾部追加的 Flags2,不再往 Flags 里挤。

跨进程 ABI 版本号现在到 20。尾部追加字段虽然不动前面的偏移,但会改 sizeof(Policy),而 sizeof 变了就必须升版本,原因是两个方向都会坏事:新 DLL 配旧引擎,旧引擎建的 section 更小,新 DLL 按新尺寸 MapViewOfFile 会直接失败;旧 DLL 配新引擎,旧 DLL 只映射自己那一段能成功,但它会按旧布局去读新加的 NeverInjectPaths 那块字节。两个方向最后都落成同一句话——版本对不上就当作"共享通道不可用",本进程跳过全部 hook,而不是含糊地按错误布局读内存。Policy 和 Channel 各带一个 magic('RGP1' / 'RGE1'),加上版本号和引擎 pid 一起校验。

弹窗怎么跨进程

ask 模式要弹窗,可麻烦在于:我的 DLL 跑在别人的进程里,窗得画在引擎进程里。这条通道没用命名管道,也没用窗口消息——那两样都带着能被目标进程观察、甚至干扰的语义。用的是命名共享内存加命名事件。

共享内存里排 8 个槽。每个槽有个 State(Free / Claimed / Pending / Answered)和一个 Generation(世代号)。生产者是任意进程里那个被卡住的 hook 线程,流程是这样:

逐个槽 CAS 抢,把 State 从 Free 抢成 Claimed
InterlockedIncrement(Generation)——必须在发布之前
填请求字段
MemoryBarrier(),再把 State 置成 Pending
SetEvent 通知引擎
等本槽的应答事件,带超时。醒来先确认 State == Answered 且 AnsweredGeneration == 自己的世代号,不满足说明这是上一次请求的迟到答复,继续等
超时就自己把槽释放掉,返回兜底结论(默认 deny)

引擎那边是 UI 线程做的:扫 Pending 的槽、快照、弹窗、写结论和 AnsweredGeneration,然后 InterlockedCompareExchange(State, Answered, Pending)——只在槽还是 Pending 的时候才置成 Answered。如果 DLL 那边已经超时把槽释放了,CAS 就失败,这个答复直接被丢掉,不会串到别人的新请求上。

第 2 步和第 7 步合起来就是整个协议的命门。没有世代号的话,"上一个请求超时释放了槽、下一个请求占了同一个槽、上一个的答复这时候才到"——这条时序会把 A 的结论喂给 B,而 B 可能正好是个写注册表的操作。所以每个请求带着自己的世代号走,答复必须对号。

几个边角:等的时候按 250 毫秒切片轮询,不是死等一整个超时,这样卸载通知一来就能立刻收手;同一个进程已经有请求在等用户时,新的直接返回兜底结论,既防刷屏也防"用户还没点完、同一个进程被问十遍";log 模式在 Ask 入口直接短路返回 Allow,压根不碰通道——观测模式不能因为通道不在就变成拒绝。

卸载顺序,一步都不能换

卸载这五步是这个项目里我最不敢动的地方:

cpp

R3ShieldCorePrompt::NotifyShutdown();      // 1. 让还在等答复的 Ask 立刻收手
MH_DisableHook(MH_ALL_HOOKS);              // 2. 新调用走回原函数
Sleep(100);                                // 3. 给"跨过前几字节、还没进计数"的线程一点时间
RegistryGuard::WaitForHooksToDrain(10000); //    ...17 个 guard 各等一次
m_newProcessInjector.reset();              // 4. 等 CreateProcessInternalW 的在飞调用归零
MH_Uninitialize();                         // 5. 确认没人在 DLL 里了，才释放 trampoline

第 5 步之前的每一件事,都是为了确保没有线程还待在这个 DLL 的代码里。早期版本直接 MH_Uninitialize,结果把宿主打崩:那一步会释放 trampoline,而此刻可能有线程正卡在 hook 里(ask 模式下甚至停在等用户点按钮,最长几十秒),它返回的时候就是野指针。WER 报的是 r3shieldcore-lib.dll_unloaded,异常码 c0000005。实测打崩过 MyApp.exe 和 OfficeClickToRun.exe。

第 3 步能奏效,靠的是每个 hook 首尾那对 InterlockedIncrement/Decrement(&g_activeHooks)。这也是我说"130 处手工记账"是笔债的原因——这 130 处里任何一处漏了递减,WaitForHooksToDrain 就永远等不到归零,卸载卡死在那儿。

几个真踩过的坑

掩码用错位。 注册表那边判断"是不是写意图",我一开始拿 KEY_WRITE 当掩码。问题是它的 READ_CONTROL(0x00020000) 位和 KEY_READ 完全重叠,结果把一大票纯读打开全判成了写意图。实测十二秒里刷出 240 条噪音。这种错它不报错,只是安静地做错事。

一个连字符。 轮询路和同步路本来该共用同一个拼名函数去造那个去重互斥体的名字。同步路那份写成了 L"\\ProcessInitAPCMutex-pid=%u"——拼出来是个对象路径,而私有命名空间根本没被真的创建过,于是 CreateMutex 每次都返回 ERROR_PATH_NOT_FOUND,每次都抛异常。同步注入路从来没成功过一次,子进程被原样放行,全靠 10 毫秒轮询兜底,而日志里看起来一切正常。

注入两次就死。 会话信号量是按 pid 命名的。同一个进程被注入两次时,第二次的 create 拿到的是同一个信号量对象(计数已被第一次拿走),acquire() 就永久阻塞。如果第二次走的是 APC 路,这段代码跑在主线程上,于是主线程卡死、main 永远进不去:现象是窗口一片空白、进程常驻。改成先 OpenSemaphoreW 探测,存在就直接放弃这次注入——fail-fast,后来的让位给先到的。

只堵最后一步等于没堵。 代码注入链是四步:NtAllocateVirtualMemory 申请可执行内存 → NtWriteVirtualMemory 写 shellcode → NtProtectVirtualMemory 改成可执行 → NtCreateThreadEx 起线程。早先我只挂了最后一步,前面三步完全裸奔。补上之后,判据的唯一关键是目标进程 ≠ 当前进程:这几个 API 在每个进程里都被合法高频调用(.NET/Java 的 JIT、浏览器的 JIT、任何带 GC 的运行时都在自己进程里 allocate + write + protect),对本进程必须一律放行,否则整个系统当场瘫掉。

它拦不到什么

上面这一整套都建立在"它走用户态 API"的前提上。反过来,程序自己带 syscall 号直接进内核、手工映射一份 DLL、或者复制一个令牌——这三条我一条都拦不住。不是没修,是用户态这个位置本身够不着。

仓库里带了个 dskill.exe,就是用直 syscall 绕过我全部 hook 的。我把它打进发布包,一来让"能被绕过"这句话有实证,二来它也是自我保护生效后留给自己的逃生门。

顺着这个边界往下推:写 MBR 的恶搞程序拦不到(那不走任何用户态 API,得靠 minifilter 在内核拦 IRP_MJ_WRITE);提前进内核覆写硬盘、改 BIOS 的那种更够不着。但注册表自启、计划任务、加载 DLL、拉起子进程、出站连接这些要经过我挂着的 API 的动作,能在半路截住——银狐、熊猫烧香这类样本落在用户态的那部分手脚,就属于这一类。

说到底

它是那半个杀软:用户态这一半,注入、hook、拦 API,做得还算认真;内核和硬件那半边够不着。110 处钩子装在每一个进程里,从里面往外看。你要是想搞清楚自己机器上谁在动手,它够用——墙它变不出来。

用 Python 复现极域 V6.0 教师端通信协议

2026-10-05T19:27:00+08:00

用 Python 复现极域 V6.0 教师端通信协议

本文介绍一个基于 Python 的第三方极域课堂管理系统 V6.0 教师端模拟器。项目通过静态逆向分析与网络抓包，还原教师端和学生端之间的 UDP 通信过程，并将发现、登录、保活、消息、学生信息上报与屏幕缩略图等能力组合成一个可观察、可验证的协议实验平台。

本项目仅用于协议学习、安全研究与教学演示。请只在自己拥有或已获得明确授权的网络和设备上测试。

项目源码：yunsjxh/Third-party-JiYu-Teacher-Endpoint

为什么要重新实现一个教师端

课堂管理软件看起来是一个普通的桌面应用，但它背后其实包含了一套完整的局域网通信协议：教师端需要先在网络中宣告自己的存在，学生端发现教师后发起登录，双方继续交换保活包、状态包和控制包；当教师请求屏幕预览时，学生端还要把一张图像拆成多个 UDP 数据片段再发送回来。

如果只观察软件界面，我们看到的是“学生上线”“发送消息”“查看缩略图”等按钮；从协议研究的角度看，真正值得追踪的是另一组问题：

学生端如何判断网络中存在一个合法的教师端？
登录握手由哪些数据包组成，顺序是否重要？
同一个界面功能是否可能由多条协议路径共同完成？
UDP 不保证到达和顺序，缩略图应当如何重组？
二进制协议中的长度、字节序、编码和填充字段如何确定？

这个项目的目标不是简单模仿一个界面，而是把这些藏在可执行文件和网络流量里的规则，整理成一份能够运行的 Python 实现。

从黑盒到协议地图

协议还原主要依靠两类证据。

第一类是 IDA Pro 静态分析。它适合定位协议魔数、字段偏移、分支条件和关键常量。例如，一个 32 位整数在内存中以小端序出现时，0x434E4F4F 对应 ASCII 字符串 OONC；沿着接收函数继续追踪，就能看到程序如何按照不同 Magic 进入不同处理分支。

第二类是真实环境中的网络抓包。静态分析可以告诉我们“代码可能怎样解释这个字段”，抓包则能验证“正常教师端实际上发送了什么”。将多组样本逐字节比较后，才可能区分固定值、序列号、GUID、IP 地址、长度字段和可选负载。

最终得到的通信结构可以概括为两条 UDP 通道：

通道	地址	主要职责
主通道	`224.50.50.42:4705`	教师发现、保活、控制命令、屏幕缩略图
会话通道	`225.2.2.1:5512`	登录宣告、MESS 消息、状态与信息上报

教师端会周期性发送 OONC、CANC 和 ANNO，学生端通过 LOGI 进入登录流程，并用 KACA、TRMC 等报文维持会话。教师端随后回送 WACA、LPNT 和 DMOC，让学生端确认教师身份并进入稳定连接状态。

text

教师端模拟器                         极域学生端
     |                                  |
     |---- OONC / CANC / ANNO --------->|  发现教师
     |<------------- LOGI --------------|  请求登录
     |---- MESS / LPNT / DMOC ---------->|  完成握手
     |<------------- KACA ---------------|  保活/发现
     |---------------- WACA ------------>|  保活响应
     |---- TNRS / 信息请求 / 消息 ------->|  业务请求
     |<---- LANT / TNAL / MESS ----------|  数据回流

这张图也是整个程序的骨架。实现不再是一堆彼此孤立的十六进制常量，而是广播线程、会话接收线程、主通道接收线程和命令行交互之间的一组协作关系。

Python 如何表达二进制协议

项目没有引入复杂的协议框架，而是直接使用标准库中的 socket 和 struct。原因很直接：协议字段大多是固定长度的小端整数、GUID、IPv4 地址和 UTF-16LE 字符串，struct.pack 足以准确表达它们。

以教师在线宣告包为例，其实现由 Magic、版本、包体长度、教师 GUID、本机 IP 和递增序列号组成：

python

pkt = (
    struct.pack('<II', 0x434E4F4F, 0x10000)
    + struct.pack('<I', 16)
    + teacher_guid.bytes_le
    + socket.inet_aton(local_ip)
    + struct.pack('<III', 1, 1, sequence)
)

这里最容易出错的并不是 Python 语法，而是协议细节：

<I 表示小端无符号 32 位整数；
Windows GUID 的内存布局需要使用 bytes_le；
中文文本必须按 UTF-16LE 编码，并正确计算字符数和结尾空字符；
包头中的长度不一定等于最终 UDP 数据报长度，而可能只描述某一层负载；
某些接收路径会额外读取负载尾部，因此构造包时需要保留兼容填充。

二进制协议复现的核心不是“让程序发出数据”，而是让每个字节都能对应到可解释、可验证的字段。

难点一：黑屏和键鼠锁定其实是两条路径

项目中最有代表性的发现，是黑屏功能并不由一个命令独立完成。

逆向分析显示，学生端存在两条相关处理路径：MESS type=0x20 负责创建黑屏窗口并设置内部状态位，COMD case 6 负责实际锁定键盘和鼠标。只发送其中一条路径，表面上可能暂时有效，却会在解锁时暴露问题。

例如，仅通过 COMD 显示黑屏时，学生端内部的 bit 0x20 没有被正确设置。后续解锁命令进入另一段分支，无法执行预期的解锁函数。真实教师端的做法是组合两条路径，模拟器也因此采用同样的流程：

通过会话通道组播 MESS 黑屏包，建立黑屏状态；
需要锁定输入时，再向目标学生单播 COMD 命令；
定时黑屏到期后，由教师端主动发送解锁消息；
手动解锁时取消已有定时器，避免重复动作。

这说明逆向工程中一个很重要的原则：不能只根据界面效果判断协议是否还原正确。真正可靠的实现，还要匹配状态变化、后续行为和异常路径。

难点二：UDP 分片不是简单拼接

屏幕预览是另一个典型问题。学生端会通过 LANT/TNAL 报文分片发送 JPEG 数据，教师端需要维护每个学生独立的接收状态，包括总长度、当前缓冲区和已接收字节数。

项目使用学生 IP 作为重组键：新图像开始时创建状态，后续分片写入对应位置；只有在确认数据完整后才尝试交给 Pillow 解码。这样可以避免多个学生同时回传缩略图时互相覆盖。

成功解码并不代表图像已经正确。抓包样本还暴露了两个图像层问题：画面是 bottom-up 的，色度通道也存在反相。项目的修复流程是：

python

img = Image.open(io.BytesIO(buffer))
img = img.transpose(Image.FLIP_TOP_BOTTOM)
y, cb, cr = img.convert('YCbCr').split()
cb = ImageOps.invert(cb)
cr = ImageOps.invert(cr)
img = Image.merge('YCbCr', (y, cb, cr)).convert('RGB')

这段处理体现了协议分析经常遇到的情况：传输层的数据结构正确，只能说明“收到了一张图”；要得到视觉上正确的结果，还需要理解发送端图像缓冲区的存储方式和颜色空间。

难点三：同一个 MESS，必须先判断语义类别

MESS 是双向的通用消息容器。聊天、黑屏、周期状态、系统信息、进程列表和窗口列表都会经过它。如果只读取某个固定偏移并直接把数字解释成 subtype，就可能把进程 PID 当成 Wi-Fi 数量，把窗口句柄当成另一类状态值。

模拟器的处理方式是先读取 category，再进入对应解析器：

0x800000 表示信息上报；
type 5 是系统信息；
type 6 是窗口列表；
type 7 是进程列表；
周期状态则走另一套 subtype 解释规则。

系统信息包含计算机名、用户、MAC、操作系统、CPU 和内存等定长字段。窗口和进程列表采用分片形式，每个条目由一个 32 位 ID 和一个以空字符结尾的 UTF-16LE 名称组成。收到首片时清空旧数据，再将后续分片追加到对应学生的状态中。

这套设计让项目从“能发控制包”进一步变成了“能维护学生状态的教师端”。命令行中的 list、ps 和 wins 读取的正是这份动态建档数据。

让研究脚本具备可调试性

协议实验往往会产生大量重复数据。若每次在线宣告和心跳都输出完整十六进制转储，真正有价值的异常包很快会被淹没。

项目为此增加了几项工程化处理：

使用四个后台线程分别处理主通道广播、会话广播和两个接收循环；
过滤本机发出的多播，避免模拟器处理自己的数据；
将日常广播与高频心跳降到 DEBUG 级别；
使用轮转日志限制单个日志文件大小，并保留有限备份；
主窗口只负责 teacher> 命令交互，独立 PowerShell 窗口实时显示日志；
对未知包保留 hexdump，便于继续补充协议知识；
对黑屏操作设置自动解锁，降低实验中因参数错误造成的影响。

这些设计并不会改变协议本身，却显著改善了研究体验。协议实现最怕“偶尔能用但无法解释”，而良好的日志、状态隔离和错误输出，能够把一次偶发现象变成可重复验证的结论。

运行与观察

项目运行环境很轻量，只依赖 Python 3.8+ 和 Pillow：

bash

pip install Pillow
python "teacher_sim .py"

程序启动后会自动选择本机网络地址，加入两个多播组，并启动四个后台线程。学生端完成登录后，可以通过 list 查看已建档设备，通过 preview <ip> 请求屏幕缩略图，或使用 msg <ip> <text> 验证双向消息链路。

仓库还包含一个纯静态项目主页，由 index.html、styles.css 和 script.js 组成。页面用 Canvas 动画呈现数据包在教师端与学生端之间流动的效果，并把功能、协议通道、运行方式和安全边界整理成更直观的展示页面。它不参与教师端协议通信，因此核心模拟器仍然可以作为单文件 Python 程序独立运行。

项目带来的几个启发

回顾整个实现过程，有几条经验尤其值得保留。

第一，抓包和静态分析必须互相校验。只看流量，很难知道字段为何这样排列；只看反编译代码，也可能误判实际执行路径。二者结合，才能逐步建立可靠的协议模型。

第二，要优先还原状态机，而不是孤立的数据包。一个报文能被接收，不代表功能已经完成；登录顺序、状态位、定时器和响应包往往同样重要。

第三，解析器要先分层再解释。Magic、外层头、category、type 和具体负载各自属于不同层次，跳过上层语义直接解释下层字段，很容易得到“数值合理但含义错误”的结果。

第四，研究工具也需要安全护栏。自动解锁、目标登录校验、清晰日志和明确的授权范围，不只是使用体验问题，也是负责任地开展协议研究所必需的部分。

结语

这个项目把一个封闭桌面软件背后的通信过程，转化成了可阅读的代码、可观察的日志和可重复的实验。从教师在线宣告、学生登录，到消息解析和图像分片重组，每一项功能都建立在对具体字节和状态变化的理解上。

它目前仍是面向极域 V6.0 的研究性实现，并不追求替代成熟的课堂管理产品。它更有价值的身份，是一份活的协议笔记：当新的字段、新的包类型或更准确的握手顺序被发现时，代码、文档和实验结果可以继续相互印证。

项目采用 MIT License。无论阅读源码、复现实验还是继续扩展协议，都请始终把合法授权和最小影响放在第一位。

完整源码和后续更新可在 GitHub 仓库 yunsjxh/Third-party-JiYu-Teacher-Endpoint 查看。

疏影：面向 Weeback 的专项破解与工程实现

2026-10-05T19:23:00+08:00

疏影：面向 Weeback 的专项破解与工程实现

先把项目定位说清楚：疏影（Sparse Shadow）不是一款通用的 Windows 系统维护软件，而是围绕 Weeback 定制开发的专项破解工具。项目代码中出现的 MPPG / eClass Client 名称、进程、安装目录和数据库，都是这条破解链路的一部分。

它要解决的不是单一功能，而是一整套围绕对象程序展开的工作：定位安装信息和运行进程、管理 DLL 模块、读取数据库并还原管理员凭据字段、处理关联驱动，以及在用户态信息不足时借助自研内核驱动观察和管理进程状态。后来加入的 YsjxhProcess，把这些能力进一步延伸到了内核层。

其中，凭据字段的还原逻辑不是通过猜测或枚举尝试得出的，而是使用 IDA 静态分析 Weeback 的 Setup.exe 后，沿数据库写入流程定位到 sub_4CB0D0（地址 0x4CB0D0），再根据反汇编结果整理出的算法。这篇文章记录这条分析链路，以及疏影如何把分析结果落成一个完整工具。

疏影包含系统级和内核级操作能力，仅应用于本人拥有、管理或得到明确授权的设备。涉及驱动、进程保护和未公开内核结构的功能，应当在具有快照和内核调试条件的隔离虚拟机中测试。

下载:https://wwaux.lanzoul.com/i09ox3y8kzcd

一个统一的破解与调试界面

疏影主程序使用 C++20、Win32 和 GDI+ 编写。界面没有采用传统工具软件中密集堆叠的系统控件，而是围绕 Material Design 3 的层级重新组织了信息：

侧栏负责功能导航；
状态卡片呈现安装、进程和驱动概况；
危险操作与普通查询使用不同的颜色和确认流程；
操作结果统一进入活动日志；
“扩展驱动工具”窗口使用与主界面一致的浅色 MD3 风格。

目前主界面覆盖 Weeback 安装信息扫描、相关进程管理、DLL 模块操作、数据库字段还原、关联驱动处理、内核进程和活动日志等页面。功能虽然较多，但所有入口都服务于同一个明确目标，而不是试图做成包罗万象的系统工具。

主程序真正做了什么

疏影的大部分功能都在用户态完成，不需要安装 YsjxhProcess。普通启动时，程序会把安装记录、目标目录、运行进程、数据库和关联组件串成一条连续的破解流程；内核驱动只是处理少数特殊状态时才使用的可选扩展。

自动检测与破解概览

启动后的概览页不是静态菜单。程序会读取 32 位和 64 位卸载注册表视图，寻找与 Weeback、MPPG 和 eClass Client 相关的安装条目，并从 DisplayName、InstallLocation 和卸载命令中整理产品名称、版本与安装目录。找到有效目录后，后续的进程扫描和 DLL 页面会自动使用同一个目标范围。

同一次检测还会尝试定位 mppgsvrc.db、读取管理员记录，并扫描关联的服务、SYS 文件、键盘过滤项和网络过滤组件。概览卡片最终汇总安装条目数、运行进程数、数据库状态与关联组件数量，用户不必逐页点击才能判断当前机器的大致状态。

如果注册表信息缺失、路径已经失效，或者使用的是非标准安装位置，也可以手动选择目录。手动目录会替代自动结果，避免工具因为安装程序没有正确写入卸载信息而失去后续功能。

安装目录与进程联动

“安装与进程”页面并不是按一份写死的进程名列表工作。疏影会递归收集目标安装目录中的 .exe 文件名，再用 Tool Help 进程快照匹配当前正在运行的实例。列表中显示可取得的 PID、进程名称和完整映像路径，因此新版本增加或更换可执行文件后，通常不需要同步修改程序内的固定名称表。

用户可以重新扫描，也可以结束当前识别出的相关进程。结束操作会执行两轮，中间短暂等待，再重新生成快照：第一轮处理当前实例，第二轮用于发现退出较慢或短时间内重新出现的同名进程。每个成功和失败结果都会计数并写入活动日志，拒绝访问的进程不会被伪装成处理成功。

这套“目录先限定范围、进程再动态匹配”的方式也服务于 DLL 页面。它比单纯按名称操作多了一层路径约束，可以减少同名程序被误判为 Weeback 组件的可能。

DLL 模块管理

DLL 页面允许在已识别的目标进程之间切换，选择本地 .dll 文件后执行加载或卸载。真正操作前，程序会再次打开目标进程、确认它仍在运行、重新读取当前映像路径，并验证路径仍位于选定的 Weeback 安装目录内。这样可以防止列表刷新前后 PID 被复用，或同名进程来自其它目录时误操作。

加载成功后，界面会记录模块文件名、目标进程名和 PID；重复加载会明确提示模块已经存在。卸载时按所选 DLL 的模块名在目标进程中定位，不要求用户手工输入基址。目标消失、路径变化、权限不足或模块不存在时，界面保留系统错误码与可读错误信息，便于继续排查。

DLL 操作属于会改变目标进程状态的功能，因此它只接受明确选择的安装目录内进程和本地 DLL，并在执行前显示确认。它不是面向任意 PID 的通用注入器。

数据库定位与字段还原

数据库页面既支持手动选择 mppgsvrc.db，也会按盘符检查 Weeback / eClass Client 的常见目录。如果已经识别出安装路径，程序还会在该目录下继续查找数据库。选定文件后，路径与处理状态会保留在页面中，不需要每次操作重新输入。

读取凭据时，疏影通过 SQLite 查询 users 表中大小写不敏感匹配的 Admin 记录，并用 CAST(password AS BLOB) 保留字段的原始字节。随后才执行 IDA 分析得到的 0xB3 变换、截断空字节并转换为界面字符串。独立脚本 decrypt_mppg_password.py 提供相同的文件定位和命令行核对入口，方便在 GUI 之外验证数据库内容。

这里没有字典、口令枚举或联网查询。功能的核心是复现目标程序自身的数据变换；具体逆向过程放在下一节单独说明。

关联组件检查与清理

“驱动清理”页面虽然处理的是驱动遗留物，但整个编排发生在用户态。检查阶段会分别列出固定服务、System32\drivers 中的关联 SYS 文件、键盘类注册表里的 kafe UpperFilters 项、MS_NdisNetFilter 网络组件，以及 Driver Store 中匹配的 OEM INF 包。页面区分正在运行、文件存在、等待重启删除和已暂存等状态。

执行完整清理时，疏影会先停止并删除对应服务，备份键盘类 UpperFilters 后只移除目标项，再处理 SYS 文件、网络过滤组件和 Driver Store 包。正在占用的文件可以登记为重启后删除；只读属性会先被清除。完成后会重新扫描、生成详细日志和 UpperFilters 备份，并让用户决定是否安排延迟重启。

这不是简单地遍历目录删除文件。服务、注册表过滤器、网络组件和驱动包各自使用对应的 Windows API，失败项单独统计，避免某一步失败后仍给出“全部完成”的结论。

活动日志、确认与窗口能力

安装检测、目录选择、进程结束、DLL 操作、数据库处理、组件清理和驱动状态查询都会进入当前会话的活动日志。界面同时使用短暂提示展示即时结果，而较长的路径、错误码和统计信息留在日志页，避免提示框承载过多文本。

会改变系统状态的操作会先进入统一确认流程，危险操作使用独立的视觉样式。主窗口还支持普通置顶和同用户 UIAccess 增强置顶，并保存置顶偏好；这主要用于破解时同时观察其它程序窗口，不改变当前用户本身的权限。

从实际使用顺序看，疏影首先是一套用户态破解工作台：自动发现环境，限定目标范围，完成进程、模块、数据库和残留组件处理，并记录每一步结果。只有这些能力不足时，才需要进入后面的内核进程页面。

用 IDA 还原 sub_4CB0D0

Weeback 使用的服务端数据库 mppgsvrc.db 是一个 SQLite 数据库。管理员记录位于 users 表中，凭据内容保存在 password 字段。直接查看字段只能看到处理后的字节，但它并不是不可逆摘要，而是 Setup.exe 写入前做过一次可逆变换。

在 IDA 中跟进数据库写入相关调用后，可以定位到地址 0x4CB0D0 的函数 sub_4CB0D0。交叉引用说明它位于凭据字段进入数据库之前的数据处理路径上。去掉反编译器生成的类型和临时变量后，其核心逻辑可以整理为：

while (*input) {
    if (*input == 0xB3)
        *output = *input;
    else
        *output = *input ^ 0xB3;

    ++output;
    ++input;
}

从 IDA 伪代码中可以直接提取四个判断点：循环条件读取当前输入字节，说明 0x00 是结束标记；条件分支单独比较 0xB3；普通分支只执行一次固定常量 XOR；循环尾部同时递增输入和输出指针。函数没有动态密钥或状态表，因此整个字段处理过程可以被完整复现。

也就是说，函数逐字节读取以 \0 结尾的输入：字节等于 0xB3 时原样复制，其余字节与 0xB3 异或。异或满足自反性：

text

(x XOR 0xB3) XOR 0xB3 = x

因此，正向处理和还原可以使用同一套变换。不过这里有一个容易被一句“再异或一次”掩盖的边界条件：0xB3 在原函数中不会参与异或，所以还原时也必须保持不变。对于只包含常见 ASCII 字符的输入，无条件异或通常能得到相同结果；若要严格复刻原函数，则应保留这个特殊分支。

严格复刻 sub_4CB0D0 时，等价的解码循环应写成：

cpp

for (auto& byte : cipher) {
    if (byte != 0xB3) {
        byte ^= 0xB3;
    }
}

为什么这个变换能够原样还原？输入循环不会处理作为字符串结束符的 0x00。对于有效输入字节，只有 0x00 ^ 0xB3 才会产生 0xB3，而 0x00 不属于被处理的字段内容。因此，结果中的 0xB3 可以按原函数语义解释为输入字节 0xB3，不会与另一个有效输入字节冲突。

在疏影中，数据还原页面先以 BLOB 方式读取字段，避免 SQLite 文本转换提前截断或改变字节：

sql

SELECT name, CAST(password AS BLOB)
FROM users
WHERE name = 'Admin' COLLATE NOCASE;

随后对返回的字节序列执行还原，在第一个空字节处截断，再按 UTF-8 转为界面使用的宽字符串。项目还提供独立的辅助脚本 decrypt_mppg_password.py，既可接收数据库路径，也可扫描常见安装目录寻找 mppgsvrc.db。如果原始内容可能包含字节 0xB3，GUI 与脚本中的处理循环也应保留上述特殊分支；对于普通 ASCII 内容，逐字节无条件 XOR 的结果与这条分支一致。

这段 IDA 分析也说明了可逆字段处理与安全存储的区别。固定常量的逐字节异或没有密钥管理、随机盐、初始化向量或单向性；一旦算法被确认，数据库中的内容即可按原流程还原。疏影所做的是把这个静态分析结论自动化。工具展示结果时仍应限制在本人拥有或得到明确授权的设备上，也不应把还原后的内容写入持久日志。这是对产品对客户不负责任的态度造成的。

可选的内核扩展：YsjxhProcess

安装扫描、普通进程管理、DLL 模块操作、数据库字段还原和关联组件清理都不依赖 YsjxhProcess。只有需要观察或修改普通 Win32 接口无法覆盖的内核进程状态时，疏影才使用这个独立驱动组件。

项目结构大致如下：

text

疏影.exe
  ├─ Win32 / GDI+ 主界面
  ├─ YsjxhProcessClient 用户态客户端
  └─ 内嵌 YsjxhProcessDriver.sys

YsjxhProcessDriver.sys
  ├─ 设备与 IOCTL 分发
  ├─ 进程状态枚举
  ├─ 进程状态管理与恢复
  ├─ 自身保护回调
  └─ profile 配置与运行时校验

YsjxhProcessCtl.exe
  └─ 命令行诊断和测试入口

主程序与驱动通过共享 IOCTL 协议通信。Release 构建会把同一次生成的 SYS 嵌入疏影，运行时再释放到 %ProgramData%\YsjxhProcess。这样可以避免用户误拿旧驱动，也能确保界面、协议和驱动版本保持一致。

默认不加载驱动

内核驱动的错误可能直接影响整个操作系统，因此疏影没有把“启动程序”和“加载驱动”绑定在一起。

普通启动时，疏影只查询 YsjxhProcess 是否已经运行，不会创建或启动驱动服务，也不会自动修改自身进程保护级别。如果确实需要在启动阶段加载驱动，可以在启动程序的同时按住 Shift。程序会在进入界面前记录这一按键状态，随后执行驱动释放、服务启动、profile 配置和疏影自身保护。

这套设计保留了快捷启动能力，同时为驱动异常提供了一个明确的安全回退入口：不按 Shift 即可进入纯用户态界面，继续查看日志、卸载服务或处理环境问题。

每秒刷新，但不打断操作

“内核进程”页面可见时会每秒读取一次驱动进程快照。自动刷新最容易出现的问题，是列表不断跳回顶部，或者用户刚刚选中的进程在下一次刷新时丢失。

疏影没有直接保存表格行号，而是保存选中进程的 PID，并使用当前顶部进程作为滚动锚点。刷新完成后再根据新的快照重新定位。这样即使进程数量和排序发生变化，界面也能尽量保持原来的操作上下文。离开“内核进程”页面后，定时驱动查询会停止，避免无意义的后台 IO。

不猜测内核偏移

进程保护和部分进程状态依赖 Windows 内核中的未公开字段。这类实现最大的风险之一，是把某个系统版本的 _EPROCESS 偏移直接套用到另一个版本。

YsjxhProcess 的配置流程会读取当前 ntoskrnl.exe 的机器类型、时间戳和映像大小，再与构建期生成的 profile 矩阵进行精确匹配。对于缺失数据，只允许在同一版本序列中使用“前后锚点完全一致”的桥接值；无法可靠确认的字段会被标记为不支持，而不是根据相邻版本猜测。

偏移下发后，驱动还会在内核态检查 System PID、活动进程链表互指关系和保护字段布局。任何关键校验失败都会拒绝启用配置。这不能消除使用未公开结构的全部风险，但可以把明显错误挡在真正修改内核状态之前。

扩展驱动工具窗口

疏影的常用页面只保留经过约束的进程操作；需要诊断完整驱动能力时，可以打开独立的“扩展驱动工具”窗口。

该窗口把驱动服务、进程状态操作、模块与规则、内核回调、路径操作、驱动查询和活动日志分区呈现。所有修改型操作都需要再次确认，危险按钮使用独立的错误色，查询与浏览操作则保持中性色。长状态信息会在顶部摘要中省略，并完整记录到日志区域。

这些能力面向隔离环境中的驱动开发、故障定位和授权实验，不应在日常工作机或未知目标上使用。

构建与签名顺序

项目同时包含用户态程序和 WDK 驱动，完整 Release 可以在 Visual Studio Developer PowerShell 中构建：

powershell

.\build-release.ps1

脚本会依次构建驱动、图形启动器、命令行工具和疏影主程序，最终输出位于 dist 目录。

如果需要对发布文件签名，顺序不能颠倒：

text

冻结驱动版本
  → 签名最终 SYS
  → 将签名 SYS 重新嵌入疏影
  → 完成发布前二进制处理
  → 最后签名发布 EXE

任何发生在签名之后的二进制修改都会破坏对应签名。驱动能够在测试签名环境加载，也不代表它已经获得普通 Windows 和 Secure Boot 环境所要求的生产级 Microsoft 内核签名。

开源致谢

感谢 KSwordDEV/KSword 项目带来的开源、实用的 ARK 工具，同时感谢该项目源码对本项目驱动设计与实现的启发。

优秀的系统工具不仅提供了可用功能，也展示了用户态与内核态如何划分职责、如何组织协议、如何处理动态数据，以及如何在高风险能力周围建立必要的验证与边界。疏影在开发过程中从这些经验中受益良多。

同时，项目使用到的第三方库、SDK 和工具仍分别遵循其原有许可证。引用和学习不等于抹去来源，清晰记录依赖与启发来源也是工程工作的一部分。

写在最后

疏影目前仍在持续迭代，但它的定位已经很明确：这是一个建立在 Weeback 静态分析结果之上的专项破解工具，而不是通用系统管理平台。安装路径、对象进程、数据库结构、字段变换和驱动操作都围绕这一目标设计。

凭据字段部分最关键的结论来自 IDA 中的 sub_4CB0D0：除 0xB3 自身保持不变外，其余输入字节都与 0xB3 异或。把这一结论与 SQLite 字段读取、进程管理和驱动能力组合起来，才形成了现在的疏影。后续工作仍需要把高风险能力限制在清晰的前置条件内，并为失败操作保留日志与恢复路径。

从黑盒到可交互画面：极域 V6.0 连续投屏与远程操控协议逆向

2026-10-05T19:14:00+08:00

从黑盒到可交互画面：极域 V6.0 连续投屏与远程操控协议逆向

本文记录 2026.07.31 研究预览版中连续屏幕观看与远程操控链路的逆向过程。结论来自 IDA Pro 静态分析、官方教师端/学生端真实流量对照、逐字节重放和运行日志验证。本文只讨论隔离实验环境中的协议研究，不应被用于未经授权的监控或控制。

摘要

极域 V6.0 的“观看学生屏幕”和“远程控制学生”不是一个简单的 UDP 命令，也不是把截图循环发送回来。完整链路至少跨越三类通道：

教师端先经 5512/UDP 的 MESS feature=8 通知学生端启动桌面发送功能；
教师端连接学生端 4806/TCP，发送 SHCO 选择 UMSP channel 10，再从 TKPC 中重组 HHRF/HJRF 桌面记录；
进入控制模式时，教师端再用 COMD 事务承载 MCMD，让学生端在指定 UDP 端口启动模拟输入接收器；鼠标和键盘事件通过固定 28 字节输入包发送。

截至当前版本，连续观看、H.264/JPEG 解封装、色度修正、SPUC 光标解析以及远程鼠标移动/点击已经在测试环境验证。键盘只验证到教师端捕获和 kind=16 发包，学生端是否最终完成 SendInput 仍不稳定，因此仍是实验性功能。

能力	当前证据
4806/TCP 建连与 SHCO 选路	已验证
TKPC 分片重组	已验证
HHRF/H.264、HJRF/JPEG 解析	已验证
U/V 色度平面修正	已验证
SPUC 远端光标解析	已验证
MCMD mode=2 建立控制	已验证
28 字节鼠标包	移动与点击已验证
kind=16 键盘包	捕获与发包已验证，学生端执行未稳定验证

一、先建立正确的系统模型

最初最容易犯的错误，是把“投屏”理解成缩略图协议 LANT/TNAL 的高频版本。抓包很快就能否定这个假设：点击官方教师端的“监看”后，学生端除了继续保活，还会开放或使用 4806/TCP；真正的连续画面主要出现在这条 TCP 流中。

远程控制同样不是直接向 4705/UDP 塞一个 WM_MOUSEMOVE。官方流程会先复用已经建立的桌面观看会话，然后通过通用命令事务启动一个独立的模拟输入通道。

mermaid

sequenceDiagram
    participant T as 第三方教师端
    participant S as 极域学生端

    T->>S: TCP connect probe :4806（只探测）
    T->>S: MESS feature=8 / start（5512/UDP）
    T->>S: TCP connect :4806
    T->>S: SHCO / channel 10
    S-->>T: TKPC / channel 10 / 桌面分片
    S-->>T: HHRF(H.264) 或 HJRF(JPEG)
    T->>S: COMD transaction → MCMD mode=2
    Note over S: BeginSimulate，监听指定 UDP 端口
    T->>S: 28-byte mouse input
    S-->>T: SPUC cursor record
    T->>S: 28-byte kind=16 keyboard input（实验性）

这个模型解释了几个看似无关的现象：

只发送 feature 8，不连接 TCP，不会得到可显示的连续画面；
直接发输入包时，学生端没有对应 UDP 接收器，数据只会被操作系统丢弃；
从 view 切换到 control 时重启 H.264 解码器，容易永久黑屏，因为新解码器没有收到此前的 SPS/PPS/IDR；
本地鼠标与学生端鼠标短暂错位并非只有坐标算法问题，还包含编码、网络、显示和 SPUC 回传延迟。

二、在 IDA 中如何找到入口

2.1 不要只搜索可见字符串

这类老式 C/C++ 网络库常把 FourCC 写成 32 位立即数。文件里的字节顺序是人眼可读的 SHCO，反汇编中却可能出现：

text

wire bytes: 53 48 43 4F  -> "SHCO"
IDA imm32 : 0x4F434853

wire bytes: 54 4B 50 43  -> "TKPC"
IDA imm32 : 0x43504B54

原因是 x86 使用小端序。仅在 Strings 窗口里搜索 SHCO 很可能什么也找不到，应该同时搜索对应的立即数，然后查看交叉引用。

本次逆向中最有效的一组锚点是：

线索	作用
`0x4F434853`	定位 UMSP channel 选择包 `SHCO`
`0x43504B54`	定位 UMSP 数据包 `TKPC`
`0x46524848`	定位 `HHRF` H.264 桌面记录
`0x46524A48`	定位 `HJRF` JPEG 桌面记录
`MCMD`	定位监看/控制模式切换结构
`SPUC`	定位光标状态记录
`0x2321347C`	定位模拟输入包分发器
常量 `4806`、channel `10`	从通用传输库缩小到桌面通道

2.2 从网络 API 反推对象边界

打开 LibBaseTrans.dll 后，先建立导入函数关系：connect、send、recv、WSARecv、线程创建、临界区和缓冲区复制。不要急着给每个函数命名，先回答三个问题：

哪个对象持有 socket？
哪个循环读取 12 字节头并按长度字段切包？
哪个分支在 payload 起始位置读取 channel id？

从 0x43504B54 的交叉引用向上回溯，可以看到一个典型的“版本 + magic + payload length”检查；继续向下跟踪，payload 的首个 u32 被当作 channel。channel 10 随后进入桌面数据处理对象，而其他 channel 被分派给不同业务。

在 IDA 中可以先做以下重命名，之后伪代码会清晰很多：

text

sub_xxx_connect     -> umsp_connect
sub_xxx_read_loop   -> umsp_recv_loop
sub_xxx_dispatch    -> dispatch_umsp_channel
sub_xxx_channel10   -> handle_desktop_fragment
sub_xxx_record      -> handle_desktop_record

名字不必一开始就完全正确。关键是让“传输层、分片层、记录层、编解码层”不再混在同一张调用图里。

2.3 从 feature 分发器找到 617 字节参数块

在学生端的 MESS 处理路径中，feature id 8 会进入远程观看分支。这个分支不是只读一个布尔值，而是复制一个较大的参数对象。把官方教师端报文和伪代码中的复制长度对照后，可以确定：

内层 feature payload 总长为 617 字节；
前 12 字节是 length / feature / flags；
中间 604 字节是远程观看参数；
最后还有 1 字节尾部填充。

不要把参数块里的端口直接当成学生端 4806/TCP。其中两个端口属于教师会话/桌面监控端点；学生端的 TCP 服务端口是另一层连接目标。这两个概念混用，会构造出长度正确但状态错误的请求。

2.4 从 MCMD 跟到模拟输入

MCMD 位于通用 COMD 事务内部。沿 MCMD 分支继续跟踪，可以看到 mode 分派以及模拟输入初始化路径。当前观察到的行为是：

mode=0：Share，双方可操作；
mode=2：Control Student，启动模拟输入并额外进入学生端本地输入锁定路径；
mode=1：本项目用于停止当前模拟输入会话。

再从输入接收线程向下跟踪，固定 magic 0x2321347C 是很强的定位点。分发器读取紧随其后的 kind，然后按鼠标或键盘结构解释剩余 20 字节。

逆向时必须继续跟到系统调用边界。看到 UDP recvfrom 并不表示控制已经生效，真正需要确认的是后续是否构造 INPUT、是否调用 SendInput、调用发生在哪个 Windows Session/desktop，以及本地 Hook 是否会再次拦截注入事件。

三、用抓包给反汇编“定类型”

IDA 告诉我们代码可能怎样解释内存，抓包则告诉我们线上实际发送了什么。两者必须互相约束。

建议只在隔离测试网中采集，并把一次操作拆成单变量实验：

只打开“观看屏幕”，不移动鼠标；
只切换到“远程控制”，不输入；
只移动一次鼠标；
只按一次左键；
只按一个普通字母键；
分别停止控制和停止观看。

Wireshark 初始过滤器：

text

udp.port == 4705 || udp.port == 5512 || tcp.port == 4806

找到对应 TCP stream 后，再单独查看：

text

tcp.stream eq <n>

抓包分析时不要依赖 TCP segment 边界。一次 recv 可能拿到半个 UMSP 包，也可能一次拿到多个包。正确做法是维护流缓冲区，只有当缓冲区至少包含 12 字节头，并且达到 12 + payload_len 后才取出一包。

3.1 差分比对比猜字段更快

对 MCMD 和输入包尤其适合做差分：固定所有条件，只改变一个操作。例如把鼠标从画面左上移动到右下，比较两包中变化的 4 字节字段；连续点击左键，观察 0x0201 与 0x0202 的成对出现；滚轮则会让 data 字段变化。

字段命名按证据逐步升级：

text

unknown_08
  -> changes_with_x
  -> normalized_x
  -> normalized_x_u16_range_in_u32

不要因为某次值恰好等于屏幕像素，就立即命名为 pixel_x。本协议鼠标坐标实际使用 0..65535 归一化范围，窗口尺寸和远端编码尺寸只是映射输入。

四、观看请求：MESS feature 8

当前实现构造的 feature payload 如下。所有多字节整数均为小端；IP 地址保持网络序原始字节。

4.1 feature 8 内层结构

偏移	大小	当前解释	观察值
`0x000`	4	payload length	`617`
`0x004`	4	feature id	`8`
`0x008`	4	start flags	`0x80000000`
`0x00C`	604	remote-view params	见下表
`0x268`	1	tail padding	`0`

604 字节参数块中，已经通过官方流量和代码路径确认或稳定观察到的字段：

参数内偏移	大小	含义	当前值
`+0x00`	4	RemoteWithVoice	`0`
`+0x04`	4	教师 IP	network order
`+0x08`	2	教师会话端口	当前频道端口
`+0x0A`	4	教师 IP（第二端点）	network order
`+0x0E`	2	桌面监控端口	当前频道端口
`+0x24`	4	NetworkType	`1`
`+0x28`	4	ShowMonitorControlMessage	`1`
`+0x2C`	4	MaxSendSpeed	`20480`
`+0x30`	4	RepairMode	`1`
`+0x34`	4	MaxPacketSize	`1440`
`+0x38`	4	FrameLimit	`25`
`+0x3C`	4	CaptureQuality	`75`
`+0x40`	4	TcpCommMode	`1`
`+0x44`	4	学生 IP	network order
`+0x48`	12	未完全命名的三元组	`5, 12, 16`

最后一组三元组虽然已经稳定复现，但在没有进一步交叉引用证据前不应强行解释其业务名称。保留“已知偏移 + 已知值 + 未知语义”比写一个听起来合理的名字更有研究价值。

停止观看使用另一种短结构：

text

u32 length  = 13
u32 feature = 0
u32 flags   = 0
u8  tail    = 0

4.2 正确启动时序

当前稳定时序是：

text

TCP connect probe 4806（立即关闭，不发 SHCO）
    -> MESS feature 8 start
    -> 单次连接 4806/TCP
    -> 立即发送 SHCO channel 10
    -> 从第一条 H.264 记录开始喂给同一个解码器

探测步骤只检查 TCP 是否监听，不启动编码器，也不发送 SHCO。正式启动后不能在失败时高频重试：学生端编码器和内部线程存在状态，重复 feature 请求或并发 TCP 会话可能导致学生端异常退出。当前实现限制每个 IP 同时只有一个观看会话，并在失败后冷却 60 秒。

五、UMSP：SHCO、TKPC 与 channel 10

5.1 SHCO 选择包

连接 4806/TCP 后，教师端发送 20 字节选择包：

偏移	类型	值
`0x00`	`u32`	version `0x00010000`
`0x04`	`u32`	`0x4F434853`，线上为 `SHCO`
`0x08`	`u32`	body length `8`
`0x0C`	`u32`	selector/op，观察值 `1`
`0x10`	`u32`	desktop channel `10`

这里的 channel 10 是业务复用编号，不是 TCP/UDP 端口。

5.2 TKPC 数据包

学生端返回的 UMSP 包使用 12 字节公共头：

偏移	类型	说明
`0x00`	`u32`	version，预期 `0x00010000`
`0x04`	`u32`	`0x43504B54`，线上为 `TKPC`
`0x08`	`u32`	payload length
`0x0C`	`u32`	channel id，桌面为 `10`
`0x10`	bytes	channel payload

代码或符号中可能把它写作 TCPK，但线上字节是 TKPC。逆向协议时应始终区分“源码/反编译变量名”和“wire bytes”，否则 Wireshark 搜索与代码常量会互相对不上。

六、桌面分片重组

channel 10 的 payload 不是直接的 H.264 NAL，而是先经过一层 12 字节桌面分片：

text

+0x00  u32 frame_seq
+0x04  u32 fragment_offset
+0x08  u32 record_total_size
+0x0C  bytes fragment_data

重组器按 frame_seq 保存状态，以 record_total_size 分配缓冲区，然后把每个 fragment 写入指定 offset。实现时至少要处理：

TCP 读取边界与 UMSP 包边界不一致；
同一分片重复到达；
分片乱序；
新 frame_seq 到来时旧帧仍未完成；
offset 或 length 越界；
恶意或损坏的 total size 导致大内存分配。

当前实现给每帧维护一份 seen 位图，只把第一次出现的字节计入 received，避免重复分片使计数提前达到 total。最多同时保留四个未完成帧，并将桌面记录大小限制在 0x241800。

一个重要踩坑是：并非所有完整记录都大于 64 字节。SPUC 光标记录只有 16 字节。如果在分片层直接用“total < 64”判定非法，就会把光标状态误报为坏帧。正确做法是先完成通用重组，再在记录层按 magic 和长度分流。

七、HHRF/HJRF 桌面记录

视频类记录包含一个 64 字节头：

偏移	大小	说明
`0x00`	4	magic：`HHRF` / `HJRF` / `HMRF`
`0x04`	4	declared record size
`0x08`	4	timestamp
`0x0C`	16	encoded rect：left/top/right/bottom
`0x1C`	16	visible rect：left/top/right/bottom
`0x2C`	4	frame type
`0x30`	16	尚未完全命名的字段
`0x40`	variable	编码 payload

magic 对应关系：

text

0x46524848 -> wire "HHRF" -> H.264 Annex-B
0x46524A48 -> wire "HJRF" -> JPEG
0x46524D48 -> wire "HMRF" -> legacy/兼容记录

日志中的一个真实样本为：

text

H264 frame=1 seq=11 record=623 declared=623
encoded=(0,0,1728,928) visible=(0,0,1718,918)

这说明编码尺寸和实际可见尺寸并不总相同。直接按 encoded rect 展示会在边缘出现填充区域，所以解码后还需要按 visible rect 裁剪。

7.1 为什么请求真实 H.264 时容易“黑屏”

H.264 是有状态码流。解码器通常需要先看到 SPS、PPS 和 IDR，才能解释后续 P/B 帧。下面几种做法都会造成只有数据、没有画面：

TCP 建连太晚，错过码流初始化；
先用一个播放器观看，切换 control 时杀掉播放器再启动另一个；
把多次观看留下的半段 .h264 直接拼在一起；
将 UMSP/桌面记录头误写进 H.264 payload；
按 TCP recv 块直接喂解码器，破坏了上层记录边界。

当前实现从第一帧开始固定使用 bundled FFmpeg，view -> control 只改变窗口交互状态，不重启解码进程。可选裸流也按会话时间戳独立保存，避免把上一次的不完整码流接到新会话前面。

7.2 为什么画面颜色会错

拿到画面后，最明显的问题曾是整体色相不对：本应为蓝色的区域显示成另一种颜色。几何内容正确、亮度基本正确而色相系统性错误，通常不是 RGB/BGR 顺序问题，而是 YUV 色度平面顺序问题。

对同一帧分别尝试常见转换后，可以确认极域这条 H.264 链路的 U/V 平面需要交换。FFmpeg 过滤器为：

text

shuffleplanes=0:2:1:3

然后再按可见尺寸裁剪：

text

shuffleplanes=0:2:1:3,crop=<visible_w>:<visible_h>:0:0

这里选择在显示管线修正，而不改写保存的 H.264 裸流。这样原始证据仍可用于后续协议分析，同时实时窗口显示正确颜色。

八、SPUC：远端光标不是画面的一部分

光标状态使用独立的 16 字节记录：

偏移	类型	说明
`0x00`	4 bytes	`SPUC`
`0x04`	`u32`	record size，预期 `16`
`0x08`	`u32`	timestamp
`0x0C`	`u32`	packed position

位置打包方式：

text

x = packed_position & 0xFFFF
y = packed_position >> 16

实际控制窗口中有三个“鼠标位置”：

本机系统指针；
刚刚发送给学生端的预测位置；
学生端通过 SPUC 回传的确认位置。

如果三者同时显示，用户会看到两个指针互相追赶。因此投屏区域隐藏本机系统指针；发送鼠标事件后的短时间内显示本地预测位置，约 180 ms 后切回 SPUC 确认位置。这个策略不能消除网络和编码延迟，但能减少操作感上的跳变。

画面显示可能经过缩放，坐标必须基于实际图像区域，而不是整个窗口或屏幕：

text

normalized_x = round(local_x * 65535 / (display_width  - 1))
normalized_y = round(local_y * 65535 / (display_height - 1))

预测光标绘制回源画面时，再从 0..65535 映射到 encoded width/height。忽略这两次映射，会在窗口缩放后产生越来越明显的位置偏差。

九、远控建立：COMD 事务中的 MCMD

MCMD 不能作为裸 UDP 报文发送，它是通用 COMD transaction 的 payload。COMD 外层负责版本、事务 GUID、超时、发送者和 payload 长度；学生端先进入事务分发器，再把 MCMD 交给监看/控制模块。

当前 MCMD 内层固定为 53 字节：

偏移	大小	说明
`0x00`	4	inner length `53`
`0x04`	4	feature/category `8`
`0x08`	4	flags `0`
`0x0C`	4	magic `MCMD`
`0x10`	4	mode：`0` / `1` / `2`
`0x14`	4	学生 IP，网络序字节
`0x18`	2	学生端输入监听 UDP 端口
`0x1A`	27	保留/零填充

项目默认从 49152..65535 随机选择一个高位端口。使用固定端口虽然方便抓包，但学生端异常退出后旧线程或状态可能仍占用它；随机端口更适合反复调试。

MCMD 发出后不能立即发送第一条输入。学生端需要创建接收线程并完成 BeginSimulate 初始化。当前实现保守等待约 350 ms；这不是协议字段，而是从实际时序中得到的工程性保护。

为了避免学生端进入“有控制状态、没有画面会话”的不完整状态，control 只在 4806/TCP 已经连接后发送 MCMD。停止时发送 mode=1 并关闭本地 UDP sender。

十、28 字节模拟输入包

所有输入事件使用相同外壳：

text

+0x00  u32 magic = 0x2321347C
+0x04  u32 kind
+0x08  u8  payload[20]
total = 28 bytes

线上 magic 的小端字节是：

text

7C 34 21 23

固定总长非常重要。多一个字节或少一个字节都可能让学生端接收线程丢包，或者让后续字段错位。

10.1 鼠标：kind=1

鼠标 payload 是五个 u32：

payload 偏移	字段	说明
`+0x00`	message	Windows 鼠标消息
`+0x04`	x	`0..65535` 归一化坐标
`+0x08`	y	`0..65535` 归一化坐标
`+0x0C`	data	滚轮等附加数据
`+0x10`	swapped	键位交换/保留状态

已验证的 message：

动作	值
move	`0x0200`
left down / up	`0x0201` / `0x0202`
right down / up	`0x0204` / `0x0205`
middle down / up	`0x0207` / `0x0208`
wheel	`0x020A`

鼠标移动和点击在当前学生端环境已经观察到实际执行结果，因此证据链不仅停留在“教师端 sendto 成功”。

10.2 键盘：kind=16，仍是实验性

当前根据反汇编字段访问和教师端行为构造的 20 字节 payload：

payload 偏移	类型	说明
`+0x00`	`u16`	scan code
`+0x02`	`u16`	virtual key
`+0x04`	`u32`	flags
`+0x08`	12 bytes	zero/reserved

当前 flags：

text

bit 0    = extended key
bit 7    = key up

普通按下为 flags=0，释放为 flags=0x80；扩展键按下/释放再或上 0x01。

Tk 的键盘事件会受输入法和焦点影响，尤其在中文输入法状态下，部分按键不会按预期到达 Tk。因此控制窗口额外使用 WH_KEYBOARD_LL 获取 Windows 提供的 VK、扫描码、扩展键标志以及 key down/up，并拦截 Alt、Windows 键，防止这些键先作用于教师机本地桌面。

但是，“Hook 日志出现”和“学生端收到有效键盘输入”之间仍有多层边界。当前只能确认：

text

本地物理按键
  -> WH_KEYBOARD_LL 捕获成功
  -> kind=16 的 28 字节包构造成功
  -> UDP sendto 成功
  -x-> 学生端解析/SendInput/目标应用收到字符：尚未稳定证明

可能影响学生端最终执行的因素包括：学生端所在 Windows Session、当前 input desktop、UAC 安全桌面、接收线程权限、学生端本地 Hook、扫描码/VK 组合、扩展键标志以及注入事件过滤。没有接收端 ACK 时，教师端日志不能跨越这些边界作结论。

十一、如何判断“真的成功”，而不是日志看起来成功

逆向远控最危险的误区是把 sendto() 返回成功当成远端执行成功。建议把证据拆成六级：

等级	证据	鼠标	键盘
A	教师端 UI/Hook 捕获事件	已验证	已验证
B	教师端构造并发送正确长度报文	已验证	已验证
C	抓包看到报文到达学生端	已验证	需持续复核
D	学生端接收器进入对应 kind 分支	已验证	尚缺稳定动态证据
E	学生端系统注入 API 成功	已验证实际效果	未稳定验证
F	目标桌面/应用收到输入	已验证	未稳定验证

如果要继续研究键盘，下一步不应继续盲改教师端字段，而应在授权测试机上对学生端接收分支做动态观测：

在 recvfrom 返回后记录 28 字节缓冲区；
确认 magic、kind 和 payload 分支；
在 SendInput 前检查构造出的 INPUT；
记录 SendInput 返回值和 GetLastError；
确认线程所属 Session 与当前 input desktop；
最后再观察目标窗口是否收到键盘消息。

只有走完这条链，才能判断问题究竟是协议字段错误，还是 Windows 输入隔离与 Hook 策略导致。

十二、几个真正耗时的坑

12.1 把 4806 与 feature 参数端口混为一谈

feature 参数里的教师端点不等于学生端 TCP 监听端口。包长和 IP 都正确时，这种错误特别难发现，因为学生端可能进入部分状态，却不产生正确桌面流。

12.2 按 recv 边界解析 TCP

本地网络里一次 recv 经常“刚好”是一包，导致错误解析器看似可用。一旦包被拆分或合并，就出现随机 magic、超大 length 和画面断流。TCP 必须按字节流处理。

12.3 把 16 字节 SPUC 当坏视频帧

早期解析器假设桌面记录至少 64 字节，日志中不断出现 total=16 的“非法帧”。保留这批原始数据并查看 magic 后，才发现它是独立光标记录。

12.4 在码流中途更换播放器

view 能显示、control 一切换就卡在“等待画面”，根因不是 MCMD，而是切换时重启了解码器。H.264 参数集已经在流开头发过，新解码器只能等待下一次可恢复点。

12.5 把颜色问题误判为 RGB/BGR

如果交换 R/B 后肤色和亮度仍不合理，应检查 YUV 平面。当前链路需要交换 U/V，而不是在最终 RGB 图像上交换红蓝通道。

12.6 本地指针、预测指针和远端指针混在一起

鼠标“不同步”不一定是包没生效。若本机系统指针可见，同时又绘制预测位置和 SPUC 位置，视觉上必然出现错位。隐藏本地指针并定义明确的预测回退窗口后，问题才可测量。

12.7 用错误的 COMD 边界调 MCMD

MCMD 是通用事务的 payload，不是 COMD 应用命令里的任意 cmdId。外层长度、GUID、事务字段或 payload offset 错一处，学生端通用分发器就可能走入完全不同的命令分支。调试时若出现与鼠标无关的窗口或系统提示，应先停止发送，重新核对事务边界，而不是继续猜键码。

十三、实现中的防崩溃与可观测性设计

协议能跑通不等于实现足够稳。当前版本加入了以下约束：

view_probe 只做 TCP connect 探测，不发送 feature 8 或 SHCO；
每个学生 IP 同时只允许一个 RemoteViewSession；
正式观看只进行一次 TCP 连接，不循环轰炸学生端；
连接/接收失败后发送停止 feature，并进入 60 秒冷却；
UMSP payload 和桌面 record 都有长度上限与越界检查；
未完成分片数量受限，重复字节不重复计数；
H.264 原始流按会话独立保存；
control 必须等待 TCP 会话 connected event；
MCMD 后等待接收线程初始化，再发送首个输入包；
远控可用 TEACHER_ENABLE_REMOTE_CONTROL=0 紧急禁用；
日志区分“捕获”“发包”“远端 SPUC 反馈”，避免把不同证据混成一句成功。

建议保留的关键日志字段：

text

[RemoteView] feature start / stop
[RemoteView] TCP connected, SHCO channel
[RemoteView] frame_seq / offset / total
[RemoteView] record magic / declared size / rect / frame type
[RemoteControl] MCMD mode / UDP endpoint
[RemoteControl] input count / kind / exact 28-byte hex
[RemoteControl] SPUC x / y / timestamp

日志必须限频。鼠标 move 可能达到每秒上百次，全量 INFO 不仅难读，还会反过来增加延迟；当前实现只详细记录前几包、关键按键和周期性样本。

十四、当前结论与下一步

连续投屏链路已经形成闭环：

text

IDA 定位 feature 8 和 UMSP
  -> 抓包确认 SHCO/TKPC/channel 10
  -> 重组桌面分片
  -> 识别 HHRF/HJRF/SPUC
  -> FFmpeg 解码、U/V 修正、visible rect 裁剪
  -> Pillow/Tk 内嵌交互窗口

远程鼠标也形成了从 MCMD 建立接收器到 28 字节输入包、学生端实际动作、SPUC 位置反馈的闭环。

键盘尚未闭环。当前研究最重要的结论不是“再换一个键码试试”，而是已经明确缺失的证据位于学生端接收分支到 Windows 输入桌面之间。下一阶段应优先补动态观测和返回值证据，再决定是否修改 kind=16 字段。

逆向协议真正有价值的部分，不是记住几个 magic 和 offset，而是把每个结论绑定到可重复的证据：反汇编交叉引用说明代码如何读，抓包说明线上如何写，日志说明我们的实现走到了哪一层，远端可见行为才说明功能最终生效。

这也是本项目在 README 中坚持区分“已验证”“可用”“部分验证”和“实验性”的原因。

附录 A：协议层级速查

text

MESS feature 8 (5512/UDP)
└── 617-byte remote-view payload

4806/TCP
└── UMSP
    ├── SHCO: select channel 10
    └── TKPC
        └── channel 10
            └── desktop fragment: seq + offset + total
                ├── HHRF: H.264 Annex-B
                ├── HJRF: JPEG
                ├── HMRF: legacy record
                └── SPUC: cursor position

COMD transaction (4705/UDP)
└── MCMD mode 0/1/2 + student input UDP port
    └── 28-byte input packet
        ├── kind=1: mouse
        └── kind=16: keyboard (experimental)

附录 B：运行命令

text

view_probe <ip>       # 只探测 4806/TCP
view <ip>             # 启动连续观看
control <ip>          # 在观看会话上启用远控
control_stop <ip>     # 停止输入模拟
view_stop <ip>        # 停止桌面流

请先执行 view_probe，并只在自己拥有管理权限或已获得明确授权的设备上测试。

我翻新了JiYu Trainer!!!部分重写一个停更五年的反电子教室软件 —— Dzjs Trainer v1.0.0

2026-10-05T17:51:43+08:00

我翻新了JiYu Trainer!!!部分重写一个停更五年的反电子教室软件 —— Dzjs Trainer v1.0.0

我是云散皆星河。这篇文章讲讲我怎么把快乐的梦鱼的 JiYuTrainer，从 SSDT Hook 时代搬进内核回调时代。

为什么接手这个项目

2019 年，快乐的梦鱼（imengyu）写了 JiYuTrainer——一个让极域电子教室全屏广播失效的工具。被老师全屏广播时自动转成窗口模式：自己能操作，老师演示也照看。项目开源在 GitHub 上，MIT 协议，从 2019 年 5 月维护到 2021 年。

然后他毕业了。2021 年 12 月 3 日，仓库归档，顶部一行字："已废弃。本项目将永远不再更新。"

我 fork 它的时候面对的现实是：原版驱动的核心是 SSDT Hook——直接改写系统服务描述符表。这在 x86 时代是经典操作，但 x64 系统的 PatchGuard（内核补丁保护） 会周期性校验内核关键结构，发现被篡改直接蓝屏。也就是说，原版的驱动方案在今天的 Win10/11 x64 上本身就是颗不定时炸弹。

所以这不是"fork 接着用"的事。要让它活在 2026 年的机房里，驱动层必须重写。

我联系了原作者，拿到了口头许可，在保留原项目贡献说明的基础上继续演进。这就是 Dzjs Trainer。

一、驱动：从 SSDT Hook 到内核回调

新驱动（JiYuTrainerDriver，x64 WDM）完全重写了。拦截能力不变，但实现全部换成操作系统官方提供的注册机制：

进程创建/退出通知——PsSetCreateProcessNotifyRoutineEx（Monitor.c）。驱动随时知道哪个进程起了、哪个进程退了。受保护的 PID 对应的进程退出时，自动调 KxUnProtectProcessWithPid 解除保护，不留悬空状态。

句柄拦截——ObRegisterCallbacks（Protection64.c）。注册进程/线程对象的 pre-operation 回调，在外部进程试图打开或复制受保护进程/线程句柄时，直接剥掉危险的访问权限。这是替代 SSDT Hook 的核心：不改系统表，只订阅系统事件，PatchGuard 无从下手。

保护目标绑定——JdrvProtectionSetTarget 通过 PsLookupProcessByProcessId 按 PID 绑定极域主进程，是用户态告诉驱动"保护谁"的入口。

IOCTL 通信协议

用户态和驱动的通道是经典的 DeviceIoControl，设备类型 0x8338，全部 METHOD_BUFFERED。IoCtl.h 里定义了 14 个控制码：

功能码	IOCTL	用途
0x800	`CTL_QUERY_VERSION`	查询驱动协议版本
0x801	`CTL_INITPARAM`	初始化参数
0x802	`CTL_INITSELFPROTECT`	开启驱动自保护
0x803	`CTL_KILL_PROCESS`	内核级杀进程
0x804/0x805	`CTL_SUSPEND_PROCESS` / `CTL_RESUME_PROCESS`	挂起/恢复进程
0x806/0x807	`CTL_SHUTDOWN` / `CTL_REBOOT`	关机/重启
0x808	`CTL_CLIENT_QUIT`	客户端退出通知
0x809	`CTL_UNINIT`	反初始化
0x80A	`CTL_READ_EVENTS`	读取内核事件队列
0x80B	`CTL_HEARTBEAT`	心跳保活
0x80C/0x80D	`CTL_DRIVER_GUARD_CONFIG` / `CTL_DRIVER_GUARD_QUERY`	驱动守卫配置/查询

主程序（DriverLoader.cpp）启动一个事件监控线程循环读 CTL_READ_EVENTS，把内核上报的事件搬回 UI；同时定时发 CTL_HEARTBEAT，校验协议版本——驱动和主程序任何一边失联，另一边都能立刻察觉，不会出现"驱动还在拦、程序已经死了"的半死状态。

卸载令牌：ECDSA P-256 签名

原版驱动装上去就下不来，这不是好设计。新版驱动卸载需要一枚签名的卸载令牌（UnloadToken64.c），流程是：

校验令牌结构：长度、size 字段、magic、version、action 字段，任何一项不符直接 STATUS_INVALID_PARAMETER
对令牌头部（到 signature 字段之前）计算 SHA-256（内核里用 BCryptHash，BCRYPT_SHA256_ALGORITHM）
用编译进驱动的 ECDSA P-256 公钥（UnlockPublicKey.h）做 BCryptVerifySignature 验签

密钥对由 tools\New-DriverUnlockKeys.ps1 生成，令牌由 tools\New-DriverUnlockToken.ps1 构造 payload、算 SHA-256、用私钥签名后输出 .unlock 文件。私钥永不入库——仓库里只有一个 JiYuTrainerDriver.unlock.enc.sample 占位。也就是说，公开构建的驱动能装能跑，但只有持有私钥的发布者能生成合法的卸载令牌。这是"谁发布、谁负责"的信任链。

二、Hook 模块：战场在 StudentMain 进程内

JiYuTrainerHooks.dll 是注入进极域学生端（StudentMain.exe，也支持 MasterHelper.exe）的 DLL，用 mhook 做 inline hook。主程序（TrainerWorker.cpp）定时刷新进程列表，定位到目标进程后注入，然后走心跳/控制握手。DLL 里还挂了一个 WH_CBT 钩子盯着窗口事件。

hook 的 API 面覆盖了极域的全部控制手段：

窗口控制类：SetWindowPos、MoveWindow、DeferWindowPos、SetWindowLongA/W、ShowWindow、SetForegroundWindow、BringWindowToTop——全屏广播转窗口、窗口置顶、黑屏安静的对抗都在这一层
输入类：SendInput、mouse_event、SetWindowsHookExA——防键盘鼠标锁定
执行类：CreateProcessA/W、WinExec、ShellExecuteW/ExW、ExitWindowsEx——拦截教师端远程下发的命令，用户可以逐条选择放行还是拒绝
通信类：DeviceIoControl、CreateFileA/W、FilterConnectCommunicationPort——监控极域自有驱动的通信
显示类：ChangeDisplaySettingsW、DwmEnableComposition、GetDesktopWindow、GetWindowDC、CreateDCW、BitBlt

反监视：三层屏幕捕获对抗

这是整个项目里我花时间最多的部分。极域的"打开看"（教师端实时监视学生屏幕）有好几条捕获路径，得逐条堵：

路径一：DispFilter.dll 的 DXGI 捕获。 用 IDA 逆向确认它只按序号导出：ordinal 1 是 DispDXGIBitBlt（真正读桌面像素），ordinal 4 是 DispDXGIGetScreenUpdate（只取脏矩形，结构体大小 0xC84、200 个 RECT）。DispDXGIBitBlt 把 DXGI 桌面帧按 RGBA 逐行 memcpy 进调用方缓冲——我的钩子在原始函数返回后，把整块像素填成不透明黑（B=G=R=0, A=0xFF），教师端看到的就是纯黑一片。

还有一个首帧空窗问题：StudentMain 是通过 LibDeskMonitor::TDDeskCreateInstance → libTDDesk2 在"打开看"开始时才 LoadLibraryW("DispFilter.dll") 动态加载它的。所以我同时钩了 LoadLibraryW/LoadLibraryExW——DispFilter 一被加载，捕获钩立即装上，不留空窗。

路径二：LibDeskMonitor.dll 的 GDI 抓屏。 它静态导入 BitBlt/StretchBlt，把源窗口 DC 拷进内存位图。之前试过钩 GetDesktopWindow/GetWindowDC 拦不住——它的源 DC 是 MFC CWnd::GetDC 直接拿的，不走这几个 API。解法是直接改写 LibDeskMonitor 自身的 IAT：钩住它内部的 BitBlt/StretchBlt，捕获完成后用 PatBlt(BLACKNESS) 把目标内存位图刷黑。还有一个细节：libTDDesk2 要等最终 GdiFlush 之后才提交捕获位图，所以我用 thread_local 记录同线程最近一次捕获的目标 DC，等原始 flush 返回后再覆盖整张持久位图——刷早了会被真实画面盖回去。

路径三：JPEG 编码流。 极域用 LibJPEG20 的 EncodeToJPEGBuffer（及 I422 变体）把帧编码后发走。这里我做了三层钩：函数实现体 inline hook + 多模块 IAT patch + GetProcAddress 拦截——因为它按序号导出、且被多个模块以不同方式引用，单层钩总会漏。卸载时逐个还原 IAT 槽位。

信息流保护：不只是涂黑

反监视之外，v1.0.0 还加了"替换"能力——教师端看到的不是黑屏，而是你指定的图片或视频：

图片路径：RGB24 缓存 + 顶向下 BGR24 DIB 双份像素，StretchDIBits 直接画
视频路径（MP4/WMV）：独立 Media Foundation 线程解码，捕获热路径只读已发布的当前帧，不做文件 I/O 不做解码——捕获是高频路径，这里卡一下教师端就掉帧了
并发安全：临界区 + 引用计数管理共享 DC 和像素缓冲，"正在使用的 DC 不会被删除"，旧缓冲进 pending 列表等引用归零再释放

三、发布链路：把"信任"做成流程

代码写完只是一半，另一半是让用户能验证拿到手的二进制没被掉包。

tools\Build-JiYuTrainerRelease.ps1 串起整个发布流程：

MSBuild 重编 x64 驱动
signtool sign /sha1 <指纹> /fd SHA256 /tr <时间戳服务器> 对驱动签名（含 RFC3161 时间戳）
Get-AuthenticodeSignature 验证签名，提取证书 Subject 和 SHA-1 指纹
关键一步：把签名者 Subject 和指纹写进 JiYuTrainer\DriverSignerPin.h，编译进主程序——主程序加载驱动前会校验驱动签名者是不是发布者本人，防偷换
调 Complete-DriverSigning.ps1：Inf2Cat 生成 catalog，再对 catalog 做 SHA-256 签名

也就是说：驱动签名 → 签名者指纹固化进主程序 → 主程序运行时校验 → catalog 二次签名。四道锁，任何一环被替换，整条链路报警。

四、周边工具箱

翻新过程中沉淀下来一批独立小工具，都在仓库里：

GuardTerminator：对付设了 ProcessBreakOnTermination（进程信息类 29）保护进程的终结工具，测试驱动自保护时用来模拟"敌人"
JiYuAvKernel / JiYuAvCtl / JiYuAvShared：辅助驱动与控制端（Driver.c/Controller.c/Scanner.c），配套 Build-JiYuAv.ps1 和独立签名脚本，做模式扫描一类的事
SlayerAnalyzer / PhoneDialogProbe / ExitInputSimulator：逆向分析和场景模拟用的小工具
DriverPublisherTests / JiYuAvPatternTests：发布链路和模式匹配的测试工程

五、诚实的支持范围

类型	状态
极域电子教室	持续维护
机房管理助手	已提供适配基础
Gakataka	计划中
红蜘蛛	计划中

Hook 模块里保留了 jiYuVersions40 / 2016HH 的版本适配逻辑。但我不想虚标——计划中就是计划中，每个版本的内脏（DLL 名、导出序号、窗口类）都不一样，没实测过的平台绝不说"支持"。

写在最后

原版 README 结尾，梦鱼说："如果您有其他功能需求，可以 fork 项目之后自己研究开发。"

我就是那个 fork 的人。五年后，SSDT Hook 换成了内核回调，裸驱动换成了带 ECDSA 卸载令牌和签名者锁定的发布链路，单一黑屏对抗换成了三层捕获钩加视频流替换。项目以 MIT 协议继续开源：

GitHub：https://github.com/yunsjxh/Dzjs-Trainer
官网：https://dzjstrainer.xn--9kq396ceqaq4si9m.cn/
感谢 JiYuTrainer 原作者快乐的梦鱼；第三方组件 curl、mhook、MemoryModule、XZip/XUnZip、dnlib 各自遵循其许可证

最后照例强调：请仅在你拥有、管理或获得明确授权的设备与网络中使用本项目。先在隔离测试环境验证，再做经授权的部署。工具没有立场，边界由使用者决定。

欢迎 Issue，欢迎 PR。加个星星⭐就更好了。

闲来无事,逆向一个银狐病毒

2026-10-05T17:21:57+08:00

闲来无事,逆向一个银狐病毒

样本：chat-deepseek.exe，2,085,620 字节，x64，无签名。样本下载在最后面。

SHA256 68ae0cabadce8467534f8a41e9ca139b4b9a066aa20d154254793bb4eb9a6b17

分两段：先在宿主机上纯静态把文件拆开（这段没运行样本的任何代码），确认它会做什么之后，再放进隔离虚拟机里跑，抓运行态证据——包括所有走错的路。

先别急着扔 IDA：把"没反应"拆成能验证的问题

拿到文件时唯一的线索是一句很含糊的话："看着像仿冒 DeepSeek 的东西，但双击之后什么都没有。"

"什么都没有"是最没用的一句话。它至少指四种完全不同的情况：进程没被创建、起来了但秒退、活着但什么都不做、在跑但被什么东西拦住了。四种的排查方向完全相反。所以第一步不是打开 IDA，而是把它翻译成几个可测量的量：

待测量	怎么测	后来的答案
进程有没有被创建、活了多久	Process Monitor 的 Create → Exit 时间	创建了，但亚秒级退出
有没有落文件	看约定路径下有没有产物	没落任何文件（连日志都没有）
有没有出网	`netstat`、DNS 缓存	没有
退出方式	正常 `ret`（退出码 0、无崩溃报告）还是异常崩溃（有 WER 日志）	干净的 ret

最后一行是关键。崩溃退出的话方向会是"找 bug、找兼容性"；而它是自己决定不干、正常返回——直接指向"内部有个判断把它拦下来了"。后面所有"推翻重来"，本质都是某条测量结果和判断对不上。

它到底有没有壳：不要看节名，要看三件事

第一次打开 PE，节表长这样：

.boot      vsize=0x592    entropy=6.00      ← 节名像 Armadillo 的引导节
.text      vsize=0x19BB0  entropy=6.44
.pkcfg     vsize=0xA0     entropy=0.22      ← 魔数 ARMPKCFG
.rdata     vsize=0x1C0000 chars=0xE0000040  (RWX, 1.75MB)
.fptable   vsize=0x100    entropy=0

.boot、.pkcfg、.fptable 是 Armadillo / SoftwarePassport 的招牌节名，加上 ARMPKCFG 魔数，很容易一眼就下"这是商业壳"。但我吃过看节名判壳的亏，所以定了三条更硬的判据：熵、导入表能不能正常解析、函数的序言模式。节名可以伪造，这三样不行。

结果第一条就出人意料：三个内嵌模块反而是明文。.text 熵 6.44（正常 MSVC 代码水平），导入目录解析出 13 个 DLL / 293 个函数全部正常，RTTI 完整可读 35 个类名，跳转表 100 项目标全落在 .text 内没损坏。我最初"主控被加壳"的悬念就此关掉——代码就在那儿，全都能读。

同样，我对 stub.exe 也误判过一次"加壳"：解析节表时把 VirtualSize 当成了 VirtualAddress（字段顺序读反），导致 RVA→偏移错位、导入表解析落到全零区。改过来后：导入目录 rva=0x206ac size=80 正常，.text 熵 6.471，头部 48 8b c4 48 89 58 08 是标准 MSVC x64 序言——明文，没壳。这提醒我：工具给你一个输出，不代表那个输出是对的。

找字符串消费点，我在这里踩了一个坑

接下来要定位 \deputies.bin 这个串在代码里被谁用。我先用最直观的办法：从函数起点线性反汇编整个 .text，扫所有 RIP 相对引用。扫出来是——零引用。

一个明明存在于 .rdata 里的字符串，居然没有任何代码引用？我回头查反汇编输出，发现从 0x2630C 往后指令流整体"错位"了。0x2630C 是一张跳转表（switch 分派表），里面是纯数据；线性反汇编器把表里的数据当指令解析，从那里开始一路错到段尾——后面所有引用自然全扫不到。

改法是不再相信反汇编器，改字节级暴力扫描：逐字节匹配 48/4C 8D|8B + ModRM(mod=00 rm=101) + disp32，target = rva + 7 + disp；call [rip+disp32] 匹配 FF 15。同一字符串立刻扫出 30 多处引用。这条教训进了我的固定流程：先在字节层确认引用，再看反汇编——反汇编是解释，字节才是事实。

用已知明文抠出密钥

最关键的转折点，是发现它其实是个"壳 + 加密载荷"的封装结构。

第二个 .rdata（1.75MB，权限 RWX，chars=0xE0000040 展开就是 MEM_READ|MEM_WRITE|MEM_EXECUTE）最可疑——可写又可执行，典型的"运行时解密落地区"。我按它的文件偏移整段读出来异或，在段内偏移 0x4000D 处解出了一个合法 PE32+：ImageBase 0x180000000，入口 0x526F0，821,760 字节。密钥是 8 个字节：5A 3C 91 E7 2B 64 D8 0F。

我不是"猜到"的。定位方式是找到解密循环本身——sub_1400023D4 里 mov al,[rax+r8+0x1c550] / xor [rdx+r8+0x29000],al，密钥表就摆在 .rdata 的 0x1C550，逐字节读出来即可。能读到循环，就不需要猜。

同一把密钥顺手把 .data 0x29000 起的一片数据解成了完整的编译期配置串——这张表后来比密钥本身有用得多。

它到底能干什么：从导出表和 RTTI 反推作者思路

解出来的 login.dll 只有 821KB，导出表只有 7 个函数，每个都很有信息量：

ArmouryCapHelperW              armoury_beacon_start
ArmouryUCapHostW               armoury_beacon_stop
Main                           armoury_beacon_on_packet
armoury_beacon_on_conn_closed

这是恶意代码自己报出的名字，和后面磁盘上的 ArmouryLogin.log、ArmouryStager.log、Roaming\Armoury 目录完全互证。beacon 说明它是信标型 C2（被动上线、心跳、回调驱动），而 on_conn_closed 尤其关键——它意味着"连接断开"是预期内的常态事件，后来直接解释了日志里的"故障转移阶梯"：那不是异常，是设计。

RTTI 里有 armoury::transport::ITransport（抽象基类）和 TcpTransport（实现），配合 std::function + shared_ptr——这是面向接口的现代 C++17 框架，不是 Gh0st 那种老式 C++。这个判断决定了后面归因不能乱套家族。

Main 那几个参数（host / port / proto / mark）的顺序我也没靠猜，而是从日志格式串反推：Main enter proto=%d port=%u host=%s mark=%s——格式串里的占位符顺序就是实参排布顺序。用"日志长什么样"反推"函数签名是什么"，是这时最省力的一招。

命令表：100 个槽位怎么逐个定性

armoury_beacon_on_packet 是命令总入口：取 packet[0]，判两个前置值，其余走跳转表——TBL @ 0x2630C（100×u32）+ IDX @ 0x26348（100×u8），索引 = cmd - 0x88。

解表不难，难的是给每个命令定性。我用的方法不是读一遍逻辑，而是"把调用链上的 API 按顺序排出来"——API 的调用顺序几乎自带语义。最典型的一次纠错是 0xC8：一开始我看到包里有两个数值（默认 120 / 68），加上"参数设置"的联想，判成了"运行参数设置"。后来把它整条链的 API 排出来：

GetDC → GetSystemMetrics×2 → CreateCompatibleDC → CreateCompatibleBitmap →
SelectObject → SetStretchBltMode → StretchBlt → GetDIBits → 清理

这是教科书级的截屏序列。而且 120×68 和上限 640×360 都是 16:9——两个数字都是图像尺寸，不是时间间隔。于是 0xC8 从"参数设置"改成"按需截图，服务端可指定分辨率"。

另一个硬结论是报文格式：[0]=命令字节、[1..16]=16 字节 payload、后面跟几个定长字段，最小长度 0x1B。协议头第 1 字节就是命令号——这条是从机器码里 cmp byte[rcx],0x88 这种硬编码比较直接读出来的，没有推断成分。

它在我机器上留下了什么：靠"静态串 ↔ 落盘名"对上号

接下来想知道它靠什么活着、重启后怎么回来。这段的推法不一样——不是从代码推行为，而是拿静态里解出的配置串，去运行态产物里找对应物。那张编译期配置表里有一批长得像 ID 的串（ARMAUTO1、ARMVMS1、ARMUAC0、ARMGRD1、ARMGID833B463E、ARMGN10、ARMPRS01、ARMPIDA30BAE5E、ARMSIDA30BAE5E、ARMOBF1、ARMSELP1、ARMSCMAP）。

当时它们只是一堆常量名。等我把运行态的注册表和计划任务拉出来，对上了：

静态配置串	运行态对应物
`ARMGID833B463E`	Run 键 `G-833B463E` → `…\Microsoft\833B463E\LeafChatHost.exe --arm-boot`
`ARMPIDA30BAE5E`	计划任务 `\P-A30BAE5E` → `stub.exe --arm-payload "…payload.bin"`
`ARMS1-%s-%lu`	互斥标记文件 `ARMS1-y0YUmsuGTDqIgQTb-1`
其中的 `A30BAE5E`	释放目录 `%LOCALAPPDATA%\Microsoft\A30BAE5E\`

这是整段分析里最舒服的一次——静态和动态第一次严丝合缝扣上。 一个本来只是"常量"的字符串，突然告诉你它就是那几个持久化机制的名字，等于凭空拿到了一份作者的设计图。计划任务的 XML 也让规律更清楚：CalendarTrigger + Repetition PT1H（每小时重注入一次）、Hidden=true、StartBoundary 是落盘后 120 秒内的时间戳——它落地不到两分钟就把持久化做完了。

还有个细节值得单说：守护器文件名是 LeafChatHost.exe，我差点把它当 IOC 写进报告。后来在投递器里翻到一张12 个名字的池子：

QuickNoteHelper  PhotoGlanceHost  SkySyncHost   PlayLiteHelper
DeskCalcHost     FileNestHelper   GuardPulseHost TunePadHelper
SnapCamHost      PageMarkHelper   LeafChatHost   PrefPanelHost

运行时随机挑一个当文件名，我拿这 12 个名字去公开情报里批量检索，零命中。所以正确写法是：文件名不是 IOC（LeafChatHost.exe 只是这次抽到的），能当锚点的是路径形态（%LOCALAPPDATA%\Microsoft\<8位十六进制>\*.exe）和命令行参数（--arm-grd / --arm-src / --arm-boot / --arm-payload）。图省事把文件名当特征，检测规则下个月就失效。

顺带一提，守它们的目录里有个 target.path，90 字节。我一开始不知道它是什么，直到发现 90 = 44 个字符 × 2（UTF-16）+ 2 字节 BOM——按 UTF-16LE 读出来，正好是那个桌面样本的完整路径。算术先对上了，语义才敢下结论。

它是怎么把自己塞进内存的

stub.exe 我只说了它是"进程镂空投递器"，做法值得展开，因为它解释了"为什么杀进程没用"。定性还是排 API 序列：

NtAllocateVirtualMemory   NtWriteVirtualMemory   NtGetContextThread
NtSetContextThread        NtResumeThread         NtClose

再配上 CreateProcessW 和一个字符串 e%s\notepad.exe——顺序连起来就是完整的 RunPE（傀儡进程）链：

CreateProcessW(notepad.exe, CREATE_SUSPENDED)  ← 宿主挂起
  → NtAllocateVirtualMemory( RWX, size = payload + 0x20000 )
  → NtWriteVirtualMemory → NtSetContextThread( 改入口点 )
  → NtResumeThread    ← 跑起来的是 notepad，内容是载荷

为什么不直接 CreateThread？ 因为镂空之后，进程在任务管理器里显示的是 notepad.exe，模块列表里没有可疑 DLL，磁盘上也没有可执行文件——查杀软件按"可疑进程名 / 可疑模块"去匹配，什么都找不到。

配套看那个被写进去的 payload.bin（39,541 字节）：它不是 PE，没有 MZ 头，是一段纯 x64 位置无关 shellcode——入口三条指令 sub rsp,0x38 → 在栈上拼出 "boot" → lea rcx,[rsp+0x20] → call，也就是说它自己会去找并加载 a64.dll。"投递器不落地可执行文件、载荷也不是 PE"——这条链上每一步都在躲静态特征。

a64.dll 里还藏着一整套"无文件"工具链

真正联网的只有 a64.dll。这一点是从导入表反过来确认的：stub.exe（3 个 DLL / 95 函数）与守护器（2 个 DLL / 97 函数）都不导入 WS2_32 / WININET / WINHTTP 中的任何一个；只有 a64.dll 是 16 个 DLL / 301 个函数，网络、截屏、令牌、设备枚举一应俱全。"守护器和投递器不联网"是设计，不是被断网了。

然后我在 a64.dll 字符串里翻到一段很扎眼的东西——powershell.exe … -ExecutionPolicy Bypass -WindowStyle Hidden -EncodedCommand，紧接着一段 Base64，解码后是内联 C# 代码。四段脚本：① 单次截屏；② 连续截屏，超 1600×900 等比缩小、先写 .tmp 再原子 Copy，200 ms/帧（5 fps）；③ 内联类 ArmFg 取前台窗口标题 + 空闲秒数，每 500 ms 写 arm_fg_%u.txt；④ 内联类 ArmWinQ 导出全部窗口信息到 arm_winq_%u_%u.txt。

为什么用 PowerShell 而不是写 C++？ 因为脚本是 -EncodedCommand 传进去的，命令行里只有一串 Base64，磁盘上不留 .ps1，进程树里也看不到脚本内容。5 fps 连续截屏 + 每 500 ms 一次前台窗口/空闲采样，合起来就是"他在看什么、有没有在操作"——社工诈骗最需要的情报。

还有一条业务线索，藏在同目录的 FILTER 文件里（2,940 字节，UTF-16），是一张两列对照表：

signal → SL      telegram → TG      safeW → SW      WhatsApp → WA

一份即时通讯软件的监控/劫持名单。 结合前面的浏览器扩展注入串 ArmouryIntercept 和 Chrome / Edge / Brave 的扩展目录路径，变现路径就清楚了：盯着 IM，找机会冒充本人去骗联系人——技术分析到这里，第一次看到"它图什么"。

C2 到底在哪：先排除，再下结论

到这时我已有完整的代码骨架，却始终没找到最该有的东西——C2 地址。先假设它写得比较直接，做了七轮搜索，每轮换一种"藏法"：

通道	我假设它藏成什么样	结果
明文直搜 `macio`、IP 的 8 种编码（原样/反转/UTF-16/十六进制/点分十进制）	明文或编过码	0 命中
重复密钥 XOR 的 crib-drag（6 crib × 周期 1–32 × 全文件每偏移）	被 XOR 加密	唯一"命中"解出 `mmmm…` 噪声 → 假阳性
单字节加法/减法混淆、单字节 XOR（各全 255 密钥）	简单混淆	0 命中
`a64.dll` 高熵区 / 版本资源 / 构建配置表	小段密文 / 写在资源里	全是查表数据，无相关字段

七轮全空之后，反而不该继续硬搜，而是回头看代码里那些"看起来在配置网络"的地方。a64.dll 里有一段协议配置块——"ARPLWire"、"/arpl/ws"、"AFR2"、"ArmouryFrameV2-AUTH"、"ArmouryFrameV2-ENC"，以及一句日志格式串：Main enter proto=%d port=%u host=%s mark=%s。

host 是 Main 的入参。 也就是说，这个样本从设计上就不带 C2——它等着外面的人把地址递进来（通过 deputies.bin 配置、或 armoury_beacon_start 的入参结构体）。这也解释了为什么"下载/更新"通道一直在报 pullfail：它在拿到配置之前，本来就无事可做。

所以"没见过的东西"和"不存在的东西"要分开。45.64.52.179 是存在的，只是不在文件里——它是从外部投递进来的。这条"排除得出外置"的结论，正好把注意力推向文件里唯一一块还没打开的地方：末尾那 50,932 字节。

"为什么没反应"——我推翻了四次

第一次。 我在静态里全量核对了经典反 VM 手法：GetSystemFirmwareTable、GlobalMemoryStatus、IsDebuggerPresent、CPUID hypervisor leaf、各种 MAC OUI……全部 0 命中。那些 VMware / VirtualBox / WireGuard 字符串我也追到了消费点，发现它们是网卡打分器的扣分项（给虚拟网卡扣 90 分，满分 120），只影响排序，没有任何退出/自杀逻辑。于是第一版结论是：没有反 VM，只有 5 个"静默闸门"，最可能是环境变量 ARMOURY_ENABLE_TRANSPORT_LAYER 没设。

第二次（被实测打脸）。 实测结果是 C:\Windows\Temp\ArmouryLogin.log 根本不生成——第一版说的"传输层/C2 问题"完全错了。重查发现两件事：一是程序真的起来了，跑到 sub_2010 尾部是一个 Sleep(0x36EE80) = 1 小时的死循环；二是 login.dll::Main 要求 5 个非空参数（前置 test rdx,rdx / test r8,r8 / … 任一为空就 je 直接返回），双击时宿主传参不满足，所以"写日志"那行从来没被执行过。这版结论：它不是"能双击跑的完整木马"，而是需要特定 loader / 参数才"活"的组件。

第三次（我把样本真的跑起来，推翻了第二版）。 我在 VMware 里跑，亚秒级静默退出，任务管理器都看不见。重查启动链，在 sub_2010 前 0x60 字节里找到了真正的卡点：

asm

0x2047  cmp  byte[0x29016], '1'    ; 配置开关 ARMVMS
0x2050  call sub_54A8              ; ★ 反 VM/沙箱 多因子打分
0x2057  jne  0x2062                ; al==1 → 落进退出块
0x2062  xor  eax,eax
0x2064  jmp  0x2359                ; ← 直接返回

sub_54A8 是打分子函数。在 VMware 里，注册表键 SOFTWARE\VMware, Inc.\VMware Tools 和进程 vmtoolsd.exe 必然命中，得分达阈值就直接返回 1 → 静默 ret 退出。"任务管理器看不到进程、日志不生成、无网络、无持久化"——现象全部吻合。

第四次（反汇编精化）。 我把 sub_54A8 逐条拆开，发现之前的"4 个因子"理解错了：那几个传进去的 10 / 9 / 10 / 7 是数组长度，不是权重——真实规模是 8 路检测、其中 4 路是数组、共 36 个检查项。同时发现"第二道门"sub_4ADC 开头 cmp byte[0x2901E],'1'（配置 ARMUAC0，实测 '0'），条件不成立就直接走到"放行"出口，它天然放行。结论：唯一的阻断点就是那个打分器。

定案（单字节差分）。 最后我用桌面上另一个版本的样本做差分——两个文件只差 1 个字节：

文件偏移 0x27616    原始样本 0xE9  →  变体 0xE8
用同一把密钥解出：   ARMVMS1        →  ARMVMS0

一个字节，虚拟机检测开关就关掉了——这也证明那张编译期配置表不是"清单"，而是运行时读取的功能开关板。

这四次推翻里我做对的只有一件事：每轮结论都写清楚"怎么证伪"——所以每被推翻一次，下一次的起点都更靠后、更精确。

顺手一提，打补丁还有个坑。两道 jne 的极性是相反的：

asm

0x2057  jne 0x2062   ; al==1 → 跳到退出块      → 这一道可以 NOP
0x2060  jne 0x2069   ; al==1 → 跳到继续分支    → 这一道 NOP 就完蛋

第二道是"通过才跳转"，如果我按第一道的思路把它也 NOP 掉，控制流会顺序落进退出块，反而保证退出；正确做法是改成无条件跳转（75 07 → EB 07，只动一个字节）。这种"看起来对称、实际方向相反"的地方，是补丁最容易翻车的位置。

去 VM 里抓 C2：先学会不把噪声当证据

绕过了反 VM、样本在 VM 里上线之后，接下来是拿到它到底连谁。netstat -an 出来一串 ESTABLISHED。如果直接按 IP 排序，175.12.122.167 会排在头号嫌疑——175.0.0.0/8 是中国段，看着最可疑。但我坚持做了一步"逐 PID 映射进程名"：

PID	进程	对端
8140	chat-deepseek.switch.exe	45.64.52.179:443
9380	chat-deepseek.switch.exe	45.64.52.179:443
7428	SearchApp.exe	175.12.122.167:443
6892	WinStore.App.exe	23.199.2.97:443

那个"头号嫌疑"其实是 Windows 搜索索引器。而 45.64.52.179 独占两条连接，两条都来自样本自身。铁律一条：不映射到进程名的 IP 排序，全是噪声。

有了 IP 还要拿域名。查 DNS 缓存时又踩了一个坑：ipconfig /displaydns 里 findstr "Record Name" 零命中，我一度以为"DNS 缓存是空的"。真相是——中文 Windows 的表头是「记录名称」，不是英文。改成 Get-DnsClientCache 按 IP 反查（语言无关），立刻拿到：

Entry : jd.macio-china.com
Data  : 45.64.52.179

C2 = jd.macio-china.com → 45.64.52.179:443。

顺手验证了一件事：两个进程 PPID 相同、命令行相同 → 是兄弟进程而非父子派生（排除了"loader 注入子体"的常规模型）；域名归属放到最后归因一节。

日志把我静态里下的协议判断推翻了

拿到 C2 之后，我一度很有把握地判定协议是 WSS（WebSocket over TLS）：内存里挖到了 RFC6455 的魔数 GUID 258EAFA5-E914-47DA-95CA-C5AB0DC85B11，还有 Sec-WebSocket-Key、Upgrade: websocket，以及 websocket.dll 和 SChannel 相关串。看起来板上钉钉。然后 VM 里取到了两份明文日志（ArmouryLogin.log / ArmouryStager.log）：

dial host=jd.macio-china.com port=443 proto=0 tmo=12000
dial OK port=443 tcp via=direct

三个字把上面的判断推翻了：

proto=0 —— 全程固定为 0。真走 WS/TLS 会是 1/2/3。
tcp via=direct —— 拨号层明确报的是 tcp，不是 tls、不是 ws。
dial OK 到 send_login 之间没有握手步骤，全程 203ms，没有 TLS 往返开销。

再加一个反证：我早先用裸 IP 去做 TLS 握手，对端直接断开——现在解释通了，因为那上面根本不是 TLS 服务。

最终定性：443 端口上跑的是裸 TCP + 自研 ARPLWire 帧 + 自研加密（ArmouryFrameV2-AUTH / ArmouryFrameV2-ENC 两阶段帧，魔数 AFR2）。WS / SChannel 的代码编译在内但默认关闭——这正是 transport_disabled 的含义。防御意义很大：443 上没有 TLS，基于 JA3 / 证书的检测手段全部失效；选 443 就是为了混进 HTTPS 流量，又不吃 TLS 检测。日志还顺手给了故障转移阶梯：

443 (tmo=12000) 失败 → 80 (tmo=5000) 失败 → backoff=200 → 回 443

所以封禁时 443 和 80 要一起拦，只封 443 它会掉到 80。

破解打包器：从一把小钥匙到全域密钥律

线索来自磁盘：样本跑起来后在磁盘上落了三个文件——a64.dll（821,760 B）、a64u.dll（与 a64.dll 同 SHA256，说明更新槽没被写入），以及同样大小但头部是 7D 6A（不是 4D 5A）的 a64。同尺寸 + 明文可得 ⇒ 直接算密钥流：keystream = a64 XOR a64.dll。手工核算前几行：

a64.dll:  4D 5A 90 00 03 00 00 00 04 00 00 00  | FF FF 00 00 B8 00 …
a64    :  7D 6A F0 89 86 9D A3 A5 73 84 74 30  | 9F 76 85 9D 1B A5 …
XOR    :  30 30 60 89 85 9D A3 A5 77 84 74 30  | 60 89 85 9D A3 A5 …
                              └──── 周期 10 ────┘

从偏移 2 起出现周期 10 的重复。这是已知明文攻击，不需要知道任何算法。

回到投递器本体。第二个 .rdata（那 1.75MB RWX 节）我按 256KB / 1MB / 256KB / 256KB 切成四个槽，逐个看占用长度：

槽	节内偏移	实际占用	减去 13 后
1	`0x040000`	821,773	821,760 ← a64.dll
2	`0x140000`	168,461	168,448 ← 守护器
3	`0x180000`	144,397	144,384 ← stub

三个槽"多出来的部分"都精确等于 13 字节。围绕这 13 字节，我纠正了自己两次：

第一，它不是二进制结构，是 NUL 结尾的 ASCII 角色标签。 我一开始当成"长度/校验字段"穷举，一无所获；换成用同一把密钥直接解这 13 字节，得到可读英文：

槽1 → loginpattern\0     （a64.dll，C2 主体）
槽2 → guardpattern\0     （守护器）
槽3 → stubpattern\0+     （进程镂空注入器）

.text 里还有独立的交叉引用可以证实：0x626A–0x629A 逐字节比对槽 2 的首地址和 'g','u','a','r','d','p'，0x62DE–0x630E 比对槽 3 和 's','t','u','b','p','a'。加载函数在 +13 处取址——和标签长度完全吻合。

第二，"每个模块一套密钥"是错的，真相是一把钥匙统治整个文件。 我原以为三个模块各自从相位 0 开始异或，推广验证后的规律是：

plain[file_off] = cipher[file_off] ^ KEY8[ (file_off + 3) mod 8 ]
KEY8 = 64 D8 0F 5A 3C 91 E7 2B

之所以会看成"每模块相位 0"，是因为三个模块的 raw 起点 0x6A000 / 0x16A000 / 0x1AA000 刚好都 ≡ 0 (mod 8)，偏移量恰好被吸收成了相位 3。最强旁证是：这条规律在完全不同的节（.data 配置表，偏移 0x27600）上也成立——同一把密钥解出 8 条语义完整的配置串。这不可能是巧合。

最后是第四份载荷。那个 256KB 的槽 0 我一开始当成"稀疏工作区"跳过（每 4096 字节只有 ~617 个非零字节）。直到把"非零字节总数"算出来：39,464——和 payload.bin 明文的 39,541 只差 77。追下去发现它就是用另一把独立密钥（2C 30 FE F5 74 5F EA 42 A4 23 EE 49 6A 82 96 73，16 字节）加密的 payload.bin，布局是 64 段 × 618 字节、步长 4043、首段起点 3425，有效载荷率只有 15.1%。

这里我踩过一次陷阱：一开始用"过滤掉所有零字节"的办法还原，得到 39,464 字节——错了。因为密文里有 77 个字节恰好等于 0x00，和间隙的填充零在视觉上无法区分，会被一起滤掉；必须按段几何（固定起点 + 固定长度）重建。改过来后，重建结果与原始槽 0 逐字节相同，SHA256 精确等于 VM 侧那份 payload.bin。把 39KB shellcode 切成 64 段散布在 256KB 里，意图很明显：让文件里不存在任何 ≥618 字节的连续 shellcode 片段，废掉字节序列特征码。

overlay：解不开的时候，把边界划清楚也是结论

前面"C2 外置"那段把注意力推到了最后一块没打开的地方：文件末尾有 50,932 字节不属于任何节（算法：文件总长减去最后一个节的结束偏移，算术自证）。它前 8 个字节是标准 PNG 签名 89 50 4E 47 0D 0A 1A 0A——看起来像图片。但它第 9 个字节起就破坏了 PNG 结构：规范要求紧接着是 00 00 00 0D + IHDR，实测完全不符；解析 chunk 长度得到 len=321167813（非法），没有 IHDR 也没有 IEND。所以那 8 字节只是明写的诱饵魔数。

接下来大量排除，一共试了 11 条路径：

攻击	结果
单字节 XOR / 周期 1–16 重复密钥 XOR（用已知 IHDR 反推）	密钥互不一致；或解出的 comp/filter/interlace 非 0 → 排除
IoC 逐周期扫（p 到 1024）+ ECB 重复 16 字节块	全落在随机基线；3,183 块重复 0
zlib/gzip/bz2/lzma（off 0–23）、RC4 × 46 密钥、复刻多态引擎、模块密钥 8 相位、K16 全 16 相位	全失败；K16 解完熵仍 7.99645

统计量给出了终局答案：

body = 50,924 B（去掉 8 字节魔数）
entropy = 7.99636   真随机期望 = 7.99639      ← 差 3×10⁻⁵
chi²    = 256.0  (df=255, 临界值 293 @p=0.05)  ← 教科书级均匀

它统计上不可区分于真随机。 到这里我没有假装把它解开，而是给了一个有边界的结论：它要么是强加密（密钥运行时派生），要么就是纯随机填充——后者的话，那 8 字节 PNG 魔数就是纯粹的诱饵。我倾向"随机填充"：这个 builder 在所有已知的加密环节都只用弱 XOR，overlay 如果真是关键配置，没理由独独升级密码强度；而且全文检索不到任何引用 50932 / 0x1F0C00 这个尺寸的代码。但在拿到第二份同源样本做差分之前，我不把这条写成结论。

这段看着像"没做完"，其实是我最有把握写进报告的部分之一：知道自己卡在哪条边界上、并能证明这条边界在哪，比给一个含糊的"应该是加密配置吧"有价值得多。

归因：基础设施能定，代码血统不能硬套

归因我拆成两层，用完全不同的证据标准。

基础设施层：证据很硬。 C2 域名注册商是 Gname.com（IANA 1923，长期位居恶意域名注册量榜首）；域名注册于 2026-06-07、只有 4 个月；macio-china.com 仿冒 macio.com.cn，子域 jd. 再仿冒京东；crt.sh 返回空（零证书透明度记录，说明它从不申请公开 CA 证书，与"TLS 握手被拒"互相印证）。和 ReliaQuest《Silver Fox》报告对一遍：Typosquatting、Gname.com、子域承载 C2、短命新域名、无公开证书、香港 IDC 托管——六项全部吻合。

代码血统层：我给不出，而且我拒绝硬套。 我逐条复核最初"像银狐"的依据：有没有 Gh0st 源码痕迹？0 条。RTTI 显示的是 armoury::transport::ITransport + C++17 的 std::function/lambda/shared_ptr——和 Gh0st 系那种"无命名空间、类名形如 CClientSocket"的老式 C++ 完全对不上；内部命名 "Armoury" 在公开情报里也查不到任何归因。所以我的写法是：代码层是一个自研的 C++17 远控框架，对外宣称代号 Armoury，与已知家族无代码同源证据；基础设施层高度符合银狐生态。 我会把它交给 CNCERT 做代码比对，而不是自己拍板说"这就是银狐"。

中间还有一次必须做的证伪。 公开情报里确实有三个 "Armoury"：微软的检测名 Trojan:Win32/Armoury，安天的 ArmouryLoader（x86、劫持华硕 Armoury Crate 的 ArmouryA.dll、用 OpenCL/GPU 解密），以及 Zscaler 记录的 CoffeeLoader 的 "Armoury" 壳。名字撞得很厉害。我做了五个阴性检测：OpenCL、clCreateBuffer、ASUS、ArmouryA、freeBuffer——5 个文件里全部 0 命中；而且本样本是 x64 原生（不是 x86），注入手法是 Nt* 进程镂空 + notepad.exe（没有天堂之门/系统调用号搜索）。结论：命名碰撞，非同源，归因时不能合并。 偷懒把两个 "Armoury" 当成一家，整个归因就毁了。

顺带说个容易被当成"归因铁证"的东西：三个模块里都有个叫 .fptable 的节，我一度想拿它当家族锚点——但它在所有模块里都是 512 字节全零，而且多个互不相关的恶意家族里都有同名同形的空节。那是构建工具链留下的，不是团伙留下的：能当"狩猎 pivot"，不能当归因。

收尾：把样本和补丁做成一个能安全复现的释放器

分析写完了，但东西交不出去。手上有五个文件：原始样本 + 四个补丁版（switch 1 字节 / nop 3 字节 / kill 5 字节 / all 9 字节）。直接扔文件夹有两个问题：误触（手滑双击就真跑了）、留不住（本机实时防护会在落盘后约 1 秒内按内容特征删掉，改后缀也没用）。

打包： AES-256 压缩包，口令 infected。坑在于必须在内存里拼完再写出去——先落一个临时明文文件再压缩的话，实时防护会在压缩途中把它删掉，包就残缺了。流程：读原文件 → 校验 SHA-256 → 内存里 writestr → 一次写出 → 再从内存回读逐条比对。

自包含启动器： 解压出来还是五个独立文件，照样被吃；干脆把五个样本作为 RCDATA 资源塞进一个 EXE（成品 10,467,328 字节），运行时再释放，磁盘上不存在"单独的样本文件"。核心是三道关：① 免责声明默认按钮是「不同意，退出」，回车即放弃且不释放任何文件；② 默认勾着「仅释放到磁盘，不要运行」；③ 取消安全选项后才出现的最后确认。手滑双击不会跑起来。

几个细节：释放文件保持原名（样本从自身路径推导守护参数，改名会改行为）；防自覆盖（启动器若叫 chat-deepseek.exe，自动转存 payload\）；被杀软删掉要说清楚（Sleep(1200) 后核对大小，对不上就弹「被实时防护拦截」）。另外留了两个模式：--verify 不写盘、不执行，只从内存资源算 SHA-256；--extract <目录> 纯命令行释放。--verify 和做静态分析的纪律是同一个思路：证明字节是对的，但一个字节都不落地、也绝不运行。

先拿无害测试载荷（只弹一个消息框）跑通全链路——不同意→不释放、仅释放不运行、真启动、改名自覆盖、--verify/--extract 哈希核对，七个场景全过才换真实样本重建。构建坑：windres 要加 -c 65001（否则中文目录名按 CP936 解码找不到）、.rc 必须写 #define IDR_PAYLOAD_*（否则被当字符串资源名）、链接 -municode -mwindows -static -lbcrypt -lshell32。顺手还写了个只读的本机 IOC 排查脚本——每条判据都是从前面那些分析结论来的。

交付物：

银狐样本启动器.exe  10,467,328 B  sha256 10c91cc3cd88c6a375d5dbcf427b2dcde4ab436ef1a131b5a5818c1b4f46cdb5
样本包.zip          4,594,752 B   sha256 595589ebf36b332b032877288d616da42bf36c684f98784bc747669e94ddafd6  （AES-256，口令 infected）

五个变体哈希在包里和 --verify 报告里是同一组（68ae0cab… / 8879984a… / 31620c4b… / 30927d0a… / bd93e88f…），两处对得上。

复盘：这几条纪律是踩出来的

一、读到最后一章再下判断。 这份分析里"为什么双击没反应"被推翻了四次，"协议是什么""各模块是不是一套密钥""高熵区是不是密文"各被推翻过一次。只读前三分之一就写总结，写出来的东西会全错。

二、工具会给你"看起来正常"的错误答案。 线性反汇编遇跳转表会静默失步，把"30 处引用"报成"零引用"；把 VirtualSize 读成 VirtualAddress 会让导入表解析落到空区，然后你判"它加壳了"。工具不报错不代表它是对的——最终以字节为准。

三、高熵不等于密文，随机也不等于随机。 字节表可以熵 7.9；真随机要用 χ² 和熵的偏离度验。反过来，我一直以为的高熵密文最后发现是 8 字节短周期 XOR——"高熵 ⇒ 强加密"这个直觉在本案被实证推翻了。

四、搜到 2 字节魔数先算随机期望命中数。 4D 5A 在 1.75MB 里的随机期望命中约 28 处——单次命中就是噪声级别。判据必须是长串或整文件哈希。

五、不映射进程名的 IP 排序全是噪声。 那个中国段 IP 一度是头号嫌疑，实际是 Windows 自带进程。

六、能当 IOC 的东西，先问"它会不会变"。 文件名从 12 个里随机抽，真正的锚点是路径形态和命令行参数。同理，静态串与运行态产物对得上号（ARMGID833B463E ↔ G-833B463E）才是最强证据——这种互证我遇到四五次。

七、操作系统会骗你，是因为它没说英文。 中文 Windows 的 ipconfig /displaydns 表头是「记录名称」；PowerShell 5.1 不支持三元运算符；.ps1 双击默认不执行。每个都能让你得出错误结论或浪费一整天。

八、取证产物不要落在受快照管辖的盘上。 我在虚拟机里跑完采集、打完快照后做硬盘还原，C:\forensics 连同产物一起被回滚吃掉了——白做一遍。每跑完一个阶段立刻外传。

九、交付物也要设计"防误触"和"防被吃"。 样本直接放文件夹里，可能被误双击，也会被实时防护悄无声息删掉。所以做成了"内存里打包 + 内嵌 EXE + 默认选项偏安全"的释放器——默认值不是随手定的，它是最后一道防线。

最后一句实话：这份分析能推进到 C2 和归因，靠的不是某个聪明方法，而是每次得出结论后都逼自己写清楚"什么证据能推翻它"。每一条被推翻的结论，都是下一次更精确的起点。真正拿到手的，都是被推翻到只剩骨架后还站着的那些。

样本下载:https://wwaux.lanzoul.com/b00jflpl5i

密码:4a97

云散皆星河的博客

我写了半个用户态杀软--R3 ShieldCore!!!

#我写了半个用户态杀软--R3 ShieldCore!!!

#注入:把同一份 DLL 放进每个进程

#新进程不能有盲区

#进了进程,把 API 换掉

#事件从别的进程传回来

#弹窗怎么跨进程

#卸载顺序,一步都不能换

#几个真踩过的坑

#它拦不到什么

#说到底

用 Python 复现极域 V6.0 教师端通信协议

#用 Python 复现极域 V6.0 教师端通信协议

#为什么要重新实现一个教师端

#从黑盒到协议地图

#Python 如何表达二进制协议

#难点一：黑屏和键鼠锁定其实是两条路径

#难点二：UDP 分片不是简单拼接

#难点三：同一个 MESS，必须先判断语义类别

#让研究脚本具备可调试性

#运行与观察

#项目带来的几个启发

#结语

疏影：面向 Weeback 的专项破解与工程实现

#疏影：面向 Weeback 的专项破解与工程实现

#一个统一的破解与调试界面

#主程序真正做了什么

#自动检测与破解概览

#安装目录与进程联动

#DLL 模块管理

#数据库定位与字段还原

#关联组件检查与清理

#活动日志、确认与窗口能力

#用 IDA 还原 sub_4CB0D0

#可选的内核扩展：YsjxhProcess

#默认不加载驱动

#每秒刷新，但不打断操作

#不猜测内核偏移

#扩展驱动工具窗口

#构建与签名顺序

#开源致谢

#写在最后

从黑盒到可交互画面：极域 V6.0 连续投屏与远程操控协议逆向

#从黑盒到可交互画面：极域 V6.0 连续投屏与远程操控协议逆向

#摘要

#一、先建立正确的系统模型

#二、在 IDA 中如何找到入口

#2.1 不要只搜索可见字符串

#2.2 从网络 API 反推对象边界

#2.3 从 feature 分发器找到 617 字节参数块

#2.4 从 MCMD 跟到模拟输入

#三、用抓包给反汇编“定类型”

#3.1 差分比对比猜字段更快

#四、观看请求：MESS feature 8

#4.1 feature 8 内层结构

#4.2 正确启动时序

#五、UMSP：SHCO、TKPC 与 channel 10

#5.1 SHCO 选择包

#5.2 TKPC 数据包

#六、桌面分片重组

#七、HHRF/HJRF 桌面记录

#7.1 为什么请求真实 H.264 时容易“黑屏”

#7.2 为什么画面颜色会错

#八、SPUC：远端光标不是画面的一部分

#九、远控建立：COMD 事务中的 MCMD

#十、28 字节模拟输入包

#10.1 鼠标：kind=1

#10.2 键盘：kind=16，仍是实验性

#十一、如何判断“真的成功”，而不是日志看起来成功

#十二、几个真正耗时的坑

#12.1 把 4806 与 feature 参数端口混为一谈

#12.2 按 recv 边界解析 TCP

#12.3 把 16 字节 SPUC 当坏视频帧

#12.4 在码流中途更换播放器

#12.5 把颜色问题误判为 RGB/BGR

#12.6 本地指针、预测指针和远端指针混在一起

#12.7 用错误的 COMD 边界调 MCMD

#十三、实现中的防崩溃与可观测性设计

#十四、当前结论与下一步

我写了半个用户态杀软--R3 ShieldCore!!!

注入:把同一份 DLL 放进每个进程

新进程不能有盲区

进了进程,把 API 换掉

事件从别的进程传回来

弹窗怎么跨进程

卸载顺序,一步都不能换

几个真踩过的坑

它拦不到什么

说到底

用 Python 复现极域 V6.0 教师端通信协议

为什么要重新实现一个教师端

从黑盒到协议地图

Python 如何表达二进制协议

难点一：黑屏和键鼠锁定其实是两条路径

难点二：UDP 分片不是简单拼接

难点三：同一个 MESS，必须先判断语义类别

让研究脚本具备可调试性

运行与观察

项目带来的几个启发

结语

疏影：面向 Weeback 的专项破解与工程实现

一个统一的破解与调试界面

主程序真正做了什么

自动检测与破解概览

安装目录与进程联动

DLL 模块管理

数据库定位与字段还原

关联组件检查与清理

活动日志、确认与窗口能力

用 IDA 还原 sub_4CB0D0

可选的内核扩展：YsjxhProcess

默认不加载驱动

每秒刷新，但不打断操作

不猜测内核偏移

扩展驱动工具窗口

构建与签名顺序

开源致谢

写在最后

从黑盒到可交互画面：极域 V6.0 连续投屏与远程操控协议逆向

摘要

一、先建立正确的系统模型

二、在 IDA 中如何找到入口

2.1 不要只搜索可见字符串

2.2 从网络 API 反推对象边界

2.3 从 feature 分发器找到 617 字节参数块

2.4 从 MCMD 跟到模拟输入

三、用抓包给反汇编“定类型”

3.1 差分比对比猜字段更快

四、观看请求：MESS feature 8

4.1 feature 8 内层结构

4.2 正确启动时序

五、UMSP：SHCO、TKPC 与 channel 10

5.1 SHCO 选择包

5.2 TKPC 数据包

六、桌面分片重组

七、HHRF/HJRF 桌面记录

7.1 为什么请求真实 H.264 时容易“黑屏”

7.2 为什么画面颜色会错

八、SPUC：远端光标不是画面的一部分

九、远控建立：COMD 事务中的 MCMD

十、28 字节模拟输入包

10.1 鼠标：kind=1

10.2 键盘：kind=16，仍是实验性

十一、如何判断“真的成功”，而不是日志看起来成功

十二、几个真正耗时的坑

12.1 把 4806 与 feature 参数端口混为一谈

12.2 按 recv 边界解析 TCP

12.3 把 16 字节 SPUC 当坏视频帧

12.4 在码流中途更换播放器

12.5 把颜色问题误判为 RGB/BGR

12.6 本地指针、预测指针和远端指针混在一起

12.7 用错误的 COMD 边界调 MCMD

十三、实现中的防崩溃与可观测性设计

十四、当前结论与下一步

附录 A：协议层级速查

附录 B：运行命令

我翻新了JiYu Trainer!!!部分重写一个停更五年的反电子教室软件 —— Dzjs Trainer v1.0.0

为什么接手这个项目

一、驱动：从 SSDT Hook 到内核回调