New odex files in Android 8.1.0

[argraur]

I get following error when trying to extract smali from odex file from Android 8.1.0:

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1889910856
    at org.jf.dexlib2.dexbacked.BaseDexBuffer.readSmallUint(BaseDexBuffer.java:53)
    at org.jf.dexlib2.dexbacked.OatFile$DexEntryIterator.next(OatFile.java:579)
    at org.jf.dexlib2.dexbacked.OatFile$DexEntryIterator.next(OatFile.java:570)
    at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48)
    at org.jf.baksmali.ListDexCommand.run(ListDexCommand.java:98)
    at org.jf.baksmali.ListCommand.run(ListCommand.java:83)
    at org.jf.baksmali.Main.main(Main.java:102)

[eg1122]

I have the same issue.

PS E:\Android\android-baksmali> java -jar baksmali.jar x -d framework-8.1/arm64 framework-8.1/oat/arm64/services.odex Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1889914952 at org.jf.dexlib2.dexbacked.BaseDexBuffer.readSmallUint(BaseDexBuffer.java:53) at org.jf.dexlib2.dexbacked.OatFile$DexEntryIterator.next(OatFile.java:579) at org.jf.dexlib2.dexbacked.OatFile$DexEntryIterator.next(OatFile.java:570) at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48) at org.jf.util.AbstractForwardSequentialList$1.next(AbstractForwardSequentialList.java:91) at java.util.AbstractSequentialList.get(Unknown Source) at org.jf.dexlib2.DexFileFactory.loadDexFile(DexFileFactory.java:129) at org.jf.baksmali.DexInputCommand.loadDexFile(DexInputCommand.java:144) at org.jf.baksmali.DisassembleCommand.run(DisassembleCommand.java:161) at org.jf.baksmali.Main.main(Main.java:102)

[sam3000]

baksmali doesn't support the oat file format changes in android 8.1.0 so it's not expected to work.

[lcweik]

you can use this repo to deodex android o's vdex file. https://github.com/lcweik/smali

[auras76]

not working

Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 1889914952 at org.jf.dexlib2.dexbacked.BaseDexBuffer.readSmallUint(BaseDexBuffer.java:53) at org.jf.dexlib2.dexbacked.OatFile$DexEntryIterator.next(OatFile.java:579) at org.jf.dexlib2.dexbacked.OatFile$DexEntryIterator.next(OatFile.java:570) at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48) at org.jf.util.AbstractForwardSequentialList$1.next(AbstractForwardSequentialList.java:91) at java.util.AbstractSequentialList.get(AbstractSequentialList.java:88) at org.jf.dexlib2.DexFileFactory.loadDexFile(DexFileFactory.java:129) at org.jf.baksmali.DexInputCommand.loadDexFile(DexInputCommand.java:144) at org.jf.baksmali.DisassembleCommand.run(DisassembleCommand.java:161) at org.jf.baksmali.Main.main(Main.java:102)

[lcweik]

send /system/framework/ and the vdex file that you need deodex to me.

[auras76]

here is odex 8.1 files. https://androidfilehost.com/?fid=817906626617953754 thanks.

[frap129]

+1 @JesusFreke

[trevorcobb]

@lcweik still can't figure out how to get my 8.1 framework deodexed either. tried your fork of baksmali. still giving same error. i understand from above it might be an issue with how OAT files are different in 8.1 though. any insight?

[LeeDroid-]

@lcweik I dont appear to be able to build your smali/baksmali for testing:

org.jf.dexlib2.analysis.MethodAnalyzerTest > testInstanceOfNarrowingAfterMove_dalvik FAILED org.junit.ComparisonFailure at MethodAnalyzerTest.java:250

org.jf.dexlib2.analysis.MethodAnalyzerTest > testInstanceOfNarrowingEqz_dalvik FAILED org.junit.ComparisonFailure at MethodAnalyzerTest.java:119

org.jf.dexlib2.analysis.MethodAnalyzerTest > testInstanceOfNarrowingNez_dalvik FAILED org.junit.ComparisonFailure at MethodAnalyzerTest.java:185

119 tests completed, 3 failed :dexlib2:test FAILED

FAILURE: Build failed with an exception.

[frap129]

@LeeDroid- Those are only tests. The smali.jar and baksmali.jar files are still built despite those failures. If you're hoping to test his source out on 8.1 dex files, it most likely will not work.

[lcweik]

@LeeDroid- you can use the release packages, or edit you project with my change. @trevorcobb you edit the vdex file with 010 editor or winhex, and remove the head before "dex\n035", you can get a dex file. zip the dexfile to a jar, you can get the origin frameworks jar.

[LeeDroid-]

My bad.. cheers guys! I'm working on 8.0 not 8.1

[frap129]

For those of us having problems, I want to point you too a little tool I found. https://github.com/anestisb/vdexExtractor extracts dex instructions from a vdex file and unquickens (deodexes/de-optimizes/whatver you want to call it) them, and outputs a dex file. No where near as featured as smali, but it does what it's supposed to very well. If you want to use this to create a vendor repo for building aosp (assuming at least @sam3000 does), I've modified extract_utils.sh to incorporate vdexExtractor for deodexing, which can be viewed at https://review.carbonrom.org/c/4910/. Currently tested on taimen's january blobs.

[razorloves]

Nice work @frap129 Your new 4914 change worked perfect on angler's january blobs. thanks

[LeeDroid-]

@frap129 vdexExtractor does what it says on the tin, however I'm not 100% convinced the results are what they should be.

Have you decompiled and compared a file deodexed by smali to a file deodexed by vdexExtractor? I don't have any specific examples to hand but the output is considerably different, many incorrect references in the dex files produced by vdexExtractor.

When looking at smali deodexed files there are very few issues in reality..

The odd check-cast results in a double no operation (nop nop) & core-oj.jar/Java/Lang/invoke is messed up.

Both methods have their issues at present IMO.

The next issue many of us are facing after deodexing is oat2dex not doing as it should & building a new dalvik-cache, the cache is empty unless selinux is set to permissive, oat2dex is denied write access too /data/dalvik-cache by selinux.. totally OT but a good one to get out there 👍

[auras76]

how can i use extract_utils.sh to deodex?

[frap129]

@razorloves Glad to hear it worked! I had yet to test it on angler. @LeeDroid- I haven't compared the outputs as I'm not using vdexExractor for modifying apps. They install, function as they should, and don't crash, so that's good enough for me. As for your oat2dex issue, the solution is to enable DEXPREOPT when building (sorry Mac users)

[Lanchon]

just a heads up: with vdex changes, aosp's oatdump is now able to unquicken (deodex). vdexExtractor i guess is a reimplementation of that functionality. but oatdump is standard aosp and should always provide correct unquikening, with any issues considered aosp bugs and expected to be fixed. see:

https://github.com/anestisb/vdexExtractor/blob/master/README.md#bytecode-unquickening-decompiler

[frap129]

@Lanchon the 8.1 release of oatdump doesn't support unquickening, however, the master branch does. You can build the master branch and ship that, however I dont want want to ship over 300mb of blobs (190mb for statically linked outdump on Linux, similar size for Darwin), so vdexExtractor is the easiest way until AOSPs next milestone release

[amakuramio]

so how do I decompile 8.1 services.jar?? anyone has precompiled tools for windows?

[Fatmajk]

I've been fighting with this issue for a week now. vdexExtractor worked perfect for me. @frap129 Thanks a lot!

[Uvneshkumar]

Guys how do I merge an APK with ODEX and VDEX into a single APK?

[SZRabinowitz]

so how do I decompile 8.1 services.jar?? anyone has precompiled tools for windows?

Same question. Do I Just use Vdex extractor and Odex extractor and name 1 classes.dex and the other classes1.dex

[SZRabinowitz]

If I post the folder with the APK, Vdex, and Odex, can someone build it for me?