I declare this manuscript finished

5_theseus/3_static_transformation.typ

@@ -82,25 +82,6 @@ If we were to expect other possible methods to be called in addition to `myMetho
 ] #todo[Ref to list of common tools?] reformated for readability.
 */
 
-The check of the `Method` value is done in a separate method injected inside the application to avoid cluttering the application too much.
-Because Java (and thus Android) uses polymorphic methods, we cannot just check the method name and its class, but also the whole method signature.
-We chose to limit the transformation to the specific instruction that calls `Method.invoke(..)`.
-This drastically reduces the risks of breaking the application, but leads to a lot of type casting.
-Indeed, the reflection call uses the generic `Object` class, but actual methods usually use specific classes (#eg `String`, `Context`, `Reflectee`) or scalar types (#eg `int`, `long`, `boolean`).
-This means that the method parameters and object on which the method is called must be downcasted to their actual type before calling the method, then the returned value must be upcasted back to an `Object`.
-Scalar types especially require special attention. 
-Java (and Android) distinguish between scalar types and classes, and they cannot be mixed: a scalar cannot be cast into an `Object`.
-However, each scalar type has an associated class that can be used when doing reflection.
-For example, the scalar type `int` is associated with the class `Integer`, the method `Integer.valueOf()` can convert an `int` scalar to an `Integer` object, and the method `Integer.intValue()` converts back an `Integer` object to an `int` scalar.
-Each time the method called by reflection uses scalars, the scalar-object conversion must be made before calling it.
-And finally, because the instruction following the reflection call expects an `Object`, the return value of the method must be cast into an `Object`.
-
-This back and forth between types might confuse some analysis tools. 
-This could be improved in future works by analysing the code around the reflection call. 
-For example, if the result of the reflection call is immediately cast into the expected type (#eg in @lst:-th-expl-cl-call, the result is cast to a `String`), there should be no need to cast it to Object in between.
-Similarly, it is common to have the method parameter arrays generated just before the reflection call and never be used again (This is due to `Method.invoke(..)` being a varargs method: the array can be generated by the compiler at compile time).
-In those cases, the parameters could be used directly without the detour inside an array.
-
 #figure(
   ```java
   class T {
@@ -137,6 +118,25 @@ In those cases, the parameters could be used directly without the detour inside
   caption: [@lst:-th-expl-cl-call after the de-reflection transformation]
 ) <lst:-th-expl-cl-call-trans>
 
+The check of the `Method` value is done in a separate method injected inside the application to avoid cluttering the application too much.
+Because Java (and thus Android) uses polymorphic methods, we cannot just check the method name and its class, but also the whole method signature.
+We chose to limit the transformation to the specific instruction that calls `Method.invoke(..)`.
+This drastically reduces the risks of breaking the application, but leads to a lot of type casting.
+Indeed, the reflection call uses the generic `Object` class, but actual methods usually use specific classes (#eg `String`, `Context`, `Reflectee`) or scalar types (#eg `int`, `long`, `boolean`).
+This means that the method parameters and object on which the method is called must be downcasted to their actual type before calling the method, then the returned value must be upcasted back to an `Object`.
+Scalar types especially require special attention. 
+Java (and Android) distinguish between scalar types and classes, and they cannot be mixed: a scalar cannot be cast into an `Object`.
+However, each scalar type has an associated class that can be used when doing reflection.
+For example, the scalar type `int` is associated with the class `Integer`, the method `Integer.valueOf()` can convert an `int` scalar to an `Integer` object, and the method `Integer.intValue()` converts back an `Integer` object to an `int` scalar.
+Each time the method called by reflection uses scalars, the scalar-object conversion must be made before calling it.
+And finally, because the instruction following the reflection call expects an `Object`, the return value of the method must be cast into an `Object`.
+
+This back and forth between types might confuse some analysis tools. 
+This could be improved in future works by analysing the code around the reflection call. 
+For example, if the result of the reflection call is immediately cast into the expected type (#eg in @lst:-th-expl-cl-call, the result is cast to a `String`), there should be no need to cast it to Object in between.
+Similarly, it is common to have the method parameter arrays generated just before the reflection call and never be used again (This is due to `Method.invoke(..)` being a varargs method: the array can be generated by the compiler at compile time).
+In those cases, the parameters could be used directly without the detour inside an array.
+
 === Transforming Code Loading (or Not) <sec:th-trans-cl>
 
 #jfl-note[Ici je pensais lire comment on tranforme le code qui load du code, mais on me parle de multi dex]
@@ -270,7 +270,7 @@ We took special care to process the least possible files in the #APKs, and only
 Unfortunately, we did not have time to compare the robustness of our solution to existing tools like Apktool and Soot, but we did a quick performance comparison, summarised in @sec:th-lib-perf.
 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]
+Nevertheless, we published our instrumentation library, Androscalpel, for anyone who wants to use it (see @sec:soft). #todo[Update is CS says no]
 
 #midskip