Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I've researched quite a bit, both on SO, as well google-ing all over the place, but I can't seem to find a straight-forward answer in regards to code obfuscation for iPhone/iPad apps written in Objective-C.
My questions are these:
Is there a way to do it? If so, how?
Is it worth it?
Does Apple allow it, or have a problem with it, when the app is submitted to them?
There doesn't seem to a code obfuscator for Objective-C. But let's assume for a moment that one does exist.
Apple will probably not reject an obfuscated app as long as it doesn't crash. The main question is: what is the point of obfuscation ? Normally, you want to obfuscate code to protect your knowledge, for example if your program uses a copy protection you want to make it harder for a potential cracker or if you're using some advanced algorithm you don't want the business competitors to be able to decompile it.
The copy protection is already been taken care of on iOS. Although through jailbreaking a normal app can be copied and run, I'd say the actual number of users who do this is fairly low (at least a lot lower than on "regular" computers like PC and Mac). Do you expect piracy such a big problem that you need to obfuscate ?
If you do have important knowledge to protect then obfuscation might be worthwhile. Obfuscation has its downsides: you can't debug your obfuscated app any more. Crash reports will be useless.
You might also want to read the article Obfuscating Cocoa.
Back to the fact there doesn't seem to be an obfuscator: What you can do is this trick: say you have a header like this:
#interface MyClass : NSObject {
}
- (void)myMethod;
You could do a cheap obfuscation like this:
#ifndef DEBUG
#define MyClass aqwe
#define myMethod oikl
#endif
#interface MyClass : NSObject {
}
- (void)myMethod;
This way you can still use meaningful symbols in your source, but the compiler would turn it into "garbage" when not compiling for debugging.
Yes, you can take a look at EnsureIT for Apple iOS or Contaxiom Code Protection
It depends. Security normally introduce complexity, you have to balance it between usability.
Apple should not have any problem with it (correct me if I'm wrong), and I personally have few apps that uses code obfuscator.
Further to the earlier answers there are now several 3rd party tools that offer some degree of obfuscation and integrity protection including :-
Arxan,
Metaforic,
Cryptanium
They vary in capabilities and include :-
Control flow obfuscation e.g. ARM instruction flows are mangled with redundant instructions to try to hide the original purpose of the code,
Class and Method renaming - renames your methods and classes to meaningless names although you have to be careful where this is used as you can easily break your app because the Objective-C runtime is expecting to find certain names,
String encryption - all static strings in the app are encrypted and code is inserted to decrypt the strings just before use in order to make static analysis harder
Anti-debug - code is inserted to break the usual debuggers (not always successfully),
Anti-tamper - usually builds a network of checksums that protect the binary code from modification,
Objective-C runtime protection - usually checks obj-c registered method implementations to make sure that they are in the app and haven't been 'swizzled'.
All of these tools are very expensive and not without their problems so you really need an application that requires a high degree of integrity in order to consider them e.g. banking or where DRM is very important.
For these types of app you will also need skilled penetration testers to ensure that your app is not exposed in other ways as these tools are often only as good as the people using them and there are still other OS vulnerabilities that will need mitigating that the tools don't address.
The executable of an app is already encrypted by Apple, and the executable code segment of the app sandbox isn't writeable, so you can't do additional encryption that requires runtime arm code modification. And the optimizer pass of the Objective C/C compiler already creates something very different from the original source code. Using more C and less Objective C will reveal less of your function names, as method names are embedded in visible plain text, but C function names are not. So any trade secret type code should probably be coded in plain C, and compiled with the optimizer turned all the way up. You could obfuscate any webKit Javascript embedded within the app bundle, or any other embedded VM code (as long as interpreted code isn't downloaded).
Probably not because Objective-C compiles out to processor instructions rather than being interpreted or compiling to byte code, so decompiling the code will already produce pretty obscure results. Obfuscation is something you usually only needed when you have to distribute the source of your code, like in interpreted languages like JavaScript, in order for it to run even when you want the code to remain secret.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I release a bunch of tools for free, but recently I have began to sell an application, that has private research, and people have been able to get my source code, and one person publically released my entire source. I spent a lot of time on this program, just to have someone crack it, and release my entire source.
How can I go about protecting my program? I have tried HWID, but people are still able to crack it. I know I am limited by C#, but it the most convenient to use. I just need a way to protect my programs from people trying to do this.
You could have a look at the many obfuscation tools that are out there, for example these:
http://gapotchenko.com/eazfuscator.net
http://orangeheap.blogspot.nl
http://confuser.codeplex.com (succeeded by https://yck1509.github.io/ConfuserEx/ and then again by https://github.com/XenocodeRCE/neo-ConfuserEx)
http://ntoolbox.com)
Well, the problem with languages like C#/Java is that they are generally much easier to de-obfuscate. The way to secure this is generally to put this stuff into a webservice, but you said you couldn't really do that. What about porting specific non-trivial functions over to a language like C, and obfuscate that. Your C# program could then use reflection to make calls to this external/unmanaged dll. It would increase the difficulty for de-obfuscating, but the problem is that if someone wants it bad enough, they can figure it out as it is client-side.
It may be that legal action is the only real solution here, but this is not a site for legal advice, and I am not qualified to give it if it were.
Additionally, this could be a business decision. Consider Making your software open-source and post a donation link. I am also not qualified to give business advice, but this is worth considering. It may actually increase your revenue, not to mention the other benefits that come with releasing open-source software.
There's Dotfuscator (http://www.preemptive.com/products/dotfuscator/overview). But the best solution in some cases is to offer what you do as a web site (Software as a Service).
Consider this tool for example to convert VB to C#: http://converter.telerik.com/
Or this tool to format JSON: http://jsonformatter.curiousconcept.com/
This may or may not work for you. I don't know what the nature of the software you're trying to protect is.
No, your code needs to contain the information needed to decrypt itself, its an impossible problem to solve.
Your best solution is to put your intellectual property on a server in the cloud that only you have access to. Give your customers a unique login, audit their access to check for abuse, off load as much grunt work onto your customers machines, but keep your algorithms locked into the cloud.
If a company works on matlab projects, then how do they provide the client the project? I mean which file do they send to the client as they cannot hand over the client the whole codes and data ?
It would depend on lots of things, such as the nature of the product you are building for the client, your relationship and contractual agreement with them, and whether they need to modify the product in the future.
When I carry out consultancy on MATLAB projects for a company, I usually supply them with MATLAB source code. Part of the contract would typically say that they own the code (and the copyright to the code) that I produce for them, and they can then do pretty much whatever they want with it.
If you have a different relationship, where you continue to own the code and need to prevent them from reading it and/or modifying it, then the issue is really the same as it is for any other language: you rely on a mixture of technological restrictions and legal restrictions, designed to be as restrictive as you need while minimizing inconvenience for the end-user.
For example,
You can obfuscate your code using the command pcode. That will prevent almost everyone who isn't extremely determined from seeing your code and modifying it (there are some loopholes though), but they will still be able to run it within MATLAB. Downsides might be that your code may become unexecutable in a future version of MATLAB, so you may need to support it again to fix that later. To mitigate this, you could specify in your contract or license agreement that only specific versions of MATLAB will be supported.
You can use MATLAB Compiler to produce a standalone library or executable that contains the code in an encrypted form. Downsides might be that they would rather use the code from within MATLAB. An upside would be that unlike the first option it doesn't require MATLAB, so you're not vulnerable to backward-compatibility issues in future.
You can include licence-management code within your MATLAB application. You can either roll your own, perhaps by calling a bit of Java for the cryptography (you will likely not be able make it very secure, unless you're very talented, but you'll probably be able to make something simple and workable), or you can buy third-party C libraries that do it well, and call them from MATLAB.
You can simply put copyright lines in your code saying that you own the copyright, and licence the code to them under specific terms, such as that they may view it, use it, but not modify or redistribute it. If you really want, you could ask them to also sign a non-disclosure agreement requiring them not to discuss the content of the code with third parties.
Although the technological restrictions available are a little different in MATLAB than they would be for a compiled language such as C or Java, at the end of the day those are only ever there to keep honest people honest - anyone determined will be able to get around them eventually, and they may well inconvenience the honest people, annoying them into disliking your product or service.
Better to use a mixture of very light technological restrictions, crystal-clear contract and licensing terms, and trust.
<advert> One of the consultancy services I offer is advice and help in preparing MATLAB code for deployment, including protecting it. If you think you'd benefit from that, please get in touch. </advert>
You can use the Matlab Compiler and compile your codes in to an exe file for windows. This is what is usually expected by a company. Some who have R&D themselves might ask you for the original m-code, or specific functions depending on your relationship/contract with them. I've been asked to give m-code several times, and it says on my contract that I am suppose to give this information to them. (UK based)
I would like to encrypt a few of my obj c classes in my iphone game which handle openfeint data and classes which handle scores.
I have heard there is a way to encrypt this data to act as another level of security, at least enough to discourage some from cracking it and forging scores on a jailbroken iphone and then spam the leaderboards.
How is this done, what are good techniques to secure this data and discourage some from attempting to spoof data?
Thanks
To truly encrypt compiled code is probably more trouble than it is worth. You have to isolate the code that will be decrypted into a dynamic library and load the library manually after decrypting it in memory. Dynamic libraries, and the other methods you might use to modify code at runtime, are frowned on by Apple when used with iOS.
With Objective-C you essentially ship with the headers build into your code. That makes it much easier to dig around in your application. Anything you can do in C, where symbols may be stripped, will be slightly harder to read. You can also use #define to obfuscate your class and method names a little. This is nowhere near encryption, but is much easier to implement and less likely to introduce wacky bugs.
#define MyNicelyNamedClass somegarblegarble
#define myNicelyNamedMethod othergarblegarble
#interface MyNicelyNamedClass
-(id) myNicelyNamedMethod;
#end
This is a relatively painless way for a developer to make their Objective-C code less obvious to others. It is about as effective as javascript obfuscation, which is to say it is one more little hurdle that will dissuade many casual attackers.
If you choose meaningful but misleading names instead of straight garbage you may even trick someone into spending hours digging through the wrong code. Not that you would ever know, but it is a satisfying thought.
Encrypting classes suffers the "shipping the lock with the key" problem that any DRM or similar security system has.
What you are looking for is self modifying code, where the code is either loaded and decrypted later by the application, or is present as machine code in the binary and modified at runtime by a key the application has.
Note that you'll likely create some very subtle and interesting bugs, and your method will be bypassed (it will take someone maybe an extra day).
Apparently Apple has changed some term in the agreement again.
From http://www.appleoutsider.com/2010/06/10/hello-lua/
section 3.3.2 is now
Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.
instead of the original
No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
I am more interested in embedding Lua, but other people have other embeddings they want to make.
I am wondering how you ask for permission, and what they mean by the terms "minor features" and "consistent" and how will Apple interpret this section? It seems to have enough loopholes to drive a real firetruck through.
(BTW this is a terribly important question for me an my product.)
Realistically, the ultimate interpretation of the developer agreement is up to Apple.
Since this is all new, it's not clear who to e-mail. You could start with the iTunes Connect people, but be prepared for a long wait to hear back. Alternatively, I've gotten some occasional quick help just by calling up the nice Apple people in Ireland.
Given the wording , if you want to embed Lua, you should be prepared to justify that you will be using Lua in a limited fashion to provide minor features or functionality.
Since you've stated this is a really important question, you might want to consider the risks inherent with pushing the envelope/being a pioneer. If there's an alternative way to get around all this, you should consider it. If there's no way around it, it might make more business sense for you to pursue another platform for now.
Now that monotouch is banned, I was wondering if there is a way to translate C# (or some other language) into Objective-C? I won't mind using Apple's API as long as I don't have to declare my variables in 3-4 stages (ivar-property-synthesize-dealloc). All I want is a less wordy language, to concentrate on my intent and not on the compiler syntax.
You should pause to see what actually happens instead of assuming Monotouch is banned.
Or, learn Objective-C. It's good for the mind to learn a new language anyway. And the frameworks will make more sense to you.
You could always define your own meta language for objects, write your intended meaning, parse that file, and paste the newly manufactured code into XCode.
And if you're really dead-set against ObjC and XCode, Apple has given you your ultimatum: use it or leave.
If it turns out the way people are suggesting it will turn out, then the answer to your question doesn't actually solve your problem.
The SDK agreement make specific mention to the 'originality' of the Objective-C (and other languages). Translating from C# to Objective-C breaches this requirement that applications be originally written in Objective-C.
Secondly, Monotouch already supports full AOT compilation.
Translating would be against Apples policy because your code must be originally coded in C, Obj -C, C++.
Coming from originally learning Java its really not that hard. Is the declaration of variables in multiple places really your main objection? Its easy to do and gives you tight control over your program. It is also suspected that iPhone OS 4 needs native code to be able to multitask properly. It makes sense as well otherwise they would of amended the current licence agreement if they wanted to stop Adobe.
This is something I wrote last year and may help you with the transition - Objective C by example for a C# developer, assuming Monotouch is actually forbidden.