hacktricks/crypto-and-stego/cryptographic-algorithms/unpacking-binaries.md

5.1 KiB
Raw Blame History

{% hint style="success" %} 学习和实践 AWS 黑客技术:HackTricks 培训 AWS 红队专家 (ARTE)
学习和实践 GCP 黑客技术:HackTricks 培训 GCP 红队专家 (GRTE)

支持 HackTricks
{% endhint %} {% endhint %}

识别打包的二进制文件

  • 缺少字符串:常见的情况是打包的二进制文件几乎没有任何字符串。
  • 很多 未使用的字符串:此外,当恶意软件使用某种商业打包工具时,常常会发现很多没有交叉引用的字符串。即使这些字符串存在,也并不意味着二进制文件没有被打包。
  • 你还可以使用一些工具来尝试找出用于打包二进制文件的打包工具:
  • PEiD
  • Exeinfo PE
  • Language 2000

基本建议

  • 从底部开始 在 IDA 中分析打包的二进制文件 并向上移动。解包器在解包代码退出时退出,因此解包器不太可能在开始时将执行权传递给解包代码。
  • 搜索 JMPCALL寄存器内存区域。还要搜索 推送参数和地址方向的函数,然后调用 retn,因为在这种情况下,函数的返回可能会调用在调用之前刚推送到堆栈的地址。
  • VirtualAlloc 上设置 断点,因为这会在内存中分配程序可以写入解包代码的空间。使用“运行到用户代码”或使用 F8 获取执行函数后 EAX 中的值,然后“在转储中跟踪该地址”。你永远不知道这是否是解包代码将要保存的区域。
  • VirtualAlloc 的参数值为 "40" 意味着可读+可写+可执行(一些需要执行的代码将被复制到这里)。
  • 在解包 代码时,通常会发现 多个调用算术操作 和像 memcopyVirtualAlloc 的函数。如果你发现自己在一个显然只执行算术操作和可能一些 memcopy 的函数中,建议尝试 找到函数的结束(可能是 JMP 或调用某个寄存器) 至少找到 最后一个函数的调用,然后运行到那里,因为代码并不有趣。
  • 在解包代码时 注意 每当你 更改内存区域,因为内存区域的变化可能表示 解包代码的开始。你可以使用 Process Hacker 轻松转储内存区域(进程 --> 属性 --> 内存)。
  • 在尝试解包代码时,知道你是否已经在处理解包代码的好方法(这样你可以直接转储它)是 检查二进制文件的字符串。如果在某个时刻你执行了跳转(可能更改了内存区域),并且你注意到 添加了更多字符串,那么你可以知道 你正在处理解包代码
    然而如果打包器已经包含了很多字符串你可以查看包含“http”这个词的字符串数量并查看这个数字是否增加。
  • 当你从内存区域转储可执行文件时,可以使用 PE-bear 修复一些头部信息。

{% hint style="success" %} 学习和实践 AWS 黑客技术:HackTricks 培训 AWS 红队专家 (ARTE)
学习和实践 GCP 黑客技术:HackTricks 培训 GCP 红队专家 (GRTE)

支持 HackTricks
{% endhint %} {% endhint %}