A journey into IoT Forensics - Episode 5 - Analysis of the Apple HomePod and the Apple Home Kit Environment (aka thanks RN Team!)

By -

This is the fifth blog post on the analysis of IoT devices. The first blog post was about the analysis of Samsung refrigerator, the second one was about the analysis of an LG Smart TV, the third one was about the analysis of an Ematic Android TV OS Box, and the fourth one was about the analysis of an iRobot Roomba 690. All the previous blog posts were based on images made available for research by VTO Labs.

This fifth post is about the acquisition and analysis of the Apple Homepod and the Apple HomeKit environment. This is based on a research developed by our RN team during 2020: in particular, it was the research topic of the thesis of our internship Francesca Maestri, who successfully obtained her computer science degree last year. Congrats and thanks for your great work Francesca!

This work was first presented online in June 2020 at the DFRWS EU 2020, as a short presentantion. It was also the topic of the famous DFRWS Rodeo. Presentation from the DFRWS, the Rodeo dataset, questions and answers are available for download.

An extended version was presented at the SANS Digital Forensics Summit in July 2020. The full video "Forensic Analysis of Apple HomePod & Apple HomeKit Environment" is available on YouTube and the presentation is available on the SANS website.

In this article, we provide some details of our findings and, hopefully, ideas for additional research activities.

The HomePod and the Home app

The aim of this work was to perform a forensic analysis of the HomePod, a smart speaker developed by Apple, and the Home App, used to manage the HomePod from other Apple devices (iPhone, iPad, Mac, and so on).

The Home application serves, in general, to manage Smart Home accessories compatible with the HomeKit, a framework for home automation developed by Apple. A list of compatible accessories is available on the Apple website. Accessories are grouped by “Rooms”, and "Rooms" are managed by the user, through the Home App.

The HomePod, which integrates the voice assistant Siri and works with the Apple Music platform, can be used as the "Home Hub" to manage accessories based on the HomeKit environment.

We were not able to find previous researches on a forensic approach to this type of device.

For this research we created a test environment composed by:
  • An Apple HomePod, version 2018
  • An Apple iPhone 7,
  • A door sensor "Eve Door", compatible with Apple HomeKit

Data extraction

During our research, we were not able to find a viable solution to directly extract data from the Apple HomePod. The iFixt website published a teardown of the Apple HomePod, that revealed a 14-pin connector under the rubber base. 

We recently found a "tweet", showing a possible adapter,  but we were not able to find it on the market.

We decided then to analyze HomePod data in two ways:

  • Generate and extract HomePod sysdiagnose logs
  • Acquire and analyze the synced iPhone
Sysdiagnose logs were generated on an HomePod device by installing a profile on the device through the iPhone, connected to the same HomeKit environment (instructions are available on Apple website). The synced iPhone was then acquired by using the checkra1n jailbreak and our iOS Triage script.

Data analysis

The focus of our analysis was to identify information about the HomePod settings and to find artifacts related to user interactions.

Data analysis: synced iPhone

Device information and settings

The Home App data is mainly stored on the iPhone in the "/private/var/mobile/Library/homed" folder.



The most interesting file to analyze is the "datastore.sqlite" SQLite database.

The "record" table contains, among the others, the following 4 columns:
  • uuid: record identifier
  • parent_uuid: parent uuid identifier
  • type: a group which the specific record belongs to
  • data: a BLOB object (a binary plist file)

By analyzing the database, we noticed a hierarchy among the various elements, based on the uuid and parent_uuid columns. Here follows some of our findings:

  • HMDHomeManagerModel is the main element in the hierarchy and the parent of HMDHomeModel

  • HMDHomeModel is the parent of HMDRoomModel and HMDAppleMediaAccessoryModel
  • HMDAppleMediaAccessoryModel is the parent of HMDAccessorySettingGroupModel

For each entry, we extracted and analyzed the binary plist file contained in the "data" column.

The “HMDHomeManagerModel” plist file doesn't contain useful information, but it's the top of the hierarchy and helps understanding how the database is organized.

The “HMDHomeModel” plist file contains information about the "Home" environment. In particular it contains the home name, the user email address, and the home geolocation (screenshot based on Josh Hickman iOS 13 image).

The "HMDAppleMediaAccessoryModel” plist file contains information about the HomePod, including: 
  • Manufacturer
  • Model
  • Serial Number
  • Firmware Version
  • Custom Name
  • WiFi
The roomUUID value leads to the other son of "HMDHomeModel", that is "HMDRoomModel".



The "HMDAccessorySettingGroupModel" group contains HomePod settings. Settings are organized based on the hierarchical concept. Here follows an example with Music and Siri settings.
The Music group contains various settings, including "Allow Explicit Contents" and "Sound Check".


The Siri group contains various settings including "Listen for Hey Siri", "Touch and hold for Siri", "Light When Using Siri" and "Sound When Using Siri".

"Language" and "Siri Voice" are also represented, with a string like "en-US, en-GB, f, n", where:
  • en-US, is the language
  • en-GB, is the accent
  • f, is the genre
  • The last value refers to the default combination ("en-US,en-US,f"): if the user changed it, the value is "n", otherwise is "d"

The "/private/var/mobile/Library/Caches/com.Apple.HomeKit.Configurations/" folder stores various plist files containing device information, including, for example, the HomePod Wi-Fi Mac Address.

User interactions

By analyzing the iPhone file system, we found two databases containing information about user interaction with the HomePod.

The well-known "/private/var/mobile/CoreDuet/Knowledge/knowledgeC.db" database contains also information about songs streamed to the HomePod.

By using the following query

SELECT 

DATETIME(ZOBJECT.ZSTARTDATE+978307200,'UNIXEPOCH') AS "START", DATETIME(ZOBJECT.ZENDDATE+978307200,'UNIXEPOCH') AS "END", ZSTREAMNAME AS "STREAM NAME", ZVALUESTRING AS "VALUE STRING", Z_DKNOWPLAYINGMETADATAKEY__TITLE AS "TITLE", Z_DKNOWPLAYINGMETADATAKEY__ARTIST AS "ARTIST", Z_DKNOWPLAYINGMETADATAKEY__ALBUM AS "ALBUM", Z_DKNOWPLAYINGMETADATAKEY__DURATION AS "DURATION", Z_DKNOWPLAYINGMETADATAKEY__GENRE AS "GENRE", Z_DKNOWPLAYINGMETADATAKEY__MEDIATYPE AS "MEDIA TYPE", Z_DKNOWPLAYINGMETADATAKEY__OUTPUTDEVICEIDS AS "OUTPUT DEVICE ID"

FROM 

ZSTRUCTUREDMETADATA JOIN ZOBJECT
ON ZOBJECT.ZSTRUCTUREDMETADATA = ZSTRUCTUREDMETADATA.Z_PK 

ORDER BY ZOBJECT.ZSTARTDATE

you can obtain a list of played song. 

By analyzing the binary plist file contained in the "Output Device ID" column you can obtain the device UUID.

The "/private/var/mobile/Library/com.apple.siri.inference/srdb.db" contains references to song played by using the Siri voice assistant. The table "entries" contains the song name (content_tokens column), the first time the song was played by using Siri (created_at column) and the last time the song was played by using Siri (modified_at column).

Data analysis: Sysdiagnose

Sysdiagnose logs generated on the HomePod can be locally saved on the synced iPhone. 
They are stored in a TAR.GZ file, named ""sysdiagnose_YYYY.MM.DD_HH-MM-SS+Timezone_iPhone-OS_AudioAccessory_IOSVERSION.tar.gz1" (for example "sysdiagnose_2020.01.29_10-31-43+0100_iPhone-OS_AudioAccessory_17D50.tar.gz1"). 

Once extracted, the archive contains the following structure.

Among the others, we highlight the following files and folders:
  • The "/logs/Networking/preferences.plist" file that contains the HomePod Name set by the user
  • The "/WiFi/bluetooth_status.txt" file that contains the HomePod Bluetooth Mac address
  • The "/WiFi/wifi_status.txt" file that contains the HomePod Wi-Fi Mac Address, the BSSID and SSID of the last connected Wi-Fi network 
  • The "/WiFi/com.apple.wifi.plist" file that contains information about Wi-Fi networks the device was connected to (SSID, BSSID, connections timestamps information about the network device (“WPS_PROB_RESP_IE”), and so on)
This file can be easily parsed with the Sysdiagnose Wi-Fi Plist script 
  • The "/ioreg/IODeviceTree.txt" file that stores the manufacturer, the serial number, and the model name used by Apple to identify the HomePod (“AudioAccessory1,1”)
  • The "logs/MobileActivation/mobileactivationd.log.*” files are the Mobile Activation logs. They can be used to obtain the operating system (iOS) version and its upgrades, along with the “Device Class” and “Product Type” assigned by Apple. These logs can be parsed with the Sysdiagnose Mobileactivationd Plist script
  • The "logs/PowerLog” folder contains the HomePod PowerLog. By simply renaming the file as "CurrentPowerlog.PLSQL" you can easily run APOLLO against it.

    Several modules could parse our database, and we obtained results about application info, device status, network usage, and so on.
  • The "system_logs.logarchive" folder contains the HomePod syslog. Here you can find a lot of details about user actions, but this is typically restricted to the last hours of activities. For example you can find information about played radios and songs.

Data analysis: Eve Door Sensor

We included in our research the door sensor "Eve Door & Window" manufactured by Elgato, compatible with the HomeKit framework. The configuration can be done with the Eve App but the sensor is also available in the Home app. 

By analyzing the "/private/var/mobile/Library/homed/datastore.sqlite" file we found:
  • “HMDAccessoryTransaction” group type, whose parent is “HMDHomeModel”. The embedded plist file contains door sensor manufacturer, model, serial number and room.

  • “HMDServiceTransaction” group type, whose parent is “HMDAccessoryTransaction”. The embedded plist file contains the sensor name in the HomeKit environment
Analyzing the Eve App we found two relevant files:
  • The "/Library/Preferences/com.elgato.plist" file that contains, device manufacturer, model and serial number
  • The "/Document/Elgato##Model##Serial_Number.sql" SQLite database, that records every time the door was opened or closed

Conclusions

Here some final considerations:
  • We were not able to find a proper connector to directly interact with the Apple HomePod
  • We were able to generate and extract the HomePod Sysdiagnose logs
  • We extracted and analyzed the paired iPhone
In the paired iPhone we found the following information:
  • HomePod basic information (serial number, os version, name, and so on)
  • HomePod settings
  • HomePod geolocation
  • Home organization in "Rooms"
  • Connected HomeKit device
  • User interactions (played songs)
  • Door sensor information and usage logs
In the HomePod Sysdiagnose logs we found:
  • HomePod basic information (serial number, os version, name, and so on)
  • HomePod settings
  • HomePod network connections
  • HomePod PowerlLogs
  • HomePod Syslog Archive
The results discussed in this research were also validated with the iOS 13 images released by Josh Hickman.


Comments

Post a Comment

Popular posts from this blog

A first look at Android 14 forensics

By -
Android 14 was released to the public by the Open Handset Alliance on October 4, 2023, and is now available on various smartphones, including the Google Pixel. This blog post aims to explore a list of the majr oartifacts you can find on this version of the Android OS.  For testing and review, I set up a Google Pixel 7A and used it for about a month, with a SIM card and various native and third-party apps installed. The blog post is organized by sections: Device information and general settings User accounts Information on Cellular, Wi-Fi, and Bluetooth connections Native Android applications Google applications Analysis of the use of native and third-party applications Other relevant information As always, I'll try to update this blog post as I test and research. Device information and general settings build.prop TXT format Stored in the root directory of the system partition  Among other things, it contains the device manufacturer, the device model, the operating system ...
Keep reading

Huawei backup decryptor

By -
When doing Mobile Forensics the first and usually the hardest step is to get access to user's data . It depends on the case type, but the so called physical  acquisition is the analyst object of desire. The reason is simple: iOS and Android native backups, respectively adb  and iTunes , contain a subset of user data, because they respect the various apps configurations where they can specify " you can't include me in backups ". Which leads to inconsistent situations like, for example, having WhatsApp data in iTunes backups and not having it in Android adb backups. Not considering WhatsApp, the majority of apps in iOS and Android do not allow their data to be included in backups . In the scenario where  device is unlocked or the lock  code is known (the only scenario considered in this post), the analyst could use the device itself to make the analysis of the installed applications. Anyone who did that at least once knows how uncomfortable is this a...
Keep reading

Dissecting the Android WiFiConfigStore.xml for forensic analysis

By -
Image
A smartphone is often connected to a Wi-Fi network: think of how much time we spend at home, in our office, or even in a public place while studying or exercising. As soon as we can reach a (hopefully trusted) Wi-Fi network, we connect to it! On Android devices, the Wi-Fi connection is managed by the Wi-Fi service. This service must store information about the previously connected Wi-Fi networks so that the phone can reconnect as soon as it's in the vicinity. The file that stores this information is WiFiConfigStore.xml, a simple XML file stored in the Userdata partition under /data/misc/apexdata/com.android.wifi/. The source code describing the contents of this file is  available on the Android source code website . This file is parsed by most commercial and open-source tools. I wanted to go a little more in-depth to take a look at the different Wi-Fi settings. The main XML tag is  <WifiConfigStoreData > . This tag contains the  Version  sub-tag, which contains...
Keep reading