Mobile banking vulnerability: Android repackaging threat


Seolwoo Joo

AhnLab Inc., Republic of Korea

Changyeon Hwang

AhnLab Inc., Republic of Korea
Editor: Helen Martin


From a security point of view, Android's openness is one of its down sides. Researchers Seolwoo Joo and Changyeon Hwang show how a repackaged mobile banking app can be used to steal users' banking credentials.

Android is now the most popular smartphone platform. The main feature of Android is openness. Android enthusiasts often install ‘custom ROMs’ on their devices – modified versions of Android OS.

But from a security perspective, the openness of Android can be dangerous. We have researched the Android ecosystem and mobile malware, and have found a critical security threat in the Android ecosystem.

Specifically, we were able to download a mobile banking application from Google Play and inject a malicious function into it using a repackaging technique. We then proved that the repackaged app would be able to leak users’ banking information.

Android issue: repackaging

Using a repackaging technique, source code can be added to the APK (Android package) file. Resources can also be changed. The process is as follows:

  1. Unpack an APK file with apktool. Apktool is an open-source reverse engineering tool for APK files. It can decode resources and rebuild them after modifications.

  2. Decompile the Java source code with JAD. JAD can extract source code from class files.

  3. Modify the Java source and resources using Eclipse.

  4. Rebuild the file using apktool.

  5. Sign the code using jarsigner.

Sequence of repackaging.

Figure 1. Sequence of repackaging.

Android issue: market & unknown sources

There are several easy ways to distribute repackaged Android apps.

Apps can be registered on the official Android market (Google Play), or on various third-party markets. There is no technical test when an app is registered, so anyone who has an account can register their app freely.

APK files can also be installed directly onto smartphones if the ‘Unknown sources’ option is checked. This may cause a very serious security problem.

Unknown source.

Figure 2. Unknown source.

A malware writer could upload a malicious repackaged app to a web page or send it by email. Android users installing the app onto their smartphone won’t notice that it is a repackaged app because it looks and behaves just like the original one.

Android malicious code examples using repackaging techniques

Repackaging techniques that can be used on the Android platform allow malicious code to be disguised as a normal app. It is difficult to distinguish between repackaged malicious code and a normal app because the repackaged app usually appears to function in exactly the same way as the legitimate one. Let’s take a look at some examples of malicious code.


Geimini is a trojan that is bundled into many valid Android apps. The example shown in Figure 3 is a repackaged version of the Monkey Jump 2 game that contains the Geimini trojan – the icon is identical to that of the valid app.

Geimini icon.

Figure 3. Geimini icon.

The permissions that are required during installation are shown in Figure 4.

Geimini permissions.

Figure 4. Geimini permissions.

If the installed malicious code is run, some private information is sent to the attacker via a specific web page. The information that is sent is as follows:

  • List of installed applications

  • List of applications that are running

  • Network status

  • SIM number and phone number

  • SMS information

  • Contacts information

  • GPS information.


The KungFu trojan has been around for a long time. Recently, a new version of KungFu has been discovered bundled with repackaged versions of the Angry Birds Space game. The repackaged malicious app spreads mainly through third-party markets and, when installed, has the same icon as the legitimate version of the game.

The game can be played as normal – so it is unlikely that users will detect the infection.

The permissions that are required for installation differ slightly between the malicious app and the legitimate app, as shown in Figure 5.

KungFu permissions and normal app permissions.

Figure 5. KungFu permissions and normal app permissions.

The KungFu trojan uses the GingerBreak exploit to gain root access to the device and install the malicious code. Once the malicious app is installed, criminals can send commands to compromised Android devices, instructing them to download additional code or push URLs to be displayed in the smartphone’s browser. Infected devices become zombies under the control of the criminals.

Mobile banking vulnerability

Banking apps handle critical financial information, so their security must be strong. We found that most of the banking apps used in Korea are vulnerable to repackaging threats.

Using a proof of concept, we will show how the password for the digital signature certificates used in mobile banking can be hijacked. The process is outlined in Figure 6.

Process of repackaging.

Figure 6. Process of repackaging.

1. Save the banking app to a PC

First, the banking app is downloaded to a PC from the Android device. We used ASTRO, which can be downloaded (free of charge) from Google Play. It has the useful function of backing up Android apps to an SD card.

ASTRO – application backup.

Figure 7. ASTRO – application backup.

2. Decompile

Usually, decompiling PC applications is a complicated task, but Android apps can easily be decompiled by using the open-source tool apktool.

For this process we need only one simple command, as shown in Figure 8.

Decompiling the banking app using apktool.

Figure 8. Decompiling the banking app using apktool.

3. Analysis and injection of malicious code

Once the code has been decompiled it can be analysed to find the part that relates to accessing the digital signature certificate (knowledge of the Java language is required). We found the code easily by searching the string that is shown when the user inputs the wrong password. Figure 9 shows the code that processes the password.

The code that handles the password

Figure 9. The code that handles the password

The ‘c’ which is a member of ‘’ has the password.


197 : iget-object v1, p0, Lcom/softforum/xecure/ui/crypto/SignCertPasswordWindow;->c:Ljava/lang/String;

The SendMsg() function is added so that the string can be sent to the attacker, and two lines are inserted (as highlighted in Figure 9) to call the function into the code phase. The SendMsg() function is shown in Figure 10.

The SendMsg function.

Figure 10. The SendMsg function.

In the same way, a criminal would be able to hijack the user’s sensitive information including their account number, login details etc.

This banking app does not have permission to send SMS messages, so the permission is added by inserting ‘Android.permission.SEND_SMS’ into the AndroidManifest.xml file, as shown in Figure 11.

Modify the XML permissions.

Figure 11. Modify the XML permissions.

4. Build & code sign

The modified code can then be rebuilt using apktool, as shown in Figure 12.

Rebuilding the app using apktool.

Figure 12. Rebuilding the app using apktool.

The code can be signed to build the APK by using jarsigner, as shown in Figure 13.

Code signing using jarsigner.

Figure 13. Code signing using jarsigner.

5. Install malicious app

There are many ways to install the malicious app on the victim’s device. In this example, adb – which is included in the Android SDK – is used for installation (see Figure 14).


Figure 14. Installation.


When the victim launches the repackaged app, every function will work normally, but the password for the digital signature certificate will be sent to the criminal. Since the app appears to work as normal, the victim won’t notice that anything is wrong.

Repackaged banking app and password.

Figure 15. Repackaged banking app and password.


User information can be leaked through repackaged mobile banking apps. Criminals are able to steal victims’ money using stolen user credentials. This could become a very serious problem because the number of users of mobile banking is growing rapidly. It is important for the security industry to find ways of protecting mobile banking apps from repackaging attacks such as this – as well as finding ways to protect other apps that deal with sensitive user information.



Latest articles:

Powering the distribution of Tesla stealer with PowerShell and VBA macros

Since their return more than four years ago, Office macros have been one of the most common ways to spread malware. In this paper, Aditya K Sood and Rohit Bansal analyse a campaign in which VBA macros are used to execute PowerShell code, which in…

VB2017 paper: Android reverse engineering tools: not the usual suspects

In the Android security field, all reverse engineers will probably have used some of the most well-known analysis tools such as apktool, smali, baksmali, dex2jar, etc. These tools are indeed must‑haves for Android application analysis. However, there…

VB2017 paper: Exploring the virtual worlds of advergaming

As adverts in gaming (‘advergaming’) ecosystems continue to become more sophisticated, so the potential complications grow for parents, children and gamers, who just want to play without having to worry about where their data is going (and how it is…

Distinguishing between malicious app collusion and benign app collaboration: a machine-learning approach

Two or more mobile apps, viewed independently, may not appear to be malicious - but in combination, they could become harmful by exchanging information with one another and by performing malicious activities together. In this paper we look at how…

VB2016 paper: Wild Android collusions

Mobile operating systems support multiple communication methods between apps. Unfortunately, these handy inter-app communication mechanisms also make it possible to carry out harmful actions in a collaborative fashion. Two or more mobile apps, viewed…

Bulletin Archive