these-android-re/thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

fix 'typos' (yesss, they are definitely typos)
All checks were successful
/ test_checkout (push) Successful in 1m49s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-26 04:21:05 +02:00
parent fede0bd9b2
commit 0d87fae9da
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
11 changed files with 302 additions and 304 deletions
Download patch file Download diff file Expand all files Collapse all files

18
2_background/5_conclusion.typ
View file

@ -2,16 +2,16 @@
== Conclusion <sec:bg-conclusion>
This chapter, presented 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.
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 a platform classes and class loading, a commonly recognised limitation of static analysis.
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, 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.
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:
@ -19,4 +19,4 @@ This process led us to explore three problem statements:
/ #pb2: #pb2-text
/ #pb3: #pb3-text
In the next chapters, we will endeavor to contribute to the Android reverse reverse engineering field by anwsering them.
In the next chapters, we will endeavour to contribute to the Android reverse engineering field by answering them.