iOS runtime mobile exploration with Objection, or Hack own application

Author: Andrey Batutin, Senior iOS Developer, DataArt.

More than once or twice, when I came to work (or just got out of bed), I found an angry letter in the mail, the essence of which was that nothing works in the app installation app, and everything needs to be fixed immediately.
')
Sometimes the cause was my jambs. Sometimes - my colleagues. And sometimes even Apple Inc itself .

But the most deadly scenarios were associated with bugs that were reproduced only on appstorovskih / release builds. Nothing baffles so much and makes you howl in front of the MacBook, like the inability to connect a debugger to its own application and see what happens there.

APNS and its troubleshooting on release / ad-hoc builds create similar difficulties.
On those builds where there is a production APNS environment, you cannot connect a debugger.
On those assemblies where there is a debager, there is no APNS production-push. But they usually fall off.

Apple, like the Old Testament god, with one hand gives a platform where the jailbreak will soon go down in history (and piracy in the App Store remains at the level of statistical error), and the other makes the developer feel like a poor relative, little Oliver Twist, who dared to ask for more porridge.

Voice-over: "Uncle Apple, please give me another distribution certificate ..."

For an average programmer to do something with the release / appstorovskoy build iOS-application was almost unreal. It was easier to quit before the release.

In short:

The release build is signed by the Distribution Certificate and uses the Distribution Provisioning Profile. Entitlement does not allow attachment of debugger to the application process. Plus, when downloading ipa from the App Store, the binary is also encrypted. App Extensions are signed separately.

That is, the application author seems to be able to take and re-sign the App Store assembly with a certificate using a debugging provisioning profile. But it still needs to know how to do it. But even after that, the question of how to connect the debager to the application process remains open.

Therefore, it is necessary to focus solely on the fact that it is not adjusted at the design stage. And catch all the bugs before the application goes to the App Store. And logs, more logs for the god of logs!

But recently a new hope has loomed on the horizon.

In the previous part, we met Frida, a wonderful framework for dynamic code injection. And SSL-pinning bypassed it in the wonderful FoodSniffer project.

In this article we will introduce the framework created on the basis of Frida, which greatly facilitates the manipulation of the release assemblies of iOS applications.

Objection

Objection allows you to inject FridaGadget into an iOS assembly and re-sign it with the necessary certificate and provisioning profile.

Training

First we need the release assembly FoodSniffer.

Important note - when creating ipa, disable “Include bitcode for iOS content”.

Then we will need a provisioning profile for the assembly.

To get it:

Install the application via Xcode on the device.
Find FoodSniffer.app in the Finder.
Go to the FoodSniffer bundle.
Copy embedded.mobileprovision from there to the folder with your release ipa.

You should have something like this:

After this, install objection according to the instructions . I strongly recommend using the virtualenv option.

In addition to objection, we need ios-deploy to run the patched application on the device.

Reware the app!

In the terminal, find out the hash of the code sign identity we need:

security find-identity -p codesigning -v

We are interested in the 386XXX identity, since it is the one that corresponds to the debit serial certificate with which the application was signed when installed via Xcode, from which we got the provisioning profile.

Register FridaGadget and re-sign our application:

objection patchipa --source FoodSniffer / FoodSniffer.ipa --codesign-signature 386XXX --provision-file embedded.mobileprovision

As a result, we should get FoodSniffer-frida-codesigned.ipa .

Now we need ios-deploy to install and connect to FridaGadget. This is an important step - if you simply install ipa on your device via iTunes or Xcode, you will not be able to connect to FridaGadget.

Before unpacking FoodSniffer-frida-codesigned.ipa :

unzip FoodSniffer-frida-codesigned.ipa

Run our patched application on the device:

ios-deploy --bundle Payload / FoodSniffer.app -W -d

If everything went well, then the application should start on the device, and in the terminal we will see:

Now, in another tab of the terminal, we connect objection to FridaGadget:

objection explore

Profit!

Objection provides

SSL Pinning Bypass

Everything is simple:

ios sslpinning disable

Now you can easily use the Proxy Server to monitor the traffic of our application, as described in the first part .

Dump UserDefaults

ios nsuserdefaults get

At the end of the dump we should see “mood_state” = “I'm hungry”

Dump app keychain

ios keychain dump

And here is our super secret password.

Fetching data from SQLite database.
In the application I added the sqlite-database chinook.db from here .

Objection allows you to make requests directly to the database as follows.

Connection to the database:

sqlite connect chinook.db
Request to her:

sqlite execute query select * from albums

Conclusion

Objection and Frida finally allow you to work relatively normally and simply with Ad Hoc and Distribution assemblies of iOS applications. They return to the programmer the power over their own application, hidden behind the layers of protection with which Apple so carefully wraps iOS apps. Plus Objection and Frida work on non-jailbroken devices. In addition, they are relatively easy to use.

With them I have a hope of make iOS development great again. Safely avoiding undermining the new Apple headquarters from the inside.