Basic Blocks

We already saw the concept of xrefs_, which can be used to get references in the assembly. The next step is to look at the Control Flow Graph (CFG) of a method.

Such a CFG can be generated using the decompile command of the androguard_ tool. Let’s take the androguard example file and decompile it:

$ androguard decompile -d output_folder -f jpg --limit "LTestDefaultPackage.*" examples/android/TestsAndroguard/bin/TestActivity.apk
[INFO    ] androguard.analysis: End of creating cross references (XREF)
[INFO    ] androguard.analysis: run time: 0min 00s
Dump information examples/android/TestsAndroguard/bin/TestActivity.apk in output_folder
Create directory output_folder
Decompilation ... End
Dump LTestDefaultPackage$TestInnerClass$TestInnerInnerClass; <init> (LTestDefaultPackage$TestInnerClass; I I)V ... jpg ... source codes ... bytecodes ...
Dump LTestDefaultPackage$TestInnerClass$TestInnerInnerClass; <init> (LTestDefaultPackage$TestInnerClass; I I LTestDefaultPackage$TestInnerClass$TestInnerInnerClass;)V ... jpg ... bytecodes ...
Dump LTestDefaultPackage$TestInnerClass$TestInnerInnerClass; Test (I)V ... jpg ... bytecodes ...
Dump LTestDefaultPackage$TestInnerClass; <init> (LTestDefaultPackage; I I)V ... jpg ... source codes ... bytecodes ...
Dump LTestDefaultPackage$TestInnerClass; <init> (LTestDefaultPackage; I I LTestDefaultPackage$TestInnerClass;)V ... jpg ... bytecodes ...
Dump LTestDefaultPackage$TestInnerClass; access$1 (LTestDefaultPackage$TestInnerClass;)I ... jpg ... bytecodes ...
Dump LTestDefaultPackage$TestInnerClass; Test (I)V ... jpg ... bytecodes ...
Dump LTestDefaultPackage; <init> ()V ... jpg ... source codes ... bytecodes ...
Dump LTestDefaultPackage; main ([Ljava/lang/String;)V ... jpg ... bytecodes ...
Dump LTestDefaultPackage; const4 ()V ... jpg ... bytecodes ...

Note, that we only decompiled a certain subset of the file, as we are not interested in the other classes right now.

Inside the output folder, we have now several files, among them some JPG files which show the CFG, like this one:


Each of the rectangles is a DVMBasicBlock. Each block is connected via an arrow, indicating the flow direction.

In this example, we can see that the switch instruction has six different ways to go, indicated by the green and purple arrows. Each green arrow is a specific check inside the switch instruction, i.e. what value results in which code block. The purple arrow is the default case. We can see that the switch only results in four different code blocks. There is a special block, with the yellow arrow, which is the pseudo instruction holding the switch payload.

Each of the switch blocks is followed by another, large basic block. If you look carefully, you can see that three of the blocks have goto commands at the end but the fourth block does not have one. First, take a look at the overall dissassembly of the method:

METHOD LTestDefaultPackage; public static main ([Ljava/lang/String; v9)V
main-BB@0x00000000 :
        0  (00000000) const/4             v8, 0
        1  (00000002) const/4             v7, 4
        2  (00000004) const/4             v6, 3
        3  (00000006) const/4             v0, 5
        4  (00000008) packed-switch       v0, 80 [ D:main-BB@0x0000000e 1:main-BB@0x00000078 2:main-BB@0x00000078 3:main-BB@0x00000088 4:main-BB@0x0000000e 5:main-BB@0x00000098 ]
        5  (0000000e) sget-object         v4, Ljava/lang/System;->out Ljava/io/PrintStream;
        6  (00000012) const-string        v5, '4'
        7  (00000016) invoke-virtual      v4, v5, Ljava/io/PrintStream;->println(Ljava/lang/String;)V [ main-BB@0x0000001c ]
        8  (0000001c) new-instance        v1, LTestDefaultPackage;
        9  (00000020) invoke-direct       v1, LTestDefaultPackage;-><init>()V
        10 (00000026) new-instance        v2, LTestDefaultPackage$TestInnerClass;
        11 (0000002a) invoke-virtual      v1, Ljava/lang/Object;->getClass()Ljava/lang/Class;
        12 (00000030) invoke-direct       v2, v1, v6, v7, v8, LTestDefaultPackage$TestInnerClass;-><init>(LTestDefaultPackage; I I LTestDefaultPackage$TestInnerClass;)V
        13 (00000036) new-instance        v3, LTestDefaultPackage$TestInnerClass$TestInnerInnerClass;
        14 (0000003a) invoke-virtual      v2, Ljava/lang/Object;->getClass()Ljava/lang/Class;
        15 (00000040) invoke-direct       v3, v2, v6, v7, v8, LTestDefaultPackage$TestInnerClass$TestInnerInnerClass;-><init>(LTestDefaultPackage$TestInnerClass; I I LTestDefaultPackage$TestInnerClass$TestInnerInnerClass;)V
        16 (00000046) sget-object         v4, Ljava/lang/System;->out Ljava/io/PrintStream;
        17 (0000004a) new-instance        v5, Ljava/lang/StringBuilder;
        18 (0000004e) const-string        v6, 't.a = '
        19 (00000052) invoke-direct       v5, v6, Ljava/lang/StringBuilder;-><init>(Ljava/lang/String;)V
        20 (00000058) invoke-static       v2, LTestDefaultPackage$TestInnerClass;->access$1(LTestDefaultPackage$TestInnerClass;)I
        21 (0000005e) move-result         v6
        22 (00000060) invoke-virtual      v5, v6, Ljava/lang/StringBuilder;->append(I)Ljava/lang/StringBuilder;
        23 (00000066) move-result-object  v5
        24 (00000068) invoke-virtual      v5, Ljava/lang/StringBuilder;->toString()Ljava/lang/String;
        25 (0000006e) move-result-object  v5
        26 (00000070) invoke-virtual      v4, v5, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
        27 (00000076) return-void
        28 (00000078) sget-object         v4, Ljava/lang/System;->out Ljava/io/PrintStream;
        29 (0000007c) const-string        v5, '1 || 2'
        30 (00000080) invoke-virtual      v4, v5, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
        31 (00000086) goto                -53 [ main-BB@0x0000001c ]
        32 (00000088) sget-object         v4, Ljava/lang/System;->out Ljava/io/PrintStream;
        33 (0000008c) const-string        v5, '3 || '
        34 (00000090) invoke-virtual      v4, v5, Ljava/io/PrintStream;->print(Ljava/lang/String;)V
        35 (00000096) goto                -68 [ main-BB@0x0000000e ]
        36 (00000098) sget-object         v4, Ljava/lang/System;->out Ljava/io/PrintStream;
        37 (0000009c) const-string        v5, '5'
        38 (000000a0) invoke-virtual      v4, v5, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
        39 (000000a6) goto                -69 [ main-BB@0x0000001c ]
        40 (000000a8) packed-switch-payload

All these blocks are concatenated to each other. If you like, try to identify the basic blocks inside the dissasembly! Hint: The second column gives the offset inside the bytecode and matches the offset given in the CFG.

As you can see, the order of instructions in the bytecode does not match the execution order. For example, the return opcode is in the middle of the bytecode, while it is the end of the exection. Therefore some parts must have a goto to resume the execution at the correct point. For example, the basic block for the case that the argument of the switch opcode is 5 ends at offset 0xa6 and has a goto command to subtract 0x45 from the current offset. But that ends up beeing offset 0x61? No, it does not. To increase your confusion, you have to know, that offset arguments for opcodes are always in 16-bit units, while the offset used by androguard are counted in 8-bit units. That means, that you have to subtract 0x8a, which indeed returns to offset 0x1c in the bytecode.


The offset units used are sometimes a little bit inconsistent across androguard! If you find some inconsistent behaviour, please report it as an issue.

To conclude, let’s take a look at the actual Java source code of this particular method:

public static void main(String [] z) {
    int a = 5;
    case 1:
    case 2:
        System.out.println("1 || 2");
    case 3:
        System.out.print("3 || ");
    case 4:
    case 5:
    TestDefaultPackage p = new TestDefaultPackage();
    TestInnerClass t = TestInnerClass(3, 4);
    TestInnerClass.TestInnerInnerClass t2 = TestInnerInnerClass(3, 4);
    System.out.println("t.a = " + t.a);

Can you see how each Basic block belongs to a different path in the code?