RiP Dev has posted a lengthy explanation of some of the techniques employed by Kali and how it helps iPhone developers.
-----
Since the Kali Anti-Piracy announcement there have been plenty of questions, comments, and other feedback (including letters cursing the Ripdev team) regarding the system to protect iPhone apps against cracking. This is why I wrote this article that explains some of the techniques employed by Kali and what exactly is going on with the application, the developer of the application and Ripdev.
First -- an introduction to how the current iPhone application cracking system works, so you can understand what we have to deal with. Cracker buys an application in the App Store and launches it on his iPhone -- initially the app's executable code is protected by Apple's DRM system. But when the app is launched, system reads all the keys and loads the unprotected application into the RAM.
Then cracker uses a debugger to "stop" the application in the RAM and creates image of the device's RAM (where the unencrypted program is loaded). Next, that image with RAM info is downloaded to the computer where cracker can create IPA file -- the executable iPhone app that can work without encryption keys.
Kali AP has three modules and each of the modules is responsible for its own segment of app protection. The first one is "anti-debug" -- subsystem that won't allow the application to run under the debugger. If Kali detects attempts to use the debugger with the app, the application will probably crash.
But let's assume that cracker was successful enough to run the application in the debugger. Then another Kali subsystem dives into the action -- "antidump". As I mentioned above, when the application is protected only by Apple's DRM, it runs in RAM basically unprotected, so it's easy to dump the app code. But when the app is protected by Kali, its code in the RAM is never completely integral: executable code goes through different stages where it first gets modified and then it's assembled back. This process is highly integrated to protection integrity checks, so even if a cracker gets RAM image, it will be severely damaged and program won't work.
The third Kali subsystem that was already mentioned -- protection integrity checks, monitors cracking attempts. It works in three stages, checking itself, the application in general, and various elements of the app. To achieve the latter Kali randomly integrates various checking modules that prevent intrusion into protection.
Thanks to close integration of these subsystems Kali is able to provide a certain level of protection for the applications that use it. This is why it was nice to read on Hackulous forums (after they tried Ripdev's app that uses Kali -- iPref) that «The protection actually doesnt look bad. On first look, I would say there wont be a crack for that for some time.»
The developers that have created Kali also fully understand that there are no unbreakable systems -- everything that was written by one person can be cracked by another (it's just a matter of time and resources). So it's quite possible that there will be some teenage genius with too much time on his hands that might crack Kali. This is why Kali's code is constantly changing and evolving. So different apps that employ Kali also use different encryption methods and other elements, so creating an automatic tool like Crackulous will be an extremely difficult task to do.
Now let's talk about the Kali implementation process. There were some concerns about it, but since Kali doesn't work with source code, there should be no worries about it. When a developer creates his application and it's ready for App Store submission, he builds the release version and uploads it to the Kali processing server. On the Kali server, the application is processed by a script that analyzes the app and builds a protected version by integrating the Kali elements. After that the developer can sign his application with his signature and upload it to the App Store. Applications that are protected with Kali go through Apple's review process and get approved (iPref is one example).
Another issue that has concerned some developers -- how does the application protected with Kali behave on the user's iPhone. Kali is completely autonomous solution that doesn't require any servers to run, so it doesn't phone home checking the license or counting deployments. It does not transfer any information from the iPhone (including user's private data). Additionally Kali doesn't perform any actions when it detects itself from within a cracked application (the app probably won't run at all after being processed by Crackulous) -- Kali doesn't damage any user data or his iPhone. For the legit user (that bought the app in App Store) the process is absolutely seamless and transparent as with any other legit app -- he will never know about any protection in the app whatsoever. Kali basically doesn't affect performance of the application and uses only 96KB of RAM to run.
Of course developers are also worried about what's going to happen if Kali does indeed get cracked. The agreement that developers sign when ordering Kali, says that Kali doesn't offer 100% guarantee from cracking- and who would promise that? ;) What Ripdev can guarantee is that if any particular application using Kali gets cracked, the system will be updated ASAP and the developer will be able to use an updated Kali in the new version of the application (and hackers will require quite some time to crack it again).
Ripdev are not naive and they don't think that Kali will defeat software piracy -- it's obvious that many developers will opt not to use it since they don't want to disclose the application sales or share the revenue from sales of their app, even the small percentage that Ripdev requires (see this PDF about the pricing for the Kali). So there will still be plenty of apps being cracked and shared over the internet. Some apps using Kali were already submitted to the App Store (we can't disclose their names though), and our own app that uses Kali -- iPref -- still causes the hackers to scratch their head (It was posted "cracked" on some sites but it doesn't work when copied to iPhone). Ripdev doesn't subscribe to the theory that cracked apps work as "free advertisement" -- there are plenty of apps with a "Lite" version, but it doesn't help much. So developers should take other approaches, and Kali could be one of them. We encourage you to take a close look at Kali and try it out to protect your app today.
-----
Read More
-----
Since the Kali Anti-Piracy announcement there have been plenty of questions, comments, and other feedback (including letters cursing the Ripdev team) regarding the system to protect iPhone apps against cracking. This is why I wrote this article that explains some of the techniques employed by Kali and what exactly is going on with the application, the developer of the application and Ripdev.
First -- an introduction to how the current iPhone application cracking system works, so you can understand what we have to deal with. Cracker buys an application in the App Store and launches it on his iPhone -- initially the app's executable code is protected by Apple's DRM system. But when the app is launched, system reads all the keys and loads the unprotected application into the RAM.
Then cracker uses a debugger to "stop" the application in the RAM and creates image of the device's RAM (where the unencrypted program is loaded). Next, that image with RAM info is downloaded to the computer where cracker can create IPA file -- the executable iPhone app that can work without encryption keys.
Kali AP has three modules and each of the modules is responsible for its own segment of app protection. The first one is "anti-debug" -- subsystem that won't allow the application to run under the debugger. If Kali detects attempts to use the debugger with the app, the application will probably crash.
But let's assume that cracker was successful enough to run the application in the debugger. Then another Kali subsystem dives into the action -- "antidump". As I mentioned above, when the application is protected only by Apple's DRM, it runs in RAM basically unprotected, so it's easy to dump the app code. But when the app is protected by Kali, its code in the RAM is never completely integral: executable code goes through different stages where it first gets modified and then it's assembled back. This process is highly integrated to protection integrity checks, so even if a cracker gets RAM image, it will be severely damaged and program won't work.
The third Kali subsystem that was already mentioned -- protection integrity checks, monitors cracking attempts. It works in three stages, checking itself, the application in general, and various elements of the app. To achieve the latter Kali randomly integrates various checking modules that prevent intrusion into protection.
Thanks to close integration of these subsystems Kali is able to provide a certain level of protection for the applications that use it. This is why it was nice to read on Hackulous forums (after they tried Ripdev's app that uses Kali -- iPref) that «The protection actually doesnt look bad. On first look, I would say there wont be a crack for that for some time.»
The developers that have created Kali also fully understand that there are no unbreakable systems -- everything that was written by one person can be cracked by another (it's just a matter of time and resources). So it's quite possible that there will be some teenage genius with too much time on his hands that might crack Kali. This is why Kali's code is constantly changing and evolving. So different apps that employ Kali also use different encryption methods and other elements, so creating an automatic tool like Crackulous will be an extremely difficult task to do.
Now let's talk about the Kali implementation process. There were some concerns about it, but since Kali doesn't work with source code, there should be no worries about it. When a developer creates his application and it's ready for App Store submission, he builds the release version and uploads it to the Kali processing server. On the Kali server, the application is processed by a script that analyzes the app and builds a protected version by integrating the Kali elements. After that the developer can sign his application with his signature and upload it to the App Store. Applications that are protected with Kali go through Apple's review process and get approved (iPref is one example).
Another issue that has concerned some developers -- how does the application protected with Kali behave on the user's iPhone. Kali is completely autonomous solution that doesn't require any servers to run, so it doesn't phone home checking the license or counting deployments. It does not transfer any information from the iPhone (including user's private data). Additionally Kali doesn't perform any actions when it detects itself from within a cracked application (the app probably won't run at all after being processed by Crackulous) -- Kali doesn't damage any user data or his iPhone. For the legit user (that bought the app in App Store) the process is absolutely seamless and transparent as with any other legit app -- he will never know about any protection in the app whatsoever. Kali basically doesn't affect performance of the application and uses only 96KB of RAM to run.
Of course developers are also worried about what's going to happen if Kali does indeed get cracked. The agreement that developers sign when ordering Kali, says that Kali doesn't offer 100% guarantee from cracking- and who would promise that? ;) What Ripdev can guarantee is that if any particular application using Kali gets cracked, the system will be updated ASAP and the developer will be able to use an updated Kali in the new version of the application (and hackers will require quite some time to crack it again).
Ripdev are not naive and they don't think that Kali will defeat software piracy -- it's obvious that many developers will opt not to use it since they don't want to disclose the application sales or share the revenue from sales of their app, even the small percentage that Ripdev requires (see this PDF about the pricing for the Kali). So there will still be plenty of apps being cracked and shared over the internet. Some apps using Kali were already submitted to the App Store (we can't disclose their names though), and our own app that uses Kali -- iPref -- still causes the hackers to scratch their head (It was posted "cracked" on some sites but it doesn't work when copied to iPhone). Ripdev doesn't subscribe to the theory that cracked apps work as "free advertisement" -- there are plenty of apps with a "Lite" version, but it doesn't help much. So developers should take other approaches, and Kali could be one of them. We encourage you to take a close look at Kali and try it out to protect your app today.
-----
Read More