Themes, questions, and long-term directions

Android apps are built upon several components that communicate together through Inter-Component Communication (ICC) mechanism. Modeling ICC is a key in Android apps static analysis to ensure data flow tracking through components, as reported by IccTA. However, a substantial number of ICC methods were overlook by the state of the art, leaving room to a lack of precision in app modeling. Indeed, I noticed that ICC can be triggered through what I called Atypical ICC methods (AICCM). To cope with this limitation, I built RAICC, an approach that is AICCM-aware. Hence, existing static approach can rely on RAICC to perform more complete analyses

Nowadays, one of the main goal of malware writers is to evade analyses. One prominent technique used to stay under the radar of dynamic analyzers is to use logic bombs. This mechanism triggers the malicious only under specific circumstances. As a challenging and unresolved problem, I tackle this problem with static approaches. After replicating existing approaches, I contributed to the research effort by proposing an hybrid approach, namely Difuzer, combining static analysis and anomaly detection

Sensitive data is a topic that has received a lot of attention in recent years, especially with the increasing importance of privacy and security in our digital world. However, there is no clear consensus or formal definition of what constitutes sensitive data in the context of software. This makes it difficult for analysts and algorithms to determine, statically, what data should be considered sensitive during data flow propagation. Currently, the most common approach is to use a user-defined list of methods that are supposed to return sensitive values. However, building such a list remains an open problem. That's why I believe it's time to take a closer look at the latest legal frameworks, such as the General Data Protection Regulation (GDPR), to gain a better understanding of what constitutes sensitive data. By exploring these frameworks, we can potentially excavate definitions that can be used for static analysis and improve the accuracy of our analyses

In Android apps, dex bytecode cohabits with many other languages (e.g., native code or JavaScript). Due to the challenge presented to unify all code representations, existing approaches focus on dex bytecode and overlook other language components. This limitation is a severe threat to validity since malicious behavior can be implemented in any language, thus in any part of an app. Therefore, I have the ambition to propose a static model to unify all code representation in Android apps. I proposed a first step, called JuCify, toward this direction at the call-graph level and with more granularity at the statement level relying on heuristic-based defined statements with binary code in Android apps

Android apps are driven by user behavior and communicate heavily with the Android framework. This communication triggers many implicit mechanisms, such as callbacks or jobs, that activate developer code. Consequently, malicious code or vulnerabilities can easily go unnoticed during traditional static analysis. That's why I believe that the Android framework requires systematic investigation. Through my research, I aim to thoroughly examine and understand these implicit mechanisms, and to identify any potential threats that may be missed by other analysis methods