This is my first attempt to implement an anti-piracy code in my App.
I am using the Landon Fuller method (LC_ENCRYPTION_INFO).
This method is based on the App being encrypted when downloaded from the App store.
I checked and found out that downloaded Apps are indeed encrypted. I also found out that when I create my App in Xcode - even if I use Release build - the App is not encrypted yet.
Here's my question: When I upload the App to Apple using Application Loader, will they test it after it has been encrypted or will they test it in its unencrypted form? The latter will cause the App not to function properly, which will of course result in the App not being approved.
This article is old and thats the wrong way to deal with piracy. (using In-Apps you can verify purchase)
Most chances the app will be rejected because of using undocumented APIs,
the Author himself state he is not using it anymore.
quote from the page:
However, there's a problem -- none of this is documented by Apple. While most of the APIs and file formats are public, the actual distribution format is not. Apple could change the signature format, the meta-data plist, or any other distribution component at any time, at which point your copy protection may raise a false positive, and your paying customers will be wondering why you're wasting their time.
So the answer for your question is dont worry how they going to test it because it wont pass.
Related
My iOS app has gone through multiple releases. I just added another feature (playing audio files using facebook audio360 tbe format), and the app got rejected with the wording:
From Apple
2. 3 Performance: Accurate Metadata Guideline 2.3.1 - Performance
We discovered that your app contains hidden features. Specifically, It
would be appropriate to remove all code obfuscation and selector
mangling from this app before resubmitting for review.
The next submission of this app may require a longer review time.
Next Steps
Review the Performance section of the App Store Review Guidelines.
Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer
Program.
Once your app is fully compliant, resubmit your app for review.
Submitting apps designed to mislead or harm customers or evade the
review process may result in the termination of your Apple Developer
Program account. Review the Terms & Conditions of the Apple Developer
Program to learn more about our policies regarding termination.
If you believe your app is compliant with the App Store Review
Guidelines, you may submit an appeal. Alternatively, you may provide
additional details about your app by replying directly to this
message.
I am not performing "code obfuscation and selector mangling", has submitted an appeal, which was also rejected pointing to the same guideline.
I am using objective-c with some swift, Xcode 9, Product -> Archive -> Submit to App Store... Is it doing some obfuscation that I could turn off?
Perhaps your audio playing feature is using a 3rd party framework which does use code obfuscation?
In any case, you can use the /usr/bin/nm tool for outputting the symbols within your raw executable and see if any of those look "mangled" in any way.
It's most probably a 3'rd party library that does that.
I used Hopper to get to know the library.
First, unzip the ipa and get the app file.
Second, Drag it to Hopper and start scanning it.
Third, search for the mangled selectors.
I got response from Apple Review Team:
Dear Developer,
Your app, extension, and/or linked framework appears to contain code
designed explicitly with the capability to change your app’s behavior
or functionality after App Review approval, which is not in compliance
with section 3.3.2 of the Apple Developer Program License Agreement
and App Store Review Guideline 2.5.2. This code, combined with a
remote resource, can facilitate significant changes to your app’s
behavior compared to when it was initially reviewed for the App Store.
While you may not be using this functionality currently, it has the
potential to load private frameworks, private methods, and enable
future feature changes.
This includes any code which passes arbitrary parameters to dynamic
methods such as dlopen(), dlsym(), respondsToSelector:,
performSelector:, method_exchangeImplementations(), and running remote
scripts in order to change app behavior or call SPI, based on the
contents of the downloaded script. Even if the remote resource is not
intentionally malicious, it could easily be hijacked via a Man In The
Middle (MiTM) attack, which can pose a serious security vulnerability
to users of your app.
Please perform an in-depth review of your app and remove any code,
frameworks, or SDKs that fall in line with the functionality described
above before submitting the next update for your app for review.
Best regards,
App Store Review
I check my code again and I see AFNetworking included methods: performSelector:, method_exchangeImplementations(), respondsToSelector:
I intend to tell Apple that AFNetworking is an opensource and legal but I think Apple will NOT trust me
So I have 2 questions:
Does Apple ask me to remove AFNetworking from my code after they know AFNetworking included respondsToSelector:, performSelector:, method_exchangeImplementations()
As the way Apple see AFNetworking, is AFNetworking legal? Are there any documents to prove it?
After getting the same message and reading in different forums, it is possible you are using a 3rd party service which allows you to alter the code after uploading the app to the AppStore.
The most popular service for that is Rollout.io, which I had to remove from my own app.
I strongly doubt that AFNetworking would cause you any issues (still looking for an answer from Apple myself, and will update when they do answer)
Update: Apple has approved my app, meaning it was Rollout.io indeed. I believe it'll be true for any 3rd party code injection tool.
I still have AFNetworking, so no problems there.
If I'm developing an iPhone app for CompanyX and when we want to put it on the App Store using CompanyX's signature, and if they dont have the source code, can they do it themselves?
Or do I have to do it with their signature, since I have the source code and then submit it to the App Store?
We have settled on a process where "CompanyX" gives us an account to their iTunes connect so we can build, sign and upload to the App Store in their name.
Probably you can build it on your machine, send them the product and they sign and upload it themselves, however that would be more tedious, as Apple's toolchain with Xcode and the Organizer has become quite good at this for the "usual" case of someone uploading their "own" apps.
AFAIK you have to sign the source code with the key you get from Apple to submit it.
This link shows a video where an app upgrade is "forced" from within the app itself:
http://buzzworks.de/blog/update-ios-beta-apps-from-within-the-app
The App Store is not called in and it's said to work only for AdHoc
apps.
Anyone knows how is this possible?
edit: please give a look to the video before answering. AdHoc apps are signed by the developer and they do not come from the App Store. This sort of forced update is useful when doing beta testing and in enterprise applications.
I've found that it's all explained here:
http://developer.apple.com/iphone/library/featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
The developer should create an .ipa with the app and a manifest in plist format with the URL to the .ipa and a few other things.
The app can optionally implement its own way to find if an update is available and open
the URL to the manifest.
I didn't it's really possible because the app has to somehow sign itself. The best I can think of right now is that the app is not signed?
You can always force people to go to the app store when a new version is out. Simply make the app connect to a webservice first. Other solutions are not accepted by Apple, or will quite simply not work because of other issues (signing is one of many).
You could also design your app in such a way that forced updates are never a requirement. You can load your user interfaces from the web (Apple has presented some valuable information about that during the previous WWDC), your data can come from the web, and if there is any other correction to do just ensure your app is backwards compatible.
That's how the app store works. And it never requires a 'forced update' ... Well, almost never ;-)
How can I determine if DRM was removed from iPhone application bundle (to protect it from piracy)?
I have an iPhone app which integrates with a third party web service. I use the technique described in this question to find pirates and then have the app "phone home" with the user's device ID and user ID for the web service (I haven't done anything with this information yet, but I was thinking about contacting them and asking them nicely to purchase my app).
In addition, once a user has used my app for a certain amount of usage, I limit functionality and direct the pirates to the App Store for full functionality.
To my knowledge, there's only one way to remove DRM: Crackulous.
So to find out what to look for in a cracked application, I would run Crackulous on your app and compare the app bundles. It should be fairly easy to determine what's been changed by looking at filesizes and running a diff on the files in the bundle.
Once you know what the changes are and to what file(s), just look for those changes in your application to determine if the application has been cracked.
If you find out exactly which files should be checked, please post your findings here so others can benefit from your research.
My previous Stack Overflow question may help you out: Reducing piracy of iPhone applications
Its probably worth pointing out that there are no casual "pirates". Casual users cannot download your app from the app store without buying it. All the DRM-removal schemes require to be run on a legitimately purchased copy.
As to looking at the bundle for changes, as I recall all you need to do is step through the link-loader commands and ensure that the code bundle is still tagged as encrypted. No need to compare it with anything. You'll need to read about Mach-O file format to do this, but thats not difficult, its all documented on developer.apple.com