MobileDevice Library is used by iTunes to transfer data between iPhone and computer over both USB and WiFi connections.
MobileDevice.framework
macOS: MobileDevice.framework
- Location: /System/Library/PrivateFrameworks/MobileDevice.framework
- Export command:
nm /System/Library/PrivateFrameworks/MobileDevice.framework/Versions/A/MobileDevice
Windows: MobileDevice.dll
| iTunes Version | AMDS location | AAS location | 32-bit DLLs | 64-bit DLLs | |
|---|---|---|---|---|---|
| 32-bit iTunes | 64-bit iTunes | ||||
| 7.0 - 7.5 | Use hardcoded path (iTunesMobileDevice.dll) |
Use hardcoded path | Yes | — | — |
| 7.6 - 8.2 | Yes | Yes | |||
| 9.0 - 12.0 | Use registry key (MobileDevice.dll) |
Use registry key | |||
| 12.1 - 12.4 | Only with "older video cards" variant | ||||
| 12.5 | No | ||||
| 12.6 - 12.10.8.5 | Yes | ||||
| 12.10.9.3 - | Use AMDS registry key | ||||
For iTunes 7.0 - 8.2, load the dll directly from %ProgramFiles%\Common Files\Apple\Mobile Device Support\iTunesMobileDevice.dll. Supporting CoreFoundation.dll (used for CFStringRef, CFPropertyListRef management) is located at the same path.
Starting with iTunes 9.0, the location of MobileDevice.dll (no longer prefixed with "iTunes") is stored in InstallDir registry value under HKLM\SOFTWARE\Apple Inc.\Apple Mobile Device Support registry key, and CoreFoundation.dll is stored in InstallDir registry value under HKLM\SOFTWARE\Apple Inc.\Apple Application Support registry key.
Starting with iTunes 12.1, the 64-bit variant of iTunes (identified by an installer filename of iTunes6464Setup.exe) includes only 64-bit binaries. This breaks compatibility with third-party 32-bit tools, as the 32-bit dlls they require simply no longer exist. Between iTunes 12.1 and 12.4, due to a bug where 64-bit iTunes would fail to play video on certain graphics cards, a "64-bit - for older video cards" variant (iTunes64Setup.exe) was separately made available on the Apple Support website, which restored the full set of 32-bit binaries. No "older video cards" release was made for iTunes 12.5. This change was rolled back with iTunes 12.6.
Starting with iTunes 12.10.9.3, Apple Application Support was merged into Apple Mobile Device Support. Hence, paths and registry keys relating to Apple Application support no longer exist. Should your program find these paths not exist, you can assume CoreFoundation.dll can be found at the same path as Apple Mobile Device Support.
Library Interfaces
- libimobiledevice provides the same functionality on Linux
- mobiledevice - command line utility for interacting with MobileDevice Framework
- SDMMobileDevice - macOS framework written in C that can be used interchangeably with Apple's private framework MobileDevice.framework
- MobileDeviceAccess - similar to above, but written in Objective-C
- MobileDevice.h - old reverse engineered header for interfacing with MobileDevice library
Private Functions
Obtaining address
In order to obtain the address of a usable private function in MobileDevice, you will have to be able to understand x86-64 assembly to reverse engineer it. These methods differ slightly based on platform due to how dynamically linked libraries handle position independent code.
Mac OS X (MobileDevice.framework)
A private function is not marked as exported in the mach-o symbol table. This means it cannot be called by simply linking against the library. To call unexported functions, the mach-o symbol table must be stepped through manually to find the offset of a particular function call. Calls can be verified by checking against the offset of the name inside the name table.
Windows (MobileDevice.dll)
Unlike OS X's dynamically linkable libraries, Windows dynamic libraries do not support position independent code in the same manner. A private function will not have its name in the exported symbol table, so in a debugger, like GDB, it will show up as part of another function. However, you will know that it is a separate function as a new stack frame is set up.
Known Error Codes
MobileDevice Error Code Listing
|
|---|
|
For the latest error codes you can look at the pseudo-code of AMDErrorString.
MobileDeviceUpdater
Since at least macOS High Sierra (possibly as early as the introduction of System Integrity Protection in OS X El Capitan), MobileDevice handles its own updates. When a device unknown to the currently installed build of MobileDevice is connected, MobileDeviceUpdater.app prompts the user to install a software update. Previously, MobileDevice would only be updated by installing a full iTunes or Xcode update.
Due to System Integrity Protection, AMDS is installed to /Library/Apple/System/Library/PrivateFrameworks/MobileDevice.framework, which is symbolically linked to from /System/Library/PrivateFrameworks/MobileDevice.framework. Apps that use MobileDevice will use the new build upon next launch.
Additionally, extra bundles may be installed to /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/CoreTypes-nnnn.bundle and /System/Library/CoreServices/CoreTypes.bundle/Contents/Library/MobileDevices-nnnn.bundle, registering icons for new devices unknown to the current base operating system. This includes Mac devices.