Closed zjns closed 6 years ago
Are you using the disassembling engine from the vdexExtractor? If so can you share the vdex/oat file so I can investigate?
Here are the odex and vdex file. I use cygwin on Windows and termux on Android to compile vdexExtractor with latest merge. They have the same problem.
It seems opcode 0xFA still used on new ART.
There is no problem with the vdexExtractor tool. If you enable the embedded disassembler engine you will see that the instruction (invoke-polymorphic) in offset 103fe8 you mention as problematic is correctly processed.
From the screenshot you pasted it seems that you use baksmali to process the extracted Dex file and not the embedded disassembler engine. When the latest baksmali version is used (2.2.4), the invoke-polymorphic instruction is indeed wrongfully processed. This is most probably related to issue https://github.com/JesusFreke/smali/issues/538 reported in smali repo.
At any case this is something you need to report to the smali/baksmali maintainers since its not a vdexExtractor issue.
$ vdexExtractor -i boot-core-oj.vdex --dis -l dis_out.txt
virtual_method #0: transform (Ldalvik/system/EmulatedStackFrame;)V
access=0001 (PUBLIC)
codeOff=103fb4 (1064884)
quickening_size=0 (0)
103fc4: 1207 |0000: const/4 v7, #int 0 // #0
103fc6: 5484 b106 |0001: iget-object v4, v8, Ljava/lang/invoke/Transformers$CollectArguments;.collector:Ljava/lang/invoke/MethodHandle; // field@06b1
103fca: 6e10 810f 0400 |0003: invoke-virtual {v4}, Ljava/lang/invoke/MethodHandle;.type:()Ljava/lang/invoke/MethodType; // method@0f81
103fd0: 0c04 |0006: move-result-object v4
103fd2: 7110 3401 0400 |0007: invoke-static {v4}, Ldalvik/system/EmulatedStackFrame;.create:(Ljava/lang/invoke/MethodType;)Ldalvik/system/EmulatedStackFrame; // method@0134
103fd8: 0c00 |000a: move-result-object v0
103fda: 5484 b206 |000b: iget-object v4, v8, Ljava/lang/invoke/Transformers$CollectArguments;.collectorRange:Ldalvik/system/EmulatedStackFrame$Range; // field@06b2
103fde: 6e57 3201 0974 |000d: invoke-virtual {v9, v0, v4, v7, v7}, Ldalvik/system/EmulatedStackFrame;.copyRangeTo:(Ldalvik/system/EmulatedStackFrame;Ldalvik/system/EmulatedStackFrame$Range;II)V // method@0132
103fe4: 5484 b106 |0010: iget-object v4, v8, Ljava/lang/invoke/Transformers$CollectArguments;.collector:Ljava/lang/invoke/MethodHandle; // field@06b1
103fe8: fa20 780f 0400 6911 |0012: invoke-polymorphic {v4, v0}, Ljava/lang/invoke/MethodHandle;.invoke:([Ljava/lang/Object;)Ljava/lang/Object;, (Ldalvik/system/EmulatedStackFrame;)V // method@0f78, proto@1169
with latest baksmali https://github.com/JesusFreke/smali/tree/49ecdb334b1eddaa8d8d8be123b322da56caf65e
Opcode 0xfa matches the invoke-polymorphic instruction (https://source.android.com/devices/tech/dalvik/dalvik-bytecode) and is perfectly valid. It has nothing to do with the de-optimization process and the vdexExtractor tool. It's an issue of the baksmali tool and you should report it there.
Thanks for your invertigation and reply. The tool from screenshot is MT Manager. It use baksmali to extract Dex file.
Until baksmali fixes the issue with the polymorphic instructions you can use the vdexExtractor disassembler engine or the dexdump tool to read the code. Also JEB2 decompiler supports the new polymorphic instructions in case you want to decompile the code.
system: MIUI 10 based Android 8.1 jar: core-oj.jar class: java.lang.invoke.Transformers$CollectArguments method: public void transform(dalvik.system.EmulatedStackFrame stackFrame)