1.VMP学习笔记之壳基础流程（一）（二）
2.Dell笔记本如何刷回低版本bios
3.php源代码保护——PHP加密方案分析&解密还原
4.网易游戏的源码四种解密&解包，附工具
5.关于Majiro引擎的加密汉化记录
VMP学习笔记之壳基础流程（一）（二）
文章标题: Vmp1.学习笔记 软件名称: Vmp1. 编写语言: Borland Delphi 4.0 - 5.0 操作平台: win7 位 详细过程 章节目录 第一章: 壳的基础操作读取PE结构信息
增加区段
根据加密等级选择不同的框架
第二章: Opcode快速入门了解Opcode解析过程
辅助第三章解析Opcode引擎而编写的
无脑查表就对了
第三章: 反汇编引擎框架学习看懂第二章就看得懂第三章
无脑查表就对了
第四章: 壳的初始化与Handle块优化去掉无用的Handle块（不重要）
指令的等级变换
部分指令变形
汇编的多变性
第五章: 壳的重定位修复（未完成） 第六章: 壳的伪代码生成与排序等等（未完成） 第七章: 万用门介绍（未完成） 第八章: Vmp壳的实现或则去混淆插件（不打算写了感觉太麻烦了） 年月日 :: 基础知识之加壳基本套路读取PE信息
添加区段
修复重定位
获取壳需要使用的API（PEB那一套）
读取PE基本信息 定义的结构如下： 获取到壳要的各种API 将用户要VM的Opcode进行解析 如何定位到加密按钮使用DarkDe4.exe
设置是保护全关，所以ProtectOptions = 8
分析关键函数sub_4A（最核心的源码函数）
sub_4A函数分析偏移到新区段的起始地址
判断RVA合法性
内存对齐后的总大小
根据保护等级选择使用哪个壳模板，并设置区段保护属性
指令前缀讲解（可选） Opcode结构顺序是加密不能被打乱的 指令前缀分为四组组1——锁定和重复前缀
组2 — 段重载前缀
分支提示
组H—操作数大小重载前缀，也可被用作某些指令的源码强制性前缀
组H—地址尺寸重载前缀
强制性前缀应当位于其他可选的前缀之后（例外的情形请查看第2.2.1节,”REX前缀”） 操作数大小重载前缀允许程序在位和位操作数大小间切换 地址尺寸重载前缀（H）允许程序在位和位地址间切换 ModR/M 和 SIB 字节（可选） ModR/M字节包含3个域信息mod域与r/m域组成个可能的值：8个寄存器和个寻址模式
reg/opcode域确定寄存器号或者附加的3位操作码
r/m域确定一个寄存器为操作数或者和mod域一起编码寻址模式
某些ModR/M字节编码需要第二寻址字节（SIB）。基址+索引或者比例+索引形式的加密聚合盒子平台站长源码位寻址需要SIB字节 针对前面内容进行实践 举例说明:CC8 MOV DWORD PTR ES：[EAX+ECX*8+0x]，0x
指令拆解Legacy Prefix（可选）H—ES 段重载
Opcode（必须有）C7
ModRM（可选）
SIB（可选）C
Displacement（可选）
Immediate（可选）
解析Opcode找到主操作码（查表）得到的源码是 MOV R/M,IMM
分析ModRM（查表）ModRM结构如下
转换成二进制如下：=
分析SIB（查表）根据上文找到的地址发现是[--][--]”，表示有SIB表
得到：MOV DWORD PTR ES：[EAX+ECX*8+0x],加密0xDell笔记本如何刷回低版本bios
这两天折腾 dell 笔记本(其型号是 vostro )，因为一些原因，源码把笔记本 bios 升级到了 A，加密但是源码我又想把 bios 降级回原来的低版本时发现不行，最开始我使用的加密那个软件对 bios 的备份文件竟然无法恢复(因为升级的时候太想尽快搞定所以没有仔细看，可能是源码因为程序根本不适用该笔记本的主板型号导致的)!尝试了网上的各种刷 bios 的软件和方法(包括用 dos 下的 AFUDOS.exe 等等)，全部失败，加密对我造成不小的源码挫败感和郁闷感。
我先查看了另一台相同型号的电脑的 bios 版本是 A，因此我从 dell 官网上下载了 A 版本的 bios 更新程序(A.EXE)，然而当你要更新 bios，他会提示“You are about to flash your bios to an older Bios version. Dell does not recommend flashing your Bios to an older version. Press OK button to exit.” 当你点击确定，程序就退出了，让人对此相当的气愤，dell 你这个程序凭什么自作主张呢，为什么禁止用户降级 bios?
我在尝试了所有办法均告失败后，看起来那些网上的工具在此时全部不给力(大概是因为这个笔记本型号比较新的原因使得网上工具统统不适用)，我不得不考虑一个最可靠最稳妥地方法，用 Dell 官网上的 bios 更新程序刷回去(因为官网可以明确的下载到和机器型号严格匹配的 bios 更新)。很显然，因为我的bios版本已经被我刷至 A，我想刷回的是版本更低的 A，我知道这个程序执行到最后会弹出那个超级脑残让人绝望的opencv快速傅里叶变换源码提示，然后退出。因此身处绝境之中这时候唯一想法就是：修改这个程序!找到弹出这个 MessageBox 的代码然后逆转他的逻辑!这是我此时最后一根救命稻草，也是唯一的希望，如果依然失败我不得不接受这个让我郁闷的现实(那就是将就着用吧)，但这最后的救命稻草终将拯救我于危难。
于是开工。启动 IDA，打开 A.exe 这个程序，等待一会让 IDA 分析完毕。让我感到高兴的好消息是，这个程序没有任何的加密和自我保护。很显然它是被直接写出来的程序(从未考虑过防止有人会去修改它而采取保护手段)，我又查看了这个程序的资源，感觉里面有一些对话框，仿佛这个程序是对 ALUWINGUI 程序的一种“封装”，因为里面都是一些 ALUWINGUI 程序的印记，例如对话框等等。但是我运行网上下载的 ALUWINGUI 这个程序却总是出现死机状态，所以不得把注意力继续转会到反汇编分析 A.exe 这个程序上。
弹出这个 MessageBox 的代码非常容易定位，因为这个 MessageBox 的文本内容是明文放在 .rdata 的，非常容易就定位到弹出这个 MessageBox 的代码的位置，找到它们以后，继续向前追踪程序跳转的关键节点，很快就找到位于(.text)地址 E 处，代码如下：
1
2
3
4
5
6
7
8
9
.text:E
.text:E loc_E: ; CODE XREF: sub_D+9Fj
.text:E ; sub_D+B7j
.text:E push offset aWarning_4 ; "WARNING"
.text:E lea eax, [ebp+Caption]
.text:E0B push eax ; LPSTR
.text:E0C call ds:wsprintfA
.text:E add esp, 8
.text:E mov ecx, [ebp+var_C]
.text:E1B cmp ecx, [ebp+var_]
.text:E jnb loc_EF0 ; 重要要修改的指令！
.text:E movzx edx, word_F8
.text:E2E and edx, h
.text:E jz short loc_E
.text:E push offset aWarning_5 ; "WARNING!!"
.text:E3B lea eax, [ebp+Caption]
.text:E push eax ; LPSTR
.text:E call ds:wsprintfA
.text:E add esp, 8
.text:E4B push offset aYouAreAboutToF ; "You are about to flash your BIOS to an "...
.text:E lea ecx, [ebp+Text]
.text:E push ecx ; LPSTR
.text:E call ds:wsprintfA
.text:E5D add esp, 8
.text:E push h ; uType
.text:E lea edx, [ebp+Caption]
.text:E push edx ; lpCaption
.text:E lea eax, [ebp+Text]
.text:E6F push eax ; lpText
.text:E push 0 ; hWnd
.text:E call ds:MessageBoxA
.text:E cmp eax, 1
.text:E7B jnz short loc_E
大概浏览一下这个函数，发现第行代码：“jnb loc_EF0” 就是关键分支点，如果 var_C var_ ，bollm主图指标源码他就会弹出我们最后见到的那个 MessageBox，否则他就会跳转到附近的 EF0 位置去正常的刷 bios。所以这里只要把 jnb 改成 jb，程序就会完全以相反逻辑运行(把正在刷低版本 bios 当成刷高版本)。
为了修改汇编代码，还需要参考 intel 的官方文档：《 ia architectures software developer manual 》。对照文档可以指导我们如何修改指令。
在 IDA 中显示 jnb loc_EF0 指令对应的是 6 个字节：“0F C9 ”，对照文档的介绍可知，前两个字节"0F " 是 JNB 的操作码(Opcode)，后面四个字节“C9 ” 代表地址偏移量是 0xC9 ()个字节(即： if not below, then EIP = EIP + 0xC9)。
接下来就是修改这条跳转指令，有多种方法(以下操作码中的操作数均为相对值，即偏移量)：
(1)把 JNB 改成 JB(操作码：0F )。只有待刷版本低于当前版本才刷。
(2)把 JNB 改成 JNZ (操作码：0F )。只要待刷版本和当前版本不同就刷。
(3)把 JNB 改成 JMP(操作码：E9)。无条件刷。(因为 JMP 操作码只有一个字节，所以需要补一个 NOP )，有可能还需要修改一个版本相等的跳转，我没有认真细看了。
这里我采用的是(1)。把该 exe 用 进制编辑器例如 UltraEdit 打开，IDA中的是进程空间中的逻辑地址，把 ImageBase 减掉就成为文件地址，而 Exe 的默认 ImageBase 是 ，所以 E 转换到文件地址是源码驿站入门教程 E，跳转到 E 这一行，把从第二个字节开始的 6 个字节(0F C9 )修改成 (0F C9 )，实际上我们只是修改了一个字节(文件地址为 E 的那个字节从 0x 改为 0x)，这样原来的 JNB 指令就变成了 JB 指令。
修改以后，运行修改后的 exe 程序，那个烦人的 MessageBox 如预期的没有出现，而是出现了系统正在关机的提示(有希望了!)，然后系统自动重启，激动人心的时刻到了，终于看到进入正在刷新 bios 的提示(如下图所示)，大约1~2分钟，bios 刷新完成，然后经过再次进入 bios 简单检查版本信息，已经回到 A 版本一切正常!!!
至此，刷回低版本 bios 就完成了。如果要刷其他版本的 bios 我估计这里是差不多的，一旦遇到这种版本问题导致的不让你刷，就可以对这个文件进行修改。好在这些 bios 升级程序并没有对这种修改设置任何障碍，因此只要具有一点汇编知识，借助工具就可以很容易的修改掉这个逻辑。最后额外吐槽一下，dell 的这个不合理的逻辑，自由权应该交给用户决定!同时，众所周知，刷 bios 被形容为具有风险的事情，我的个人意见时，一定要谨慎，ai操盘线指标源码如果不是特殊需要(例如为了激活 win7 以上系统)和有成功的把握，就尽量不要去刷 bios。最后关于激活 win7 再额外说一点，目前几乎所有软破解方法和网上流传的 key 已经全部失效，而只剩下最后一条路，就是从 bios 上入手(也就是不管用软件还是硬刷 bios，使 bios 中具有 SLIC 2.1 版本)，模拟成大的笔记本 oem 厂商的产品，这样 windows 就只能放行，因为尽管这种用手段激活的“盗版”用户数量很多，但是因为它们混杂在数量更加庞大的正版 oem 产品之中，而目前 windows 的认证技术还不足以能识别，所以这种“盗版”几乎肯定是安全的。
补充BiosFix 程序下载链接：
BiosFix(刷Bios程序辅助工具) 免费绿色版:pile_string，可以获取执行的源代码。如Beast扩展，虽然源码泄露容易导致解密，但可通过ID阿分析找到加密密钥。
源代码混淆与PHP扩展方案比较
扩展方案的混淆更为深入，加密后执行环境不变，注释可能保留。例如，Beast扩展利用AES加密，但关键密钥隐藏在编译后的扩展中，可通过分析找到并解密。高级保护方案
商业防护方案如_ZendGuard_、_SourceGuardian_、_IonCube_等，常通过修改引擎或直接操作opcode来增加保护，这些方法更难直接还原源代码。结论
在选择PHP源码保护时，应优先考虑opcode或虚拟机方案，如仅使用混淆，虽然能增加阅读难度，但一旦加密扩展被获取，保护效果有限。确保加密扩展的安全性是关键。网易游戏的四种解密&解包，附工具
游戏开发与文件处理
游戏开发中通常涉及三种主要文件类型：pyc，nxs，以及npk。pyc文件通过修改opcode进行加密，加密后变为nxs文件。nxs文件则被进一步打包为npk文件。对于不同的文件类型，有相应的工具和解包步骤。
PyC文件处理
针对PyC文件的处理，使用NeteasePycObject工具进行opcode还原。此工具提供命令行功能，通过输入文件、输出文件并可选输入加密参数（默认解密），实现opcode的转换。注意，部分文件中的偏移可能存在问题，这类问题可通过自行修改工具代码解决。
NXS文件解密
NXS文件的解密则采用NeteaseNxsUnpack工具，通过Python脚本运行该工具，输入文件和输出文件路径进行解密。之后，使用Netpyc工具解密opcode并进行反编译。
NPK文件解包
对于NPK文件，使用NeteaseNpkUnpack工具进行解包，通过命令行操作，输入文件和输出文件夹路径，解包后的文件无后缀，需要用户自行分析文件类型。
Script.NPK解包
在处理Script.NPK文件时，首先解包NPK，解包后得到的文件夹包含所有NXS文件，然后按照NXS文件解密步骤进行后续处理。
解包与加密
游戏开发中，Windows系统中的nxfilesystem.dll包含解码缓冲（DecodeBuffer）函数。该函数通常在openwithloader调用中参与文件的解密处理。openwithloader负责文件的打开、校验以及部分初始化，其中解密并非所有数据都包含，通常涉及配置文件等。
文件位置与加密路径
除了NPK文件存储，部分文件也可能直接存储在系统特定位置，如 C:\Users\用户名\AppData\Local\游戏名缩写 中。找到包含script文件夹的目录后，通过在nxfilesystem.dll中搜索导出的包含路径的函数，可以解析加密路径，解密文件。
关于Majiro引擎的汉化记录
在处理Majiro引擎相关工作时，遇到的挑战在于它的工具较为分散且历史久远，主要采用OCaml编写。对于使用GBK编码文本导入的需求，我成功修改了源码并记录了流程，以供有需要的开发者参考，避免走不必要的弯路。
为了使Majiro引擎程序本体能够正常播放语音，需要对部分关键代码进行修改。因为程序通常基于日文字符来判断语音播放，当导入GBK文本时，字符对应的十六进制编码发生改变。通过使用OllyDbg工具直接打开主程序并搜索特定代码片段，将`push 0x`改为`push 0xa1b8`即可。这一步操作需进行2-3次，具体位置可能稍有不同，建议在OllyDbg中定位后，使用Winhex进行修改。推荐使用wxMEdit编辑器，它支持Unicode家族、SJIS和GBK等常见编码，方便直接浏览二进制文件内容。
对于Majiro引擎的ARC封包处理，使用`arc_conv`工具可以实现有效转换。Majo对象文件（mjo）在解密状态下有其特定的文件头，如`MajiroObjV1.`表示解密版本，`MajiroObjX1.`则为加密版本。解密版本的mjo文件更易于操作，使用wxMEdit查看时，原版文件需使用SJIS编码才能正确显示字符串内容。
在讨论Majiro引擎的汉化工作时，通常涉及到`mjasm`和`mjdisasm`两个重要工具。通过使用`mjdisasm`，可以将mjo脚本拆分为mjs和sjs文件，其中mjs文件包含脚本逻辑，sjs文件包含字符串。而`mjasm`则可以将修改后的mjs和sjs文件组合成新的mjo文件。由于原版mjo文件采用SJIS编码，无法直接用于汉化工作，因此作者选择了重新编译支持GBK编码导入的版本。
Mjdev工具作为Majiro引擎的重要组成部分，提供了编译好的版本，包含了一系列组件。汉化工作主要依赖于`mjasm`和`mjdisasm`两个工具，它们分别用于处理mjs和sjs文件的编码转换。要实现汉化，作者自行编译了一个支持GBK编码导入的Mjdev版本，通过配置相应的环境依赖，包括OCaml、ExtLib库以及bash环境，最终实现了对Majiro引擎的适应性增强。
针对操作系统环境的优化，作者推荐使用Windows的Ubuntu子系统，替代传统的cygwin环境，以简化配置过程。通过安装Ubuntu子系统并创建普通用户，可以更方便地使用opam等工具来管理OCaml环境。在完成环境配置后，使用opam创建OCaml 3..0的编译环境，并通过下载、编译和安装ExtLib库，实现了Mjdev工具的自定义编译。
为了解决Mjdev中的一些兼容性问题，如对于GBK编码的支持以及特定opcode和指令格式的处理，作者对源代码进行了针对性的修改。具体来说，修改了判断有效字符范围的代码，更新了mjs文件的处理逻辑，以及调整了mjo文件的读取规则，以适应GBK编码的文本。这些修改不仅提升了工具的兼容性，也使得Majiro引擎在处理非日文编码的文本时更加灵活。
最后，作者提供了其编译的Mjdev版本的下载链接，以供有需要的开发者使用。链接中包含了针对GBK编码优化的版本，需要在bash环境下执行。针对原版代码中存在的指令生成顺序问题，作者已进行了修正，以避免不必要的调试工作。
.jpg)
