好友
阅读权限10
听众
最后登录1970-1-1
|
本帖最后由 XiaoYangTech 于 2026-2-24 16:18 编辑
破壁之旅：我与Gemini的24小时，从Enigma枷锁到自由之身
——记一次VideoScribe 3.14.2魔改版的一机一码去除历程
本文首发吾爱破解，记录了一次从零开始、历经AI幻觉、工具失效、内存海捞，最终成功剥离Enigma Protector一机一码的全过程。献给所有在逆向路上死磕到底的兄弟们。
缘起：一个被二次锁住的“破解版”
事情是这样的：我在B站看到有人拿VideoScribe“拿下整个雅思频道”，声称这个软件非常易用，我顿时非常感兴趣，去B站搜索了一下，发现这个软件原生中文支持相当不好，官方版本不支持导入中文字体，也没办法创建竖屏的画布，更没法免登录进去软件随便免费用里面功能。由于当时还没放寒假，第二天在学校的智慧黑板上下载到一个声称“VS4.2楷体版”的安装包，安装以后试玩了几下，发现非常的简单易用，但是不是软件内中文字体缺字漏字，就是白屏直接卡死，工程文件直接白费，外网上面的破解版，需要每七天注册一个账户，还没有中文汉化界面。于是考完试只能求助于某购物网站，买到了一个号称“最后一个本地版本”的VideoScribe安装包。这软件后期改成了网页套壳，我拿到的这个是基于Adobe AIR的3.14.2版本，主程序371MB。
但卖家留了一手：程序启动会弹出一个机器码窗口，需要找他要注册码才能用。重装系统就得重新要码，说明是本地验证。
查壳：Detect it Easy，无壳。搜文件：看了AIR的XML文件，指向独立的文件，但是找了以后，发现没有独立的VideoScribeBin（正常AIR程序应该有）。搜字节：CWS、FWS全无，全是乱码。
我开始意识到：这不是普通的封包，这是加了一机一码的商业壳。
第一阶段：开搞前的“AI热身”——幻觉与现实的交错
我想起之前拿Gemini问各种技术问题答得头头是道，瞬间有了信心，打开了Gemini，想借它的思路破局。结果……
幻觉1：让我用金山搜索找文件 我之前别的对话说我喜欢用WPS，它直接脑补出“金山搜索”这个不存在的工具，让我全盘搜.lic等扩展名。我一看就知道是幻觉，忽略以后，AI又叫我去AppData看多出来的swf，我找了半天，毛都没有。
幻觉2：让我用WinHex搜“Primary Memory” WinHex打开RAM后根本没有这个标签，它非说双击就行。我卡了一小时，最后发现是AI又在胡编乱造。
幻觉3：让我用火绒剑“独立版” 我说火绒新版没火绒剑了，它坚持说“网上有独立版”。我去下了，结果根本打不开，说是火绒版本缺少驱动，新版火绒“安全分析工具”也没这么多功能。
以及更多的幻觉，这里不再一一叙述。
我开始怀疑人生：这AI到底靠不靠谱？
但后来我想通了：AI是参谋，不是司令。它的建议要结合实际情况过滤，但它的知识库确实能提供方向。
第二阶段：虚拟机伪装——突破“This program cannot run under VMWare”
实体机激活了软件，为了能在虚拟机再次出现那个一机一码授权窗口，首先得解决反虚拟机。这个程序一启动就会检测VMware环境，弹窗报错退出。
一开始，我按照AI提供的防检测代码，在虚拟机的.vmx文件中添加了以下几行：
monitor_control.restrict_backdoor = "TRUE"
isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
保存后重启虚拟机，那个烦人的“This program cannot run under VMWare”弹窗消失了，程序正常弹出注册窗口——第一步伪装成功。
但随后，为了彻底克隆实体机的硬件特征（主板、CPU、系统盘等），我又按照AI的指导，在.vmx中追加了更多代码，比如：
cpuid.1.eax = "00000000000906EB"
hypervisor.cpuid.v0 = "FALSE"
board-id.reflectHost = "TRUE"
hw.model.reflectHost = "TRUE"
serialNumber.reflectHost = "TRUE"
smbios.reflectHost = "TRUE"
结果再次启动虚拟机时，VMware报错：
无法加载配置文件“E:\Virtual Machines\Win7x64\Windows 7 x64.vmx”。
文件的第 164 行: 变量“SMBIOS.reflectHost”已定义。
文件的第 163 行: 变量“serialNumber.reflectHost”已定义。
...
原来是因为之前添加的防检测代码中已经包含了部分同名变量（如board-id.reflectHost等），导致重复定义。我只好让AI重新搜索并删除了所有重复的行，确保每个变量只出现一次。
最终保留下来的完整代码如下：
monitor_control.restrict_backdoor = "TRUE"
isolation.tools.getPtrLocation.disable = "TRUE"
isolation.tools.setPtrLocation.disable = "TRUE"
isolation.tools.setVersion.disable = "TRUE"
isolation.tools.getVersion.disable = "TRUE"
monitor_control.vt32 = "TRUE"
monitor_control.strict_backdoor = "TRUE"
hypervisor.cpuid.v0 = "FALSE"
cpuid.1.eax = "00000000000906EB"
board-id.reflectHost = "TRUE"
hw.model.reflectHost = "TRUE"
serialNumber.reflectHost = "TRUE"
smbios.reflectHost = "TRUE"
再次启动虚拟机，一切正常，但是程序依然能弹出注册窗口。
接下来，我尝试了各种硬件特征克隆：修改磁盘卷序列号（vol C:），导入实体机的注册表授权项……然而注册窗口依然顽强地弹出来。这说明卖家的Enigma壳不仅有反虚拟机，还有深度的硬件绑定，单纯靠改配置文件无法欺骗。
虽然这条路没走通，但它让我意识到：必须从内存层面动手，直接抓取解密后的资源。
第三阶段：行为监控——ProcMon与ProcExp的尝试
此时视线转回实体机，在转向内存操作之前，我决定先用动态监控工具看看程序运行时到底访问了哪些文件。这或许能直接定位到授权文件的位置。
3.1 Process Monitor监控文件访问
我在虚拟机中打开Process Monitor，设置过滤器：
Process Name 是 VideoScribe.exe
Operation 包含 CreateFile、ReadFile、WriteFile等
然后运行程序，等注册窗口弹出后停止监控。在茫茫多的日志中，我发现了几条关键记录：
程序尝试读取 C:\Users\Administrator\Desktop\evb088e9，结果显示 NAME NOT FOUND。
程序频繁查询 HKCU\Software\Classes\CLSID 下的某些项。
还尝试读取 C:\Users\Administrator\AppData\Roaming\Sparkol-VideoScribe 下的文件，但该目录当时是空的。
这个 evb088e9 引起了AI的注意——evb 是 Enigma Virtual Box 的特征，说明程序在试图访问一个虚拟化的挂载点。但既然硬盘上没有这个文件，那它肯定是映射在内存中的虚拟文件。
为了对比，我在实体机（已激活）上也运行了一次ProcMon。结果发现实体机中 evb088e9 这条记录是 SUCCESS，并且程序还成功读取了 C:\Users\Admin\AppData\Local\Microsoft\Windows\INetCache\IE\...\videoscribe3.14.2[1].xml 这样的缓存文件。
我尝试把实体机上的 VideoScribeDesktop 整个文件夹拷贝到虚拟机的对应位置，再次运行，注册窗口依然弹出。看来授权不仅仅依赖这些静态文件，还有硬件绑定。
3.2 Process Explorer查看内存句柄
接着我用Process Explorer（ProcExp）附加到运行中的VideoScribe进程，查看它的句柄（Ctrl+L打开下方面板，切换到Handles视图）。在文件类型的句柄中，AI发现了一个名为 \Device\NamedPipe\evb 的管道，以及几个指向 \Sessions\1\BaseNamedObjects\Local\EVB_* 的 Section 对象。这些对象都是内核对象，没有对应的物理文件，进一步证实了资源被虚拟化在内存中。
这些监控虽然没直接找到文件，但让我确信：核心资源不在磁盘上，必须从内存里抢。
第四阶段：解包工具集体阵亡
我尝试了AI说的各种Enigma解包工具：
EnigmaVBUnpacker v0.63：报“此文件不受Enigma Virtual Box保护”。
7-Zip：拆出来的东西压根不是我要的Flash文件。
evbunpack.py（命令行版）：同样提示“EVB filesystem magic not found”。
其他所谓“万能脱壳机”：要么崩溃，要么输出一堆无效文件。
看来Enigma对程序做了魔改，特征码被篡改，自动化工具全部失效。我尝试用AI教的：WinHex搜索文件特征码，搜索到0个符合特征的结果。
第五阶段：动态调试——x64dbg刚附上就闪退
AI叫我尝试在虚拟机用x64dbg附加进程，结果一点“附加”，程序直接闪退。这是Enigma Protector典型的反调试机制，它检测到调试器后主动自杀。
尝试各种同类型软件均无效，看来壳的强度不低。
第六阶段：手动WinHex搜内存——发现“没这个功能”
在AI的反复建议下，我决定用WinHex直接搜索内存中的CWS特征码。AI信誓旦旦地说：“在WinHex中点击‘工具’->‘打开RAM’，选择进程，然后搜索十六进制43 57 53就能找到。”
我按照步骤操作：以管理员身份运行WinHex，点击“工具”->“打开RAM”，在进程列表中找到VideoScribe.exe，双击——弹出一个窗口，里面是各种内存段，但根本没有所谓的“Primary Memory”标签。我试着双击每个段，进去后按Ctrl+F搜索43 57 53，结果要么搜不到，要么WinHex直接卡死。
反复尝试了几次，WinHex每次都卡顿几分钟，最后无响应。我开始怀疑是权限问题，又试了以管理员运行、关闭杀毒软件，依然无效。AI这时解释说：“WinHex的RAM搜索功能对大型进程确实不太友好，可能你的版本不支持。”
折腾了一个多小时，一无所获。我意识到，靠WinHex手动搜内存这条路走不通——不是功能没有，而是实际操作中根本没法用。
第七阶段：专用Dump工具——得到fixed_dump.exe和一堆DLL
既然WinHex内存搜索不靠谱，我在网上找到一个C++写的Enigma内存Dump工具（据称支持v5.x到v7.80）。抱着试试看的心态，运行：
以管理员身份运行工具，选择VideoScribe.exe进程。
工具自动执行反调试绕过、挂起其他线程、Dump主模块、重建PE头。
输出：dump_raw.bin（原始内存镜像）、fixed_dump.exe（修复了PE头的EXE），以及Dumps文件夹下91个系统DLL。
我兴奋地双击fixed_dump.exe——没反应。任务管理器里进程闪一下就没。
一个重要的背景：我此时准备去睡觉了，毕竟是晚上十一点了，第二天早上再搞。第二天早上，我还特意用Gemini搜了一下“Enigma Protector破解难度”，得到的答复是“Enigma Protector的保护强度很高，脚本小子或者新手很难破解，通常需要手动脱壳和修复IAT”。这让我一度有点打退堂鼓，但想着反正也是闲着没事胡乱折腾，就当练手了。没想到第二天，正是在AI的多次指导下（虽然中间混杂着幻觉），我一步步走向了成功。
第二天早上，我尝试听AI的，用Scylla修复IAT：打开Scylla，附加到正在运行的VideoScribe，点击“IAT Autosearch”，结果搜到555个导入项，全部是Invalid，有效API数为0。强行Fix Dump后，程序依旧无法运行。
工具附带的说明也说了：对于Enigma 7.x，Dump出来的EXE很可能无法运行，需要手动修复。但我是小白，修复IAT对我来说太难了。
第八阶段：Process Hacker导出内存——发现488MB大块
既然修复IAT无望，我决定直接从内存里抓取解密后的资源。根据之前经验，AIR程序的核心SWF通常会在内存中以大块连续数据存在。
操作步骤：
保持VideoScribe在注册以后的主界面运行。
打开Process Hacker，右键点击VideoScribe.exe，选择“Properties”。
切换到“Memory”标签页，按“Size”排序。
发现一个488,516 KB的大块内存，在这上面还有很多几T大小的内存块，可能是Enigma为了干扰内存读取程序创建的，我挑选的那个内存块，类型为“Private”，权限为“RW”（读写）。
右键点击该行，选择“Save…”保存为big_chunk.bin。
（这里要注意：Process Hacker直接保存整个进程内存会崩溃，但单独保存一个大块没问题。）
第九阶段：WinHex搜CWS——找到一百多个“cws”
用WinHex打开这个488MB的big_chunk.bin，开始搜索希望中的SWF文件头43 57 53（CWS）。
区分大小写搜索：0个结果。
不区分大小写搜索：一百多个“cws”散落在各处，但周围的字节全是乱码，显然不是真正的文件头。
我试着按照AI说的，把第一个“cws”附近的数据切出来，另存为.swf，丢进JPEXS（FFDEC）——全是“Invalid SWF File”。
为了验证这些“cws”是不是真正的头，我还尝试了更细致的分析：观察每个“cws”后面的4个字节，看是否构成合理的SWF大小。正常的SWF头中，第5-8字节是以小端序存储的文件大小（解压后）。结果这些位置的值全是乱七八糟的，没有一个是合理的整数（比如几十MB对应的十六进制）。显然，这些只是内存中随机出现的巧合，并非真正的SWF签名。
我又尝试搜索未压缩SWF的头46 57 53（FWS），同样一无所获。心情跌到谷底。
第十阶段：转机——搜“sparkol”发现中文字符（AI的洞察）
就在我快要放弃时，Gemini给了一个建议（这次不是幻觉）：“你试试搜sparkol，那是VideoScribe的公司名，内存里肯定有。”
我半信半疑地在WinHex里搜索文本“sparkol”（区分大小写），结果——搜到了！而且不止一处！
更惊喜的是，在“sparkol”周围，竟然出现了大量可读的中文字符，比如“导出视频”、“字体设置”、“新建工程”等。这说明这一块内存里确实存放着解密后的汉化资源！
但为什么搜不到CWS？很可能卖家去掉了SWF的文件头，或者用自定义的方式存储数据。
为了确认这不是孤立的文本，我扩大了搜索范围，发现这些中文字符成片出现，覆盖了数MB的区域。这绝对是程序的核心资源区。我又尝试搜索了“xmlns”、“application”等AIR常见的XML标签，也在附近找到了匹配。至此，我确信这个488MB的大块里藏着完整的资源。
第十一阶段：FFDEC立功——“另存为”拯救世界（又是AI的点拨）
既然能看到中文，说明这段数据可以被解析。Gemini又提了一句：“也许可以直接把整个bin文件丢进FFDEC试试，它可能能识别。”
我突发奇想：直接把整个488MB的big_chunk.bin拖进JPEXS（FFDEC）试试。
双击打开，等待几秒……FFDEC居然真的加载出来了！
左侧树状目录里，scripts、fonts、texts全都能展开。字体文件夹里，赫然躺着“阿里巴巴普惠体”“Ma Shan Zheng”等中文字体，字符集完整。文本搜索里，“导出”“登录”“字体”全都在。
原来FFDEC有强大的容错能力，能自动识别内存中的SWF结构并忽略垃圾数据。它可能通过扫描二进制中的ActionScript字节码特征、字体定义等来定位有效数据，即使没有标准文件头也能解析。
我立刻点击“文件”->“另存为”，保存为一个新的VideoScribeBin.swf。
第十二阶段：借尸还魂——原版白包跑汉化
我去网上找了一个官方的VideoScribe 3.14.2原版（无壳，正常安装版）。把它安装目录里的VideoScribeBin备份，替换成我提纯后的那个SWF。
双击运行——界面出来了，全是中文，字体完美，没有任何一机一码弹窗。
那一刻，我差点对着屏幕喊出声。虽然后来发现，清空缓存路径以后，在线音乐库用不了，在线图片库用不了，但是我依然有继续搞的信心，在之后会发布出这一被垄断的软件。
复盘：为什么能成？
Enigma的软肋：它再强，也必须在内存里解密。只要能Dump内存，壳就是皇帝的新衣。
FFDEC的容错：SWF文件结构其实有很强的自描述性，FFDEC能识别并剔除内存垃圾，直接提取有效数据。
Process Hacker的内存导出：精准定位大块内存，避免全进程Dump导致的崩溃。
AI的双刃剑：Gemini给了我很多错误方向（金山搜索、Primary Memory、火绒剑独立版），但也提供了关键灵感（搜sparkol、FFDEC打开）。很多细节其实不是我注意到的，而是AI提醒的。如果没有它的这些建议，我可能还在瞎搜CWS。
行为监控的价值：ProcMon和ProcExp虽然没有直接找到授权文件，但揭示了程序的虚拟化特性，为后续的内存提取提供了信心。
坚持不放弃：面对“脚本小子很难破解”的定论，以及一次次切文件失败，最终还是靠耐心和尝试找到了突破口。
给后来者的建议
别信AI的“精确操作”：它说的工具路径、菜单名、功能，大概率是错的。但它提供的思路值得参考。
Enigma壳的破解核心：不是修IAT，不是找OEP，而是拿到解密后的资源。一旦资源到手，壳就是个空盒子。
FFDEC是神器：对付AIR程序的SWF资源，它比任何十六进制工具都管用。
虚拟机是实验室：随便折腾，不怕崩。实体机激活状态可以用来对比内存差异。
Process Hacker导内存：要单独导出大块内存，不要全进程Dump，否则容易崩溃。
ProcMon/ProcExp先用起来：先观察程序的行为，往往能给你指明方向。
多尝试，不要轻易放弃：我切了几十次文件都失败了，但最后发现直接把整个bin拖进FFDEC才是正解。
尾声：关于“黑灰产”与“免费发布”
这个卖家干的事：正版软件收费没问题，但他自己破解后再加一层Enigma壳，搞“一机一码”二次售卖。本质上是在盗版上再加锁，两头吃。
我提取出来的SWF里没有任何一机一码逻辑（校验全在壳上），所以我搞到的其实是“被剥掉锁的干净汉化资源”。
免责声明：本文所述技术仅供逆向工程与学习交流使用。所有资源来源于网络，本人仅对已存在的软件进行了内存分析与结构提纯。严禁用于商业用途。
后记：从周六晚上折腾到周日上午，从AI幻觉到工具失效，从500MB乱码到纯净SWF，这场“破壁之旅”终于画上句号。
如果你也在死磕某个Enigma保护的软件，记住这句话：壳锁住了文件，但锁不住运行时的内存。只要它跑起来，肉就一定能挖出来。
共勉。
（本文同步发布于吾爱破解，欢迎交流指正。转载请保留出处。）
|
免费评分
-
查看全部评分
|
发帖前要善用【论坛搜索】功能，那里可能会有你要找的答案或者已经有人发布过相同内容了，请勿重复发帖。 |
|
|
|
|
|
|
[复制链接]
发表于 2026-2-22 18:16
|
发表于 2026-2-23 21:39
