Part of UC3BPR20 2025 - Acquisition and Analysis of Forensic Artefacts in a Smart Home Environment: A Study in IoT Forensics.
The following IoT / smart home forensics dataset is a result of a digital forensics experiment, based on a wireless smart home testbed consisting of an Atom Homey Pro smart home gateway and a set of Zigbee sensors and actuators, managed by the Homey Android application emulated on an Android Studio AVD. The resulting forensic artefacts (in the form of forensic images of the Homey Pro's eMMC storage, as well as logically extracted Android data, before and after execution of the experiment) has been made available in this dataset, which aims to support future research, training, and testing in IoT forensics (also feel free to use it in CTF challenges).
As a reference point for future training and experiments, the contents of the testbed, the variables and controls, the most significant artefacts, as well as an outline of the acquisition process are detailed in the following sections.
A prototype tool, the SlyFox IoT Sleuth (SFHPCBA01) has been developed as a forensic acquisition tool for Homey Pro (and other RPI CM4-based devices), based on the identified acquisition process described below.
| Pre Experiment | SHA-256 |
|---|---|
b924fe3259b3109939bee99eb3c28d10a20a8565dc0c3d7e157c55efdf80cfa7 |
|
0e5482254374c13ffd9379eb29e2fe74efe096aaf82156231b1a4b43b5073602 |
| Post Experiment | SHA-256 |
|---|---|
3239ba054101b7f1c75970183aa1f4b4320c51b83f7b804b2a7ad6dc0be05842 |
|
84f85f3b49a750587363b91e2a07ecb4e709ad730439a56638bde2fb7991c253 |
The EnCase EWF (.E01) forensic images can be examined in any/most forensic tools. Free alternatives include FTK Imager and Autopsy.
The Android files can be manually examined with any text/hex viewer or forensic tool. The SQLite (.db) files can be examined in DB Browser for SQLite or Autopsy, as examples.
- Are you able to identify the type of OS and the startup processes?.
- Where is the Homey software located and what technologies are used?.
- Where are the site- and user-specific configurations and logs stored?.
- Can you find any correlations between the user/site data located in the eMMC and the Android application?.
- What other artefacts of forensic relevance can you identify, outside the ones listed in artefacts ?.
The testbed used in the experiment consisted of the following devices:
| Device Name | Device Details |
|---|---|
| Atom Homey Pro | Smart home hub and centre of the WPAN Zigbee network. The network's sensors and actuators are paired to this unit, which in turn is managed by the Homey app. Model: HY0025. |
| Homey for Android | Homey - A better smart home 8.2.2 (nodpi) (Android 5.0+). Downloaded from APKMirror. SHA-256: 3e7fe942fe1e35e9120e4af4f79df12ece70383fcf474dc49318cec8fc724a76. |
| AVD | Android Studio Meerkat, 2024.3.1 Patch 1 (macOS) and Android Emulator v.35.4.9. |
| Ikea Traadfri LED | LED bulb with built-in wireless Zigbee actuator. Item No. 905.390.72. |
| EVA Zigbee HAN Meter reader | Wireless Zigbee smart meter sensor that connects to the smart meter with a HAN (RJ45) connector and pairs wirelessly to the Homey Pro smart home hub. EAN: 7072090000317. |
| Ikea Vindstyrka | Wireless Zigbee air quality sensor. Item No. 004.982.31. |
| Ikea Badring | Wireless Zigbee water leak sensor. Item No. 605.043.52. |
| Ikea Rodret | Wireless Zigbee dimmer switch. Item No. 205.281.28. |
| Ikea Vallhorn | Wireless Zigbee motion sensor. Item No. 905.043.41. |
The following variables were used during the configuration of the testbed and should serve as reference when examining the dataset.
| No | Description |
|---|---|
| 1 | The experiment (and testbed) was operational from 20.04.2025 to 01.05.2025. |
| 2 | The devices used in the testbed are listed in contents of the testbed. |
| 3 | Alle devices were installed in the default 'office' room, second floor. |
| 4 | Two 'apps' were installed to support devices from Ikea Tradfri and Eva (Datek) AMS meter. |
| 5 | Two 'flows' were configured, turning lights on/off on motion/no motion in the office. |
| 6 | Account Name: UC3 BPR * |
| 7 | Wi-Fi Credentials: Alti***443108, pqVPvReK * |
| 8 | Account Credentials: UC3BPR20@***web.io, helloUC3BPR20 * |
*All credentials used in the testbed were changed/closed after the end of the experiment.
The following artefacts of forensic value has been identified. Can you find more?
BOOTA / BOOTB
| Location | Significance |
|---|---|
/tryboot.txt |
Configuration file for UART's and selected system settings. + a message from the Homey developers. |
ROOTA
| Location | Significance |
|---|---|
/usr/lib/os-release |
OS-release information – Debian 11 (Bullseye). |
/etc/debian_version |
Debian version – 11.11. |
/etc/rpi-issue |
Details the use of the pi-gen tool to generate the OS-image. |
/etc/passwd |
List of OS user-accounts. One non-system user identified – \protect\texttt{homey:x:1000:1000:,,,:/home/homey:/bin/bash |
/var/lib/docker/ |
Docker’s global root. Including the Homey core container and its application code |
| `/var/lib/docker/overlay2/ | Docker’s copy-on-write storage area where the image layer store changes. |
ROOTB
| Location | Significance |
|---|---|
/var/lib/docker/ |
Docker’s global root. Including the Homey core container and its application code. |
/var/lib/docker/overlay2/ |
Docker’s copy-on-write storage area where image layer store changes. |
USER
| Location | Significance |
|---|---|
/sqlite/db.sqlite |
Main database, containing information on the user account, smart home site and configurations, sensors paired, their configurations and parts of their logged data, cloud keys, timestamps, and more. |
/network-manager-connections |
Wi-Fi credentials, including password in plaintext. |
log/system.log |
System events, such as the start of the Homey Pro Docker container. |
log/homey-pro.log |
Homey Pro application events such as network adapters and cloud manager. |
/apps/} |
Directory for third-party plugins for Homey Pro, such as Ikea Tradfri and Eva HAN-sensor. |
db.sqlite – The six devices paired to the site. 5x Ikea Tradfri, 1x Eva/Datek.
| Location | Significance |
|---|---|
/data/data/app.homey |
Primary application folder (see directory tree below). |
/data/system/packages.list |
Lists installed applications. |
/data/system/package-usage.list |
Lists recently used applications and utilities. |
/data/misc/profiles/ |
Can hold app-execution and profiling data. |
/sdcard/Android/data/app.homey |
External (virtual) storage location for application-related files. |
app.homey, app.homey/databases and app.homey/app_webview directories.
app.homey/cache/ and app.homey/cache/http-cache/ directories.
The Homey Pro's eMMC was forensically imaged by performing the following steps:
- Physically extract the CM4 SoM from the Homey Pro's main PCB.
- Configure and mount the CM4 in the CM4IO development board.
- Mount the eMMC as a USB storage device on a host computer, using
rpiboot. - 'bit-for-bit' clone the eMMC to a raw .img file using
dd. - Create a forensic image (EnCase EWF / .E01) of the raw file.
It is strongly advised to use an external (hardware) write blocker when working with evidence items. If none is available, an alternative can be to enable blockdev, a kernel-level software write blocker.
Enable write protection with sudo blockdev --setro /dev/sda (given sda is identified as the eMMC). Then verify that it has been enabled by running blockdev --getro /dev/sda, where 1 is enabled, and 0 is disabled.
Example of use of dd. Make sure to double check disk device name with lsblk.
sudo dd if=/dev/sdb of=~/cm4-homey-pre-emmc-backup.img bs=4M status=progress conv=fsync
dd to image the eMMC.
Install ewf-tools:
sudo apt-get update && sudo apt-get install libewf-dev ewf-tools
Then create a loop device of the raw image 1.
LOOPDEV=$(sudo losetup --read-only --find --show ~/cm4-homey-pre-emmc-backup.img)
echo "Loop device is: $LOOPDEV"
Now run ewfacquire to initiate the creation of the EWF image.
sudo ewfacquire -t ~/evidence_encase/HomeyProPre -C "UC3BPR20" -e "OEE" -d sha256 -E 01 -N "Homey Pro eMMC Pre-Experiment"
-m fixed -M physical -f encase6 -o 0 -B 7818182656 -P 512 -b 64 -g 64 -r 2 -c deflate: best -S 9000000000 -D "Homey Pro Pre-Experiment Acquisition"
"$LOOPDEV"
ewfacquire to create a EWF forensic image of the newly acquired raw image.
ewfacquire - Mandatory configuration arguments with descriptions:
sudo ewfacquire \
-t ~/ evidence_encase/HomeyProPre \ # Target basename → HomeyProPre.E01
-C "UC3BPR20" \ # Case number
-e "OEE" \ # Examiner
-d sha256 # SHA-256 hashing
-E 01 \ # Evidence number
-N "Homey Pro eMMC Pre-Experiment" \ # Notes
—m fixed \ # Media type
-M physical \ # Media characteristics
-f encase6 \ # EWF format (EnCase 6)
-0 0 # Start offset
-B 7818182656 \ # Bytes to acquire (full 8GB)
-P 512 \ # Bytes per sector
-b 64 \ # Sectors per chunk
-g 64 \ # Error granularity
-r 2 \ # Retry count on read error
-c deflate: best # Best DEFLATE compression (slowest)
-S 9000000000 # 9 GB cap → Single segment only.
-D "Homey Pro Pre-Experiment Acquisition" \ # Description/ comment
"$LOOPDEV"
The Homey Android application (Testbed) was installed on and AVD(Android Virtual Device) in the Android Studio emulator (Device Manager). The ADB (Android Debug Interface) was used to logically extract application data and relevant system data from the AVD.
ADB commands as part of the logical acquisition:
adb devices # list AVDs
adb shell # Access ADB shell. If multiple, specify, e.g: adb -s emulator-5556 shell
adb su # Enable root
adb shell whoami # Verify root
adb remount # Enable read/write access
adb pull # Specify /avd/path/to/pull/ /path/to/destination/on/host/pc/
Until next time...
Footnotes
-
Loop devices in Linux are virtual block devices that allow you to mount and interact with a file as if it were a physical disk. They are commonly used when working with disk images, such as ISO files. Example: A loop device (/dev/loopX, where X is a number) lets you treat a regular file like a storage device. This is useful when dealing with disk images, encrypted filesystems, or snapshots. ↩