關于brut.androlib.res.decoder.XmlpullStreamDecoder$1.parseManifest 分析

接著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.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給讀者去驗證。

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容