syssec_red_book

8.4. State of the ArtAll the other information come from reverse-engineering attempts [303] and itis thus hard to compare it to any other research-oriented approach.DroidMOSS [414] relies on signatures for detecting malware in app markets.Similarly, DroidRanger [417] and JuxtApps [207] identify known mobile malwarerepackaged in different apps. Although quite successful, signature-basedtechniques limit the detection effectiveness only to known malware (and itis vulnerable to the adoption of reflection, native code, and obfuscation ingeneral).Enck et al. [168] reported on a study of Android permissions found ina large dataset of Google Play apps, aimed at understanding their securitycharacteristics. Such an understanding is an interesting starting point tobootstrap the design of techniques that are able to enforce security policies [402]and avoid the installation of apps requesting a dangerous combination [169]or an overprivileged set of permissions [178, 312]. Although promising, thepeculiarity of Android apps (e.g., a potential combination of Java and nativecode) can easily elude policy enforcement (when confined to protecting the JavaAPI—as represented by the state-of-the-art) or collude to perform maliciousactions while maintaining a legitimate-seeming appearance. This clearly callsfor continuing research in this direction.Aurasium [402] is an app rewriting framework (Java only) that enablesdynamic and fine-grained policy enforcement of Android applications. Unfortunately,working at the application level exposes Aurasium to easy detectionor evasion attacks by malicious Android applications. For example, regularapplications can rely on native code to detect and disable hooks in the globaloffset table, even without privilege escalation exploits.SmartDroid [413] makes use of hybrid analyses that statically identify pathsleading to suspicious actions (e.g., accessing sensitive data) and dynamicallydetermine UI elements that take the execution flow down paths identified bythe static analysis. To this end, the authors instrument both the Android emulatorand Android’s internal components to infer which UI elements can triggersuspicious behaviors. In addition, they evaluate SmartDroid on a testbedof 7 different malware samples. Unfortunately, SmartDroid is vulnerable toobfuscation and reflection, which make it hard—if not impossible—to staticallydetermine every possible execution path.Anand et al. propose ACTEve [83], an algorithm that utilizes concolicexecution to automatically generate input events for smartphone applications.ACTEve is fully automatic: it does not require a learning phase (such ascapture-and-replay approaches) and uses novel techniques to prevent the pathexplosionproblem. Unfortunately, the average running time of ACTEve fallswithin the range of hours, which makes it ill-suited to automated large scaleanalyses or practical in-device detection.63