Add option to preserve original line numbers when saving source files

[BLuFeNiX]

When decompiling an APK or DEX, line numbers corresponding to the LineNumberTable in the Java Class file structure are correctly displayed next to the decompiled source code, however, there is not a way to dump the contents of the source file while retaining those line numbers.

Example:

    package com.example.foo;

    public class MainActivity extends Activity {

14      protected void onCreate(Bundle bundle) {
15          super.onCreate(bundle);
16          foo();
        }

22      public void foo() {
23          // foo impl
        }
    }

Since there was additional whitespace somewhere in the original source files, jagx detects that correct line numbers (corresponding to the LineNumberTable in the Java Class file structure), but when the file is saved, these numbers will not align with the output.

Example of desired output:

package com.example.foo;

public class MainActivity extends Activity {





// empty lines inserted here ...




    protected void onCreate(Bundle bundle) {
        super.onCreate(bundle);
        foo();
    }

// and here, so that line numbers match 


    public void foo() {
      // foo impl
    }
}

Why is this useful?
If we were able to align the decompiled source code with the correct line numbers, the jagx output would be suitable for attaching a debugger to the target APK.

[beaumontk]

Just discovered option ADD_LINE_NUMBERS and setting it to true works a treat! So ignore the rest of this!

This option would help a lot in finding the code in the smali file. Suggest insert the line numbers as comments to the right of the code using tabs. eg.

wot.getStackTraceString("KBDBG_125f2_smali_wqb_c", Thread.currentThread()); //49
String str = this.k; //50

ie. comments aligned on the right depending on the longest line of code in the class. Hope this is not too complicated.

[BLuFeNiX]

@beaumontk your suggestion would be better than what is currently available, however still not suitable for a debugger. The Java debugger expects line numbers to match the actual line number in the file itself. ex: if you compile this code:

package com.example.foo;
public class MainActivity extends Activity {
    protected void onCreate(Bundle bundle) {
        super.onCreate(bundle);
        foo();
        bar();
        bazz();
    }
}

and then you run it with a debugger attached, you can break on foo() by putting a breakpoint on line 5, as expected. However, if you were to have improper whitespace in your source code (as often happens when using decompiled code), you might have something like this:

package com.example.foo;

public class MainActivity extends Activity {

    protected void onCreate(Bundle bundle) {
        super.onCreate(bundle);
        foo();
        bar();
        bazz();
    }

}

When debugging the original binary against this code, you might try to break on foo() by inserting a breakpoint on line 7. This will not work, since the debugger does not care what the content of your source code is, it just cares about the line number. So, it would effectively break on bazz() instead, since bazz() was on line 7 in the original code.

Edit:
Perhaps your suggestion should be another enhancement request? I see it being useful in different scenarios, like manual review of decompiled code.

[beaumontk]

Hi Chase,For me this is not a problem. I just want to associate code from jadx with that from apktool. So my solution works fine. But I have another problem that maybe you can help with. apktool: invoke-virtual {p0}, Ludy;->c()Ljava/lang/String;jadx:     String c2 = udy.c(); But this actually calls wqb:apktool: .method public final c()Ljava/lang/String;jadx:     public final String c() { How is this possible? wqb instead of udy? There are other similar mysteries in this Google apk !!!! Regards,KB On Saturday, 16 November 2019, 16:39:40 GMT, Chase Montgomery <[email protected]> wrote: @beaumontk your suggestion would be better than what is currently available, however still not suitable for a debugger. The Java debugger expects line numbers to match the actual line number in the file itself. ex: if you compile this code: package com.example.foo; public class MainActivity extends Activity { protected void onCreate(Bundle bundle) { super.onCreate(bundle); foo(); bar(); bazz(); } } and then you run it with a debugger attached, you can break on foo() by putting a breakpoint on line 5, as expected. However, if you were to have improper whitespace in your source code (as often happens when using decompiled code), you might have something like this: package com.example.foo; public class MainActivity extends Activity { protected void onCreate(Bundle bundle) { super.onCreate(bundle); foo(); bar(); bazz(); } } When running this code, you might try to break on foo() by inserting a breakpoint on line 7. This will not work, since the debugger does not care what the content of your source code is, it just cares about the line number. So, it would effectively break on bazz() instead, since bazz() was on line 7 in the original code. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[BLuFeNiX]

@beaumontk your question is not related to this issue. You should submit your own bug report (with greater detail) or perhaps post a question on stackoverflow.

[firmianay]

Is there any progress on this question? When I try mariana-trench for analysis， it has a parameter to specify the source code. I tried to pass in the decompiled code of jadx, but because the line numbers did not match, it could not work correctly.

(mariana-trench)$ mariana-trench \
  --system-jar-configuration-path=$ANDROID_SDK/platforms/android-30/android.jar \
  --apk-path=sample-app-debug.apk \
  --source-root-directory=app/src/main/java