接着APKTOOL_DUMMY_ (1) , 如下图:
在通过源码debug后,结论:
Apktool2.4.1 brut.androlib.res.decoder.AXmlResourceParser.getAttributeName() 方法,里面的逻辑有问题,在本样本APK中,问题的原因是在于,从resourceIDs 里面拿不到下标入图所示的ID值, 进而导致getAttributeNameResource() 的值为0,从而导致value为null,即抛出上图异常。
2.4.1Debug 010查看下面给出这块代码在相邻2版本的源码:
2.4.0 2.4.1 2.5.0扩展:工作关系 样本APK是合租的CP方发过来的APK,不方便发上来, 不过经过我的查看,理论上是CP经过了一些特殊的处理,导致我这边解包报错。
在经过ApkTool 2.4.0 或 Apktool 2.5.0 回编的APK都能给ApkTool 2.4.1 解包通过010对比AndroidManifest.xml
2.4.1不能解包 2.4.1能解包 正常的APK包不难发现,因为缺少了16844146,16844147,16844154 是导致问题的关键, 然后对比正常APK可得知这些值都是固定的(用到的模板是AndroidResource.bt 更新日期是2017年,模板AndroidManifest.bt更新时间是2019,都有做对比),查看模板,发现模板AndroidResource.bt 代码量更多(主要是添加了映射 即上图所示)
通过框架文件1.apk 可知
再附上一张图
AndroidMainfest.png
根据上面整理可得:
因为APK的清单文件ResourceChunk的ResourceIds数组里面缺失了16844146(compileSdkVersion)省略...
在用ApkTool2.4.1进行解压的时候,由于不满足条件 value.length() !=0 && !android_ns.equals(getAttributeNamespace(index)) 所以需要拿到对应的ResourceId去框架文件1.APK里面去拿到值(compileSdkVersion),因为缺少了相对应的值(导致抛出NPE异常解包失败)。通过分析不同版本的getAttributeName()方法,在2.4.1的版本中的更改可能导致解包因上诉解包失败(实际上,compileSdkVersion已经通过从StringChunk中拿到了),所以在2.5.0中明确:只有在StringChunk拿不到,才根据ResourceId值去框架文件中拿到对应的Value。
至此,文件分享完毕。 之后可能会根据这个规律, 想办法出一个APK给读者去验证。
网友评论