diff --git a/2_background/X_dynamic_analysis.typ b/2_background/7_dynamic_analysis.typ
similarity index 75%
rename from 2_background/X_dynamic_analysis.typ
rename to 2_background/7_dynamic_analysis.typ
index 48cc89e..67aa8e2 100644
--- a/2_background/X_dynamic_analysis.typ
+++ b/2_background/7_dynamic_analysis.typ
@@ -29,12 +29,18 @@ Unfortuntely, exploring the application entirely is not always possible, as some
 Ruggia #etal~@ruggia_unmasking_2024 make a list of evasion techniques.
 They propose a new sandbox, DroidDungeon, that contrary to other sandboxes like DroidScope@droidscope180237 or CopperDroid@Tam2015, strongly emphasizes on resiliance against evasion mechanism.
 
-A common objectif of dynamic analysis is to collect bytecode loaded dynamically #jm-note[and reflections information.][check?].
+A common objectif of dynamic analysis is to collect bytecode loaded dynamically and reflections information.
 Like we said earlier, DexHunter~@zhang2015dexhunter and AppSpear~@yang_appspear_2015 that by instrumenting the Android Runtime.
 Qu #etal~@qu_dydroid_2017 developped DyDroid, an hybrid framework using dynamic analysis to intercept dynamic code loading and static analysis to determine the nature of the loaded code.
-They used DyDroid to make an autid of the use of dynamic code loading in applications from the Google Play store in 2016.
-They found that it was mostly related to mobile advertisement, and that the code loading originated from a third party library included in the application, rather than the code of the application developper itself.
-#todo[DCL and reflection, then segway to hybride an limite ]
+They used DyDroid to make an autit of the use of dynamic code loading in applications from the Google Play store in 2016.
+It resulted that dynamic code loading was mostly related to mobile advertisement, and that the code loading originated from a third party library included in the application, rather than the code of the application developper itself.
+Similarly, StaDynA~@zhauniarovichStaDynAAddressingProblem2015 is a framework that generate a call graph statically, then use dynamic analysis to analyse dynamic code loading and reflection calls to complete this call graph.
+
+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.
+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.
 
 //#todo[RealDroid sandbox bases on modified ART?]
 //#todo[force execution?]
diff --git a/2_background/main.typ b/2_background/main.typ
index 3ccc689..54f581c 100644
--- a/2_background/main.typ
+++ b/2_background/main.typ
@@ -11,7 +11,7 @@
 #include("4_datasets_and_benchmarking.typ")
 #include("5_platform_classes.typ")
 #include("6_classloading.typ")
-#include("X_dynamic_analysis.typ")
+#include("7_dynamic_analysis.typ")
 
 /*
 * Cours generique sur android