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，还是不要考虑了吧。