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.
Related
I need to refactor an app, written long time ago. As a begginer, I'm struggling a little bit with a bunch of new question.
It was written in objective C.
It has included some frameworks (security, coredata, quartzcore, mapkit...) and application uses tapku library. That's what I know so far.
There is an XmlRpc external there. My question is: If that all is written in 2014. from some random guy, do I need to change/upgrade all of this frameworks/external etc. and find a newer version of it on the internet, or I can use it as they are?
Edit: I'm rewriting the whole project, I need to fix things that are not working, (I didn't find any still, though) and I'm just asking if I would have benefits (speed of application, user experience etc.) if I include a newer version of all of these frameworks, if that is possible.
I have created a number of re-usable classes that I use across xcode projects, for example:
Utility
EmailController
MarketingController
FlashLightController
etc
I had been simply copying these class files from and back into a central repository, but now I have a number of apps it is all getting a little confusing from a config management point of view. So I was looking for an alternative.
I started investigating Static Libraries but they seem to be quite a lot of more effort for simply re-using code (e.g. different libs for device vs simulator, still having to have copies of .h files, etc).
Does anyone know of a decent alternative for quick and easy code reuse?
Thanks, Charlie
You can put the code files into a project without actually copying them into the project. In other words, just keep the class files in a completely separate location. Import them into many projects, but uncheck the option to copy them in. The projects will still refer to them successfully. Now a change made in the class files will propagate to every project that uses them.
Also, consider whether workspaces will help you.
In my view, almost anything is better than making a library or framework!
Static libraries would probably be your best bet, as I have used them and have found them to be pretty easy to use. (I haven't had to use different libraries for device or simulator, mine works on them all). Having the header isn't that annoying, and static libraries are really the only way (outside of dynamic libraries, which are banned by apple) other than copying the files to reuse code.
I'm fairly new to programming and wanted to start programming more efficiently. Try as I may I often find myself straying from the MVC model.
I was wondering are there any tips or methods in keeping your code organized when coding in xcode objc? To be more specific (I know you guys like that :) I want to
Be able to write libraries or self-containing code that can bring from one project to another
Share my code with others as open sourced projects
Prevent myself from writing messy code that does not follow proper structure
Use a high warning level. Build cleanly.
Remove all static analyzer issues.
Write some unit tests.
Keep the public interfaces small.
Specify your library's dependencies (e.g. minimum SDK versions and dependent libraries).
Compile against multiple/supported OS versions regularly.
Learn to create and manage static library targets. This is all you should need to support and reuse the library in another project (unless you drag external resources into the picture, which becomes a pain).
No global state (e.g. singletons, global variables).
Be precise about support in multithreaded contexts (more commonly, that concurrency shall be the client's responsibility).
Document your public interface (maybe your private one too…).
Define a precise and uniform error model.
You can never have enough error detection.
Set very high standards -- Build them for reuse as reference implementations.
Determine the granularity of the libraries early on. These should be very small and focused.
Consider using C or C++ implementations for your backend/core libraries (that stuff can be stripped).
Do establish and specify any prefixes for your library's objc classes and categories. Use good prefixes too.
Minimize visible dependencies (e.g. don't #import tons of frameworks which could be hidden).
Be sure it compiles without the client needing to add additional #imports.
Don't rely on clients putting things in specific places, or that resources will have specific names.
Be very conservative about memory consumption and execution costs.
No leaks.
No zombies.
No slow blocking operations on the main thread.
Don't publish something until it's been well tested, and has been stable for some time. Bugs break clients' code, then they are less likely to reuse your library if it keeps breaking their program.
Study, use, and learn from good libraries.
Ask somebody (ideally, who's more experienced than you) to review your code.
Do use/exercise the libraries wherever appropriate in your projects.
Fix bugs before adding features.
Don't let that scare you -- it can be really fun, and you can learn a lot in the process.
There are a number of ways you can reuse code:
Store the code in a common directory and include that directory in your projects. Simple, but can have versioning issues.
Create a separate project which builds a static iOS library and then create a framework. More complex to setup because it involves scripting to build the framework directory structure. But easy to use in other projects and can handle versioning and device/simulator combined libs.
Create a separate project which builds a static iOS library and then include this as a subproject in other projects. Avoids having to build frameworks and the results can be more optimised.
That's the basic 3, there are of course a number of variations on these and how you go about them. A lot of what you decide to do is going to come down to who you are going to do this for. For example I like sub projects for my own code, but for code I want to make available for others, I think frameworks are better. even if they are more work to create. Plus I can then wrap them up with docsets of the api documentation and upload the whole lot as a DMG to github for others to download.
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.
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.