## https://sploitus.com/exploit?id=CCE35787-5EEA-5046-B245-A77F2AA63D00
# iOS "Airborne" Vulnerabilities - Log Artifact Extractor
This script is designed to help identify potential traces of the "Airborne" set of vulnerabilities (primarily affecting Apple's AirPlay protocol) by querying iOS system logs from a `.logarchive` bundle. It automates the execution of several `log show` commands tailored to find anomalies that *could* be associated with these vulnerabilities.
**Disclaimer:** *This tool is for informational and investigative purposes only. The presence of log entries matching these queries does not definitively confirm a compromise. Log entries should be analyzed in context. The absence of findings does not guarantee a device is secure. Always ensure your devices are updated to the latest OS versions.*
## About the Author and Project
This script was developed by **Anton Shustikov** ceo@cakecats.com (now is ceo cakescats) as part of the **CakesCats** project.
**CakesCats** is an initiative focused on:
* **Information Security Education:** Aiming to make cybersecurity concepts more accessible and understandable.
* **Support:** Providing free support to activists and individuals facing difficult situations related to digital security.
* **Simple & Clear Products:** Developing straightforward tools and resources for digital safety and security.
Anton Shustikov is an information security and fintech consultant with extensive experience in creating security systems. He is the founder of the non-commercial educational project CakesCats and contributes articles to publications like Forbes and "Xakep" magazine. His work often involves investigating digital threats and promoting digital hygiene.
## About "Airborne" Vulnerabilities
"Airborne" is a name given to a set of vulnerabilities (discovered by Oligo Security in their original research) affecting Apple's AirPlay protocol and the AirPlay Software Development Kit (SDK). These vulnerabilities can impact a wide range of Apple devices (iPhones, iPads, Macs, Apple TV, etc.) and third-party devices using the AirPlay SDK (e.g., smart speakers, receivers).
**Key aspects of "Airborne" type vulnerabilities:**
* **Discovery Context:** The original "Airborne" research was published by Oligo Security (More details: [https://www.oligo.security/blog/airborne](https://www.oligo.security/blog/airborne)). This script is designed to look for general forensic artifacts that *could* be related to such vulnerabilities.
* **Affected Protocols/Components:** Primarily Apple AirPlay, but also related services like Bonjour (mDNS) and `rapportd` which handles device-to-device communication.
* **Potential Impact:** Remote Code Execution (RCE) (including zero-click and potentially wormable variants), Denial of Service (DoS), Access Control List (ACL) bypass, information disclosure, and Man-in-the-Middle (MITM) attacks.
* **CVEs (Contextual Examples):** While specific CVE numbers change with each new discovery, the "Airborne" class of vulnerabilities targets flaws in how AirPlay and related network services handle data, pairing, or connections. For example, previous hypothetical discussions for this tool considered CVEs like CVE-2025-24252 (related to mDNS issues) or CVE-2025-24132 (related to buffer overflows in the AirPlay SDK). *Users should always refer to specific CVE details and vendor advisories for the vulnerabilities they are investigating.*
* **Affected OS Versions (General Guidance):** Typically, versions of iOS, iPadOS, macOS, tvOS, and third-party AirPlay SDKs prior to patches released by Apple and respective vendors in response to specific vulnerability disclosures. Always consult Apple's official security updates and vendor advisories for information on patched versions.
## How This Tool Works
This script executes a series of `log show` commands using carefully crafted predicates. These predicates are designed to filter the vast amount of information in iOS system logs to pinpoint potential indicators of compromise or anomalous activity that *might* be related to "Airborne" type vulnerabilities.
The script looks for:
* Crashes or errors in critical system processes involved in AirPlay, media streaming, network discovery, and device-to-device communication (e.g., `mediaserverd`, `AirPlayXPCHelper`, `rapportd`, `mDNSResponder`).
* Errors specifically logged by the AirPlay subsystem or Bonjour/mDNS services.
* Anomalous network connection events (e.g., unexpected connection resets, failures to connect) reported by relevant processes.
* Kernel panics, which can indicate severe system instability potentially caused by an exploit.
* Suspicious activity related to configuration profiles (as a general post-exploitation vector).
* Sandbox violation messages, which could indicate an exploit attempting to break out of its restricted environment.
The output of each query is saved into a separate, descriptively named text file within a timestamped results directory, allowing for focused analysis of different types of potential artifacts.
## Prerequisites
1. **macOS Environment:** The `log show` utility and this script are intended to be run on macOS.
2. **iOS Log Archive (`.logarchive`):** You need an iOS system log archive (a bundle, which is technically a directory) from the device you intend to analyze. This can typically be obtained via:
* **Xcode:** Connect the iOS device to a Mac, open Xcode, go to Window -> Devices and Simulators, select your device, then click "View Device Logs" and "Export".
* **`sysdiagnose`:** Trigger a `sysdiagnose` on the iPhone (usually by pressing Volume Up + Volume Down + Side button simultaneously, but combinations can vary by model and iOS version). After the `sysdiagnose` is generated (it can take several minutes), it can be AirDropped to a Mac or accessed when syncing the iPhone with a Mac (often found in Finder under the iPhone's sync location within a `.tar.gz` file). The `.logarchive` will be within the extracted `sysdiagnose` contents.
3. **Bash Shell:** The script is written for `bash`.
## Setup and Execution
1. **Save the Script:**
Save the script code (provided above) as `airborne_artifact_extractor.sh` (or any other name with a `.sh` extension).
2. **Make it Executable:**
Open your Terminal application, navigate to the directory where you saved the script, and run the following command:
```bash
chmod +x airborne_artifact_extractor.sh
```
3. **Check macOS Quarantine Attribute (Important for downloaded scripts):**
If you downloaded this script from the internet, macOS might quarantine it, which can prevent it from running correctly or at all.
* To check if the quarantine attribute is set, run:
```bash
xattr airborne_artifact_extractor.sh
```
* If the output includes `com.apple.quarantine`, remove this attribute by running:
```bash
xattr -d com.apple.quarantine airborne_artifact_extractor.sh
```
If you still encounter issues running the script, especially if it's located in a directory like `~/Downloads`, ensure that your Terminal application has necessary permissions (e.g., "Full Disk Access" in System Settings -> Privacy & Security) to access the script's location and the log archive.
## Troubleshooting Execution Issues
### Bad Interpreter or `^M` errors (e.g., `/bin/bash^M: bad interpreter: No such file or directory`)
If you encounter an error like `bash: ./your_script_name.sh: /bin/bash^M: bad interpreter: No such file or directory`, `/usr/bin/env: โbash\rโ: No such file or directory`, or similar messages involving `\r` or `^M` characters when trying to execute the script, it's likely due to Windows-style line endings (CRLF - Carriage Return Line Feed) instead of Unix-style line endings (LF - Line Feed).
This usually happens if the script file was created or edited on a Windows system and then transferred to macOS or Linux without converting the line endings. Unix systems expect only LF as a line terminator, and the extra CR character (`\r` or `^M`) is misinterpreted as part of the interpreter path or commands.
**Solution: Convert Line Endings with `dos2unix`**
The easiest way to fix this is by using the `dos2unix` utility.
1. **Install `dos2unix`:**
* **On macOS (using Homebrew):**
If you don't have Homebrew, install it first from [brew.sh](https://brew.sh). Then run:
```bash
brew install dos2unix
```
* **On Debian/Ubuntu-based Linux distributions:**
```bash
sudo apt update
sudo apt install dos2unix
```
* **On Fedora/RHEL-based Linux distributions:**
```bash
sudo dnf install dos2unix # (or yum for older versions)
```
2. **Convert the script file:**
Navigate to the directory containing `airborne_artifact_extractor.sh` and run:
```bash
dos2unix airborne_artifact_extractor.sh
```
This command will convert the line endings in place.
**Alternative Solutions (if `dos2unix` is not available/preferred):**
* **Using `sed`:**
```bash
sed -i.bak 's/\r$//' airborne_artifact_extractor.sh
```
(This command modifies the file in place and creates a backup `airborne_artifact_extractor.sh.bak`. On some versions of `sed`, especially on macOS, the `-i` option requires an extension for the backup file, like `-i '.bak'` or `-i ''` for no backup if supported. For macOS, you might need `sed -i '' 's/\r//g' airborne_artifact_extractor.sh`)
* **Using `tr`:**
```bash
tr -d '\r' < airborne_artifact_extractor.sh > airborne_artifact_extractor_unix.sh
chmod +x airborne_artifact_extractor_unix.sh
# Then use airborne_artifact_extractor_unix.sh
```
* **Text Editors:**
Most modern text editors (like VS Code, Sublime Text, Atom, Notepad++) allow you to change line endings. Open the script file, find the setting for line endings (usually in the status bar or File/Edit menu), and change it from "CRLF" or "Windows" to "LF" or "Unix". Then re-save the file.
After converting the line endings, try running the script again. Remember to also ensure it has execute permissions (`chmod +x airborne_artifact_extractor.sh`).
## Usage
Execute the script from the Terminal, providing the path to the `.logarchive` bundle and optional time range parameters:
```bash
./airborne_artifact_extractor.sh /path/to/your/iphone_logs.logarchive [time_range_parameters]
Arguments:
R1 (Required): The full or relative path to the .logarchive file/bundle.
[time_range_parameters] (Optional): Standard log show time range parameters. If these are omitted, the script will default to analyzing the --last 7d (last 7 days) of logs.
Examples:
--last 24h (for the last 24 hours)
--last 3d (for the last 3 days)
--start "YYYY-MM-DD HH:MM:SS" --end "YYYY-MM-DD HH:MM:SS" (for a specific time range). Important: Ensure the date-time string is enclosed in quotes.
Timezone Configuration:
The script includes timezone settings at the top, which you can modify:
TZ_SETTING: Defines the timezone used for interpreting the --start and --end arguments you provide. For instance, if set to "Etc/GMT-7" (which corresponds to UTC+7), and you use --start "2025-04-10 00:00:00", this will be treated as midnight on April 10th in the UTC+7 timezone. If you want the script to use your Mac's current local timezone for these arguments, you can set TZ_SETTING="" or comment out that line.
TIMEZONE_DISPLAY: Specifies the timezone for formatting the timestamps in the output log files via the log show --timezone option. Example: "Asia/Bangkok" for UTC+7. Choose a timezone name recognized by your system.
Command Examples:
Analyze logs from the last 7 days (default behavior):
Bash
./airborne_artifact_extractor.sh /Volumes/ExternalHD/iOS_Logs/iPhone13_archive.logarchive
Analyze logs from the last 48 hours:
Bash
./airborne_artifact_extractor.sh ./My_iPhone_Sysdiagnose.logarchive --last 48h
Analyze logs for a specific date and time range (times will be interpreted according to TZ_SETTING):
Bash
./airborne_artifact_extractor.sh ../Log_Archives/device_XYZ.logarchive --start "2025-04-05 00:00:00" --end "2025-04-06 23:59:59"
Output Files
The script will create a new directory named airborne_traces_YYYYMMDD_HHMMSS (where YYYYMMDD_HHMMSS is the current date and time) in the same directory as the script (or your current working directory if the script's directory is not writable). Inside this folder, you will find several .txt files, each containing the output of a specific query. The filenames are prefixed with numbers for ordering:
01_critical_process_errors.txt: Faults and errors for critical processes.
02_process_termination_exceptions.txt: Unexpected terminations or exceptions in key processes.
03_kernel_panics.txt: Kernel panic events.
04_airplay_subsystem_errors.txt: Errors and faults in the AirPlay subsystem.
05_mdns_errors.txt: Errors and faults in mDNSResponder (Bonjour).
06_airplay_pairing_auth_failures.txt: Issues with AirPlay/rapportd pairing, authentication, or connections.
07_network_connection_errors.txt: Network connection errors from relevant processes.
08_networkd_errors.txt: Errors in the system networkd service.
09_sandbox_violations.txt: Messages related to sandbox violations.
10_profile_activity.txt: Activity related to configuration profiles.
Interpreting Results
Empty files are common: An empty output file means no log entries matched that specific query's criteria for the given time range. In many cases, this is a good sign, indicating the absence of those particular suspicious indicators.
Focus on patterns and correlations: A single isolated error message is often not indicative of a compromise. Look for clusters of errors, suspicious sequences of events across different log files, or errors that correlate with times you experienced unusual device behavior or were using potentially vulnerable services like AirPlay.
ECONNRESET in rapportd logs (often in 06_... or 07_...): These indicate abrupt TCP connection terminations. While they can be caused by benign network issues (poor Wi-Fi, router problems), in the context of investigating "Airborne" vulnerabilities, they warrant closer inspection. They could signify instability caused by an attempted exploit on your device or a peer device, or network interference.
Crashes (fault or panic types) in mediaserverd, AirPlayXPCHelper (often in 01_..., 02_...), or kernel panics (03_...) are generally strong indicators of system instability that could be exploit-related if they occur unexpectedly or during network interactions targeted by "Airborne".
Context is Key: Always review the log findings in conjunction with your knowledge of how the device was being used at the time, the network environment it was in, and any actual symptoms observed.
Contributing
Feel free to fork this repository, suggest improvements, report issues, or add more specific queries that could be helpful in identifying traces of such vulnerabilities.