Technical analysis of TrollRestore and CVE-2024-44252 in iOS

Overview

TrollRestore uses CVE-2024-44252 to install TrollStore on affected iOS devices. The vulnerability is in the MobileBackup2 restore path and allows crafted backup entries to escape the expected restore domain.

This article describes the relevant iOS components, the backup structure used by the tool, and the security impact of the path traversal issue. It focuses on the data flow and trust boundary failure rather than on operational use.

Introduction

iOS uses code signing, sandboxing, entitlements, and system integrity protections to restrict what apps can install or modify. CVE-2024-44252 affects that model through the MobileBackup2 service, which processes backup and restore data from a trusted host connection.

TrollRestore targets that restore path to place a helper where normal app sandbox restrictions would not allow it. Understanding the issue requires looking at MobileBackup2 domains, restore metadata, and how path validation failed.

Background

iOS security model

iOS implements a multi-layered security architecture:

• App sandbox: Each app runs in its own isolated environment with limited access to system resources
• Code signing: All executable code must be signed by Apple or a trusted developer
• System integrity protection: Prevents modification of system files and directories
• Entitlements: Controls what resources an app can access

MobileBackup2 service

MobileBackup2 handles device backup and restore operations. It is exposed as com.apple.mobilebackup2 through the iOS lockdown protocol, which authenticates a host computer before allowing access to device services.

Domain types in iOS

iOS uses different domain types for file access:

• AppDomain: For regular app installations, with limited system access
• SysContainerDomain: For system container access, with elevated privileges

The vulnerability: CVE-2024-44252

CVE-2024-44252 is a path traversal vulnerability in the MobileBackup2 service. The issue allowed a crafted restore payload to:

1. Use path traversal after the SysContainerDomain- prefix.
2. Follow symlinks in the SysContainerDomain domain.
3. Write files to protected system directories.

The root cause is insufficient path normalization and validation when MobileBackup2 handled paths under the SysContainerDomain- prefix.

Restore methodology

Target selection

TrollRestore selects a target system app and retrieves its UUID and bundle path from the device. The target must be replaceable without breaking core device behavior, while still providing the privileges needed by the helper.

Backup structure creation

The tool creates a specially crafted backup structure using a custom Backup class:

backup.Directory("", "RootDomain"),
backup.Directory("Library", "RootDomain"),
backup.Directory("Library/Preferences", "RootDomain"),

The backup also includes a temporary file containing the helper payload:

backup.ConcreteFile("Library/Preferences/temp", "RootDomain",
    owner=33, group=33, contents=helper_contents, inode=0),

A key component is the path traversal entry:

backup.Directory(
    "",
    f"SysContainerDomain-../../../../../../../../var/backup/var/containers/Bundle/Application/{app_uuid}/{app}",
    owner=33,
    group=33,
),

The SysContainerDomain- prefix causes MobileBackup2 to treat the entry as a system container path. The traversal sequence then escapes the expected container boundary and points the restore operation at the target app container.

Backup file generation

The backup structure is converted into actual files:

1. Individual files are written with SHA1-derived names based on their backup domain and path. MobileBackup2 uses those deterministic identifiers to locate records during restore.

2. Manifest.mbdb is generated with records for each file.

3. Status.plist, Manifest.plist, and Info.plist are created. These files describe backup state, structure, and metadata.

Restore process

The restore process is initiated with specific parameters:

mb.restore(backup_dir, system=True, reboot=False, copy=False, source=".")

During the restore process, the MobileBackup2 service:

1. Reads the Manifest.mbdb to understand the backup structure
2. Processes each file according to its domain and path
3. For files with the SysContainerDomain- prefix:
   • Recognizes the prefix as a system container path
   • Processes the path traversal (../../../../../../../../)
   • Writes the file to the target location

The deliberate error

A critical behavior is the deliberate error that occurs during restore:

1. Premature termination: The error stops the restore before later verification or cleanup steps run.

2. State manipulation: The file-write stage has already completed, so the device is left in an intermediate state.

The files and directories are already written to the device before the error occurs. The restoration process in iOS works in stages:

1. Preparation
2. File Transfer
3. File Writing
4. Verification
5. Completion

By triggering an error after file writing but before completion, the process leaves restored files in place without completing the normal restore lifecycle.

This behavior bypasses several iOS security measures:

1. System integrity: It modifies system files that should be protected
2. App sandbox: It bypasses the app sandbox restrictions
3. Code signing: It replaces signed system apps with unsigned code

Conclusion

TrollRestore shows how a restore service can become a privilege boundary when it accepts structured data from a trusted host. The vulnerable behavior is not the backup format itself, but the service’s failure to keep restored paths inside the intended domain.

The defensive lesson is straightforward: normalize paths before authorization, reject traversal after domain prefixes are resolved, and validate final filesystem targets before writing restored content.