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

finish ch5

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-22 01:40:29 +02:00
parent cc4ecf28fe
commit 039970904e
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
4 changed files with 48 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

32
5_theseus/1_introduction.typ
View file

@ -2,14 +2,28 @@
== Introduction <sec:th-intro>
#todo[
Expliquer qu'a la lumiere de @sec:rasta et @sec:cl, le reverser a des pbs:
les outils plantent parfois, et a cause de l'obfuscation il a envie de pouvoir modifier le code
Mofigier ke cide sugnifie obtenir une nouvelle application dont on avait patché la partie qui pose pb.
Par example on voudait patcher les applis reflexifs (citer la concurence), les chargement dynamique, etc.
#todo[Reflectif call? Reflection call?]
L'interet de patcher une app est qu'ensuite on peut donner cette APK a un outils d'analyse, cf @sec:rasta.
Dans ce chapitre, on va donc presenter...
]
In the previous chapter, we studied the static impact of class loaders.
Doing so, we ignored the main usage of class laoders by developpers: dynamic code loading.
In this chapter, we tackle this issue, as well as the issue of reflection that often comes with dynamic code loading.
Dynamic code loading is the practice of loading at runtime bytecode that was not already part of the original bytecode of the association.
This bytecode can stored as assets of the application, downloaded from a remote server, or even generated algorithmically by the application.
This is a problem for analysis: when the bytecode is not already visible in the application, it cannot be analysed statically.
Meanwhile, reflection is the action of using code to manipulate object representing structures of the code itself, like classes or methods.
The main issue for analysis occures when it is used to call methods.
A static analtysis will show calls to `Method.invoke()`, but not the actual method invoked.
#todo[Section méthodologie avec le schemat]
In both cases, static analysis falls short, as the information to analyse may be generated just it time for its use.
For such cases, dynamic analysis is a more appropriate approach.
It can be used to collect the missing information while the application is running.
However, having this information does not means that the application can now be analysed in its entirety.
Generic analysis tools rarely have an easy way to read additionnal information about an application before analysing, and when they do, it is not standard.
The usual approach for hybrid analysis, analysis that mix static and dynamic analysis, is to select one specific static tool, and modify its code to take into accound the additionnal data collected by dynamic analysis.
In this chapter, we propose to modify the code of the application to add the information needed for analysis in a format that any analysis tool can use.
We structured this chapter as follow: We first present an overview of our method in @sec:th-overview.
We then present the transformations we apply to the application in @sec:th-trans, and the dynamic analysis we perform in @sec:th-dyn.
In @sec:th-res compare the results of different tools on the initial application versus the modified application.
To complete this chapter, in @sec:th-limits we discuss the limits of our solution, as well as directions for futur works.
Finally, we conclude in @sec:th-conclusion.

8
5_theseus/main.typ
View file

@ -3,10 +3,14 @@
= The Application of Theseus: After Adding Runtime Data, it is Still Your Application <sec:th>
//#epigraph("Plutarch, Life of Theseus 23.1")[The ship wherein Theseus and the youth of Athens returned from Crete had thirty oars, and was preserved by the Athenians \[...\] for they took away the old planks as they decayed, putting in new and strong timber in their places]
#epigraph("Toby Fox, Undertale")[Despite everything, it's still you.]
#epigraph("Undertale, Toby Fox")[Despite everything, it's still you.]
#align(center, highlight-block(inset: 15pt, width: 75%, block(align(left)[
#todo[Abstract for @sec:th]
Some applications use dynamic code loading and reflection calls that prevent static analysis tools from analysing the complete application.
Those behavior can be analyse with dynamic analysis, but the information collected is not enough analyse the application: most tools do not have a way to process this additionnal data.
In this chapter, promose to use dynamic analysis to collect information related to dynamic code loading and reflection, and to encode this information in the bytecode of the application to allow further analysis.
We compared the results of analysis on application before and after the transformation, using tools like Flowdroid or Androguard, and found that the additional information is indeed processed by the tools.
We also compared the finishing rate of the tools, using the same experiment as in @sec:rasta, and found that the finishing rate is generally only slightly negativelly impacted by the transformation.
])))
#include("1_introduction.typ")

18
6_conclusion/main.typ Normal file
View file

@ -0,0 +1,18 @@
#import "../lib.typ": epigraph, todo
= Conclusion <sec:conclusion>
//#epigraph("Spoon Boy, The Matrix")[There is no spoon.] // lol
#epigraph("Kate \"Acid Burn\" Libby, Hackers")[You know if you would have said so in the beginning, you would have saved yourself a whole lot of trouble.]
#todo[Conclude]
/*
* Futur work: mon unique pov pour le futur: what need to be done
*
* Take aways depuis l'intro
* puis résumé des contributions majeurs, un paragraphe par contrib
*
* future work plus haut niveau: reprandre les plus important et/ou des plus large: eg: quide web-base? flutter?
*/

5
main.typ
View file

@ -147,10 +147,7 @@
#include("3_rasta/main.typ")
#include("4_class_loader/main.typ")
#include("5_theseus/main.typ")
= Conclusion <sec:conclusion>
#todo[Conclude]
#include("6_conclusion/main.typ")
/*
* Take aways depuis l'intro