I'm looking for an open source for antitampering and Code obfuscation tool for my iOS project. Some library like Proguard in Android.
I found iXGuard and Dexprotector are paid tools. I'm looking for some open source tool.
Any help will be appreciated.
Xcode already does most of the obfuscation part
Find the points below:
Code tampering and obfuscation are hardly related terms because RELEASE native builds from Xcode destroy names of variables,
functions, etc So I would hardly bother with obfuscation - you just
do not need it.
Apple encrypts the code of the applications submitted to the App Store and restricts access to the machine code of the apps after
download to prevent easy static analysis of the application.
And what use case do you mean when you refer to anti-tampering? Do you mean the release of the same app with different resources (images + brand name) to the official app store? - I would hardly bother with such attempts.
And be prepared for any App Store rejection if you are doing any extra code obfuscation by using paid or any other third-party tools. Apple rejects most of the obfuscated things done through these tools. Apple rejection message looks like this:
3 Performance: Accurate Metadata Guideline 2.3.1 - Performance We discovered that your app contains obfuscated code, selector mangling, or features meant to subvert the App Review process by changing this app's concept after approval to the App Store.
https://developer.apple.com/forums/thread/113211
The code for a native app is stored in the form of a binary executable file, which is further encrypted; its decryption is performed only when the executable file is loaded by the processor into the random access memory and the whole decryption process happens at the hardware level. That is why it is very hard to create offline decryption tools. The only way to decrypt encrypted binary data is on a jailbroken device with a few special tools installed.
https://mentormate.com/blog/security-in-ios-protecting-ipa-file-content/
I have searched for a library that helps me to obfuscate the code and I've found this one:
https://github.com/rockbruno/swiftshield
Related
I know that Swift libraries can be statically linked, but I'd heard that linking in Swift would cause Apple's private API detectors to prevent it from going into the App Store? Is this true?
Found a link on an Apple Forum; hopefully it helps you, I haven't yet submitted anything to the AppStore yet.
But overall, seems like it's possibly more trouble than it's worth. If you get denied, you're possibly then going to spend time rebuilding/reworking.
Seems to be one point brought up, is to ensure you've added all files needed to compile your App, in your submission.
Link below:
https://forums.developer.apple.com/thread/94488
As of Xcode 9 beta 4, Xcode natively supports static libraries with Swift sources. but You have to use dynamic lib
Here is how Apple describes their dynamic framework:
Two important factors that determine the performance of apps are their launch times and their memory footprints. Reducing the size of an app’s executable file and minimizing its use of memory once it’s launched make the app launch faster and use less memory once it’s launched. Using dynamic libraries instead of static libraries reduces the executable file size of an app. They also allow apps to delay loading libraries with special functionality only when they’re needed instead of at launch time. This feature contributes further to reduced launch times and efficient memory use.
Source: https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html
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.
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.
Greetings,
I'm in the progress of writing a web server script that lets you create custom iOS apps (basically exchanging logos and a few other things). The web server customizes a previously uploaded "shell" .ipa and re-zips the whole container to send it to the user's browser. That is: we customize a previously uploaded .ipa on the web server and let the user download it for submission to the App Store.
The next step would be to re-codesign the whole .ipa - because we changed the .IPA contents and the user must use his own signing identity - so that he can actually upload it to the App Store.
From what I understand, there is a "CodeResources" file which contains some kind of hash for each resource file in the bundle, and the executable contains some kind of embedded signature as well. To generate these, you'd have to use the "codesign" utility on the user's computer, then use Application Loader to submit it to the App Store. Correct so far?
What I'm trying to find out is:
Is there a way to codesign the .ipa on the server (with having the user upload his certificate beforehand), so that he does not have any extra work to do?
If 1) is not possible, is there some kind of tool that allows to re-codesign the .ipa without much hassle? Xcode seems to require some project setup work to do just a bit of code signing - if possible at all.
Are there any alternative ways to codesign the .ipa files for the user - possibly without having to manually do it by hand?
Thanks in advance!
Xcode uses the codesign command line utility to create the CodeResources folder and the digital signature, you can invoke it yourself to sign an app bundle outside of Xcode. You could probably automate this on a server if the server was running Mac OS X; if you're really clever you might be able to figure out how to create the signature yourself using openssl (the signing certificates, etc. are all standard stuff). Or, if you can count on the user having the dev tools installed, provide them with an app that automates the signing for them.
Here's a blog entry describing some of the process (though the use case is a little different).
I don't like to answer my own question, but I want to close this after so long.
We ended up using Xcode's targets and schemes to ease up the generation of many different apps. Since we have a reasonable number of app variants, this seems to be OK for now.
Code signing is a mess and Apple constantly changes the technical process behind it - so it's a moving target and requires a lot of hacking and trial-and-error work.