backup before SnP

PhD/seminar/images/wein.svg

@@ -23,15 +23,16 @@
      inkscape:pagecheckerboard="0"
      inkscape:deskcolor="#d1d1d1"
      inkscape:document-units="mm"
-     inkscape:zoom="0.48898373"
-     inkscape:cx="1387.5717"
-     inkscape:cy="64.419321"
+     inkscape:zoom="0.34576371"
+     inkscape:cx="1476.4418"
+     inkscape:cy="183.65143"
      inkscape:window-width="1920"
      inkscape:window-height="1011"
      inkscape:window-x="0"
      inkscape:window-y="0"
      inkscape:window-maximized="1"
-     inkscape:current-layer="svg1"><inkscape:page
+     inkscape:current-layer="svg1"
+     showgrid="false"><inkscape:page
        x="0"
        y="0"
        width="221.72084"
@@ -114,7 +115,7 @@
        id="tspan5"
        style="fill:#2a80ff;fill-opacity:1;stroke:none;stroke-width:3.59596"
        x="238.5392"
-       y="33.84008">Independance</tspan></text><text
+       y="33.84008">Independence</tspan></text><text
      xml:space="preserve"
      style="font-size:11.4172px;font-family:Fuji;-inkscape-font-specification:Fuji;fill:#670081;fill-opacity:1;stroke:none;stroke-width:3.59596;stroke-linecap:round"
      x="396.68823"
@@ -144,7 +145,7 @@
        id="tspan10"
        style="fill:#2a80ff;fill-opacity:1;stroke:none;stroke-width:3.59596"
        x="470.26004"
-       y="33.84008">Independance</tspan></text><text
+       y="33.84008">Independence</tspan></text><text
      xml:space="preserve"
      style="font-size:11.4172px;font-family:Fuji;-inkscape-font-specification:Fuji;fill:#670081;fill-opacity:1;stroke:none;stroke-width:3.59596;stroke-linecap:round"
      x="628.40906"

PhD/seminar/images/wein_2.svg

@@ -25,7 +25,7 @@
        id="tspan5"
        style="fill:#2a80ff;fill-opacity:1;stroke:none;stroke-width:3.59596"
        x="6.8183551"
-       y="33.84008">Independance</tspan></text><text
+       y="33.84008">Independence</tspan></text><text
      xml:space="preserve"
      style="font-size:11.4172px;font-family:Fuji;-inkscape-font-specification:Fuji;fill:#670081;fill-opacity:1;stroke:none;stroke-width:3.59596;stroke-linecap:round"
      x="164.96738"

PhD/seminar/images/wein_3.svg

@@ -25,7 +25,7 @@
        id="tspan10"
        style="fill:#2a80ff;fill-opacity:1;stroke:none;stroke-width:3.59596"
        x="6.8183398"
-       y="33.84008">Independance</tspan></text><text
+       y="33.84008">Independence</tspan></text><text
      xml:space="preserve"
      style="font-size:11.4172px;font-family:Fuji;-inkscape-font-specification:Fuji;fill:#670081;fill-opacity:1;stroke:none;stroke-width:3.59596;stroke-linecap:round"
      x="164.96736"

PhD/seminar/seminar.typ

@@ -12,8 +12,8 @@
 
 #title-slide(
   author: [Arthur Grisel-Davy],
-  title: "Process List Verification with Power Analysis",
-  subtitle: "Subtitle",
+  title: "Process List Verification With Power Analysis",
+  subtitle: "",
   date: "September 2024",
   extra: ""
 )
@@ -119,7 +119,7 @@ Power is:
 #only(3)[#align(center)[#image("images/equation_3.svg", width:100%)]]
 ]
 
-#slide(title:"Proposed Approach - model")[
+#slide(title:"Proposed Approach - Model")[
 #only(1)[#align(center)[#image("images/model_1.svg", width:100%)]]
 #only(2)[#align(center)[#image("images/model_2.svg", width:100%)]]
 #only(3)[#align(center)[#image("images/model_3.svg", width:100%)]]
@@ -169,8 +169,8 @@ Power is:
 #text(weight:"bold")[Next Steps:]
  - Collect more and better data
  - Try methods on other devices
- - Developp a benchmark for attack detection
- - Decomposition Approach
+ - Develop a benchmark for attack detection
+ - Decomposition approach
    - Extract process information from decomposed abnormal time series
    - Benchmark against MLP approach
 ]

procver/ACNS/acronyms.tex

@@ -0,0 +1,25 @@
+\DeclareAcronym{ids}{
+    short={IDS},
+    long={Intrusion Detection System}
+}
+\DeclareAcronym{hids}{
+    short={HIDS},
+    long={Host-Based Intrusion Detection System}
+}
+\DeclareAcronym{os}{
+    short={OS},
+    long={Operating System}
+}
+\DeclareAcronym{sci}{
+    short={SCI},
+    long={Side-Channel Information}
+}
+\DeclareAcronym{cpu}{
+    short={CPU},
+    long={Central Processing Unit}
+}
+\DeclareAcronym{ilp}{
+    short={ILP},
+    long={Instantaneous List of Processes}
+}
+

procver/ACNS/biblio.bib

@@ -0,0 +1,252 @@
+
+@misc{smith_evasion_2022,
+	title = {Evasion {Techniques} — {Hiding} your process from `ps`},
+	url = {https://keiran.scot/2022/10/10/Evasion-Techniques-Hiding-your-process-from-ps/},
+	abstract = {Everything in Linux is a file, that even goes for your process information. This lived inside the /proc directory on your filesystem. Today we will use and abuse this knowledge to hide a target process from the ps command in Linux, and in essence other Unix based systems. But first…
+How does the ps command work? As mentioned previously everything in Linux is a file, including the process tree in /proc.},
+	language = {en-us},
+	urldate = {2024-11-08},
+	author = {Smith, Keiran},
+	month = oct,
+	year = {2022},
+	note = {Section: posts},
+	annote = {Try that for both hiding and masquerading a process.
+},
+	file = {Snapshot:/home/grizzly/Zotero/storage/EUYRZ2P7/Evasion-Techniques-Hiding-your-process-from-ps.html:text/html},
+}
+
+@article{almshari_detection_2020,
+	title = {Detection of {Potentially} {Compromised} {Computer} {Nodes} and {Clusters} {Connected} on a {Smart} {Grid}, {Using} {Power} {Consumption} {Data}},
+	volume = {20},
+	copyright = {http://creativecommons.org/licenses/by/3.0/},
+	issn = {1424-8220},
+	url = {https://www.mdpi.com/1424-8220/20/18/5075},
+	doi = {10.3390/s20185075},
+	abstract = {Monitoring what application or type of applications running on a computer or a cluster without violating the privacy of the users can be challenging, especially when we may not have operator access to these devices, or specialized software. Smart grids and Internet of things (IoT) devices can provide power consumption data of connected individual devices or groups. This research will attempt to provide insides on what applications are running based on the power consumption of the machines and clusters. It is therefore assumed that there is a correlation between electric power and what software application is running. Additionally, it is believed that it is possible to create power consumption profiles for various software applications and even normal and abnormal behavior (e.g., a virus). In order to achieve this, an experiment was organized for the purpose of collecting 48 h of continuous real power consumption data from two PCs that were part of a university computer lab. That included collecting data with a one-second sample period, during class as well as idle time from each machine and their cluster. During the second half of the recording period, one of the machines was infected with a custom-made virus, allowing comparison between power consumption data before and after infection. The data were analyzed using different approaches: descriptive analysis, F-Test of two samples of variance, two-way analysis of variance (ANOVA) and autoregressive integrated moving average (ARIMA). The results show that it is possible to detect what type of application is running and if an individual machine or its cluster are infected. Additionally, we can conclude if the lab is used or not, making this research an ideal management tool for administrators.},
+	language = {en},
+	number = {18},
+	urldate = {2024-11-07},
+	journal = {Sensors},
+	author = {Almshari, Mohammed and Tsaramirsis, Georgios and Khadidos, Adil Omar and Buhari, Seyed Mohammed and Khan, Fazal Qudus and Khadidos, Alaa Omar},
+	month = jan,
+	year = {2020},
+	note = {Number: 18
+Publisher: Multidisciplinary Digital Publishing Institute},
+	keywords = {autoregressive integrated moving average (ARIMA), descriptive analysis, F-Test of two samples of variance, IoT, machine learning, malware detection, power consumption, privacy, security, smart grid, two-way analysis of variance (ANOVA)},
+	pages = {5075},
+	annote = {The goal here is to detect what application are running on a machine based on the power consumption. The application is very relevant as it concerns computers in a university and not specialized machines.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/FPWN8QSX/Almshari et al. - 2020 - Detection of Potentially Compromised Computer Nodes and Clusters Connected on a Smart Grid, Using Po.pdf:application/pdf},
+}
+
+@inproceedings{james_detection_2017,
+	title = {Detection of anomalous behavior of smartphones using signal processing and machine learning techniques},
+	url = {https://ieeexplore.ieee.org/document/8292418},
+	doi = {10.1109/PIMRC.2017.8292418},
+	abstract = {Different applications in smartphones result in different power consumption patterns. The fact that every application has been coded to perform different tasks leads to the claim that every action onboard (whether software or hardware) will consequently have a trace in the power consumption of the smartphone. Even though the power consumed by the application might not be the same every time it is used, there still remains a similarity in the power consumption pattern. An anomalous behavior on the smartphone would result in a reduction in the similarity of the power consumption pattern. This change in similarity can be used to detect the presence of anomalous behavior of smartphones. We have proposed two approaches to detecting anomalous behavior on smartphones based on the power consumption pattern. The first approach is based on signal processing and the second approach explores the area of statistical learning in detecting malware. The two approaches have been analysed, evaluated, and compared. It has been observed that the signal processing method of detection performed better for anomalous behavior of lower intensity and the statistical learning method performed better for higher intensity anomalous behavior. It was also observed that both the methods are complementary.},
+	urldate = {2024-11-07},
+	booktitle = {2017 {IEEE} 28th {Annual} {International} {Symposium} on {Personal}, {Indoor}, and {Mobile} {Radio} {Communications} ({PIMRC})},
+	author = {James, R. Soundar Raja and Albasir, A. and Naik, K. and Dabbagh, M. Y. and Dash, P. and Zamani, M. and Goel, N.},
+	month = oct,
+	year = {2017},
+	note = {ISSN: 2166-9589},
+	keywords = {Malware, Power demand, Power measurement, Signal processing, Smart phones, Statistical learning},
+	pages = {1--7},
+	annote = {Power pattern detection and anomalous activity detection, but on smartphone.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/JQL8YJ2D/James et al. - 2017 - Detection of anomalous behavior of smartphones using signal processing and machine learning techniqu.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/XQE3UMIP/8292418.html:text/html},
+}
+
+@inproceedings{bridges_towards_2018,
+	title = {Towards {Malware} {Detection} via {CPU} {Power} {Consumption}: {Data} {Collection} {Design} and {Analytics}},
+	shorttitle = {Towards {Malware} {Detection} via {CPU} {Power} {Consumption}},
+	url = {https://ieeexplore.ieee.org/document/8456118},
+	doi = {10.1109/TrustCom/BigDataSE.2018.00250},
+	abstract = {This paper presents an experimental design and algorithm for power-based malware detection on general-purpose computers. Our design allows programmatic collection of CPU power profiles for a fixed set of non-malicious benchmarks, first running in an uninfected state and then in an infected state with malware running along with non-malicious software. To characterize power consumption profiles, we use both simple statistical and novel, sophisticated features. We propose an unsupervised, one-class anomaly detection ensemble and compare its perfor-mance with several supervised, kernel-based SVM classifiers (trained on clean and infected profiles) in detecting previously unseen malware. The anomaly detection system exhibits perfect detection when using all features across all benchmarks, with smaller false detection rate than the supervised classifiers. This paper provides a proof of concept that power-based malware detection is feasible for general-purpose computers and presents several future research steps toward that goal.},
+	urldate = {2024-11-07},
+	booktitle = {2018 17th {IEEE} {International} {Conference} {On} {Trust}, {Security} {And} {Privacy} {In} {Computing} {And} {Communications}/ 12th {IEEE} {International} {Conference} {On} {Big} {Data} {Science} {And} {Engineering} ({TrustCom}/{BigDataSE})},
+	author = {Bridges, Robert and Hernández Jiménez, Jarilyn and Nichols, Jeffrey and Goseva-Popstojanova, Katerina and Prowell, Stacy},
+	month = aug,
+	year = {2018},
+	note = {ISSN: 2324-9013},
+	keywords = {Malware, Power demand, anomaly detection, Anomaly detection, Benchmark testing, Computers, Detectors, intrusion detection, malware, power monitoring, rootkit, side channel analysis},
+	pages = {1680--1684},
+	annote = {This paper focuses on collecting a power dataset for infected and clean machine and then training a model to classify them. This is a good step toward verification of loca lressources (the label infected/clean is kind of a local ressource) but the method and goal are very different: malware vs hidden processes and SVM classification vs NN regression.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/RYB2CQ8U/Bridges et al. - 2018 - Towards Malware Detection via CPU Power Consumption Data Collection Design and Analytics.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/PCBDDMKS/8456118.html:text/html},
+}
+
+@inproceedings{sukhija_towards_2022,
+	address = {New York, NY, USA},
+	series = {{MEDES} '22},
+	title = {Towards {Anomaly} {Detection} for {Monitoring} {Power} {Consumption} in {HPC} {Facilities}},
+	isbn = {978-1-4503-9219-8},
+	url = {https://doi.org/10.1145/3508397.3564826},
+	doi = {10.1145/3508397.3564826},
+	abstract = {Given the increasing complexity and the heterogeneity of today's computing system infrastructure, power efficiency and fault tolerance remain the top challenges of an High Performance Computing (HPC) facility operation. Recently, many research efforts are focusing on monitoring solutions for collecting, correlating, and analyzing computing infrastructures health events and metrics data to not only identify the normal events but also the anomalous, thus aiding to reduce downtime and power consumption in the face of a computational center's and users' critical needs. In this preliminary work, we present an anomaly detection methodology integrated with the Operations Monitoring and Notification Infrastructure (OMNI) data warehouse at Lawrence Berkeley National Laboratory's (LBNL) National Energy Scientific Computing Center (NERSC) that has implemented anomaly detection algorithms for identifying abnormal power patterns. We evaluated our methodology using five million unlabeled power datasets from the Cori computation system at NERSC and reported on the accuracy of the anomaly detection algorithms in detecting different anomalous behavior pertaining to the amount of power consumed. The methodology is employed to aid in monitoring and automating power alerting to achieve power efficiency and reliability in future systems to be deployed at NERSC or other HPC facilities.},
+	urldate = {2024-11-07},
+	booktitle = {Proceedings of the 14th {International} {Conference} on {Management} of {Digital} {EcoSystems}},
+	publisher = {Association for Computing Machinery},
+	author = {Sukhija, Nitin and Bautista, Elizabeth and Butz, Drake and Whitney, Cary},
+	month = dec,
+	year = {2022},
+	pages = {1--8},
+	annote = {This article does not correlate with the logs at all. The detection of anomalous events is done purely with analysis of the power only using an unsupervised model trained on the power only.
+},
+	file = {PDF:/home/grizzly/Zotero/storage/LW4J6TQN/Sukhija et al. - 2022 - Towards Anomaly Detection for Monitoring Power Consumption in HPC Facilities.pdf:application/pdf},
+}
+
+@inproceedings{takasaki_anomalous_2021,
+	title = {An {Anomalous} {Behavior} {Detection} {Method} {Based} on {Power} {Analysis} {Utilizing} {Steady} {State} {Power} {Waveform} {Predicted} by {LSTM}},
+	url = {https://ieeexplore.ieee.org/document/9486706},
+	doi = {10.1109/IOLTS52814.2021.9486706},
+	abstract = {Hardware security issues have emerged in recent years as Internet of Things (IoT) devices have rapidly spread. Power analysis is one of the methods to detect anomalous operations, but it is hard to apply it to IoT devices where an operating system and various software programs are running and hence its power waveforms become more complex. In this paper, we propose an anomalous behavior detection method utilizing application-specific power behaviors extracted by steady-state power waveform, which is generated by LSTM (long short-term memory). The proposed method is based on extracting application-specific power behaviors by predicting steady-state power waveforms. At that time, by using LSTM, we can effectively predict steady-state power waveforms, even if they include one or more cycled waveforms and/or they are composed of many complex waveforms. In the experiment, we implement three normal application programs and one anomalous application program on a single board computer and apply the proposed method to it. The experimental results demonstrate that the proposed method successfully detects the anomalous power behavior of an anomalous application program, while the existing method cannot.},
+	urldate = {2024-11-07},
+	booktitle = {2021 {IEEE} 27th {International} {Symposium} on {On}-{Line} {Testing} and {Robust} {System} {Design} ({IOLTS})},
+	author = {Takasaki, Kazunari and Kida, Ryoichi and Togawa, Nozomu},
+	month = jun,
+	year = {2021},
+	note = {ISSN: 1942-9401},
+	keywords = {anomalous behavior, Hardware, Internet of Things, IoT device, LSTM, Operating systems, power analysis, Security, Software, Steady-state, System analysis and design},
+	pages = {1--7},
+	annote = {This paper gets dangerously close. If I understand correctly, they do not use the data from the machine. They use previous power consumption data to predict the next power data. Because the power consumption should follow a steady pattern for the same program, then deviation can be detected. Read the full article to be sure.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/HQBNCHA9/Takasaki et al. - 2021 - An Anomalous Behavior Detection Method Based on Power Analysis Utilizing Steady State Power Waveform.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/7ECVKIEA/9486706.html:text/html},
+}
+
+@inproceedings{moreno_efficient_2016,
+	title = {Efficient program tracing and monitoring through power consumption - with a little help from the compiler},
+	url = {https://ieeexplore.ieee.org/document/7459561?arnumber=7459561},
+	abstract = {Ensuring correctness and enforcing security are growing concerns given the complexity of modern connected devices and safety-critical systems. A promising approach is non-intrusive runtime monitoring through reconstruction of program execution traces from power consumption measurements. This can be used for verification, validation, debugging, and security purposes. In this paper, we propose a framework for increasing the effectiveness of power-based program tracing techniques. These systems determine the most likely block of source code that produced an observed power trace (CPU power consumption as a function of time). Our framework maximizes distinguishability between power traces for different code blocks. To this end, we provide a special compiler optimization stage that reorders intermediate representation (IR) and determines the reorderings that lead to power traces with highest distances between each other, thus reducing the probability of misclassification. Our work includes an experimental evaluation, using LLVM for an ARM architecture. Experimental results confirm the effectiveness of our technique.},
+	urldate = {2024-11-07},
+	booktitle = {2016 {Design}, {Automation} \& {Test} in {Europe} {Conference} \& {Exhibition} ({DATE})},
+	author = {Moreno, Carlos and Kauffman, Sean and Fischmeister, Sebastian},
+	month = mar,
+	year = {2016},
+	note = {ISSN: 1558-1101},
+	keywords = {Power demand, Power measurement, Security, Electronic mail, Monitoring, Optimization, Training},
+	pages = {1556--1561},
+	annote = {The power consumption is correlated with the activity of the program for “verification, validation, debugging, and security purposes”. It does require the compiler order code blocks for maximal detectability.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/J7YXVQBD/Moreno et al. - 2016 - Efficient program tracing and monitoring through power consumption - with a little help from the com.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/9YQB5S9Y/7459561.html:text/html},
+}
+
+@inproceedings{zhu_towards_2012,
+	title = {Towards a {Novel} {Approach} for {Hidden} {Process} {Detection} {Based} on {Physical} {Memory} {Scanning}},
+	url = {https://ieeexplore.ieee.org/document/6405787/?arnumber=6405787},
+	doi = {10.1109/MINES.2012.239},
+	abstract = {Leveraging developed root kit, malware could deeply hide its own process and hardly be detected. Based on analyzing various existing detecting technologies, a novel approach for hidden process detection was proposed in this paper. The approach used page table entry patching to traverse physical memory and obtain the raw data, and formulated the characteristic selection constraints to extract reliable process object characteristics, which were used to search process object instances based on string matching in physical memory to form a credible list of processes. The approach could also be used to search other kernel objects on varieties of system platforms. The experimental results show that new detection is effective in hidden process searching.},
+	urldate = {2024-11-06},
+	booktitle = {2012 {Fourth} {International} {Conference} on {Multimedia} {Information} {Networking} and {Security}},
+	author = {Zhu, Junhu and Zhou, Tianyang and Wang, Qingxian},
+	month = nov,
+	year = {2012},
+	note = {ISSN: 2162-8998},
+	keywords = {Hardware, Security, Data structures, hidden process, Kernel, Memory management, paging mechanism, physical memory scan, Process control, string matching},
+	pages = {662--665},
+	annote = {Yet another memory analysis tool to detect hidden processes. This time they use “physical memory scan” but it is just another version of memory analysis that is host-based.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/64LW8E8I/Zhu et al. - 2012 - Towards a Novel Approach for Hidden Process Detection Based on Physical Memory Scanning.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/P5444QL5/6405787.html:text/html},
+}
+
+@article{nasereddin_new_2024,
+	title = {A new approach for detecting process injection attacks using memory analysis},
+	volume = {23},
+	issn = {1615-5270},
+	url = {https://doi.org/10.1007/s10207-024-00836-w},
+	doi = {10.1007/s10207-024-00836-w},
+	abstract = {This paper introduces a new approach for examining and analyzing fileless malware artifacts in computer memory. The proposed approach offers the distinct advantage of conducting a comprehensive live analysis of memory without the need for periodic memory dumping. Once a new process arrives, log files are collected by monitoring the Event Tracing for Windows facility as well as listing the executables of the active process for violation detection. The proposed approach significantly reduces detection time and minimizes resource consumption by adopting parallel computing (programming), where the main software (Master) divides the work, organizes the process of searching for artifacts, and distributes tasks to several agents. A dataset of 17411 malware samples is used in the assessment of the new approach. It provided satisfactory and reliable results in dealing with at least six different process injection techniques including classic DLL injection, reflective DLL injection, process hollowing, hook injection, registry modifications, and .NET DLL injection. The detection accuracy rate has reached \$\$99.93{\textbackslash}\%\$\$with a false-positive rate of \$\$0.068{\textbackslash}\%\$\$. Moreover, the accuracy was monitored in the case of launching several malwares using different process injection techniques simultaneously, and the detector was able to detect them efficiently. Also, it achieved a detection time with an average of 0.052 msec per detected malware.},
+	language = {en},
+	number = {3},
+	urldate = {2024-11-06},
+	journal = {International Journal of Information Security},
+	author = {Nasereddin, Mohammed and Al-Qassas, Raad},
+	month = jun,
+	year = {2024},
+	keywords = {Fileless malware, Intrusion detection, Malware analysis and detection, Memory forensics, Process injection attacks},
+	pages = {2099--2121},
+	annote = {Again an idea based on memory analysis.
+One good point is the use of known malware.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/63B57ANI/Nasereddin and Al-Qassas - 2024 - A new approach for detecting process injection attacks using memory analysis.pdf:application/pdf},
+}
+
+@inproceedings{wang_procguard_2022,
+	title = {{ProcGuard}: {Process} {Injection} {Behaviours} {Detection} {Using} {Fine}-grained {Analysis} of {API} {Call} {Chain} with {Deep} {Learning}},
+	shorttitle = {{ProcGuard}},
+	url = {https://ieeexplore.ieee.org/document/10063560/?arnumber=10063560},
+	doi = {10.1109/TrustCom56396.2022.00109},
+	abstract = {New malware increasingly adopts novel fileless techniques to evade detection from antivirus programs. Process injection is one of the most popular fileless attack techniques. This technique makes malware more stealthy by writing malicious code into memory space and reusing the name and port of the host process. It is difficult for traditional security software to detect and intercept process injections due to the stealthiness of its behavior. We propose a novel framework called ProcGuard for detecting process injection behaviors. This framework collects sensitive function call information of typical process injection. Then we perform a fine-grained analysis of process injection behavior based on the function call chain characteristics of the program, and we also use the improved RCNN network to enhance API analysis on the tampered memory segments. We combine API analysis with deep learning to determine whether a process injection attack has been executed. We collect a large number of malicious samples with process injection behavior and construct a dataset for evaluating the effectiveness of ProcGuard. The experimental results demonstrate that it achieves an accuracy of 81.58\% with a lower false-positive rate compared to other systems. In addition, we also evaluate the detection time and runtime performance loss metrics of ProcGuard, both of which are improved compared to previous detection tools.},
+	urldate = {2024-11-06},
+	booktitle = {2022 {IEEE} {International} {Conference} on {Trust}, {Security} and {Privacy} in {Computing} and {Communications} ({TrustCom})},
+	author = {Wang, Juan and Ma, Chenjun and Li, Ziang and Yuan, Huanyu and Wang, Jie},
+	month = dec,
+	year = {2022},
+	note = {ISSN: 2324-9013},
+	keywords = {Malware, API call chain, deep learning, Deep learning, Heuristic algorithms, Measurement, Privacy, process injection, Runtime, Writing},
+	pages = {778--785},
+	annote = {In this paper, the ressource monitored to detect hidden processes is specific API calls that are related to code injection. This method seems more specific to a certain type of masquerading.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/9KU2EXSB/Wang et al. - 2022 - ProcGuard Process Injection Behaviours Detection Using Fine-grained Analysis of API Call Chain with.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/WCSP8PKH/10063560.html:text/html},
+}
+
+@inproceedings{vaas_detecting_2017,
+	title = {Detecting disguised processes using application-behavior profiling},
+	url = {https://ieeexplore.ieee.org/document/7943508},
+	doi = {10.1109/THS.2017.7943508},
+	abstract = {In order to avoid detection, malware can disguise itself as a legitimate program or hijack system processes to reach its goals. Commonly used signature-based Intrusion Detection Systems (IDS) struggle to distinguish between these processes and are thus only of limited use to detect such attacks. They also have the shortcoming that they need to be updated frequently to possess the latest malware definitions. This makes them inherently prone to missing novel attack techniques. Misuse detection IDSs however overcome this problem by maintaining a ground truth of normal application behavior while reporting deviations as anomalies. In our approach, we try to accomplish this by observing a process' memory consumption. This is for two reasons: We expect the readings to be less volatile in comparison to for instance network operations. Second, by breaking the problem down, we are able to investigate thoroughly while still laying the foundations for future expansion. We use the observations from a given host to train a machine learning algorithm. After an initial learning phase, we evaluate the model with readings from the application it has been trained on and other applications in order to assess its quality. Our results indicate that the efficacy of this method is highly dependent on parametrizing the machine learning algorithm appropriately. A large variance in accuracy with only slightly altered inputs confirms this suggestion. We finish with a discussion on deploying such an IDS at scale in a realistic scenario.},
+	urldate = {2024-11-01},
+	booktitle = {2017 {IEEE} {International} {Symposium} on {Technologies} for {Homeland} {Security} ({HST})},
+	author = {Vaas, Christian and Happa, Jassim},
+	month = apr,
+	year = {2017},
+	keywords = {Malware, Training, Memory management, Intrusion detection, Data models, Time series analysis},
+	pages = {1--6},
+	annote = {This paper uses a similar idea as I do. They collect digital footprint (instead of physical ones for me) to assess the legitimacy of a process. They use memory usage as their second source of truth.
+They evaluate their method on 1 day of machine data and the legitimacy of a few processes: explorer, texmaker, mintty and ssh.
+
+Differences: Their method is host-based. So it is not immune to attackers. It simply takes the attacker one more step to bypass or feed erroneous data to the IDS.
+
+},
+	file = {IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/RJHM6UXV/7943508.html:text/html;PDF:/home/grizzly/Zotero/storage/4J5RMGK9/Vaas and Happa - 2017 - Detecting disguised processes using application-behavior profiling.pdf:application/pdf},
+}
+
+@inproceedings{yu-tao_hpdbf_2016,
+	title = {{HPDBF}: {A} forensics method for hidden process based on memory analysis},
+	shorttitle = {{HPDBF}},
+	url = {https://ieeexplore.ieee.org/document/8070249/?arnumber=8070249},
+	doi = {10.1109/ICCSNT.2016.8070249},
+	abstract = {Malicious processes usually cooperate with concealing technology to hide themselves. The detection against hidden processes can effectively narrow the range of malicious processes. Behavior analysis is then implemented on the filtered process to finally locate the malicious one. In this paper, a method of hidden process detection and behavior forensics based on memory analysis is proposed. It uses virtual machine monitor to extract and analyze memory data, detecting hidden processes; then analyzes the executable code of the target process to determine whether there is malicious behavior during the operation of the process. Experimental results demonstrated the effectiveness and the acceptable performance overhead of the proposed method.},
+	urldate = {2024-11-06},
+	booktitle = {2016 5th {International} {Conference} on {Computer} {Science} and {Network} {Technology} ({ICCSNT})},
+	author = {Yu-Tao, Zhao and Qing-Bao, Li and Guang-Yu, Zeng and San-Jun, Cheng},
+	month = dec,
+	year = {2016},
+	keywords = {hidden process, Kernel, behavior forensics, Forensics, Linux, memory analysis, Schedules, semantic reconstruction, Semantics, Virtual machine monitors},
+	pages = {705--710},
+	annote = {Same idea as Vaas and Happa, use memory analysis to detect hidden processes.
+},
+	file = {Full Text PDF:/home/grizzly/Zotero/storage/FU379NT5/Yu-Tao et al. - 2016 - HPDBF A forensics method for hidden process based on memory analysis.pdf:application/pdf;IEEE Xplore Abstract Record:/home/grizzly/Zotero/storage/LNAZ34XB/8070249.html:text/html},
+}
+
+@misc{noauthor_unveiling_nodate,
+	title = {Unveiling {WolfsBane}: {Gelsemium}’s {Linux} counterpart to {Gelsevirine}},
+	shorttitle = {Unveiling {WolfsBane}},
+	url = {https://www.welivesecurity.com/en/eset-research/unveiling-wolfsbane-gelsemiums-linux-counterpart-to-gelsevirine/},
+	abstract = {ESET researchers analyzed previously unknown Linux backdoors that are connected to known Windows malware used by the China-aligned Gelsemium group, as well as to Project Wood.},
+	language = {en},
+	urldate = {2024-11-22},
+	file = {Snapshot:/home/grizzly/Zotero/storage/6WSUP3XC/unveiling-wolfsbane-gelsemiums-linux-counterpart-to-gelsevirine.html:text/html},
+}
+
+@misc{noauthor_unix-thrustbeurk_2024,
+	title = {unix-thrust/beurk},
+	copyright = {GPL-3.0},
+	url = {https://github.com/unix-thrust/beurk},
+	abstract = {BEURK Experimental Unix RootKit},
+	urldate = {2024-11-22},
+	publisher = {unix-thrust},
+	month = nov,
+	year = {2024},
+	note = {original-date: 2015-04-14T15:30:44Z},
+}

procver/ACNS/main.tex

@@ -0,0 +1,216 @@
+\documentclass[runningheads]{llncs}
+%
+\usepackage[T1]{fontenc}
+% T1 fonts will be used to generate the final print and online PDFs,
+% so please use T1 fonts in your manuscript whenever possible.
+% Other font encondings may result in incorrect characters.
+%
+\usepackage{graphicx}
+\usepackage{xcolor}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+\usepackage{acro}
+\input{acronyms}
+
+% Used for displaying a sample figure. If possible, figure files should
+% be included in EPS format.
+
+\newcommand\agd[1]{{\color{red}$\bigstar$}\footnote{agd: #1}}
+
+% If you use the hyperref package, please uncomment the following two lines
+% to display URLs in blue roman font according to Springer's eBook style:
+%\usepackage{color}
+%\renewcommand\UrlFont{\color{blue}\rmfamily}
+%\urlstyle{rm}
+%
+\begin{document}
+%
+\title{PowPrint: Big Patounes all over the Power Trace}
+%
+%\titlerunning{Abbreviated paper title}
+% If the paper title is too long for the running head, you can set
+% an abbreviated paper title here
+%
+\author{Arthur Grisel-Davy\inst{1}\orcidID{0000-1111-2222-3333} \and
+Sebastiean Fischmeister\inst{1}\orcidID{1111-2222-3333-4444}}
+%
+\authorrunning{A. Grisel-Davy and Sebastian Fischmeister.}
+% First names are abbreviated in the running head.
+% If there are more than two authors, 'et al.' is used.
+%
+\institute{University of Waterloo, Waterloo, CA
+\email{agriseld@uwaterloo.ca}\\
+}
+%
+\maketitle              % typeset the header of the contribution
+%
+\begin{abstract}
+The cat and mouse game has led attackers to use ever-increasingly complex evasion technics to hide their malware.
+ 
+\keywords{Intrusion Detection \and Side-Channel Analysis \and Power Trace.}
+\end{abstract}
+
+\section{Introduction}
+%The modern landscape of malware families is diverse.
+%Attackers write malware for a wide range or purposes, each with their goals, target systems, attacks vectors, and constraints.
+%Some malware are purely destructive, designed to destroy data or equipement or harm people.
+%Others have ulterior notive like disrupting target operations, extract sensitive information, or request ransoms.
+%
+%Most malware a complexe pieces of sotware that require expertise and time to developp.
+%Among them, one group sits above all in terms of complexity and capabilities, the Advanced Persistent Threats.
+%APTs are meta-malware that may not be directly intended to cause harm to the target.
+%Instead, they are a framework from which a payloads can operate.
+%The APT are diverse depending on the authors, the capabilities, and the intendent audience.
+%However common capabilities of APTs are deployment, persistence, and stealth.
+%
+%In this sutdy, we are interested in the stealth capabilities of malwares.
+%Malware authors often wish for their program to remain undetected on the infected machine.
+%Hidden on the target, the malware can remain active and either continuously perform its intended actions or wait for commands.
+%Effectively hiding a piece of software is a complex task on two main levels.
+%First, from a filesystem of static analysispoint of view, the executable or code that consitute the malware must be invisible or appear innofensive.
+%Then, when running, the malware must also either hide its activity from HIDS or masquerade a valid process.
+%
+%In this study, we consider the second case when a program is performing actions shile remaining invisible or innofensive from the operating system.
+
+Malware developement has always been a field of computer science that rivals in complexity with the most current academic research.
+To remain effective, malware must keep up and even lead the most advanced detection and prevention mechanisms.
+This complexity has kept modern malware capable of infiltrate and iscrupt systems while avoiding detection.
+
+While stealth may not be main focus of all malwares --- some are designed with destructive power or speed of deployement and action ---, the ability to remain hidden on the infected system --- called evasion --- is a common feature of many modern malware.
+Thanks to the creativity of malware authors, many evasions technics have been used over time.
+While most were discovered and documented, it is safe to assume that there are and will always be evasions technics that are on step ahead and bypases the current detection methods.
+
+Evasions technics is un umbrella terms that englobes \agd{find appropriate word} multiple sub categories, each for a different purpose.
+One aspect of evasion is the ability to conceal the malicious nature of the files that consitute the ;alware.
+For this purpose, alware may employ homomorphic or metamorphic methods to "dejouer" signature analysis or use a fileless design to avoid analsysi altogether.
+Another compleing capability is the ... \agd{find another evasion technic}
+
+This study focuses on another specific evasion domain, process hiding.
+The list of running processes is an obvious compeling ressource to start detectin malware.
+To detect running malware, one could simply gather the list of all running software and search for known malware.
+With the list of processes frequently collected, an \ac{hids} \agd{replace acronym} can detect known malware, mine rules, define an activity profile, or detect anomalous situations.
+
+Staying off the process list is good first step for any malware aiming for stealth.
+We can categorize the technics achieving this type of evasion between hiding and masquerading.
+For process hiding, the goal is to execute a program and leave no trace of it in the process list.
+For process masquerading, the aim is not so much to avoid the listing but to avoid the malware being listed with its real identity.
+A process masquerading an another will assume its process name and characteristics, with the goal of appearing legitimate on the machine.
+Process hiding and masquerading differ in their ultimate goal but leverage a lot of the same technics.
+The core idea of process list manipulation is tampering with the process listing mechanism provided by the OS to the monitoring software.
+Independently of the \ac{os}, attackers often rely on intercepting system's call to remove or replace information or directly manipulating kernel objects.
+For the purpose of this study, we do not differentiate between Unix-based OSs and Windows systems as process hiding is a common practice for malware in both environments.
+
+% there are detection methods but they are all host-based and dommed to be bypassed
+Of course, many methods have been proposed and implemented to detect or counter process list tampering.
+These methods --- although they leverage different mechanisms --- are all host-based.
+This create a circular dependency where the \ac{ids} rely on the host system to provide the very information leveraged to assess its integrity.
+In this situation, an attacker that succesfully compromises a machine can employ evasion technics that manipulate the data used for detection.
+As rootkis providing process hiding remained a threat since their introduction, it is safe to assume that current countermesures --- and future ones based on similar technics --- do not provide complete protection.
+
+% is it a bird? is it a plane? No its the good old power consumption!
+One possible alternate method for detecting process list manipulation is using a secondary source of information to corroborate the process list.
+To avoid bypass, the secondary source must be independent from the \ac{os} and not require its cooperation to enable protection.
+However, the source must also provide information correlated with process presence and activity on the machine.
+
+\ac{sci} are compeling as the secondary source.
+As involuntary emissions, they are intrisecely independent from the origin system.
+No communication is required with the system to access these information.
+As physical by-product of the computation, they are hard to forge from an attacker point of view.
+A program can somewhat controle its computation intensity but it is difficult to precisely controle the  generated emission and impossible to fully supress them.
+If the attacker wish to perform any computation on the compromised machine, it will result in some form of physical emission.
+The most common \ac{sci} leveraged for attack or defense is energy consumption.
+Due to its ease of capture, high reliability, large range of application, and good informative potential about the activity of the system.
+Of course, there are drawbacks to using power consumption as a source of information.
+First, the raw power consumption of a machine is not an actionable piece of information.
+A step of information mining --- for example pattern recognition, anomaly detection, or even a simple thresholding --- is always required to take a decision.
+Then, measuring true independent power consumption data require additional hardware.
+Although software estimations of power consumption are available, they bear the same issue as other host-based source of information.
+Finaly, the power consumption of a mchine only ontains a small subset of all information related to processes activity.
+A \ac{cpu} are capable or hundreds to thousands of millions operations per seconds.
+Each intruction triggers multiple consumptions patterns acrosses multiple components of the system.
+Although --- in theory --- the power consumption is a sum of all these sub-consumptions, the reality of measurement --- in terms of resolution, accuracy, and sampling rate --- make single-instruction measurement unrealistic at a global scale of the \ac{cpu}.
+
+Taking all these limitations into account, the power consumption of a machine --- and more specifically the global power consuimption of its \ac{cpu} --- is a valuable complementary source of information.
+The correlation between a list of processes and the power consumption can enable the detection of process list tampering, evidence of malware activity.
+
+
+% Thank you king of sweden. No it was nothing you are welcome. Ok get home safe now. Byeeee.
+
+
+
+
+\subsection{Contribution}
+This paper proposes a novel approach for detecting tampering of process listing using power consumption traces.
+After a period of learning on known-good data, a machine learning model can predict the expected power consumption of a the \ac{cpu} of a system from the list of processes at a point in time.
+This expected consumption may diverge significantly from the real consumption and indicate an error in either source of information.
+Assuming that the power consumption is immune to tampering due to its complete isolation from the monitored system, the source of the deviation can only result from an illegal modification of the process list.
+The nature of the divergence can further inform about the nature of the tampering.
+
+
+\section{Related Work}
+
+\subsection{Evasion Technics}
+% Evasion technics
+
+\subsection{Countermeasures}
+% HIDS countermeasures
+% Present the current technics for detecting process list tampering.
+% Point out that they are all host-based
+
+\subsection{Side-Channel Correlation}
+% Usage of side-channel for correlating system's state
+%
+
+\section{Problem Statement}
+
+The main problem that this study proposes to tack can be described as follows:
+
+\begin{center}
+    Given the list of processes and their state and the power consumption of the \ac{cpu} over the same time periode, identify any tampering of the process list.
+\end{center}
+
+The list of processes over time $P = \{p_0,p_1\dots,p_{n-1}\}$ is a nested data object where each item $p_i$ contains all listed processes at timestamp $i$ named the \ac{ilp}.
+Each \ac{ilp} contains the name and state of each process present on the machine at a point in time.
+From capture to utilization in the prediction model, the process list $P$ undergo a number of transformation to reorganise the information for learning.
+See Section~\ref{sec:preprocessing} for technical details about the process list processing.
+
+The power consumption trace --- also named power trace --- is a univariate time series representing the measured power consumption of the \ac{cpu} over time.
+
+\subsection{Attacker Model}
+
+% Capabilities
+This study assumes a powerfull attacker with complete remote access to the monitored machine.
+We suppose that the attacker previously established remote access and can use this access at will and without risking detection.
+For example, the attacker could have recovered legitimate credentials for a local account on the machine.
+Moreover, the attacker is assumed to enjoy unrestricted access to the machine with the highest priviledge level.
+No operation on the machine is impossible to the attacker.
+
+The only limitation of the attacker is pysical access to the power measurement system.
+This mechanism may be additional hardware installed in a machine or built-in by the manufacturer.
+In any case, the attacker does not have access to the internal components responsible for measuring, processing, or sending the power consumption to the verification machine.
+
+However, the attacker can gain access to other components of the machine.
+For example, it is expected that the attacker can attack storage devices and boot a different \ac{os} than expected.
+
+% Goals
+The goal of the attacker is outside the scope of this study.
+The only expected intention of the attacker is to remain stealthy against \ac{ids}.
+To acieve stealth, the attacker will employ evasion technics to hide or masquerade its malicious processes using any method available to them.
+
+
+% Knowledge: The attacker may know about the monitoring system.
+This study assumes that teh attacker is aware that the proposed defense mechanism in installed on the machine.
+There is no part of the proposed approach that should remain secret to achieve its full potential.
+
+\section{Proposed Approach}
+
+\section{Case Studies}
+
+\section{Discussion}
+
+\section{Conclusion}
+
+\bibliography{biblio} % Import the bibliography
+\bibliographystyle{plain} % set the reference style
+
+\end{document}

procver/ACNS/notes.txt

@@ -0,0 +1,28 @@
+Main Points for the Introduction
+
+    Background and Motivation:
+        The increasing sophistication of malware and attack techniques, such as rootkits and masquerading processes, poses significant challenges to traditional detection mechanisms.
+        Hidden or masqueraded processes can evade standard tools by leveraging techniques like kernel-level manipulation, API hooking, or process injection.
+
+    Limitations of Current Approaches:
+        Signature-based and behavior-based detection methods are often circumvented by polymorphic or fileless malware.
+        Existing tools may struggle to differentiate between legitimate and malicious processes, especially when attackers mimic trusted processes.
+
+    Emerging Focus on Side-Channel Analysis:
+        Side-channel data, such as power consumption, has emerged as a promising non-invasive means of system monitoring.
+        Power consumption patterns inherently reflect the activity of running processes, including their computational and memory usage characteristics.
+
+    Research Gap:
+        While side-channel data has been explored for other applications, its potential for detecting hidden or masqueraded processes remains underexplored.
+        A reliable method to associate anomalous power consumption patterns with malicious process activity could significantly enhance detection capabilities.
+
+    Proposed Contribution:
+        Introduction of a novel method leveraging power consumption patterns to detect hidden or masqueraded processes.
+        Description of how the method identifies deviations from expected power usage profiles using advanced statistical or machine learning techniques.
+
+    Significance of the Work:
+        The proposed method offers a complementary tool to traditional detection systems, enhancing system security.
+        Its ability to utilize hardware-level data reduces reliance on potentially compromised software-based mechanisms.
+
+    Structure of the Article:
+        Overview of the proposed method, followed by an in-depth explanation of the methodology, experimental setup, results, and discussion on implications and limitations.

procver/SnP/acronyms.tex

@@ -0,0 +1,103 @@
+\DeclareAcronym{ids}{
+    short={IDS},
+    long={Intrusion Detection System}
+}
+\DeclareAcronym{hids}{
+    short={HIDS},
+    long={Host-Based Intrusion Detection System}
+}
+\DeclareAcronym{os}{
+    short={OS},
+    long={Operating System}
+}
+\DeclareAcronym{sci}{
+    short={SCI},
+    long={Side-Channel Information}
+}
+\DeclareAcronym{cpu}{
+    short={CPU},
+    long={Central Processing Unit}
+}
+\DeclareAcronym{ilp}{
+    short={ILP},
+    long={Instantaneous List of Processes}
+}
+
+\DeclareAcronym{uefi}{
+    short={UEFI},
+    long={Unified Extensible Firmware Interface}
+}
+
+\DeclareAcronym{vm}{
+    short={VM},
+    short-plural={s},
+    long={Virtual Machine},
+    long-plural={s}
+}
+
+\DeclareAcronym{vmm}{
+    short={VMM},
+    short-plural={VMMs},
+    long={Virtual Machine Monitor},
+    long-plural={Virtual Machine Monitors}
+}
+
+\DeclareAcronym{msrt}{
+    short={MSRT},
+    long={Malicious Software Removal Tool}
+}
+
+\DeclareAcronym{cve}{
+    short={CVE},
+    long={Common Vulnerabilities and Exposures}
+}
+
+\DeclareAcronym{ssl}{
+    short={SSL},
+    long={Secure Socket Layer}
+}
+
+\DeclareAcronym{nilm}{
+    short={NILM},
+    long={Non-Intrusive Load Monitoring}
+}
+
+\DeclareAcronym{bios}{
+    short={BIOS},
+    long={Basic Input/Output System}
+}
+
+\DeclareAcronym{tsv}{
+    short={TSV},
+    long={Tab-Separated Values}
+}
+
+\DeclareAcronym{pcb}{
+    short={PCB},
+    long={Printed Circuit Board}
+}
+
+\DeclareAcronym{aws}{
+    short={AWS},
+    long={Amazon Web Services}
+}
+
+\DeclareAcronym{dtw}{
+    short={DTW},
+    long={Dynamic Time Warping}
+}
+
+\DeclareAcronym{mlp}{
+    short={MLP},
+    long={Multilayer Perceptron}
+}
+
+\DeclareAcronym{mae}{
+    short={MAE},
+    long={Mean Absolute Error}
+}
+
+\DeclareAcronym{mse}{
+    short={MSE},
+    long={Mean Squared Error}
+}

procver/SnP/biblio.bib

@@ -0,0 +1,286 @@
+@misc{win-msrt,
+  author = {Microsoft},
+  title = {Windows Malicious Software Removal Tool: Progress Made, Trends Observed},
+  year = 2024,
+  url = {https://www.microsoft.com/en-us/download/details.aspx?id=14591},
+  urldate = {01-05-2025}
+}
+
+@misc{cosmicstrand,
+  author = {Kaspersky},
+  title = {CosmicStrand: sophisticated firmware rootkit allows durable persistence},
+  year = 2022,
+  url = {https://www.kaspersky.com/about/press-releases/cosmicstrand-sophisticated-firmware-rootkit-allows-durable-persistence},
+  urldate = {01-05-2025}
+}
+
+@inproceedings{10.1145/1315245.1315262,
+author = {Jiang, Xuxian and Wang, Xinyuan and Xu, Dongyan},
+title = {Stealthy malware detection through vmm-based "out-of-the-box" semantic view reconstruction},
+year = {2007},
+isbn = {9781595937032},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/1315245.1315262},
+doi = {10.1145/1315245.1315262},
+abstract = {An alarming trend in malware attacks is that they are armed with stealthy techniques to detect, evade, and subvert malware detection facilities of the victim. On the defensive side, a fundamental limitation of traditional host-based anti-malware systems is that they run inside the very hosts they are protecting ("in the box"), making them vulnerable to counter-detection and subversion by malware. To address this limitation, recent solutions based on virtual machine (VM) technologies advocate placing the malware detection facilities outside of the protected VM ("out of the box"). However, they gain tamper resistance at the cost of losing the native, semantic view of the host which is enjoyed by the "in the box" approach, thus leading to a technical challenge known as the semantic gap.In this paper, we present the design, implementation, and evaluation of VMwatcher - an "out-of-the-box" approach that overcomes the semantic gap challenge. A new technique called guest view casting is developed to systematically reconstruct internal semantic views (e.g., files, processes, and kernel modules) of a VM from the outside in a non-intrusive manner. Specifically, the new technique casts semantic definitions of guest OS data structures and functions on virtual machine monitor (VMM)-level VM states, so that the semantic view can be reconstructed. With the semantic gap bridged, we identify two unique malware detection capabilities: (1) view comparison-based malware detection and its demonstration in rootkit detection and (2) "out-of-the-box" deployment of host-based anti-malware software with improved detection accuracy and tamper-resistance. We have implemented a proof-of-concept prototype on both Linux and Windows platforms and our experimental results with real-world malware, including elusive kernel-level rootkits, demonstrate its practicality and effectiveness.},
+booktitle = {Proceedings of the 14th ACM Conference on Computer and Communications Security},
+pages = {128–138},
+numpages = {11},
+keywords = {virtual machines, rootkits, malware detection},
+location = {Alexandria, Virginia, USA},
+series = {CCS '07}
+}
+
+@inproceedings{wen2008implicit,
+  title={Implicit detection of hidden processes with a feather-weight hardware-assisted virtual machine monitor},
+  author={Wen, Yan and Zhao, Jinjing and Wang, Huaimin and Cao, Jiannong},
+  booktitle={Information Security and Privacy: 13th Australasian Conference, ACISP 2008, Wollongong, Australia, July 7-9, 2008. Proceedings 13},
+  pages={361--375},
+  year={2008},
+  organization={Springer}
+}
+
+@inproceedings{jones2008vmm,
+  title={VMM-based hidden process detection and identification using Lycosid},
+  author={Jones, Stephen T and Arpaci-Dusseau, Andrea C and Arpaci-Dusseau, Remzi H},
+  booktitle={Proceedings of the fourth ACM SIGPLAN/SIGOPS international conference on Virtual execution environments},
+  pages={91--100},
+  year={2008}
+}
+
+@inproceedings{wang2005detecting,
+  title={Detecting stealth software with strider ghostbuster},
+  author={Wang, Y-M and Beck, Doug and Vo, Binh and Roussev, Roussi and Verbowski, Chad},
+  booktitle={2005 International Conference on Dependable Systems and Networks (DSN'05)},
+  pages={368--377},
+  year={2005},
+  organization={IEEE}
+}
+
+@article{cloudburst,
+  title={Cloudburst},
+  author={Kortchinsky, Kostya},
+  journal={Black Hat USA.[http://www.blackhat.com/presentations/bh-usa-09/KORTCHINSKY/BHUSA09-Kortchinsky-Cloudburst-PAPER.pdf]},
+  year={2009}
+}
+
+@misc{cve-vmware-2017,
+  title = {CVE-2017-4902},
+  author = {VMware},
+  howpublished = "Available from NIST NVD",
+  year = {2017},
+  url={https://nvd.nist.gov/vuln/detail/CVE-2017-4902},
+  urldate={03 May 2025}
+}
+
+@misc{cve-vbox-2021,
+  title = {CVE-2021-2443},
+  author = {VirtualBox},
+  howpublished = "Available from NIST NVD",
+  year = {2021},
+  url={https://nvd.nist.gov/vuln/detail/CVE-2021-2443},
+  urldate={03 May 2025}
+}
+
+@misc{cve-qemu-2019,
+  title = {CVE-2019-6778},
+  author = {QEMU},
+  howpublished = "Available from NIST NVD",
+  year = {2019},
+  url={https://nvd.nist.gov/vuln/detail/CVE-2019-6778},
+  urldate={03 May 2025}
+}
+
+@misc{cve-xen-2015,
+  title = {CVE-2015-5154},
+  author = {Xen},
+  howpublished = "Available from NIST NVD",
+  year = {2015},
+  url={https://nvd.nist.gov/vuln/detail/CVE-2015-5154},
+  urldate={03 May 2025}
+}
+
+@misc{cve-hyperv-2021,
+  title = {CVE-2021-28476},
+  author = {Microsoft Hyper-V},
+  howpublished = "Available from NIST NVD",
+  year = {2021},
+  url={https://nvd.nist.gov/vuln/detail/CVE-2021-28476},
+  urldate={03 May 2025}
+}
+
+@inproceedings{kocher1996timing,
+  title={Timing attacks on implementations of Diffie-Hellman, RSA, DSS, and other systems},
+  author={Kocher, Paul C},
+  booktitle={Advances in Cryptology—CRYPTO’96: 16th Annual International Cryptology Conference Santa Barbara, California, USA August 18--22, 1996 Proceedings 16},
+  pages={104--113},
+  year={1996},
+  organization={Springer}
+}
+
+@article{van1985electromagnetic,
+  title={Electromagnetic radiation from video display units: An eavesdropping risk?},
+  author={Van Eck, Wim},
+  journal={Computers \& Security},
+  volume={4},
+  number={4},
+  pages={269--286},
+  year={1985},
+  publisher={Elsevier}
+}
+
+@article{brumley2005remote,
+  title={Remote timing attacks are practical},
+  author={Brumley, David and Boneh, Dan},
+  journal={Computer Networks},
+  volume={48},
+  number={5},
+  pages={701--716},
+  year={2005},
+  publisher={Elsevier}
+}
+
+@INPROCEEDINGS{1301311,
+  author={Asonov, D. and Agrawal, R.},
+  booktitle={IEEE Symposium on Security and Privacy, 2004. Proceedings. 2004}, 
+  title={Keyboard acoustic emanations}, 
+  year={2004},
+  volume={},
+  number={},
+  pages={3-11},
+  keywords={Keyboards;Neural networks;Microphones;Telephony;Acoustic devices;Immune system;Humans;Ear;Computer security;Information security},
+  doi={10.1109/SECPRI.2004.1301311}
+}
+
+@article{worden2007application,
+  title={The application of machine learning to structural health monitoring},
+  author={Worden, Keith and Manson, Graeme},
+  journal={Philosophical Transactions of the Royal Society A: Mathematical, Physical and Engineering Sciences},
+  volume={365},
+  number={1851},
+  pages={515--537},
+  year={2007},
+  publisher={The Royal Society London}
+}
+@inproceedings{shewale2019novel,
+  title={Novel machine health monitoring system},
+  author={Shewale, Mahesh S and Mulik, Sharad S and Deshmukh, Suhas P and Patange, Abhishek D and Zambare, Hrishikesh B and Sundare, Advait P},
+  booktitle={Proceedings of the 2nd International Conference on Data Engineering and Communication Technology: ICDECT 2017},
+  pages={461--468},
+  year={2019},
+  organization={Springer}
+}
+
+@article{khan2019malware,
+  title={Malware detection in embedded systems using neural network model for electromagnetic side-channel signals},
+  author={Khan, Haider Adnan and Sehatbakhsh, Nader and Nguyen, Luong N and Prvulovic, Milos and Zaji{\'c}, Alenka},
+  journal={Journal of Hardware and Systems Security},
+  volume={3},
+  pages={305--318},
+  year={2019},
+  publisher={Springer}
+}
+
+@inproceedings{cathis2024sok,
+  title={SoK Paper: Power Side-Channel Malware Detection},
+  author={Cathis, Alexander and Li, Ge and Wei, Shijia and Orshansky, Michael and Tiwari, Mohit and Gerstlauer, Andreas},
+  booktitle={Proceedings of the International Workshop on Hardware and Architectural Support for Security and Privacy 2024},
+  pages={1--9},
+  year={2024}
+}
+
+@ARTICLE{7362010,
+  author={Caviglione, Luca and Gaggero, Mauro and Lalande, Jean-François and Mazurczyk, Wojciech and Urbański, Marcin},
+  journal={IEEE Transactions on Information Forensics and Security}, 
+  title={Seeing the Unseen: Revealing Mobile Malware Hidden Communications via Energy Consumption and Artificial Intelligence}, 
+  year={2016},
+  volume={11},
+  number={4},
+  pages={799-810},
+  keywords={Malware;Mobile handsets;Power demand;Energy measurement;Energy consumption;Performance evaluation;Neural networks;Energy-based malware detection;covert channels;colluding applications;neural networks;decision trees;Energy-based malware detection;covert channels;colluding applications;neural networks;decision trees},
+  doi={10.1109/TIFS.2015.2510825}
+}
+
+@article{chou2014real,
+  title={Real-time detection of anomalous power consumption},
+  author={Chou, Jui-Sheng and Telaga, Abdi Suryadinata},
+  journal={Renewable and Sustainable Energy Reviews},
+  volume={33},
+  pages={400--411},
+  year={2014},
+  publisher={Elsevier}
+}
+
+@inproceedings{cortez2017resource,
+  title={Resource central: Understanding and predicting workloads for improved resource management in large cloud platforms},
+  author={Cortez, Eli and Bonde, Anand and Muzio, Alexandre and Russinovich, Mark and Fontoura, Marcus and Bianchini, Ricardo},
+  booktitle={Proceedings of the 26th Symposium on Operating Systems Principles},
+  pages={153--167},
+  year={2017}
+}
+
+@misc{azure-dataset,
+  author = {Azure},
+  title = {Azure Public Dataset},
+  year = {2019},
+  publisher = {GitHub},
+  journal = {GitHub repository},
+  howpublished = {\url{https://https://github.com/Azure/AzurePublicDataset}},
+}
+
+@misc{zenodo-dataset,
+  author = {Anonymous},
+  title = {Power Consumption and Process List from Replayed Azure VM Dataset},
+  year = {2025},
+  publisher = {Zenodo},
+  howpublished = {\url{https://https://zenodo.org/records/14775781}},
+}
+
+@inproceedings{tekiner2021sok,
+  title={SoK: cryptojacking malware},
+  author={Tekiner, Ege and Acar, Abbas and Uluagac, A Selcuk and Kirda, Engin and Selcuk, Ali Aydin},
+  booktitle={2021 IEEE European Symposium on Security and Privacy (EuroS\&P)},
+  pages={120--139},
+  year={2021},
+  organization={IEEE}
+}
+
+@inproceedings{bridges2018towards,
+  title={Towards malware detection via cpu power consumption: Data collection design and analytics},
+  author={Bridges, Robert and Jim{\'e}nez, Jarilyn Hern{\'a}ndez and Nichols, Jeffrey and Goseva-Popstojanova, Katerina and Prowell, Stacy},
+  booktitle={2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications/12th IEEE International Conference On Big Data Science And Engineering (TrustCom/BigDataSE)},
+  pages={1680--1684},
+  year={2018},
+  organization={IEEE}
+}
+
+@misc{chollet2015keras,
+  title={Keras},
+  author={Chollet, Fran\c{c}ois and others},
+  year={2015},
+  howpublished={\url{https://keras.io}},
+} 
+
+@article{eresheim2017evolution,
+  title={The evolution of process hiding techniques in malware-current threats and possible countermeasures},
+  author={Eresheim, Sebastian and Luh, Robert and Schrittwieser, Sebastian},
+  journal={Journal of Information Processing},
+  volume={25},
+  pages={866--874},
+  year={2017},
+  publisher={Information Processing Society of Japan}
+}
+
+@incollection{MCCUE20073,
+title = {1 - Basics},
+editor = {Colleen McCue},
+booktitle = {Data Mining and Predictive Analysis},
+publisher = {Butterworth-Heinemann},
+address = {Burlington},
+pages = {3-18},
+year = {2007},
+isbn = {978-0-7506-7796-7},
+doi = {https://doi.org/10.1016/B978-075067796-7/50023-4},
+url = {https://www.sciencedirect.com/science/article/pii/B9780750677967500234},
+author = {Colleen McCue}

procver/SnP/checklist

@@ -0,0 +1,13 @@
+All figures/tables/code are referenced in the text, all references have a capital letter, all have an unbreakable space between the name and the ref.
+
+All citations are properly formated. No weird spacing, all titles with the same case.
+
+All figures work in black and white.
+
+All captions are self sufficient and follow the same format.
+
+All acronyms uses and acronym manager package.
+
+There is no two heading without text between them.
+
+There is no more footnote review comments.

procver/SnP/images/ael_illustration.svg

@@ -0,0 +1,531 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   width="349.6778mm"
+   height="101.18298mm"
+   viewBox="0 0 349.6778 101.18298"
+   version="1.1"
+   id="svg1"
+   inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
+   sodipodi:docname="ael_illustration.svg"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg">
+  <sodipodi:namedview
+     id="namedview1"
+     pagecolor="#ffffff"
+     bordercolor="#eeeeee"
+     borderopacity="1"
+     inkscape:showpageshadow="0"
+     inkscape:pageopacity="0"
+     inkscape:pagecheckerboard="0"
+     inkscape:deskcolor="#505050"
+     inkscape:document-units="mm"
+     inkscape:zoom="0.72426347"
+     inkscape:cx="577.8284"
+     inkscape:cy="399.71642"
+     inkscape:window-width="1920"
+     inkscape:window-height="1022"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="layer1" />
+  <defs
+     id="defs1">
+    <inkscape:path-effect
+       effect="tiling"
+       id="path-effect41"
+       is_visible="true"
+       lpeversion="1.3.1"
+       unit="px"
+       seed="1;1"
+       lpesatellites=""
+       num_rows="1"
+       num_cols="26"
+       gapx="15"
+       gapy="0"
+       offset="0"
+       offset_type="false"
+       scale="0"
+       rotate="0"
+       mirrorrowsx="false"
+       mirrorrowsy="false"
+       mirrorcolsx="false"
+       mirrorcolsy="false"
+       mirrortrans="false"
+       shrink_interp="false"
+       split_items="false"
+       link_styles="false"
+       interpolate_scalex="false"
+       interpolate_scaley="true"
+       interpolate_rotatex="false"
+       interpolate_rotatey="true"
+       random_scale="false"
+       random_rotate="false"
+       random_gap_y="false"
+       random_gap_x="false"
+       transformorigin="" />
+    <marker
+       style="overflow:visible"
+       id="Triangle"
+       refX="0"
+       refY="0"
+       orient="auto-start-reverse"
+       inkscape:stockid="Triangle arrow"
+       markerWidth="1.5"
+       markerHeight="1.5"
+       viewBox="0 0 1 1"
+       inkscape:isstock="true"
+       inkscape:collect="always"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="scale(0.5)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path135" />
+    </marker>
+    <marker
+       style="overflow:visible"
+       id="marker19"
+       refX="0"
+       refY="0"
+       orient="auto-start-reverse"
+       inkscape:stockid="Wide arrow"
+       markerWidth="1"
+       markerHeight="1"
+       viewBox="0 0 1 1"
+       inkscape:isstock="true"
+       inkscape:collect="always"
+       preserveAspectRatio="xMidYMid">
+      <path
+         style="fill:none;stroke:context-stroke;stroke-width:1;stroke-linecap:butt"
+         d="M 3,-3 0,0 3,3"
+         transform="rotate(180,0.125,0)"
+         sodipodi:nodetypes="ccc"
+         id="path19" />
+    </marker>
+    <marker
+       style="overflow:visible"
+       id="ArrowWide"
+       refX="0"
+       refY="0"
+       orient="auto-start-reverse"
+       inkscape:stockid="Wide arrow"
+       markerWidth="1"
+       markerHeight="1"
+       viewBox="0 0 1 1"
+       inkscape:isstock="true"
+       inkscape:collect="always"
+       preserveAspectRatio="xMidYMid">
+      <path
+         style="fill:none;stroke:context-stroke;stroke-width:1;stroke-linecap:butt"
+         d="M 3,-3 0,0 3,3"
+         transform="rotate(180,0.125,0)"
+         sodipodi:nodetypes="ccc"
+         id="path18" />
+    </marker>
+    <inkscape:path-effect
+       effect="tiling"
+       id="path-effect5"
+       is_visible="true"
+       lpeversion="1.3.1"
+       unit="px"
+       seed="1;1"
+       lpesatellites=""
+       num_rows="1"
+       num_cols="56"
+       gapx="7"
+       gapy="0"
+       offset="0"
+       offset_type="false"
+       scale="0"
+       rotate="0"
+       mirrorrowsx="false"
+       mirrorrowsy="false"
+       mirrorcolsx="false"
+       mirrorcolsy="false"
+       mirrortrans="false"
+       shrink_interp="false"
+       split_items="false"
+       link_styles="false"
+       interpolate_scalex="false"
+       interpolate_scaley="true"
+       interpolate_rotatex="false"
+       interpolate_rotatey="true"
+       random_scale="false"
+       random_rotate="false"
+       random_gap_y="false"
+       random_gap_x="false"
+       transformorigin="" />
+  </defs>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(7.6715867,-14.612546)">
+    <path
+       style="fill:none;stroke:#999999;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:3.2, 0.4;stroke-dashoffset:0"
+       d="M 7.068815,78.882337 H 166.8519"
+       id="path7"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
+       d="M 7.068815,101.29964 V 43.116742"
+       id="path1"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
+       d="M 4.471481,99.074395 H 142.27195"
+       id="path2" />
+    <path
+       style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
+       d="M 217.6747,99.838389 V 41.462177"
+       id="path3"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;stroke:#808080;stroke-width:0.746001;stroke-linecap:butt;stroke-linejoin:round"
+       d="M 215.63951,98.094758 H 323.6155"
+       id="path4" />
+    <path
+       style="fill:none;stroke:#0000ff;stroke-width:0.4;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none"
+       d="m 10.200644,96.02498 2.363655,-0.329666 2.363654,0.659335 2.363655,-0.989 2.363655,-20.933804 h 2.363655 l 2.363654,1.379641 2.363656,-2.972144 2.363655,1.592503 2.363654,21.834975 2.363654,-0.466218 2.363656,0.466218 2.363655,-2.680757 2.363654,-0.524495 2.363656,-2.389369 2.363654,2.156259 2.363655,-0.699329 2.363655,3.788028 2.363655,0.116557 2.363654,-0.932438 2.363656,-42.77554 2.363654,25.292349 2.363655,-17.483193 2.363655,1.748322 2.363655,0.116556 2.363654,2.214536 2.363655,31.236634 2.363656,-0.582773 2.363654,0.815883 2.363654,-1.165545 2.363656,0.699328 2.363655,-0.815884 2.363654,-19.9701 h 2.363656 l 2.363654,2.603464 2.363655,-2.603464 2.363655,-1.417669 2.363655,1.417669 2.363657,20.727707 2.36365,-0.291389 2.36366,0.466221 2.36365,0.116557 2.36366,-1.223823 2.36366,-19.795268 h 2.36365 l 2.36366,20.669429 2.36365,-2.797311 2.36365,-0.990712 2.36366,2.097982 2.36365,-2.039705 2.36366,1.223823 2.36366,3.554913 2.36365,-0.874158 2.36365,-0.349665 2.36366,-1.282101 2.36365,0.990716"
+       id="path6" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 19.266465,49.616466 V 78.627094"
+       id="path8"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 29.591652,49.616466 V 78.627094"
+       id="path10"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 56.006298,49.616466 V 78.627094"
+       id="path11"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 70.401934,49.616466 V 78.627094"
+       id="path12"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 85.310839,49.616466 V 78.627094"
+       id="path13"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 98.163377,49.616466 V 78.627094"
+       id="path14"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 111.3064,49.616466 V 78.627094"
+       id="path15"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 114.7104,49.616466 V 78.627094"
+       id="path16"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#ff7f2a;fill-opacity:1;stroke:none;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="169.04597"
+       y="80.558311"
+       id="text16"><tspan
+         sodipodi:role="line"
+         id="tspan16"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#ff7f2a;fill-opacity:1;stroke:none;stroke-width:0.3"
+         x="169.04597"
+         y="80.558311">Threshold</tspan></text>
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
+       d="M 19.266465,47.020343 H 29.591652"
+       id="path17" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="23.057627"
+       y="44.432217"
+       id="text19"><tspan
+         sodipodi:role="line"
+         id="tspan19"
+         style="fill:#000000;stroke:none;stroke-width:0.200001"
+         x="23.057627"
+         y="44.432217">2</tspan></text>
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
+       d="M 56.189081,47.020343 H 70.140596"
+       id="path20"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="61.92915"
+       y="44.432217"
+       id="text20"><tspan
+         sodipodi:role="line"
+         id="tspan20"
+         style="fill:#000000;stroke:none;stroke-width:0.200001"
+         x="61.92915"
+         y="44.432217">3</tspan></text>
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
+       d="M 85.611791,47.020343 H 97.902403"
+       id="path21"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="88.875069"
+       y="44.432217"
+       id="text21"><tspan
+         sodipodi:role="line"
+         id="tspan21"
+         style="fill:#000000;stroke:none;stroke-width:0.200001"
+         x="88.875069"
+         y="44.432217">2.5</tspan></text>
+    <path
+       style="opacity:0.202361;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-start:url(#ArrowWide);marker-end:url(#marker19)"
+       d="m 111.31208,47.020343 h 3.2285"
+       id="path22"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="111.77805"
+       y="44.432217"
+       id="text22"><tspan
+         sodipodi:role="line"
+         id="tspan22"
+         style="fill:#000000;stroke:none;stroke-width:0.200001"
+         x="111.77805"
+         y="44.432217">1</tspan></text>
+    <circle
+       style="opacity:1;fill:none;stroke:#000000;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="path24"
+       cx="245.11917"
+       cy="58.49585"
+       r="1.6895757" />
+    <path
+       style="opacity:1;fill:none;stroke:#ff7f2a;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:1.5, 1.5;stroke-dashoffset:0"
+       d="m 245.11918,61.735318 v 38.16765"
+       id="path25"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:1;fill:none;stroke:#cc00ff;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:1.5, 1.5;stroke-dashoffset:0"
+       d="M 241.75858,58.495849 H 215.80855"
+       id="path26"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:3.60176px;line-height:4.47931px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="167.82986"
+       y="43.970543"
+       id="text26"><tspan
+         sodipodi:role="line"
+         id="tspan26"
+         style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
+         x="167.82986"
+         y="43.970543" /><tspan
+         sodipodi:role="line"
+         style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
+         x="167.82986"
+         y="48.449852"
+         id="tspan31">Avg</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
+         x="167.82986"
+         y="52.929165"
+         id="tspan27">Med</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
+         x="167.82986"
+         y="57.408474"
+         id="tspan28">Max</tspan><tspan
+         sodipodi:role="line"
+         style="font-size:3.60176px;line-height:4.47931px;fill:#000000;stroke:none;stroke-width:0.5;stroke-dasharray:none"
+         x="167.82986"
+         y="61.887783"
+         id="tspan30">Min</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15905px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#cc00ff;fill-opacity:1;stroke:none;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="161.71469"
+       y="43.362156"
+       id="text32"><tspan
+         sodipodi:role="line"
+         id="tspan32"
+         style="fill:#cc00ff;fill-opacity:1;stroke-width:0.5"
+         x="161.71469"
+         y="43.362156">Aggregation</tspan></text>
+    <path
+       style="opacity:1;fill:none;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       d="M 166.80902,45.051558 V 62.812326"
+       id="path32"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:5.85286px;line-height:7.27885px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="14.980807"
+       y="43.937721"
+       id="text33"><tspan
+         sodipodi:role="line"
+         id="tspan33"
+         style="font-size:5.85286px;line-height:7.27885px;fill:#000000;stroke:none;stroke-width:0.200001"
+         x="14.980807"
+         y="43.937721">(</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:5.85286px;line-height:7.27885px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;stroke:none;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="119.32017"
+       y="43.937721"
+       id="text34"><tspan
+         sodipodi:role="line"
+         id="tspan34"
+         style="font-size:5.85286px;line-height:7.27885px;fill:#000000;stroke:none;stroke-width:0.200001"
+         x="119.32017"
+         y="43.937721">)</tspan></text>
+    <path
+       style="opacity:1;fill:#000000;stroke:#000000;stroke-width:0.200001;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;marker-end:url(#Triangle)"
+       d="m 121.73002,42.360314 h 34.82826"
+       id="path34"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:1;fill:none;fill-opacity:1;stroke:#ff7f2a;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Triangle)"
+       d="m 181.8543,82.509725 c 2.51098,33.463385 54.00084,29.234555 60.57504,19.115365"
+       id="path35"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="opacity:1;fill:none;fill-opacity:1;stroke:#cc00ff;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#Triangle)"
+       d="m 189.70854,42.548398 c 11.5525,0.03719 13.34672,12.091892 24.4063,15.412535"
+       id="path36"
+       sodipodi:nodetypes="cc" />
+    <rect
+       style="opacity:1;fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect36"
+       width="146.98166"
+       height="75.686523"
+       x="2.0665262"
+       y="30.588257"
+       ry="3.1483846" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:6.98191px;line-height:8.68299px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       x="6.6319842"
+       y="28.727407"
+       id="text36"><tspan
+         sodipodi:role="line"
+         id="tspan36"
+         style="fill:#000000;stroke:none;stroke-width:0.2"
+         x="6.6319842"
+         y="28.727407">Residuals</tspan></text>
+    <rect
+       style="opacity:1;fill:none;fill-opacity:1;stroke:#000000;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect37"
+       width="116.75873"
+       height="75.686523"
+       x="210.78566"
+       y="30.588257"
+       ry="3.1483846" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:6.98191px;line-height:8.68299px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.2;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       x="213.54291"
+       y="28.727407"
+       id="text37"><tspan
+         sodipodi:role="line"
+         id="tspan37"
+         style="fill:#000000;stroke:none;stroke-width:0.2"
+         x="213.54291"
+         y="28.727407">Aggregated Error Length (AEL)</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#ff7f2a;fill-opacity:1;stroke:none;stroke-width:0.3;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       x="302.56812"
+       y="103.75573"
+       id="text38"><tspan
+         sodipodi:role="line"
+         id="tspan38"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:4.95243px;line-height:6.15903px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.3"
+         x="302.56812"
+         y="103.75573">Threshold</tspan></text>
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle42"
+       cx="237.18169"
+       cy="53.112087"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle43"
+       cx="229.24419"
+       cy="50.4179"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle44"
+       cx="221.30669"
+       cy="44.070576"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle45"
+       cx="253.05669"
+       cy="67.689087"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle46"
+       cx="260.99417"
+       cy="77.246773"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle47"
+       cx="268.93167"
+       cy="83.91375"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle48"
+       cx="276.86917"
+       cy="87.658218"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle49"
+       cx="284.80667"
+       cy="88.023529"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle50"
+       cx="292.74417"
+       cy="88.754158"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle51"
+       cx="300.68167"
+       cy="91.448349"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle52"
+       cx="308.61917"
+       cy="91.494011"
+       r="1.6895757" />
+    <circle
+       style="opacity:1;fill:none;stroke:#b3b3b3;stroke-width:0.499999;stroke-linecap:butt;stroke-linejoin:round;stroke-dasharray:none;stroke-dashoffset:0"
+       id="circle53"
+       cx="316.55667"
+       cy="91.631004"
+       r="1.6895757" />
+  </g>
+</svg>

procver/SnP/images/related_work.svg

@@ -0,0 +1,592 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   width="792.42957mm"
+   height="259.8837mm"
+   viewBox="0 0 792.42956 259.88371"
+   version="1.1"
+   id="svg5"
+   inkscape:version="1.4.1 (93de688d07, 2025-03-30)"
+   xml:space="preserve"
+   sodipodi:docname="related_work.svg"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:xlink="http://www.w3.org/1999/xlink"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg"><sodipodi:namedview
+     id="namedview7"
+     pagecolor="#ffffff"
+     bordercolor="#000000"
+     borderopacity="1"
+     inkscape:showpageshadow="0"
+     inkscape:pageopacity="0"
+     inkscape:pagecheckerboard="0"
+     inkscape:deskcolor="#b5b5b5"
+     inkscape:document-units="mm"
+     showgrid="false"
+     inkscape:zoom="2.7891246"
+     inkscape:cx="1683.6824"
+     inkscape:cy="281.98812"
+     inkscape:window-width="1920"
+     inkscape:window-height="1022"
+     inkscape:window-x="0"
+     inkscape:window-y="0"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="layer1"><inkscape:page
+       x="0"
+       y="0"
+       width="792.42957"
+       height="259.8837"
+       id="page1"
+       margin="0"
+       bleed="0" /></sodipodi:namedview><defs
+     id="defs2"><marker
+       style="overflow:visible"
+       id="Dot"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Dot"
+       markerWidth="1"
+       markerHeight="1"
+       viewBox="0 0 1 1"
+       inkscape:isstock="true"
+       inkscape:collect="always"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(0.5)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:none"
+         d="M 5,0 C 5,2.76 2.76,5 0,5 -2.76,5 -5,2.76 -5,0 c 0,-2.76 2.3,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         sodipodi:nodetypes="sssss"
+         id="path17" /></marker><marker
+       style="overflow:visible"
+       id="Triangle"
+       refX="0"
+       refY="0"
+       orient="auto-start-reverse"
+       inkscape:stockid="Triangle arrow"
+       markerWidth="1"
+       markerHeight="1"
+       viewBox="0 0 1 1"
+       inkscape:isstock="true"
+       inkscape:collect="always"
+       preserveAspectRatio="xMidYMid"><path
+         transform="scale(0.5)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:context-stroke;stroke-width:1pt"
+         d="M 5.77,0 -2.88,5 V -5 Z"
+         id="path135" /></marker></defs><g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(224.10697,45.791336)"><circle
+       style="fill:#e6e6e6;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none"
+       id="path87"
+       cx="-328.62012"
+       cy="299.08551"
+       r="59.431034"
+       transform="rotate(-135)" /><circle
+       style="fill:#999999;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none"
+       id="path78"
+       cx="-336.25137"
+       cy="291.13647"
+       r="42.21381"
+       transform="rotate(-135)" /><path
+       style="fill:none;stroke:#000000;stroke-width:1;stroke-linecap:butt;stroke-linejoin:miter;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Triangle)"
+       d="M -215.89073,87.23208 H 286.59341"
+       id="path1"
+       sodipodi:nodetypes="cc" /><text
+       xml:space="preserve"
+       style="font-size:3.88056px;line-height:1.25;font-family:'Monaspace Neon Var';-inkscape-font-specification:'Monaspace Neon Var';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
+       x="327.862"
+       y="71.679672"
+       id="text36"><tspan
+         sodipodi:role="line"
+         style="stroke-width:0.264583"
+         x="327.862"
+         y="71.679672"
+         id="tspan37" /></text><path
+       id="path3"
+       style="color:#000000;fill:#000000;-inkscape-stroke:none"
+       d="m -147.72485,67.47964 v 15.777332 c -1.83131,0.128657 -3.28145,1.657668 -3.28145,3.521228 0,1.94765 1.5834,3.53157 3.53105,3.53157 1.94765,0 3.53156,-1.58392 3.53156,-3.53157 0,-1.86356 -1.45014,-3.392571 -3.28145,-3.521228 V 67.47964 Z m 0.2496,16.267224 c 1.67743,0 3.03134,1.353906 3.03134,3.031336 0,1.67743 -1.35391,3.03134 -3.03134,3.03134 -1.67743,0 -3.03082,-1.35391 -3.03082,-3.03134 0,-1.67743 1.35339,-3.031336 3.03082,-3.031336 z" /><text
+       xml:space="preserve"
+       style="font-size:3.88056px;line-height:1.25;font-family:'Monaspace Neon Var';-inkscape-font-specification:'Monaspace Neon Var';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
+       x="-151.82608"
+       y="66.915802"
+       id="text50"><tspan
+         id="tspan50"
+         style="stroke-width:0.264583"
+         x="-151.82608"
+         y="66.915802"
+         sodipodi:role="line">1969</tspan></text><rect
+       style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect50"
+       width="56.265244"
+       height="25.585007"
+       x="-173.95004"
+       y="37.277485"
+       ry="1.3401735" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
+       x="190.02438"
+       y="196.82707"
+       id="text81"
+       transform="translate(-362.699,-146.55585)"><tspan
+         x="190.02438"
+         y="196.82707"
+         id="tspan44">Invented the term &quot;Covert Channel&quot;.
+</tspan><tspan
+         x="190.02438"
+         y="199.47292"
+         id="tspan45">This is though of in the case of programms </tspan><tspan
+         x="190.02438"
+         y="202.11876"
+         id="tspan46">communicating on the same machine. It is the early days </tspan><tspan
+         x="190.02438"
+         y="204.7646"
+         id="tspan47">of the idea of covert channels in computer science.</tspan></text><rect
+       style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect81"
+       width="56.26524"
+       height="10.447671"
+       x="-173.95004"
+       y="37.277485"
+       ry="1.3401735" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:88.3485;display:inline;stroke-width:0.264583"
+       x="320.76639"
+       y="166.06209"
+       id="text82"
+       transform="matrix(0.72076737,0,0,0.72076737,-402.47872,-76.749177)"><tspan
+         x="320.76639"
+         y="166.06209"
+         id="tspan48">A note on the confinement problem</tspan></text><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:16.9333px;line-height:21.059px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';text-align:center;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:middle;fill:#000000;stroke:none;stroke-width:0.746001;stroke-linecap:round;stroke-linejoin:round"
+       x="-184.64418"
+       y="-28.716087"
+       id="text83"><tspan
+         sodipodi:role="line"
+         id="tspan83"
+         style="stroke:none;stroke-width:0.746"
+         x="-184.64418"
+         y="-28.716087">General</tspan></text><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:16.9333px;line-height:21.059px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:0.746001;stroke-linecap:round;stroke-linejoin:round"
+       x="-220.59908"
+       y="210.33742"
+       id="text84"><tspan
+         sodipodi:role="line"
+         id="tspan84"
+         style="text-align:start;text-anchor:start;stroke:none;stroke-width:0.746"
+         x="-220.59908"
+         y="210.33742">Specific</tspan></text><path
+       id="path84"
+       style="color:#000000;fill:#000000;-inkscape-stroke:none"
+       d="M 202.50751,106.54263 V 90.76529 c -1.83131,-0.12865 -3.28145,-1.65766 -3.28145,-3.52122 0,-1.94765 1.5834,-3.531573 3.53105,-3.531573 1.94765,0 3.53156,1.583923 3.53156,3.531573 0,1.86356 -1.45014,3.39257 -3.28145,3.52122 v 15.77734 z m 0.2496,-16.26723 c 1.67743,0 3.03134,-1.3539 3.03134,-3.03133 0,-1.67743 -1.35391,-3.031343 -3.03134,-3.031343 -1.67743,0 -3.03082,1.353913 -3.03082,3.031343 0,1.67743 1.35339,3.03133 3.03082,3.03133 z" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
+       x="198.40628"
+       y="110.24815"
+       id="text85"><tspan
+         id="tspan85"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';stroke-width:0.264583"
+         x="198.40628"
+         y="110.24815"
+         sodipodi:role="line">2008</tspan></text><rect
+       style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect85"
+       width="56.265244"
+       height="90.850403"
+       x="176.28232"
+       y="111.3315"
+       ry="1.3401735" /><rect
+       style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect90"
+       width="59.49057"
+       height="11.870605"
+       x="174.66965"
+       y="111.3315"
+       ry="1.3401735" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
+       x="320.76639"
+       y="166.06209"
+       id="text91"
+       transform="matrix(0.72076737,0,0,0.72076737,-54.807652,-4.4026833)"><tspan
+         x="320.76639"
+         y="166.06209"
+         id="tspan49">Implicit Detection of Hidden Processes </tspan><tspan
+         x="320.76639"
+         y="170.91278"
+         id="tspan51">with aFeather-Weight Hardware-Assisted </tspan><tspan
+         x="320.76639"
+         y="175.76347"
+         id="tspan52">Virtual Machine Monitor</tspan></text><path
+       id="path93"
+       style="color:#000000;fill:#000000;-inkscape-stroke:none"
+       d="M -6.7755952,106.54263 V 90.76529 c -1.83131,-0.12865 -3.2814498,-1.65766 -3.2814498,-3.52122 0,-1.94765 1.5833998,-3.531573 3.5310498,-3.531573 1.94765,0 3.53156,1.583923 3.53156,3.531573 0,1.86356 -1.45014,3.39257 -3.28145,3.52122 v 15.77734 z m 0.2496,-16.26723 c 1.67743,0 3.03134,-1.3539 3.03134,-3.03133 0,-1.67743 -1.35391,-3.031343 -3.03134,-3.031343 -1.67743,0 -3.03082,1.353913 -3.03082,3.031343 0,1.67743 1.35339,3.03133 3.03082,3.03133 z" /><text
+       xml:space="preserve"
+       style="font-size:3.88056px;line-height:1.25;font-family:'Monaspace Neon Var';-inkscape-font-specification:'Monaspace Neon Var';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
+       x="-10.876826"
+       y="110.24815"
+       id="text94"><tspan
+         id="tspan94"
+         style="stroke-width:0.264583"
+         x="-10.876826"
+         y="110.24815"
+         sodipodi:role="line">1969</tspan></text><rect
+       style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect94"
+       width="56.265244"
+       height="25.585007"
+       x="-33.00079"
+       y="111.3315"
+       ry="1.3401735" /><rect
+       style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect95"
+       width="56.265244"
+       height="11.870608"
+       x="-33.00079"
+       y="111.3315"
+       ry="1.3401735" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
+       x="320.76639"
+       y="166.06209"
+       id="text97"
+       transform="matrix(0.72076737,0,0,0.72076737,-262.9524,-4.4026833)"><tspan
+         x="320.76639"
+         y="166.06209"
+         id="tspan53">Microsoft / Kaspersky Reports on </tspan><tspan
+         x="320.76639"
+         y="170.91278"
+         id="tspan54">rootkits</tspan></text><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
+       x="190.02438"
+       y="196.82707"
+       id="text101"
+       transform="translate(-12.552264,-70.087023)"><tspan
+         x="190.02438"
+         y="196.82707"
+         id="tspan55">- Their solution affect the performance. Yes it is only </tspan><tspan
+         x="190.02438"
+         y="199.47292"
+         id="tspan56">~5% but it is still a performance loss. Our solution </tspan><tspan
+         x="190.02438"
+         y="202.11876"
+         id="tspan57">cannot affect the performance because the data </tspan><tspan
+         x="190.02438"
+         y="204.7646"
+         id="tspan58">collection and analysis is separated.
+</tspan><tspan
+         x="190.02438"
+         y="207.41045"
+         id="tspan59">- They claim to support &quot;Dynamic OS migration&quot; which </tspan><tspan
+         x="190.02438"
+         y="210.05629"
+         id="tspan60">means the solution can be applied to an existing </tspan><tspan
+         x="190.02438"
+         y="212.70213"
+         id="tspan61">running VM without restarting/recreating it. We also </tspan><tspan
+         x="190.02438"
+         y="215.34798"
+         id="tspan62">have that and it seems like a desirable property so </tspan><tspan
+         x="190.02438"
+         y="217.99382"
+         id="tspan63">let's mention it.
+</tspan><tspan
+         x="190.02438"
+         y="220.63967"
+         id="tspan64">- They provide &quot;non-bypassable interfaces&quot; as a way for </tspan><tspan
+         x="190.02438"
+         y="223.28551"
+         id="tspan65">the OS to communicate with the monitoring system and </tspan><tspan
+         x="190.02438"
+         y="225.93135"
+         id="tspan66">retrieve the True Process List. They apparently use </tspan><tspan
+         x="190.02438"
+         y="228.5772"
+         id="tspan67">very low level mechanisms specific to Intel processor </tspan><tspan
+         x="190.02438"
+         y="231.22304"
+         id="tspan68">to establish this communication but I am not sure what </tspan><tspan
+         x="190.02438"
+         y="233.86888"
+         id="tspan69">makes them completely &quot;non-bypassable&quot;.
+</tspan><tspan
+         x="190.02438"
+         y="236.51473"
+         id="tspan70">- They have a more comprehensive evaluation of the </tspan><tspan
+         x="190.02438"
+         y="239.16057"
+         id="tspan71">detection performances compared with other softwares. </tspan><tspan
+         x="190.02438"
+         y="241.80641"
+         id="tspan73">However the same comparison would be unfaire to ProcVer </tspan><tspan
+         x="190.02438"
+         y="244.45226"
+         id="tspan74">because its achievement lies in the fact that it is </tspan><tspan
+         x="190.02438"
+         y="247.0981"
+         id="tspan75">completely remote from the OS and the fact that it </tspan><tspan
+         x="190.02438"
+         y="249.74394"
+         id="tspan82">should work the same on known malwares and zero-days </tspan><tspan
+         x="190.02438"
+         y="252.38979"
+         id="tspan86">attacks. Moreover, it is an additional layer of </tspan><tspan
+         x="190.02438"
+         y="255.03563"
+         id="tspan87">defense, not a silver bullet.
+</tspan><tspan
+         x="190.02438"
+         y="257.68147"
+         id="tspan88">- Their solution is very hardware specific in the sense </tspan><tspan
+         x="190.02438"
+         y="260.3273"
+         id="tspan89">that it is designed for a processor model/family/</tspan><tspan
+         x="190.02438"
+         y="262.97315"
+         id="tspan90">manufacturer and would require significant rework to be </tspan><tspan
+         x="190.02438"
+         y="265.61899"
+         id="tspan91">ported to another hardware. Our solution is hardware </tspan><tspan
+         x="190.02438"
+         y="268.26483"
+         id="tspan92">specific for training but hardware agnostic in its </tspan><tspan
+         x="190.02438"
+         y="270.91068"
+         id="tspan93">design and capabilities.</tspan></text><path
+       id="path101"
+       style="color:#000000;fill:#000000;-inkscape-stroke:none"
+       d="M 136.23453,106.54263 V 90.76529 c -1.83131,-0.12865 -3.28145,-1.65766 -3.28145,-3.52122 0,-1.94765 1.5834,-3.531573 3.53105,-3.531573 1.94765,0 3.53156,1.583923 3.53156,3.531573 0,1.86356 -1.45014,3.39257 -3.28145,3.52122 v 15.77734 z m 0.2496,-16.26723 c 1.67743,0 3.03134,-1.3539 3.03134,-3.03133 0,-1.67743 -1.35391,-3.031343 -3.03134,-3.031343 -1.67743,0 -3.03082,1.353913 -3.03082,3.031343 0,1.67743 1.35339,3.03133 3.03082,3.03133 z" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
+       x="132.1333"
+       y="110.24815"
+       id="text102"><tspan
+         id="tspan101"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';stroke-width:0.264583"
+         x="132.1333"
+         y="110.24815"
+         sodipodi:role="line">2005</tspan></text><rect
+       style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect102"
+       width="56.667709"
+       height="41.683708"
+       x="110.00934"
+       y="111.3315"
+       ry="1.3401735" /><rect
+       style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect103"
+       width="59.49057"
+       height="11.870605"
+       x="108.39667"
+       y="111.3315"
+       ry="1.3401735" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
+       x="320.76639"
+       y="166.06209"
+       id="text105"
+       transform="matrix(0.72076737,0,0,0.72076737,-121.08064,-4.4026833)"><tspan
+         x="320.76639"
+         y="166.06209"
+         id="tspan95">Detecting Stealth Software with </tspan><tspan
+         x="320.76639"
+         y="170.91278"
+         id="tspan96">Strider GhostBuster</tspan></text><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
+       x="190.02438"
+       y="196.82707"
+       id="text106"
+       transform="translate(-78.825247,-54.909023)" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
+       x="190.02438"
+       y="196.82707"
+       id="text72"
+       transform="translate(-79.14574,-70.087023)"><tspan
+         x="190.02438"
+         y="196.82707"
+         id="tspan97">- Their solution relies on the comparison of two </tspan><tspan
+         x="190.02438"
+         y="199.47292"
+         id="tspan98">snapshot made at the same time using two different </tspan><tspan
+         x="190.02438"
+         y="202.11876"
+         id="tspan99">mechanism, assuming one goes through the hidden malware </tspan><tspan
+         x="190.02438"
+         y="204.7646"
+         id="tspan100">and one does not. The method is called cross-view diff.
+</tspan><tspan
+         x="190.02438"
+         y="207.41045"
+         id="tspan102">- In a sense, there is a parallel to be drawn between </tspan><tspan
+         x="190.02438"
+         y="210.05629"
+         id="tspan103">their approach an mine. I also doo a cross-view diff of </tspan><tspan
+         x="190.02438"
+         y="212.70213"
+         id="tspan104">the state ofthe machine but one of my view is the power </tspan><tspan
+         x="190.02438"
+         y="215.34798"
+         id="tspan105">and the other one is the process list.
+</tspan><tspan
+         x="190.02438"
+         y="217.99382"
+         id="tspan106">- Our method only exposes CPU-consuming malware. The </tspan><tspan
+         x="190.02438"
+         y="220.63967"
+         id="tspan107">file-hiding malware are invisible to us.</tspan></text><path
+       id="path72"
+       style="color:#000000;fill:#000000;-inkscape-stroke:none"
+       d="m 185.43665,67.933517 v 15.77734 c -1.83131,0.12865 -3.28145,1.657663 -3.28145,3.521223 0,1.94765 1.5834,3.53157 3.53105,3.53157 1.94765,0 3.53156,-1.58392 3.53156,-3.53157 0,-1.86356 -1.45014,-3.392573 -3.28145,-3.521223 v -15.77734 z m 0.2496,16.26723 c 1.67743,0 3.03134,1.353903 3.03134,3.031333 0,1.67743 -1.35391,3.03134 -3.03134,3.03134 -1.67743,0 -3.03082,-1.35391 -3.03082,-3.03134 0,-1.67743 1.35339,-3.031333 3.03082,-3.031333 z" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;stroke-width:0.264583"
+       x="181.33542"
+       y="67.18058"
+       id="text73"><tspan
+         id="tspan72"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';stroke-width:0.264583"
+         x="181.33542"
+         y="67.18058"
+         sodipodi:role="line">2005</tspan></text><rect
+       style="fill:#cccccc;fill-opacity:1;stroke:#1a1a1a;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect73"
+       width="56.667709"
+       height="41.683708"
+       x="159.21146"
+       y="20.624043"
+       ry="1.3401735" /><rect
+       style="fill:#ffc6a0;fill-opacity:1;stroke:#ff6803;stroke-width:0.577775;stroke-dasharray:none;stroke-opacity:1"
+       id="rect74"
+       width="59.49057"
+       height="15.626968"
+       x="157.59879"
+       y="16.86768"
+       ry="1.3401735" /><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:bold;font-stretch:normal;font-size:3.88056px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono Bold';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:78.7407;display:inline;stroke-width:0.264583"
+       x="320.76639"
+       y="166.06209"
+       id="text75"
+       transform="matrix(0.72076737,0,0,0.72076737,-71.878518,-99.356979)"><tspan
+         x="320.76639"
+         y="166.06209"
+         id="tspan108">Stealthy Malware Detection Through </tspan><tspan
+         x="320.76639"
+         y="170.91278"
+         id="tspan109">VMM-BasedS“Out-of-the-Box” Semantic </tspan><tspan
+         x="320.76639"
+         y="175.76347"
+         id="tspan110">View Reconstructiontealthy Malware </tspan><tspan
+         x="320.76639"
+         y="180.61416"
+         id="tspan111">Detection Through VMM-Based</tspan></text><text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:2.11667px;line-height:1.25;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';letter-spacing:-0.291042px;word-spacing:0px;white-space:pre;inline-size:54.6704;display:inline;stroke-width:0.264583"
+       x="190.02438"
+       y="196.82707"
+       id="text76"
+       transform="translate(-29.943618,-160.79447)"><tspan
+         x="190.02438"
+         y="196.82707"
+         id="tspan112">Important paper in the field. Lots of citation.
+</tspan><tspan
+         x="190.02438"
+         y="199.47292"
+         id="tspan113">
+</tspan><tspan
+         x="190.02438"
+         y="202.11876"
+         id="tspan114">- They claim to have a method that is &quot;Out-of-the-Box&quot; </tspan><tspan
+         x="190.02438"
+         y="204.7646"
+         id="tspan115">opposit to the host-based methods. This follows the </tspan><tspan
+         x="190.02438"
+         y="207.41045"
+         id="tspan116">same idea that we have for independance but we take it </tspan><tspan
+         x="190.02438"
+         y="210.05629"
+         id="tspan117">one step further, making it &quot;out-of-the-case/rack&quot; for </tspan><tspan
+         x="190.02438"
+         y="212.70213"
+         id="tspan118">complete and undeniable independence. Their method only </tspan><tspan
+         x="190.02438"
+         y="215.34798"
+         id="tspan119">work on VM because there is a place between the VM and </tspan><tspan
+         x="190.02438"
+         y="217.99382"
+         id="tspan120">the hardware to install their detector. Our method is </tspan><tspan
+         x="190.02438"
+         y="220.63967"
+         id="tspan121">applicable to any hardware.</tspan></text><circle
+       style="fill:#cccccc;fill-opacity:1;stroke:#000000;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none"
+       id="path76"
+       cx="-404.80991"
+       cy="185.1604"
+       r="22.767"
+       transform="rotate(-150)" /><text
+       xml:space="preserve"
+       style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
+       id="text77"
+       transform="translate(-1.4757142,-1.8781817)"><textPath
+         xlink:href="#path76"
+         id="textPath86"><tspan
+           id="tspan77"
+           style="fill:#000000;stroke:none;stroke-width:2.1">Target OS</tspan></textPath></text><text
+       xml:space="preserve"
+       style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
+       x="424.49768"
+       y="43.393692"
+       id="text78"><tspan
+         sodipodi:role="line"
+         id="tspan78"
+         style="fill:#000000;stroke:none;stroke-width:2.1"
+         x="424.49768"
+         y="43.393692">Host-Based IDS</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
+       id="text79"
+       transform="translate(-2.0123375,-1.2074025)"><textPath
+         xlink:href="#path78"
+         id="textPath87"><tspan
+           id="tspan79"
+           style="fill:#000000;stroke:none;stroke-width:2.1">Hardware</tspan></textPath></text><text
+       xml:space="preserve"
+       style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
+       x="430.40054"
+       y="4.8795161"
+       id="text80"><tspan
+         sodipodi:role="line"
+         id="tspan80"
+         style="fill:#000000;stroke:none;stroke-width:2.1"
+         x="430.40054"
+         y="4.8795161">VM Monitors</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
+       x="421.81458"
+       y="-23.579235"
+       id="text86"><tspan
+         sodipodi:role="line"
+         id="tspan81"
+         style="fill:#000000;stroke:none;stroke-width:2.1"
+         x="421.81458"
+         y="-23.579235">Physics-Based IDS</tspan></text><text
+       xml:space="preserve"
+       style="font-size:4.5861px;line-height:5.70346px;font-family:'Adwaita Mono';-inkscape-font-specification:'Adwaita Mono';text-align:start;letter-spacing:0px;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#000000;stroke:none;stroke-width:2.1;stroke-linejoin:round"
+       id="text88"
+       transform="translate(-1.8877159,-1.615455)"><textPath
+         xlink:href="#path87"
+         id="textPath88">Server Room</textPath></text><path
+       style="fill:none;fill-opacity:1;stroke:#ffb37e;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Dot)"
+       d="M 427.02924,4.6755133 C 361.20707,11.587768 304.15054,22.636116 216.62419,24.122327"
+       id="path88"
+       sodipodi:nodetypes="cc" /><path
+       style="fill:none;fill-opacity:1;stroke:#ffb37e;stroke-width:1;stroke-linejoin:round;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Dot)"
+       d="M 420.38886,13.497726 C 378.0926,35.018806 321.13093,116.07567 233.60458,117.56189"
+       id="path89"
+       sodipodi:nodetypes="cc" /></g></svg>

procver/SnP/main.tex

@@ -0,0 +1,851 @@
+%% bare_conf_compsoc.tex
+%% V1.4b
+%% 2015/08/26
+%% by Michael Shell
+%% See:
+%% http://www.michaelshell.org/
+%% for current contact information.
+%%
+%% This is a skeleton file demonstrating the use of IEEEtran.cls
+%% (requires IEEEtran.cls version 1.8b or later) with an IEEE Computer
+%% Society conference paper.
+%%
+%% Support sites:
+%% http://www.michaelshell.org/tex/ieeetran/
+%% http://www.ctan.org/pkg/ieeetran
+%% and
+%% http://www.ieee.org/
+
+%%*************************************************************************
+%% Legal Notice:
+%% This code is offered as-is without any warranty either expressed or
+%% implied; without even the implied warranty of MERCHANTABILITY or
+%% FITNESS FOR A PARTICULAR PURPOSE! 
+%% User assumes all risk.
+%% In no event shall the IEEE or any contributor to this code be liable for
+%% any damages or losses, including, but not limited to, incidental,
+%% consequential, or any other damages, resulting from the use or misuse
+%% of any information contained here.
+%%
+%% All comments are the opinions of their respective authors and are not
+%% necessarily endorsed by the IEEE.
+%%
+%% This work is distributed under the LaTeX Project Public License (LPPL)
+%% ( http://www.latex-project.org/ ) version 1.3, and may be freely used,
+%% distributed and modified. A copy of the LPPL, version 1.3, is included
+%% in the base LaTeX documentation of all distributions of LaTeX released
+%% 2003/12/01 or later.
+%% Retain all contribution notices and credits.
+%% ** Modified files should be clearly indicated as such, including  **
+%% ** renaming them and changing author support contact information. **
+%%*************************************************************************
+
+
+% *** Authors should verify (and, if needed, correct) their LaTeX system  ***
+% *** with the testflow diagnostic prior to trusting their LaTeX platform ***
+% *** with production work. The IEEE's font choices and paper sizes can   ***
+% *** trigger bugs that do not appear when using other class files.       ***                          ***
+% The testflow support page is at:
+% http://www.michaelshell.org/tex/testflow/
+
+
+
+\documentclass[conference,compsoc]{IEEEtran}
+% Some/most Computer Society conferences require the compsoc mode option,
+% but others may want the standard conference format.
+%
+% If IEEEtran.cls has not been installed into the LaTeX system files,
+% manually specify the path to it like:
+% \documentclass[conference,compsoc]{../sty/IEEEtran}
+
+
+
+
+
+% Some very useful LaTeX packages include:
+% (uncomment the ones you want to load)
+
+
+% *** MISC UTILITY PACKAGES ***
+%
+%\usepackage{ifpdf}
+% Heiko Oberdiek's ifpdf.sty is very useful if you need conditional
+% compilation based on whether the output is pdf or dvi.
+% usage:
+% \ifpdf
+%   % pdf code
+% \else
+%   % dvi code
+% \fi
+% The latest version of ifpdf.sty can be obtained from:
+% http://www.ctan.org/pkg/ifpdf
+% Also, note that IEEEtran.cls V1.7 and later provides a builtin
+% \ifCLASSINFOpdf conditional that works the same way.
+% When switching from latex to pdflatex and vice-versa, the compiler may
+% have to be run twice to clear warning/error messages.
+
+
+\usepackage{graphicx}
+\usepackage{xcolor}
+\usepackage{amsfonts}
+\usepackage{amssymb}
+\usepackage{acro}
+\usepackage{booktabs}
+\usepackage{url}
+\usepackage{algorithm}
+\usepackage{algpseudocode}
+
+
+\input{acronyms}
+
+
+
+% *** CITATION PACKAGES ***
+%
+\ifCLASSOPTIONcompsoc
+  % IEEE Computer Society needs nocompress option
+  % requires cite.sty v4.0 or later (November 2003)
+  \usepackage[nocompress]{cite}
+\else
+  % normal IEEE
+  \usepackage{cite}
+\fi
+
+
+% correct bad hyphenation here
+\hyphenation{op-tical net-works semi-conduc-tor}
+
+\input{utils}
+
+
+\begin{document}
+%
+% paper title
+% Titles are generally capitalized except for words such as a, an, and, as,
+% at, but, by, for, in, nor, of, on, or, the, to and up, which are usually
+% not capitalized unless they are the first or last word of the title.
+% Linebreaks \\ can be used within to get better formatting as desired.
+% Do not put math or special symbols in the title.
+\title{Electron Accounting: Hidden Process Detection through Power Consumption Prediction}
+
+
+% author names and affiliations
+% use a multiple column layout for up to three different
+% affiliations
+% \author{
+%     \IEEEauthorblockN{Arthur Grisel-Davy}
+%     \IEEEauthorblockA{Electrical and\\Computer Engineering\\
+%     University of Waterloo\\
+%     Ontario, CA\\
+%     agriseld@uwaterlo.ca}
+%     \and
+%     \IEEEauthorblockN{Mahesh Tripunitara}
+%     \IEEEauthorblockA{Electrical and\\Computer Engineering\\
+%     University of Waterloo\\
+%      Ontario, CA\\
+%     tripunit@uwaterloo.ca}
+%     \and
+%     \IEEEauthorblockN{Sebastian Fischmeister}
+%     \IEEEauthorblockA{Electrical and\\Computer Engineering\\
+%     University of Waterloo\\
+%     Ontario, CA\\
+%     sfischme@uwaterloo.ca}
+% }
+
+\author{
+    \IEEEauthorblockN{Anonymous}
+    \IEEEauthorblockA{None\\
+    None\\
+    None\\
+    none@example.com}
+    \and
+    \IEEEauthorblockN{Anonymous}
+    \IEEEauthorblockA{None\\
+    None\\
+    None\\
+    none@example.com}
+    \and
+    \IEEEauthorblockN{Anonymous}
+    \IEEEauthorblockA{None\\
+    None\\
+    None\\
+    none@example.com}
+}
+
+% conference papers do not typically use \thanks and this command
+% is locked out in conference mode. If really needed, such as for
+% the acknowledgment of grants, issue a \IEEEoverridecommandlockouts
+% after \documentclass
+
+% for over three affiliations, or if they all won't fit within the width
+% of the page (and note that there is less available width in this regard for
+% compsoc conferences compared to traditional conferences), use this
+% alternative format:
+% 
+%\author{\IEEEauthorblockN{Michael Shell\IEEEauthorrefmark{1},
+%Homer Simpson\IEEEauthorrefmark{2},
+%James Kirk\IEEEauthorrefmark{3}, 
+%Montgomery Scott\IEEEauthorrefmark{3} and
+%Eldon Tyrell\IEEEauthorrefmark{4}}
+%\IEEEauthorblockA{\IEEEauthorrefmark{1}School of Electrical and Computer Engineering\\
+%Georgia Institute of Technology,
+%Atlanta, Georgia 30332--0250\\ Email: see http://www.michaelshell.org/contact.html}
+%\IEEEauthorblockA{\IEEEauthorrefmark{2}Twentieth Century Fox, Springfield, USA\\
+%Email: homer@thesimpsons.com}
+%\IEEEauthorblockA{\IEEEauthorrefmark{3}Starfleet Academy, San Francisco, California 96678-2391\\
+%Telephone: (800) 555--1212, Fax: (888) 555--1212}
+%\IEEEauthorblockA{\IEEEauthorrefmark{4}Tyrell Inc., 123 Replicant Street, Los Angeles, California 90210--4321}}
+
+
+
+
+% use for special paper notices
+%\IEEEspecialpapernotice{(Invited Paper)}
+
+
+
+
+% make the title area
+\maketitle
+
+% As a general rule, do not put math, special symbols or citations
+% in the abstract
+\begin{abstract}
+One important source of information for detecting malware on a machine is the list of processes.
+By analyzing this list, an Intrusion Detection System (IDS) can detect known malware, mine and verify security rules, or confirm the presence and activity of expected key processes.
+For this reason, tampering with the process list is a common evasion technique for malware that aims to remain hidden on the machine.
+The tampering can involve removing processes associated with malicious activities or injecting expected processes that have been stopped.
+
+We propose a new approach to verify the integrity of the process list --- before its use by traditional IDS --- using \ac{sci}.
+The proposed approach uses the process list to predict the power consumption of the Central Processing Unit (CPU).
+If the prediction matches the ground truth consumption measured externally, then the process list is trusted.
+Otherwise, the discrepancy is evidence of modifications to the list.
+
+We evaluate the potential of this approach on 388 CPU activity traces of real-world virtual machines gathered from a public dataset and replayed on local machines to collect the necessary information.
+We also evaluate the sensitivity of the approach in terms of the energy consumption of malware to determine the range of detection.
+The results validate the potential of the proposed approach as a complementary validation system for detecting process list tampering.
+
+\end{abstract}
+
+% no keywords
+
+
+
+
+% For peer review papers, you can put extra information on the cover
+% page as needed:
+% \ifCLASSOPTIONpeerreview
+% \begin{center} \bfseries EDICS Category: 3-BBND \end{center}
+% \fi
+%
+% For peerreview papers, this IEEEtran command inserts a page break and
+% creates the second title. It will be ignored for other modes.
+\IEEEpeerreviewmaketitle
+
+
+
+\section{Introduction}
+% no \IEEEPARstart
+Malware development has always been a field of computer science that rivals in complexity with the most current academic research.
+To remain effective, malware must keep pace with, and even outpace, the most advanced detection and prevention mechanisms.
+This complexity has kept modern malware capable of infiltrate and disrupt systems while avoiding detection.
+
+While stealth may not be the main focus of all malware --- some are designed for destructive power or speed of deployment and action ---, the ability to remain hidden on the infected system --- called evasion --- is a common feature of many modern malware.
+Because of the creativity of malware authors, many evasion techniques have been used over time.
+While most were discovered and documented, it is safe to assume that there are and will always be evasion techniques that are one step ahead and bypass the current detection methods.
+
+\textit{Evasion techniques} is an umbrella term that covers multiple sub-categories, each for a different purpose.
+One aspect of evasion is the ability to conceal the malicious nature of the files that constitute the malware.
+For this purpose, malware may employ homomorphic or metamorphic methods to bypass signature matching or use a file-less design to avoid analysis altogether.
+Hiding artifacts is another capability that malware author employ to evade detection.
+By exploiting the \ac{os} mechanisms, malware can hide their executables, logs, or users.
+
+This study focuses on another specific evasion domain: process hiding.
+The list of running processes is an obviously compelling resource to start detecting malware.
+To detect running malware, one could simply gather the list of all running software and search for known malware.
+With the list of processes frequently collected, an \ac{hids} can detect known malware, mine rules, define an activity profile, or detect anomalous situations.
+
+\begin{figure}[t]
+\centering
+\includegraphics[width=1\linewidth]{images/contribution.pdf}
+\caption{Intrusion detection systems traditionally trust the list of processes to be complete and accurate. We propose an independent verification mechanism that uses the power consumption of the processor to identify tampering with the process list before its usage.}
+\label{fig:contribution}
+\end{figure}
+
+Removing itself from the process list is a good first step for any malware aiming for stealth.
+We can categorize the techniques achieving this type of evasion between hiding and masquerading.
+For process hiding, the goal is to execute a program and leave no trace of it in the process list.
+For process masquerading, the aim is not as much to avoid the listing but to avoid the malware being listed with its real identity.
+A process masquerading as another will assume its process name and characteristics, with the goal of appearing legitimate on the machine.
+Process hiding and masquerading differ in their ultimate goal but leverage common techniques.
+The core idea of process list manipulation is tampering with the process listing mechanism provided by the \ac{os} to the monitoring software.
+Independently of the \ac{os}, attackers often rely on intercepting system calls to remove or replace information or directly manipulating kernel objects.
+For the purpose of this study, we do not differentiate between Unix-based \acp{os} and Windows systems, as process hiding is a common practice for malware in both environments.
+
+
+% there are detection methods but they are all host-based and doomed to be bypassed
+Of course, many methods have been proposed and implemented to detect or counter process list tampering (see Section~\ref{sec:related-work}).
+These methods --- although they leverage different mechanisms --- are all host-based.
+This creates a circular dependency where the \ac{ids} rely on the host system to provide the very information leveraged to assess its integrity.
+In this situation, an attacker that successfully compromises a machine can employ evasion techniques that manipulate the data used for detection.
+Some methods, targeting hypervisor systems specifically, run on the host instead of the \ac{vm}.
+This position adds distances between the \ac{ids} and the machine being monitored and provides additional security against bypasses.
+However, multiple \ac{vm} escape mechanisms have been documented over the years, affecting most virtualization software and reducing the virtual distance between the attacker and the detection system. 
+As rootkits providing process hiding remained a threat since their introduction, it is safe to assume that current countermeasures --- and future ones based on similar techniques --- do not provide complete protection.
+
+% is it a bird? is it a plane? No its the good old power consumption!
+One possible alternate method for detecting process list manipulation is using a secondary source of information to corroborate the process list (see Figure~\ref{fig:contribution}).
+To avoid bypass, the secondary source must be independent of the \ac{os} and not require its cooperation to enable protection.
+However, the source must also provide information correlated with process presence and activity on the machine.
+
+
+\ac{sci} is compelling as the secondary source.
+As involuntary emissions, they are naturally independent of the origin system.
+No communication is required with the system to access this information.
+As physical by-products of the computation, they are hard to forge or remove from the attacker's standpoint.
+A program can somewhat control its computation intensity, but it is difficult to precisely control the generated emissions and impossible to fully suppress them.
+If the attacker wants to perform any computation on the compromised machine, it will result in some form of physical emission.
+The most common \ac{sci} leveraged for attack or defense is energy consumption due to its ease of capture, high reliability, large range of applications, and good informative potential about the activity of the system.
+
+However, there are drawbacks to using power consumption as a source of information.
+First, the raw power consumption of a machine is not an actionable piece of information.
+A step of information mining --- for example, pattern recognition, anomaly detection, or even the comparison to a threshold --- is always required to make a decision.
+Then, measuring true independent power consumption data requires additional hardware.
+Although software estimations of power consumption are available, they bear the same circular dependency issue as other host-based sources of information (see Section~\ref{sec:soft-power} for more details about software-based measurements).
+Finally, the power consumption of a machine only contains a small subset of all information related to process activity.
+A modern \ac{cpu} executes hundreds to thousands of millions of instructions per second.
+Each instruction triggers multiple consumption patterns across multiple components of the system.
+Although --- in theory --- the power consumption is a sum of all these sub-consumptions, the reality of measurement, in terms of resolution, accuracy, and sampling rate, makes single-instruction measurement unrealistic at a global scale of the \ac{cpu}.
+
+Taking all these limitations into account, the power consumption of a machine --- and more specifically, the power consumption of its \ac{cpu} --- can be a valuable complementary source of information if properly exploited.
+The correlation between a list of processes and the power consumption can enable the detection of process list tampering and evidence of malware activity.
+
+\section{Contribution}
+In this paper, we propose a novel hidden process detection approach that leverages the power consumption of the \ac{cpu} as ground truth information to verify the process list (see Figure~\ref{fig:contribution}).
+The list of processes serves as input to a machine-learning model that predicts the expected power consumption based on the instances of processes and their state.
+The comparison between this predicted power and the independently-measured reference enables the detection of \ac{cpu}-consuming malware.
+
+
+\section{Related Work}\label{sec:related-work}
+Hiding malicious activity to avoid detection is neither a new nor a diminishing issue.
+Rootkits are a well-established threat with a history spanning decades and modern examples still in use by malicious actors.
+In 2022, Kaspersky announced the detection of CosmicStrand, a \ac{uefi} firmware rootkit resistant to \ac{os} reinstallation \cite{cosmicstrand}.
+In 2024, the Windows \ac{msrt} reported that Rootkits represented 14\% of all detected malware \cite{win-msrt}.
+
+As a response to this threat, the field of hidden malware detection has received frequent contributions over the last twenty years.
+With the emergence and popularization of virtualized environments for cloud computing over the same period, many proposed approaches leveraged the special position and visibility that a software running on the host machine has over the \acp{vm}.
+These \ac{vmm}-based methods can be considered \textit{out-of-the-box} as there is a logical isolation between the monitoring software and the monitored \ac{vm}.
+This isolation provides a compelling independence from the potentially compromised target, which improves robustness to bypasses by the malware.
+VMWatcher proposed by Jiang et al. in 2007 \cite{10.1145/1315245.1315262} is an important contribution to the field and an example of \ac{vmm}-based approaches.
+Their proposed approach reconstructs the monitored \ac{vm}'s objects at the host level to enable host-based anti-malware to run from the safety of the host while enjoying the same visibility as running in the \ac{vm}.
+This approach enables hidden-process detection to be more robust to bypass or counter-detection.
+Other proposed approaches \cite{wen2008implicit, jones2008vmm, wang2005detecting} leverage the special position of the host machine to perform rootkit detection.
+
+However, all \ac{vmm}-based approaches make the hidden assumption that the host machine and the \ac{vm} can be considered isolated machines when it comes to malware, thus providing a secure environment for running protection software.
+While it is undeniable that virtualization provides, by design, a strong barrier between the host and the guest, it would be a mistake to consider it perfect.
+\ac{vm} escapes are usually made possible by the presence of vulnerabilities in the virtualization system, and \ac{cve} reports can be found for all major systems.
+In 2009, Kortchinsky presented Cloudburst, a \ac{vm} escape mechanism for the VMWare virtualization system based on the exploitation of vulnerabilities in the graphics stack.
+In 2017, a heap buffer overflow in SVGA \ac{vm} escape vulnerability for VMWare was exploited during the Pown2Own competition \cite{cve-vmware-2017}.
+In 2021, a vulnerability in Oracle VirtualBox allowed a highly privileged attacker to hang or crash the host system or update, insert or delete access to some of the host data \cite{cve-vbox-2021}.
+In 2019, a heap buffer overflow vulnerability was discovered in the QEMU virtualization system and could enable an attacker to execute arbitrary code with privileges of the QEMU process, potentially leading to \ac{vm} escape \cite{cve-qemu-2019}.
+Similar vulnerabilities exist for Xen Hypervisor (that uses QEMU for some tasks) \cite{cve-xen-2015} or Microsoft Hyper-V \cite{cve-hyperv-2021}.
+In light of all these vulnerabilities, it is valid to assume that, to a dedicated attacker, the host and the \ac{vm} guest are not isolated.
+Stemming from this assumption, \ac{vmm}-based hidden processes detection methods are as vulnerable to bypass or tampering as host-based approaches.
+However, the idea of an isolated source of information about the system's activity remains compelling for hidden process detection.
+
+One solution to combine observability and independence is to study \ac{sci}.
+\ac{sci} is a by-product of a machine's normal operation.
+In the case of a computer, commonly studied side-channels are sound (fan, keyboard), electromagnetic emissions, timing, and power consumption.
+Historically, \ac{sci} have been leveraged for attacks.
+Since the seminal work of P. Kosher \cite{kocher1996timing} in 1996 on using timing information in the power consumption to extract cryptographic secrets, all side-channel emissions have been evaluated for extracting information about a system's activity or information.
+The sound of a person typing on a keyboard can be correlated to the typed text \cite{1301311}, the electromagnetic radiations from a display can reveal information about the displayed image \cite{van1985electromagnetic}, and \ac{ssl} connections are vulnerable to timing attacks even through multiple routers \cite{brumley2005remote}.
+
+These works revealed the amount of information that leaks through involuntary emissions.
+Although side-channel was first studied as an attack vector, other researchers realized the potential of this source of information for defensive purposes.
+Akin to machine health monitoring \cite{worden2007application, shewale2019novel}, defensive side-channel analysis uses the \ac{sci} of a machine to non-intrusively infer and assess its state, activity, or performance.
+In the case of a computer, previous works evaluated the use of electromagnetic or power consumption emissions to detect malware \cite{khan2019malware, cathis2024sok}.
+In 2015, Caviglione et al. \cite{7362010} proposed to use the power consumption of a mobile device to identify evidence of hidden software communication.
+In 2018, Bridges et al.\cite{bridges2018towards} describe a power-based malware detection system for general purpose computers.
+Their method using only the power consumption as source of information, it relies on a labelled dataset to learn the power profiles associated with malware activity.
+These works illustrate the potential of power consumption as a proxy variable for the activity of hidden processes on a machine.
+
+It is interesting to note that the problem of using the power consumption of a computing machine to identify hidden processes has a direct parallel in the domain of \ac{nilm} and smart buildings or cities.
+A study by Chou et al. \cite{chou2014real} proposes to apply machine-learning methods to process large datasets of building power consumption data for both consumption prediction and anomaly detection.
+It is easy to draw a conceptual parallel between a computer running multiple processes and a building containing multiple appliances.
+In both cases, the activity of each component is additive and contributes to global power consumption.
+However, it is important to keep in mind the differences between the two applications, such as the non-linearity and upper-bound of the accumulation of processes from the point of view of the \ac{cpu} consumption.
+
+\section{Problem Statement}
+
+The main problem that this study proposes to tackle can be described as follows:
+
+\begin{center}
+    Given the list of processes and their state and the power consumption of the \ac{cpu} over the same time period, identify any tampering with the process list.
+\end{center}
+
+The list of processes over time $P = \{p_0,p_1\dots,p_{n-1}\}$ is a nested data object where each item $p_i$ contains all listed processes at timestamp $i$ named the \ac{ilp}.
+Each \ac{ilp} contains the name and state of each process present on the machine at a point in time.
+From capture to utilization in the prediction model, the process list $P$ undergoes a number of transformations to reorganize the information for learning.
+See Section~\ref{sec:feature-engineering} for technical details about the process list processing.
+The power consumption trace --- also named power trace --- is a univariate time series representing the measured power consumption of the \ac{cpu} over time.
+
+\subsection{Attacker Model}
+The proposed approach makes several assumptions on the capabilities, goal, and knowledge of the attackers.
+Certain aspects of the detection framework --- for example, the strict independence requirement for the collection of the power trace --- are direct consequences of these assumptions.
+
+\subsubsection{Capabilities}
+This study assumes a powerful attacker with complete remote access to the monitored machine.
+We suppose that the attacker previously established remote access and can use this access at will and without risking detection.
+For example, the attacker could have recovered legitimate credentials for a local account on the machine.
+Moreover, the attacker is assumed to enjoy unrestricted access to the machine with the highest privilege level.
+No operation on the machine is impossible for the attacker, including any firmware or \ac{bios} tampering.
+For example, it is expected that the attacker can attack storage devices and boot a different \ac{os} than expected.
+In the case of the virtualized environment, it is also assumed that the attacker can escape the initial infected \ac{vm} and infect the underlying host machine.
+
+The only limitation of the attacker is the physical access to the power measurement system.
+This mechanism includes the hardware installed in a machine or built-in by the manufacturer, as well as the subsequent data processing pipeline.
+The attacker does not have access to the internal components responsible for measuring, processing, or verifying the power consumption.
+
+\subsubsection{Goals}
+This study does not restrict the attacker to any specific intention beyond stealth.
+The attacker may want to secretly execute arbitrary code, exploit the machine's resources --- for example, cryptojacking malware\cite{tekiner2021sok} --- or prevent the execution of programs --- such as backup or updates.
+To achieve stealth, the attacker will employ evasion techniques \cite{eresheim2017evolution} to hide or masquerade its malicious processes.
+This study is not restricted to any specific evasion method.
+
+
+\subsubsection{Attacker's Knowledge}
+This study assumes that the attacker is aware that the proposed defense mechanism is deployed on the machine and understands all aspects of it.
+However, the attacker may ignore the implementation choices related to the proposed approach.
+For example, the attacker is aware that a power analysis method is active on the machine but may ignore the hyper-parameters of the model in use, the window of training data leveraged, or the sampling rate of the power capture system.
+See Section~\ref{sec:evasion} for a more detailed analysis of a possible partial evasion method depending on the attacker's knowledge.
+
+\section{Proposed Approach}
+
+To address the problem of hidden process detection, we use a method based on power prediction.
+Figure~\ref{fig:proposed_approach} presents an overview of the proposed approach.
+The intuition behind this approach is that the power consumption of a \ac{cpu} is an aggregate of the individual power consumption of the tasks it performs.
+Thus, given enough training samples involving different combinations of tasks and the associated power consumption, a machine-learning model should be able to infer the power consumption from the list of processes.
+After training and establishing the nominal accuracy of the prediction, the model starts inferring power traces associated with untrusted lists of processes.
+If the predicted power is different from the ground truth by a margin that exceeds the nominal error, then the list of processes might have been tampered with.
+The tampering could be subtractive --- an attacker ran a process but prevented it from appearing in the process list --- or additive --- a non-running process was artificially added to the process list --- resulting respectively in a negative or positive prediction error.
+
+\begin{figure*}[t]
+\centering
+\includegraphics[width=1\linewidth]{images/proposed_approach_overview.pdf}
+\caption{Overview of the proposed approach. First, the regression model takes a list of process for a window of time and predicts the power consumption. Then, the comparison between the prediction and the actual consumption reveals any tampering of the process list.}
+\label{fig:proposed_approach}
+\end{figure*}
+
+\subsection{Sources of Information}\label{sec:collection}
+
+\begin{figure}[t]
+\centering
+\includegraphics[width=1\linewidth]{images/collection_pipeline_small.pdf}
+\caption{Data collection pipeline for process verification. The input data in the \ac{cpu} readings from the Azure dataset. The replay script stresses the local machine to replicate the activity on the \ac{vm}. The captured power consumption and processes list are preprocessed into usable training data for the prediction model.}
+\label{fig:pipeline}
+\end{figure}
+
+This approach leverages two distinct sources of information.
+Figure~\ref{fig:pipeline} illustrates the data collection pipeline for each source of information.
+The first source is the list of processes.
+This list is accessible by any privileged users through \ac{os} utilities on every common \acp{os}.
+All implementations in this study use the \texttt{ps} command on the Debian 12 distribution.
+This command lists a lot of information from the processes that are retrieved from the \texttt{/proc} virtual file system.
+Out of all the available information, only the command and the state of the process are collected and used for training the model.
+The choice of collecting the complete command associated with each process stems from the necessity of differentiating instances of the same program working in different modes.
+From a power consumption point of view, programs performing different tasks should be considered independent to enable the prediction model to learn their power profile independently of the program name.
+The collection of the process list uses a \texttt{bash} script whose main loops consist of listing the processes and storing the information in a \ac{tsv} file.
+The target sampling rate was set to 10Hz, with actual sampling rates ranging from 8Hz to 10Hz depending on the hardware capabilities.
+
+The second source of information is the power consumption of the \ac{cpu}.
+There are two main approaches for measuring the power: (1) placing a current sensing device in series with the power cable and (2) attaching a wireless current clamp around the power cable.
+While the second method is less intrusive, early exploratory work revealed that the measured values carried more noise, and that could affect the performance of the method.
+Thus, we chose to place the current sensing device in series with the power cable to access the best raw data possible.
+The current sensor consists of a \ac{pcb} that the current traverses.
+A Hall effect sensor produces a voltage proportional to the current, and this voltage is amplified and digitized before being sent to a storage server.
+The sensor samples the current at 10kHz.
+This high sampling rate is much higher than the sampling rate of the process list (to which the power trace must be reduced), but the extra information is useful for reducing the noise while down-sampling.
+
+\subsection{Feature Engineering}\label{sec:feature-engineering}
+
+Each source of information undergoes a pre-processing phase to form the training and testing dataset necessary for this evaluation.
+
+\subsubsection{Process List}
+For the processes, the main task is the encoding of the occurrences in a format suitable for a machine-learning model.
+The collection file contains, for each timestamp, the command and state of all processes.
+A natural encoding is multi-hot, where each unique command --- across the whole collection file --- is associated with a position in an array.
+Each cell of the encoded array is populated with the number of occurrences of the associated command.
+However, this method encodes the occurrence of a process but not its state.
+To encode the state, we first separate all possible states as either consuming power or not consuming power.
+As an example, all processes with the \textit{running} state are actively running on the machine and thus using the \ac{cpu} and consuming power.
+On the other hand, all processes with the \textit{sleeping} state are idle and do not affect the power consumption.
+Using this binary partition of all states, two encoding arrays are created.
+The first array encodes the occurrences of the consuming processes, and the second encodes the occurrences of the non-consuming processes.
+These two arrays can be concatenated along either axis depending on the input shape of the machine learning model used.
+
+\subsubsection{Power Trace}
+For the power trace, the pre-processing steps involve filtering and downsampling.
+The capture system produces raw power traces sampled at 10kHz.
+However, these traces must contain a single sample for each process list retrieved from the machine.
+Instead of sub-sampling the power trace to match the timestamps of the process list dataset (and loosing all extra information), some noise filtering takes place before the resampling of the trace.
+The filter is a rolling median function with a time window of one second and centred around the middle sample.
+Then the trace is down-sampled using the nearest power value for each process list timestamp.
+When loading the trace for analysis, a second median filter with a time window of 10 seconds helps remove more of the noise that affect the trace.
+
+The final pre-processed data is two arrays.
+The first is a one-dimensional array of the power consumption of the \ac{cpu} at each timestamp.
+The second is a two-dimensional array where each row contains the multi-hot encoded information of all listed processes and their state at each timestamp.
+All data for the two case studies presented in this paper are freely available online \cite{zenodo-dataset}.
+
+\subsubsection{Model}
+The task of predicting the power using a list of processes is a typical regression task.
+Each process has a power consumption value, and all consumptions add up to form the global power consumption of the \ac{cpu}.
+For processes always present in the list (for example, the init process), the model might not be able to learn its specific power consumption as it cannot be isolated from other constant or mandatory processes.
+Additionally, some process's consumption might be dependent on the presence of other processes.
+These potential dependencies motivate the selection of a neural network model over a simpler linear regression approach.
+Although no claim is made that the selected model is optimal for the task, we found from empirical evaluations that satisfactory results were achievable with an \ac{mlp} network composed of a few inner layers.
+
+The selected network is a densely connected \ac{mlp} network with five inner layers of size $128,128,128,100,10$ and a single output layer value (see Figure~\ref{fig:model}), created using the Keras Python library \cite{chollet2015keras}.
+The training uses the Adam optimizer with an \ac{mae} loss, a batch size of 1024 and 100 epochs without an early stopping strategy.
+Additionally, dropouts with rates $0.3,0.3,0.3,0.1$ were added to the first four inner layers.
+
+
+\begin{figure}[t]
+\centering
+\includegraphics[width=1\linewidth]{images/model.pdf}
+\caption{The chosen model for this study is an \ac{mlp} with five densely connected hidden layers. The input is a 2D array populated with the number of occurrences of each process at a point in time. The first dimension contains the running processes, and the second is the sleeping processes. The output is a single number corresponding to the predicted power consumption at this instant. The model predicts the power at each instant independently from the previous or future observation.}
+\label{fig:model}
+\end{figure}
+
+
+\section{Case Study 1}
+
+%To demonstrate the capabilities of the proposed approach, this paper presents two case study\agd{update if needed} that replicates real machine tasks.
+This first case study aims at evaluating the ability of a machine-learning model to infer the power consumption of the \ac{cpu} from the list of processes.
+To this purpose, we must acquire ground truth power consumption and process information during machine activity for training and validation.
+To the best of our knowledge, no dataset containing these information is publicly available.
+To provide a realistic evaluation, the captured data is based on a publicly available dataset of real production \ac{vm} deployed on the Azure cloud service \cite{cortez2017resource,azure-dataset}.
+However, this dataset only provides \ac{cpu} activity readings.
+To build the training dataset required for this experiment (process list and power consumption), we replicated the activity provided by the Azure dataset on multiple machines instrumented for collecting all required data (see Section~\ref{sec:collection}).
+
+\subsection{Data Preparation}
+The core principle for replaying the dataset is to run a task on the machine with a target \ac{cpu} usage matching the value in the Azure dataset.
+The raw \ac{cpu} readings are values between 0\% and 100\% that are captured per \ac{vm}.
+
+The initial idea would be to consider each sample iteratively and use the raw readings as the target usage.
+However, this approach would require running processes with different target usage (considered different processes) for consecutive values slightly varying around the same average.
+This approach would be an unfair replay that produces a large number of unique processes registered in the process list even when only a few processes are running on the source \ac{vm}.
+This artificial variety would make it harder for a model to learn the consumption associated with each process and would not correctly represent the activity on the production machine.
+To alleviate this issue, we first bin the \ac{cpu} readings in ten equal sections of ten percent usage each.
+Thus, all readings gravitating around a unique value are represented by the same process.
+
+After binning the \ac{cpu} readings, we group the \ac{vm} in consolidated groups averaging 80\% \ac{cpu} usage.
+\ac{vm} consolidation --- also called \ac{vm} packing --- is the practice of grouping compatible virtual instances on the same hardware to optimize resource usage.
+The target of 80\% usage is the recommended average from \ac{aws}.
+Optimizing the \ac{vm} packing is a field of research in itself \cite{cortez2017resource} and is outside the scope of this study.
+We used a simple algorithm to pack \acp{vm} into consolidated groups by adding randomly selected \ac{vm} until the average activity is reached or exceeded.
+
+The Azure dataset contains 2.6 million traces of individual \ac{vm}.
+To get a representative sample of all traces, we randomly selected 388 \ac{vm} traces to place in 71 consolidated replay groups.
+These groups were replayed on four different machines (see Table~\ref{tab:machines}).
+Multiple machines enable replaying more traces --- achieving a more accurate representation of the dataset --- and including some hardware diversity to help identify if some hardware is more suitable for this approach.
+
+
+
+\begin{table}
+\centering
+\begin{tabular}{llll}
+\toprule
+Machine & CPU & Clock & RAM\\
+\midrule
+1 & i7-6700 (8) & 4.00 GHz & 16 GiB \\
+2 & E5-2620 v3 (12) & 3.20 GHz & 32 GiB \\
+3 & i7-2600 (8) & 3.80 GHz & 8 GiB \\
+4 & i7-3770 (8) & 3.90 GHz & 16 GiB \\
+\bottomrule\\
+\end{tabular}
+\caption{Specifications of the machines used for replaying the CPU activity from the Azure dataset.}
+\label{tab:machines}
+\end{table}
+
+
+\subsection{Results}
+Figure~\ref{fig:prediction} presents an example of the ground truth power consumption and the prediction.
+There are two elements that are interesting to notice in the figure.
+First, the power spikes associated with the processes are correctly predicted by the model.
+It is clear that, given the training data, the model can learn the power consumption associated with each process and sum them to reach a prediction consistent with the ground truth at a macro scale.
+On a per-sample scale, the ground truth contains noise that is impossible for the model to predict, given the input data.
+In a computer, sources of noise to the power consumption are myriad, and thus, it is expected that the prediction only outputs an average power level.
+
+To compare the prediction of the model with the ground truth quantitatively, one common metric in machine learning is the \ac{mse}.
+The \ac{mse} computes the average of the point-wise square of the error.
+Table~\ref{tab:mse} presents the \ac{mse} values for both the normal and simulated attack version of each consolidated \ac{vm}.
+From these values, we can infer two important elements.
+First, the attack \ac{mse} is higher in 89\% of the traces.
+These results (similar to an ablation study) indicate that the model does extract valuable information from the input process list, as the prediction becomes worse when these are removed.
+The second important point comes from the relatively high number of runs where the \ac{mse} does not degrade when the process list is modified.
+This second element indicates that the \ac{mse} cannot be the determining value for detecting an attack as it does not robustly capture the presence of an attack.
+
+To address the second point, we propose to use a different value to evaluate the performance of the prediction.
+When studying the prediction more closely, it becomes apparent that the prediction suffers from a misalignment with respect to the ground truth.
+Although the patterns are correct, the difference in timing introduces large errors around the transitions that greatly influence the \ac{mse} score.
+The objective is to choose a distance metric robust to static or dynamic misalignment between the two source signals.
+The \ac{dtw} distance was proposed for solving exactly this issue.
+When applied to two signals, \ac{dtw} computes an optimal match distance that is tolerant to static and dynamic shifts.
+Because the attacks mostly affect the amplitude and not the timing of the power consumption patterns, the \ac{dtw} distance should increase when an attack is present and the prediction worsens.
+Table~\ref{tab:cs1} presents the results for the \ac{dtw} distance for each run of a consolidated \ac{vm} for both the normal and the attack versions of the input process list.
+We can confirm from these values that the \ac{dtw} distance is a more robust metric for evaluating the performance of the model in predicting the power consumption.
+In 94\% of the runs, the value increases for the attack version compared with the normal version.
+
+\begin{figure}[t]
+\centering
+\includegraphics[width=1\linewidth]{images/prediction.pdf}
+\caption{Example of ground truth power consumption and prediction from the model. The regular spikes in the prediction corresponds to state transition in the replay scripts that generate wide changes in the process list. The power levels generated by the stress program are correctly learned and predicted by the model, although miss-alignments are visible between the ground truth and the prediction.}
+\label{fig:prediction}
+\end{figure}
+
+\begin{table*}
+\centering
+\begin{tabular}{cc|cc|cc|cc}\toprule
+\multicolumn{2}{c}{\textbf{Machine 1}} & \multicolumn{2}{c}{\textbf{Machine 2}} & \multicolumn{2}{c}{\textbf{Machine 3}} & \multicolumn{2}{c}{\textbf{Machine 4}}\\
+
+\textbf{MSE} & \textbf{Attack MSE} & \textbf{MSE} & \textbf{Attack MSE} & \textbf{MSE} & \textbf{Attack MSE} & \textbf{MSE} & \textbf{Attack MSE}\\
+\midrule
+
+0.016&\textbf{0.024}&0.104&\textbf{0.163}&0.045&\textbf{0.051}&0.02&\textbf{0.142}\\
+0.021&\textbf{0.027}&0.085&\textbf{0.088}&0.053&\textbf{0.055}&0.162&\textbf{0.21}\\
+0.012&\textbf{0.013}&0.023&\textbf{0.636}&0.07&\textbf{0.083}&0.07&\textbf{0.096}\\
+0.069&\textbf{0.13}&0.071&\textbf{0.107}&0.001&\textbf{0.001}&0.063&\textbf{0.08}\\
+0.02&\textbf{0.031}&0.062&\textbf{0.235}&0.051&\textbf{0.078}&0.134&\textbf{0.537}\\
+\textbf{0.068}&0.063&0.06&\textbf{0.089}&0.026&\textbf{0.03}&0.167&\textbf{0.306}\\
+\textbf{0.029}&0.028&0.009&\textbf{0.011}&0.014&\textbf{0.026}&0.057&\textbf{0.243}\\
+0.022&\textbf{0.034}&0.013&\textbf{0.024}&0.001&\textbf{0.001}&0.129&\textbf{0.238}\\
+0.002&\textbf{0.079}&\textbf{0.042}&0.041&\textbf{0.084}&0.067&0.099&\textbf{0.138}\\
+0.028&\textbf{0.044}&0.095&\textbf{0.099}&0.061&\textbf{0.075}&0.004&\textbf{0.005}\\
+0.007&\textbf{0.008}&0.015&\textbf{0.017}&\textbf{0.044}&0.033&0.015&\textbf{0.02}\\
+\textbf{0.035}&0.032&0.027&\textbf{0.048}&0.096&\textbf{0.11}&0.01&\textbf{0.011}\\
+0.085&\textbf{0.099}&0.028&\textbf{0.05}&\textbf{0.044}&0.039&0.041&\textbf{0.046}\\
+0.067&\textbf{0.097}&0.028&\textbf{0.044}&0.075&\textbf{0.107}&0.046&\textbf{0.05}\\
+0.006&\textbf{0.015}&0.011&\textbf{0.012}&0.081&\textbf{0.082}&0.102&\textbf{0.166}\\
+\textbf{0.059}&0.035&0.113&\textbf{0.128}&0.054&\textbf{0.151}&0.038&\textbf{0.068}\\
+0.015&\textbf{0.026}&0.004&\textbf{0.004}&0.02&\textbf{0.023}&0.068&\textbf{0.134}\\
+0.033&\textbf{0.04}&0.087&\textbf{0.146}&0.02&\textbf{0.027}&0.044&\textbf{0.045}\\
+\bottomrule\\
+\end{tabular}
+\caption{\ac{mse} of the \ac{cpu} power consumption prediction for each machine for both the correct process list and the modified process list. The prediction \ac{mse} increases in 64 runs and decreases in 8 runs out of the total 72 runs. These results illustrate the capability of the model to learn power consumption levels associated with processes and the effect of erroneous entries in the process list.}
+\label{tab:mse}
+\end{table*}
+
+\begin{table*}
+\centering
+\begin{tabular}{cc|cc|cc|cc}\toprule
+\multicolumn{2}{c}{\textbf{Machine 1}} & \multicolumn{2}{c}{\textbf{Machine 2}} & \multicolumn{2}{c}{\textbf{Machine 3}} & \multicolumn{2}{c}{\textbf{Machine 4}}\\
+
+\textbf{DTW} & \textbf{Attack DTW} & \textbf{DTW} & \textbf{Attack DTW} & \textbf{DTW} & \textbf{Attack DTW} & \textbf{DTW} & \textbf{Attack DTW}\\
+\midrule
+1040.0&\textbf{1400.0}&2200.0&\textbf{8540.0}&860.0&\textbf{1860.0}&\textbf{3770.0}&1810.0\\
+1350.0&\textbf{1710.0}&1190.0&\textbf{6560.0}&2360.0&\textbf{2970.0}&4110.0&\textbf{7450.0}\\
+850.0&\textbf{1690.0}&1140.0&\textbf{12000.0}&2710.0&\textbf{5320.0}&3010.0&\textbf{3730.0}\\
+3570.0&\textbf{9910.0}&2120.0&\textbf{5210.0}&804.0&\textbf{2900.0}&2610.0&\textbf{3450.0}\\
+1020.0&\textbf{1460.0}&2440.0&\textbf{7670.0}&2080.0&\textbf{2870.0}&3590.0&\textbf{20000.0}\\
+2340.0&\textbf{2870.0}&2220.0&\textbf{4020.0}&1320.0&\textbf{2280.0}&2720.0&\textbf{9070.0}\\
+1380.0&\textbf{2010.0}&765.0&\textbf{1660.0}&1670.0&\textbf{1810.0}&3590.0&\textbf{5370.0}\\
+874.0&\textbf{2290.0}&1020.0&\textbf{2800.0}&\textbf{76.0}&75.7&4180.0&\textbf{8180.0}\\
+997.0&\textbf{1540.0}&1650.0&\textbf{3330.0}&\textbf{3580.0}&2070.0&3520.0&\textbf{6710.0}\\
+1900.0&\textbf{2780.0}&2460.0&\textbf{5540.0}&2210.0&\textbf{3310.0}&388.0&\textbf{851.0}\\
+421.0&\textbf{447.0}&1000.0&\textbf{1670.0}&1900.0&\textbf{3090.0}&1140.0&\textbf{1570.0}\\
+2230.0&\textbf{2400.0}&1020.0&\textbf{2930.0}&3020.0&\textbf{3140.0}&944.0&\textbf{1890.0}\\
+3380.0&\textbf{3710.0}&1220.0&\textbf{3150.0}&2610.0&\textbf{2610.0}&1680.0&\textbf{2820.0}\\
+1120.0&\textbf{5260.0}&1840.0&\textbf{2860.0}&2520.0&\textbf{4960.0}&2000.0&\textbf{2460.0}\\
+589.0&\textbf{1050.0}&764.0&\textbf{1730.0}&4320.0&\textbf{5920.0}&3800.0&\textbf{4620.0}\\
+1410.0&\textbf{2410.0}&3160.0&\textbf{5930.0}&3040.0&\textbf{6880.0}&2160.0&\textbf{3650.0}\\
+599.0&\textbf{9910.0}&321.0&\textbf{670.0}&1130.0&\textbf{3710.0}&2600.0&\textbf{4740.0}\\
+X&X&3850.0&\textbf{7480.0}&\textbf{1710.0}&1540.0&1670.0&\textbf{3870.0}\\
+\bottomrule\\
+\end{tabular}
+\caption{\ac{dtw} distance between the predicted power and the ground truth during normal operation and simulated attack. The expected behaviour is an increase in the distance during the attack, representing the difficulty of the model to predict the correct pattern when the process information is wrong. The data confirm the expected behaviour in 94\% of the replayed consolidated \ac{vm}, confirming the soundness of the approach.}
+\label{tab:cs1}
+\end{table*}
+
+\section{Case Study 2}
+The first case study provided evidence supporting the two statements: (1) \textit{A model can learn to predict the power consumption of the \ac{cpu} using the instantaneous process list with satisfactory accuracy.}, and (2) \textit{When the process list is modified to hide processes with significant \ac{cpu} usage, the accuracy of the prediction degrades.}
+Establishing these statements is an important step on the way to establishing if this method is suitable for detecting process list tampering and hidden malware.
+However, the experiment conducted in the first case study does not characterize the type of malware that can be detected.
+
+By the very nature of the proposed approach, we already know that malware inducing marginal amounts of \ac{cpu} usage can likely evade detection.
+Indeed, if the inaccuracy added by the missing process information falls within the nominal inaccuracy of the model, then there is no basis for establishing that the process list is wrong.
+Similarly, malware requiring a high \ac{cpu} usage for a very short time would cause a thin spike in the power data that could get removed due to the reprocessing of the power trace.
+
+From these observations, it appears that the important metric for establishing if a process can be detected in the power consumption is the total energy that it requires to perform its operation.
+The malware authors have some control over the power profile of the program --- for example, selecting a fast approach that maximizes \ac{cpu} usage over a short time of a discrete approach that performs little operations over a longer time ---, but they can never reduce their energy usage to zero.
+
+In this case study, we want to illustrate the capabilities of the proposed approach for detecting hidden processes using different power profiles.
+We start by establishing a measure of the power consumption of a process in terms of time and \ac{cpu} usage.
+Let us consider a program $A$ using 50\% of the \ac{cpu} for 10 seconds.
+We measure its energy requirement as $E_A = 50 \textrm{CPU} \times 10s = 500 CPU.s$.
+Let us also suppose that the task of the program can be parallelized to take advantage of the multiple cores or modern \acp{cpu}.
+In this case, the program author has a range of activity profiles available.
+On one end, the program can use 100\% of the processor to minimize time.
+On the other, the program can spread the \ac{cpu} usage over a very large amount of time.
+Between these two extremes, all combinations of activity and duration that respect the total activity profile are possible.
+Figure~\ref{fig:malware_area} illustrates the different activity profiles that a hypothetical malware can take.
+
+\begin{figure}[t]
+\centering
+\includegraphics[width=1\linewidth]{images/profiles.pdf}
+\caption{A program can spread its activity from a minimum duration --- when using all available \ac{cpu} resources --- to an arbitrarily long duration. Regardless of the pattern, the total activity remains the same. The second case study establishes which activity profiles are detectable by the proposed approach.}
+\label{fig:malware_area}
+\end{figure}
+
+The point of the second case study is to establish the performance of the proposed method at detecting malware with different activity profiles.
+
+\subsection{Data Collection and Detection Method}
+For this case study, we replayed and collected the same \ac{vm} as for the first case study.
+During the last 20\% of the trace --- that are excluded from training ---, a pre-defined malware script executed three instances of fake malware following three different activity profiles.
+The three instances of the malware are: (1) 100\% \ac{cpu} usage for two minutes, (2) 80\% \ac{cpu} usage for two minutes and 30 seconds, and (3) 60\% for three minutes and 20 seconds, following a constant total \ac{cpu} usage of $2000 CPU.s$.
+
+After the data is collected, we split each trace --- following the same method as for the first case study --- and train a new model for each of them.
+The model predicts the remaining 20\% of the trace using the list of processes.
+Although the malware process occurrences are only present in the test part of the dataset --- and thus the model should not be able to predict their associated power ---, we still remove the occurrence from the test part to ensure that the input data resemble real data as closely as possible.
+
+The detection relies on the comparison between the predicted power trace and the real power trace.
+One intuitive approach would be to compute the absolute difference between the two traces and set a threshold above which an attack is detected.
+While this approach does detect attacks in the correct periods corresponding to real attacks, early evaluations revealed that too many other parts of the trace were also detected as attacks.
+This was due to large error spikes due to timing inconsistencies between the process list information and the power consumption trace.
+The top graph of Figure~\ref{fig:cs2} illustrates this timing shift.
+We can see in this graph that the predicted power follows the same pattern as the ground truth trace, but their transitions are not perfectly aligned.
+This synchronization issue prompted the development of a more robust detection method that is more tolerant of timing inconsistencies and focuses more on pattern predictions.
+
+The chosen solution is a combination of a sliding window and the \ac{dtw} distance.
+The \ac{dtw} distance is adequate for computing a similarity score between time series with different time references --- either offset or dilation/compression.
+To apply \ac{dtw}, we apply a sliding window of width 1000 samples --- approximately 10 seconds --- with a stride of one sample.
+For each window, the \ac{dtw} distance between the prediction and the ground truth is computed.
+The bottom graph of Figure~\ref{fig:cs2} shows the windowed \ac{dtw} distance corresponding to the traces in the top graph.
+Now that a more robust distance metric is available, a threshold calculated as $1.1\times max(D_{[0,4000]})$ --- $D$ the windowed \ac{dtw} distance --- is applied to determine which periods contain attacks.
+
+\begin{figure*}[t]
+\centering
+\includegraphics[width=1\linewidth]{images/attack_detection.pdf}
+\caption{Visualization of the detection of hidden processes using the predicted power consumption. The top graph presents the real power consumption of the machine (Ground Truth), the prediction of the model over the same period, and the periods when the malware is running. The bottom graph presents the sliding DTW distance and the detected attack periods. An attack is detected when the DTW distance between the prediction and the ground truth exceeds the threshold. The highlighted periods show that, for this example, at least one detection is made for each real attack.}
+\label{fig:cs2}
+\end{figure*}
+
+\subsection{Results}
+
+For each run, we compute the accuracy, recall, and $F-1$ score of the attack prediction.
+Table~\ref{tab:cs2_results} presents the performance of the detection for each replayed \ac{vm}.
+It is important to notice that each \ac{vm} was replayed on a single machine, thus the results are not to be compared linewise.
+The bottom line presents the results of each metric averaged across all \ac{vm} of the machines.
+
+To interpret the results, it is important to understand the type of problem studied.
+The detection of attacks in a time series is an infrequent event detection problem where most of the labels to predict are "no attack".
+As it is explained by McCue \cite{MCCUE20073}, this type of problem cannot use the same classical baseline as other machine learning problems because naive solution can yield seemingly excellent results.
+For example, in the case of this study, a naive model that always predict "no attack" achieves remarkable results with 97\% precision, 100\% recall and 98\% $F_1$.
+It is obvious that never predicting an attack should not be a high-achieving solution to this problem, and there lie the difficulty of interpreting the results.
+Instead of using the baseline results of naive or random methods, the performance metrics should aim for reaching their best possible value (100\% for the all three considered metrics).
+
+The first important information from the results is that the average metrics achieve a score of at least 0.75.
+This result is promising as it indicates that the detection method does detect some attacks.
+However, the individual results are also interesting.
+For some traces, the performance can vary widely from a near-perfect detection to a hardly adequate one.
+This variety indicates that the type of hardware and the activity of the \ac{vm} have an influence on the detection performance.
+The root cause and precise nature of this influence is hard to determine with certitude and opens the way for future works dedicated to identifying more accurately the best environment for this approach.
+
+
+\begin{table*}
+\centering
+\begin{tabular}{ccc|ccc|ccc|ccc}\toprule
+\multicolumn{3}{c}{\textbf{Machine 1}} & \multicolumn{3}{c}{\textbf{Machine 2}} & \multicolumn{3}{c}{\textbf{Machine 3}} & \multicolumn{3}{c}{\textbf{Machine 4}}\\
+P & R & $F_1$ & P & R & $F_1$ & P & R & $F_1$ & P & R & $F_1$\\
+\midrule
+0.874&0.951&0.845&0.895&0.874&0.93&0.568&0.675&0.842&0.935&0.632&0.72\\
+0.828&0.93&0.801&0.928&0.91&0.882&0.746&0.874&0.867&0.894&0.768&0.887\\
+0.707&0.939&0.838&0.874&0.841&0.788&0.468&0.798&0.768&0.833&0.574&0.819\\
+0.698&0.933&0.946&0.916&0.83&0.924&0.868&0.92&0.758&0.927&0.89&0.914\\
+0.836&0.924&0.763&0.949&0.877&0.905&0.74&0.94&0.856&0.911&0.751&0.942\\
+0.885&0.891&0.758&0.788&0.581&0.889&0.762&0.794&0.631&0.89&0.76&0.791\\
+0.852&0.908&0.718&0.701&0.869&0.883&0.847&0.654&0.836&0.891&0.777&0.676\\
+0.839&0.911&0.848&0.916&0.916&0.914&0.867&0.835&0.876&0.879&0.831&0.853\\
+0.906&0.75&0.716&0.728&0.885&0.866&0.816&0.46&0.892&0.803&0.763&0.527\\
+0.703&0.939&0.762&0.956&0.839&0.927&0.76&0.955&0.765&0.93&0.761&0.953\\
+0.719&0.89&0.739&0.933&0.848&0.81&0.828&0.891&0.778&0.831&0.78&0.901\\
+1.0&0.752&0.803&0.831&1.0&0.824&0.744&0.666&1.0&0.778&0.767&0.711\\
+0.718&0.902&0.73&0.873&0.847&0.91&0.854&0.85&0.777&0.905&0.787&0.796\\
+0.785&0.896&0.838&0.723&0.826&0.885&0.828&0.85&0.796&0.89&0.833&0.782\\
+0.784&0.944&0.701&0.858&0.833&0.849&0.837&0.866&0.783&0.877&0.763&0.837\\
+0.694&0.919&0.921&0.908&0.833&0.908&0.913&0.776&0.757&0.912&0.872&0.806\\
+0.71&0.889&0.713&0.929&0.842&0.877&0.843&0.881&0.77&0.882&0.772&0.892\\
+0.708&0.943&0.685&0.827&0.841&0.844&0.828&0.849&0.769&0.873&0.75&0.796\\
+\midrule
+\multicolumn{12}{c}{\textbf{Average}}\\
+\midrule
+0.791&0.85&0.807&0.901&0.879&0.88&0.785&0.784&0.768&0.863&0.807&0.811\\
+\bottomrule\\
+\end{tabular}
+\caption{Results of the detection of hidden malware activity in the replayed \ac{vm}. Each machine replayed 18 different \ac{vm}. The results are not to be compared linewise across machines. The performance metrics are precision (P), recall (R) and the $F_1$ score of the attack vector. The average results per machine are consistently above 0.75 $F_1$ score. These results illustrate the promising results of the approach but also indicate that the type of machine and activity have an influence on the performance and should be taken into account.}
+\label{tab:cs2_results}
+\end{table*}
+
+\section{Discussion}
+
+In this section, we elaborate on aspects of the study that we think are important to further explain.
+
+\subsection{Software Power Measurement}\label{sec:soft-power}
+The implementation of the approach proposed in this study can seem prohibitively complex due to the use of hardware components added to the machine to protect.
+After all, software solutions exist to measure or estimate the power consumption of a \ac{cpu} package. Removing the hardware components would enable mass deployment of this method to large fleets of machines at a fraction of the cost.
+
+However, the hardware measurement of the power consumption is the guarantee of an independent and trustworthy source of information.
+As soon as the power measurement mechanism relies on the collaboration of the protected machine, it is considered tainted and thus cannot be used for verifying the integrity of the list of processes.
+For this reason, the implementation of this method requires the use of an independent measurement of the power.
+
+
+\subsection{Evasion Techniques}\label{sec:evasion}
+As mentioned in the attacker model section, one of the goals is to provide a method for detecting process list tampering that does not rely on security-by-obscurity.
+This results in complete transparency from the defender about what method is used.
+We thus assume that the attacker knows that the power consumption of the machine is being correlated with the process list to detect tampering --- although the implementation details, such as the model architecture, temporal resolution, or training data, might be unknown.
+It is important to notice that this knowledge offers some evasion possibilities for the attacker.
+
+Let us suppose that an attacker can infect a machine and gain visibility on the running processes at all times.
+Let us also suppose that the attacker knows exactly the \ac{cpu} activity profile of their malware.
+In this situation, the attacker could select an ensemble of legitimate processes that, together, match the activity profile of their malware.
+Then, when it is time to run the malware, the attacker would delete it from the process list but inject in its place the group of legitimate processes to explain the increase of \ac{cpu} activity.
+
+From the point of view of the proposed approach, this modification would be invisible.
+However, that does not automatically imply that the attack would remain undetected.
+The proposed method is not meant to be placed at the end of the cyber-security pipeline.
+It is actually the opposite, as this verification step should be performed in the early stages of the data gathering.
+The point is to provide assurance that the list of processes is complete so that other tools can use it for detecting malware or applying security rules.
+In the case of this evasion, the proposed method fails to recognize a tampered list but forces the attacker to modify it in a way that should trigger other methods down the line.
+
+This theoretic evasion illustrates the necessity to implement the proposed approach as an additional layer and not a solution in itself.
+Verifying the integrity of the process list is not a replacement for analyzing it.
+
+\section{Future Work}
+This work constitutes --- to the best of our knowledge --- the first exploration in using \ac{sci} to validate the collected information from a potentially infected machine.
+Being at the interface of cyber-security and machine learning, there are many aspects of this work that deserve a dedicated and meticulous study to reach optimal performance.
+The input data collected from the machine for this study is limited to the list of processes and their state reduced to a binary choice.
+These represent only a very small part of all information that could be collected and verified using the proposed approach. 
+The reported resource usage (CPU, RAM, Disk I/O, Network, etc.), as well as more detailed information like the full process state range, would be interesting to validate and could enable the detection of other types of malware.
+On the side-channel side, power consumption is an obvious first choice as it is easy to measure and fairly informative, but other channels could provide useful complementary information.
+Finally, the machine learning model used in this study is only one example of an architecture that performs well for this task.
+
+Our aim for the continuation of this work is to provide a more general framework of models capable of using multi-model input and predicting multiple side-channel activity profiles, providing a more complete view of the machine's activity and reducing the hiding places of the malware.
+
+\section{Conclusion}
+This study provides an evaluation of using the power consumption of a machine to correlate and validate the list of processes before its use by an \ac{ids}.
+The independence of measurement provided by the \ac{sci} provides a ground truth against which the power predicted using the list of processes is compared.
+We illustrate the baseline performance of the prediction and, more importantly, the deviation that occurs when the list of processes is tampered with.
+This deviation enables the detection of hidden malware consuming \ac{cpu} resources while attempting to evade detection.
+The case studies illustrate the capability of the proposed approach in a consolidated \ac{vm} environment.
+To provide realistic evaluations, we replay public \ac{vm} activity traces from real instances.
+The proposed approach shows promising results for the \ac{sci} to be used as an additional complementary layer of protection against hidden malware.\\
+\newpage
+\clearpage
+\bibliographystyle{plain} % We choose the "plain" reference style
+\bibliography{biblio} % Entries are in the refs.bib file
+
+
+% that's all folks
+\end{document}
+
+

procver/SnP/questions.tex

@@ -0,0 +1,5 @@
+Q: For Case Study 1, should I present both results or just one table?
+
+Q: Should I insist on the fact that the dataset is public?
+
+Q: Should I find a citation for the DTW distance metric?

procver/SnP/utils.tex

@@ -0,0 +1,4 @@
+
+% Comments commands
+\newcommand\agd[1]{{\color{red}$\bigstar$}\footnote{agd: #1}}
+\newcommand\cn{{\color{purple}\textsuperscript{[citation needed]}}}

trust/aamas/images/opinion_flow.svg

@@ -0,0 +1,796 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   width="210mm"
+   height="138.08856mm"
+   viewBox="0 0 210 138.08856"
+   version="1.1"
+   id="svg1"
+   inkscape:version="1.4 (e7c3feb100, 2024-10-09)"
+   sodipodi:docname="opinion_flow.svg"
+   inkscape:export-filename="opinion_flow.pdf"
+   inkscape:export-xdpi="96"
+   inkscape:export-ydpi="96"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:svg="http://www.w3.org/2000/svg">
+  <sodipodi:namedview
+     id="namedview1"
+     pagecolor="#ffffff"
+     bordercolor="#eeeeee"
+     borderopacity="1"
+     inkscape:showpageshadow="0"
+     inkscape:pageopacity="0"
+     inkscape:pagecheckerboard="0"
+     inkscape:deskcolor="#505050"
+     inkscape:document-units="mm"
+     inkscape:zoom="1.0242632"
+     inkscape:cx="393.45356"
+     inkscape:cy="303.14474"
+     inkscape:window-width="1920"
+     inkscape:window-height="1022"
+     inkscape:window-x="0"
+     inkscape:window-y="30"
+     inkscape:window-maximized="1"
+     inkscape:current-layer="layer1"
+     showgrid="false">
+    <inkscape:page
+       x="0"
+       y="0"
+       width="210"
+       height="138.08856"
+       id="page40"
+       margin="0"
+       bleed="0"
+       inkscape:label="1" />
+  </sodipodi:namedview>
+  <defs
+     id="defs1">
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect126"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,1,1,0,0,0,1 @ F,0,0,1,0,2.9015773,0,1 @ F,0,0,1,0,2.9042436,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect124"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,4.0068516,0,1 @ F,0,0,1,0,2.3248419,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect122"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,3.1466014,0,1 @ F,0,0,1,0,2.5831576,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect120"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,3.1622223,0,1 @ F,0,0,1,0,2.4539997,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect118"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,1,1,0,0,0,1 @ F,0,0,1,0,2.9963802,0,1 @ F,0,0,1,0,3.8747364,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect77"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,1,1,0,0,0,1 @ F,0,0,1,0,2.9015773,0,1 @ F,0,0,1,0,2.9042436,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect75"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,4.0068516,0,1 @ F,0,0,1,0,2.3248419,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect73"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,3.1466014,0,1 @ F,0,0,1,0,2.5831576,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect71"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,3.1622223,0,1 @ F,0,0,1,0,2.4539997,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect69"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,1,1,0,0,0,1 @ F,0,0,1,0,2.9963802,0,1 @ F,0,0,1,0,3.8747364,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <marker
+       style="overflow:visible"
+       id="Dot"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Dot"
+       markerWidth="1"
+       markerHeight="1"
+       viewBox="0 0 1 1"
+       inkscape:isstock="true"
+       inkscape:collect="always"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="scale(0.5)"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:none"
+         d="M 5,0 C 5,2.76 2.76,5 0,5 -2.76,5 -5,2.76 -5,0 c 0,-2.76 2.3,-5 5,-5 2.76,0 5,2.24 5,5 z"
+         sodipodi:nodetypes="sssss"
+         id="path17" />
+    </marker>
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect38"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,1,1,0,0,0,1 @ F,0,0,1,0,2.9015773,0,1 @ F,0,0,1,0,2.9042436,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect31"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,3.1622223,0,1 @ F,0,0,1,0,2.4539997,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect30"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,3.1466014,0,1 @ F,0,0,1,0,2.5831576,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect29"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,0,1,0,0,0,1 @ F,0,0,1,0,4.0068516,0,1 @ F,0,0,1,0,2.3248419,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <inkscape:path-effect
+       effect="fillet_chamfer"
+       id="path-effect27"
+       is_visible="true"
+       lpeversion="1"
+       nodesatellites_param="F,0,1,1,0,0,0,1 @ F,0,0,1,0,2.9963802,0,1 @ F,0,0,1,0,3.8747364,0,1 @ F,0,0,1,0,0,0,1"
+       radius="0"
+       unit="px"
+       method="auto"
+       mode="F"
+       chamfer_steps="1"
+       flexible="false"
+       use_knot_distance="true"
+       apply_no_radius="true"
+       apply_with_radius="true"
+       only_selected="false"
+       hide_knots="false" />
+    <marker
+       style="overflow:visible"
+       id="RoundedArrow"
+       refX="0"
+       refY="0"
+       orient="auto-start-reverse"
+       inkscape:stockid="Rounded arrow"
+       markerWidth="1"
+       markerHeight="1"
+       viewBox="0 0 1 1"
+       inkscape:isstock="true"
+       inkscape:collect="always"
+       preserveAspectRatio="xMidYMid">
+      <path
+         transform="scale(0.7)"
+         d="m -0.21114562,-4.1055728 6.42229122,3.21114561 a 1,1 90 0 1 0,1.78885438 L -0.21114562,4.1055728 A 1.236068,1.236068 31.717474 0 1 -2,3 v -6 a 1.236068,1.236068 148.28253 0 1 1.78885438,-1.1055728 z"
+         style="fill:context-stroke;fill-rule:evenodd;stroke:none"
+         id="path8" />
+    </marker>
+  </defs>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1">
+    <rect
+       style="fill:#ececec;stroke:#666666;stroke-width:0.499999;stroke-dasharray:none"
+       id="rect81"
+       width="83.048515"
+       height="39.561104"
+       x="123.8624"
+       y="2.3281696"
+       ry="1.9105021" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:7.33795px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+       x="3.8406572"
+       y="20.063766"
+       id="text1"><tspan
+         sodipodi:role="line"
+         id="tspan1"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+         x="3.8406572"
+         y="20.063766">Physical Variable</tspan></text>
+    <g
+       id="g7"
+       transform="matrix(0.52297582,0,0,0.52297582,-6.2257545,21.478907)">
+      <rect
+         style="fill:#e6e6e6;stroke:#000000;stroke-width:0.264583"
+         id="rect1"
+         width="52.239849"
+         height="36.348709"
+         x="38.13818"
+         y="26.553293"
+         ry="3.6531365" />
+      <text
+         xml:space="preserve"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:9.9582px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif, Medium';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:center;writing-mode:lr-tb;direction:ltr;text-anchor:middle;white-space:pre;inline-size:45.377;display:inline;fill:#1a1a1a;stroke:none;stroke-width:0.829849"
+         x="123.13419"
+         y="46.976418"
+         id="text2"
+         transform="matrix(1.0936786,0,0,1.0936786,-70.570223,-9.7364997)"><tspan
+           x="123.13419"
+           y="46.976418"
+           id="tspan2">STL<tspan
+   y="46.976418"
+   id="tspan30"> </tspan></tspan><tspan
+           x="123.13419"
+           y="59.424169"
+           id="tspan31">Checker</tspan></text>
+    </g>
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 27.37968,22.183994 v 9.680812"
+       id="path7" />
+    <g
+       id="g12"
+       transform="matrix(0.25685083,0,0,0.25685083,112.9774,20.200074)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="path9"
+         cx="69.443932"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 77.660587,-48.069316 c -0.32647,-0.326474 -0.85216,-0.326475 -1.17864,-4e-6 l -7.03808,7.03809 -7.0381,-7.038089 c -0.32647,-0.326473 -0.85191,-0.326224 -1.17838,2.46e-4 l -1.36367,1.363667 c -0.32647,0.326471 -0.32672,0.851919 -2.4e-4,1.178392 l 7.03808,7.038087 -7.03784,7.037843 c -0.32647,0.32647 -0.32647,0.852167 0,1.17864 l 1.36367,1.363668 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 7.03784,-7.037841 7.03784,7.037843 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 1.36367,-1.363666 c 0.32647,-0.326472 0.32646,-0.852168 0,-1.178636 l -7.03785,-7.037843 7.03809,-7.03809 c 0.32647,-0.326471 0.32647,-0.852168 0,-1.178636 z"
+         id="path10"
+         style="stroke-width:0.678775" />
+    </g>
+    <g
+       id="g13"
+       transform="matrix(0.25685083,0,0,0.25685083,103.21896,30.550459)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="circle10"
+         cx="107.43655"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 106.47233,-51.073378 c -0.4617,-3e-6 -0.83342,0.371715 -0.83342,0.833422 v 9.953355 l -9.953373,8e-6 c -0.4617,-3e-6 -0.83306,0.371716 -0.83306,0.833414 v 1.928518 c 0,0.461699 0.37137,0.833424 0.83308,0.833419 l 9.953353,5e-6 v 9.953011 c 0,0.461698 0.37172,0.833422 0.83342,0.833424 l 1.92852,-1e-6 c 0.4617,-10e-7 0.83343,-0.371727 0.83343,-0.833426 v -9.953009 l 9.95301,2e-6 c 0.46169,-2e-6 0.83342,-0.371727 0.83342,-0.833426 v -1.928518 c 0,-0.461699 -0.37173,-0.833416 -0.83342,-0.833421 l -9.95302,5e-6 v -9.953363 c 0,-0.461699 -0.37172,-0.833423 -0.83342,-0.833421 z"
+         id="path11"
+         style="stroke-width:0.678775" />
+    </g>
+    <g
+       id="g14"
+       transform="matrix(0.25685083,0,0,0.25685083,93.067621,41.03354)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="circle11"
+         cx="146.95886"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 145.99464,-51.073378 c -0.4617,-3e-6 -0.83342,0.371715 -0.83342,0.833422 v 9.953355 l -9.95337,8e-6 c -0.4617,-3e-6 -0.83306,0.371716 -0.83306,0.833414 v 1.928518 c 0,0.461699 0.37137,0.833424 0.83308,0.833419 l 9.95335,5e-6 v 9.953011 c 0,0.461698 0.37172,0.833422 0.83342,0.833424 l 1.92852,-1e-6 c 0.4617,-10e-7 0.83343,-0.371727 0.83343,-0.833426 v -9.953009 l 9.95301,2e-6 c 0.46169,-2e-6 0.83342,-0.371727 0.83342,-0.833426 v -1.928518 c 0,-0.461699 -0.37173,-0.833416 -0.83342,-0.833421 l -9.95302,5e-6 v -9.953363 c 0,-0.461699 -0.37172,-0.833423 -0.83342,-0.833421 z"
+         id="path12"
+         style="stroke-width:0.678775" />
+      <rect
+         style="fill:#000000;stroke:none;stroke-width:1;stroke-dasharray:none"
+         id="rect12"
+         width="30.868732"
+         height="3.0997891"
+         x="131.52449"
+         y="-20.536102"
+         ry="1.2277884" />
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:7.33795px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+       x="138.69669"
+       y="12.779222"
+       id="text14"><tspan
+         sodipodi:role="line"
+         id="tspan14"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+         x="138.69669"
+         y="12.779222">Discount </tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:7.33795px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+       x="138.69669"
+       y="33.534252"
+       id="text15"><tspan
+         sodipodi:role="line"
+         id="tspan15"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+         x="138.69669"
+         y="33.534252">Average Fusion </tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:7.33795px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+       x="138.69669"
+       y="23.170813"
+       id="text16"><tspan
+         sodipodi:role="line"
+         id="tspan16"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+         x="138.69669"
+         y="23.170813">Cumulative Fusion</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:7.33795px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+       x="14.059326"
+       y="93.153305"
+       id="text17"><tspan
+         sodipodi:role="line"
+         id="tspan17"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+         x="14.059326"
+         y="93.153305">Car 2</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:7.33795px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+       x="14.059326"
+       y="102.711"
+       id="text18"><tspan
+         sodipodi:role="line"
+         id="tspan18"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+         x="14.059326"
+         y="102.711">Car 3</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:7.33795px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';text-align:start;writing-mode:lr-tb;direction:ltr;text-anchor:start;fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+       x="14.059326"
+       y="112.26868"
+       id="text19"><tspan
+         sodipodi:role="line"
+         id="tspan19"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif Medium';fill:#1a1a1a;stroke:none;stroke-width:0.611495"
+         x="14.059326"
+         y="112.26868">Car 4</tspan></text>
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="M 33.754743,90.647006 H 46.922818"
+       id="path19"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="M 33.754743,100.2047 H 46.922818"
+       id="path21"
+       sodipodi:nodetypes="cc" />
+    <g
+       id="g22"
+       transform="matrix(0.25685083,0,0,0.25685083,40.003198,100.53295)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="circle21"
+         cx="69.443932"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 77.660587,-48.069316 c -0.32647,-0.326474 -0.85216,-0.326475 -1.17864,-4e-6 l -7.03808,7.03809 -7.0381,-7.038089 c -0.32647,-0.326473 -0.85191,-0.326224 -1.17838,2.46e-4 l -1.36367,1.363667 c -0.32647,0.326471 -0.32672,0.851919 -2.4e-4,1.178392 l 7.03808,7.038087 -7.03784,7.037843 c -0.32647,0.32647 -0.32647,0.852167 0,1.17864 l 1.36367,1.363668 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 7.03784,-7.037841 7.03784,7.037843 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 1.36367,-1.363666 c 0.32647,-0.326472 0.32646,-0.852168 0,-1.178636 l -7.03785,-7.037843 7.03809,-7.03809 c 0.32647,-0.326471 0.32647,-0.852168 0,-1.178636 z"
+         id="path22"
+         style="stroke-width:0.678775" />
+    </g>
+    <g
+       id="g24"
+       transform="matrix(0.25685083,0,0,0.25685083,40.003198,110.09064)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="circle23"
+         cx="69.443932"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 77.660587,-48.069316 c -0.32647,-0.326474 -0.85216,-0.326475 -1.17864,-4e-6 l -7.03808,7.03809 -7.0381,-7.038089 c -0.32647,-0.326473 -0.85191,-0.326224 -1.17838,2.46e-4 l -1.36367,1.363667 c -0.32647,0.326471 -0.32672,0.851919 -2.4e-4,1.178392 l 7.03808,7.038087 -7.03784,7.037843 c -0.32647,0.32647 -0.32647,0.852167 0,1.17864 l 1.36367,1.363668 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 7.03784,-7.037841 7.03784,7.037843 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 1.36367,-1.363666 c 0.32647,-0.326472 0.32646,-0.852168 0,-1.178636 l -7.03785,-7.037843 7.03809,-7.03809 c 0.32647,-0.326471 0.32647,-0.852168 0,-1.178636 z"
+         id="path24"
+         style="stroke-width:0.678775" />
+    </g>
+    <g
+       id="g23"
+       transform="matrix(0.25685083,0,0,0.25685083,40.003198,119.64832)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="circle22"
+         cx="69.443932"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 77.660587,-48.069316 c -0.32647,-0.326474 -0.85216,-0.326475 -1.17864,-4e-6 l -7.03808,7.03809 -7.0381,-7.038089 c -0.32647,-0.326473 -0.85191,-0.326224 -1.17838,2.46e-4 l -1.36367,1.363667 c -0.32647,0.326471 -0.32672,0.851919 -2.4e-4,1.178392 l 7.03808,7.038087 -7.03784,7.037843 c -0.32647,0.32647 -0.32647,0.852167 0,1.17864 l 1.36367,1.363668 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 7.03784,-7.037841 7.03784,7.037843 c 0.32647,0.326468 0.85217,0.326469 1.17864,-2e-6 l 1.36367,-1.363666 c 0.32647,-0.326472 0.32646,-0.852168 0,-1.178636 l -7.03785,-7.037843 7.03809,-7.03809 c 0.32647,-0.326471 0.32647,-0.852168 0,-1.178636 z"
+         id="path23"
+         style="stroke-width:0.678775" />
+    </g>
+    <g
+       id="g25"
+       transform="matrix(0.3671597,0,0,0.3671597,53.331705,95.608454)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="circle24"
+         cx="146.95886"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 145.99464,-51.073378 c -0.4617,-3e-6 -0.83342,0.371715 -0.83342,0.833422 v 9.953355 l -9.95337,8e-6 c -0.4617,-3e-6 -0.83306,0.371716 -0.83306,0.833414 v 1.928518 c 0,0.461699 0.37137,0.833424 0.83308,0.833419 l 9.95335,5e-6 v 9.953011 c 0,0.461698 0.37172,0.833422 0.83342,0.833424 l 1.92852,-1e-6 c 0.4617,-10e-7 0.83343,-0.371727 0.83343,-0.833426 v -9.953009 l 9.95301,2e-6 c 0.46169,-2e-6 0.83342,-0.371727 0.83342,-0.833426 v -1.928518 c 0,-0.461699 -0.37173,-0.833416 -0.83342,-0.833421 l -9.95302,5e-6 v -9.953363 c 0,-0.461699 -0.37172,-0.833423 -0.83342,-0.833421 z"
+         id="path25"
+         style="stroke-width:0.678775" />
+      <rect
+         style="fill:#000000;stroke:none;stroke-width:1;stroke-dasharray:none"
+         id="rect25"
+         width="30.868732"
+         height="3.0997891"
+         x="131.52449"
+         y="-20.536102"
+         ry="1.2277884" />
+    </g>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 65.755216,56.700308 0,2.538774 a 5.9610605,5.9610605 63.313203 0 0 2.404723,4.784005 L 82.65119,74.795605 a 11.707071,11.707071 18.313203 0 0 6.984377,2.311648 h 7.103684"
+       id="path26"
+       inkscape:path-effect="#path-effect27"
+       inkscape:original-d="m 65.755216,56.700308 v 5.535154 l 20.005615,14.871791 h 10.97842"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 63.933149,90.119909 h 8.943687 a 7.5856931,7.5856931 157.37037 0 0 5.38811,-2.246124 l 5.768515,-5.820954 a 5.8867741,5.8867741 157.37037 0 1 4.18137,-1.743074 h 8.52442"
+       id="path27"
+       sodipodi:nodetypes="cccc"
+       inkscape:path-effect="#path-effect31"
+       inkscape:original-d="m 63.933149,90.119909 h 12.105909 l 9.721773,-9.810152 h 10.97842" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 63.933149,99.677592 h 8.959308 a 5.5920586,5.5920586 150.63393 0 0 4.779812,-2.689558 L 84.42007,85.875816 a 4.5907209,4.5907209 150.63393 0 1 3.923919,-2.207954 h 8.395262"
+       id="path28"
+       sodipodi:nodetypes="cccc"
+       inkscape:path-effect="#path-effect30"
+       inkscape:original-d="m 63.933149,99.677592 h 12.105909 l 9.721773,-16.00973 h 10.97842" />
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 63.933149,109.23527 h 8.099057 a 6.156811,6.156811 146.94393 0 0 5.629418,-3.66362 l 7.157767,-16.161672 a 3.5722841,3.5722841 146.94393 0 1 3.266282,-2.125695 h 8.653578"
+       id="path29"
+       sodipodi:nodetypes="cccc"
+       inkscape:path-effect="#path-effect29"
+       inkscape:original-d="m 63.933149,109.23527 h 12.105909 l 9.721773,-21.950987 h 10.97842" />
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="M 33.754743,90.647006 H 46.922818"
+       id="path31"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="M 33.754743,109.76238 H 46.922818"
+       id="path33"
+       sodipodi:nodetypes="cc" />
+    <g
+       id="g33"
+       transform="translate(-3.8101584,7.4344554)">
+      <rect
+         style="fill:#e6e6e6;stroke:#000000;stroke-width:0.138371"
+         id="rect33"
+         width="34.940495"
+         height="19.009499"
+         x="51.845127"
+         y="27.931183"
+         ry="1.9105021" />
+      <text
+         xml:space="preserve"
+         style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:9.9582px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif, Medium';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:center;writing-mode:lr-tb;direction:ltr;text-anchor:middle;white-space:pre;inline-size:72.9262;display:inline;fill:#1a1a1a;stroke:none;stroke-width:0.829849"
+         x="123.13419"
+         y="46.976418"
+         id="text33"
+         transform="matrix(0.49881491,0,0,0.49881491,7.8114529,12.140657)"><tspan
+           x="123.13419"
+           y="46.976418"
+           id="tspan32">Evidence-Based<tspan
+   y="46.976418"
+   id="tspan33"> </tspan></tspan><tspan
+           x="123.13419"
+           y="59.424169"
+           id="tspan34">Opinion</tspan></text>
+    </g>
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 41.801098,44.870385 h 3.105166"
+       id="path34"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 117.22891,81.476811 h 13.16808"
+       id="path35"
+       sodipodi:nodetypes="cc" />
+    <g
+       id="g36"
+       transform="matrix(0.25685083,0,0,0.25685083,112.15935,91.362755)">
+      <circle
+         style="fill:none;stroke:#1a1a1a;stroke-width:1;stroke-dasharray:none"
+         id="circle35"
+         cx="107.43655"
+         cy="-38.489048"
+         r="16.532209" />
+      <path
+         d="m 106.47233,-51.073378 c -0.4617,-3e-6 -0.83342,0.371715 -0.83342,0.833422 v 9.953355 l -9.953373,8e-6 c -0.4617,-3e-6 -0.83306,0.371716 -0.83306,0.833414 v 1.928518 c 0,0.461699 0.37137,0.833424 0.83308,0.833419 l 9.953353,5e-6 v 9.953011 c 0,0.461698 0.37172,0.833422 0.83342,0.833424 l 1.92852,-1e-6 c 0.4617,-10e-7 0.83343,-0.371727 0.83343,-0.833426 v -9.953009 l 9.95301,2e-6 c 0.46169,-2e-6 0.83342,-0.371727 0.83342,-0.833426 v -1.928518 c 0,-0.461699 -0.37173,-0.833416 -0.83342,-0.833421 l -9.95302,5e-6 v -9.953363 c 0,-0.461699 -0.37172,-0.833423 -0.83342,-0.833421 z"
+         id="path36"
+         style="stroke-width:0.678775" />
+    </g>
+    <path
+       style="fill:#1a1a1a;stroke:#1a1a1a;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="m 148.13189,81.476811 h 13.16808"
+       id="path37"
+       sodipodi:nodetypes="cc" />
+    <rect
+       style="fill:#e6e6e6;stroke:#000000;stroke-width:0.138371"
+       id="rect37"
+       width="34.940495"
+       height="19.009499"
+       x="167.73917"
+       y="71.972061"
+       ry="1.9105021" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:9.9582px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif, Medium';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:center;writing-mode:lr-tb;direction:ltr;text-anchor:middle;white-space:pre;inline-size:72.9262;display:inline;fill:#1a1a1a;stroke:none;stroke-width:0.829849"
+       x="123.13419"
+       y="46.976418"
+       id="text37"
+       transform="matrix(0.49881491,0,0,0.49881491,123.70549,56.181536)"><tspan
+         x="123.13419"
+         y="46.976418"
+         id="tspan35">Global Long<tspan
+   y="46.976418"
+   id="tspan36"> </tspan></tspan><tspan
+         x="123.13419"
+         y="59.424169"
+         id="tspan37">Term Opinion</tspan></text>
+    <path
+       style="fill:none;stroke:#000000;stroke-width:0.499999;stroke-dasharray:none;marker-end:url(#RoundedArrow)"
+       d="M 69.315373,25.830628 V 17.858852 A 2.9015773,2.9015773 45 0 0 66.413796,14.957275 H 26.76473 a 2.9042436,2.9042436 135 0 0 -2.904244,2.904244 v 11.525646"
+       id="path38"
+       inkscape:path-effect="#path-effect38"
+       inkscape:original-d="M 69.315373,25.830628 V 14.957275 H 23.860486 v 14.42989"
+       sodipodi:nodetypes="cccc"
+       transform="translate(115.89404,44.040879)" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:11.3157px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif, Medium';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:center;writing-mode:lr-tb;direction:ltr;text-anchor:middle;white-space:pre;inline-size:72.9262;display:inline;fill:#1a1a1a;stroke:none;stroke-width:0.829849"
+       x="123.13419"
+       y="46.976418"
+       id="text38"
+       transform="matrix(0.49881491,0,0,0.49881491,62.35026,85.279968)"><tspan
+         x="123.13419"
+         y="46.976418"
+         id="tspan38">Global Short<tspan
+   y="46.976418"
+   id="tspan39"> </tspan></tspan><tspan
+         x="123.13419"
+         y="61.121039"
+         id="tspan40">Term Opinion</tspan></text>
+    <path
+       style="fill:#1a1a1a;stroke:#999999;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#Dot)"
+       d="M 123.81295,102.49131 V 81.476811"
+       id="path39"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:#1a1a1a;stroke:#999999;stroke-width:0.5;stroke-dasharray:none;marker-end:url(#Dot)"
+       d="M 92.194265,60.151154 75.405564,69.409346"
+       id="path40"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:11.3157px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif, Medium';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:center;writing-mode:lr-tb;direction:ltr;text-anchor:middle;white-space:pre;inline-size:72.9262;display:inline;fill:#1a1a1a;stroke:none;stroke-width:0.829849"
+       x="123.13419"
+       y="46.976418"
+       id="text40"
+       transform="matrix(0.49881491,0,0,0.49881491,43.47519,31.120787)"><tspan
+         x="123.13419"
+         y="46.976418"
+         id="tspan41">Direct<tspan
+   y="46.976418"
+   id="tspan42"> </tspan></tspan><tspan
+         x="123.13419"
+         y="61.121039"
+         id="tspan43">Opinion</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:11.3157px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif, Medium';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:center;writing-mode:lr-tb;direction:ltr;text-anchor:middle;white-space:pre;inline-size:72.9262;display:inline;fill:#1a1a1a;stroke:none;stroke-width:0.829849"
+       x="123.13419"
+       y="46.976418"
+       id="text86"
+       transform="matrix(0.49881491,0,0,0.49881491,8.6557388,100.56572)"><tspan
+         x="123.13419"
+         y="46.976418"
+         id="tspan44">Discounted<tspan
+   y="46.976418"
+   id="tspan45"> </tspan></tspan><tspan
+         x="123.13419"
+         y="61.121039"
+         id="tspan46">Opinions</tspan></text>
+    <path
+       style="fill:#1a1a1a;stroke:#999999;stroke-width:0.5;stroke-dasharray:none;marker-mid:url(#Dot);marker-end:url(#Dot)"
+       d="M 69.502834,119.31098 V 109.23527 99.677592 90.119909"
+       id="path86"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:#1a1a1a;stroke:#999999;stroke-width:0.5;stroke-dasharray:none;marker-mid:url(#Dot);marker-end:url(#Dot)"
+       d="m 40.313153,80.609423 v 10.07571 9.557677 9.55768"
+       id="path87"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:500;font-stretch:normal;font-size:11.3157px;font-family:'CMU Serif';-inkscape-font-specification:'CMU Serif, Medium';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:center;writing-mode:lr-tb;direction:ltr;text-anchor:middle;white-space:pre;inline-size:72.9262;display:inline;fill:#1a1a1a;stroke:none;stroke-width:0.829849"
+       x="123.13419"
+       y="46.976418"
+       id="text87"
+       transform="matrix(0.49881491,0,0,0.49881491,-21.16409,45.779683)"><tspan
+         x="123.13419"
+         y="46.976418"
+         id="tspan47">Indirect<tspan
+   y="46.976418"
+   id="tspan48"> </tspan></tspan><tspan
+         x="123.13419"
+         y="61.121039"
+         id="tspan49">Opinions</tspan></text>
+  </g>
+</svg>