iPhone Piracy Protection Code 2 - Another Tutorial

[Shmoopi]

Originally Posted by jsonli

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.

Absolutely, a lot of people make it sound like piracy is a necessary part of development, but it isn't. We can stop cracking, but only if we all use it. One developer here and there isn't going to stop anybody. That's why I wrote this tutorial.

-The cracking programs all run the debugger in order to pause the app when all of it's code is exposed in the ram.
-The reason that they can't just use touch, is because they already do, just not when they manually crack it.
-The cracking programs are all explained on Hackulous.com or appulo.us, if you'd like to take a look.

Thanks for the input!

[jsonli]

Originally Posted by Shmoopi

Absolutely, a lot of people make it sound like piracy is a necessary part of development, but it isn't. We can stop cracking, but only if we all use it. One developer here and there isn't going to stop anybody. That's why I wrote this tutorial.

-The cracking programs all run the debugger in order to pause the app when all of it's code is exposed in the ram.
-The reason that they can't just use touch, is because they already do, just not when they manually crack it.
-The cracking programs are all explained on Hackulous.com or appulo.us, if you'd like to take a look.

Thanks for the input!

Well I think the biggest advantage we have is that we just need to beat automated cracking tools rather than someone doing it manually.

I am not sure if you are right about touch, if a jailbroken phone can run programs as root, touch should be able to modify any timestamp. I'd be wary of the timestamp check, and to be safe I'd never use it alone at this point.

BTW regarding the encryption check, is it possible to check whether a phone is jailbroken or not? If so, we could just add that to the check.
i.e. jailbroken + not encrypted == pirated.
I'm assuming the Apple reviewers are not using jailbroken phones to test.

I'll take a look at those sites. I tried googling a few, but they all asked me to enter a password before I could enter LOL.

[thewitt]

There are jailbroken phones that do not belong to pirates, but I assume today all pirates have jailbroken phones...

-t

[jsonli]

Originally Posted by thewitt

There are jailbroken phones that do not belong to pirates, but I assume today all pirates have jailbroken phones...

-t

Right... and the Apple reviewers probably don't have jailbroken phones either, so we can combine that with the encryption check so it doesn't blow up in the reviewers face (in case they review before encrypting).

[Shmoopi]

Originally Posted by jsonli

Well I think the biggest advantage we have is that we just need to beat automated cracking tools rather than someone doing it manually.

I am not sure if you are right about touch, if a jailbroken phone can run programs as root, touch should be able to modify any timestamp. I'd be wary of the timestamp check, and to be safe I'd never use it alone at this point.

BTW regarding the encryption check, is it possible to check whether a phone is jailbroken or not? If so, we could just add that to the check.
i.e. jailbroken + not encrypted == pirated.
I'm assuming the Apple reviewers are not using jailbroken phones to test.

I'll take a look at those sites. I tried googling a few, but they all asked me to enter a password before I could enter LOL.

You're right, automatic tools are, in large part, the only thing we need to beat, unless your app is expecting hundreds of thousands in revenue.

The Time Stamp check is a good bet, only if you have other measures to circumvent automatic crackers. Meaning that this check will not stop the automated processes because they could change the programs to keep the timestamps the same, but might easily stop the manual crackers.

Regarding the encryption check, I think that's a great idea. However, checking if the user is jailbroken can be bypassed in many ways, especially if anyone reading this is not a legitimate iPhone Developer, and who's to say that the reviewers are not in fact jailbroken users? Instead, you could try layering other methods like the SignerIdentity method and the Encryption method, but the main problem with layering checks is that if one method is patched, then so are all the rest.

Good work though, I like the innovation!

[MaCeXpErTo]

Apple rejected one of my apps because of these codes.

[jsonli]

Originally Posted by MaCeXpErTo

Apple rejected one of my apps because of these codes.

You don't know which one?

[raheel]

Originally Posted by MaCeXpErTo

Apple rejected one of my apps because of these codes.

Yea, thats wat im afraid of, could you enlighten us more with details?

[jsonli]

BTW, how does a user go about uploading/cracking an app they've purchased?

Could we just upload lite versions ourselves through this service?

[Shmoopi]

Originally Posted by jsonli

BTW, how does a user go about uploading/cracking an app they've purchased?

Could we just upload lite versions ourselves through this service?

Crackers usually use a program called XCrack, PoedCrack, C4Crack,Crackulous, or something else, to crack the apps. They then upload the cracked version to a File Sharing site, post the link on Appulous, and then download them.

Sure, you could upload any app through Appulous, even a beta version.

[Tambourin]

Originally Posted by Shmoopi

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!

About putting advertisement, don't the crackers block advertisement?
I suppose it must be pretty easy to block urls to admob or remove the admob sdk code.

[jsonli]

Originally Posted by Tambourin

About putting advertisement, don't the crackers block advertisement?
I suppose it must be pretty easy to block urls to admob or remove the admob sdk code.

In general, I don't think so. Someone might be able to deny the AdMob SDK from returning the UIView of the banner, but the developer has coded the app such that there is space in the UI allocated for a big fat banner.

[TheFabolusBensun]

You don't mention where all this stuff goes... I guessed and put the majority of it inside the applicationDidFinishLaunching in AppDelegate.m

I have errors like:

RTLD_GLOBAL' undeclared
implicit declaration of function 'dlsym
implicit declaration of function 'dlclose
Unused variable 'aString
nested functions are disabled, use fnested-functions to re-enable
dlinfo' undeclared
Invalid use of undefined type 'struct mach_header'
Dereferencing pointer to incompatible type
'UIApplication' may not respond to '-terminate'
'UIApplication' may not respond to '-terminateWithSuccess'
'UIWebView' may not respond to '-alloc'
'UIWindow' may not respond to '-alloc'
'UIView' may not respond to '-alloc'
'UILabel' may not respond to '-alloc'
'UITextField' may not respond to '-alloc'
'UIImageView' may not respond to '-alloc'
'UIImage' may not respond to '-alloc'
'UISwitch' may not respond to '-alloc'
'UISegmentedControl' may not respond to '-alloc'
'UITabBar' may not respond to '-alloc'

You guys knew where to put it, I obviously have no idea... can you just perhaps say? please, my apps are simple but still I don't want to get hacked.

Bennis.

[steipete]

Originally Posted by MaCeXpErTo

Apple rejected one of my apps because of these codes.

Is it because of private api? or what was the reaction?

Has someone already deployed such a copy protection on the appstore? risking a rejection is not the end of the world, but would definitely hurt...

[Johni85]

Originally Posted by steipete

Is it because of private api? or what was the reaction?

Has someone already deployed such a copy protection on the appstore? risking a rejection is not the end of the world, but would definitely hurt...

That would be very interesting for me too.

[JamesT0723]

App just rejected for using the following API calls;


[[UIApplication sharedApplication] terminate];
[[UIApplication sharedApplication] terminateWithSuccess];


Thought you would like to know.....
-James

[CHV]

Originally Posted by steipete

Is it because of private api? or what was the reaction?

Has someone already deployed such a copy protection on the appstore? risking a rejection is not the end of the world, but would definitely hurt...

Yes, I did it and my apps did not get rejected.

All my apps include code that checks the integrity of the app. If the app was changed in any way then it is cracked and it does not work anymore.

The code does not use private APIs... only APIs that are allowed to be used anyway. The reviewers and all legal customers won't run into this code and so none of them cares. Only pirates will run into the code and because of the fact that they did not pay for the app, they don't deserve to use it.

[Shmoopi]

Originally Posted by JamesT0723

App just rejected for using the following API calls;


[[UIApplication sharedApplication] terminate];
[[UIApplication sharedApplication] terminateWithSuccess];


Thought you would like to know.....
-James

Sorry to hear that, I forgot that those were private API's. Hopefully you can try some of the other termination code samples.

[JamesT0723]

Shmoopi,

In the app I used plenty of the other termination code you posted, none of the others were mentioned in the rejection notice.

Additionally, the code makes calls to non-existent methods via dynamic selectors to terminate/crash the app if piracy is detected.


-James

[iPhoneAppStudio]

JamesT0723, thanks so much for posting these. I was about to submit an app that has both of these calls!

[Shmoopi]

Originally Posted by iPhoneAppStudio

JamesT0723, thanks so much for posting these. I was about to submit an app that has both of these calls!

Yeah, thanks for posting that I would not have caught that. The other terminations that you used are not private api's so they are fine to use, in case you were wondering. However, Apple may include those in there private api list because they don't like when apps crash without warning, especially when it's built into the code.

[iPhoneAppStudio]

Originally Posted by Shmoopi

Yeah, thanks for posting that I would not have caught that. The other terminations that you used are not private api's so they are fine to use, in case you were wondering. However, Apple may include those in there private api list because they don't like when apps crash without warning, especially when it's built into the code.

Yeah, I was thinking that future improvements of some of these classes might prevent them from crashing out. But I think it is still better to use them than close(0).

It would be nice if they would just fix the piracy problem. I really hate having to fill an apps full of land minds like this.

[coder00000]

Shmoopi thanks for sharing your insight here. I've incorporated some of these ideas into my own submission. I put some logging into my app which is currently under review at Apple, and I wanted to confirm that at least one phase of the testing is being done in a regular iPhone and that the tester is using a signed and encrypted binary.

[steoc4]

Hi

Can anyone explain a good way to test these methods without putting an app on the app store? Can you make a distribution build and then crack it? I've been trying to put distribution builds of my app on a jailbroken phone but I haven't had much luck.

What I have done is put a regular build on my phone - the cracking applications I found wouldn't crack it because it wasn't enctrypted, but what I could do was ssh to the phone and delete the CodeResources, CodeSignature and ResourceRules.plist from within the app in order to simulate a cracked app - but the code which I copied and pasted from here didn't seem to work - the 'fileExistsAtPath' function is returning true even though I've clearly deleted these files, and I'm sure I'm in the correct place because I tried deleting a PNG and my app became unable to load it.

[iPhoneDevelopment]

Hi,

I have taken two of the methods from here and combined them to make it twice as hard to crack my app (I understand the argument about there always being a way around whatever protection is put in place, but it is nice to at least feel like you are helping stop your app being cracked):

-(void) crackCheck { 
NSString* bundlePath = [[NSBundle mainBundle] bundlePath];
NSString* path = [NSString stringWithFormat:@"%@/Info.plist", bundlePath];
NSString* path2 = [NSString stringWithFormat:@"%@/AppName", bundlePath];
NSDate* infoModifiedDate = [[[NSFileManager defaultManager] fileAttributesAtPath:path traverseLink:YES] fileModificationDate];
NSDate* infoModifiedDate2 = [[[NSFileManager defaultManager] fileAttributesAtPath:path2 traverseLink:YES] fileModificationDate];
NSDate* pkgInfoModifiedDate = [[[NSFileManager defaultManager] fileAttributesAtPath:[[[NSBundle mainBundle] resourcePath] stringByAppendingPathComponent:@"PkgInfo"] traverseLink:YES] fileModificationDate];

if(fabs([infoModifiedDate timeIntervalSinceReferenceDate] - [pkgInfoModifiedDate timeIntervalSinceReferenceDate]) > 600) {	
	if (gameState == kGameStateRunning) {
		gameState = kGameStatePaused;
		if (crackedProgress.hidden) {
			crackedProgress.hidden = NO;}
		if (crackedAlert.hidden) {
			crackedAlert.hidden = NO;}
	}
}
if(fabs([infoModifiedDate2 timeIntervalSinceReferenceDate] - [pkgInfoModifiedDate timeIntervalSinceReferenceDate]) > 600) {	
	if (gameState == kGameStateRunning) {
		gameState = kGameStatePaused;
		if (crackedProgress.hidden) {
			crackedProgress.hidden = NO;}
		if (crackedAlert.hidden) {
			crackedAlert.hidden = NO;}
	}
} 
	BOOL fileExists = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/_CodeSignature", bundlePath)];
	if (!fileExists) {
		if (gameState == kGameStateRunning) {
			gameState = kGameStatePaused;
			if (crackedProgress.hidden) {
				crackedProgress.hidden = NO;}
			if (crackedAlert.hidden) {
				crackedAlert.hidden = NO;}
		}
	}
	BOOL fileExists2 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/CodeResources", bundlePath)];
	if (!fileExists2) {
		if (gameState == kGameStateRunning) {
			gameState = kGameStatePaused;
			if (crackedProgress.hidden) {
				crackedProgress.hidden = NO;}
			if (crackedAlert.hidden) {
				crackedAlert.hidden = NO;}
		}
	}
	BOOL fileExists3 = [[NSFileManager defaultManager] fileExistsAtPath:(@"%@/ResourceRules.plist", bundlePath)];
	if (!fileExists3) {
		if (gameState == kGameStateRunning) {
			gameState = kGameStatePaused;
			if (crackedProgress.hidden) {
				crackedProgress.hidden = NO;}
			if (crackedAlert.hidden) {
				crackedAlert.hidden = NO;}
		}
	}
}

I then halt the game and show an alert and a fake progress bar saying that the device's data is being sent to Apple... that should make them delete the cracked app :P.

Just one question.. is there any way to test the protection without cracking it and putting on a jailbroken phone (not being something I want to do)?

Thanks

Cam