Please do not post the same thing multiple times. The board software automatically flags certain posts as needing moderator attention. This happens the most often for new users. I'm pretty sure this is made clear at the time you attempt to post. Posting the same thing over and over again just makes that many more posts the moderators have to weed through later. This makes us sad. Don't make us sad. If your post/thread doesn't appear, just wait a while. Don't post it again. If it hasn't shown up by the next day, then you can try again. I normally go through posts in the mornings, and try to check a few times throughout the day, but I'm not here 24/7. There will typically be a significant delay before posts are approved. Just be patient.
Welcome back everyone! This is the third tutorial of iOS Anti-Piracy code from all over the world. This tutorial will, unfortunately, not be showing you a ton of unique, ingenious, and awesome anti-piracy methods like I have in the past. No, this time I will be showing you only two revised method that I like a lot, I will go over which methods from my last two tutorials are still relevant, and then I will introduce you to my new iOS Anti-Piracy Protection Libraries (yes two)!
There are a couple files you may be interested in checking for in order to determine if an application is pirated. ...
Unfortunately this has been circumvented. I have been using this method on all my apps for the past 1-2 years, and none of them were cracked... until last week. I am not sure whether the method is new, or it was just the sudden publicity my app got.
The cracked .ipa contains the files that you suggest to check for, and all of the files are untouched with the exception of the executable.
Also, the 5.1 SDK generates different files, so building old projects containing these checks will lead to false positives.
Unfortunately this has been circumvented. I have been using this method on all my apps for the past 1-2 years, and none of them were cracked... until last week. I am not sure whether the method is new, or it was just the sudden publicity my app got.
The cracked .ipa does not contain the files that you suggest to check for, and all of the files are untouched with the exception of the executable.
Also, the 5.1 SDK generates different files, so building old projects containing these checks will lead to false positives.
@Shmoopi Can you confirm if this is true or false?
Unfortunately this has been circumvented. I have been using this method on all my apps for the past 1-2 years, and none of them were cracked... until last week. I am not sure whether the method is new, or it was just the sudden publicity my app got.
The cracked .ipa contains the files that you suggest to check for, and all of the files are untouched with the exception of the executable.
Also, the 5.1 SDK generates different files, so building old projects containing these checks will lead to false positives.
Objective Zero;419916 said:
@Shmoopi Can you confirm if this is true or false?
I can't vouch for iOS 5.1 as I've only just started using it. However, I can assure you that the method is still valid for iOS<5.1. <br /> The reason your application may have been cracked is due to the Overdrive dylib built into the Clutch cracking tool. The Overdrive library is designed to defeat many common Anti-Piracy methods and unfortunately, does render an application's ability to check for some files useless. It can't defeat everything, though, and the more you deviate from commonly used Anti-Piracy mechanisms, the more likely you are to overcome it.
I'm going to revise the tutorial, or create a new one, that addresses iOS 5.1 and the changes it brings. For now, if you have an application that checks for the code resources and other like files, please check to make sure it will still work before submitting it to the App Store.
The reason your application may have been cracked is due to the Overdrive dylib built into the Clutch cracking tool.
Yes, I have found it since then, it seems to have been around since quite a while. It would be good to know exactly what system calls it can spoof...
and the more you deviate from commonly used Anti-Piracy mechanisms, the more likely you are to overcome it.
Yes, this is obviously true, the only problem is that it's difficult to come with unique solutions, as there are only a limited number of ways to it, and even if different people dig into it independently they will probably come up with the same solution. For example I first used this check without reading about it anywhere before. But apparently it has become common knowledge since then... it isn't difficult to find after all.
As for the 5.1 isssue, I did some more investigation today. The thing that is different (and broke my solution) is that the "CodeResources" symlink is missing from the .ipa. The file that it used to point to (_CodeSignature/CodeResources) still exists. To make things worse, pre-5.1 OS versions seem to replace the missing symlink, so in apps built by the 5.1 SDK any check for this symlink will pass when running on 5.0 or earlier, but fail on 5.1.
Yes, I have found it since then, it seems to have been around since quite a while. It would be good to know exactly what system calls it can spoof...
Yes, this is obviously true, the only problem is that it's difficult to come with unique solutions, as there are only a limited number of ways to it, and even if different people dig into it independently they will probably come up with the same solution. For example I first used this check without reading about it anywhere before. But apparently it has become common knowledge since then... it isn't difficult to find after all.
As for the 5.1 isssue, I did some more investigation today. The thing that is different (and broke my solution) is that the "CodeResources" symlink is missing from the .ipa. The file that it used to point to (_CodeSignature/CodeResources) still exists. To make things worse, pre-5.1 OS versions seem to replace the missing symlink, so in apps built by the 5.1 SDK any check for this symlink will pass when running on 5.0 or earlier, but fail on 5.1.
Well, according to a pleasant email I received from a pirate who very much disliked my Anti-Piracy Library, they stated that Overdrive hooks read() as well as stat(). This prevents you from reading and checking the contents of a file.
Even though it may not seem like it, there are a couple different ways to check for files, check the encryption status, stop debuggers, etc. It becomes more time consuming but there's always a way. Try creating a function in C versus Objective C or try checking the status of a file without using NSFileManager. It's a pain to re-write something Apple has built-in, but it makes it much harder to crack.
For the 5.1 problem, hmmm.... I wonder why it does that on older versions but not the newest? After reviewing it, I found that my checks are still finding the files... I wonder why your's are different. Can you tell us how you're implementing the check?
Well, according to a pleasant email I received from a pirate who very much disliked my Anti-Piracy Library, they stated that Overdrive hooks read() as well as stat(). This prevents you from reading and checking the contents of a file.
Even though it may not seem like it, there are a couple different ways to check for files, check the encryption status, stop debuggers, etc. It becomes more time consuming but there's always a way. Try creating a function in C versus Objective C or try checking the status of a file without using NSFileManager. It's a pain to re-write something Apple has built-in, but it makes it much harder to crack.
For the 5.1 problem, hmmm.... I wonder why it does that on older versions but not the newest? After reviewing it, I found that my checks are still finding the files... I wonder why your's are different. Can you tell us how you're implementing the check?
A file called overdrive.dylib is added to the application's .app directory. This dynamic library hooks certain filesystem function calls using interposition.
From what I understand, only dynamically linked functions can be hooked. Statically linked functions can't be hooked.
Therefore, if you want to defeat Overdrive, you would have to statically link the system libraries that contain the functions they try to hook.
Here's a longer list of calls it hooks: ptrace stat opendir readdir fopen fclose fread open read close
Would this work?
[edit] I don't know if this is possible or even allowed.
Apparently, Apple does not allow iOS developers to use their own dynamic libraries, so you will only see this happen on jailbroken devices.
Frameworks still use dynamic libraries, even if you link to the static ones? Are there XCode4 compiler options to statically link to runtime libraries? Or is that somehow impossible due to the sandbox nature of the iOS app?
A file called overdrive.dylib is added to the application's .app directory. This dynamic library hooks certain filesystem function calls using interposition.
From what I understand, only dynamically linked functions can be hooked. Statically linked functions can't be hooked.
Therefore, if you want to defeat Overdrive, you would have to statically link the system libraries that contain the functions they try to hook.
Here's a longer list of calls it hooks: ptrace stat opendir readdir fopen fclose fread open read close
Would this work?
[edit] I don't know if this is possible or even allowed.
Apparently, Apple does not allow iOS developers to use their own dynamic libraries, so you will only see this happen on jailbroken devices.
Frameworks still use dynamic libraries, even if you link to the static ones? Are there XCode4 compiler options to statically link to runtime libraries? Or is that somehow impossible due to the sandbox nature of the iOS app?
From what you're saying, you would have to create a static library that redefines each of these calls - a big undertaking to say the least.
As far as I know, frameworks will use dynamic libraries in place of static ones. I'm going to look into it to see what I can find. I think it is possible to add static libraries in place of dynamic ones, but the options may be limited.
I wonder why your's are different. Can you tell us how you're implementing the check?
Pretty basic, with opendir() and readdir() functions. For now just to be sure I left out this symlink from the checks, implemented one of the other methods with a little sauce and submitted my update.
From what you're saying, you would have to create a static library that redefines each of these calls - a big undertaking to say the least.
I don't think samurle wants to rewrite all these calls, just statically link to the system-provided library. But I am not sure it's safe to do that. Could it break in later iOS versions, when some new system stuff suddenly becomes incompatible with the earlier libc?
From what you're saying, you would have to create a static library that redefines each of these calls - a big undertaking to say the least.
As far as I know, frameworks will use dynamic libraries in place of static ones. I'm going to look into it to see what I can find. I think it is possible to add static libraries in place of dynamic ones, but the options may be limited.
Not necessarily, if you can link to the system's static libraries. That's why I'm asking if there are XCode4 compiler options to change from dynamic to static linking. With static linking, there is no middle man, as far as I know.
Might be useful for creating your own subset of runtime library code.
But I am not sure it's safe to do that. Could it break in later iOS versions, when some new system stuff suddenly becomes incompatible with the earlier libc?
Possibly. You could make your app unstable even with the current system, if parts of the app are using both the dynamic and static runtime libraries at the same time. Somewhere in the Apple docs says the framework will continue to use dynamic libraries, no matter what.
One potential issue with the tutorial is that comparing getuid() to 0 will result in a false positive for anyone who legitimately bought an app on a jailbroken phone.
It does sound like a good solution to circumvent Overdrive is to use open source as a guide in order to re-implement read(), etc, in an anti-piracy library that can be statically included in the app.
my_other_reg;419903 said:
The cracked .ipa contains the files that you suggest to check for, and all of the files are untouched with the exception of the executable.
Wow, all the files are untouched? This is really bad news for us app developers. This would seem to render almost all the normal checks used for the past year obsolete...?
What can my app do on a jailbroken device that it couldn't do before? What privileges does it have now? Something that can be used as an advantage?
Would it be possible for an app to detect and delete a file in its own directory, like, overdrive.dylib? Or is it impossible to unload/unhook a .dylib from memory that is alreading running?
Shmoopi
Posts: 213Tutorial Authors, Registered Users
Replies
The cracked .ipa contains the files that you suggest to check for, and all of the files are untouched with the exception of the executable.
Also, the 5.1 SDK generates different files, so building old projects containing these checks will lead to false positives.
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeCheck out my OCR app!
http://itunes.apple.com/app/ocr-pro/id486512712?mt=8
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeThe reason your application may have been cracked is due to the Overdrive dylib built into the Clutch cracking tool. The Overdrive library is designed to defeat many common Anti-Piracy methods and unfortunately, does render an application's ability to check for some files useless. It can't defeat everything, though, and the more you deviate from commonly used Anti-Piracy mechanisms, the more likely you are to overcome it.
I'm going to revise the tutorial, or create a new one, that addresses iOS 5.1 and the changes it brings. For now, if you have an application that checks for the code resources and other like files, please check to make sure it will still work before submitting it to the App Store.
Check Out The Official Shmoopi LLC Website
iPrivateBrowser | <a href="http:
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeAs for the 5.1 isssue, I did some more investigation today. The thing that is different (and broke my solution) is that the "CodeResources" symlink is missing from the .ipa. The file that it used to point to (_CodeSignature/CodeResources) still exists. To make things worse, pre-5.1 OS versions seem to replace the missing symlink, so in apps built by the 5.1 SDK any check for this symlink will pass when running on 5.0 or earlier, but fail on 5.1.
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeEven though it may not seem like it, there are a couple different ways to check for files, check the encryption status, stop debuggers, etc. It becomes more time consuming but there's always a way. Try creating a function in C versus Objective C or try checking the status of a file without using NSFileManager. It's a pain to re-write something Apple has built-in, but it makes it much harder to crack.
For the 5.1 problem, hmmm.... I wonder why it does that on older versions but not the newest? After reviewing it, I found that my checks are still finding the files... I wonder why your's are different. Can you tell us how you're implementing the check?
Check Out The Official Shmoopi LLC Website
iPrivateBrowser | <a href="http:
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeThis dynamic library hooks certain filesystem function calls using interposition.
From what I understand, only dynamically linked functions can be hooked.
Statically linked functions can't be hooked.
Therefore, if you want to defeat Overdrive, you would have to statically link
the system libraries that contain the functions they try to hook.
Here's a longer list of calls it hooks:
ptrace
stat
opendir
readdir
fopen
fclose
fread
open
read
close
Would this work?
[edit]
I don't know if this is possible or even allowed.
Apparently, Apple does not allow iOS developers to use their own dynamic libraries,
so you will only see this happen on jailbroken devices.
Frameworks still use dynamic libraries, even if you link to the static ones?
Are there XCode4 compiler options to statically link to runtime libraries?
Or is that somehow impossible due to the sandbox nature of the iOS app?
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeAs far as I know, frameworks will use dynamic libraries in place of static ones. I'm going to look into it to see what I can find. I think it is possible to add static libraries in place of dynamic ones, but the options may be limited.
Check Out The Official Shmoopi LLC Website
iPrivateBrowser | <a href="http:
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like Awesome- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like Awesomethere are XCode4 compiler options to change from dynamic to static linking. With static linking,
there is no middle man, as far as I know.
btw, there's some open source code here:
http://opensource.apple.com/
Might be useful for creating your own subset of runtime library code. Possibly. You could make your app unstable even with the current system, if parts of the app are using both
the dynamic and static runtime libraries at the same time. Somewhere in the Apple docs says the framework will continue to use dynamic libraries, no matter what.
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeIt does sound like a good solution to circumvent Overdrive is to use open source as a guide in order to re-implement read(), etc, in an anti-piracy library that can be statically included in the app. Wow, all the files are untouched? This is really bad news for us app developers. This would seem to render almost all the normal checks used for the past year obsolete...?
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like AwesomeSomething that can be used as an advantage?
Would it be possible for an app to detect and delete a file in its own directory, like, overdrive.dylib?
Or is it impossible to unload/unhook a .dylib from memory that is alreading running?
- Spam
- Abuse
- Troll
0 • Off Topic Insightful Disagree Dislike Like Awesome