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

Multiple Useless/Non-Obfuscated Checks #7

Open
Shmoopi opened this issue Jul 15, 2013 · 0 comments
Open

Multiple Useless/Non-Obfuscated Checks #7

Shmoopi opened this issue Jul 15, 2013 · 0 comments

Comments

@Shmoopi
Copy link

Shmoopi commented Jul 15, 2013

Hello,

I think you've done a great job creating an easy-to-use class to add simple jailbreak and piracy checks to every developer's application. But I think your checks are mostly useless. Here's why:

  1. SignerIdentity checks have been useless after iOS 3.0. SignerIdentity is no longer a default key in the info.plist. - Consider removing
  2. Checking for the existence of the _CodeSignature and ResourceRule.plist is great, but most cracking methods nowadays no longer remove the file, they just delete the important entries/clear the file of all contents. - In the future, make sure that the file still contains something in it, or that it's formatted correctly
  3. Checking the modified dates of the plist and executable and comparing them can sometimes be dead wrong. When compiling, the files can often be created at differing times (i.e. 11:59 and another at 12:00) - comparing them is often a bad idea, you may be better off checking if the dates are within a certain range rather than exactly the same
  4. Checking for the existence of cydia and other jailbreak application files is the right move, but your obfuscation method is not. This will still show up in a hex editor clear as day. - Use a cypher or #define them

Other than that, here are some nitpicks of mine:

  1. Don't just #ifdef the simulator, also check that we're not catching debug users or i386 users.
  2. Check for more jailbreak files and use the permissions approach (increment checks to see if a certain threshold is reached)
  3. Many cracking tools will block or prevent your app from writing to system files or checking your application files, check that you can still, at least, write to your own documents directory and use NSFileManager to verify what you know should already exist and not exist (basically, double check the validity of NSFileManager)
  4. Use static inline functions! The clearly labeled objective-c function is wide open for attack.

If you fix these bugs, add better protection and obscurity, and you can research new methods of protection, this class will be invaluable. For now, it's dangerous at best. Please consider changing and helping other people protect their projects.

Thanks,
Shmoopi

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

1 participant