Debugging Android Applications Without Java Source Code

What is the article about

In this article, I am compressed, without the "water", I will tell you how to debug Android applications without having their source code in Java. The article is not quite for beginners. It is useful primarily for those who more or less understand the syntax of Smali and have some experience in reversing engineering applications for Android.

Instruments

We need Apk-tool 1.4.1 and NetBeans 6.8 . Yes, yes, it is these ancient versions! With newer versions, debugging unfortunately “does not start”, which has already been repeatedly mentioned in various discussions (for example, see here and here ).

The installation does not stop in detail. NetBeans is installed by default, just launch the installation and click Next-Next-Next. Installing Apk-tools consists of apktool.jar unpacking the apktool.jar file into any folder.
')
Also along the way we need DDMS - it is in the Android SDK.

Debugging

This section provides step-by-step instructions. It was written for Windows, but will probably work on both Linux and Mac OS. I also have a draft of this manual in English on my blog, but I will not give a link, for the rules. This instruction more or less repeats the original instruction with the Apk-tool wiki, however it contains some additional points, without which debugging can “not start”. At one time, I did not start, and I found these additional items using the method of enhanced googling and "scientific spear". I hope that now my experience will save someone time.

Please follow the instructions exactly - this is important!

1. Decode your .apk file into the out directory with the Apk-tool. To do this, use the -d option:
   

    java -jar apktool.jar d -d my.app.apk out 

   
   As a result, in the out/smali directory you will have a bunch of .java files with commented out Smali code inside. This is normal, as it should be.
   
2. Add the android:debuggable="true" attribute to the <application> section of the out/AndroidManifest.xml file
   
3. Put the out directory back in the .apk file:
   

    java -jar apktool.jar b -d out my.app.to.debug.apk 

   
   
4. Sign the file my.app.to.debug.apk and install it on a real device or emulator where you are going to debug it.
5. Delete the out/build directory (it may prevent you from creating a project in step 6 and 7).
   
6. Launch NetBeans, click “File” -> “New Project”. Select "Java" -> "Java Project with Existing Sources". Click “Next”.
7. Specify out as the “Project Folder”. Click “Next”.
8. Add the out/smali to the Source Package Folder list. Click “Next” and then “Finish”. As a result, those .java files with commented Smali code inside will be added to the project.
9. Run my.app.to.debug.apk on a real device or emulator (if you are using a real device, then make sure it is connected to your computer using a USB cable and your system “sees” it).
   
10. Run DDMS, find your application in the list and click on it. Remember the information in the last column, this is the port number, usually something like 86xx/8700 .
    
11. In Netbeans, click “Debug” -> “Attach Debugger” -> select “JPDA” and enter “ 8700 ” in the “Port” field (or whatever port number you had in the previous step). Remaining fields remain unchanged. Click “OK”.
12. Now you can debug the application: in the Netbeans panel you can click on the corresponding buttons
13. Install breakpoint on the instruction you are interested in (yes, on one of those instructions from the commented out Smali code inside those .java files that I mentioned twice before). Remember that you cannot set breakpoints on lines that start with ".", ":" Or "#". Only on Smali code instructions!
14. Do something in the app for your breakpoint to work. After that, you can do step by step debugging, view the values ​​of fields and variables, etc.

That's all, if briefly.

Underwater rocks

Without a trick here of course nothing. Usually everything goes well, strictly according to the instructions, right up to step 13. But at step 13, people often put a breakpoint at the very beginning of the application code: for example, in the onCreate(...) method in the activity with which the application starts. It seems to be logical - if it’s not quite clear where to start debugging an application, it’s better to start from the very beginning. However, in most cases it does not work. The debugged application works as if nothing had happened to itself, and the sneaky breakpoint in onCreate(...) does not want to trigger anything.

This is due to the fact that we connect the debugger to an already running application. This means the code at the beginning of the application (for example, in the same onCreate method in the activity that starts the execution of the application) has already been executed, and it is useless to set breakpoint on it (although not always of course). Moreover, when we attach a debugger to a running application, it does not stop until our breakpoint works or until we stop it ourselves - this point is also worth remembering.

In my next article, I show a trick that allows you to debug Java applications for Android without source code from the very beginning, i.e. from the very first onCreate(...) method (or even the constructor) in the activity with which the application starts to run.

If you have questions, please ask them in the comments or in personal messages. I will try to respond as quickly as possible, but if I’m stupid, please be patient. I will try to answer all.

Happy debugging!