Towards Automatic Triggering of Android Malware

Adrien Abraham (1) , Radoniaina Andriatsimandefitra Ratsisahanana (1) , Nicolas Kiss (1) , Jean-François Lalande (2, 1) , Valérie Viet Triem Tong (1)

1 CIDRE - Confidentialité, Intégrité, Disponibilité et Répartition
2 LIFO - Laboratoire d'Informatique Fondamentale d'Orléans

An important part of malware analysis is dynamic analysis. Dynamic analysis try to defeat the techniques used by malware developers that hide their malicious code using obfuscation, ciphering, stealth techniques, etc. For example, a malicious developer can simply delay the execution of his malicious code for a certain period of time. His goal is to be sure that the malware runs on a device of a real user and not on an analysis platform. Thus, the major constraint with dynamic approaches is that their efficiency relies on the effective observation of the malicious behavior. For automating application executions, a first framework [1] proposes to stress applications by sending pseudo-random streams of user events such as clicks, touches, or gestures, and system-level events. Better than a monkey, Dynodroid [2] generates more relevant UI and system inputs. Nevertheless, for a lot of malware we are far from triggering their behavior. Android malware are regularly a repackaged version of regular applications: the malicious code is dissimulated inside the initial code. From a quantitative point of view, an android application is a collection of bytecode instructions that can represent a lot of possible execution paths. The previous cited approaches mainly focus on the test of the application and cannot cover all possible execution paths: using these techniques will certainly not reveal interesting observations for the malicious behavior. We are currently working on a solution to automatically identify suspicious parts of the code and then to trigger its execution. Our approach is divided into three steps. The first step resorts to static analysis: we define a scoring function that computes an indicator of risk for each method in the bytecode. The second step consists in computing an execution path that leads to the code identified as the most dangerous. The third step enables to modify the bytecode in order to force this particular execution path. This last step is the most tricky: it requires to change the control flow and to generate the right UI events in order to succeed in executing the suspicious code.

Domaines: Cryptographie et sécurité [cs.CR]

Adrien Abraham, Radoniaina Andriatsimandefitra Ratsisahanana, Nicolas Kiss, Jean-François Lalande, Valérie Viet Triem Tong. Towards Automatic Triggering of Android Malware. 12th International Conference on Detection of Intrusions and Malware & Vulnerability Assessment, Jul 2015, Milano, Italy. ⟨hal-01168354⟩