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

finished, maybe, yes?
All checks were successful
/ test_checkout (push) Successful in 1m43s
Details

Browse source
This commit is contained in:
Jean-Marie 'Histausse' Mineau 2025-10-03 04:36:10 +02:00
parent 63f34abca6
commit 6a43784496
Signed by: histausse
GPG key ID: B66AEEDA9B645AD2
3 changed files with 38 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

6
5_theseus/3_static_transformation.typ
View file

@ -231,17 +231,17 @@ Most of the contributions we saw performing instrumentation rely on Soot.
Soot works on an intermediate representation, Jimple, that is easier to manipulate.
However, Soot can be cumbersome to set up and use, and we initially wanted better control over the modified bytecode.
Our initial idea was to use Apktool, but in @sec:rasta, we found that many errors raised by tools were due to trying to parse Smali incorrectly.
So, rather than parsing, modifying and regenerating the Smali text file, we decided to make our own instrumentation library from scratch.
So, rather than parsing, modifying and regenerating the Smali text files, we decided to make our own instrumentation library from scratch.
It was not as difficult as one would expect, thanks to the clear documentation of the Dalvik format from Google#footnote[https://source.android.com/docs/core/runtime/dex-format].
In addition, when we had doubts about the specification, we had the option to check the implementation used by Apktool#footnote[https://github.com/JesusFreke/smali], or the code used by Android to check the integrity of the #DEX files#footnote[https://cs.android.com/android/platform/superproject/main/+/main:art/libdexfile/dex/dex_file_verifier.cc;drc=11bd0da6cfa3fa40bc61deae0ad1e6ba230b0954].
One thing we noticed when manually instrumenting applications with Apktool is that sometimes the repackaged applications cannot be installed or run due to some files being stored incorrectly in the new application (#eg native library files must not be compressed).
We also found that some applications deliberately store files with names that will crash the zip library used by Apktool.
For this reason, we also used our own library to modify the #APK files.
We take special care to process the least possible files in the #APKs, and only strip the #DEX files and signatures, before adding the new modified #DEX files at the end.
We took special care to process the least possible files in the #APKs, and only strip the #DEX files and signatures, before adding the new modified #DEX files at the end.
Unfortunately, we did not have time to compare the robustness of our solution to existing tools like Apktool and Soot.
In hindsight, we probably should have taken the time to find a way to use smali/backsamli (the backend of Apktool) as a library or SootUp to do the instrumentation, but neither option has documentation to instrument applications.
In hindsight, we probably should have taken the time to find a way to use smali/backsmali (the backend of Apktool) as a library or use SootUp to do the instrumentation, but neither option has documentation to instrument applications this way.
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]