This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
iPhone/iPad App Code Obfuscation - Is it Possible? Worth it?
I have spent a lot of time on this and I couldn't able to find a perfect answer. That's why I decided to put my question here. I have an iPhone application and want to encrypt the code to prevent from class-dump or otool utilities. (Tools used to dump out the headers from executable). I would like to know is there any way to encrypt the source code or obfuscate the source code?
It's a lot more complicated than it might seem initially. Any tool that mangles method names has the potential to fudge up:
KVC compliance
The use of dynamically generated selectors
Nib file compatibility
Protocol conformance
Method inheritance
Obfuscation is just another layer to deal with; often obfuscation is easily reversed. It is not really possible to “encrypt” your classes because the Objective-C runtime and Cocoa framework won't know how to decrypt it. Anyone determined enough will eventually figure out how your program works.
Actually you can provide some obfuscation and tamper protection with specialist 3rd party tools. There are 2 companies, I know of, that provide tools or services to do this : Arxan and irDato.
Neither are cheap or accessible to small developers but if you are developing for a large corporation then you should consider them.
Obfuscation is done by mangling code paths and adding redundant instructions so as to confuse anybody trying to reverse engineer the code. Tamper protection is done by adding checksums to the code and embedding checksum checks within functions. You can create a network of interdependent checksums that makes it extremely difficult to bypass them. There are a few other things that can be done but you really need to talk to specialists in this area.
Further to the earlier answer, Apple does not encrypt the binaries but just signs them. It is fairly easy to reverse engineer and modify app binaries on a jailbroken device.
Apparently, according to this answer Apple encrypts iPhone binaries as a matter of course for all iPhone apps.
I'd stop worrying about it.
Related
i'm newbie in FTP connection programming in Cocoa. I found 2 library that i can choose for make my app, but i dont know what's the best between these libraries. The libraries are libcurl and chilkat . The problem is what benefit of each library? Did somebody compare it? or maybe can anyone tell me about your experience? Thank you
I don't have any experience with chilkat, but I can tell yout that libcurl is used in a lot of programming languages and is available on a lot of systems. In for example PHP or on a Mac curl is a great tool to use.
So I would advice libcurl if it's available on your platform. You will probably find more information about curl and it has proven itself on many other platforms.
Also interesting if you want to go with curl is curlhandle. It's a cocoa wrapper around the curl library. Probably very handy in your case, but I've no experience with it.
I can tell you that the difference between libcurl and chilkat is like this: (though you probably know by now)
Chilkat is like the chess game you buy at the store and libcurl is like the plastic in liquid form you buy that you can make any chess piece with.
Libcurl is a slightly abstracted sockets-connector and Chilkat handles everything you'd do, up to a certain amount, with that connection. You're either staring at bits or something "made those bits into an email". I'm about to buy Chilkat for some of the libs, I like the features, but at the same time I wish I had time to read the RFC's and play with the other stuff using libcurl. Anywho, hope that answer is worth something to someone.
Because this question is still ranking high on google i give you my experience.
I bought chilkat in 2015 and moved to libcurl later and my own implementation much later. Both are far from perfect. libcurl just shows it's age and some weak designs.
libCurl is an library that tries to implement all URL able protocols even if they are designed as stream protocol like FTP. Do yourself a favour and only use it with HTTP/HTTPS. It just does the transfer part. Which is not enough for handling. You would love to see at least mime and charset routines to use the downloaded files.
Chilkat is a toplevel library that tries to give you as much highlevel access as possible. It uses background threads in script languages where it is not easy to use. The problem is that the API is terrible, very little documented and total failure when you want to write a quality program. For example it returns requests as a string. There is no way for stream processing. Now imagine you download a large GB iso file, you wont be happy. It can return as a file but then you have to specify this at the begin of a request when you don't knwo the download size.
Also the code quality until proven otherwise is bad. There are a few chilkat source code snippets in the wild which you can find via google and they are pure madness. Ok we don't know how this old code has been refactored now. But it leaves a bad taste, remember this is closed source and there is not a single mention about corner cases, which protocol is implemented, which feature of protocols are implemented and so on. You are using a total black box.
Also it does not allow high performance and high value code. I used it to write a web crawler and it was much much slower then libcurl.
I later used the HTTP and SSH compoenents to automate some server/client management scripts and there it shines. You know both sides and can just test if they work together and don't get any surprises. Then it is indeed easy and better then using the broken python or ruby SSH.
But if you ever contact with another unknown server, Chilkat is not your library.
I have developed a number of frameworks that I want to ship with my application. I don't want others to be able to use the frameworks, but i've seen utilities such as class-dump which can get the headers back easily.
My question is, how can I make my frameworks more secure? I know that they'll never be 100% secure, but are there some good general tips to follow?
Thanks!
In short, don't bother. The very nature of the Objective-C runtime is that there is significant metadata available.
The reality is that it would be exceedingly rare for someone to pick up your framework and try to embed/use it.
Note that code obfuscators don't really work very well; there is still quite a bit of metadata that must be exposed. You can go that route, but -- generally -- it makes debugging/crash analysis significantly more difficult without actually solving a real problem.
I see others have pointed you down the path of obfuscation (though I suspect that the answer of #define someSelector mmmrrrggglll wasn't really tested much).
Some specific points to consider as you go down this path (I'm sure I've missed many):
if you use KVO/KVC, make sure you obfuscate all those calls to addObserver:* and the like
if you are targeting Mac OS X, don't forget about Bindings, too!
Interface Builder's xib files will often contain references to instance variables and/or properties and/or methods. Don't forget about those!
Anything that uses runtime introspection will need obfuscation, too.
make sure you don't obfuscate anything that the system frameworks are dependent; wouldn't want to subclass NSView, say, and then obfuscate drawRect: or initWithFrame:.
In some cases, the Info.plist can refer to class names and entry points. Don't mess with those, either!
Also, make sure every use of #selector() is also properly obfuscated; nothing like setting up an NSTimer firing against a method that no longer exists.
Make sure your obfuscation plans also includes the engineering work necessary to create an un-obfuscator for crash logs.
You'll also want to consider how you are going to debug a production binary; assume your stack traces will be obfuscated. b mmmrrrggglll ftw!
If your framework has symbol exports control, make sure to obfuscate 'em, too! Keep in mind that the way symbols are created differs between architecture and compiler, in some cases.
You can use static libraries to link with your application instead of frameworks. However, if you want to ship frameworks, you can use code obsfucators to make your library more difficult to use.
EDIT:
This SO post has a pretty simple description of a basic obsfucation.
How can objective C classes be encrypted
There are products on the market that do this, but they are expensive.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Objective-C Code Obfuscation
I am trying to put together an iOS package that can be reused in multiple apps. I would like to be able to bundle it up for others to easily plug in and use, and I would like to obfuscate the code so that no one can read it.
What would you recommend between building a framework, a static library, or another solution to accomplish this and why?
If you're distributing for iOS, you have two options:
Distribute a precompiled binary and headers
Distribute the source
Since you're asking about hiding stuff, I don't think #2 is what you're looking for.
As for #1, the best you can do is just not tell 3rd party users about more stuff. They'll still be able to use the runtime to find methods and properties and instance variables, etc. If you're doing everything in C-land (ie, no Objective-C classes), then they can still use things like otool to dump symbols.
In short:
It's probably not worth trying to "obfuscate" your code. Just tell them about the stuff they need to know about, then give them a .a file and the headers they need.
A framework is the standard Cocoa approach to shared code. You can distribute a framework as a compiled code library and a collection of public headers without making any of the underlying Objective-C soure code visible. Of course, a dedicated hacker could still read the machine code, but this would be a big undertaking, and probably not worth the time they would have to spend on it.
If you are really concerned about sensitive code, you could consider an internet-based service, in which your library calls out to a remote server under your control to perform some business logic. This approach is quite a bit more involved, and does not offer as much flexibility for your customers.
I understand that it is easy to hack Mach-O executable, I just want simple protection against "class-dump" tool. Is there any tool or XCode plugin that can change all classes names and class functions to something not very readable (like random combination of symbols and numbers)?
Frankly that's all protection I need.
I wrote a bit about this in this blog post, but to summarise: you can avoid having methods appearing in class-dump by registering them at runtime, or just keeping them as functions.
If really all you want to do is rename the classes/methods, you can use the tops command-line tool or Xcode's refactoring feature.
Are you looking for Objective C obfuscators?
This page has a great discussion on Obfuscating Cocoa.
You really probably don't want to bother with this. Obfuscation will not prevent a determined hacker from reverse engineering a truly valuable algorithm. Casual users won't bother, so you're likely doing a lot of work for little added value. As #mvds points out in a comment to your question, NIB connections will betray the purpose of many classes and a determined hacker could use dtrace/Instruments.app to trace messages to uncover much of the rest of what they need.
Any truly valuable IP needs to be protected by something stronger than obfuscation and should probably be written in C/C++ as well as having legal patent and copyright protection (and enforcement).
If you're not doing already, you can at least strip your executable of certain unnecessary symbols by enabling 'Deployment Postprocessing' and 'Strip Linked Product 'in the Xcode build setting. (Or just use the strip tool directly.) Better than nothing.
I've just finished a library in Objective-C that I compiled as a Static Library for distribution.
I'd wanted to know what chances to get this decompiled are out there.
Do you know any software that can do this?
If so, how could I protect me better?
EDIT: My static lib is made for iPhone / ARM
I created an algorithm that depending on the some parameters of the app, it can run as demo or as full code. You init the object with X variables and unlock the full version. I was wondering if they'll be able to see this algorithm so they can create a key generator.
If it executes, it can be decompiled. Objective-C is particularly easy to decompile into readable code thanks to its dynamic features. If you want to make things a little bit harder, you could write most of your code in plain C and strip the executable — which of course has the tradeoff of making your application design harder to manage. But be honest with yourself: If somebody wants to crack your code, you are not going to be able to stop them. Crackers have practically unlimited amounts of time and enthusiasm and will actually be excited by any novel efforts you put in to stop them. Nobody has yet made uncrackable software, and the biggest corporations in the world have tried. You're not going to do better than them, especially if you need to ask about it on Stack Overflow.
Take the time that you would have put into thwarting decompilation and use it to make your product better — that will have a much better ROI.
It's not clear what you are trying to protect yourself from. Yes, it can be reverse engineered. The simplest tool is otool, part of the standard developer distribution:
otool -tV <library>
From that they run up to things like IDA Pro, which has iPhone support and is very nice for this kind of work. In between, I'm really surprised that I haven't seen a rework of otx for iPhone/ARM yet. I wouldn't be surprised to see one show up eventually. And of course there's gdb if you're trying to work out how things flow and what the data is at various points.
If you have more details about what you're trying to protect yourself from, there may be some targeted answers. Beyond that, read Chuck's comments.
ChanceGetsDecompiled = ExpectedGainFromBeingDecompiled / PopularityOfLibrary
Well if you REALLY want to know I would try decompiling it your self. You don't say if this is for PPC, Intel, or ARM which makes a difference. Here is a decompiler for Intel
i386 Decompiler
I don't know what you could do (I don't think there is much) to limit this. Code can always be reverse engineered. Be happy that your not using java or .net. Their decompilation is so nice.