I needed to setup some new systems for mobile application penetration tests at the start of January and part of this process includes importing Burp’s certificate for traffic interception. I have set this up in the past but it seems to change fairly regularly with newer versions of Android emulators.

I installed the latest version of Android Studio and setup an android virtual device (AVD) emulator based on Nougat (Android 7.0). I reviewed all the various guides I could find, but none of them quite worked correctly. I eventually figured it out, got the systems setup, and moved on, but then last week I came across a Tweet by ropnop for his blog titled “Configuring Burp Suite with Android Nougat.” It is a great guide, but part of the steps are what specifically did not work for me and resulted in a lot of troubleshooting. This inspired me to write this post as others might be experiencing the same thing for AVD’s created/run with Android Studio.

I will not provide detailed screenshots of all of the steps, as the above post by ropnop does a great job. The key steps are:

  1. Export Burp’s certificate in DER format
  2. Convert the certificate from DER to PEM format: openssl x509 -inform DER –in burpmobile.der -out burpmobile.pem -outform PEM
  3. Get the hash of the certificate: openssl x509 -inform PEM -subject_hash_old -in burpmobile.pem | head -1
  4. Rename the PEM certificate to the hash output above with an extension of .0 (that is a zero): mv burpmobile.pem <hash>.0

The next steps then changed a little bit on all the machines in which I performed this task. The Google documentation, and ropnop’s guide, each uses adb next to obtain root access and then remount the /system directory as read-write. This is necessary as you must copy the certificate to the system directory. When I performed these steps, everything seemed to work. The commands all completed successfully and a ‘mount -v’ showed /system as being mounted as read-write. However, as soon as I attempted to copy the certificate to the proper directory in /system, I received a write error and then a subsequent execution of ‘mount -v’ showed /system as being mounted read-only. Weird.

I began looking at ways to start the AVD myself vs. using the tools within Android Studio. I came across documentation for the emulator.exe tool here and noticed the ‘-writable-system’ command line switch. This ended up being the key to resolving my issue. The final steps for me ended up being to start the emulator directly with the ‘-writeable-system’ switch, get root access, set /system to read-write, then upload the certificate:

  1. Start the emulator: emulator.exe -writable-system -camera-back none -camera-front none -netdelay none -netspeed full -avd <Name of AVD>
  2. Get root access: Run: adb -s <emulator_id> root
  3. Mount /system as read-write: adb -s <emulator_id> remount
  4. Upload the certificate to the AVD: adb -s <emulator_id> push C:\Tools\burp\<hash>.0 /storage/emulated/0/Download/
  5. Access the AVD shell: adb -s <emulator_id> shell
  6. Move the certificate to the appropriate directory: mv /storage/emulated/0/Download/<hash>.0 /system/etc/security/cacerts/
  7. Set the appropriate permissions on the certificate: chmod 644 /system/etc/security/cacerts/<hash>.0

One other issue I ran into on a few of the installs was Android Studio setting specific files in the AVD directory to read-only. I have no idea why this occurred on a handful of these but it did. The only thing I could think of is that these were installed almost a week later and maybe the installer pulled in updates as part of the process that causes this issue ¯\_(ツ)_/¯. The fix required three changes to this process:

  1. Use Windows attrib command to remove the read-only flag from all files in the AVD directory: attrib -r C:\Users\<username>\.android\avd\<Name of AVD> /S /D
  2. Use the ‘-no-snapshot-load’ command line switch on step #1 above with emulator.exe to perform a cold boot and completely disable Quick Boot mode
  3. Configure my AVD with Android Studio to disable support for Quick Boot

Leave a Reply

Your email address will not be published. Required fields are marked *