zoukankan      html  css  js  c++  java
  • 手工脱壳之 ASPack压缩壳【随机基址】【重定位表加密】

    一、工具及壳介绍

     使用工具:Ollydbg,PEID,ImportREC,LoadPE

    ASPack壳:

    二、脱壳

    1.ESP定律

    ASPack壳明显多了两个区段:

       

       

    开头是pushad,可以采用ESP定律脱壳。

       

       

    esp下硬件断点:

       

       

    断下来的地方单步几步,来到OEP。

       

       

    第一个call是VC特征初始化安全Cookie,确认是OEP。

       

       

    查看模块基址,exe基址,用OllydbgDump Dump下进程内存。

       

       

    使用ImportREC修复IAT

    完成后双击运行。

    2.逆向重定位加密 

    双击发现运行不起来,推测是随机基址的问题。PEID查看重定位表数据。

    重定位表被破坏:

    目标:找到加密重定位表的代码块,进行逆向分析。

    操作:通过重定位表数据 顺藤摘瓜。

    加壳的区段信息脱壳后的区段信息对比:

       

    可见重定位表的映射内存RVA是一样的。

    OD重新加载原程序。获取加载基址。 

       

    0x12F000+16000 == 0x1306000。

    此处是重定位表,下硬件访问断点:

       

       

    首先断下处,根据内存框的数据一直在变动,判定解压数据的地方:

       

       

    跳过解压循环:

       

    F9后,接着断下。

       

       

    查看内存框内 重定位表内存数据 已解压完毕,但明显不是重定位表数据。

    根据ECX,推测此行代码是 把修改完成后重定位表 覆盖进来。

       

    查看 重定位表内存数据 正确。

     

    继续F9,接下来就是修复exe重定位的代码块了:

       

    步过发现此代码块还进行加密重定位表数据

    所以推测 exe代码的重定位修复加密重定位表 的操作都在此代码块。

       

       

    跟踪分析,解析代码的流程。 

       

       

       

       

       

    操作:NOP掉这条指令,再重复以上脱壳步骤。

    查看重定位表数据:正常

     

    双击运行发现还有错误。

       

       

    显而易见,PE加载器并没有修复重定位,用LoadPE查看数据目录表信息。

       

       

    重定位RVA并不是0x1600,可见APSack壳并不是采取自我代码修复重定位,

    而是自己构造重定位表,让PE加载器修复自我,再另行修复exe的重定位。

    修改回来即可。

       

       

    成功运行:

       

       

    个人总结:相比前面的ESP定律脱壳,感觉后面的重定位比较关键。

    附件:

    ASPack.exe

    KIDofot

  • 相关阅读:
    axios中put和patch的区别(都是update , put是需要提交整个对象资源,patch是可以修改局部)
    父子组件传值
    springboot+mybatis 配置sql打印日志
    spring cloud eureka
    springAop
    java线程dump分析工具
    02.java并发编程之原子性操作
    01线程的一些方法
    Spring validator常用注解
    Idea报错Command line is too long
  • 原文地址:https://www.cnblogs.com/KIDofot/p/8597000.html
Copyright © 2011-2022 走看看