## 一、先说这是个什么坑

需求很朴素：一份带宏的业务模板 `.xlsm`，宏里有缺陷，要改。

难点在于环境给了三道锁：

1. **不能用 Excel/WPS 的 COM 自动化**。`New-Object -ComObject Excel.Application` 直接被安全策略拦截，报 `COM object instantiation can run arbitrary code`。也就是说"用脚本驱动 Excel 打开→改 VBA→保存"这条最省事的路，一开始就断了。
2. **没有 Visual Studio**，没有 VBA 编辑器可用。
3. **不能让用户手动改**。用户不是开发，指望他打开 VBE 粘贴代码不现实，而且几十份模板手改必错。

于是问题变成：**在完全不让 Excel 参与的前提下，直接改写文件里的 VBA 源码，并且不能碰坏表格数据、不能让 Excel 打开时报格式错误。**

这篇文章记录的就是这件事怎么做成，以及中间两条看起来"校验全绿"、实则把 Excel 搞崩的错误路线。

## 二、VBA 到底存在文件的哪个位置

动手前必须搞清楚存储结构，否则后面全是瞎试。

`.xlsm` 本质是一个 zip。宏不在工作表里，而在一个独立部件：

```text
xl/vbaProject.bin  →  这是一个 MS-CFB 复合文档（OLE2 结构，和老式 .doc 同宗）
                        ├── VBA/dir          （目录流，记录各模块元信息）
                        ├── VBA/ThisWorkbook
                        ├── VBA/模块1
                        └── …每个模块一条流
```

每条**模块流**的布局是：

```text
[ PerformanceCache 前缀 ] [ MS-OVBA 压缩后的源码 ]
                          ↑ 这个分界点叫 textoffset
```

两个关键点：

- **PerformanceCache 是 Excel 的编译产物缓存**（p-code），规格上规定读取时忽略、保存时重建，实测前缀能长达 46 KB，**必须原样保留**。
- **源码段是 MS-OVBA 压缩的**，这是一种带 CopyToken 的 RLE/LZ 混合编码，不是 zip、不是 deflate，得按 `[MS-OVBA]` 规范自己解。

用 Python 把它读出来的骨架：

```python
import sys; sys.path.insert(0, r"C:\ProgramData\wb_tmp\pylibs")
import olefile, zipfile
from oletools import olevba

vba = zipfile.ZipFile(XLSM).read("xl/vbaProject.bin")
open(TMP, "wb").write(vba)

ole = olefile.OleFileIO(TMP)
proj = olevba.VBA_Project(ole, "", "PROJECT", "VBA/dir")
proj.parse_project_stream()                     # 不调用这句，modules 会是空的
mods    = {fn: code for _cp, fn, code in proj.parse_modules()}
offsets = {m.streamname: m.textoffset for m in proj.modules}
```

`parse_project_stream()` 这一句不能省——直接调 `parse_modules()` 会什么都不返回，这是新手第一个卡点。

另外两个容易忽略的事实：

- 中文环境下**模块源码是 GBK 编码**，读写都要按 GBK 处理；
- 源码换行是 **`\r\n`**，后面做字符串匹配时 old/new 串里必须写字面的 `\r\n`，写成 `\n` 会匹配不到，而且它不报错，只是"静静没生效"。

## 三、三条路线，两条把 Excel 搞崩了

改源码说起来就是"换掉压缩段再写回去"，但怎么换，差别巨大。我一共试了三条路，**只有第三条是安全的**。

### 路线 1：完整重建 CFB（Excel 拒收）

思路：解析出所有流，改完源码后用 `olefile`/自写代码重新构建一个 CFB 复合文档，再重打 zip。

结果：**olefile、olevba 的所有校验全部通过**，结构自洽、源码回读一致。但双击打开时 Excel 直接报：

> 文件格式或文件扩展名无效

结论：**校验库通过 ≠ Excel 认账**。Excel 对 CFB 的解析比开源库严格得多，红黑树拓扑、名称编码、时间戳这些细节，只要有一处不是它熟悉的样子，它就拒收整个文件。

### 路线 2：整流替换 + dir 流重压缩 + FAT 链截断（Excel 原生闪退）

这条更阴。做法是把整个模块流换成"纯压缩容器"，同时把 dir 流里该模块的 `MODULEOFFSET` 改成 0（PerformanceCache 可省略，Excel 会自动重编译），再手工截断 FAT 链、把多余扇区标 `FREESECT`，最后把改动过的扇区原位写回。

结果：**所有静态校验依然全绿**——olefile 打得开、源码回读一致、zip 比对也只有 `vbaProject.bin` 变了。

但用户一输入触发 VBA，Excel **直接原生闪退**。事件日志：`0xC0000005`（访问违例），出错模块 unknown，**重试 3 次必崩**。

推定原因是 dir 流重压缩或 FAT 手术产生了 Excel 严格解析器不认的编码——**olevba 的解码器太宽容，验证不出这类问题**。

### 路线 3：等长原位替换（唯一可用）

核心约束：**新压缩体的字节长度必须等于原压缩体长度，dir 流和 FAT 链一个字节都不动。**

- textoffset 前缀（PerformanceCache）原样保留；
- 只在压缩段做原位覆写，按 FAT 链写回原扇区；
- 目录表、dir 流、MiniFAT 全部零改动。

这条路之所以稳，是因为它**不触发 Excel 对结构变更的任何敏感路径**——文件大小、扇区布局、目录信息全部不变，Excel 感知到的只是"这段 p-code 缓存好像和源码对不上了"，而它会自动重编译。

## 四、等长替换里最难的部分：字节预算怎么凑

"等长"三个字，做起来是整个流程里最磨人的一步。

新源码压缩后如果比原来长，就填不进原位；短了也不行，会破坏后续结构。所以要主动把源码**凑到字节级等长**，手法是：

1. **精简**：去掉全行注释和行尾注释，把源码压到**小于**原长度。注意判断注释不能简单 `split("'")`——字符串字面量里的单引号不是注释，得用一个引号状态机扫描 `"…"` 区域。
2. **配平**：去注释前后统计关键字数量（`Sub/End Sub`、`Function/End Function`、`For/Next`、`Do/Loop`）必须一致，防止注释里混进了代码。
3. **填充**：压缩后若还差几十字节，用**无重复 3-gram 的随机注释**补齐。为什么要求无重复 3-gram？因为 MS-OVBA 压缩靠 CopyToken 复用前面出现过的串，重复模式太多会让压缩率变高、长度缩水，凑不准。
4. **回补 banner**：如果预算富余很大，在源码头部补一段精简的说明注释。

还有个兜底细节：`proj.modules` 有时为空，拿不到 `textoffset`。这时改用**暴力定位**——扫描流内每个 `0x01` 的位置，逐个尝试 `decompress_stream(stream[i:])`，与已知源码逐字节相等的那一处就是正确的 textoffset。

## 五、MS-OVBA 压缩自己实现的三个坑

既然要原位改写压缩段，就得自己实现 MS-OVBA 压缩器。规范读起来不复杂，但这三个点各卡了一轮：

1. **`bit_count` 用的是"块内位置"，不是全局位置。** 编码 CopyToken 时，`difference = 解压当前位置 − 本块起点`（不是文件全局偏移），`bit_count = max(ceil(log2(difference)), 4)`；`difference == 0` 时只发字面量。用全局位置算，解压必失败。
2. **CopyToken 的 offset 差 1。** 编码和解码都是 `offset − 1`，少减一个就直接错位。
3. **单块跨度上限是 3584，不是 4096。** 全字面量时块体最大 4608 字节，超过 4096 会溢出，实测取 3584 才安全。

CFB 层面还有两个偏移要记牢：**MiniFAT 起始扇区在 CFB 头 `0x3C`，扇区数在 `0x40`**（`0x38` 那个是 mini-stream 截断阈值 4096）。另外缩流有个坑：模块流若被缩到 **< 4096 字节**会留在常规扇区，而 olefile/Excel 会按 ministream 语义去读，直接读到垃圾。要么保证替换后流长 ≥ 4096（在压缩体内加注释内容凑，**不能**在容器尾部垫零——严格解析器会把尾部当新 chunk 报 `InvalidChunkSignature`），要么把它搬进 ministream。

## 六、最阴的一层：改了源码，Excel 跑的还是旧的

这是整件事里最反直觉的一点，也是最容易让人"明明改对了却以为没改"的地方。

拼接完的新文件，源码回读是对的，但**宏的行为完全没变**。原因是：Excel 实际执行的不是流尾部的明文源码，而是**流前缀 PerformanceCache 里的旧编译 p-code**。源码和缓存不一致时，Excel 未必会重新编译——它可能就一直跑缓存里的旧版本。

验证方式（E2E，别省）：用 COM 开宏后 `Application.Run "模块名.PublicSub"`，观察行为特征是否符合新版。

让新代码**可靠生效的唯一办法是 VBOM 重建模块**：

```text
1. 打开 AccessVBOM 信任项（注册表）
2. VBComponents.Remove 旧模块
3. VBComponents.Add(1) 新建，改回原模块名
4. CodeModule.AddFromString(新源码)
5. Run 一次触发编译
6. SaveAs 另存
```

两个必须注意的点：

- **`AddFromString` 的源码里必须剥掉 `Attribute VB_Name` 行**，重复的属性行会导致编译失败，`Run` 时报"宏不可用"；
- **只往里塞一两行注释不能让缓存失效**，必须整个模块重建。

顺带说一句：如果环境允许用 COM 做 VBOM 重建，那其实还有一条更省事的路线——直接以只读打开工作簿、改完 `SaveAs` 新文件名，**Excel 自己会重写 `vbaProject.bin`**，p-code 残留风险直接清零。能走这条路就别手工改二进制。

## 七、交付前的验证清单（不验证不许交付）

静态校验工具和 Excel 的严格度差距巨大，所以我把验证固化成 7 条，逐条过：

1. **压缩往返**：`decompress_container(compress_container(src)) == src`，并用 `olevba.decompress_stream` 交叉验证（两套独立实现）；
2. **流比对**：新旧 `vbaProject.bin` 逐流比对，除目标模块外**其余流必须逐字节一致**；
3. **源码回读**：对新的 `vbaProject.bin` 再跑一遍解析，确认源码与预期字符串**完全相同**；
4. **zip 比对**：新旧 xlsm 的 zip 条目**只有 `xl/vbaProject.bin` 不同**，其余逐字节一致（证明表格本体没被碰）；
5. **表格回读**：`openpyxl` 以 `keep_vba=True` 加载，比对单元格值、行高、合并区、打印区域；
6. **CFB 结构**：新目录表前 116 字节应与原始逐字节相同，只有 offset 116/120 的 start/size 变化；
7. **关键字配平**：`Sub/End Sub`、`Function/End Function`、`For/Next`、`Do/Loop` 计数相等；`If/End If` 的口径是 `^(If|ElseIf)…Then$` 条数 **减去** `ElseIf` 条数 == `End If` 条数。

最后一步交付：先 `Copy-Item` 备份原文件再就地替换，并把备份路径明确告诉使用者。

## 八、几个方法论层面的教训

**1. "能通过解析器校验"和"能被宿主程序接受"是两回事。**
这套流程里两次翻车都栽在同一个认知上：olefile/olevba 全绿，Excel 要么拒收、要么原生闪退。开源解析器的容错度远高于 Excel 的严格度，**最终裁判只有 Excel 本人**。所以任何二进制级修改，最后一环必须是"真机打开跑一遍"，静态校验只能用来缩小范围，不能用来宣布成功。

**2. 改数据前先留快照，别信"一律删除/一律清空"式修法。**
这次的缺陷报告里，最初的修法建议是"把单元格里的 `Chr(10)` 全删掉"。但那份模板的正文**本身就用 `Chr(10)` 分行**——照做会直接毁掉内容。正确做法是改动前留原文快照，还原时按快照回写。同理，修一个缺陷前，先确认这条触发路径上还有谁在改同一份数据。

**3. 诊断前先确认"实际运行的是哪一版"。**
这次中途出现过一个很坑的情况：交付的 v4 文件，用户测出来的症状全是 v3 的行为。原因是他此前打开的旧版工作簿还留在 Excel 内存里，随手保存就把补丁覆盖回旧版了。**诊断前先提取目标文件的宏源码、比对版本特征**（比如某版独有的函数名），确认眼前跑的到底是哪一版，否则整套推理都建立在错误前提上。

**4. 别碰结构，只碰内容。**
所有成功的方案都遵循同一条原则：目录表、dir 流、FAT 链、其余模块流，一律零改动，只在压缩段做等长原位覆写。反过来，凡是动到结构（重建 CFB、改 dir 流、截断 FAT）的方案，全都在 Excel 面前翻车了。

## 小结

| 环节 | 结论 |
|---|---|
| VBA 存储位置 | `xl/vbaProject.bin` → MS-CFB → 模块流 = PerformanceCache + MS-OVBA 压缩源码 |
| 重建 CFB | Excel 报"文件格式或文件扩展名无效" |
| 整流替换 + FAT 截断 | 校验全绿但 Excel 原生闪退（0xC0000005） |
| 等长原位替换 | 唯一已验证安全路径 |
| 改了不生效 | 执行的是旧 p-code，需 VBOM 重建模块（`AddFromString` 要剥 `Attribute VB_Name`） |
| 最终裁判 | Excel 真机打开跑一遍，解析器校验不能替代 |

整个过程的门槛不在算法，而在**对宿主程序脾气的理解**：它比文档严格、比解析库挑剔，而且它认的是缓存不是源码。想明白这三点，剩下的就是工程耐心。


不能用 Excel/WPS 的 COM 自动化。New-Object -ComObject Excel.Application 直接被安全策略拦截，报 COM object instantiation can run arbitrary code。也就是说"用脚本驱动 Excel 打开→改 VBA→保存"这条最省事的路，一开始就断了。

#WorkBuddy# 不能开 Excel、不能用 COM，怎么改 .xlsm 里的 VBA 宏？一次 MS-OVBA 二进制级修补实战

环境禁用 Excel COM 自动化、又没有 Visual Studio，怎么改掉 .xlsm 里的 VBA 宏？本文记录一次 MS-OVBA 二进制级修补实战：先解剖 vbaProject.bin 的 CFB 与压缩流结构，再对比三条改造路线——重建 CFB 被 Excel 拒收、整流替换导致原生闪退、等长原位替换才是唯一安全解；最后揭示改了源码却不生效的 p-code 缓存陷阱与 VBOM 重

编程语言

开发工具

安全

在Excel/WPS被禁用、无VBA编辑器的环境下，直接改写xlsm文件中vbaProject.bin内的MS-OVBA压缩源码。关键成功点是采用等长原位替换技术，确保字节长度不变，不触发结构敏感路径。需自研压缩器处理三个编码坑，并注意Excel执行的是PerformanceCache缓存而非明文源码，必须通过VBOM重建模块才能生效。验证需7条清单加真机测试，切勿依赖解析器校验。

代码解释

容器

Python

WorkBuddy企业版限时双倍 Credits 活动

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

在Excel/WPS被禁用、无VBA编辑器的环境下，直接改写xlsm文件中vbaProject.bin内的MS-OVBA压缩源码。关键成功点是采用等长原位替换技术，确保字节长度不变，不触发结构敏感路径。需自研压缩器处理三个编码坑，并注意Excel执行的是PerformanceCache缓存而非明文源码，必须通过VBOM...

#WorkBuddy# 不能开 Excel、不能用 COM，怎么改 .xlsm 里的 VBA 宏？一次 MS-OVBA 二进制级修补实战-腾讯云开发者社区-腾讯云

#WorkBuddy# 不能开 Excel、不能用 COM，怎么改 .xlsm 里的 VBA 宏？一次 MS-OVBA 二进制级修补实战

#WorkBuddy# 不能开 Excel、不能用 COM，怎么改 .xlsm 里的 VBA 宏？一次 MS-OVBA 二进制级修补实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐