注册使用情况跟踪x86

时间:2017-06-24 16:40:32

标签: assembly x86 reverse-engineering cpu-registers

我有一个应用程序的汇编指令列表,我想知道哪些寄存器可以免费使用,以及在列表的任何索引处使用了哪些寄存器。

如何知道何时使用寄存器以及何时将其释放(可以再次使用)?我的目标是到达真正免费的寄存器。

这是我解决问题的假设,因为我对装配知识如此有限,所以听起来可能很愚蠢。

术语:读取(源),写入(目标)

  1. 将所有指令标记为每个寄存器的WRITES TO或READS FROM(使用http://ref.x86asm.net/coder32.html获取所有信息as described here)。
  2. 跟踪所有阅读和阅读将操作写入寄存器并找出它可以自由使用的时间。例:
    • 寄存器X正在由5处的指令写入。
    • 正在通过8的指令读取寄存器X。
    • 寄存器X正在由15处的指令写入。
    • 我可以说,寄存器X不是在8-15之间被读取而是在15处被重新分配。这意味着它在指令8和15之间是空闲的,但是在5-8之间是忙的。
  3. 它能解决问题还是有意义?我也对其他解决方案持开放态度。

    评论后更新:

    我看到JMPS /调用/条件移动搞砸了所有这些。为了保证安全(安全=免费寄存器真的免费),做这样的事情怎么样:当我看到每个跳/呼/有条件移动到外面时,我将所有寄存器标记为"正在阅读&#34 ;哈罗德描述的最极端悲观假设。我相信在这种情况下我会得到更安全的结果,即使它不会很好,因为寄存器大部分时间都处于繁忙状态。您是否同意我的结果会以这种方式安全?

    说明

    • 1指令:写入注册X.
    • 3指令:有条件的JMP / MOV / CALL。
    • 5指令:写入注册X.
    • 8指令:从寄存器X读取。
    • 15岁的指示:写入注册X.

    结果

    • 在1-3之间:寄存器X正忙,因为我在3处将重新定位外部计为READ。
    • 3-5之间:注册X是免费的,因为不再阅读。
    • 5-8之间:寄存器X忙,因为在8处有读操作。
    • 8-15之间:注册X是免费的。

    更新2

    我会将应用程序拆分为基本块,其中每个块代表跳转(也是条件),调用和返回之间的一大块代码。跳转语句将是块的结尾。然后,假设所有寄存器在开始时都在使用,我将分析每个块。我可能会错过很多免费注册,但当我得到一个,我知道那个是真的免费注册=)

    更新3

    我仍在尝试根据反馈改进解决方案(感谢哈罗德)。

    我已经阅读了活体分析,据我所知,建议从应用程序结束到开始进行分析。但我不知道在编译程序集中应用程序的结束,如下面的评论中提到的停止问题,所以我将对未来的分支做另外的处理。

    1. 按照描述标记所有说明。读=源,写=目的地。条件移动计为读取到源并写入目标。
    2. 将所有指令分成块。使用任何条件或直接分支出口拆分它们。
    3. 将所有块相互链接,每个块都有may_continue_with容器,该容器包含指向它可能继续的分支的指针。
    4. 询问一个块是否在A索引处有一个寄存器X是空闲的。块检查在索引A之后是否首次访问寄存器X是读取还是写入操作。首先,它检查自己的指令,如果它没有找到在寄存器上运行的任何指令,它会向未来的分支询问相同的问题。 (未来的分支机构会进一步询问他们是否有任何访问寄存器X的指令)。该块返回:
      • false 如果未来分支的任何首先具有读取权限
      • true 如果未来分支的所有首先具有写入权限(只有一个分支不够,因为我们不知道哪个分支将被执行)。

1 个答案:

答案 0 :(得分:5)

第1步很简单,只需要很多实际工作(需要解析x86机器代码),有些库可能对此有所帮助。

由于控制流程,步骤2并不像听起来那么容易。在控制流程简单的假设下,活跃度分析是众所周知的问题。在这种情况下还有一些额外的问题。

  • 可以调用其输入寄存器尚未确定的过程。这主要是由于不幸的订购,处理程序深度优先减少了问题。但由于(相互)递归,因此不一定有任何顺序可以使这个问题不会出现。您可以进行过程间活性分析来解决这个问题。
  • 可以调用 unknown 过程(虚函数或通过函数指针显式调用)。除了做出最极端的悲观假设之外,我认为你不能做太多。
  • 即使是过程内控制流也可能是不可预测的,例如当switch被编译到跳转表时。实际上,并不能保证变量跳跃首先是过程间的,你可能大部分都认为......我真的不知道该怎么办。
  

然后我将分析每个块,假设所有寄存器在开始时都在使用。

这是一个巨大的浪费,通过适当的liveness analysis可以轻松避免。

相关问题