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
|
|
|
|
In this chapter, looked at the specificities of Android and the usual tools used as a basis for reverse engeenering applications.
|
|
Many contributions have been done 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 a 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, maintanability and stealthyness.
|
|
The result of those analysis are often in an ad hoc format, making it difficult to reuse with other tools.
|
|
A few exception as well as some static analysis tools proposed an interesting solution to this issue:
|
|
instrumenting the analyse application to encode the results of the analysis in the form of a valide #APK, a format any Android analysis tools should be able read.
|
|
We liked this solution and believe it should be studied further.
|
|
This process led us to our problem statements:
|
|
|
|
/ #pb1: #pb1-text
|
|
/ #pb2: #pb2-text
|
|
/ #pb3: #pb3-text
|
|
|
|
In the next chapters, we will endeavor to contribute to the Android reverse reverse engineering field by anwsering those problematics.
|