Jean-Marie 'Histausse' Mineau
10df431972
All checks were successful
/ test_checkout (push) Successful in 1m42s
29 lines
2.4 KiB
Typst
29 lines
2.4 KiB
Typst
#import "../lib.typ": todo
|
|
|
|
== 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.
|
|
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.
|
|
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 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.
|