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

grammarly
All checks were successful
/ test_checkout (push) Successful in 1m42s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-22 06:02:08 +02:00
parent 039970904e
commit 10df431972
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
9 changed files with 240 additions and 250 deletions
Download patch file Download diff file Expand all files Collapse all files

20
5_theseus/2_overview.typ
View file

@ -3,11 +3,11 @@
== Overview <sec:th-overview>
Our objectif is to make available some dynamic information to any analysis tool able to analyse an Android #APK.
To do so, we elected to follow the path of a few contributions we presented in @sec:bg such as DroidRA~@li_droidra_2016 and use instrumentation.
Contrary to DroidRA, which use static analysis to compute the values of string and from that the methods used by reflection, we chose to dynamic analysis.
This allows us to collect informations that are simply not available statically (#eg a string send from a remote command and control server).
The tradeoff beeing the lack of exhaustiveness: dynamic analysis is known to have code coverage issues.
Our objective is to make available some dynamic information to any analysis tool able to analyse an Android #APK.
To do so, we elected to follow the path of a few contributions we presented in @sec:bg, such as DroidRA~@li_droidra_2016, and use instrumentation.
Contrary to DroidRA, which uses static analysis to compute the values of strings and, from that, the methods used by reflection, we chose to use dynamic analysis.
This allows us to collect information that is simply not available statically (#eg a string sent from a remote command and control server).
The tradeoff being the lack of exhaustiveness: dynamic analysis is known to have code coverage issues.
#figure(
raw-render(
@ -47,12 +47,12 @@ The tradeoff beeing the lack of exhaustiveness: dynamic analysis is known to hav
caption: [Process to add runtime information to an #APK],
) <fig:th-process>
@fig:th-process summarize our process.
@fig:th-process summarises our process.
We first take an application that we analyse dynamically.
To improve code coverage, either an reverse engineer or an automated runner will interact with the application.
During this analysis, we use Frida to capture dynamic informations like the name of the methods called using reflection and bytecode loaded at runtime.
This analysis described in @sec:th-dyn.
To improve code coverage, either a reverse engineer or an automated runner will interact with the application.
During this analysis, we use Frida to capture dynamic information like the names of the methods called using reflection and bytecode loaded at runtime.
This analysis is described in @sec:th-dyn.
The data collected by this analysis is then combined to application, transforming the application into another one that can then be analyzed further.
The data collected by this analysis is then combined with the application, transforming the application into another one that can then be analysed further.
We present the details of this transformation in @sec:th-trans.
Since the transformation drives the data we need to collect, we have decided to place this section first in this chapter.