can I place your is_encrypted{} method somewhere else like the viewDidLoad?
or it absolutely has to be in the int main{}?
if it has to be in int main{}, would it close out if your is_encrypted{} returns a no?
in other words, I'd like to display an UIAlertView that "This App has been modified" then close the app out after one minute.
How caan I pass/receive the output of is_encrypted{} to the rest of my app?
Thanks again for sharing this great information,
-FerrariX
No, your encryption check can go anywhere you like, not just the main file. It doesn't close your app if the is_encrypted{} returns no, the space after return no was purposefully left blank to allow you to put whatever code you wanted there. If you did put the encryption check in the main file, you could return a *Pirated check to NSUserDefaults where upon viewDidLoad your AppDelegate could check to see if it's pirated. No problem Thanks for asking!
When an App goes through the review process, Apple doesn't change anything to change the Time Stamps on the app files, therefore rendering the time checking method useless?
When an App goes through the review process, Apple doesn't change anything to change the Time Stamps on the app files, therefore rendering the time checking method useless?
No, Apple not changing the Timestamps on the app files is what we want. If they did change the App files, causing the Timestamps to change, the Timestamp method would report piracy every time the app was run, which is bad. What we want to see is if the Cracker tries to change any of the App files, causing the Timestamp of any of the files to change, and then report piracy. Hope that clears it up a bit for you.
Now that I implemented my anti-piracy protection code I was looking for a way to test it, but it seems that they only way to "crack 'n try" is to have the app on the appstore and crack it.
Now that I implemented my anti-piracy protection code I was looking for a way to test it, but it seems that they only way to "crack 'n try" is to have the app on the appstore and crack it.
Is that true or I'm missing something?
It doesn't necessarily have to be in the App Store per say, but it does have to be cracked to check if most of these methods work. You can add the SignerIdentity Key to the Plist to check if the SignerIdentity methods from the last tutorial work, but it would be somewhat wasted since all the new crack methods use a different method.
By the way, I just read that the new xCrack Application automatically eliminates any Ptrace checks in your source code. Has anyone heard about this yet?
Of relevance to the subject at hand, is this old article about copy protection on Spyro the Dragon. I encourage my fellow devs to pay particular attention to the need to distribute copy protection through the game rather than simply on load.
__________________
Visit Mr Jack Games for my blog and more about my games
Thanks for the great information Shmoopi. I am finding that the the encryption check code always returns NO - Not encrypted. This is true whether I run with the simulator or an iPhone. When running on the phone crypt_cmd->cryptid always equals 0. But I am assuming that encryption should be enabled.
Has anyone had success with the encryption check code?
Thanks for the great information Shmoopi. I am finding that the the encryption check code always returns NO - Not encrypted. This is true whether I run with the simulator or an iPhone. When running on the phone crypt_cmd->cryptid always equals 0. But I am assuming that encryption should be enabled.
Has anyone had success with the encryption check code?
That's very strange, if everything is right it should never check for it during a simulator build, which is encrypted anyway, and would find it during anything else. Try running it during a release build after cleaning all targets and see if that works. If it doesn't, take your executable from the build, whether it be debug or release, open up terminal, and type "Otool -l *Drag your executable file here". When you do that, a long line of encryption code from the file will pop up, navigate to command 9 and look for the encryption status, it will be either a 1 or a 0. 1 means that the file is encrypted, 0 means the file is not encrypted. If it shows a 1 then you know their is something with code, if not then report back here and I'll check it and possibly get rid of that method, although I've never had a problem with it. Thanks for the heads up!
That's very strange, if everything is right it should never check for it during a simulator build, which is encrypted anyway, and would find it during anything else. Try running it during a release build after cleaning all targets and see if that works. If it doesn't, take your executable from the build, whether it be debug or release, open up terminal, and type "Otool -l *Drag your executable file here". When you do that, a long line of encryption code from the file will pop up, navigate to command 9 and look for the encryption status, it will be either a 1 or a 0. 1 means that the file is encrypted, 0 means the file is not encrypted. If it shows a 1 then you know their is something with code, if not then report back here and I'll check it and possibly get rid of that method, although I've never had a problem with it. Thanks for the heads up!
Thanks for the quick response. Here is the Otool -l command 9 for the release build:
I read all the different ways posted in this thread, and the encryption check seemed the best and safest way to go. I've implemented it and I'm in the same situation as above. However I compile my app, I get a crypt_cmd->cryptid equal 0, for all (non-simulator) targets and all configurations.
The assumption though is that binary encryption won't actually occur until Apple signs the binary.
I used the otool -l command to check binaries I previously submitted to Apple and the cryptid is 0. I use it on all apps I downloaded from the App Store, including my apps, and the cryptid is 1.
So I'm not worried about this, binary encryption will occur when Apple signs it and puts it in the store.
But, my concern is this: When the reviewer puts it on their device to test it, is the binary already signed by Apple and therefore encrypted? Cause if it isn't, then the app will think the reviewer is running a pirated copy right?
I read all the different ways posted in this thread, and the encryption check seemed the best and safest way to go. I've implemented it and I'm in the same situation as above. However I compile my app, I get a crypt_cmd->cryptid equal 0, for all (non-simulator) targets and all configurations.
The assumption though is that binary encryption won't actually occur until Apple signs the binary.
I used the otool -l command to check binaries I previously submitted to Apple and the cryptid is 0. I use it on all apps I downloaded from the App Store, including my apps, and the cryptid is 1.
So I'm not worried about this, binary encryption will occur when Apple signs it and puts it in the store.
But, my concern is this: When the reviewer puts it on their device to test it, is the binary already signed by Apple and therefore encrypted? Cause if it isn't, then the app will think the reviewer is running a pirated copy right?
I think that you are probably correct. I am concerned about what the reviewer might see too. It seems unlikely that Apple would sign the binary before it has been reviewed.
I have an app that was recently featured on the "What's Hot" list. It only had the obscured signer identity check for piracy and was cracked almost immediately. So far piracy doesn't look outrageous but I have had other apps where the piracy was as high as 80%. I've incorporated all of the other countermeasures but I'd like to add encryption before I release the next version.
I was also considering giving Oliver's (Dr Touch) AntiPiracy a try. Honestly, I would rather spend my time developing cool stuff for my apps than trying to thwart the crackers. But of course his code is a bigger target than a home brewed solution.
I read all the different ways posted in this thread, and the encryption check seemed the best and safest way to go. I've implemented it and I'm in the same situation as above. However I compile my app, I get a crypt_cmd->cryptid equal 0, for all (non-simulator) targets and all configurations.
The assumption though is that binary encryption won't actually occur until Apple signs the binary.
I used the otool -l command to check binaries I previously submitted to Apple and the cryptid is 0. I use it on all apps I downloaded from the App Store, including my apps, and the cryptid is 1.
So I'm not worried about this, binary encryption will occur when Apple signs it and puts it in the store.
But, my concern is this: When the reviewer puts it on their device to test it, is the binary already signed by Apple and therefore encrypted? Cause if it isn't, then the app will think the reviewer is running a pirated copy right?
I honestly don't know the answer to that question. I've implemented this check in my code and my app got into the App Store just fine. Either Apple is not thoroughly checking the apps, or they encrypt the app before running it. I'll test this out in my next update, I'll run this check on one of my free apps, and if it returns negative I'll show an alert asking if this person is a tester. What do you think?
Quote:
Originally Posted by iPhoneAppStudio
I think that you are probably correct. I am concerned about what the reviewer might see too. It seems unlikely that Apple would sign the binary before it has been reviewed.
I have an app that was recently featured on the "What's Hot" list. It only had the obscured signer identity check for piracy and was cracked almost immediately. So far piracy doesn't look outrageous but I have had other apps where the piracy was as high as 80%. I've incorporated all of the other countermeasures but I'd like to add encryption before I release the next version.
I was also considering giving Oliver's (Dr Touch) AntiPiracy a try. Honestly, I would rather spend my time developing cool stuff for my apps than trying to thwart the crackers. But of course his code is a bigger target than a home brewed solution.
I agree with you, developers shouldn't have to develop Anti-Piracy code for the iPhone, we should be spending time making cool features for our apps.
I've never used Dr Touch's AntiPiracy code, but just by watching the commercial it seems that he uses the encryption method, and probably a couple more listed in this tutorial. Feel free to try it and tell us how it is though.
I agree with you, developers shouldn't have to develop Anti-Piracy code for the iPhone, we should be spending time making cool features for our apps.
Pretty much any automated anti-piracy system borders on worthless because if it works in an automated fashion, the pirates can automate it's circumvention.
__________________
Visit Mr Jack Games for my blog and more about my games
Really thanks a lot for sharing all the anticrack things for free. I have one lame questions, what should I do when the code get known that the app has been pirated? Close the app - how? Thanks
Really thanks a lot for sharing all the anticrack things for free. I have one lame questions, what should I do when the code get known that the app has been pirated? Close the app - how? Thanks
You should do anything that you want to do. If you want to close the app, go ahead and close it by using some of the closing methods listed in the bottom of this tutorial, likewise, if you want to put advertisements, popups, or anything else in there, feel free. This is your app, do whatever you want!
Ultimately though, I would think about what you would do as a cracker if the developer had implemented whatever method you use when you detect it's pirated. Would you be mad? Sad? Frustrated? Think about it from the opposite perspective.
Quote:
Originally Posted by F.R.E.E.
I am having strange problems with the following preprocessor commands
Very interesting. I'm going to have to take a lot closer look at the Encryption check method that I've provided. It looks like their should be a more reliable way to implement this check. Thanks, for the comment F.R.E.E., I'll post here when it's updated.
either NS_BLOCK_ASSERTIONS is not consistently defined or NDEBUG across the matrix of simulator/device/debug/release
I am still looking at it, but I am not sure where to find out what preprocessor commands are defined for a given configuration. Where do I locate that or how do I produce output to see the gcc command line?
So part of the problem I was having was caused by using the wrong compiler. My project was setup for gcc 4.0 somehow..
anyway, that didn't fix the problem. The basic problem is all the preprocessor macros except for TARGET_IPHONE_SIMULATOR were undefined in all build configurations. Also, TARGET_IPHONE_SIMULATOR is never undefined, so just checking #if TARGET_IPHONE_SIMULATOR has not proven to be enough. The value of the macro does change between 1 and 0
I solved the problem by adding my own preprocessor macro to the debug builds, and checking the value of TARGET_IPHONE_SIMULATOR like so.
This is just great, thanks alot for your time Shmoopi.
I had some questions regarding all your methods..
1. SOme of the newer methods you posted, can only one of them be used? Or we should practically implement most never checks.
2. Is there anyway, this cases a backlash in appstore.. (considering its working sweetly on your native development device) and since most of us will not Crack and Check to see if its working, it'll be difficult to predict how it'll behave ?? or am i just being paranoid?
I've never really used any of the jailbroken installer programs before, but the vast majority of cracks are occurring automatically aren't they?
I was reading about Crackulous, and paid users that submit the cracked app which presumably goes through an automated process.
I don't think there are people manually cracking 100s or 1000s of apps every single day.
Is this not the case?
You're right, pirates do not spend all day manually cracking 100's or 1000's of apps. Most pirates are teenagers using XCrack or Crackulous who download a couple apps and crack them, there are actually very few people who take the time to manually crack them. Remember that pirating applications is not (usually) the pirates actual job, almost every pirate does it as a hobby.
Quote:
Originally Posted by raheel
This is just great, thanks alot for your time Shmoopi.
I had some questions regarding all your methods..
1. SOme of the newer methods you posted, can only one of them be used? Or we should practically implement almost every check.
2. Is there anyway, this will cause a backlash in appstore.. (considering its working sweetly on your native development device) and since most of us will not Crack and Check to see if its working, it'll be difficult to predict how it'll behave ?? or am i just being paranoid?
Thanks again for the post.
1. You can implement however many checks you would want. If you want to really protect your applications, then use a lot of the methods. If you think you're safe with one method, use only one. Ultimately, it's up to you.
2. Well, you can take my word for it, or you can check it out yourself. I've taken a lot of time testing and implementing these checks, mostly to see if they'll work in the App Store, and have never had any problems. But if you're still unsure, you can make a dummy application, use some of the checks, submit it to the App Store, and then crack it to see if they'll work. While it may seem like a lot of work, it's worth the effort.
You're right, pirates do not spend all day manually cracking 100's or 1000's of apps. Most pirates are teenagers using XCrack or Crackulous who download a couple apps and crack them, there are actually very few people who take the time to manually crack them. Remember that pirating applications is not (usually) the pirates actual job, almost every pirate does it as a hobby.
Okay, just wanted to get that cleared up. I've replied to several posts in the past that have had "nothing is uncrackable / the pirate will just return false to the piracy check" which doesn't really apply to iPhone apps since no one does it manually.
We just need to defend against automated cracks - we've got it much easier in some regards than on the PC.
Questions:
- Why does the cracking program run gdb?
- For the timestamp check, I'm not familiar with the permissions structure on a jailbroken phone, but could the cracking program just run touch to change the timestamps? I'm probably right in assuming anyone writing the cracking software will think of touch as the first way around it.
- Is there some sort of cracking manual you guys are reading? I'd love to get down and dirty with the details and maybe I can contribute some checks as well.
Thanks for asking!
Linear Mode
