逆向工程 - 在 aarch64 Hi3559AV 目标上反转 uboot 问题 - 吾爱随笔录

逆向工程艾达拆卸二元分析手臂

2021-07-10 22:42:41

我正在尝试为 ARM aarch64 Hi3559AV 目标反转 uboot。

我已经转储了二进制文件 uboot.bin.gz，并将它加载到 IDA 中的正确地址。IDA 似乎在 0x10 的偏移处看到了很多字符串（可能还有一些数据）。

我已经从目标转储了 RAM，并确认代码确实位于正确的地址，字符串/数据也是如此。这是与位置无关的代码，因此所有内容都在偏移量处，而不是硬编码地址。所以这让我很困惑。仍然在学习，所以我相信更有经验的人确切地知道为什么会这样。

我可以解决这个问题，但我正在使用 gdb-multiarch 在 qemu 调试上运行部分代码。当然不是来自入口点的完整 uboot 代码，因为它会在硬件访问等时失败。所以我使用 gcc 来制作一个存根程序，确保 uboot 数据以正确的内存地址结束，我可以用正确的方式调用目标函数数据/参数。

这对于某些功能来说很好，但我正在查看的功能不会在内存中产生预期的数据输出，只是空白。另外就像 IDA 一样，当它打印字符串时，它们被 0x10 偏移，所以是错误的。

任何建议为什么会这样？

这是一个 SHA 函数，虽然该板确实支持硬件加密（在 qemu 上不起作用），但代码没有显示使用它的迹象。这也不能解释字符串/数据偏移问题。

目标板是否使用了某种硬件寻址模式而不是我没有复制？

我不能在 uboot 启动代码 WriteStatusReg(ARM64_SYSREG(3, 0, 4, 0, 1), v29); （不是说这与记忆有关，只是一个例子）。

或者它可能是某种 .text 段或对齐的东西，IDA 没有正确执行，qemu 也没有，因为我只是直接跳到一个函数。毕竟这是一个裸机二进制图像。

欢迎任何建议或指点。如果我没有正确表述问题或未包含所需信息，请接受我的道歉 - 很高兴根据需要进行澄清。

干杯

1个回答

好的，我想我终于明白了，uboot blob 中有一个部分代码重定位例程，它将它的一小部分复制到另一个内存区域，并具有不同的对齐方式。

这是在我们开始之前从uboot的启动代码中调用的。调用这个附加代码的 Init 函数，尽管在执行中看起来两个代码区域的元素都被使用了（而不仅仅是来自调用表）。在这种情况下，我们已经在启动时有一个较早的阶段，所以这是执行的 uboot 代码的第三部分。

这对 uboot 专家来说可能不是新闻。

因此，虽然我确实正确地验证了代码 + 数据确实在我预期的位置，但有些代码毕竟没有在该内存位置运行。Target 是我无法调试的嵌入式设备，所以以前不清楚。

一旦在 IDA 中手动执行此步骤（通过创建新代码段并手动加载附加文件），此新段中的字符串引用将正常工作。

我还没有用我的 qemu 冒险尝试过这个，但这似乎是朝着正确方向迈出的一大步。

如果将来有人看到这个并且它有帮助 - 太好了:) 搜索者可以找到的一些东西：

“IDA 字符串在错误的地方”“uboot 反汇编字符串”“uboot 内存重新分配”

更新：确实它确实在 qemu 中工作 - 正确执行的代码生成目标的哈希值。这非常有助于理解该目标使用的加密例程并提供我需要的解密。在 gdb 中逐步执行虚拟代码是很有启发性的。

这导致在此设备上进行更具挑战性的工作 - 从互联网订购更多咖啡用品.....

其它你可能感兴趣的问题