This commit is contained in:
parent
19286eba61
commit
eb35d092ac
10 changed files with 170 additions and 43 deletions
22
2_background/9_conclusion.typ
Normal file
22
2_background/9_conclusion.typ
Normal file
|
@ -0,0 +1,22 @@
|
|||
#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.
|
Loading…
Add table
Add a link
Reference in a new issue