File size: 6,430 Bytes
b4ec2f6
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
# iOS Protocol Guide

## Overview

This document describes the iOS protocols used by iOSDiag for device communication and diagnostics.

## USBMUX Protocol

### Purpose
Direct USB communication with iOS devices via the usbmuxd daemon.

### Connection Flow
1. Connect to usbmuxd socket (typically `/var/run/usbmuxd`)
2. Send HELLO message
3. Receive HELLO response
4. Send LISTEN message to monitor device events
5. Receive DEVICE_ATTACHED/DETACHED messages
6. Send CONNECT message to establish device connection
7. Receive RESULT message with status

### Message Format
```
Header (16 bytes):
  - Length (4 bytes, little-endian)
  - Version (4 bytes, little-endian)
  - Message Type (4 bytes, little-endian)
  - Tag (4 bytes, little-endian)

Payload:
  - Variable length based on message type
```

### Message Types
- `HELLO` (1): Initial handshake
- `DEVICE_ATTACHED` (2): Device connected
- `DEVICE_DETACHED` (3): Device disconnected
- `RESULT` (4): Operation result
- `LISTEN` (5): Listen for device events
- `CONNECT` (6): Connect to device
- `LISTEN_PAIR` (7): Listen for pairing events
- `PAIR_RECORD` (8): Pairing record

## Lockdown Protocol

### Purpose
Device configuration, service management, and pairing.

### Connection Flow
1. Establish USBMUX connection to port 62078
2. Send StartSession request
3. Receive StartSession response with session ID
4. Send service requests (GetValue, SetValue, StartService, etc.)
5. Receive responses

### Message Format
Plist-based messages over SSL/TLS:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Request</key>
    <string>GetValue</string>
    <key>Domain</key>
    <string>com.apple.mobile.battery</string>
    <key>Key</key>
    <string>BatteryCurrentCapacity</string>
  </dict>
</plist>
```

### Common Requests
- `GetValue`: Retrieve device property
- `SetValue`: Set device property
- `StartService`: Start a service
- `StartSession`: Begin session
- `StopSession`: End session
- `Pair`: Establish pairing
- `ValidatePair`: Verify pairing

### Common Domains
- `com.apple.mobile.battery`: Battery information
- `com.apple.mobile.device_name`: Device name
- `com.apple.mobile.firmware`: Firmware version
- `com.apple.mobile.hardware`: Hardware information
- `com.apple.mobile.system_services`: System services

## DiagnosticsRelay Protocol

### Purpose
Access hardware diagnostics and system information.

### Connection Flow
1. Establish Lockdown connection
2. Request DiagnosticsRelay service
3. Send diagnostic requests
4. Receive diagnostic responses

### Message Format
Plist-based messages:
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>Request</key>
    <string>Query</string>
    <key>Diagnostics</key>
    <array>
      <string>com.apple.mobile.battery</string>
      <string>com.apple.mobile.thermal</string>
    </array>
  </dict>
</plist>
```

### Common Diagnostics
- `com.apple.mobile.battery`: Battery metrics
- `com.apple.mobile.thermal`: Thermal information
- `com.apple.mobile.nand`: Storage health
- `com.apple.mobile.wifi`: Wi-Fi diagnostics
- `com.apple.mobile.power`: Power information

## CrashReport Protocol

### Purpose
Retrieve crash logs and panic information.

### Connection Flow
1. Establish Lockdown connection
2. Request CrashReportCopy service
3. Send file list request
4. Receive file list
5. Request individual files
6. Receive file contents

### File Locations
- `/var/mobile/Library/Logs/CrashReporter/`: Crash logs
- `/var/mobile/Library/Logs/panic.log`: Panic logs
- `/var/mobile/Library/Logs/system.log`: System logs

## Syslog Protocol

### Purpose
Stream system logs in real-time.

### Connection Flow
1. Establish Lockdown connection
2. Request Syslog service
3. Receive log messages as they occur
4. Parse and process messages

### Message Format
Text-based log entries:
```
<timestamp> <hostname> <process>[<pid>]: <message>
```

## CoreDevice Protocol

### Purpose
Network-based communication for newer iOS versions.

### Connection Flow
1. Establish network connection to device
2. Send CoreDevice handshake
3. Establish secure tunnel
4. Send requests through tunnel
5. Receive responses

### Advantages
- Network-based (no USB required)
- Supports multiple simultaneous connections
- Lower latency for repeated operations

## Pairing Process

### Overview
Devices must be paired before accessing sensitive services.

### Pairing Flow
1. User accepts pairing prompt on device
2. Device generates certificate
3. Host generates certificate
4. Certificates are exchanged
5. Pair record is stored locally
6. Future connections use stored pair record

### Pair Record Format
```json
{
  "DeviceCertificate": "base64-encoded-certificate",
  "HostCertificate": "base64-encoded-certificate",
  "HostPrivateKey": "base64-encoded-private-key",
  "HostID": "unique-host-identifier",
  "RootPrivateKey": "base64-encoded-root-key",
  "RootCertificate": "base64-encoded-root-certificate",
  "SystemBUID": "device-unique-identifier"
}
```

## Error Handling

### Common Errors
- `InvalidRequest`: Malformed request
- `InvalidResponse`: Unexpected response format
- `ServiceNotAvailable`: Service not running
- `InvalidService`: Service doesn't exist
- `PermissionDenied`: Insufficient permissions
- `DeviceNotFound`: Device disconnected
- `PairingRequired`: Device not paired

### Retry Strategy
- Exponential backoff: 100ms, 200ms, 400ms, 800ms, 1600ms
- Maximum retries: 5
- Timeout: 30 seconds per request

## Security Considerations

### SSL/TLS
- Lockdown uses SSL/TLS for encryption
- Certificate pinning for device verification
- Mutual authentication

### Cryptography
- RSA-2048 for key exchange
- AES-128-CBC for encryption
- SHA-256 for hashing

### Authentication
- Pairing-based authentication
- Session tokens
- Request signing

## Performance Optimization

### Connection Pooling
- Reuse connections when possible
- Lazy connection establishment
- Connection timeout management

### Pipelining
- Send multiple requests without waiting for responses
- Batch operations
- Parallel service access

### Caching
- Cache device properties
- Cache service availability
- Cache pair records

---

**Last Updated**: 2026-02-10  
**Version**: 1.0.0