BareDroid Presenter: Callan Christophersen

What is BareDroid BareDroid is a system to analyse Android apps on real devices with no emulation. It uses dynamic analysis techniques.

Purpose of BareDroid 1.Provide a feasible solution to smart malware that can detect emulators. 2.Provide the same functionality and scale for a similar price as emulators.

The Problem – Emulator Detection 1.Static artefacts. (e.g. flags) 2.Dynamic artefacts. (e.g. sensor input) 3.Hypervisor artefacts. (e.g. caching policies)

Problem 1 - Static artefacts An emulator can be discovered by: – Checking the number of cores. Most emulators only report one. – Checking the build model: build.MODEL =="google_sdk” (google bouncer). – Checking the sim IMSI or IMEI for GSM devices. – Checking if the device supports USB OTG. No emulator supports this. – Checking the network hardware configuration. Solution: Build more complete emulators or simply use real devices to test with.

Problem 2 - Dynamic artefacts Emulators can be detected by checking: – Can the device receive SMS. – Does the GPS fix ever change. Does the number of satellites change. – Do the WiFi/Bluetooth/RFC connections ever change. – Does the device move. Accelerometer, tested by making device vibrate – Does putting load on the CPU cause a change in the internal voltage. – Does the battery experience drain… and so on… Solution: It is very very hard to emulate all these thing to the point where if your emulator does not perfectly resemble a real device, it can be fingerprinted and evaded. So either build the perfect emulator or test on real devices.

Problem 3 - Hypervisor artefacts Fingerprinting the hypervisor: – Behavioural fingerprints: CPU has a known bug which is not emulated Model-Specific Registers. E.g. if the emulator allows you to use a register that the real CPU would not. – Timing attacks: Relative performance differences between hypervisors and real devices can be detected and this ratio can be used to identified the hypervisor. E.g. Qemu. – Hardware Specific Values: Peripherals such as IDE/SCSI devices must be emulated to be used. These devices are usually emulated in a characteristic way which means that these characteristics can be used to identify a specific hypervisor. Solution: it is not clear that these issues can ever be overcome by better engineering of hypervisors. We can however test apps with real devices.

So why do we use emulators? Speed. Emulators can be reset to a known safe state very fast. Scalability. Emulators can be copied to scale horizontally cheaply. To compete BareDroid would need to be able to reset real devices fast. To be feasible BareDroid would need to scale for a similar price point. – BareDroid does scale for less than twice the price of emulators.

How BareDroid works The data that needs to be restored can be seen as a set of partitions. BareDroid relies on a kernel-level mechanism to lock a partition (mark it read only). BareDroid treats the system partitions differently from the user partitions. – System partitions use a chain of trust. (modified infrequently) – User partitions use a swap system. (modified frequently)

System Partitions Rarely modified. Since they contain: – Bootloader, Recovery, kernel etc. An initial partition is restored to a safe state and it is then used to check a subsequent partition. This process iterates over all system partitions. The checks are simply a verification that the data of the partition has been signed with one of the keys in the embedded keystore such as the OEM key. If a check fails then that partition is restored. S1S2S3Sn Checks Checks… …

DM-Verity Dm-verity is a kernel mechanism which verifies each block of the system partition against a hash tree. Where the root hash has been verified by the previous partition. The system partition is checked in this way because of its size. Performing this kind of check allows this partition to be checked as it is being accessed.

User Partitions U 1, U 2, U 3, U 4, U 5, U 6, …, U n U’ 1, U’ 2, U’ 3, U’ 4, U’ 5, U’ 6, …, U’ n Û 1, Û 2, Û 3, Û 4, Û 5, Û 6, …, Û n App tested here Background thread restores U i ’ from Û i Dirty copy Clean copy Background thread restores U i from Û i Modified often since they contain all the user data like the apps. To allow for fast(er) restore times 3 copies of each partition are used: 1.A permanent clean copy, Û. Kernel lock is needed here. 2.A testing copy, U. 3.A copy to be restored, U’.

Restoring a partition When one of the checks fails the partition that the check refers to must be re-flashed. In the case of user partitions this happens automatically for each new analysis. In the case of the system partitions, these must be re-flashed between analyses. – This performance hit is not very great since the system partitions are typically quite small.

Mass analysis BareDroid operates in a phone cloud where management software starts the BareDroid process on each device and loads the apps to be tested. The management software interacts with the devices over ADB.

Evaluation – Analysis Technique BareDroid’s analysis is based on a modification to the SELinux policy for keeping records of system calls. From the results BareDroid can use this to determine if an app has done something malicious.

Evaluation – Effectiveness Table of known emulator sensitive malware file actions and their detections. *App crashed upon start, possibly due to emulator checks.

What if SELinux breaks? Then the Kernel lock on Û will no longer work. – A fix for this is to periodically check the hash of Û. An attacker could target the aboot partition and others trying to avoid BareDroid’s partition checks. – This would most likely be discovered since it would cause an irregular boot. In addition to this it is unlikely that an attacker would use a Linux kernel zero-day just to target BareDroid when they would most likely be caught. – BareDroid could recover by simply hard rebooting.

Evaluation - Speed According to Dr Robert Sheehan at UOA: “a response time of 0.2 seconds is noticeable, more than 5 seconds is unacceptable.” Well… Checking and restoring step: – With no errors: Seconds – If dm-verity detects errors: Seconds Full device restore: Seconds Emulator restore: ~1 Second

Evaluation - Cost BareDroid cost per device: US $349 Emulator-based system cost per CPU: US $300

Improvements BareDroid could be stored and run from network shared drives in servers. This would considerably speed up the restore process. It would also remove the need for on device code for restores making previously discussed attacks impossible. Disadvantages: – Increased cost. The hardware required isn’t cheap. – Because of the commonality of the hardware involved the fingerprintability of BareDroid would be increased.

References Android source site: Detecting System Emulators by Thomas Raffetseder, Christopher Kruegel, and Engin Kirda: doc/isc07_detection.pdf doc/isc07_detection.pdf BareDroid paper available on course webpage: 15_ACSAC_Baredroid.pdf 15_ACSAC_Baredroid.pdf

Thanks Questions?