EOFException - getResPackagesFromApk()

[udhos]

brut.androlib.AndrolibException: Could not decode arsc file Is this issue known?

Information

1. Apktool Version (apktool -version) - 2.3.0
2. Operating System (Mac, Linux, Windows) - LINUX
3. APK From? (Playstore, ROM, Other) - Other, generated by me with gomobile tool

Stacktrace/Logcat

$ java -cp ~/Downloads/apktool_2.3.0.jar brut.apktool.Main d invader.apk 
I: Using Apktool 2.3.0 on invader.apk
I: Loading resource table...
Exception in thread "main" brut.androlib.AndrolibException: Could not decode arsc file
	at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:52)
	at brut.androlib.res.AndrolibResources.getResPackagesFromApk(AndrolibResources.java:575)
	at brut.androlib.res.AndrolibResources.loadMainPkg(AndrolibResources.java:72)
	at brut.androlib.res.AndrolibResources.getResTable(AndrolibResources.java:64)
	at brut.androlib.Androlib.getResTable(Androlib.java:68)
	at brut.androlib.ApkDecoder.setTargetSdkVersion(ApkDecoder.java:214)
	at brut.androlib.ApkDecoder.decode(ApkDecoder.java:109)
	at brut.apktool.Main.cmdDecode(Main.java:160)
	at brut.apktool.Main.main(Main.java:72)
Caused by: java.io.EOFException
	at com.google.common.io.LittleEndianDataInputStream.readAndCheckByte(LittleEndianDataInputStream.java:2
26)
	at com.google.common.io.LittleEndianDataInputStream.readUnsignedShort(LittleEndianDataInputStream.java:
100)
	at com.google.common.io.LittleEndianDataInputStream.readShort(LittleEndianDataInputStream.java:188)
	at brut.util.DataInputDelegate.readShort(DataInputDelegate.java:49)
	at brut.androlib.res.decoder.ARSCDecoder.readEntry(ARSCDecoder.java:239)
	at brut.androlib.res.decoder.ARSCDecoder.readTableType(ARSCDecoder.java:231)
	at brut.androlib.res.decoder.ARSCDecoder.readTableTypeSpec(ARSCDecoder.java:156)
	at brut.androlib.res.decoder.ARSCDecoder.readTablePackage(ARSCDecoder.java:118)
	at brut.androlib.res.decoder.ARSCDecoder.readTableHeader(ARSCDecoder.java:80)
	at brut.androlib.res.decoder.ARSCDecoder.decode(ARSCDecoder.java:47)
	... 8 more

Steps to Reproduce

$ java -cp ~/Downloads/apktool_2.3.0.jar brut.apktool.Main d invader.apk

Frameworks

If this APK is from an OEM ROM (Samsung, HTC, LG). Please attach framework files (.apks that live in /system/framework or /system/priv-app) NOT APPLICABLE

APK

If this APK can be freely shared, please upload/attach a link to it.

https://storage.googleapis.com/apagueme/invader.apk

Questions to ask before submission

1. Have you tried apktool d, apktool b without changing anything? YES
2. If you are trying to install a modified apk, did you resign it? Not a modified APK.
3. Are you using the latest apktool version? YES

[iBotPeaches]

Confirmed. I replicate the issue.

[CunningLogic]

Can you reupload this apk?

[iBotPeaches]

invader.apk.zip

[iBotPeaches]

4year update. Still crashes.

[iBotPeaches]

This was resolved when I discovered what is either a misunderstanding of sparse resources or some optimization technique. In some resource pools you may list x items but have (x - c) where c is some random constant. It appears that some resources can be referenced across specs - so obfuscation/optimization techniques strip the duplicate from other specs. The count remains untouched, but AOSP doesn't care - it just reads chunks till there gone.

So this should have patched it - https://github.com/iBotPeaches/Apktool/commit/6a28621fcc8770a369caaf24d78bea337b23ccc5

Confirmed below.

➜  1656 apktool d invader.apk -f
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
I: Using Apktool 2.8.2-22eb80-SNAPSHOT on invader.apk
I: Loading resource table...
W: End of chunk hit. Skipping remaining entries (1) in type: mipmap
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /home/ibotpeaches/.local/share/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
➜  1656 

Sorry for taking a few years. I recently refactored the core ARSC/AXML parser and thus have a far better understanding of the spec and could more easily make sense of these issues.

Closing as resolved in 2.8.0/2.8.1