How To Inject A Dylib Into An Ios App With Optools
Dimitri Rajawi
I tried to inject my own library into an iOS binary(ipa) file. But I was not able to do it. This question may have suggestions in this site, but there is no proper solution. I already tried implementing some of the solutions or suggestions mentioned in the below links,
I tried the to insert a load command of a library as per documentation mentioned in optool. which actually expects run time arguments. So I included the below arguments under Arguments section of Xcode,
dyci-main is a code injection tool through which we can not add or insert library. This will be helpful for adding or modifying some logics or debugging purpose. Apart from that we can not do anything I hope. If any body having an idea to insert load command is greatly appreciated.
injecting-code-to-a-ipa is having some sort of solution but it is not clear. Even if you follow each and every steps you can't make it success. The main confusing part is some command load instruction we must execute as per screenshot and have to save as dynamic library. Which is the input file to execute commands? If you are able to make it successful, please let me know.
I have used OpTool and it worked for me. I was more interested to insert load command for dynamic library and below is command line arguments i have setup.install -c -p -t ex. install -c load -p "@executable_path/LibraryName.dylib" -t "/Users/xxx/AppName.app/AppName"
-load : It is variable we have to give to insert LC_LOAD_DYLIB-payload : it should be always in format of "@executable_path/name of Library.dylib" since we will be copy pasting .dylib file into myapp.app directory.- target : here need to mention the full path of executable binary. which will be contained in myapp.app directory
Jailbreaking iOS getting harder with every new version released, repacking and resigning iOS applications to be sideloaded on non-jailbroken iOS device has been a subject that has generated significant interest from security researchers in recent years. Sideloading applications is restricted on non-jailbroken devices due to several codesigning enforcements implemented in the iOS kernel. This is done in order to prevent malicious actors from distributing and running untrusted code on unsuspecting user's devices. These codesigning enforcements in conjunction with Apple's AppStore application review process has done a great deal in preventing malicious applications being distributed to iOS users.
Whilst these measures make it harder for attackers to target AppStore users, they also make it harder for security researchers to independently evaluate the security of iOS applications. There are several reasons why security researchers would want to sideload applications. The two most common reasons are:
There have been some notable research and blog posts that address the problem of repacking and resigning applications to be deployed on non-jailbroken devices. However, the referenced research either lacked sufficient detail or only demonstrate trivial examples of repacking and resigning iOS applications.
These limitations lead to the creation of this guide, which addresses the repackaging and resigning of applications with varying build configurations on non-jailbroken devices. In particular, the repackaging and resigning of the following build configurations will be addressed:
In order to get started a researcher would need to setup a workspace with appropriate tooling. A jailbroken iOS device to decrypt applications from the AppStore and a non-jailbroken iOS device to sideload the repackaged application.
For the purpose of this guide a iPod Touch 6th gen running iOS 10 that was jailbroken using Saigon beta2 and a non-jailbroken iPhone 6s running iOS 11. It should be noted that both the jailbroken and non-jailbroken device are 64bit devices.
MacOS is required to perform a number of operations required to repack an iOS application. This includes tools like Xcode, otool and codesign. At the time of writing, the author was not aware of FOSS alternatives that would reliably achieve the same operations required to repack iOS applications. However, should FOSS tools be available in the future, this guide will be updated to use them.
In order to demonstrate patching an application with custom code, this guide makes uses Frida server bundled as a shared library commonly referred to as FridaGadget. When the patched application is spawned, it would load the dylib that launches Frida server. One can then connect to this server and being instrumenting the application.
To install repacked applications onto the target device, one of the several options available is idevice* utilities. This guide uses ideviceinstaller, ideviceimagemounter and idevicedebug to install and run repacked applications. The utilities ideviceimagemounter and idevicedebug are only required to spawn an application using debugserver.
Downloading iOS application bundles (IPAs) from the AppStore can be accomplished using iTunes 12.6. It should be noted that newer versions of iTunes do not support downloading applications from the AppStore. One can download iTunes 12.6 from the following link. For the first repacking demonstration, Simple Notepad, a trivial note taking iOS application is used to get the reader familiar with six steps to repacking applications briefly described in Methodology section.
Unpacking the Simple Notepad IPA using unzip or a similar utility reveals a single MachO executable binary named "Plain Notes". The following snippet shows the layout of MachO binaries within the Simple Notepad application bundle:
There are several automated solutions created to decrypt AppStore binaries such as Clutch, dumpdecrypted or dump-ios. However, some of these automated solutions struggle to cope with applications that implement binary protections such as debugger detection and/or hooking detection. Which is why it is sometimes necessary to decrypt binaries manually. An excellent guide on decrypting AppStore binaries can be found at the following link.
The first step to decrypting the Simple Notepad is to setup debugserver to intercept and attach to the application when it is launched. The following code snippet demonstrates setting up debugserver to attach to the Simple Notepad application:
Once debugserver has been setup and has intercepted the launch of Simple Notepad, connect to the debugserver instance using lldb. To locate the decrypted image in memory one would need to know the size of the image and the image offset. Offsets can be gathered from inspecting the load commands of the application binary using otool:
Due to system wide ASLR enforced on iOS, it is necessary to locate the base address of the image in memory and then compute the offset from that address. This can be done once lldb is connected to debugserver and is attached to the process:
The count parameter is the cryptsize value and the offset to the decrypted section is the base address + cryptoffset. Once we've dumped the decrypted memory region, we then need to splice this into the original AppStore binary. iOS applications downloaded using iTunes, typically contain multi arch FAT binaries. In order to patch the binary correctly, one would first have to locate the offset for the arm64 architecture using otool:
Using the offset of the encrypted section from the encryption information and the offset of the arm64 arch within the FAT binary, use dd to splice the decrypted image into the original binary. The seek value shown below is the sum of the two offset values i.e cryptoff + offset in the FAT binary:
Once patched, set the cryptid value to 0, this can be done by loading the patched binary into MachO-View, selecting the right architecture and Load command and updating the value as shown in the following screenshot:
Copy the FridaGadget.dylib and FridaGadget.config to the unzipped IPA, within the Payload/Plain Notes.app/ directory. The unpacked bundle with the decrypted application binary and FridaGadget should look as follows:
The values of address and port can be configured to any interface and port accessible on the target device. This will be the interface and port the Frida server will be listening on when spawned via the repacked application.
Having patched the application binary to load the custom dylib i.e. FridaGadget. Begin the process of signing the application binaries to be sideloaded on our target non-jailbroken device. The first step in that process is to generate a provisioning profile for the target device. This is achieved by created an empty Xcode project and that targets the non-jailbroken device.
Before building this project, one would typically require to add an AppleID to Xcode which would then generate and manage signing certificates for the application. The AppleID could be one associated with a free developer account or one that is part of the Apple Developer Program. Setting up an an AppleID on Xcode can be done via the menu; Preferences > Accounts.
The signing cert used is shown in the screenshot below:
Note: If when building the empty project, you happen to deploy it to the device, then make sure you delete it before sideloading the repackaged application.
The next step is to extract the provisioning profile from this empty project and reuse it to repack our target application. This provisioning profile is located under:
The entitlements.plist file contains the entitlements required by the application binary to work on a non-jailbroken iOS environment. These entitlements.plist will be used at a later stage in the resigning process to sign the application binary.
The next step is to update the Bundle Identifier of the Simple Notepad app to the bundle identifier of the Provisioning Profile generated in the previous section. In this example the bundle identifier within the Provisioning Profile is "com.example.amarekano.repackdemo". Update the Info.plist file within the Payload/Plain Notes.app directory of the unpacked application with the following command:
7fc3f7cf58