#import "../lib.typ": AOSP, eg, DEX, APK, ART, API, ADB
#import "../lib.typ": todo, jfl-note

== Perspectives for Future Work

In this section, we present what, in light of this thesis, we believe to be worthwhile avenues of work to improve the Android reverse engineering ecosystem.

The main issues that appeared in all our work appear to be engineering ones.
The errors we analysed in @sec:rasta showed that even something that should be basic, reading the content of an application, can be challenging.
@sec:cl also showed that reproducing the exact behaviour of Android is more difficult than it seems (in our specific case, it was the class loading algorithm, but we can expect other features to have similar edge cases).
As long as those issues are not solved, we cannot build robust analysis tools.

One avenue that is more research-oriented and that should be investigated would be to reuse for analysis purposes the code actually used by Android.
For instance, the parsing of #DEX, #APK, and resource files could be done using the same code as the #ART.
This is possible thanks to #AOSP being open-source.
However, this is not straightforward.
Dynamic analysis relying on patched versions of the #AOSP showed that it is difficult to maintain this kind of software over time.
Doing this would require limiting the modifications to the actual source code of Android to minimise the changes needed at each Android update.
Another obstacle to overcome is to decouple the compilation of the tool from the rest of #AOSP: it is a massive dependency that needs a lot of resources to build.
Having such a dependency would be a barrier to entry, preventing others from modifying or improving the tool.
Should those issues be solved, directly using the code from #AOSP would allow such a tool to stay up to date with Android and limit discrepancies between what Android does and what the tool sees.

An orthogonal solution to this problem of not being able to analyse edge cases is to create a new benchmark to test the capacity of a tool to handle real-life applications.
Benchmarks are usually targeted at some specific technique (#eg taint tracking), and accordingly, test for issues specific to the targeted technique (#eg accurately tracking data that passes through an array).
We suggest using a similar method to what we did in @sec:rasta to keep the benchmark independent from the tested tools.
Instead of checking the correctness of the tools, this benchmark should test if the tool is able to finish its analysis.
Applications in this benchmark could either be real-life applications that was proven to be difficult to analyse (for instance, applications that crashed many of the tested tools in @sec:rasta), or hand-crafted applications reproducing corner cases or anti-reverse techniques encountered while analysing obfuscated applications (for instance, an application with gibberish binary file names inside `META-INF/` that can crash Jadx zip reader).
The main challenge with such a benchmark is that it would need frequent updates to follow Android evolutions, and be diverse enough to encompass a large spectrum of possible issues.

Lastly, our experience with dynamic analysis led us to believe that there is a need for a new protocol and/or #API for automatic testing.
Currently, except for intrusive methods like instrumentations, interacting with an application is done through a mix of #ADB and UI Automator.
Unfortunately, those tools give very poor feedback.
Information about the execution is mostly found in the Android logs, lost among other system events, and it is difficult to filter the events related to the application without losing critical data.
For instance, exception logs are usually linked to the application in the Android logs, but some exceptions originating from the #ART (and not the code of the application itself) are logged as system errors.
Similarly, an application can fail to install, or successfully install but later be quarantined or uninstalled by the Android operating system, without clear feedback.
Another issue is that more and more, Android will require interactions with the system (for instance, with a security permission pop-up), and those interactions are not handled by UI Automator.
Similarly, when an application opens another one for a specific task (opening a document, for example), what is happening is unclear from the standpoint of UI Atomator.
We think that an #API or protocol that merges and delivers in a structured way all those informations, and allows access to the relevant component (such as a system popup) would be beneficial both for automated testing and dynamic analysis.

Integrating such a protocol into Android would open interesting perspectives.
For instance, we could imagine Google requiring applications requesting critical permissions to provide test inputs with a high code coverage (maybe even 100% of coverage).
Those tests would incentivise application developers to provide better quality code for applications handling sensitive data, but also to provide solutions for the coverage issue that comes with dynamic analysis.
Requiring a high code coverage would force the developer to supply solutions for situations normally requiring human interaction.
For example, if an application requires the user to authenticate themself, the developer would need to provide a testing account that can then be used for tests and analysis.
Of course, we can expect malicious applications to implement evasion techniques when they detect an analysis following the tests they provided, but code coverage can be checked, and imposing constraints on the coverage of the tests should mitigate evasion.
