在仿真途中遇到了一个 DSPLib.py 文件，每次仿真都会加载一次，开头明摆着写着 VPICRYPTV2 ；要是它放在内部加载，恐怕也不会注意到，放在用户可见的目录中加载，这有些引发好奇心了，于是看看到底从哪里加载到源码的。下面记一下查找解密位置的流程：

首先，是个 .py，加载后是 module，先看看加载流程，发现了一个内置库 vpi_tc_internal

它没有 __file__ 字段，说明其是内置或故意隐藏的，应该嵌入在解释器内部；先观察执行效果，它使用 check_header 方法检查数据头部，另一个 init_module 方法从 module spec 加载，解密并初始化这一模块，这是 spec 的结构：

不过，spec 被初始化后，已经编译为字节码了，没有 __source__ 字段：

劫持 exec 会导致相关的 scipy 组件初始化出错，看起来没有很好的方法，并且无法保留注释等内容，接下来看下究竟是哪里进行了解密。

仿真由界面调用启动，界面程序为 pde.exe，命令行仿真程序为 ptcl.exe，在 System Informer 下可以看到创建的进程：

IDA 静态分析 ptcl.exe，搜索 VPICRYPTV2，寻找到一个字符串，发现字符串初始化结构：

这是一个字符串对象的初始化过程，atexit 是销毁逻辑，初始化时将固定位置的字符串复制到这一对象的数据区，IDA 中暂时标注为 VPICRYPTV2_string 对象；

接下来，寻找对象引用，按 x 找交叉引用，能够找到两个主要使用点，有一个较短，再向上找引用是 check_header 的逻辑，显然，并无解密逻辑；另一个伪代码较长，后续流程较为复杂，应该是要排查的内容：

上来就是一个字符串比较，清晰明了，进入这一分支的是解密流程，跳过压缩文件相关的逻辑，要看的是 VPICRYPTV2 解密逻辑：

排查这些步骤中的函数，标注了 get_VPICRYPTV2_key_string，其内部逻辑执行了混淆的 blowfish 秘钥构建，密钥是由 off_141A4A5E8 位置的三个字符串交叉生成的，这三个原始字符串似乎是开发人员随手复制的，例如 Error: no file existing，重新混合组合成二进制秘钥字符串，下面是偏移处的数据：

不过，这里的逻辑有些难以辨识，这一 get_VPICRYPTV2_key_string 函数给了一个明确的返回值，考虑直接动态调试查看秘钥情况。

由于 ptcl.exe 由 pde.exe 界面程序创建进程，先调试 pde.exe，断点设置在创建进程相关接口：

和 ptcl.exe 相关的执行停止在 CreateProcessW，对于 CreateProcessW 有六个参数：

在 x64 调用约定中，前 4 个参数在寄存器（RCX, RDX, R8, R9），后面的参数在栈上。

RDX 指针位置的数据的确是 ptcl.exe 相关的命令行指令，从 System Informer 可以看到环境变量和运行参数，使用 x64dbg.exe 启动 ptcl.exe 开始调试：

x64dbg 跳过 pde.exe 的 CreateProcessW 进程创建，IDA 内找到 ptcl.exe 的断点在 ret 之前：

例如 .text:0000000141240966 地址，由于 IDA 静态时默认起始地址 0x140000000，对应的实际运行时断点位置为 ptcl.exe + 0x14124F5D2 - 0x140000000；

x64dbg 下 Ctrl+G 在 x64dbg.exe 中导航到这一地址位置设置断点，F9 继续运行 ptcl.exe 和 pde.exe 使二者正常完成初始化 HTTP 通信，开始读取文件和解密（bp fopen 会无法初始化，还是需要手动设用户段的断点）：

停止在 00007FF7A9D90966 (IDA内0x141240956附近)，RAX 内部地址为 000000FEC42FE638，是函数返回的目标字符串对象指针，RAX 内存镜像 dump 000000FEC42FE638：

前 8 字节为 50 B9 FC 43 D2 02 00 00，转换成地址是：0x000002D243FCB950，这是数据指针；偏移 16 字节（+0x10）处为 52 00 00 00 00 00 00 00，十六进制 0x52 = 十进制 82，说明 Blowfish 算法使用的密钥长度是 82 字节。

去数据区寻找秘钥 dump 0x000002D243FCB950：

可以看到秘钥为

69r114o114:32n111 102i108e32e120i115t105n10380r111f105l101 98a10068i115k32f117l108

看起来仍然是混淆的，这并不是个好现象，不过秘钥指针传递到了 v24，一定是被后续使用到。

继续静态分析，看后续代码 blowfish_start_decrypt，v24 传递给函数第四个参数，函数内 a4 就是这一秘钥字符串：

sub_14123DBC0 使用 a4 字符串赋值给了 v13，v13 在下一个 blowfish_decrypt_init 函数中被处理为 Blowfish 解密需要的 S-Box 和 P-Array，存入a1 + 0x68(104)和a1 + 0x24(32)：

之后 blowfish_crypt_exec 使用了 a1 中储存的 S-Box 和 P-Array，进行分块解密，返回值 v11 为数据长度，这是最终解密操作的核心：

数据写入到前面申请的地址空间 v12 = (void *)operator new(*a3 - 4);，v12 作为第五个参数传递到函数中：

因此，在上一级函数 blowfish_start_decrypt动态调试，返回 v12 前打一个断点，读取 v12(R12) 即为解密后的数据，a1(RDI) + 0x68 和 a1(RDI) + 0x20 的两个偏置位置则为 S-Box 和 P-Array 数据，现在继续动态调试：

停止在 00007FF7A9D9F6F6，对应 IDA 的 .text:000000014124F6F6，做内存转储 dump R12，直接报错解密后数据即可。

查看对应的 RDI + 0x20 和 RDI + 0x68 地址位置的 S-Box 和 P-Array，RDI + 0x20 可以直接转储，18 个 P-Array 秘钥连续储存，RDI + 0x68 的 S-Box 数据是字符串对象，同理找到其数据区地址 0x000000FEC42FE760：

获取数据区内容 dump 0x000000FEC42FE760：

有了 S-Box 和 P-Array，也可以手动做 Blowfish ECB 解码获取数据

这样就能离线解码出目标文件了：

总之这一代码库的加密部分，使用 Blowfish ECB 已经是加密的老一辈了，而且代码库也没有更多的做混淆或检测；寻找解密部分还算顺利，这次就说到这吧

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！