Volatile memory forensics for the Robot Operating System  V ́ ıctor Mayoral Vilches ,   Laura Alzola Kirschgens ,   Endika Gil-Uriarte ,   Alejandro Hern ́ andez  ALIAS ROBOTICS, Calle Venta de la Estrella 6, Pab 110 01006 Vitoria-Gasteiz,  ́ Alava, Spain  Bernhard Dieber  JOANNEUM RESEARCH Institute for Robotics and Mechatronics Lakeside B08 9020 Klagenfurt, Austria  Abstract  The increasing impact of robotics on industry and on society will unavoidably lead to the involvement of robots in inci- dents and mishaps. In such cases, forensic analyses are key techniques to provide useful evidence on what happened, and try to prevent future incidents. This article discusses volatile memory forensics for the Robot Operating System (ROS). The authors start by providing a general overview of foren- sic techniques in robotics and then present a robotics-specific Volatility plugin named   linux rosnode , packaged within the  ros volatility   project and aimed to extract evidence from robot’s volatile memory. They demonstrate how this plugin can be used to detect a specific attack pattern on ROS, where a publisher node is unregistered externally, leading to de- nial of service and disruption of robotic behaviors. Step-by- step, common practices are introduced for performing foren- sic analysis and several techniques to capture memory are described. The authors finalize by introducing some future remarks while providing references to reproduce their work.  1   Introduction  As robots become widespread and used in a variety of dif- ferent applications, it is expected that malicious actors will start compromising robotic systems for their own purposes. Potential misuse of robots may range from privacy invasion by unauthorized remote access to sensors (like the camera of your robot at home) up to causing damage or harm to the robot’s environment or persons in its vicinity. In an attempt to diagnose and prevent robot-aided crime, robot forensics proposes a number of scientific tests and methods to obtain, preserve and document evidence from robot-related crimes. Robot forensics are closely connected to computer forensics as a subgroup of digital forensics, namely summed up as Digital Forensic Incident Response competences (DFIR). This entails the interaction of crime, evidence, science and law.   According to Abeykoon and Feng[1], the field of computer forensics is young and was initiated around 1970 in the United States, in response to the requirement for more extensive access to solve cyber-criminal activities related to protocols in a computer.   Within the digital forensics community, there are different areas of interest.   Of most relevance are:   a) non-volatile memory forensics,   which includes hard drives and storage peripherals, b) network forensics and c) volatile (RAM) memory forensics. For the purpose of robotics, the authors classify these areas in two subgroups: • Memory forensics • Networking forensics In this article, the authors focus on robot memory forensics that could become the stepping stone towards the creation of future Robot-specific Forensics and Incident Response (RFIR)   teams.   In   particular,   volatile   (RAM)   memory forensics is studied for its interest in robotics. The goal is to perform an online analysis of a robot’s memory to detect potential manipulations in the running system. RAM forensics aims to use memory management structures in computers such as arrays, bitmaps, records, linked lists, hash tables, trees, etc, to extract files or other information resident in a computer’s physical memory.   These files can later be used to prove that a crime has transpired, or to trace how it came to pass.   In robotics, it is relevant to note that RAM typically presents all the recent infor- mation that runs across all devices of the robotic system. This becomes specially interesting given the popularity of distributed architectures in robotics.   Regardless of the availability of non-volatile memory, most robot components, as participants of the robot network, may contain relevant information in their RAM memory. Specially, most robots have a dedicated component for computation or cognition. Such   component   is   in   charge   of   concentrating   recent samples from sensors and actuators to reason and react accordingly.   During this study, the authors will focus on  arXiv:1812.09492v1 [cs.CR] 22 Dec 2018
such a component, namely on the cognition device of the robot. Moreover, the focus will be on the study of the Robot Operating System (ROS)[2], which to many is the most popular framework for robot application development. Besides   ROS,   the   authors   also   restrict   themselves   to the study of forensics in Linux-based robotic systems. The rationale behind this assumption is twofold.   First, ROS was traditionally only supported in Linux, which made the community grow in that direction.   Nowadays, most ROS robotic systems are powered by Linux or by a POSIX- compliant Unix variant. Second, a growing number of robot components run embedded Linux, in which memory-only file systems are used. Such artifacts are lost when the device is powered down. Thus, as pointed out by Ligh et al. [3], in many cases, preserving RAM is the best (and sometimes the only) method to determine which files an attacker accesses. The sections below are structured as follows:   section 2 provides an overview of prior art in the area of robot forensics and particularly, robot memory forensics. Section 3 discusses how to perform a memory forensics analysis in ROS, including memory acquisition, tools, and presenting a walk-through on several use cases.   Finally, section 4 presents the conclusions and future work.   In addition, Appendix A clarifies the differences between forensics and reversing.  2   Previous work  There are very few studies that aim to perform forensic research in robots.   However, as they are digital systems, much of the existing literature applies to them too. Within previous work, a large share of attention has been paid to analyze non-volatile media such as hard drives or storage peripherals,   also present in robots.   More recently,   the rise of networks has created an interest in the study of network-based   evidence.   Both   of   these   subjects   have existing, extensive bodies of knowledge, as exemplified by Luttgens et al.[4] and Cichonski et al.[5]. This is not the case of RAM memory.   Few studies fo- cus on volatile memory forensics and even less are relevant or applicable to robotics.   Some of the most interesting include the talk given by Mariusz Burdach at Black Hat 2016[6], the popular Android’s memory acquisition and analysis[7] or [3], where a comprehensive discussion on forensic techniques for volatile memory is held for different operating systems. A recent study on memory forensics for ROS was conducted by Abeykoon et al.[1], where the authors claim they   present the first methodology and toolset for acquisition and deep analysis of volatile physical memory from robot operating system devices . This article presents certain information on a somewhat interesting manner, but lacks on formal methods, and the content presented is not useful for the expert reader. Within the text, the Robot Operating System is presented as a relatively new concept, although ROS was launched first in 2007.   At the time of writing, the commonly cited ROS article, published in 2009, has received about 4959 citations. The ROS community has spread across countries and events dedicated to ROS are appearing in different geographical areas. Regardless of certain discrepancies with the understanding of ROS, Abeykoon et al. provide a nice introduction to the field of forensics and make use of popular forensic tools such as Volatility[8] or LiME[9]. The authors, however, do not present any novel contribution that justi- fies their claims, nor any description to reproduce their work. In   an   attempt   to   provide   a   foundational   path   for   the growth of robot forensics, and specifically aimed at volatile memory, the content below presents a study on ROS volatile memory forensics. The authors introduce common practices for performing forensic analysis in robots powered by ROS and describe several techniques to capture memory.   They discuss the tools employed, introduce their contributions, and explain how to use them through a study case that provides a walk-through on the forensics of a ROS system. To finalize, the authors introduce some remarks and insights for future research and provide references to reproduce their work.  3   ROS volatile memory forensics 3.1   Volatile memory acquisition in robots  As pointed out before, several techniques from traditional digital forensics will be useful for robots.   Among them, memory acquisition for robots can be performed in a simi- lar manner. The following subsections will describe some of the most popular techniques applicable to robots:  3.1.1   Using   /dev/mem /dev/mem   provides access to the physical memory of a run- ning system. According to Ligh et al.[3],   /dev/mem   was the most popular interface for memory acquisition before being disabled in most Linux distributions for security reasons. Currently, its access remains restricted[10] in popular distri- butions like Ubuntu through the   CONFIG STRICT DEVMEM  kernel option. Still, with the right privileges, a forensics analyst should be able to get the right level of permission. Unfortunately, this interface only allows to access the first 896MB of RAM 2
memory with commands like the ones in Listing 1.   The limitation of this interface gave birth to other methods.  1   sudo dd if=/dev/mem of=/home/vagrant/robot.dd  2   bs=1MB count=10  Listing 1: Command line to capture volatile memory with  /dev/mem  3.1.2   Using   ptrace ptrace   is the userland debugging interface that Linux provides and, according to [3], it is not suitable for robust memory acquisition.   It can acquire pages from running processes without any changes required in the kernel. This makes the process of acquiring memory less aggressive and simplified in certain robots.   However the information acquired keeps solely restricted to process-related pages. An   interesting   tool   to   capture   memory   in   this   manner is   https://github.com/citypw/lcamtuf-memfetch . Similar to what is described in [3], this repository offers an applications that, when compiled and executed, reads the starting and ending addresses of process’ memory ranges from   /proc/<pid>/maps   and then uses   ptrace   to dump each page to disk. The previous two methods were widely used on 32-bit systems, yet with the growth of 64-bit devices, new acquisi- tion methods appeared that made use of kernel modules to access the complete range of RAM memory. The following two are, as of today, the most popular in the Linux world.  3.1.3   Using   /dev/fmem /dev/fmem   was created as an extension of   /dev/mem . The character device appears by loading a kernel driver and it exports physical memory for other programs to access while providing a number of advantages as described at [3]. Listing 2 shows how to install the character device and 3, how to use it to acquire memory.  1   git clone https://github.com/NateBrune/fmem  2   cd fmem && make  3   sudo ./run.sh  Listing 2: Installing   /dev/fmem   character device for mem- ory acquisition  1   sudo dd if=/dev/fmem of=memory.dump  2   bs=1MB count=1000  Listing 3: Command line to capture volatile memory with  /dev/fmem  3.1.4   Using the   Li nux   M emory   E xtractor (LiME)  LiME is often presented[3] as the latest Linux memory acquisition tool.   It is operated by loading a kernel driver that,   instead of creating a userland accessible character device (like   /dev/fmem   above), fetches the memory from the kernelspace. This enhances the accuracy of the resulting samples due to the removal of context switches between kernel and user spaces for transferring data. LiME   allows   to   capture   memory   in   different   formats. Listing 4 shows how to install LiME in the   $ HOME   directory, 5 how to use it and 6 how to remove the kernel module to cleanup after the memory capture.   LiME will be the tool used throughout the analysis.–  1   cd $HOME && git clone https://github.com/504ensicsLabs/LiME  2   cd $HOME/LiME/src && make  3   cd $HOME/LiME/src && cp lime-*.ko lime.ko  4   cd $HOME/LiME/src && sudo mv lime.ko /lib/modules/  Listing 4: Installing LiME in the   $ HOME   directory for mem- ory acquisition  1   sudo insmod /lib/modules/lime.ko  2   "path=/home/vagrant/robot.lime  3   format=lime"  Listing 5: Command line to capture volatile memory with LiME through the kernel module  3.2   Volatility and the   ros volatility   plugins  The Volatility framework [8] is an open collection of tools for the extraction of digital artifacts from volatile memory (RAM) samples.   It is written in Python, licensed under GPLv2 and provides a wide variety of algorithms that run in Linux, Mac OS or Windows. The framework consists of several subsystems that work together to provide a robust set of features. Among these subsystems is the   plugin system . 3
1   sudo rmmod /lib/modules/lime.ko  Listing 6: Command line to remove LiME’s kernel module Plugins allow you to extend the Volatility framework with new capabilities.   For example, an address space plugin could introduce support for operating systems that run on new CPU chipsets.   Volatility is indeed a fantastic tool. However,   currently and according to its README, its support in Linux is limited, and only kernels up to 3.6, which imposes certain limitations for robots running modern kernels. The authors will be using Volatility and extend it with a new set of plugins named   ros volatility 1   that have been developed to analyze the memory of ROS-related artifacts. At the time of writing   ros volatility   presents only a single plugin: •   linux rosnode :   A basic class used to fetch all ROS nodes from memory. It extends the linux pslist class to obtain all processes and filters according to those that make use of the typical ROS libraries.   In addition, it checks the sockets of each one of the nodes and verifies whether the node was or wasn’t registered in the ROS network. Additional plugins are being developed and contributed to analyze memory and determine issues in topics and other ab- stractions of the ROS ecosystem.  3.3   A Study case: Unauthenticated registra- tion/unregistration of ROS Nodes  Described by Dieber et al.[11],   the ROS Master API 2  requires no authentication capabilities to register and un- register publishers, subscribers and services.   This leads to a reported vulnerability 3   that can easily be exploited with off-the-shelf penetration testing tools, provided an attacker has access to the internal robot network.   Based on this, possible exploits range from eavesdropping via denial of service up to injection of false data. To assess the severity of the vulnerability,   the authors of this paper have used the Robot Vulnerability Scoring System (RVSS)[12] under the following assumptions: • Vectors of attack come from within the internal network of the robot. As discussed by Mayoral et al.[13], most robots separate their networking setup in two different networks: an internal one, where the software and hard- ware components operate and an external one, meant to access the robot from the outside world. This assump- tion is not entirely true, given recent discoveries[14]. Still, provided some basic security awareness and tak- ing a conservative approach, the authors assume that this vulnerability should apply only to those with access to the robot   internal   network, where the ROS Master is operating. • Attack complexity is low given the availability of off- the-shelf penetration testing tools that can exploit this flaw. • No safety implications have been considered since the vulnerability affects ROS, what can be classified as a (software) component and not a complete robot system by itself.   It should be noted, however, that a robotic system using a vulnerable ROS setup could easily cause human harm and thereby imply environmental or even human safety hazards. Following this conservative approach,   the vector of the vulnerability is   RV SS   : 1 . 0 / AV   :   IN / AC   :   L / PR   :   N / UI   :   N / Y   :  T   / S   :   U / C   :   H / I   :   N / A   :   H / H   :   N .   Altogether, and as stated by Mayoral et al., this vulnerability scores with   7.6   out of 10, which implies a   High   degree of severity according to the classification proposed. The following section will show how an attack can exploit this vulnerability and cause selected nodes to be unregistered from the robot network. ROS Master   /publisher   /listener   roschaos  Unregister publisher ”P”  Publisher ”P” unregistered, terminate connection  Publisher ”P” unregistered, terminate connection Figure 1: Sequence diagram of an unauthenticated unregis- tration attack in ROS.  3.3.1   Attacking ROS  To simulate the attack in an artificial robotic system, the authors made use of the Robotics CTF[15] public resources 4  and   constructed   an   scenario   with   a   robotic   system   as described in Figure 2.   Besides the simulated robot, the scenario also contains different robot penetration testing tools. Mainly   ROSPenTo 5   and   roschaos 6 . ROSPenTo is a .NET-based tool that allows for analyzing and manipulating a ROS-network on a very fine-grained level with a high degree of stealthiness.   Roschaos is meant for high-impact 4
Figure 2: Robot subject of the study case 1:   Unauthenticated registration/unregistration of ROS Nodes  attacks aiming at causing more damage in a single step. The application contains two nodes,   a   /publisher   node running in a process called ’talker’ and a   /listener   node running in a process with that name. Along with that, ROS starts also the roscore process, which contains the ROS master. There is also a ROS node named   /rosout   that is part of the ROS core. The attack is described in listing 7 and the resulting status in listing 8:  1   root@655447dc534c:/# rosnode list  2   /listener  3   /publisher  4   /rosout  5 6   root@655447dc534c:/# roschaos master unregister  7   node --node_name /publisher  8   Unregistering /publisher  Listing 7:   Unauthenticated unregistration attack on ROS Master API As it can be seen when introspecting the ROS Master through the   rosnode list   command, the   /publisher   node has disappeared while the process   talker   is still running (line 13 of listing 8) and consuming resources.   What happens under the hood here is that the ROS master will now notify all subscribers of the   /publisher   node that it is no longer available. The   authors   ask   themselves:   How   can   we   determine whether our system has been subject of the unauthenticated unregistration attack? How can we identify at which point our robotic system was compromised? What are the affected subsystems?   The following section will explore some of   these   questions   by   researching   the   volatile   memory landscape of the presented simulated robot.  1   root@655447dc534c:/# rosnode list  2   /listener  3   /rosout  4 5   root@655447dc534c:/# ps -e  6   PID TTY   TIME CMD  7   1 pts/0   00:00:00 launch_script.b  8   31 pts/0   00:00:00 roscore  9   42 ?   00:00:01 rosmaster  10   55 ?   00:00:01 rosout  11   72 pts/0   00:00:00 bash  12   78 pts/1   00:00:00 bash  13   90 pts/0   00:00:00 talker  14   108 pts/0   00:00:01 listener  15   174 pts/1   00:00:00 ps  Listing 8: Status after unauthenticated unregistration attack on ROS Master API  3.3.2   Forensic study  The study of this vulnerability will be conducted using the  ros volatility   plugin set.   In particular, the   linux rosnode  plugin which locates ROS nodes from memory and reports information about them. The authors will base their research on memory captures made through the LiME utility installed in their robotic system. In an untampered system, the plugin operates as follows:  1   vagrant@vagrant-ubuntu-trusty-64:~$ vol.py  2   --plugins=/vagrant/ros_volatility  3   --profile LinuxUbuntu14045x64  4   -f robot.lime linux_rosnode  5   Volatility Foundation Volatility Framework 2.6  6   rosout  7   talker  8   listener  Listing 9: Output of running the   linux rosnode   plugin be- fore the unauthenticated unregistration attack on the Master API Listing 9 shows the result of running the   linux rosnode   plu- gin on the ROS setup, prior to the exploitation of an unau- thenticated unregistration attack on the Master API. Listing 10 displays the result of running   linux rosnode   after the at- tack (described previously in Listing 7). Note that the   talker  node has been identified as unregistered. The plugin deter- mines this aspect by analyzing all the sockets available in memory for each one of the ROS nodes detected, and infers that those publishers with a socket in the same port both in 5
‘LISTEN‘ and ‘CLOSE WAIT‘ status were likely unregis- tered. The code that implements this detection is revealed at Listing 11.  1   vagrant@vagrant-ubuntu-trusty-64:~$ vol.py  2   --plugins=/vagrant/ros_volatility  3   --profile LinuxUbuntu14045x64  4   -f robot_hacked.lime linux_rosnode  5   Volatility Foundation Volatility Framework 2.6  6   rosout  7   talker (unregistered)  8   listener  Listing 10: Output of running the   linux rosnode   plugin after the unauthenticated unregistration attack on the Master API By using the   linux rosnode   plugin, a researcher is able to determine that the   talker   ROS node has been unregistered and thereby, the system, likely, compromised. A complete walk-through   on   the   forensic   study   of   this   vulnerabil- ity   is   available   at   https://github.com/vmayoral/ basic_robot_cybersecurity/tree/master/robot_ forensics/tutorial1 . The authors now know that the system has been tam- pered and the talker unregistered, but what was the cause? To answer this question, one of the default volatility plugins will be used. Results are displayed in Listing 12.   Lines 23 and 24 show that it was the   roschaos   tool what exploited the unauthenticated   unregistration   vulnerability   in   the   ROS Master.  1   # The following assumption is made for detecting  2   #   unregistered nodes:  3   #  4   #   a publisher having a socket in the same  5   #   port both in `LISTEN` and `CLOSE_WAIT`  6   #   status was likely unregistered  7   #  8   # WARNING: this assumption was validated for a simple  9   #   scenario. Further  10   # research needs to be executed to validate it in  11   # multi-topic and multi-nodes scenarios.  12   listen_ports = [] # ports with LISTEN state  13   close_wait_ports = [] # ports with CLOSE_WAIT state  14   for ents in t.netstat():  15   if ents[0] == socket.AF_INET:  16   (_, proto, saddr, sport, daddr, dport,  17   state) = ents[1]  18   if state == 'LISTEN':  19   listen_ports.append(sport)  20   elif state == 'CLOSE_WAIT':  21   close_wait_ports.append(sport)  22 23   unregistered = False  24   for p in close_wait_ports:  25   if p in listen_ports:  26   unregistered = True  Listing 11: Detection of unregistered nodes, snipped of code from   linux rosnode   plugin 6
1   vagrant@vagrant-ubuntu-trusty-64:~$ vol.py  2   --plugins=/home/vagrant/volatility-plugins/linux  3   --profile LinuxUbuntu14045x64  4   -f robot_hacked.lime linux_bash  5   1583 bash   2018-11-01 17:58:12  6   UTC+0000   rosnode list  7   1583 bash   2018-11-01 17:58:18  8   UTC+0000   roscore &  9   1583 bash   2018-11-01 17:58:28  10   UTC+0000   rosrun scenario1 talker &  11   1583 bash   2018-11-01 17:58:32  12   UTC+0000   rosrun scenario1  13   listener > /tmp/listener.txt &  14   ...  15   1583 bash   2018-11-01 18:09:19  16   UTC+0000   rosnode list  17   1583 bash   2018-11-01 18:09:33  18   UTC+0000   sudo insmod /lib/modules/lime.ko  19   "path=/home/vagrant/robot.lime format=lime"  20   1583 bash   2018-11-01 18:09:38  21   UTC+0000   sudo rmmod /lib/modules/lime.ko  22   1583 bash   2018-11-01 18:09:46  23   UTC+0000   roschaos master unregister node  24   --node_name /publisher  25   1583 bash   2018-11-01 18:09:50  26   UTC+0000   sudo insmod /lib/modules/lime.ko  27   "path=/home/vagrant/robot_hacked.lime format=lime"  Listing 12: The   linux bash   volatility plugin recovers a his- tory of commands, exploit discovered  4   Discussion and future work  In an attempt to provide a foundational path for the growth of robot forensics, and specifically, aimed at volatile memory, the authors presented the first steps towards reproducible robotic volatile memory forensic analyses with a focus on Linux and ROS, the   de facto   standard in robotics. Common practices were introduced and a walkthrough for a simulated attack was illustrated step-by-step.   Through the forensic analysis presented, the readers should be able to answer several of the proposed questions and determine the specific cause of the attack by solely looking at RAM memory. Contributions have been presented in the form of a plugin to the Volatility framework. It should be noted however that due to restrictions in the framework, only (Linux) kernels below version 3.6 are supported. Future work will address this limitation and look into more elaborated forensic stud- ies, involving more complicated attacks. Additional plugins are being developed for   ros volatility   to detect other attacks. Eventually, the authors hope that unknown robotic attack patterns could get identified.   Beyond detecting attacks, it would be of special interest the future extension of the ROS robotics framework with memory introspection tools that running side-by-side with the application, could perform real-time analyses at regular intervals to detect attacks such as the one just reported. Another   area   of   future   work   to   approach   robot   foren- sics that could serve as a natural extension of the work presented here is the use of a dedicated tamper-proof storage device to securely store the results of the analyses done at run-time (commonly called a  ̈ black box ̈ ). Recently, a con- cept and prototype for such a device especially tailored for modern robots (and their threat profile) has been presented in [16].   While currently this device needs to be specially considered within the robot application,   using   memory forensics to generate its input data would make it much easier applicable in existing robot software. No changes to a ROS application or the ROS core would be necessary, but still, meaningful forensic evidence on the robot system’s execution could be collected.  A   Robot forensics and reversing  Opposed to forensics, which focuses on recovering data to establish who committed the crime[3], reverse engineering (commonly known as reversing) is concerned with the pro- cess of extracting knowledge or design blueprints from the system[17]. As described by Eilam, reverse engineering is usually conducted to obtain missing knowledge, ideas, and design philosophy when such information is unavailable. In some cases, the information is owned by someone who is not willing to share. These two concepts are often mistaken. When transposed to robotics, we apply the following under- standing: •   Robot forensics : the process to obtain, preserve and document evidence (typically data) from robot-related crimes. •   Robot reversing   (or robot reverse engineering):   the process of extracting information about the design el- ements in a robotic system.  B   Acknowledgments  This research has been partially funded by the Basque Gov- ernment, in particular, by the Business Development Basque Agency (SPRI) through the Ekintzaile 2018 program. Spe- cial thanks to BIC Araba and the Basque Cybersecurity Cen- ter (BCSC) for their support. This work has been supported by the programme ”ICT of the Future”, managed by the Aus- trian Research Promotion Agency (FFG), under grant no. 861264. 7
C   Availability  All source code to reproduce the work presented here has been made publicly available. Further extensions will also be published into the same repositories to raise community interest. The authors of the paper encourage other security researchers to contribute with their own ideas an extensions. A walkthrough on the forensic study presented in this paper is also available from  https://github.com/vmayoral/basic_robot_ cybersecurity/tree/master/robot_exploitation/ tutorial11  additional information on the vulnerability exploited can be obtained from  https: //github.com/aliasrobotics/RVDP/issues/87  finally, the extensions to Volatility to perform forensic stud- ies can be downloaded from  https: //github.com/aliasrobotics/ros_volatility  References  [1] I. Abeykoon and X. Feng, “A forensic investigation of the robot operating system,” in   Internet of Things (iThings) and IEEE Green Computing and Commu- nications (GreenCom) and IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), 2017 IEEE International Conference on . IEEE, 2017, pp. 851–857. [2] M. Quigley, K. Conley, B. Gerkey, J. Faust, T. Foote, J. Leibs, R. Wheeler, and A. Y. Ng, “Ros: an open- source robot operating system,” in   ICRA workshop on open source software , vol. 3, no. 3.2.   Kobe, Japan, 2009, p. 5. [3] M. H. Ligh, A. Case, J. Levy, and A. Walters,   The art of memory forensics:   detecting malware and threats in windows, linux, and Mac memory .   John Wiley & Sons, 2014. [4] J. T. Luttgens, M. Pepe, and K. Mandia,   Incident re- sponse & computer forensics .   McGraw-Hill Educa- tion Group, 2014. [5] P. Cichonski, P. Millar, T. Grance, and K. Scarfone, “Computer security incident handling guide (nist sp 800-61 revision 2) 2012.” [6] M. Burdach, “Physical memory forensics,”   USA: Black Hat , 2006. [7] J. Sylve, A. Case, L. Marziale, and G. G. Richard, “Ac- quisition and analysis of volatile memory from android devices,”   Digital Investigation , vol. 8, no. 3-4, pp. 175– 184, 2012. [8] A. Walters, “The volatility framework: Volatile mem- ory artifact extraction utility framework,” 2007. [9] J. Sylve, “Lime-linux memory extractor,” in   Proceed- ings of the 7th ShmooCon conference , 2012. [10] A. Van-de Ven, “x86: introduce /dev/mem restrictions with   a   config   option.”   [Online].   Available:   https: //lwn.net/Articles/267427/ [11] B. Dieber, B. Breiling, S. Taurer, S. Kacianka, S. Rass, and P. Schartner, “Security for the robot operating sys- tem,”   Robotics and Autonomous Systems , vol. 98, pp. 192–203, 2017. [12] V. Mayoral Vilches, E. Gil-Uriarte, I. Zamalloa Ugarte, G. Olalde Mendia,   R. Izquierdo Pis ́ on,   L. Alzola Kirschgens, A. Bilbao Calvo, A. Hern ́ andez Cordero, L. Apa, and C. Cerrudo, “Towards an open standard for assessing the severity of robot security vulnerabili- ties, the Robot Vulnerability Scoring System (RVSS),”  ArXiv e-prints , Jul. 2018. [13] V. Mayoral Vilches, L. Alzola Kirschgens, A. Bil- bao Calvo, A. Hern ́ andez Cordero, R. Izquierdo Pis ́ on, D. Mayoral Vilches, A. Mu ̃ niz Rosas, G. Olalde Men- dia, L. Usategi San Juan, I. Zamalloa Ugarte, E. Gil- Uriarte, E. Tews, and A. Peter, “Introducing the robot security framework (rsf), a standardized methodology to perform security assessments in robotics,”   ArXiv e- prints , Jun. 2018. [14] N. DeMarinis, S. Tellex, V. Kemerlis, G. Konidaris, and R. Fonseca, “Scanning the internet for ros:   A view of security in robotics research,”   arXiv preprint arXiv:1808.03322 , 2018. [15] G. Olalde Mendia, L. Usategui San Juan, X. Perez Bas- caran, A. Bilbao Calvo, A. Hern ́ andez Cordero, I. Za- malloa Ugarte, A. Mu ̃ niz Rosas, D. Mayoral Vilches, U. Ayucar Carbajo, L. Alzola Kirschgens, V. Mayoral Vilches, and E. Gil-Uriarte, “Robotics CTF (RCTF), a playground for robot hacking,”   ArXiv e-prints , Oct. 2018. [16] S. Taurer, B. Dieber, and P. Schartner, “Secure data recording and bio-inspired functional integrity for in- telligent robots,” in   Proceedings of the 2018 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS 2018) , 2018. [17] E. Eilam,   Reversing:   secrets of reverse engineering . John Wiley & Sons, 2011. 8
Notes  1 https://github.com/aliasrobotics/ros_volatility  2 http://wiki.ros.org/ROS/Master_API#register. 2BAC8-unregister_methods  3 https://github.com/aliasrobotics/RVDP/issues/87  4 https://github.com/aliasrobotics/RCTF  5 https://github.com/jr-robotics/ROSPenTo  6 https://github.com/ruffsl/roschaos  9