Show me your Kung-Fu. Reversing/Forensic Android

The last week was held in Barcelona the NoConName security conference, and I had the pleasure of attending to give a security conference about Android. It talked about how to perform a dynamic analysis, static and forensic skip protection and release application along with our friend of MalwareIntelligence too, Ehooo, a small PoC reveals a vulnerability of Tap-Jacking.

For those who could not attend on these lines you can find a brief summary of what my conference, so it can access all the information that was used from the following links:

 ^·        Slides: http://www.slideshare.net/0xroot/malware-intelligence-pptslides

^·          Source Code: http://code.google.com/p/tap-android/

^·          Video: http://www.youtube.com/watch?v=VN_IR2vUMAw

Riding the laboratory

When analyzing any application on the Android platform, we must clearly distinguish between static and dynamic analysis. As the first study level application code to understand the workings of it and study the features it has, and the second based on the behavior that once executed the application in order to study the connections established with network.

For each of them will be necessary to use a different set of tools that vary according to our purpose.

Static analysis
  · Dex2jar - Allows to convert class files to *. dex files *. jar to be later rotten abierto y editaros specific IDE for them to work it.
· Jd-gui - Load *.jar files and it lets you view them in code java classes that you componen.
· JAD - Turn them files to *. class *.JAD files with the intention of subsequently being loaded onto it su Understand for analysis.
· Dexdump - tools included it in the Android SDK that it allows all code desensamblar it the file *.dex Dalvik Bytecode.
· Understand - Excellent tool to analyze, disseminate, and review the operation and the flow of calls made ​​between the various methods that have been declared in the application source code.
· Axml2print - Learn To clear it AndroidManifest.xml.

Others tools:

Androguard - http://code.google.com/p/androguard/

Droidguard - http://code.google.com/p/droidguard/

Apk-tool - http://code.google.com/p/android-apktool/

Dynamic analysis
1. Create a virtual machine making use of the SDK.
2. Launch the emulator on a given port and store the connections

a.      Emulator –port n @device-name –tcpdump foo.pcap

3.       Install the application to analyze

a.      adb install foo.apk

4.       Launch events on the device and the application

a.      adb shell monkey –v –p package.app n

5.       To analyze the logs created

a.      adb shell logcat –d

6.       Rely on Wireshark to analyze the connections made.

(1)  The fact of throwing events on the device is because on occasion some applications or malware to occur need special circumstances to be operational. See the receipt/sending an SMS, an incoming call from a phone number, etc.

All these activities can be simulated using the following commands:

·         Phone calls

o   Gsm call p-n

o   Gsm accept p-n

o   Gsm cancel p-n

·         SMS

o   Sms send p-n text

·         Change GPS

o   Geo fix -13… 21…

Modus Operandi

If your goal is to begin to analyze applications without having to introduce you to the ins and outs of the Android platform, a modus operandi that can serve is as follows:

·         AXML2Print - Remove the permissions required by the application of AndroidManifest.xml
· Dex2Jar / JAD - To perform code transformations needed.
· JDGUI - To analyze the class files *.jar
· Understand - To make a static analysis of code and get the flow charts of the functions that make up the application.
· Wireshark - To perform the dynamic analysis of the application and see the connections you make.

Forensics

To perform a correlation of the file system is necessary to have root permissions on the device, this can be achieved thanks to various exploits or applications that can be found without too much difficulty, and an explanation of their proper use.

When you lift the phone a shell we see that the system is based on Unix and that the filesystem is mounted as follows:

$ mount

rootfs / rootfs ro,relatime 0 0

tmpfs /dev tmpfs rw,relatime,mode=755 0 0

devpts /dev/pts devpts rw,relatime,mode=600 0 0

proc /proc proc rw,relatime 0 0

sysfs /sys sysfs rw,relatime 0 0

none /acct cgroup rw,relatime,cpuacct 0 0

tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0

none /dev/cpuctl cgroup rw,relatime,cpu 0 0

/dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0

/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0

/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0

So there are several different mounting points for each directory mtdblocks important in our telephone:

·         /systen mount in /dev/block/mtdblock3

·         /cache mount in /dev/block/mtdblock4

·         /data mount in /dev/block/mtdblock5

And in case you have an SD card, can be found in /sdcard.

The necessary step to make a correct correlation is to use the dd command to pull together to bring us the image we make the system work to our local environment:

# dd if=/dev/mtd/mtd5 of=/sdcard/data/mtd5.img bs=2048

100480+0 records in 

100480+0 records out

205783040 bytes transferred in 108.504 secs (1896547 bytes/sec)

sebas@Helios:~/Android/sdk/platform-tools$ sudo ./adb pull /sdcard/data/mtd5.img /home/sebas/Android/research/mtd5.img

1799 KB/s (205783040 bytes in 111.650s)

So the process to be as trivial as grep the output for certain strings that can serve useful:

sebas@Helios:~/Android/research$ strings -a ./mtd5.img | grep databases | more

...

/data/data/com.android.providers.contacts/databases/contacts2.db-journal

/data/data/com.google.android.gsf/databases/talk.db-journal

/data/data/com.google.android.gsf/databases/talk.db-mj157DA2E7

...

Concluding that the information in the applications installed on the phone is in the path:

·         /data/data/package.app/databases/…

So the process will be as trivial as the files you want to bring us back to our work environment for further analysis.

By bypassing the protections
To skip the protections of Google there are two possible methods:

Manually:

1.       Disassemble the code using Baksmali:

a.       sebas@Helios:~/Android/research/protection/com.yoyogames/bcode/com$ java -jar baksmali-1.2.6.jar -x -o baksmali_code ../../Android/research/protection/com.yoyogames/classes.dex

2.        Make the following modifications of code in the license file check (./baksmali_code/com/android/vending/licensing/LicenseChecker.smali)

a.       We modified the method checkAccess with the following code  http://pastebin.com/FHfaD6WU

b.      We modified the method handleServiceConnectionError with the following code  http://pastebin.com/fHS8Kp8p

3.       We packed up the application again using the tool APKTool

4.       We signed the application JarSigner

a.       sebas@Helios:~/Android/sdk/tools$ jarsigner -verify -verbose -certs ~/Android/research/protection/com.yoyogames/prueba.apk

5.       Used Zipalign for optimization and efficiency issues:

a.       sebas@Helios:~/Android/sdk/tools$ ./zipalign -v 4 ~/Android/research/protection/com.yoyogames/prueba.apk ~/Android/research/protection/com.yoyogames/prueba-final.apk

6.       Install the application and enjoy.

Automatically
We use the tool Anti-LVL (http://androidcracking.blogspot.com/p/antilvl.html) developed by Lohan Plus:

sebas@Helios:~/Android/sdk/tools$ sudo java -jar antilvl.jar -f ~/Android/research/protection/com.yoyogames.droidtntbf-1.apk pruebafinal.apk

So that with a simple and easy step will automatically perform all steps of the manual method.

Tap-Jacking Vulnerability

The vulnerability is found and exploited due to the trust model that is available Android applications, allowing certain permissions to open dialogues with the user, so that it can make decisions that the application itself can not.

A malicious application that exploits this vulnerability can open a dialogue TapJacking privileges and place an opaque layer above this happens all the screen events to the layer directly below. Getting in this way to make calls, send messages, clicks on ads, banking, all while the user is not aware of it.

The ruling was achieved following the Toasts, special kinds of dialogues, which unlike the "Activities" allowed overlaps the current activity of the application while this screen events were passed to lower layers.

These principles have a look that distinguishes the normal dialogue, could be modified in size and behavior, as you can see in the video that is uploaded.

The vulnerability, edited at first by Google, affects all current versions Android phones. Therefore the risk remains quite high. They developed a total of 4 payloads to test its operation:

·         CallPayload.java – Make phone calls to the number indicated.

·         MarketPayload.java – Download and install applications on the market.

·         ResetPayload.java – Returns to factory phone.

·         SMSPayload.java – Send a text message back to us.

 And the internal structure is as follows:

·         Main.java – Run the main service and cargo payloads.

·         MalwarePayload.java – Internal abstraction to facilitate the implementation of new payloads.

·         MalwareService.java – Creates toast e process starts tap-jacking.

·         Main.xml – Does the layout of the application, launching with an onClick event each payload.

·         Strings.xml – Contains the strings that are used in the application.

Conclusion
After this brief summary and research befell I have some questions for space:

• In the issue of protection of applications, does the developer's fault for not taking adequate protective measures, or Google is to blame for having a system as 'infallible'?
• Google is concerned to fight against Malware? Or is it a battle that is lost from the start?
• Is it necessary to keep learning new versions instead of correcting errors in the previous there? We promote the progress of the platform, versions or fragmentation inevitable?
• Do you have to protect our data? Can we rely on the protection offered by Google? Nearest Compensates have our digital life knowing the danger we run?

Sebastian Guerrero  

Crimeware Research