In this second part of the blog we'll setup the needed environment to run the Flarebear Android application to do dynamic analysis.

The easiest way to run Flarebear is to use Android Studio and the corresponding emulator. And now comes the tricky part: Without hardware acceleration, the emulator runs terribly slow and the Flarebear application is unusable.

First I tried to setup Android Studio in a Windows VM. Even with enabled VT-x pass through, Intel Hardware Accelerated Execution Manager (HAXM) refused to install and therefore the emulator run without acceleration and was super slow.

Later I realized that Android Studio also runs on Linux. This worked much better, since KVM is used there for hardware acceleration.

To start, following is needed:

• A Linux VM with enabled VT-x (consult your hypervisors documentation on how to enable this)
• Android Studio

Android Studio can be downloaded for free from Google.

After downloading the archive, extract it and switch to the bin directory. Then execute studio.sh:

1
2
3

tar xvzf android-studio-ide-${version}-linux.tar.gz
cd android-studio/bin
./studio.sh

The installation wizard will appear and guide you through the installation process. Important is to install also the Android virtual devices, as this is actually the needed emulator.

After the downloading of the additional components and their installation, following window appears:

Since we do not want to create a new Android application project, we select Configure and the AVD Manager to create a new Android Virtual Device. In the next step, the virtual hardware can be specified:

It doesn't matter so much which phone model is selected. The next step is more important.

This dialog allows to select the wanted Android system image. Two points are important here:

• We want to take advantage of the hardware virtualisation feature to accelerate the execution of the emulator. Therefore a x86_64 image is preferable.
• We want root access inside the emulated device to be able to deploy the Frida server. The easiest way to achieve this is not to use a Target with installed Google Play Services.

Therefore:

ABI: x86_64

Target: Android 9.0 (Google APIs)

Before starting the newly created Android device, following qemu / KVM packages need to be installed:

sudo apt-get install qemu-kvm bridge-utils

Now the emulated Android device can be started by clicking on the green arrow in the Android Virtual Device manager:

It takes some time until Android booted. But then the virtual device is ready and looks like this:

Next we want to get root access at this virtual device. Together with Android Studio also the Android SDK was installed, which provides tools to access an Android device remotely. To get a shell, we'll use adb, the Android debugging bridge. The Android SDK is installed per default at ~/Android/Sdk/ and adb is found in the platform-tools folder.

First let's check whether adb recognizes our virtual Android device:

$:~/Android/Sdk/platform-tools$ ./adb devices -l
List of devices attached
emulator-5554          device product:sdk_gphone_x86 model:Android_SDK_built_for_x86 device:generic_x86 transport_id:3

Next request root access through adb

$:~/Android/Sdk/platform-tools$ ./adb root
restarting adbd as root

Then we can get a root shell like this:

$:~/Android/Sdk/platform-tools$ ./adb shell
generic_x86:/ # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb) <snip>

Now everything is ready to actually install the Flarebear Android application:

./adb install ~/Downloads/flare19/Flarebear/flarebear.apk

After the installation, start the Flarebear application by opening the app menu in the virtual Android device and selecting Flarebear.

Now we can start to play with Flarebear :-) We have three main buttons, which seem to correspond to the three functions we found in the first part:

• a food button -> feed function
• a play button -> play function
• a clean button -> clean function

As we click on these buttons, we change the internal states stored in the sharedPrefereces. Wouldn't it be nice to be able to dump and modify these internal states ? We'll do exactly this in the next and last part of this write-up. We'll using Frida, a well-known dynamic instrumentation toolkit, to hook functions defined in the FlareBearActivity class. This gives us the ability to dump and to set the sharedPreferences states and ultimately the ability to get the flag.