Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibitlity Issue with iOS 8.1? #9

Open
HermannK opened this issue Nov 4, 2014 · 6 comments
Open

Compatibitlity Issue with iOS 8.1? #9

HermannK opened this issue Nov 4, 2014 · 6 comments

Comments

@HermannK
Copy link

HermannK commented Nov 4, 2014

This occurred after we migrated to iOS 8.1. However, I have not double checked whether this is really related to iOS 8.1

static NSString *str2 = @"ResourceRules.plist";
[manager fileExistsAtPath:([NSString stringWithFormat:@"%@/%@", bundlePath, str2])]
returns FALSE.
As a result the method isCracked returns true which causes a false alarm.

@HermannK
Copy link
Author

HermannK commented Nov 4, 2014

We found in the release notes
https://developer.apple.com/library/ios/releasenotes/General/RN-iOSSDK-8.0/index.html#//apple_ref/doc/uid/TP40014223
the following:
"The file system layout of app containers has changed on disk. Rather than relying on hard-coded directory structure, use the NSSearchPathForDirectoriesInDomains function or the URLForDirectory:inDomain:appropriateForURL:create:error: method of the NSFileManager class. See Accessing Files and Directories in File System Programming Guide"

@Jordo96
Copy link

Jordo96 commented Nov 11, 2014

As of iOS 8.1 / OSX 10.10, applications now longer create a resourcerules plist by default, meaning this code would be mostly invalid as a missing resourcerules.plist no longer indicates that the application has been tampered with. If you did want to add this in though, it can be done through going to Build Settings > Code Signing > 'Code Signing Resource Path' and adding '$(SDKROOT)/ResourceRules.plist' as the value.

@sidan5
Copy link

sidan5 commented Nov 12, 2014

@Jordo96 That fix on debug. But is that going to work on production?

@sidan5
Copy link

sidan5 commented Dec 13, 2014

@HermannK @Jordo96 Do you know if that would work on production? Can't figure this out and don't want to make a bad version.

@Jordo96
Copy link

Jordo96 commented Dec 14, 2014

Probably best to just remove the check from the code - after all, it is no longer really a definitive way to determine if the application has been compromised if it is no longer actually needed. If you still wanted to keep the check in the code, then I'm pretty confident it would work in production.

@sidan5
Copy link

sidan5 commented Dec 14, 2014

@Jordo96 How confident you are? My app have been compromised straight after removing this check. Maybe I shall add an analytics event just to make sure before doing any serious action...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants