[0x06c] Add Patching Example for Debugging iOS Apps

[su-vikas]

Added content on how to patch an iOS app to make it debuggable.

This PR closes #1375 .

[sushi2k]

Thanks for the PR!

We should we give more detailed instructions, or even link to a blog where it is described technically in detail. Can you share an example of how the entitlements file should look like? For example:

<dict>
<key>com.apple.security.get-task-allow</key>
<false/>
</dict>

[su-vikas]

Thanks @sushi2k. Slightly busy for next few days, will update it once I get some time to spare.

[cpholguera]

When reviewing this I noticed a bit of confusion in the chapter. We are maintaining the patching/signing manual steps in different sections and it gets complicated. Why don't we remove the manual steps? It will be hard to keep up with the changes in the repackaging process. This also solves @sushi2k's comment.

I propose a cleanup. The following should be done:

1. Go to section "Dynamic Analysis" and re-work the paragraph , remove the section "Dynamic Analysis on Non-Jailbroken Devices" and replace it with a sentence linking to the section "Patching, Repackaging, and Re-Signing".

2. Go to section "Patching, Repackaging, and Re-Signing" and simplify it as well:

Remove both "Patching Examples" and replace them with an introduction about patching, why would you need to patch an app?

a) to make some permanent changes in the app binary (e.g. changing some byte value?
b) to include the Frida-Gadget to be able to use Frida from non-jailbroken devices or to include some permanent changes in the Frida-Gadget so that they are always dynamically applied when starting the app (e.g. a permanent jailbreak detection bypass) instead of you having to attach to the app from a computer and using e.g. objection to bypass the jailbreak detection.
c) to "make the app debuggable", e.g. when following objection's instructions for Patching-iOS-Applications below, be sure to include the get-task-allow entitlement in the generated embedded.mobileprovision. This allows other processes (like a debugger) to attach to the app.

Then in "Repackaging and Re-Signing", we can simply say that the preferred way is the automated way (use the content deleted in step 1. "Automated Repackaging with Objection"), that is, to use objection to patch the app and if you want to learn more about how it is done manually we refer to the objection patcher code.

I'd refer to Objection's Wiki:
https://github.com/sensepost/objection/wiki/Patching-iOS-Applications
https://github.com/sensepost/objection/wiki/Running-Patched-iOS-Applications

And for curious people that want to do it manually (for some reason) there is this well-maintained code:
https://github.com/sensepost/objection/blob/master/objection/utils/patchers/ios.py

What do you think? I know it sounds like a lot but I think it can be done very quickly actually. Please let me know if I can help you with something.

[su-vikas]

@cpholguera agreed, I will try to do it in coming days.

[cpholguera]

Awesome, thanks a lot!

[su-vikas]

Hi @cpholguera

I was thinking on the part of having only automated approach (using objection) and removing manual one.

Personally I prefer to present the manual approach and then tell that there is an automated approach as well, in this case using Objection. With the basics, it helps to debug weird patching issues as well and for the curious it gives a good idea about things happening underneath all the automation.
I feel in this guide we do discuss lot of manual steps (various commands etc) and thus will be inline with that idea?

Let me know what you feel about this?

[cpholguera]

Hi Vikas, thanks for the answer, I'll bring this point in our leaders meeting tomorrow and let you know.

[cpholguera]

Unfortunately we could not finish the discussion. We'll come back to you soon, sorry about that!

[cpholguera]

Thanks @su-vikas!

[sushi2k]

Thanks for the change @su-vikas !