Cyber Forensics on Internet of Things: Slicing and Dicing Raspberry Pi

Any device can now connect to the Internet, and Raspberry Pi is one of the more popular applications, enabling single-board computers to make robotics, devices, and appliances part of the Internet of Things (IoT). The low cost and customizability of Raspberry Pi makes it easily adopted and widespread. Unfortunately, the unprotected Raspberry Pi device—when connected to the Internet—also paves the way for cyber-attacks. Our ability to investigate, collect, and validate digital forensic evidence with confidence using Raspberry Pi has become important. This article discusses and presents techniques and methodologies for the investigation of timestamp variations between different Raspberry Pi ext4 filesystems (Raspbian vs. UbuntuMATE), comparing forensic evidence with that of other ext4 filesystems (i.e., Ubuntu), based on interactions within a private cloud, as well as a public cloud. Sixteen observational principles of file operations were documented to assist in our understanding of Raspberry Pi’s behavior in the cloud environments. This study contributes to IoT forensics for law enforcement in cybercrime investigations.


Introduction
Technology is constantly evolving. From the automation of mechanical tools to the introduction of computer chips for ubiquitous application, cloud computing ushers in yet another new era of technology, where the majority of computational processing, storage, and analysis can be performed in centralized locations. This change has left "thin client" workstations and mobile devices with virtually one task-interacting with humans. Meanwhile, new chipset sensor technology enables mobile devices to collect human behavioral data. The more that mobile devices interact with humans, the more behavioral and consumption data can be captured and attuned to each individual, household, community, or organization. The era of the Internet of Things (IoT) allows us to integrate sensor technology with common goods and services, and to collect and profile users' behaviors.
The ability of the Internet of Things (IoT) to interact with humans creates opportunities for digital voice assistants like Alexa 1 , Siri 2 , and Cortana 3 . Enabled by artificial intelligence (AI), natural language processing (NLP), and natural language 1 Alexa is a virtual assistant created by Amazon. 2 Siri is a virtual assistant created by Apple. 3 Cortana is a virtual assistant created by Microsoft. generation (NLG), these smart and performance-driven support systems enable technological interaction and communication with humans, incorporating the ability to understand, give/receive commands to programmable IoT devices independently, and possibly fulfill more complex needs. Let's visualize a smart bulb as an IoT device. A smart bulb can refer to a traditional bulb converted by and integrated with a chipset. By connecting the chipset-enabled light bulb to the Internet, the smart light bulb can receive commands from-and transmit data automatically to-an AI-enabled digital voice assistant like Alexa. The chipset and its Raspberry Pi (aka "Pi") motherboard provide a gateway for a traditional bulb to become an IoT device, and thus be accessible online.
Just about any traditional device can be converted by Pi to become an IoT device. The connectivity to the Internet-whether through wired or wireless mechanisms-makes these devices (e.g., robotics, wearables, smart home appliances, or embedded electronic teapots, etc.) accessible from anywhere. The feature of a single chip computer-compatible with various Linux operating systems-makes Pi a highly customizable IoT solution. Moreover, the adoption of Pi is quite cost effective. Pi provides affordable and easy customizability for technology innovators, and thus becomes an ideal substitute for expensive IoT devices, like CCTV smart cameras. As Pi enables the construction of IoT devices, any technically savvy user can now easily convert a traditional camera to a smart camera and create a complete smart home environment. Your refrigerator can now provide a shopping list before you come home from work. You can communicate with-and instruct-Alexa to report near real-time updates about your house or office, through Pi-enabled IoT devices, while you are on vacation.
As the deployment of these Pi-enabled IoT devices increases, the potential for cyber threats impacting these IoT devices also increases. Hackers can now take controls over these IoT devices through the same Internet channel we would use to connect. Moreover, these IoT devices can be controlled as cyber zombies and botnets to flood cyberinfrastructure with distributed denial-of-service attacks. Our ability to understand how the filesystems work on the Pi-enabled IoT devices is critical. This article discusses techniques and methodologies of timestamp investigation of Pi-enabled physical IoT devices and compares the timestamps of these IoT devices with other Linux-based systems in both private and public Cloud environments. More specifically, our research question is: to what extent do Raspberry Pi-enabled IoT devices differ when compared to other ext4 filesystems in the Cloud?

Related Works
To understand digital forensics and how timestamps work in the Pi, we begin with a review of literature in cloud forensics and IoT forensics.

Cloud Forensics
Cloud storage has become a necessity in information management practices, for both individuals as well as organizations. Massive user demands have created additional framework options, such as "storage as a service" (StaaS) within cloud computing architecture (Ho et al. 2018). As sensitive or critical information may be stored in the cloud, cloud storage has thus become a target that attracts both curious users and malicious hackers. Chung et al. (2012) suggested the possibility of extracting traces of evidence from activities, such as browsing, uploading, and downloading files, during the usage of cloud storage services (e.g., Amazon S3, Dropbox, and Google Docs) in the local device (e.g., Windows 2000, XP, Vista, 7, or Mac O/S), and analyzing these traces. Quick and Choo (2013b) analyzed the Dropbox cloud service and gave specific descriptions of the type of terrestrial artifacts and data remnants remaining on client devices such as Windows 7 and Apple iPhone 3G. More specifically, sufficient file references-with a broad range of the file examinations including directory listings, prefetch files, link files, thumbnails, registry, browser history, and memory captures-were concluded as being important in the overall determination of Dropbox usage on a local device. Martini and Choo (2012) proposed a cloud forensic framework; and moreover, Martini and Choo (2013) adopted and validated this framework in an ownCloud case study, and suggested that an in-depth understanding of the artifacts is required to undertake cloud storage forensics-both client and server forensics. As a result, Martini and Choo (2013) provided technical recommendations of ownCloud StaaS instances, which include metadata analysis, authentication data, cached files, browser artifacts, mobile client artifacts, as well as network data analysis. Quick and Choo (2013a) also proposed another cloud forensics analysis framework, and this framework was adopted and validated in a Google Drive study (Quick and Choo 2014). In the case of the Google Drive study, Quick and Choo (2014) provided a technique for finding the traces of digital forensic evidences over several cloud platforms, and found that a user's password for accounts on Google Drive was stored in cleartext within the file (p. 182).
With the growing number of mobile phones and smart devices, pervasive connections via mobile devices and social networks are growing exponentially. The investigate-ability of pervasive social networks and big data concerns law enforcement agencies with regards to the ubiquitous presence of international crime. Quick and Choo (2017) proposed Digital Forensic Intelligence Analysis Cycle (DFIAC), which was adopted from a cloud forensic analysis framework (Quick and Choo 2013a), and can be used in locating information across an increasing volume of forensically extracted data from mobile devices. Based on DFIAC, Quick and Choo (2017) demonstrated how a huge volume of gigabytes data can be reduced to mere megabytes when test data was converted into spreadsheets like csv, xls or xlsx. However, the ability to investigate on, and make sense of, big data from pervasive mobile devices and social networks still lacks significantly in the discipline of cloud forensics.
Regarding Google Docs forensics, Roussev and McCulley (2016) proposed the concept of analyzing cloud-native digital artifacts, and discussed the residual digital artifacts that maintain in the persistent state of web/SaaS applications. Such artifacts can have a completely different structure and their state is often maintained in the form of a complete (or partial) log of user editing actions. Several of Google's APIs were examined, and observations were made to the Docs editor, Slides application and changelog, drawings objects changelog, and Sheets API. "Track changes" functionality within the artifacts were similar to how Microsoft Word would operate, but slightly different due to different formatting and user interface issues (p. S110).  developed a cloud drive acquisition tool: kumodd, to analyze full API-based acquisition of Google Drive, Dropbox, Box and Microsoft OneDrive. However, because this tool does not acquire cloud-native artifacts in their original form, Roussev and McCulley (2016) developed a new proof-of-concept tool, called kumodocs, to extract and process the history of documents and slides on Google Docs and Slides. This tool can also perform a quick privacy audit, as it can identify all the images, suggestions, comments that have been ostensibly deleted but still can be recovered. Ho et al. (2018) further explored the challenges of cloud forensics investigation into file access, transfer and operations, and identifying file operational and behavioral patterns based on timestamps. Timestamp patterns were observed contributing to the law enforcement community; a reference manual for uncovering data breach incidents occurring between the NTFS and ext4 filesystems in cloud forensics investigations.

IoT Forensics
Conceptually, any device that can be controlled through remote access connectivity can be considered an IoT device. Raspberry Pi can be easily adopted to the home environment. Casey (2015) suggested that smart home devices can be deployed in a wide range of household appliances-controlled and accessed via the Internet, as well as through voice or text commands. These smart home devices typically collect non-sensitive information such as energy sensor data or device usage; however, they can also store sensitive information such as credit card details, users' browsing history, and social networking activities. If hackers are able to access and eavesdrop on these devices, it could potentially result in fraudulent transactions. Casey (2015) stressed the importance of smart home forensics because of the possibilities of many new forms of burglary.
Raspberry Pi can also be deployed in healthcare and smart city context, due to its cost-effective features. Feng et al. (2017) however suggested that Pi has structural and operations issues regarding the integrity of the device-especially if the device is deployed as a processor. While several different Pi models were discussed, the authors examined and analyzed only the physical media layer, media management layer, file system layer, application layer, network layer, and memory layer for the Pi Model B (rev 2). Exploring the vulnerable side of the Pi, Feng et al. (2017) identified that the Raspbian operating system uses the secure shell protocol (SSH) on port 22 to establish remote connections. However, security issues arise when port 22 continues to remain open in situations where remote access is not required. Also, the default user credentials for Raspbian is well known to be the username 'pi' and password 'raspberry,' and users usually neglect to change this. One of the biggest concerns is with the massive deployment of Pi. When Pi devices are deployed in millions of homes-and especially in a healthcare context-the devices can be easily hijacked, turned into botnets, and used for automated distributed denial-ofservice (DDoS) attacks (p. 11).
In a healthcare context, Murray (2017) explored the ability of installing Kali Linux on Pi, and used the Pi device to foresee penetration testing techniques. This study demonstrated how flexible the Pi can be when adopted as master nodes to perform man-in-the-middle attack and denial of service attack, or as sensor nodes to simulate the communication with each other, or as slave nodes (i.e., compromised zombies) to act based on the commands of master nodes. Murray (2017) proposed a revocable key-policy attribute-encryption protocol to control access rights directly on encrypted data. This approach can secure eHealth data sharing in the cloud environment between multiple organizations.
Ubiquitous use and always-on operation mode makes IoT devices a black box of user activities but can also become a great source of potential digital evidence. Similar to the Zawoad and Hasan (2015) multi-level forensics approach, Chung et al. (2017) further proposed a proof-of-concept Cloud-based IoT Forensics Tool (CIFT) in the study of Amazon Alexa ecosystem with the embedded smart speaker system, Amazon Echo. This CIFT-combining cloud-native forensics with client-side forensics-supports identification, acquisition and analysis of both native artifacts from the cloud as well as client artifacts from local devices.
On the other hand, the popularity-and the always-on mode-also enables IoT devices to produce reams of data, which challenges the investigation process in terms of extracting and processing evidence. Quick and Choo (2018) outlined a process for bulk digital forensic data analysis that includes disparate device data. Based on the Digital Forensics Intelligence Analysis Cycle described in Quick and Choo (2013a), Quick and Choo (2018) framed the process for digital forensics of disparate device into multiple phases. This dataset was analyzed for two purposes: (1) to explore the reliability of data from a fitness band device, and (2) to examine a process of analysis of a large volume of disparate data. Through these experiments, Quick and Choo (2018) provided proof that a malicious user's attempts to manipulate the time of activity in order to provide a false alibi cannot succeed, because the true time/date settings will be corrected when files are uploaded to the associated account.

Study Framework
Since timestamps are critical components in IoT device forensics, our immediate objective was to collect timestamps from different operating systems (Raspbian 9.14, UbuntuMATE, and Ubuntu 18.04), and to perform file operations from those ext4 filesystems-interacting with both a private cloud as well as the public cloud. We connected Raspbian Pi with Linuxrepresenting a private cloud, while ownCloud and Dropbox represented the public cloud. Our aim was to collect, observe and compare timestamps of file operations, and to derive generalizable observation rules across different ext4 filesystems ( Figure  1).

Research Design and Experiment Setup
As Error! Reference source not found. illustrates, the research design is divided into three phases: 1) file operations on a standalone machine, 2) file transfer with the private cloud (Ubuntu Linux), and 3) file synchronization with the public cloud (ownCloud and Dropbox).
In this experiment, the extracted timestamp attributes include the create time (cr-time), modify time (m-time), access time (a-time), and change time (c-time). To obtain these metadata, we leverage the debugfs tool by running the inode number of that particular file in the debugfs. Inode is the index value of a file, which is a unique number in a partition. To set up debugfs, we mount the debugfs program with root permission. After mounting debugfs, we run the 'stat' command, which gives the inode value of the respected file and passes that inode value to the debugfs command to provide the timestamps of a file. The same approach is used for the different filesystems, and results are used in comparison.

Computing Environment
Our computing environment was setup in the iSensor laboratory 4 at Florida State University School of Information. File operations were performed using test files, and timestamps were observed based on different attributes in the file timestamp 4 iSensor Lab: https://isensoranalytics.com/ In the first phase, file operations were performed on two sets of standalone physical Pi systems with different operating systems. One Ubuntu system was also set up for comparison purposes. Then, connections with both the private and public Cloud were set up. The following file operations were performed and compared: create, compress, decompress, access, modify, move, rename, copy and delete.
In the second phase, file transfer operations and interactions were performed between a Pi and an Ubuntu Linux system within the private cloud (illustrated in Figure 2). The private cloud was also set up at the iSensor laboratory 4 -represented by direct cable connection between the Pi's and the Ubuntu Linux. Files were transferred between Pi's and Ubuntu Linux system. The following file operations were performed via SSH 5 and compared: create, upload, and download.
⇒Private cloud o RJ45 Cat-6 Ethernet patch cable connection for office networks in a wired LAN In the third phase, file transfer operations and interaction were performed between a Pi and public cloud (Figure 2). Files were transferred from a Raspberry Pi to public cloud using a browser and self-synchronizing command line interface. ⇒Public

Data Collection
Timestamps were collected and recorded both before and after various file operations from the inode metadata information collected using the debugfs tool. In Appendix A, the timestamps recorded during various file operations are given. Tables were aggregated based on the timestamps recorded and compared during identical file operations in different settings.

Investigation Procedure
Both Pi devices (Raspbian 9.14 and UbuntuMATE) and Ubuntu (18.04) utilized an ext4 filesystem, and generated similar inode reports using debugfs procedures. Basically, after each file was created, we accessed the inode number using the stat command for that file. From there, we collected the timestamp metadata (i.e., cr-time, m-time, a-time, and c-time) before and after each file operation was performed sequentially. We then recorded the changes on whether or not each file operation had changed or updated the baseline timestamps.
The following steps were iteratively conducted and taken during each phase of the investigations. Phase 1. Standalone file operations o Step 1: Set up two Pi's (Raspbian 9.14 and UbuntuMATE) and one Ubuntu Linux (18.04 LTS), and properly install all of the starting software. o Step 2: Determine the name of the ext4 filesystem used in each environment. o Step 3: Mount the debugfs tool to the ext4 filesystem found in step 2 using root. o Step 4: Create a test file and use the 'stat' command to determine the inode numb. o Step 5: Use the debugfs tool to gather the first set of timestamps.

Observations
Our objectives include three phases of observations of the file operations performed on: (1) a standalone physical Pi between two operating systems, (2) file transfer operations within a private cloud, and (3) and file synchronization operations with public cloud (represented by the interaction with either ownCloud or Dropbox). During the phase one observation, we compared the timestamps on Pi (Raspbian 9.14 vs. UbuntuMATE) and additionally Ubuntu 18.04. During the phase two observations, we compared file transfer operations and the interaction between Pi and Ubuntu 18.04 in a private cloud. During the phase three observations, we compared file synchronization operations and the interaction (1) between Pi and a public cloud (i.e., ownCloud), and (2) between Ubuntu and a public cloud (i.e., Dropbox). Our observations are showcased in Table 1 through Table 3.

Preliminary Observations
Preliminary observations and baseline data were collected to identify how different Pi operating systems change the way timestamps are collected in comparison with Ubuntu using the same sets of instructions on a text file (.txt). We observed that the timestamps of file operations were slightly different between Raspbian 9.14 and UbuntuMATE. Moreover, we observed significant differences between Raspberry Pi (armv7) and Ubuntu standalone system (x86) ext4 filesystems. These might be caused by differences in the instruction set architecture.

Direct Observations
Based on the experiment, we observed two general differences-when a file is modified and deleted-between Raspberry Pi running on Raspbian 9.14 and UbuntuMATE. The observations below are taken to compare timestamps across Raspbian 9.14, UbuntuMATE and Ubuntu 18.04. Data of direct observations were documented and reported from Table 4 to Table 9 in Appendix A.

Observation 1. File creation
The create time (cr-time) refers to the time of creation. When a file is created, all timestamps are recorded as the time of creation depending on the file creation commands.

Observation 2. File compression
When a file is compressed, it changes the timestamps with the time of compression. However, the timestamps will vary depending on different compression algorithms and operations. o Rule 2: When a file is compressed using the 'tar' 6 command, all timestamps are changed to the time of compression in both Raspberry Pi and Ubuntu 18.04 system. o Rule 3: When a file is compressed using the 'gzip' 7 command, the change time (c-time) and the create time (crtime) are changed to the compression time, whereas the access time (a-time) and modify time (m-time) are not changed in both Raspberry Pi and Ubuntu 18.04 system.

Observation 3. File decompression
The file compression forms the baseline timestamp. When a file is decompressed, both the time of decompression as well as the time before the compression are recorded in timestamps. o Rule 4: When a compressed file is decompressed using the 'tar' command, there is no change in the file's timestamps in Raspberry Pi where the access time (a-time) is updated to the time of decompression in Ubuntu 18.04 system. o Rule 5: When a compressed file is decompressed using the 'gzip' command, the create time (cr-time) and access time (a-time) are not changed, but the modify time (m-time) and change time (c-time) are changed to the time of decompression in Raspberry Pi system whereas the create time (cr-time) remains the same while the rest of the three timestamp characteristics are updated to the decompression time in the Ubuntu 18.04 system.

Observation 4. File access
On accessing a file without making any modifications, updates of the timestamp will change based on the latest time of access. The timestamps are recorded depending on the mode of operation. o Rule 6: When a file is accessed using both GUI and the 'cat' command, there is no change in the timestamps of the file in Raspberry Pi system, but the access time (a-time) of the file is updated to the latest time of access in Ubuntu 18.04 system.

Observation 5. Modify
When modifying a file, different operating environments each have an effect on the timestamps. o Rule 7: When a file is modified using GUI, the create time (cr-time) and access time (a-time) are not changed, but the modify time (m-time) and change time (c-time) are updated to the time of modification on Raspbian 9.14. When a file is modified using GUI, all timestamps are updated to the time of file modification across UbuntuMATE and Ubuntu 18.04. This is because the filesystem assigns a new inode value after the file is saved. o Rule 8: When a file is modified using the 'nano' command, the create time (cr-time) and access time (a-time) are not changed, but the modify time (m-time) and change time (c-time) are updated to the time of modification in Raspberry Pi systems. However, the create time (c-time) is not changed, but the other three timestamps are updated to the time of modification in Ubuntu 18.04 system.

Observation 6. Move
When moving a file, the timestamp remains the same in both Raspberry Pi systems as well as the Ubuntu 18.04 system. o Rule 9: When a file is moved using the 'mv' command, the change time (c-time) is updated to the time of file move, and the rest of the timestamps remain the same.

Observation 7. Rename
On renaming a file, the timestamp remains the same in both Raspberry Pi systems as well as Ubuntu 18.04 system. o Rule 10: When a file is renamed, the change time (c-time) is updated to the time of rename, and the rest of the timestamps remain unchanged.

Observation 8. Copy
On copying a file, a new file is created in the filesystem, which generates a new inode value with new timestamps, all reflecting the time of creation. But this also makes some changes in the timestamps of the original file. o Rule 11: When a file is copied in the same directory, or in a different directory using the same name, or into a different directory using a different name, a new file is created with new timestamps reflecting the time of creation, while the timestamp of the original file remains unchanged in Raspberry Pi systems. o Rule 12: When a file is copied in the same directory, or in a different directory using the same name, or into a different directory using a different name, a new file is created with new timestamps reflecting the time of creation, but the access time (a-time) of the original file is updated to the time of creation of the new file in Ubuntu 18.04 system.

Observation 9. Delete
On deleting a file, some of the timestamp characteristics are updated with the time of file deletion depending on the operating system. o Rule 13: When a file is deleted, the create time (cr-time) and access time (a-time) are not changed, whereas the modify time (m-time) and change time (c-time) are updated to the time of deletion in Raspbian 9.14 and Ubutntu 18.04 systems.
o Rule 14: When a file is deleted, the change time (c-time) is updated to the time of deletion, but the rest of the timestamps remain the same in UbuntuMATE.

Observation 10. File transfer to private cloud
We observed file operations when a file is transferred to a private cloud (Ubuntu 18.04). The 'SCP' (secure copy) command-'scp pi@ipaddress:myfile.txt'-is used. o Rule 15: There is no change in the timestamp when uploading a file from the Raspberry Pi system to the private cloud. o Rule 16: The change time (c-time) and modification time (m-time) are updated to the time of download when the same file is downloaded back to the same location on both Raspberry Pi's.

Observation 11. File upload/ download to public cloud
The public cloud enables file synchronization. When a file is uploaded to the cloud, it is automatically synchronized with the local drive. Thus, there is no download operation in our observations. We observed the file synchronization operation with the public cloud. ownCloud is used as our public cloud through the self-synchronization system as well as through web browser. o Rule 17: There was no change in the timestamps of the file when uploading a file to the public cloud using selfsynchronization system in both Raspberry Pi's. o Rule 18: The create time (cr-time) and change time (c-time) are updated to the time of upload while the rest of the timestamps remain unchanged using a browser in both Raspberry Pi's.

Cross-Sectional Observations
We compared different file operations across ext4 filesystems including Raspbian 9.14, UbuntuMATE, Ubuntu 18.04, Ubuntu 18.04 (VM), Ubuntu 14.04 (VM), and conducted cross-sectional analysis on timestamps collected during the same time period to derive the following observation rules.

Observation 12. Updates of create time
We compared the file's create time (cr-time) and derived that the create time is updated when a file is compressed, but not updated when the file is decompressed, accessed, moved, renamed or copied. o Rule 19: Create time is updated when the file is compressed across all five operating systems and updated when the file is modified using a GUI across Ubuntu operating systems, but not Raspbian 9.14.

Observation 13. Updates of modify time
We compared the file's modify time (m-time) and observed that the timestamp is updated when a file is created, compressed, decompressed, and modified across all five file operations. o Rule 20: Modify time (m-time) is updated when a file is created using 'cat' command, but not 'nano' and 'echo' commands across all operating systems. o Rule 21: Modify time (m-time) is updated when a file is compressed using 'tar' command, but not 'gzip' command across all operating systems. o Rule 22: Modify time (m-time) is updated when a file is modified using both 'GUI' and 'nano' commands across all the five platforms. o Rule 23: Modify time (m-time) is updated when a file is deleted in Raspbian 9.14, Ubuntu 18.04 and Ubuntu 18.04 VM, but not in UbuntuMATE and Ubuntu 14.04 VM.

Observation 14. Updates of access time
We compared the file access time (a-time) and observed that it is updated when a file is compressed across all five operating systems. However, the access time is also updated when a file is compressed, decompressed, accessed, modified, moved, or copied in Ubuntu 18.

Observation 15. Updates of change time
We compared file change time and observed that it is updated when a file is created, compressed, decompressed, modified, moved, renamed or deleted, across all five operating systems.
o Rule 29: Change time (c-time) is updated when a file is created using the 'cat' command across all five operating systems, but it remains unchanged when 'nano' and 'echo' commands are used. o Rule 30: Change time (c-time) is updated when a file is compressed using 'tar' and 'gzip' commands whereas the c-time is updated only when a file is decompressed using the 'gzip' command. o Rule 31: Change time (c-time) is updated when a file is modified, moved, renamed or deleted across five operating systems using both GUI and the 'nano' command.

Observation 16. Deletion of disingenuous file
We compared the cross-sectional data of the file's create time, access time, modify time and change time, and observed the following rule: o Rule 32: When a file's create time (cr-time) is recorded to be later than the modify time (m-time) or access time (a-time), it indicates that the file was uploaded or downloaded to the cloud from Raspberry Pi System.

Results and Discussion
When conducting forensic experiments on IoT devices (such as the Raspberry Pi), it is important to be aware of changes to the inode timestamps incurred by various file operations. In this section, we not only discussed the significant changes of the file operation on the current IoT forensics study of the ext4 filesystems, but also compared the current findings with the observations of Ubuntu ext4 filesystems in the standalone as well as the cloud settings conducted by Ho et al. (2018).

Differences between Pi Raspbian 9.14 and Pi with UbuntuMATE O/S
Although the same set of file operations were performed, there is only one noticeable difference-i.e., when modifying a file using GUI-as observed between two Raspberry Pi's. When a file is modified using GUI, the modify time (m-time) and change time (c-time) are updated to the time of modification in Raspbian 9.14. However, UbuntuMATE assigns a new inode number to the modified file as soon it is saved. All four timestamps are updated to the time of modification (observation rule 7).

Differences between Pi Ext4 and Ubuntu Ext4
When comparing Pi's operations with Ubuntu, we observed that the ext4 filesystems in Pi's are less sensitive than the ext4 filesystems in Ubuntu. That is, we noticed six (6)

Differences between Ubuntu Ext4
To compare the differences of file operations among different Ubuntu ext4 filesystems, we further set up two virtual machines (i.e., Ubuntu 18.04 and 14.04 VMs) in the Hyper-V management system ( Table 10 in Appendix B)-running on Windows Server 2016 Datacenter-so we could observe how ext4 filesystems of the same O/S behave on a different environments (i.e., physical vs. virtual) in order to compare our results with the findings from Ho et al. (2018). We adopted the same experimental approaches-performing the same set of file operations and instructions as illustrated in Ho et al. (2018). As a result, we observed five (5) differences when comparing both Ubuntu 18.04 and the Ubuntu 14.04 Virtual Machine. The behaviors of the three Ubuntu systems are not completely the same. More specifically, both the Ubuntu 18.04 standalone system and Ubuntu 18.04 Virtual Machine have no difference in the three phases of the observations (Table 11). However, we attribute the ext4 filesystems in Ubuntu 18.04 as being more sensitive than ext4 filesystems in Ubuntu 14.04, which includes the following differences. First, when a file is accessed without making any modification using GUI or the 'cat' command, the access time (

Conclusion
As cloud computing and the Internet of Things (IoT) become increasingly prevalent in everyday use, it is important for law enforcement investigators to understand how these files operate, as well as how they are recorded and transferred in different filesystems (e.g., the ext4 filesystem) over the Cloud environments. Timestamp metadata can change across the ext4 filesystems-even when executing the same file operations. This IoT forensics study was designed and conducted to examine and compare how timestamps vary within IoT devices, particularly between Raspberry Pi (Raspbian 9.14 vs. UbuntuMATE) and Ubuntu (e.g., 18.04). We further experimented on file transfer operations; from the Raspberry Pi (Raspbian 9.14 vs. UbuntuMATE) to the private cloud (i.e., Ubuntu 18.04), and moved further into file synchronization operations from the Raspberry Pi (Raspbian 9.14 vs. UbuntuMATE) to the public cloud (i.e., ownCloud and Dropbox).
We anticipate that the reasons for differences in some observations among the Pi's are caused by the differences in their O/S (i.e., Raspbian 9.14 vs. UbuntuMATE). We further anticipate the reasons for the differences between the Pi and Ubuntu 18.04 or 14.04 may be caused by the different architectures of the hardware processors (i.e., arm7 vs. X.86). Different versions of hardware processors such as Raspberry Pi can support only arm architecture. In general, the Ubuntu 18.04 is more sensitive than the Pi's or the Ubuntu 14.04.

Limitations and Future Directions
The authors were able to analyze the ext4 filesystem in the Raspbian environments with arm architecture and Ubuntu with X.86 architecture. Analyzing other proprietary IoT O/S-with Linux expansions-could provide for a more complete dataset while also painting a more accurate picture of the IoT forensic investigative process. Although Raspberry Pi is an incredibly versatile tool with boundless possibilities in the IoT field, it is still limited by its processing power, and must use extremely lightweight distributions. Further exploration of the NTFS and FAT32 filesystems could provide a more comprehensive view should these filesystems be adopted in the IoT world. In the current study, differences in timestamp metadata within ext4 filesystems were identified. The same examination of file operations could be performed on different Linux distributions, which may yield a greater varied set of results and observations.

Implications to Practitioners
It is a common practice for organizations-both in public and private sectors-to store and access corporate information in the cloud environment. The threats that organizations face and experience are twofold. First, IoT devices make the modern lifestyle more connected, such as connected cars, homes, hospitals, healthcare facilities, retail stores, manufacturing, and smart cities. However, the connectivity of IoT devices make our society more vulnerable as cyberinfrastruture can be compromised. IoT devices can be used by hackers to form botnets and launch distributed denial-of-service (DDOS) attacks against corporate backend servers that can exploit users' privacy, which further cause safety concerns. Second, organizations face significant white collar crime and insider threats in unauthorized modification of sensitive and/or classified information. It is critical for cyber forensics practitioners to gain intrinsic knowledge and techniques of how file systems operate and behave for advanced threat investigation. This study provides detailed steps and techniques for IoT forensics, and is significantly relevant to cyber investigation. The study demonstrates mechanisms of digital evidence analysis and observation with regards to access and modification of file systems within normal versus abnormal conditions.

Contributions
The purpose of this study is to build a thorough understanding of how the ext4 filesystem timestamps reflect file operation activities in cloud environments. This cyber forensics study-specifically, IoT forensics-was designed and conducted to examine, compare and provide baseline observations for how timestamps change in the same ext4 filesystems between IoT devices and Linux-based systems. The observations, techniques and methodologies discussed in this article contribute to a thorough understanding of how the same ext4 filesystem timestamps work differently, or perhaps similarly, for Pi and Linuxbased systems (e.g., Ubuntu) in cloud environments. Furthermore, this study advances cyber forensics and cyber-criminal investigation for use by the law enforcement and intelligence community.

Declaration of Conflicting Interest
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.   * Red color indicates a timestamp change (i.e., difference) recorded and observed-as compared with previous timestamp observation. * Red color indicates a timestamp change (i.e., difference) recorded and observed-as compared with previous timestamp observation. * Red color indicates a timestamp change (i.e., difference) recorded and observed-as compared with previous timestamp observation.