疏影：面向 Weeback电子教室 的专项破解与工程实现
---title: 疏影：面向 Weeback电子教室 的专项破解与工程实现
date: 2026-07-23
tags:
- Windows
- C++
- WDK
- Weeback
- IDA
- 逆向工程
- SQLite
- 内核驱动
- 专项破解
---
# 疏影：面向 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`。交叉引用说明它位于凭据字段进入数据库之前的数据处理路径上。去掉反编译器生成的类型和临时变量后，其核心逻辑可以整理为：
```c
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 内核签名。
## 开源致谢
感谢 (https://github.com/KSwordDEV/KSword) 项目带来的开源、实用的 ARK 工具，同时感谢该项目源码对本项目驱动设计与实现的启发。
优秀的系统工具不仅提供了可用功能，也展示了用户态与内核态如何划分职责、如何组织协议、如何处理动态数据，以及如何在高风险能力周围建立必要的验证与边界。疏影在开发过程中从这些经验中受益良多。
同时，项目使用到的第三方库、SDK 和工具仍分别遵循其原有许可证。引用和学习不等于抹去来源，清晰记录依赖与启发来源也是工程工作的一部分。
## 写在最后
疏影目前仍在持续迭代，但它的定位已经很明确：这是一个建立在 Weeback 静态分析结果之上的专项破解工具，而不是通用系统管理平台。安装路径、对象进程、数据库结构、字段变换和驱动操作都围绕这一目标设计。
凭据字段部分最关键的结论来自 IDA 中的 `sub_4CB0D0`：除 `0xB3` 自身保持不变外，其余输入字节都与 `0xB3` 异或。把这一结论与 SQLite 字段读取、进程管理和驱动能力组合起来，才形成了现在的疏影。后续工作仍需要把高风险能力限制在清晰的前置条件内，并为失败操作保留日志与恢复路径。 谢谢分享，准备试下 谢谢分享，准备试下
谢谢分享，准备试下 好复杂，小白飘过
好复杂，小白飘过，学习学习 文章是ai写的吗，关键步骤太简略了。 Hmily 发表于 2026-7-24 18:06
文章是ai写的吗，关键步骤太简略了。
是的哦,提示词调教有问题:'(weeqw 谢谢分享 多谢啦 大佬
页:
[1]
2