Jean-Marie 'Histausse' Mineau
d7df45b206
Some checks failed
/ test_checkout (push) Failing after 21s
29 lines
2.7 KiB
Typst
29 lines
2.7 KiB
Typst
#import "../lib.typ": todo
|
|
|
|
== Introduction <sec:th-intro>
|
|
|
|
In the previous chapter, we studied the static impact of class loaders.
|
|
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.
|
|
The main issue for analysis occurs when it is used to call methods.
|
|
A static analysis will show calls to `Method.invoke()`, but not the actual method invoked.
|
|
|
|
In both cases, static analysis falls short, as the information to analyse may be generated just in 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 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.
|
|
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.
|
|
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 future work.
|
|
Finally, we conclude in @sec:th-conclusion.
|