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

erf, not good, but it's something at least
All checks were successful
/ test_checkout (push) Successful in 1m47s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-09-25 16:49:27 +02:00
parent c34eb1b838
commit fede0bd9b2
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
5 changed files with 42 additions and 36 deletions
Download patch file Download diff file Expand all files Collapse all files

22
2_background/4_3_theseus.typ
View file

@ -1,13 +1,17 @@
#import "../lib.typ": APK, etal, ART, SDK, eg, DEX, eg, pb3, pb3-text
#import "../lib.typ": todo, jm-note, jfl-note
== Allowing Static Analysis Tools to Analyse Obfuscated Application <sec:bg-soa-th>
=== Allowing Static Analysis Tools to Analyse Obfuscated Application <sec:bg-soa-th>
#pb3-text
=== Dynamic Analysis <sec:bg-dynamic>
Dynamic analysis of Android application have been researched for a long time.
Like static analysis, it has its own challenges, that we will explore in this subsection.
After that we will also look at contributions that seeked to encode results inside the #APK format, or used intrumentation to improve analyses in some way.
As we said previously, static analysis is not capable of analysing everything.
Some situation, like reflection of dynamic code loading, require a different approach: dynamic analysis.
==== Dynamic Analysis <sec:bg-dynamic>
Some situation, like reflection of dynamic code loading, are difficult to solve with static analysis and require a different approach: dynamic analysis.
With dynamic analysis, the application is actually executed and the reverse engineer obserces its behavior.
Monitoring the behavior can be achieved by various strategies: observing the filesystem, the display screen, the process memory, the kernel, ...
Depending on the chosen level of observation, it can be technically difficult.
@ -42,13 +46,13 @@ Similarly, StaDynA~@zhauniarovichStaDynAAddressingProblem2015 is a framework tha
The issue with those approach is that they are only compatible with their own subsequent analysis.
For instance, StaDynA only provide the call graph, and cannot be used as is to improve the capacity of Flowdroid.
This is unfortunate, has the reverse engineer next step will depend on the context: not beeing able to reuse the result of a previous analysis with other #jm-note[non-specialise][erf, non-specific? non-adapted?] tools limit greatly their options.
This is unfortunate, has the reverse engineer next step will depend on the context: not beeing able to reuse the result of a previous analysis with any ad hoc tools limit greatly their options.
AppSpear has an interesting solution to this issue: the code it intercept is repackage inside a new #APK file that Android analysis tools should be able to analyze.
In the next section, we will explore further the contributions that take this approache of using actual application to encode its result.
We will now explore further the contributions that take this approache of using actual application to encode its result.
//#todo[RealDroid sandbox bases on modified ART?]
//#todo[force execution?]
=== Improving Analysis with Instrumentation <sec:bg-instrumentation>
==== Improving Analysis with Instrumentation <sec:bg-instrumentation>
Usually, instrumentation refers to the practice of modifying the behavior of a program to collect information during its execution.
Frida is a good example of instrumentation framework.
@ -75,7 +79,6 @@ Those cases are quite commons and beeing able to solve those without resorting t
On the other hand, COAL will struggle to solve cases with complexe string manipulation and is simply not able to handle cases that rely on external data (#eg downloaded from the internet at runtime).
Likewise, this can only access code loaded dynamically if the code was present inside the application without any kind of obfuscation (#eg a #DEX file in the assets of the application can be analyse, but not if it is ciphered).
#v(2em)
Instrumenting applications to encode the result of an analysis as an unified representation has been explored before.
@ -84,7 +87,6 @@ Similarly, DroidRA compute reflection information computed statically and inject
However, AppSpear and DexLego focus primarely on specific obfuscation techniques, making there implementation difficult to port to more rescent version of Android, and DroidRA suffers the limitation of static analysis.
We believe that instrumentation is a promising approach to encode those information.
Especially, we think that it could be used to provide dynamic information that are not available to static analysis tools like DroidRA.
To explore this possibility, we will try to anwser our third problem statement #pb3: #pb3-text
In @sec:th, we will try use instrumentation to combine dynamica analysis (to collect code loaded dynamically and reflection information) with static analysis, indifferently of the static analysis tool used.