Jean-Marie 'Histausse' Mineau
0d87fae9da
All checks were successful
/ test_checkout (push) Successful in 1m49s
22 lines
1.6 KiB
Typst
22 lines
1.6 KiB
Typst
#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.
|