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

midskip
All checks were successful
/ test_checkout (push) Successful in 1m44s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-10-04 00:29:34 +02:00
parent de9674f09c
commit 96b8d24b29
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
13 changed files with 26 additions and 24 deletions
Download patch file Download diff file Expand all files Collapse all files

4
5_theseus/3_static_transformation.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": todo, APK, APKs, DEX, JAR, OAT, SDK, eg, ART, jm-note, jfl-note
#import "../lib.typ": todo, APK, APKs, DEX, JAR, OAT, SDK, eg, ART, jm-note, jfl-note, midskip
== Code Transformation <sec:th-trans>
@ -245,7 +245,7 @@ In hindsight, we probably should have taken the time to find a way to use smali/
At the time of writing, the feature is still being developed, but in the future, Androguard might also become an option to modify #DEX files.
Nevertheless, we published our instrumentation library, Androscalpel, for anyone who wants to use it. #todo[ref to code]
#v(2em)
#midskip
Now that we saw the transformations we want to make, we know the runtime information we need to do it.
In the next section, we will propose a solution to collect that information.

4
5_theseus/4_dynamic_data_collection.typ
View file

@ -1,4 +1,4 @@
#import "../lib.typ": todo, SDK, API, ART, DEX, APK, JAR, ADB, jfl-note, APKs
#import "../lib.typ": todo, SDK, API, ART, DEX, APK, JAR, ADB, jfl-note, APKs, midskip
== Collecting Runtime Information <sec:th-dyn>
@ -77,7 +77,7 @@ Nonetheless, the benefit of our implementation is that it only requires an #ADB
Of course, to analyse a specific application, a reverse engineer could use an actual smartphone and explore the application manually.
It would be a lot more stable than our automated batch analysis setup.
#v(2em)
#midskip
Now that we saw both the dynamic analysis setup and the transformation we want to perform on the #APKs, we put our proposed approach into practice.
In the next section, we will run our dynamic analysis on #APKs and study the data collected, as well as the impact the instrumentation has on applications and different analysis tools.

4
5_theseus/5_results.typ
View file

@ -1,6 +1,6 @@
#import "@preview/diagraph:0.3.5": render
#import "../lib.typ": SDK, num, mypercent, ART, ie, APKs, API, APIs, etal
#import "../lib.typ": SDK, num, mypercent, ART, ie, APKs, API, APIs, etal, midskip
#import "../lib.typ": todo, jfl-note
#import "X_var.typ": *
#import "../3_rasta/X_var.typ": NBTOTALSTRING
@ -298,7 +298,7 @@ In red on the figure however, we have the calls that were hidded by reflection i
caption: [Call Graph of `Main.main()` generated by Androguard after patching],
) <fig:th-cg-after>
#v(2em)
#midskip
To conclude, we showed that our approach indeed improves the results of analysis tools without impacting their finishing rates much.
Unfortunately, we also noticed that our dynamic analysis is suboptimal, either due to our experimental setup or due to our solution to explore the applications.