Closed GoogleCodeExporter closed 9 years ago
hmmm.
(for me)
https://github.com/android/platform_frameworks_base/commits/6e2fb587d71631bd29fd
b844a6451d68e2144337/include/androidfw/ResourceTypes.h
Never seen it fail this early before. Its looking for the header for a familiar
chunk and not finding it. Looking at the last few commits to AOSP, I don't see
anything that has directly affected this chunk data, so not sure at the moment.
Original comment by connor.tumbleson
on 6 Aug 2014 at 7:41
Issue 680 has been merged into this issue.
Original comment by connor.tumbleson
on 26 Sep 2014 at 11:43
This issue is now top priority. It seems the newest updates of Google apps are
breaking on this.
Data shifted somewhere and is breaking things. AOSP isn't helping locate this
so its gonna be a fun weekend.
Original comment by connor.tumbleson
on 26 Sep 2014 at 11:45
[deleted comment]
Is there a workaround for this issue? Thx.
Original comment by pzhang9...@gmail.com
on 30 Sep 2014 at 9:39
#5 - Not yet, I do have a commit in process with good progress though. All
updates regarding it will be posted in this issue.
(Now that you've responded you will get updates about changes). Others may
"star" the issue to receive updates instead of responding.
Original comment by connor.tumbleson
on 30 Sep 2014 at 9:55
I'm hitting the same problem on another Android application provided by Google.
Please let me know if I can help out in fixing this issue by testing possible
fixes.
Original comment by nico.de....@gmail.com
on 2 Oct 2014 at 9:14
Original comment by connor.tumbleson
on 2 Oct 2014 at 7:13
[Update for myself - notes]
PhoneSky and GooogleSearch have the exact problem. After the first
ResChunk_header (after we pull table strings, and package count). We iterate
into the first package and get id / name of package successfully.
We pull typeStrings, lastPublicType, keyStrings and lastPublicKey perfectly
fine. The problem comes when trying to pull the typeNames * specName
ResStringPools.
The skipIntCheck we have fails, like it should. In the case of Phonesky, the
pointer is at 0x5B5C68 looking for 0x01001C. When in reality the header it is
looking for is located at 0x5B5D40, 0xD8 (216) away.
Manually setting the correct pointer as you debug fixes each string block, one
by one. So just setting the correct pointer fixes the problem completely. The
problem is understanding why there is this extra data in only new applications
and why its not documented anywhere:
https://github.com/android/platform_frameworks_base/blob/master/include/androidf
w/ResourceTypes.h#L177
Building smaller applications to reduce overhead in hex editing HUGE google
apps cannot replicate this. L apks, wear apks, etc. Creating any sort of check
is useless since the data ranges in size and location constantly. We have to
figure out what this new data is in between the ResTable_package and before the
ResStringPool_header starts.
Running PhoneSky again and comparing it to the ResTable_package
https://github.com/android/platform_frameworks_base/blob/master/include/androidf
w/ResourceTypes.h#L801 we get these variables correctly. So the start of the
ResTable_pacakge can be pulled without error on these apks.
128 / 0x7F
com.android.vending
typeStrings = 288
lastPublicType = 15
keyStrings = 500
lastPublicKey = 3000
My guess is that our assumption of all ResTable_package having an immediate
ResStringPool right after is incorrect. We assume it, but AOSP lists 3 other
possibilities that can be in that header "type" positon.
enum {
RES_NULL_TYPE = 0x0000,
RES_STRING_POOL_TYPE = 0x0001,
RES_TABLE_TYPE = 0x0002,
RES_XML_TYPE = 0x0003,
....
}
Assuming something other than a StringPool our first header after the
ResTable_package would be RES_NULL_TYPE, since 0x5B5C68 returns 0x0000. Though
this is just a theory since the struct of RES_NULL_TYPE, RES_TABLE_TYPE &
RES_XML_TYPE are unknown to me currently.
Original comment by connor.tumbleson
on 5 Oct 2014 at 5:01
I believe this is fixed as of this:
https://github.com/iBotPeaches/Apktool/pull/92
Just needed to sleep on it. It works for the broken apks provided. I'm going to
run a few more tests, then slice an RC2 release today if all goes well.
Original comment by connor.tumbleson
on 5 Oct 2014 at 5:23
https://github.com/iBotPeaches/Apktool/commit/0912ac6323a51bb9db08793b9b30386bd1
073721
Original comment by connor.tumbleson
on 5 Oct 2014 at 6:20
Yay!
Original comment by archon810
on 5 Oct 2014 at 7:10
Can we download the updated version somewhere?
Original comment by archon810
on 5 Oct 2014 at 8:18
Tried rc2. Got a crash here: https://gist.github.com/a5a2c68b8a722dd5f7c8.
APK is here:
http://www.apkmirror.com/apk/google-inc/google-play-newsstand/google-play-newsst
and-3-3-2-apk/.
Original comment by archon810
on 6 Oct 2014 at 1:05
tried RC3 with SystemUI.apk out of samsung SGS5 build here:
https://dl.dropboxusercontent.com/u/14028045/SystemUI.apk
got this which i think is the same problem?
C:\Dev\apktool>java -jar apktool.jar d -f c:\dev\systemui\systemui.apk
I: Using Apktool 2.0.0-RC3 on systemui.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: C:\Users\Michael\apktool\framework\1.apk
Exception in thread "main" java.lang.ClassCastException:
brut.androlib.res.data.value.ResStringValue cannot be cast to
brut.androlib.res.data.value.ResAttr
at brut.androlib.res.decoder.ResAttrDecoder.decode(ResAttrDecoder.java:36)
at brut.androlib.res.decoder.AXmlResourceParser.getAttributeValue(AXmlResourceParser.java:369)
at org.xmlpull.v1.wrapper.classic.XmlPullParserDelegate.getAttributeValue(XmlPullParserDelegate.java:69)
at org.xmlpull.v1.wrapper.classic.StaticXmlSerializerWrapper.writeStartTag(StaticXmlSerializerWrapper.java:267)
at org.xmlpull.v1.wrapper.classic.StaticXmlSerializerWrapper.event(StaticXmlSerializerWrapper.java:211)
at brut.androlib.res.decoder.XmlPullStreamDecoder$1.event(XmlPullStreamDecoder.java:83)
at brut.androlib.res.decoder.XmlPullStreamDecoder.decode(XmlPullStreamDecoder.java:141)
at brut.androlib.res.decoder.XmlPullStreamDecoder.decodeManifest(XmlPullStreamDecoder.java:153)
at brut.androlib.res.decoder.ResFileDecoder.decodeManifest(ResFileDecoder.java:134)
at brut.androlib.res.AndrolibResources.decode(AndrolibResources.java:296)
at brut.androlib.Androlib.decodeResourcesFull(Androlib.java:131)
at brut.androlib.ApkDecoder.decode(ApkDecoder.java:101)
at brut.apktool.Main.cmdDecode(Main.java:165)
at brut.apktool.Main.main(Main.java:81)
Original comment by Michael....@gmail.com
on 16 Dec 2014 at 10:59
[deleted comment]
Got exactly same problem and same errors one by one as Michael got with
Samsung Note 4 when trying to decode SystemUI.apk by using RC3.
Original comment by Aviron...@gmail.com
on 12 Jan 2015 at 5:41
i´ve the same issue, windows 8.1 and the last version of apktool, i tried with
apkmanager and same result. Please help us! :(
Original comment by alberto....@tuapli.com
on 15 Feb 2015 at 3:38
[deleted comment]
Funny thing is if you rename any of the resources xml files to
"AndroidManifest.xml" and just zip this xml file as an apk then the apktool
will decode it :)
Original comment by bastanij...@gmail.com
on 19 Feb 2015 at 4:52
Original issue reported on code.google.com by
archon810
on 6 Aug 2014 at 7:08