bagbak

fix

• Some malformed app bundles might have executables that don't have executable mode https://github.com/chichou/bagbak/issues/105

features

• add command line option to enable debug logging
• add command line option to dump raw files without packing to ipa

This is a huge update.

From this version, I totally gave up the approach to transfer files using frida. It does not require extra dependencies, but this approach does not always meet my expectation.

Some processes (e.g. AppExtensions) have very limited resource, especially memory limits (jetsam). I got so many users reporting that they saw unexpected termination during the dump process.

I didn't like the approach using external tools like iproxy and scp. It involves sub process creation and it's not easy to handle all the corner cases. Besides, to use hard-coded credentials (on iOS, that's root/alpine) on ssh, you need sshpass. One more dependency!

Thanks to oleavr, frida now has a lightweight libimobiledevice-like api that allows me to implement the whole workflow (iproxy and ssh) in javascript. To be fair, this layer only works good with USB connection, while the C libimobiledevice supports wireless too. I always have a tethered environment so it's not a big deal.

Now the workflow has changed a lot from v3.0.0.

Prior v3:

1. Spwan the main executable of app, inject the 1st stage agent
2. Enumerate and send all files to the computer
3. Enumerate app extensions
4. Inject the 2nd stage agent to pkd to do some nasty patch to launch arbitrary extension
5. Get pids from extensions and inject them one by one

This workflow is so complicated. Even if I manage to implement it, it becomes more and more unstable.

Back then I had no choice but this strategy. I remember there were users asking for support for AppExtension, so I tried to directly spawn an extension process. It failed. I don't remember the specific error, but it might related to XPC.

Even today, if you try to directly run a XPC service in the terminal on your mac, you only get this error message:

➜  ~ /System/Library/PrivateFrameworks/CoreEmbeddedSpeechRecognition.framework/Versions/A/XPCServices/com.apple.siri.embeddedspeech.xpc/Contents/MacOS/com.apple.siri.embeddedspeech
An XPC Service cannot be run directly.
[1]    29433 abort

So I had to inject some shady hooks to pkd and use the racy NSExtension API to spawn the process.

However, recently I revisited the idea with spawn method, it worked. Now I don't have to maintain a complex workflow and hack system deamons. Simply run the target is enough.

The new workflow since v3.0.0:

1. It does not require you to configurate iproxy, it's included in my implementation
2. There is a port scanner that automatically detects the SSH server on your device, either OpenSSH or dropbear (bundled with checkra1n)
3. A handmade scp to pull files from app. I found that the miminal jailbreak environment does not include a proper sftp server, so I have to research and implement the undocumented legacy scp protocol
4. Scan the local copy of the app bundle to find which binaries are encrypted. In the previous versions (including all other similar tools), they all blindly dump all frameworks.
5. Only spawn the corresponding process (main or extension) and decrypt the binary on demand.

Another benifit is that the new implementation is totaly headless. You don't need to unlock the device and make the target app as the frontmost anymore. I even tried dumping multiple apps at the same time, and it seemed to work except the SSH over USB bandwidth is limited.

The new version has been tested on 16.x (checkm8, rootless) and 14.x (Unc0ver, with rootfs and Cydia).

Upgrade to frida@16

v1.6.0: fix a long standing bug that may cause serialization failure