#import "../lib.typ": APK, pb1, pb2, pb3, pb1-text, pb2-text, pb3-text

== Conclusion <sec:bg-conclusion>

This chapter presented the specificities of Android and the usual tools used as a basis for reverse engineering applications.
Many contributions have been made to static analysis, and benchmarks have been proposed to compare the different tools that resulted from those contributions.
Those benchmarks raised questions about the reusability of those tools and their capacity to handle real-world applications.
We then looked at platform classes and class loading, a commonly recognised limitation of static analysis.
Because of that, the issue is generally relegated to dynamic analysis, leaving the details of the class loading mechanisms of Android unexplored.
To complement static analysis, we continued by looking at dynamic analysis.
A variety of approaches have been proposed, balancing ease of use, maintainability and stealthiness.
The results of those analyses are often in an ad hoc format, making it difficult to reuse with other tools.
A few exceptions, as well as some static analysis tools, proposed an interesting solution to this issue:
instrumenting the analysed application to encode the results of the analysis in the form of a valid #APK, a format any Android analysis tools should be able to read.
We liked this solution and believe it should be studied further.
This process led us to explore three problem statements:

/ #pb1: #pb1-text
/ #pb2: #pb2-text
/ #pb3: #pb3-text

In the next chapters, we will endeavour to contribute to the Android reverse engineering field by answering them.
