From 8039145a145b759f1e63ef2898a2c09634bcdbe8 Mon Sep 17 00:00:00 2001 From: Arthur Grisel-Davy Date: Tue, 1 Aug 2023 21:24:49 -0400 Subject: [PATCH] remove notes --- BPV/qrs/main.typ | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/BPV/qrs/main.typ b/BPV/qrs/main.typ index d4f8d99..2195358 100644 --- a/BPV/qrs/main.typ +++ b/BPV/qrs/main.typ @@ -317,7 +317,6 @@ The abnormal boot sequences are composed of sequences where an operator went int == Results The models are manually tuned to obtain 100% accuracy in the classification of nominal and abnormal boot sequences. Obtaining 100% accuracy illustrates that there is a clear separation between nominal and abnormal boot sequences for this type of attack. -//#agd[could not redo the results as teh data for bios boot are missing] Although this test case represents an unrealistic situation (mainly because the anomalous samples are accessible during training), it is still a valuable first evaluation of the #acr("BPV"). This test case serves as a proof-of-concept and indicates that there is a potential for the detection of firmware-level attacks with power consumption. @@ -481,7 +480,7 @@ The experiment procedure automatically captures boot-up traces for better reprod caption: [Results of the intrusion detection on the drone.] ) ] -#agd[Remove results of battery module bug, they are confusing] + @drone-results presents the results of the detection. Both Original and Compiled represent nominal firmware versions. @@ -490,7 +489,6 @@ The model correctly identifies the anomalous firmware. One interesting scenario is the Battery Module Bug that is mostly detected as nominal. This result is expected as the bug affects the operations of the firmware after the boot-up sequence. Hence, the power consumption in the first second of activity remains nominal. -//#agd[Should the result of the battery module bug remain, or is it confusing to present scenarios where the BPV expectedly fails?] It is interesting to notice that the differences in power consumption patterns among the different firmware are visible immediately after the initial power spike. This suggests that future work could achieve an even lower time-to-decision, likely as low as 200ms depending on the anomaly.