rerefactor bg

2_background/2_2_tools.typ

@@ -0,0 +1,95 @@
+#import "../lib.typ": todo, APK, IDE, SDK, DEX, ADB, ART, eg, XML, AXML, API, jfl-note
+
+=== Reverse Engineering Tools <sec:bg-tools>
+
+Due to the specificities of Android, reverse engineers need tools adapted to Android.
+The developement tools provided by Google can be used for basic operations, but a reverse engineer will quickly need more specialized tool.
+Usually, the first steep while while analysing an application is to look at its content.
+Apktool and Jadx are common tools used to convert the content of an application into a readable format.
+Analysing an application this way, without running it, is called static analysis.
+For more advanced form of static analysis, Androguard and Soot can be used as librairy to automate analyses.
+When static analysis became too complicated (#eg if the application uses obfuscation techniques), a reverse engineer might switch to dynamic analysis.
+This time, the application is executed and the analyst will scrutinise the behaviour of the application.
+Frida is a good option to help this dynamic analysis, 
+It is a toolkit that can be use to intercept method call and execute custom while an application is running.
+
+==== Android Studio <sec:bg-android-studio>
+
+The whole Android developement ecosystem is packaged by Google in the #IDE Android Studio#footnote[https://developer.android.com/studio]. 
+In practice, Android Studio is a source-code editor that wrap arround the different tools of the android #SDK.
+The #SDK tools and packages can be installed manually with the `sdkmanager` tool.
+Among the notable tools in the #SDK, they are:
+
+- `emulator`: an Android emulator. 
+  This tools allow to run an emulated Android phone on a computer.
+  Although very useful, Android emulator has several limitation. 
+  For once, it cannot emulate another achitecture.
+  An x86_64 computer cannot emulate an ARM smartphone.
+  This can be an issue because a majority of smartphone run on ARM processor.
+  Also, for certain version of Android, the proprietary GooglePlay libraries are not available on rooted emulators.
+  Lastly, emulators are not designed to be stealthy and can easily be detected by an application.
+  Malware will avoid detection by not running their payload on emulators.
+- #ADB: a tool to send commands to Android smartphone or emulator.
+  It can be used to install applications, send instructions, events, and generally perform debuging operations.
+- Platform Packages: Those packages contains data associated to a version of android needed to compile an application.
+  Especially, they contains the so call `android.jar` files, that contains the list of #API for a version of Android.
+- `d8`: The main use of `d8` is to convert java bytecode files (`.class`) to Android #DEX format.
+  It can also be used to perform different level of optimization of the bytecode generated.
+- `aapt`/`aapt2` (Android Asset Packaging Tool): This tools is used to build the #APK file.
+  It is commonly used by other tools that repackage applications like Apktool.
+  Behind the scene, it converts #XML to binary #AXML and ensure that each files have the right compression and alignment. (#eg some ressource files are mapped in memory by the #ART, and thus need to be aligned and not compressed).
+- `apksigner`: the tool used to sign an #APK file.
+  When repackaging an application, for example with Apktool, the new application need to be signed.
+
+==== Apktool <sec:bg-apktool>
+
+Apktool#footnote[https://apktool.org/] is a _reengineering tool_ for Android #APK files.
+It can be used to disassemble an application: it will extract the files from the #APK file, convert the binary #AXML to text #XML, and use smali/backsmali#footnote[https://github.com/JesusFreke/smali] to convert the #DEX files to smali, an assembler-like langage that match the Dalvik bytecode instructions.
+The main strenght of Apktool is that after having disassemble an application, the content of the application can be edited and reassemble into a new #APK. #jfl-note[limites? ca marche toujours?]
+
+==== Androguard <sec:bg-androguard>
+
+Androguard#footnote[https://github.com/androguard/androguard]~@desnos:adnroguard:2011 is a python library for parsing and disassembling #APK files.
+It can be used to automatically read Android manifests, ressources, and bytecode.
+Contrary to Apktool wich generate text files, it can be used as a library to programatically to analyse the application.
+However, contrary to Apktool, it cannot repackage a modified application.
+
+In addition, it can perform additionnal analysis, like computing a call graph or control flow graph of the application. 
+We will explain what are those graphs later in @sec:bg-static.
+
+==== Jadx <sec:bg-jadx>
+
+Jadx#footnote[https://github.com/skylot/jadx] is an application decompiler.
+It convert #DEX files to Java source code.
+It is not always capable of decompiling all classes of an application, so it cannot be used to recompile a new application, but the code generated can be very helpful to reverse an application.
+In addition to decompilling #DEX files, Jadx can also decode Android manifests and application ressources.
+
+==== Soot <sec:bg-soot>
+
+Soot#footnote[https://github.com/soot-oss/soot]~@Arzt2013 was originaly a Java optimization framework.
+It could leaft java bytecode to other intermediate representations that can could be optimized, then converted back to bytecode.
+Because Dalvik bytecode and Java bytecode are equivalent, support for Android was added to Soot, and Soot features are now leveraged to analyse and modify Android applications.
+One of the best known example of Soot usage for Android analysis is Flowdroid~@Arzt2014a, a tool that computes data flow in an application.
+
+A new version of Soot, SootUp#footnote[https://github.com/soot-oss/SootUp], is currently beeing worked on.
+Compared to Soot, it has a modernize interface and architecture, but it is not yet feature complete and some tools like Flowdroid are still using Soot.
+
+==== Frida <sec:bg-frida>
+
+Frida#footnote[https://frida.re/] is a dynamic intrumentation toolkit.
+It allows the reverse engineer to inject and run javascript code inside a running application.
+
+To instrument an application, the frida server must be running as root on the phone, or the frida librairy must be injected inside the #APK file before installing it.
+Frida defines a javascript wrapper arround the Java Native Interface (JNI) used by native code to interact with Java classes and the Android #API.
+In addition to allowing interaction with Java objects from the application and the Android API, this wrapper provides the option to replace a method implementation by a javascript function (that itself can call the original method implementation if needed).
+This make Frida a powerful tool capable of collecting runtime informations or modifying the behavior of an application as needed.
+
+The main drawback of using Frida is that it is a known tools easily detected by applications.
+Malware might implement countermeasures that avoid running malicious payload in presence of Frida.
+
+#v(2em)
+
+Those tools are quite useful for manual operations.
+However, considering the complexity of modern Android applications, it might take a lot of work for a reverse engineer to analyse one application.
+Different techniques have been developped to streamline the analysis.
+Next, we will see the most common of those techniques for static analysis.