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

pass chapter 5
Some checks failed
/ test_checkout (push) Failing after 21s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-30 03:05:07 +02:00
parent f309dd55b8
commit d7df45b206
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
8 changed files with 64 additions and 56 deletions
Download patch file Download diff file Expand all files Collapse all files

12
5_theseus/1_introduction.typ
View file

@ -2,12 +2,10 @@
== Introduction <sec:th-intro>
#todo[Reflectif call? Reflection call?]
In the previous chapter, we studied the static impact of class loaders.
Doing so, we ignored the main usage of class loaders by developers: 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.
However, as we focused on the default behaviour of Android, we ignored the main use of class loaders for developers: dynamic code loading.
In this chapter, we address this issue, as well as the issue of reflection that often accompanies 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 application.
This bytecode can be 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 objects representing structures of the code itself, like classes or methods.
@ -19,8 +17,10 @@ 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 mean that the application can now be analysed in its entirety.
Generic analysis tools rarely have an easy way to read additional information about an application before analysing, and when they do, it is not standard.
The usual approach for hybrid analysis, analyses that mix static and dynamic analysis, is to select one specific static tool and modify its code to take into account the additional data collected by dynamic analysis.
The usual approach for hybrid analysis (analyses that mix static and dynamic analysis) is to select one specific static tool and modify its code to take into account the additional data collected by dynamic analysis.
This limits the reverse engineer to a few tools that they took the time to study and modify for the task.
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.
This way, the analyst is no longer limited in their choice of tool and can focus on the actual analysis of the application.
We structured this chapter as follows: 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.