Reference no: EM132295620 , Length: word count:1000

Assignment - Repackaging Android apps to disclose sensitive information

Each student needs to choose an Android app and repackage it.

Tasks -

1) Choose an Android app

Ideally, choosing popular apps on Google Play.

After repackaging, if the app can no longer be installed, you need to change another app for repackaging.

Reporting this and explain why it cannot be installed can be a plus to this assignment.

2) Select the location where the code will be changed.

This can be a single place or multiple places. The complexity of considered places will be taken into account when marking.

3) Do the actual change (attack).

Here various tools can be leveraged.

For simplicity, ApkTool can be used to modify the code at the Smali code level.

For flexibility, Soot can be leveraged to instrument the code in Android APK files.

No matter which tool is selected, the final attack should be done automatically.

4) Demonstrate the change via video and write the process in a report.

Android Repackaging Attack Lab -

Lab Tasks -

Task 1: Obtain An Android App (APK file)

To launch the repackaging attack, we need a host app. In real attacks, attackers usually choose popular apps, because they can get more people to download their repackaged apps. For this task, you can write your own app or download an existing app.

It should be noted that we are using an Android VM in this lab, not a physical Android device, so some apps may not run on the VM (they will crash). One of the possible reasons for crashing is that the application may have native code. Native code compiled for a real Android device has binary code for ARM processors, while our Android VM runs on x86 processors. To get these apps running in our Android VM, the native code needs to be recompiled for x86 processors. That requires source code, which is hard to get. Therefore, if you have encountered this problem, just find another app. This limitation is only caused by the lab environment, and it is not an issue for the attacks in the real world.

Task 2: Disassemble Android App

To launch the repackaging attack on an app, we need to modify the app. Although we can directly modify the APK file, it is not easy, because the code in the APK file contains Dalvik bytecode (dex format), which is not meant for human to read. We need to convert the bytecode into something that is human readable. The most common human readable format for Dalvik bytecode is known as Smali. The names "Smali" and "Baksmali" are the Icelandic equivalents of "assembler" and "disassembler", respectively.

In this task, we will use a tool called APKTool to disassemble dex code (classes.dex) to smali code. APKTool is a very powerful reverse engineering tool for Android apps. It is useful to decode and rebuild Android apps.

Task 3: Inject Malicious Code

In this task, we will inject malicious code into the target app's smali code. There are many ways to do that. One approach is to directly modify some existing smali file, so we can add malicious logic into it. Another approach, which is much easier, is to add a completely new component to the app; this new component is independent from the existing app, so it does not affect the app's behavior. Since each independent component can be placed in a separate smali ?le, using this approach, we just need to create a new smali file.

Task 4: Repack Android App with Malicious Code

After we have inserted your own malicious smali code, we are ready to reassemble everything together, and build a single APK file. The process takes two steps.

Step 1: Rebuild APK - We use APKTool again to generate a new APK file. The command is shown in the following. By default, the new APK ?le will be saved in the dist directory.

Step 2: Sign the APK file - Android requires all apps to be digitally signed before they can be installed. This requires each APK to have a digital signature and a public key certificate. The certificate and the signature helps Android to identify the author of an app. From the security perspective, the certificate needs to be signed by a certificate authority, who, before signing, needs to verify that the identify stored inside the certificate is indeed authentic. Getting a certificate from an accepted certificate authority is usually not free, so Android allows developers to sign their certificates using their own private key, i.e., the certificate is self signed. The purpose of such self-signed certificates is meant for apps to be able to run on Android devices, not for security. Developers can put any name they want in the certificate, regardless of whether the name is legally owned by others or not, because no certificate authority is involved to check that. Obviously, this entirely defeats the purpose of certificate and signature. Google Play Store does some name verification before accepting an app, but other third-party app markets do not always conduct such a verification.

In this lab, we will just use a self-signed certificate. The entire process consists of three steps.

1. Step 1: Generate a public and private key pair using the keytool command.

2. Step 2: We can now use jarsigner to sign the APK file using the key generated in the previous step.

Task 5: Install and Reboot

In this final step, we will install the modified app on our Android VM, and test whether the attack is successful or not. We need to connect to the Android VM using the "adb connect" command from our Ubuntu VM, and then install the app using the "adb install" command. We need to know the IP address of the Android VM; we can ?nd it on Android by going through the following process: SettingsApp - About - Status. We can also ?nd the IP address by running the netcfg command in Android terminal app.

To demonstrate whether the attack works, we just need to add a few contacts in the Contacts app, turn off the Android VM, and start again. If your attack is successful, you should see that all the contact records that you just entered are deleted.

A common problems. We need to launch the installed repackaged application once to register the receiver. Otherwise, the injected code will not be executed if we just reboot the VM after the installation.

Questions -

After finishing all the lab tasks, you need to answer the following questions in your lab report.

Question 1: Why is the repackaging attack not much a risk in iOS devices?

Question 2: If you were Google, what decisions you would make to reduce the attacking chances of repackaging attacks?

Question 3: Third-party markets are considered as the major source of repackaged applications. Do you think that using the official Google Play Store only can totally keep you away from the attacks? Why or why not?

Question 4: In real life, if you had to download applications from untrusted source, what would you do to ensure the security of your device?

Attachment:- Assignment Files.rar