首页 > 代码库 > JAVA字节码修改异常分析

JAVA字节码修改异常分析

源class反编译后代码如下:

 public boolean isExpiring()  {    if ((this.timestamp == null) || (this.timestamp.length() <= 0)) {      return true;    }    boolean isExpiring = false;    try {      SimpleDateFormat df = new SimpleDateFormat(        SSOAuthConfig.getAuthDataDateFormart());      Date date1 = df.parse(this.timestamp);      long time1 = date1.getTime();      long time2 = System.currentTimeMillis();      long diffMilSecs = time2 - time1;      Log.i(TAG, "diffMilSecs: " + String.valueOf(diffMilSecs));      if (diffMilSecs > 0L)        isExpiring = true;    }    catch (Exception e) {      isExpiring = true;      Log.e(TAG, "parse  Date Exception", e);    }    return isExpiring;  }

现在要把

if (diffMilSecs > 0L)
这一行改成
if (diffMilSecs > -100000L)
在javaBite中修改之后文件异常,不能反编译。(按理来说只要常量池里添加一个常量,并在此处引用即可。改动非常小,不会有什么影响,而且之前class文件修改都是正常的,为什么这次不行了呢?)

对比正常class文件反编译和异常class文件使用ida反编译结果如下:

修改过的文件,反编译时报错,但IDA能显示出异常的位置。
再看一下异常的反编译:


我们可以看到.stack和.end stack之间的区域异常。单独的一个class文件,还没有运行,怎么会有stack信息呢?IDA这里的stack到底代表什么呢?我们的修改后的class文件反编译时异常和这些有什么联系么?


看下以下描述
StackMapTable Attribute在J2SE 6中引入,记录了类型检查时需要用到的信息,如字节码的偏移量、局部变量的验证类型、操作栈中的验证类型,用于类型检查过程。在Code Attribute只能包含一项StackMapTable Attribute,记录所有当前Code Attribute中的验证信息。

参见Java字节码(.class文件)格式详解(二)

到底和这个有没有关系呢?对比.class文件格式里的
StackMapTable 这个段的字段定义,可以解析出ida所示的.stack和.end stack里的信息。具体就不写了,过程不复杂,但是手动解比较烦琐,对照结构体一项一项的比就好了(像IDA .stack里的
cn/com/zte/android/securityauth/model/SSOAuthResultData这种信息,就是在class文件的常量池里的一个引用)。目前也没有找到什么有用的工具详细解析stackmaptable。

总结:j2se 6之后的编译器编译的class文件修改起来比较麻烦,要考虑StackMapTable的帧校验。如果能反出源码,最好反出源码修改,再编成class文件。如果不能,只能找工具帮忙了,至于手动写StackMapTable,还是不要考虑了吧。

JAVA字节码修改异常分析