[carvingdbg] 设计的讨论

1. 讨论关于 open file 和 debug file

open file 是把一个档案从硬盘读取，把它进行反汇编，把结果顺序输出到 ListView 中。这种方式跟 IDA 或 w32dsm 类似，暂时没有包含调试功能

debug file 是未开发完成的新部份，它是 CreateProcess 以后，以 debugger 身份对目标进行 ReadProcessMemory，把目标程序的实际内存进行反汇编，输出固定行数的 ListView 中，并可以放断点和调试。这种方式跟 OD 类似，假如程序在运行时修改指令 (smc) ，debugger 中会即时反映出来。

现在的开发进度以反汇编部份为主，先完成一个正确无误并且速度理想的反汇编核心。现在的源码，反汇编的速度是快的，但是把 ListView 加入 item时是非常缓慢，这一步是主要浪费时间的原因。当反汇编大型档案时 (我使用我写的 crackme6.exe 来测试，它的体积是 7.14 MB) ，内存使用量极大，导致反汇编核心的内存开始抄 (swap)到硬盘上，速度下降。 将来的设计，可能使用像 IDA 的方式，把反汇编出来的数据有系统地储存在硬盘的档案里 ( IDA是 database 档 )，这样便可以解决有限内存的问题。

我在开发 debug file 那部份时，发现了一个问题，假如CreateProcess 后debugger 在段序的 Entry point 断下，开始对 Entry point 地方进行第一次反汇编，那幺我们怎样可以肯定在 Entry point 那一行之上的指令是从那里开始进行分隔 ?

例如 :

1006420 :  push ebp
1006421 :  mov ebp, esp
…

我们的 Entry point 是 1006420，我们从指令的反汇编得知这条指令的长度，继而向下找出下一条指令，是位于 1006421，继续反汇编。 那幺，位于 Entry point 1006420 之上的指令，我们应该从那个位置开始反汇编 ?  ( 从 1006419 还是 1006418 ?  或是那里 )

解决是方法，可以是在反汇编 Entry point 的时候，便把整个程序的所有跳转和位置转移 ( jmp, jx, call ) 都进行跟踪，找出所有相关的程序段，使整个程序的所有指令位置都被检出来，这样便能得知 Entry point 之上的指令从那里开始反汇编

这种做法需要考虑的问题，是将来面对令花指令时的能力，使用这种方法很有可能被花指令扰乱，使 debugger 误以为程序的某一部份是 data，不是指令
(现时 OD 也有这种程况 )

大家有甚幺想法 ?

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！