factorize pb stat

1_introduction/main.typ

@@ -1,4 +1,4 @@
-#import "../lib.typ": todo, epigraph, eg, APK, API, highlight-block, jm-note,
+#import "../lib.typ": todo, epigraph, eg, APK, API, highlight-block, jm-note, pb1-text, pb2-text, pb3-text
 
 = Introduction <sec:intro>
 
@@ -45,7 +45,7 @@ This leads us to our first problem statement:
 // Chiffrer les contrib avec des xp qui ignore les app qui font crasher les outils?
 
 #highlight-block(breakable: false)[
-  *Pb1*: _To what extent are previously published Android analysis tools still usable today, and what factors impact their reusability?_
+  *Pb1*: #pb1-text
   
   Many tools have been published to analyse Android applications, but the Android ecosystem is fast evolving.
   Tools developed 5 years ago might not be usable anymore.
@@ -70,7 +70,7 @@ In fact, the Android Runtime is constantly performing class loading to load clas
 This blind spot in static analysis tools raises our second problem statement:
 
 #highlight-block(breakable: false)[
-  *Pb2*: _What is the default Android class loading algorithm, and does it impact static analysis?_
+  *Pb2*: #pb2-text
 
   Class loading is an operation often ignored in static analysis.
   The exact algorithm used is not well known and might not be accurately modeled by static analysis tools.
@@ -84,7 +84,7 @@ A reverse engineer can obtain the relevant information with dynamic analysing, b
 This lead us to our last problem statement:
 
 #highlight-block(breakable: false)[
-  *Pb3*: _Can we provide dynamic code loading and reflection data collected dynamically to any static analysis tools to improve their results?_
+  *Pb3*: #pb3-text 
 
   Dynamic code loading and reflection are problems most suited for dynamic analysis.
   However, static analysis tools do not have access to collected data.