iPhone Piracy Protection Code 2 - Another Tutorial

[Sai Baba]

One "silly" question. I have looked into my app's binary data in hex editor. And on my huge surprise - function names were in there!?

So if i was a cracker .. i can easyly cind your function named "crackCheck" and avoid its execution or something like that. So, naming protection function is also important isnt it?

[iPhoneAppStudio]

Originally Posted by Sai Baba

One "silly" question. I have looked into my app's binary data in hex editor. And on my huge surprise - function names were in there!?

So if i was a cracker .. i can easyly cind your function named "crackCheck" and avoid its execution or something like that. Ao, naming protection function is also important isnt it?

Not silly and very true. I don't remember all of the details but there is a Mobile Orchard podcast that goes into detail about the iPhone OS "runtime". What I recall is that method names and class names are used by the OS so they are included in the binary. I believe that this is the podcast:

Episode 23: Mike Ash On The Objective-C Runtime

It is best to use in line code if you can. But if you do use special methods or classes you should avoid obvious names. You don't want to give the cracker any clues.

[Kalimba]

Originally Posted by Sai Baba

One "silly" question. I have looked into my app's binary data in hex editor. And on my huge surprise - function names were in there!?

So if i was a cracker .. i can easyly cind your function named "crackCheck" and avoid its execution or something like that. So, naming protection function is also important isnt it?

Were you looking at a Release or Debug build? I believe symbol information is usually available in Debug builds, but I thought it was excluded from Release builds.

Originally Posted by iPhoneAppStudio

Not silly and very true. I don't remember all of the details but there is a Mobile Orchard podcast that goes into detail about the iPhone OS "runtime". What I recall is that method names and class names are used by the OS so they are included in the binary. I believe that this is the podcast:

Episode 23: Mike Ash On The Objective-C Runtime

It is best to use in line code if you can. But if you do use special methods or classes you should avoid obvious names. You don't want to give the cracker any clues.

I just listened to that podcast, and there was nothing I heard that indicated that unmangled method names were visible in the runtime. To me, it sounded like selectors are used for looking up class methods, and Ash described selectors essentially as a unique hash of the string representation of the method name.

[Sai Baba]

I was looking at release build. Function names - were there! Thats why i was confused and thats why i have renamed my protection functions into totally silly names. Now beat that crackers

Anyway ... there is one more thing. Cracker can always avoid execution or change behaviour of your protection function and then you're screwed. I have an idea how to protect that - CRC check protection. Has anyone experimented with that? I have experimented under windows/x86 but not yet on iphone/arm. Any links on that?

[dre]

Are you guys using Objective C/C++ or plain C/C++? If it's an Objective C class, then the method calls are dynamic (that's why it's slower) and thus the method names are stored in the binary.

Use C/C++ and turn off RTTI, then function names won't get to your binaries.

Another suggestion: don't use names like "Info.plist", etc. - scramble the names and keep them scrambled in the binary.

[Sai Baba]

Here, to be exact - i was using example from the first page of this thread:

void ZNDebugIntegrity() { ...

Looks like plain C function to me? ZNDebugIntegrity - right there in my hex editor! Oh, so you are saying to turn of that RTTI thingie. Where is that in xcode ... probably i'll find it later myself, thanks.

[dre]

Yes, it is a plain C function. Are you sure you are looking at release build?

For the sake of purity, you can name the file with .c extension. So the compiler won't even think "Objective C".

[Sai Baba]

Yes, I am sure, in release build - and also in distribution build! Where is RTTI option in xcode? Will try to find it later myself anyway ...

[dre]

Originally Posted by Sai Baba

Yes, I am sure, in release build - and also in distribution build! Where is RTTI option in xcode? Will try to find it later myself anyway ...

Oh, it's called "Enable C++ Runtime Types" in xcode, disable it (unless you are using them). It doesn't solve the problem though. The mangled function names are still there. I guess Apple wants to keep them there for stack trace reports or something, or maybe to easily check if we are using some taboo API. I guess the only solution is to give these functions/classes some silly names.

[Sai Baba]

Originally Posted by dre

I guess Apple wants to keep them there for stack trace reports or something, or maybe to easily check if we are using some taboo API.

Guess thats it.

[Sai Baba]

How do you close application? Is just exit(0) ok?

[Steake]

Originally Posted by 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

My app congratulates the user on actually cracking it... Because i'm cool

[Kalimba]

Originally Posted by Steake

My app congratulates the user on actually cracking it... Because i'm cool

Hmm... but usually only one person actually cracks it. Every other "user" who runs the app is simply downloading the already-cracked version from the web.

[Sai Baba]

Originally Posted by Steake

My app congratulates the user on actually cracking it... Because i'm cool

Cool indeed, but cracker can also post-crack that message so it does not display and then we got your fully cracked app. Tada!

Besides that, you give a cracker a starting point with that message so he knows where to start post-cracking process.

Insted of that, my idea is that when application detects that it is cracked then it silently starts working wrong, so the cracker can not be sure where to start post-cracking process.

I just done that and some cracker posted "cracked" version of my app which is not usable at all! He probably didnt have time to actually try and use application. There are tons of other apps for him to crack. Maybe some other time.

is_encrypted is the king! Rename it and adjust a little to suit your needs.

Thank you guys!

[learnSomething]

2 other anti debugging techniques.
1. use PTRACE_TRACEME to trace the app itself. gdb won't be able to attach
2. gdb opens some more file descriptors than the usual 3 for the child process. So you can check if more than 5 file descriptors exists. if they exist you can exit your app.

and of course you can use asm to do the basic PT_DENY_ATTACH

anyhow, I'm not an AppStore dev, I develop for the CydiaStore. Doesn't apple rely on being able to use gdb with your executable in order to test your app?

and make sure you avoid all kind of strings. strings are a dead giveaway (encrypted or not), especially you only need to break in gdb right before the msg_send and you can print out the objects in the registers (po $r0). Don't use objC for checks. try to use as much C as possible.

here are some other suggestions: http://iphonedevwiki.net/index.php/Crack_prevention

[ballso]

Regarding the javaconvert method, the info plist size differs whether you build it for simulator or device. Don't forget to change to the device build plist size before the the final distribution build.

#define kInfoSize 500
//Place your NSLog Plist Size into the above Define statment

NSLog(@"File Size: %qi\n", [fileSize unsignedLongLongValue]);

[Tambourin]

why should it change
the plist is always the same

[ballso]

Originally Posted by Tambourin

why should it change
the plist is always the same

I really don't know, maybe someone more experienced could fill in on this. But it sure does change in size from like 550 to 600 in my case.

Simulator - 3.1.3 | Release : 550
Device - 3.1.3 (Base SDK) | Release : 600

[Chilibird]

You could always tie the functionality of your app into whether your anti piracy function runs.

E.G- When the crackCheck method is called, it sets another variable indicating that it ran. Your app can then check for that variable at opportune times. That way if a cracker disables the crackCheck method, the app still won't work. However, if he DOESN'T disable it, the anti-crack method runs and they get caught.

[ballso]

Originally Posted by Tambourin

why should it change
the plist is always the same

Have you tried printing out the plist file size both in simulator and on the device?

[learnSomething]

Originally Posted by Chilibird

You could always tie the functionality of your app into whether your anti piracy function runs.

E.G- When the crackCheck method is called, it sets another variable indicating that it ran. Your app can then check for that variable at opportune times. That way if a cracker disables the crackCheck method, the app still won't work. However, if he DOESN'T disable it, the anti-crack method runs and they get caught.

most cracker don't NOP the call for the crackCheck method, they simply change for example CMP R0, #0 to something like CMP R0, R0. So your idea won't have any actual use.

You need to understand how cracking works to get it done right.
a guy called Reilly wrote a detailed tutorial on how to manually crack apps with additional protection: everyone who works on anti-crack stuff should read it: ARTeam Website: Downloads / / Patching Applications from Apple?s AppStore with additional protection (online view has only 6 pages. download the zip to read the pdf with over 30 pages).

[Sai Baba]

As far as I can see, most crackers do not RUN application at all after "cracking" it!
Thats why tons of non-working "cracks" come up on various download locations! I'm kinda mad but maybe that's a good thing after all, who knows ...

[raheel]

What are the risks involved in adding these anticrack measures? Can they somehow malfunction in a legally bought app for a JailBroken iphone?? That will ruin the reputation in the appstore.

I heard some stories where the app wouldnt even start in a normal legally bought for app.. Im very tempted to use these methods, but im afraid if it'll have accidentally some adverse effect. Is anyone already using them?

[CHV]

Originally Posted by raheel

What are the risks involved in adding these anticrack measures? Can they somehow malfunction in a legally bought app for a JailBroken iphone?? That will ruin the reputation in the appstore.

I heard some stories where the app wouldnt even start in a normal legally bought for app.. Im very tempted to use these methods, but im afraid if it'll have accidentally some adverse effect. Is anyone already using them?

You need to implement your code absolutely fail proof and correctly and make sure that the anti-piracy measurements are not activated when the app was legally purchased. You need to figure out what your app needs to look out for in order to see if the app was pirated or not. If the app detects that it was pirated then it can (legally) do anything it wants, including turning the iDevice into an iBrick. Nobody can you (the developer) hold responsible when a pirated (stolen) copyrighted product creates havok.

If you wanna be sure that your anti piracy code is working correctly, then you need to do what a pirate does: Crack it yourself with the pirate's tools and test it.

[aarong]

Apologies in advance for my noobish question.

If I am calling is_encrypted from main.m, where do I call it?

This is what my main looks like:

int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
is_encrypted();
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}