1. Multi-level information - flow tracking system for Android Runtime
TaintART
Multi-level information - flow tracking system for Android Runtime

2. Background
To upgrade runtime performance, Android launched Android Runtime (ART) environment in 2014, replacing Dalvik VM based runtime environment. With ART, TaintDroid's data flow analysis for new apps became infeasible. Therefore, TaintART was introduced, replacing TaintDroid Just like TaintDroid, TaintART labels (or taints) the variables / sensitive data and tracks down taint propagation and leakage (sinks). However, TaintDroid can at most only support legacy systems up to Android 4.4.
While many applications provide useful services are widely used for comm, photography, entertainment, etc., some also send sensitive information to remote server for various data analytics. Worst yet, some of them can gain profit from these personal data. Malware is a good example of a mechanism that secretly steals information such as contact list without user’s consent.
This is called privacy leakage and it is a serious threat to a large comm of mobile users
Researchers found two solutions of data-flow analysis.
Firstly, with the disassembled code of a given app , researchers can perform static taint analysis. This type of method can statically derive a set of possible data which may leave devices at runtime and decide whether sensitive data leaks to untrusted channels. A problem with this is that it cannot detect runtime information when app developers use code encryption and dynamic code loading techniques.
Therefore researchers proposed to use dynamic methodologies to monitor suspicious behaviors at runtime. This type of analysis will label (or taint) sensitive data from certain sources and handle label transitions (taint propagation or the moving of sensitive data). If a tainted label transmits out of mobile device (i.e if it sinks), one can then monitor the data leakage dynamically. This method is used by TaintDroid (which was later replaced by TaintART when ART replaced the old Dalvik system ) .
TaintDroid (implemented in Android 2.1, 2.3, 4.1, 4.3) utilizes internal mem of Dalvik virt machine for taint storage and propagation. To enhance the performance of Android, Google had recently changed to the Ahead of Time (AOT) compilation strategy and introduced Android RunTime (ART) to replace Dalvik VM starting from Android 5 onward.
ART – performs the translation of application’s bytecode into native instructions that could be later executed by device’s runtime environment
“What is ART and what is Dalvik? Dalvik is the old runtime for your Android device, while ART is the newer, faster more high performing one of the two, but as of yet, isn’t supported by all apps. Dalvik is a ''just-in-time'' runtime which executes code only if it is necessary. On the other hand, ART is ''ahead-of-time,'' where codes are executed before the need presents itself (pre-compiled once on install). ” - ANDROIDPIT

3. Problem TaintDroid’s incompatibility with ART’s AOT strategy
TaintDroid discontinued, TaintART began
TaintDroid’s incompatibility with ART’s AOT strategy
TaintDroid’s lack of performance and compiler optimization
TaintDroid users cannot use policy enforcement to prevent privacy leakage.
An increase in popularity in new version of SDK hindered continual updates for TaintDroid
ART has AOT compilation strategy and unlike the Dalvik way of interpreting code by virtual machine at runtime, AOT directly compiles apps into native code at the first installation time. Thus TaintDroid became infeasible to use in newly – designed runtime.
Secondly, although the latest Android provides a fallback runtime interpreter for debugging, lack of performance and compiler optimization hinders its ability to provide data flow analysis
TaintDroid users cannot user policy enforcement to prevent privacy leakage.
App developers tend to target newer versions of Android so to use latest features that TaintDroid does not support and therefore malware can exploit the incapability of old app versions to bypass security or data flow analysis.

4. Motivation
ART’s improved performance, AOT strategy, improved garbage collection and debugging called for an upgrade on Dalvik based applications Popularity of target SDK versions mean more apps are developed in newer SDK. - New apps would be able bypass TaintDroid operation. - Thus vulnerability increases. Performance race against iOS Need for multi - level taint analysis technique to minimize tag storage and overheads.
TaintART employs a multi-level taint tag methodology to minimize taint storage so that tags can be stored in processor registers for fast access.

5. Idea
Main idea was to develop a new version of TaintDroid that could cater the new high performing ART environment
Decrease overheads and enhance performance
Implements multi – level privacy enforcement
Yield better Macrobenchmark and Microbenchmark results in comparison to TaintDroid in particular
Implement multi – level privacy enforcement that helps prevent data leakage

6. Details
Basic idea of how taint tags are stored in a register.
Spill happens if there is an excess of tags. Tags are spilled to main memory. Both taint tag and variable (register) need spilled else not valid.
In dynamic taint analysis, sensitive data is targeted at any tag at any sensitive function called taint source. A taint tag will be labeled on the sensitive data for tracking. When data is copied or transformed to another place, its taint tag will propagate to the new place. When the data is purged, its taint tag will be cleared. Taint propagation and taint purging is called taint logic. The taint tag storage is where taint tag status for tracking data is stored. Dynamic taint analysis will track the tainted sensitive data and monitor if any tainted data leaves the system at some specific functions called taint sinks.
The register allocator of the TaintART compiler will ensure that R5 will not be assigned for other purposes such as variable storage. The first sixteen bits (from bit 0 to bit 15) will be used for storing taint tags of sixteen registers (from R0 to R15)
Taint Tag Spilling Because a processor has a limited number of registers and not all variables can be assigned to registers, the register allocator will temporarily store ex- tra variables in the main memory. The operation of moving a variable from a register to the main memory is called reg- ister spilling.
Two components taking actions on two separate stages respectively. They are TaintART compiler at installation stage and TaintART runtime at runtime stage.
Four steps to propagate taint status from an R1 variable to an R0 variable for the MOV R0, R1 instruction

7. Macrobenchmark
In contrast with Microbenchmarking, Macrobenchmark merely gives us a birds eye view of TaintART’s performance
Launch time 6% overhead, 12% overhead for installation time
Performance was also evaluated reading and writing contacts in address book. It resulted 20% and 12% overhead on read and write respectively.
In summary, TaintART has introduced an acceptable level of overhead to end– users or to analysts given the volume of information – flow.
- Google Nexus 5, 2.3 GHz CPU with 2GB memory 16GB internal storage. Marshmallow 6.0.1
- Several macrobenchmarks are used to measure the overhead for normal usage
- An app based on SDK. Middle column is an Android UI / application exerciser (i.e. the Monkey tool to launch this app and record the time T_0 . When the activity is been displayed on the screen, we record time T_1.
- Monkey is a command line tool that sends pseudo-random stream of user events into the system, which acts as a stress test on the the application software your are developing.
- T_1 - T_0 ( = 21.1ms) suggests the time elapsed from launch time into app context.
- This overhead is clearly acceptable because most of the logic for launching an app is executed in the native code and TaintART mainly affects runtime performance on the Java environment.
- For installation time, overhead is ms (12%) which are mainly attributed to the instrumented ART compiler.
- For read and write there is a 20% and 12% overhead which is acceptable level of overhead to end - users.

8. Compiler Microbenchmark
Since TaintART uses ART compiler - inserts logic at the compilation time
80 built - in apps were compiled and recorded
Using the TaintART compiler there was
9.9% more overhead.
This is acceptable because Android uses ahead-of-time compilation strategy (app is only compiled once at the installation time).
- Compiler Microbenchmarks - since TaintART uses ART compiler - inserts logic at the compilation time
- 80 built - in apps (including calculator, contacts, browser, download manager, etc) were utilized and compiled and the compilation time was recorded.
- Using the TaintART compiler there 19.9% more overhead. This is acceptable because Android uses ahead-of-time compilation strategy (app is only compiled once at the installation time).

9. Compiler Microbenchmark 2
oatdump disassembles compiled native code and categorizes them into 7 groups
Type II 21% increase.
The increase is primarily in one category, the instructions are mostly
arithmetic (ADD, SUB)
logical (ORR, AND),
movement (MOV, MVN)
For Type I, comparison is minimal (0.8%) because of ART’s AOT strategy.
oatdump disassembles compiled native code and categorizes them into 7 groups
The total number of instructions increase by 21%. The increase is primarily in one category, the data processing instructions category where arithmetic instructions (ADD, SUB), logical instructions (ORR, AND), movement instructions (MOV, MVN), etc.
For Type I, which tends to cost more CPU cycles, TaintART compiler only introduces about 0.8% more instructions. Because of this, the overhead of runtime performance of TaintART is minimal. This means that TaintART can achieve better runtime performance than VM based TaintDroid with the gains of AOT compilation strategy in the new ART environment.

10. Java Microbenchmarking
6 different types were run (10 times) in 5 different runtime environments Google Nexus 5
Compared to the original ART compiler with optimizing backend, TaintART had 14% overhead overall.
Most importantly ART has brought a massive improvement over the legacy Dalvik environment achieving about 99.8% more scores for overall runtime performance.
CaffeineMark – measures the speed of Java programs.

11. Memory Microbenchmarking
This shows the portion of memory occupied by
benchmark process at the runtime.
Since TaintART mainly relies on CPU register for taint tag storage, the overhead on memory usage is only about 0.4%.
TaintDroid had 4.4% memory overhead mainly because it doubles the size of internal stack of Dalvik VM for storing taint tags
CaffeineMark 3 tool was run ten times that monitored /proc/ [pid] /status file at runtime. Figure shows the virtual memory resident set (VmRSS) size at the runtime representing the portion of memory by the benchmark process in memory. Since TaintART mainly relies on CPU register for taint tag storage, the overhead on memory usage is only about 0.4%. For comparison, TaintDroid introduces 4.4% memory overhead mainly because it doubles the size of internal stack of Dalvik VM for storing taint tags, and we avoid this by carefully using the register resources.
In computing, resident set size (RSS) is the portion of memory occupied by a process that is held in main memory (RAM). 

12. IPC Microbenchmarking
Client and a Server applications were developed which communicated via Binder.
Client sends messages to server for setting and getting an object that contains a string and integer field.
This was done 10,000 times and execution time was recorded. An avg of memory usage was also recorded. There are about 4.35% IPC overhead and 4% memory overhead, which is negligible.

13. Conclusion
TaintART (successor of TaintDroid) uses ART compiler and runtime for handling
taint propagation logic
tracking source methods and
report data leakage from sink methods
TaintART employs CPU registers for multi-level taint – tag to minimize storage and achieve fast taint propagation logic
Provides APIs for analysts to track specific data
Implements multi-level privacy tracking system [which can be used for policy enforcement]
Less than 15% overheads on overall CPU-bound microbenchmark [imposes negligible overhead on built– in and third – party apps]
Twice as fast performance compared for Java runtime benchmark.
Less than 15% overheads on overall CPU-bound microbenchmark imposes negligible overhead on built – in and third – party apps.

14. Issues
IMPROVEMENTS
The results might just be slightly different if a couple other Android devices were used, with different specs.
Providing stats on popular taint sinks (leakages).
Discussion on whether taint labels could be maliciously altered to benefit leakage without a trace?
Lack of comparison of with TaintDroid’s benchmark.
A variety of benchmarking were done in detail, However, no example for actual taint sink.
TaintART maintains similar compatibility level when compared with original Android environment i.e. they fail the same tests
A variety of benchmarking recorded and evaluated in detail, However, no example for actual taint sink.
Extra notes:

15. Questions
TaintART – Multi-level Information-Flow Tracking System for Android Runtime