我要评论下图是我的机器中这个call了api的call的地址. 在api返回处bpx(这个call的下一行).
点击run
现在在错误entry 5e9c98上下hardware bpx on write然后点击run.当在那儿写入时将被断下.
你可以看到在前面一行保存着错误值.后面指出这个错值从[ebp-394]处来.所以在转储窗口中选择goto expression ebp-394. 那儿你将会看到这个值.下brekpoint hardware on access.
如果我按下运行键，我将看到无论值是好是坏都在这一行被保存.看附近有一个call bpx它.
你可以看到这是关键call.因为当它结束时eax带着稍后将写入的值. 我测试了这个call里的每一个跳转(只有5到6个,通常都是这样):
00df4b68 /75 03 jnz short 00df4b6d
00df4b79 /75 07 jnz short 00df4b82
00df4b8d /74 0c je short 00df4b9b
00df4b92 /74 1b je short 00df4baf
00df4b99 ^75 f4 jnz short 00df4b8f
胜利者是df4b8d处的跳转. 正如我先前所说的在所有的armadillos里都是一样的,所以当我们在脱其它armadillo时,通过跟踪这些代码我们可以很容易发现这个好跳转.
00df4b8d /74 0c je short 00df4b9b
它必须永远跳转,所以我们做如图修改:
清除bpx点击run. (记住清除hardware bpx). 当程序走到我们修改为死循环的指令那儿时输入表已经修复了,再也没有坏值了. 然后它在子进程的oep处停下.在纸上写下magic jump的值(eb 0c),记住.
我们将要重复那些步骤.当我们走到上次我们unhook 子进程那一步时,我们将要在magic jump处设置一个 infinite loop代替在api上设置.
在那儿从父进程处unhook子进程,然后它将在magic jump处死循环.
附加子进程,按 run, 然后停止(f12). 它将停在magic jump.
现在还没有任何改变,因为magic jump还没起作用.把它改回先前的值(eb 0c).
如果我们运行程序,它将停在oep,而且输入表也很完美和完整.现在我们可以利用这个进程用import reconstructor去修复在第一部分中转储的程序了.
所有的值都是好的.最后那几个是指向dll的.
那些值指向exxxxx,如果我们看看view-memory我们可以得知那是dll.
现在我们要用一下import reconstructor.
打开import reconstructor在"attach to an active process"对话框选择这个进程.
装载这些dll需要很长一段时间.当完成后写下oep的值,表的起始地址值和表的长度,不要按iat autosearch.
如图在import reconstructor中那些值是这样计算的:你在纸上写下的值-image base. 比如: oep=534e90, image base=400000, 534e90- 400000= 134e90. rva也一样 (表的起始地址值).
现在按get imports. 所有的entries都修复了.
发表评论