wip

5_theseus/4_results.typ

@@ -1,4 +1,5 @@
-#import "../lib.typ": todo, SDK, num, mypercent, ART, ie, APKs, jfl-note
+#import "../lib.typ": SDK, num, mypercent, ART, ie, APKs, API,
+#import "../lib.typ": todo, jfl-note
 #import "X_var.typ": *
 #import "../3_rasta/X_var.typ": NBTOTALSTRING
 
@@ -107,6 +108,15 @@ The remaining #num(nb_bytecode_collected - nb_google - nb_appsflyer - nb_faceboo
 
 === Impact on Analysis Tools Finishing Rate
 
+Unfortunately, our implementation of the transformation is imperfect and does fails some time.
+Over the #num(dyn_res.all.nb - dyn_res.all.nb_failed), #num(nb_patched) were patched.
+The remaining #mypercent(dyn_res.all.nb - dyn_res.all.nb_failed - nb_patched, dyn_res.all.nb - dyn_res.all.nb_failed) failed either due to some quirk in the zip format of the #APK file or because of a bug in our implementation when exceeding the method reference limit in a single #DEX file.
+Taking into accound the failure from both dynamic analysis and the patching, we have a #mypercent(dyn_res.all.nb - nb_patched, dyn_res.all.nb) failure rate.
+This is a reasonable failure rate, but we should keep in mind that it adds up to the failure rate of the other tools we want to use on the patched application.
+
+We then run the same experiment we run in @sec:rasta.
+We run the tools on the #APK before and after patching, and compared the finishing rates in @fig:th-status-npatched-vs-patched without taking into account #APKs we failed to patch#footnote[Due to an handling error during the experiment, the figure show the results for #nb_patched_rasta #APKs instead of #nb_patched.].
+
 #todo[alt text @fig:th-status-npatched-vs-patched]
 #todo[Check SAAF and IC3 results on patched]
 #figure({
@@ -120,7 +130,7 @@ The remaining #num(nb_bytecode_collected - nb_google - nb_appsflyer - nb_faceboo
   caption: [Exist status of static analysis tools on original #APKs (left) and patched #APKs (right)]
 ) <fig:th-status-npatched-vs-patched>
 
-#todo[Check if flowdroid improve, compare sucess rate of RASTA, show result for demo app]
+#todo[Flowdroid results are inconclusive: some apks have more leak after and as many apks have less? also, runing flowdroid on the same apk can return a different number of leak???]
 
 #jfl-note[Combien d'app tranforme? on parle des 888? on fait les 2 tranformation sur chaque apk? ca reussit tout le temps?]
 
@@ -158,7 +168,7 @@ public class Main {
 
     ...
 }
-  ```
+  ```,
   caption: [Code of the main class of the application showed by Jadx, before patching],
 )<fig:th-demo-before>
 
@@ -175,7 +185,7 @@ This is not particularly surprising considering the obfusctation methods used.
 
 Then we run the dynamic analysis we described in @sec:th-dyn on the application and apply the transformation described in @sec:th-trans to add the dynamic informations to it.
 This time, Flowdroid compute a larger callgraph of 76 edges, and does find a data leak.
-Indeed, when looking at the new application with Jadx, we notice a new class `Malicious`, and the code of `Main.main()` is now as shown in @figth-demo-after:
+Indeed, when looking at the new application with Jadx, we notice a new class `Malicious`, and the code of `Main.main()` is now as shown in @fig:th-demo-after:
 the method called in the loop is either `Malicious.get_data`, `Malicious.send_data()` or `Method.invoke()`.
 Although self explanatory, verifying the code of those methods indeed confirm that `get_data()` calls `Utils.source()` and `send_data()` calls `Utils.sink()`.
 
@@ -195,7 +205,7 @@ Although self explanatory, verifying the code of those methods indeed confirm th
               method.invoke(null, objArr);
         }
     }
-    ```
+    ```,
     caption: [Code of `Main.main()` showed by Jadx, after patching],
 )<fig:th-demo-after>