Exception in thread "main" org.jf.util.ExceptionWithContext: Calculator.odex is not an apk, dex file or odex file.

[GoogleCodeExporter]

Exception in thread "main" org.jf.util.ExceptionWithContext: Calculator.odex is not an apk, dex file or odex file.

[GoogleCodeExporter]

ART odexes are not supported. See my comments in 
https://code.google.com/p/smali/issues/detail?id=225

Original comment by [email protected] on 30 Jan 2015 at 7:08

• Changed state: WAI
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

That being said, I could probably at least do some sort of detection of an ART 
odex, and print a more helpful error mesage :)

Original comment by [email protected] on 30 Jan 2015 at 7:09

• Changed state: Accepted
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thanks, I am primarily interested in extracting classes.dex to be used by 
another tool for analysis. Can you recommend some other solution? 

Original comment by [email protected] on 30 Jan 2015 at 9:20

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

There are tools out there to extract the dex file from an oat file (those .odex 
files are actually oat files), but it will be in an art-specific odex form, 
which baksmali won't be able to deodex correctly. So it will have the odex 
instructions like invoke-virtual/quick, which have a vtable index instead of a 
method name - and similarly for field accesses.


I'm not aware of any tools for deodexing an art odex.

Original comment by [email protected] on 30 Jan 2015 at 11:55

• Added labels: ****
• Removed labels: ****