首页 > 代码库 > 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字节码修改异常分析
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。