By Jonathan Jang
How much of your smartphone contains sensitive information? Do you have a lock screen or any type of barrier to prevent a random person from accessing that data?
Smartphones have become an integral part of modern society as studies show an increase in their usage and functionality over the years. In its early years, Android devices have been known to have little to no security. But as time passed, Android has gone through remarkable changes. In today’s discussion, we will test to see if we can gain access to an Android device through the use of an Android emulator in a controlled environment. Upon doing so, we will then test to see if this is possible on an actual Android device. My hypothesis states that an actual Android device will not need root access to bypass the fingerprint scanner in some similar fashion.
Understanding Android and its File System
Android is an operating system that was based on the Linux kernel. This is why we can find directories like boot, cache, data, misc, system, and recovery when exploring the file system. The boot directory is where one can find the necessary files needed when an Android device gets turned on. The cache directory is just like any other caching type of service that will house application files that get changed frequently like cache from browsers and more. The data directory contains all information relating to a user’s data. In this directory, users will be able to change personal settings, read, write, and execute files like media and messages. The misc directory encompasses a series of system settings, which get initialized after a user selects options and typically get triggered by a true or false switch. The system directory is where one can find Android’s operating system files, bloatware applications, and more. The recovery directory is used as a place to hold backup files and the files needed to boot into recovery mode.
Right out of the box, Android users are granted the ability to read, write, and execute files within the data directory, which allow users to get basic functionality out of their phones like looking at images. However, for good measure, the rest of the directories are not easily accessible unless the Android device is connected to a computer.
Testing in Android Emulation
Before getting into the details of bypassing a fingerprint lock screen in emulation, we first needed to figure out how to emulate a fingerprint gesture onto the Android Emulator. In order to accomplish this task, we used the emulator to emulate a “fingerprint touch” event. From a security standpoint, if fingerprints were actually stored by a certain ID number in a database on the Android device, then this could bring about many vulnerabilities. However, since these emulators are primarily used for testing, it is highly unlikely that this will be the case.
In order to emulate how to bypass any type of lock screen, including the fingerprint, we used a virtual Android machine, Android Debug Bridge (ADB), and our knowledge of Android’s file system hierarchy. Upon ADB shelling into the virtual Android machine and navigating to /data/system, we were able to find that there were two files called gatekeeper.password.key and gatekeeper.pattern.key. These two files are the files that are used to store the lock screen information. By just removing the two files listed above and restarting the device, a person now has access to all content on the Android device. The images below show a Google Nexus illustrating the process of bypassing the fingerprint lock screen:
Testing an Actual Android Device
Upon testing the technique used above, my hypothesis began to fall apart as I learned that Android does not allow ADB shell access unless a device has USB debugging enabled. Additionally, without root access, I was unable to modify any of the necessary files. From an adversary perspective, this prevents an attacker from gaining access to a device. However, if a malignant person were able to gain root access through the use of any third party applications or any other brute forcing means, then it is highly possible that this could be a real issue on Android devices.
I attempted to root my actual device to test if I could gain write access to the key files within the /data/system directory. Unfortunately, my Android device had its kernel locked by the vendor which made it impossible to root. As a result, no further testing was able to get accomplished.
Comparing Both Sides
In my emulated test, I found that the only files that were used were the gatekeeper.pattern.key and the gatekeeper.password.key, regardless of whether we chose to use a pin, pattern, or fingerprint lock screen. In contrast, when using an actual Android device, I discovered that depending on the type of lock screen being used, the files that would correspond to the type of lock screen would differ. Additionally, when using a fingerprint as the lock screen, there was the introduction of the personalfingerprintpassword.key file, which was speculated to be the file that housed the fingerprint information. Additionally, the gatekeeper.backuppin.key and gatekeeper.backuppassword.key files were most likely the files that housed the backup password. Furthermore, the biggest difference between both the sides were the types of users. The root user allowed all files to be read, written, and executed. However, the shell user only permitted files to be seen and read.
Conclusion & Future Work
Coming to the end of my experiment, it can be said that my hypothesis failed. Although I was not able to successfully bypass the fingerprint lock screen on an Android device, I believe that this experience was for the better as it gave reassuring footholds to Androids security policy. Likewise, I also believe that the emulated Android operating system and the real Android operating system have differences between the two. I surmise that the emulated Android operating system was designed with restrictions to be ideal for developers when testing their applications while keeping the real Android operating system secure. Personally, I would not have it any other way because in the modern day and age, smartphones like Android devices are literal “computers in our pockets” because of how technology is exponentially evolving.
In the future, it would be better to have multiple Android devices to cover all conditions so that the proper tests could be done. Additionally, attempting to perform this task on fully upgraded Android devices would have also provided a better baseline for future studies.