Home Android & Kotlin Books Real-World Android by Tutorials

App Analysis Written by Kolin Stürt

Heads up... You're reading this book for free, with parts of this chapter shown beyond this point as scrambled text.

You can unlock the rest of this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

In the previous chapters, you looked at analytic reporting and advanced debugging techniques. Now, you’ll learn to analyze your app to investigate issues where you know there’s a problem post-release, but you don’t know which part of the code is the culprit. For example, finding a corrupt file or a conflict with a statically compiled third-party library requires deep investigation.

In this chapter, you’ll learn how to:

  • Look at data artifacts that aren’t obvious from your code.
  • Analyze databases.
  • Reverse-engineer code you didn’t write.

For this chapter, you’ll use the Pixel XL API 30 (R) Emulator.

Debugging versus investigating

When you debug your app, you apply tools to fix not just the symptoms, but the underlying problem. You look for specific regions of code, perhaps a section that has changed recently or that is prone to errors.

There are two types of tests you can run to find problems:

  • Dynamic testing: Testing while executing the code.
  • Static testing: Auditing the source code for issues.

In either case, the goal is to understand the problem before attempting to fix it. App analysis helps you acquire all available data to aid your problem-solving.

Before you even get to that point, you can perform tests to avoid mysterious bug reports. By covering all your code with tests, going through each flow-control case and testing each line of code at least once, you’ll minimize the chance that unknown cases will pop up later. Then, it’s important to test each code change thoroughly, to make sure you didn’t break code that was working before. This is called regression testing.

Because you wrote the code, you know how to use your app. It’s important to step away from that mindset and think about what a real-world user will do — and that’s not always what you expect. There are ways of covering more of that behavior: One is to input random data, called fuzz testing. Another is to choose extreme values in hopes of finding an edge case. These tests help find bugs that aren’t obvious from looking at the code or using the app in a normal way.

Even with all this testing, you’ll find unexpected bugs. One example is memory corruption due to race conditions. It’s difficult to find race conditions during testing because you have to corrupt memory in the “right way” to see the problem. Sometimes the problems appear a long time later in the app’s lifecycle. This is why it’s crucial to run Lint — Android Studio’s static code analysis tool.

Despite all these precautions, sometimes there’s just no way to step back through the events to find out what caused a problem.

To see this in action, you’ll work through a real-world example that walks you through the process of analyzing a specific device that you’re allowed to inspect. This will give you a sense of the process and the complications you’ll encounter along the way.

You won’t be able to follow along with everything in the next section, as the process changes widely per device, so read through the example without trying it on your own device.

Extracting data

Your CEO comes to you with a device that crashes when they launch PetSave. You plug the device into your debugger, build and debug, and the problem goes away.

adb shell  # 1
pm list packages -f  # 2

Extracting data from a package

Once you’ve found the PetSave package, try to run the app over ADB to extract data with the correct permissions. It’s easy to retrieve data from apps that allow external install locations or that save data to public areas. In most cases, however, you’ll need to access data that’s in the private storage area.

adb shell
adb exec-out run-as com.raywenderlich.android.petsave cat databases/reports-db > reports-db
adb shell
run-as com.raywenderlich.android.petsave  #1
chmod 666 databases/reports-db  #2
cp /data/data/com.raywenderlich.android.petsave/databases/reports-db /sdcard/  #3
run-as com.raywenderlich.android.petsave
chmod 600 databases/reports-db  #4
adb pull /sdcard/reports-db .  #5
adb backup -apk -shared com.raywenderlich.android.petsave

Extracting data from the emulator

Now that you have access to the file system of the CEO’s device, it’s time to extract the data. Build and run in the emulator, then make a report.

Figure 22.1 — File Explorer
Kafuxu 89.6 — Dafa Owhkitej

Figure 22.2 — Locate the Data Folders
Pusiyu 59.4 — Bagoyu qwo Gera Ragpacz

Examining SharedPreferences

Open MyPrefs.xml inside shared_prefs. You’ll notice at least one entry with a timestamp.

Examining other files

Now, select users.dat in the files directory.

"::basic_string(void*,void(*),void(*)_char_\0\0cd.Nico Sell - CEO"
_passwordChar = "";

Analyzing databases

Often, user records are stored in a database instead of a serialized object. Because of that, it’s a good idea to cross-check the data to see if the bug exists in more than one place.

Figure 22.3 — SQL Browser
Migoca 80.8 — ZJM Bruqpeg

Figure 22.4 — Locate and Open Your DB file
Sawuqi 90.9 — Jeyesa emc Ikis Toad WY paxi

Figure 22.5 — Browser the Tables of Your DB
Pedipa 40.1 — Ntackos gne Kojpiv aw Leis JG

Figure 22.6 — Browser the Data of Your DB
Nimigu 65.1 — Xyicpoh mnu Bili uq Hiex DZ


Recovering deleted data

The data you’ve analyzed so far exists inside a saved SQLite block. SQLite has unallocated blocks and free blocks. When you delete something from the database, SQLite doesn’t overwrite the block immediately. Instead, it simply marks the block as free — which means that you might still be able to access that information. To read that data block, you’d use a hex viewer that also displays ASCII to search for keywords that might still be present.

Black box testing and reverse-engineering

At this point, you’ve analyzed and fixed code that you own, but bugs happen in third-party frameworks, too. It’s helpful to know how to analyze them so you can properly communicate the issue to the third party. If you have a statically compiled library, for example, you’re on the outside — it works like a black box to you.

Understanding bytecode

You now have a new issue to deal with: The team updated an expired API key but the app still isn’t working.

Figure 22.7 — Access SECRET in ApiConstants
Rodega 09.2 — Ewmujc SIBMUY is OtiMifrvihzp

Using APK Analyzer

APK Analyzer is a tool for inspecting your finalized app. It presents a view with a breakdown of your app’s file size, letting you see what’s taking up the most space along with the total method and reference counts.

Figure 22.8 — Using APK Analyzer
Tojeje 11.3 — Abest UKL Anuybrih

Figure 22.9 — Analyze the Classes in the APK for Your App
Sozufo 19.9 — Ajuxgxe hpo Kqaprah ux pra ULC nez Feen Esc

Figure 22.10 — Access the SECRET Constants in the Classes in the APK for Your App
Jisowa 40.11 — Ervuct qpe NUYPIW Kufpkekqt ed svu Zvavlot at cve ULM kiz Hoep Imw

Introspection and reflection

When you’re away at work, your pets hang out for hours, not seeming to do very much. That’s probably because they’re busy introspecting and reflecting on life. In Kotlin, introspection and reflection are features of the language that inspect objects and call methods dynamically at runtime.

Figure 22.11 — Obfuscation in Practice
Minaro 53.20 — Osqayqiyiuv az Svuvxoli

val kClass = Class.forName(ownerClassName).kotlin // 1
val instance = kClass.objectInstance ?: kClass.java.newInstance() // 2
val member = kClass.memberProperties.filterIsInstance<KMutableProperty<*>>()
    .firstOrNull { it.name == fieldName } // 3
member?.setter?.call(instance, value) // 4

Using reverse-engineering tools

You’ve just reverse-engineered code, and because you have the original project open in Android Studio, it was easy to do. But this is not the only way to view the bytecode. Many other tools let you analyze the production version of apps, especially for black-box testing or checking how your finalized app looks.

Debugging with ProGuard output files

In the app build.gradle, replace buildTypes’s code with the following:

buildTypes {
  release {
    minifyEnabled true
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
  debug {
    minifyEnabled true
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
Figure 22.12 — The Code After Proguard Obfuscation
Rebofa 88.18 — Kka Pudu Uzhaw Jginainw Apmisdazeor

Figure 22.13 — Loading the Proguard Mapping File
Qadami 14.33 — Wougots qva Yxaduexq Rukmoxw Sido

Some final notes

Finding a software defect is like holding a mirror up to yourself — a great learning opportunity. It provides valuable insight into which common mistakes you make as a developer and how you can improve. App analysis is self-analysis. And, like every other phase of the lifecycle, it’s iterative.

Key points

  • There are two types of tests you can run to help you find problems: dynamic and static
  • Dynamic testing is testing while executing the code.
  • Static testing is auditing the source code for issues.
  • Android Debug Bridge (ADB) is a very important tool that helps you access your device data.
  • Understanding Java bytecode is a vital skill when testing the security of your app.
  • Several tools allow you to reverse-engineer your app. APK Analyzer is one of those.

Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.

Have feedback to share about the online reading experience? If you have feedback about the UI, UX, highlighting, or other features of our online readers, you can send them to the design team with the form below:

© 2021 Razeware LLC

You're reading for free, with parts of this chapter shown as scrambled text. Unlock this book, and our entire catalogue of books and videos, with a raywenderlich.com Professional subscription.

Unlock Now

To highlight or take notes, you’ll need to own this book in a subscription or purchased by itself.