Closed IgorEisberg closed 6 years ago
Confirm!
The problem is located in the baksmali software and not the vdexExtractor. If you use the vdexExtractor disassembler (--dis
flag) you will see that the opcodes you highlighted are properly decompiled and match the invoke-polymorphic
instruction.
9e6c44: 5463 f187 |001e: iget-object v3, v6, Landroid/widget/RemoteViews$ReflectionAction;.Lcom/android/ims/internal/IImsVideoCallCallback;:Ljava/lang/Object; // field@87f1
9e6c48: fa30 12f8 0203 4415 |0020: invoke-polymorphic {v2, v0, v3}, Ljava/lang/invoke/MethodHandle;.invoke:([Ljava/lang/Object;)Ljava/lang/Object;, (Landroid/view/View;Ljava/lang/Object;)Ljava/lang/Runnable; // method@f812, proto@1544
9e6c50: 0c03 |0024: move-result-object v3
The same issue has been reported in https://github.com/anestisb/vdexExtractor/issues/20 too. It appears that baksmali is not properly handling the recently introduced polymorphic instructions. You need to double-check you have the latest baksmali version and report the issue to the smali project if still there.
Thanks for the info!
vdex file: http://www.mediafire.com/file/pn2747p8aaoq7lv/boot-framework.vdex/file
Seems like there are 2 quickened methods remaining and both are referring to the same vtable index.