Introduction
Malicious applications are a significant threat to Android users. There have even been cases of malicious applications on the official Google Play marketplace. However, malware authors and legitimate developers struggle with the same problem, getting people to download their apps.

For a malicious application to be profitable it should be appealing enough for a user to install it and functional enough to receive positive reviews and remain on the market. Rather than design novel applications, many malware authors have been injecting malicious content into benign applications and peddling their plagiarized software to unsuspecting users. This practice of modifying existing applications has been labelled “repackaging”.

Repackaging enables rapid production of ostensibly unique malicious applications. The same payload can be injected into any number of unique benign applications. The benign code from each application will act as camouflage to hide the payload since malware analysis systems can be confused by the amount of benign information.

Zhou and Jiang (Zhou, Jiang, 2012) extensively surveyed and analysed Android malware and found that 86% of the malware collected were repackaged. Several noteworthy malware authors had repackaged paid apps, popular games, and even security updates.

An intuitive means of repackaging injects independent classes into an application. Android applications can have multiple entry points, so it is possible for malicious code to begin execution without interacting with benign code. For example when a repackaged application starts it can initiate both benign and malicious functionality. The next section will discuss steps involved in this form of repackaging.

How To Repackage
The first step is creating a malicious application that implements the intended payload. The payload should be initiated by an event such as the application starting or a phone call being received. This application should be compiled and tested. A simple example is an application that abuses its permissions to send user information to an attacker’s server.

Once the malicious application has been prepared it’s payload can be extracted. Apktool is a reverse engineering tool that allows assembly and disassembly of Android applications. Disassemble the malicious application and extract the directory containing classes relevant to your payload. Don’t forget to include the code that initiates malicious activity when the desired event happens. It may seem redundant to compile then disassemble, but the process puts the payload in a format more amiable to injection into a disassembled benign application.

Third, download a suitable benign application for repackaging. Ideal targets are popular and require permissions similar to those required by the payload. If necessary use a tool such as AirDroid to transfer the application from an Android device to a PC. This application will be disassembled by Apktool or a similar tool.

The classes extracted from the malicious application are inserted into the class directory of the disassembled benign application. The AndroidManifest.xml file must be modified to include awareness of any new classes, permissions, or libraries added to the application. Finally the modified application is assembled with Apktool and signed with a new key. At this point the repackaged application is ready for distribution.

Related Work
Zhou et al. created a tool named DroidMOSS for detecting repackaged applications in third-party Android marketplaces (Zhou, Zhou, Jiang, Ning, 2012). This system uses a rolling hash to detect similar applications and determines if similar applications have the same author’s signature. If the apps are similar, but the signatures differ then one of the apps is likely repackaged.

Aurasium (Xu, Saïdi, Anderson, 2012) demonstrates that repackaging can be beneficial to legitimate developers as well. This service automatically repackages Android applications to enable sand boxing and policy enforcement. Once these applications have been repackaged by Aurasium they will notify the user and request permission before they attempt to perform any suspicious activities.

The SRL has been working on a means of separating malicious components from benign in repackaged applications (Walenstein, Deshotels, Lakhotia, 2012). This method uses graph centrality to analyse relationships between classes in an application. Classes that have unusually low coupling with the rest of the program are suspected as injected components.

Future Work
Researchers interested in repackaging can pursue several solutions to the problem. Tamper proofing to prevent repackaging would protect developers and limit the amount of vulnerable applications available to attackers. Detection systems that identify repackaged applications can keep markets and devices free of this type of malware. Campaigns to raise user awareness may train users to identify plagiarized applications before they install them.

References