Android software developers often use third-party libraries like mobile payment, database, and game engines to build their applications. Most of these libraries are close-source, making the developers unable to change them. However, usage of these libraries could bring security issues to their applications. For instance, a payment engine might have an internal log print intended for debugging that might leak a user’s login credentials. It is also possible for a game engine to have some scripts and resources saved locally in plain text, which is prone to theft by a hacker.
Most android applications are written in Java, but when software developers need low-level API access, they write their code in C/C++ and compile it into a native library. Afterwards, they call it through the Java Native Interface. When a developer finishes writing an app’s code, they use Android SDK tools to pack all the resource files, data and compiled code into an Android Package.
All android applications are packed, shared and installed in the APK format, which can be extracted like a regular ZIP file. When an APK file is extracted, some vulnerable parts of the application that attackers can exploit get exposed. One of those weak points is a folder called “assets”, which stores the application’s raw data. In a game engine, this data could include texture resources for game scenes, audio and video files, and the game’s logic script files. All these crucial files can be easily accessed because APK files are not encrypted and can be easily transferred from another Android device.
Another vulnerability can be exploited in the application if installed on a rooted android device. This is the weak file access controls on both rooted android devices and external storage devices like SD cards. Through the root privilege of a user’s device, an attacker can gain access to an application’s private data. Likewise, the attacker can get the data easily if it is written on an external storage device. If that private data is not encrypted, the attacker would easily see the user’s login information. Furthermore, the attacker might also be able to view the app’s debug information with a tool called Logcat.
Additionally, the exposure to these vulnerabilities means the applications are prone to hooking. Hooking is the replacement of an existing code in a program with a custom code. Sometimes this custom code can be placed either after or before the existing code without removing it entirely.
For instance, a hacker can write a code and hook it to the login page of a mobile application. This code will alter the usual login page and demand more sensitive information from an unsuspecting user. This is done mainly with a software called Frida, which lets people hook into applications and input their JavaScript code, which would interfere with running processes. Expert app developers are usually adept at using Frida to find hooks in their application for them to remove the intrusive code to restore the software to its normal functionality.
Endnote
Android app developers should ensure their applications cannot be easily ripped apart to reveal vulnerabilities, which can endanger the user. They should only use secure third-party libraries for their app development and encrypt vital information. Lastly, they should beware of hooking and regularly use software like Frida to find hooks in their code.