接著APKTOOL_DUMMY_ (1) , 如下圖:
在通過源碼debug后,結論:
Apktool2.4.1? ?brut.androlib.res.decoder.AXmlResourceParser.getAttributeName() 方法,里面的邏輯有問題,在本樣本APK中,問題的原因是在于,從resourceIDs 里面拿不到下標入圖所示的ID值, 進而導致getAttributeNameResource() 的值為0,從而導致value為null,即拋出上圖異常。
下面給出這塊代碼在相鄰2版本的源碼:
擴展:工作關系? 樣本APK是合租的CP方發過來的APK,不方便發上來,? 不過經過我的查看,理論上是CP經過了一些特殊的處理,導致我這邊解包報錯。
在經過ApkTool 2.4.0 或 Apktool 2.5.0 回編的APK都能給ApkTool 2.4.1 解包通過010對比AndroidManifest.xml
不難發現,因為缺少了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給讀者去驗證。