Dev:Cydia Substrate

MobileSubstrate is the de facto framework that allows 3rd-party developers to provide run-time patches (“MobileSubstrate extensions”) to system functions, similar to Application Enhancer on the OS X.

MobileSubstrate consists of 3 major components: MobileHooker, MobileLoader and safe mode.

MobileHooker
MobileHooker is used to replace system functions. This process is known as hooking. There are 2 APIs that one would use: MSHookMessage will replace the implementation of the Objective-C message -[class selector] by replacement, and return the original implementation. To hook a class method, provide the meta class retrieved from objc_getMetaClass in the MSHookeMessage(Ex) call and see example note below. This dynamic replacement is in fact a feature of Objective-C, and can be done using method_setImplementation. MSHookMessage is not thread-safe and has been deprecated in favor of MSHookMessageEx

MSHookFunction is like MSHookMessage but is for C/C++ functions. The replacement must be done at assembly level. Conceptually, MSHookFunction will write instructions that jumps to the replacement function, and allocate some bytes on a custom memory location, which has the original cut-out instructions and a jump to the rest of the hooked function. Since on the iPhoneOS by default a memory page cannot be simultaneously writable and executable, a kernel patch must be applied for MSHookFunction to work.

As of the latest version of MobileSubstrate, MSHookMessage also requires a kernel patch for supercall closures to hook all methods properly.

Example code
Using MSHookFunction:

Using MSHookMessageEx: Note that if you are hooking a class method, you have to put a meta-class in the class argument, e.g.

Using MSHookFunction to hook private functions (in this case a C++ Method): Because we want the pointer to a private symbol we have to use nlist.

MobileLoader
MobileLoader loads 3rd-party patching code into the running application.

MobileLoader will first load itself into the run application using DYLD_INSERT_LIBRARIES environment variable. Then it looks for all dynamic libraries in the directory /Library/MobileSubstrate/DynamicLibraries/, and dlopen them. An extension should use constructor code to perform any works, e.g.

Developers may add filters to restrict whether the extension should be loaded or not. Filters are implemented as plist that lives beside the dylib. If the dylib is named foo.dylib, then the filter should be named foo.plist. The filter should be a dictionary with key Filter, which is another dictionaries that can contain these keys:
 * CoreFoundationVersion (array): The extension is loaded only if the version of CoreFoundation.framework is above the specified values. Currently, only the first 2 values are checked.
 * Bundles (array): The extension is loaded only if the bundle-ID of the running application matches the list.
 * Classes (array): The extension is loaded only if the one of the specified objective-C classes is implemented in the application.
 * Executables (array): The extension is loaded only if one of the executable names matches the running application. This is required to hook things that have no other identifiable characteristics.

For example, to restrict the extension only load in, the plist would look like Filter = { Bundles = (com.apple.springboard); };

You can also use this method to restrict the extension to only load into applications that link to a specific bundle, such as UIKit. For example: Filter = { Bundles = (com.apple.UIKit); };

Finally, you can also specify an extension to be loaded into a set of applications, like this: Filter = { Bundles = ( "com.apple.MobileSMS", "net.whatsapp.WhatsApp" ); };

In general the rule is that if you are using more than one filter (example: Executables and Bundle) all filters have to match. You can change that by using Mode = "Any".

Filter = { Executables = ("mediaserverd",); Bundles = ( "com.apple.MobileSMS", "net.whatsapp.WhatsApp" ); Mode = "Any"; };

In addition, MobileLoader also hooks nlist to improve its performance, and defines several signal handlers for safe mode.

For setuid apps, since all inserted environment variables are ignored, the developer of the App must explicitly dlopen("/Library/MobileSubstrate/MobileSubstrate.dylib") to let MobileLoader run.

Safe mode
When a extension crashed the SpringBoard, MobileLoader will catch that and put the device into safe mode. In safe mode all 3rd-party extensions will be disabled.

The following signals will invoke safe mode:
 * SIGTRAP
 * SIGABRT
 * SIGILL
 * SIGBUS
 * SIGSEGV
 * SIGSYS