finish applying superficial comments

BPV/qrs/main.typ

@@ -156,7 +156,7 @@ Finally, from the developer's point of view, forging power consumption to impoer
 This is especially true when considering firmware or machines with low computation capabilities or highly specialized devices that have deterministic and stable execution patterns at boot-up.
 
 However, to the best of our knowledge, no work leveraged the same data or method for firmware integrity verification.
-Boot-ups are a natural target for defensive purposes are they are notoriously hard to protect, and host-based #acr("IDS") are not yet active to defend the machine.
+Boot-up sequences are notoriously hard to protect as host-based #acr("IDS") are not yet active to defend the machine.
 Moreover, boot-ups produces significantly more consistent power consumption than normal operation on general-purpose machines as it follows a pre-defined process.
 
 In light of the potential of side-channel attacks, some work proposed manipulating power consumption patterns.
@@ -220,7 +220,7 @@ All time series considered in this problem ($T union u$) are all of the same len
 #figure(
   placement: auto,
   image("images/illustration.svg", width:100%),
-  caption: [Overview of the detection process.]
+  caption: [Overview of the implementation of #acr("BPV") to protect embedded systems based on their power consumption.]
 )<overview>
 
 == Detection Models<detector>
@@ -276,7 +276,7 @@ The vertical dashed lines represent the distance threshold.
 #figure(
   placement: auto,
   image("images/training.svg", width:100%),
-  caption: [BPV model trained with two modes.]
+  caption: [Illustration of th BPV model trained with two modes.]
 )<fig-modes>
 = Test Cases<test-cases>
 
@@ -421,7 +421,7 @@ The results are presented in @tab-results.
     columns: (40%,40%),
     auto-vlines: false,
     align: (left, right),
-    [*Machine*], [*BPV*],
+    [*Machine*], [*BPV $F_1$ Score*],
     [TP-Link switch], [0.87],
     [HP switch], [0.98],
     [Asus router], [1.00],
@@ -429,7 +429,7 @@ The results are presented in @tab-results.
   ),
   supplement: [Table],
   kind: "table",
-  caption: [Results of detection.]
+  caption: [Results of the detection of anomalous firmwares on networking devices.]
 )<tab-results>
 
 There are two hyper-parameters to tune to obtain the best performances.
@@ -469,11 +469,11 @@ The experiment scenarios are:
 - *Low Battery:* When the drone starts with a low battery level, its behaviour changes to signal the user of the issue. Any battery level below 11V is considered low. In this scenario, a nominal firmware is loaded, and the drone starts with 10V, triggering the low battery behaviour.
 - *Malfunctioning Firmware:* Two malfunctioning firmware versions were compiled. The first introduces a _division-by-zero_ bug in the second stage bootloader. The second introduces the same bug but in the battery management module (in the OS part of the firmware). The second scenario should not introduce measurable anomalous patterns in the boot-up sequence as it only affects the OS stage.
 
-#figure(
-  placement:top,
-  image("images/drone-overlaps.svg", width: 100%),
-  caption: [Overlap of boot-up traces for different scenarios and their average. Green = Low Battery (8 traces + average), Purple = Battery Module Bug (8 traces + average), Orange = Bootloader Bug (6 traces + average).]
-)
+//#figure(
+//  placement:top,
+//  image("images/drone-overlaps.svg", width: 100%),
+//  caption: [Overlap of boot-up traces for different scenarios and their average. Green = Low Battery (8 traces + average), Purple = Battery Module Bug (8 traces + average), Orange = Bootloader Bug (6 traces + average).]
+//)<overlap-drone>
 
 The experiment procedure consists in starting the drone flight controller multiple times while capturing the power consumption.
 The experiment consists in repeating each scenario between 40 and 100 times.
@@ -585,7 +585,7 @@ To avoid introducing training biases, the dataset is balanced by generating new
 #figure(
   placement: auto,
   image("images/Synthetic_vs_Normal_TPLINK.svg", width: 100%),
-  caption: [Example of generated anomalous traces compared with captured normal traces for TP-Link switch.],
+  caption: [Example of generated anomalous traces (orange) compared with captured normal (green) traces for TP-Link switch.],
 )<fig-Synthetic_vs_Normal_TPLINK>
 
 === Results