Well this one is driving me crazy so better ask for some help before I fire the big guns and go commando mode with this.
I’m trying to patch iOS apps so I can remove “spyware” and other stuff. Newest iOS versions require all code to be signed. This article by Saurik talks about 3 different ways to workaround this problem without a developer certificate (an idea that crossed my mind is to configure the kernel only to accept Apple’s certificates and my certificate, to avoid rogue stuff like worms [I have to see if code signing is effective against code injection for example]). I don’t like number 3 due to associated security problems so I have to work with the other two. The first problem is that the available ldid seems to have some problems with armv7 binaries (iPad and iPhone4?) – a fixed version that runs in OS X is available here. I try to resign/add new signature to the modified binaries but the checksums don’t change so ldid doesn’t seem to work. I can sign the binaries without any problem in OS X using a self signed certificate. But here lies my problem. Let me describe my scenario…
I have an unencrypted app running. I copy the main binary to OS X and patch whatever I want. I resign the binary (method #1 or #2) and replace it in the iPad. I try to run the binary and iOS refuses to do so. If I remove the kernel flag (#3) it works so there aren’t problems with the binary itself. Restore the kernel flag, kill the process, try to run again and it refuses. So I did another test. Since I have the ipa file for the unencrypted app, I replace the binary inside it with my newly patched one, delete the app from iPad and iTunes, and install the new modified ipa. Try to run the newly installed modified app and it works! WTF?
I had read somewhere about iTunes adding something to the keychain (I memorized one thing, that iOS keychain was very simple with just three methods available) when apps were synced/installed (I can’t seem to find back this article – !#&%”#/&%#”&”#&!). My test appears to confirm something like this else the new modified app would also fail.
So my question is if it’s possible to modify the main binary and resign it, without having to reinstall the whole app again. Am I missing something? I can’t seem to find any valuable info about this.
Anyway, contrary to what I thought, might be very interesting related to protections and other tricks. The following links, 1 2 3 4, show that there are possibilities to implement protections. My (wrong!) idea was that Apple didn’t allow this kind of stuff in the app approval process. Well that PiOS article and this presentation changed this. It’s very possible to bypass Apple verification process and do something nasty into thos iOS devices (I’m worried regarding corporate security and my personal stuff). Well, to my defense, I must say that I always found intriguing how Apple could, efficiently, verify throughly all the code for each app – that never added into my mind but I never bothered to check heehheh.
Update:
Found a pretty interesting presentation from Hack in the Box 2010 about iPhone security model.