Home/ Questions/Q 8771335
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T17:45:36+00:00

Is there anything else that must be done to load a String constant into

  • 0

Is there anything else that must be done to load a String constant into a register, and then using it in a method invocation, besides doing:

const-string v6, "TEST CONSTANT"
invoke-static {v6, p1}, Landroid/util/Log;->wtf(Ljava/lang/String;Ljava/lang/String;)I

?

the following block of instructions

iget-object v4, p0, Lcom/mypackage/MyClass;->myList:Ljava/util/List;
invoke-interface {v4, p1}, Ljava/util/List;->contains(Ljava/lang/Object;)Z
move-result v5
if-eqz v5, :cond_not_met_0
const-string v6, "TEST CONSTANT"
invoke-static {v6, p1}, Landroid/util/Log;->wtf(Ljava/lang/String;Ljava/lang/String;)I
:cond_not_met_0

invoke-interface {v4, p2}, Ljava/util/List;->contains(Ljava/lang/Object;)Z
move-result v5
if-eqz v5, :cond_not_met_1
invoke-static {v6, p2}, Landroid/util/Log;->wtf(Ljava/lang/String;Ljava/lang/String;)I
:cond_not_met_1

gave me the following logcat error messages:

10-29 23:37:37.191: W/dalvikvm(515): VFY: register1 v6 type 2, wanted ref
10-29 23:37:37.241: W/dalvikvm(515): VFY: bad arg 0 (into Ljava/lang/String;)
10-29 23:37:37.241: W/dalvikvm(515): VFY:  rejecting call to Landroid/util/Log;.wtf (Ljava/lang/String;Ljava/lang/String;)I
10-29 23:37:37.241: W/dalvikvm(515): VFY:  rejecting opcode 0x71 at 0x0028
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your suspicions in this case are correct. The problem is because at the second Log->wtf instance, v6 was not necessarily set.

    As to why this happens, it’s important to note that very little verification is done when re-assembling the bytecode. In many cases, the assembler simply does not have enough information to do this level of verification – this would require the assembler have knowledge of the full set of classes that will be present when the application runs, similar to the case of deodexing (-o) or generating register info (-r).

    These types of problems are caught by dalvik when verifies the bytecode, which is exactly what the error you mentioned is from.

    Additionally, you mention “the values i used for p1 and p2 would have failed both if-eqz tests”. This does not matter to dalvik’s bytecode verifier. The verifier makes sure that all code paths are valid. It can’t know or assume any particular value for the parameters that are passed in to the method.

    If you want to see some additional information related to how the register types are propagated throughout the method, you can try the -r option for baksmali.

    # grab the full framework directory from your device
adb pull /system/framework framework
# run baksmali with the -r command
baksmali -r ARGS,DEST,FULLMERGE -d framework <apk_or_dex_file>

    This will add comments before/after every instruction with detailed information about the types of registers at that position.

    • 0