Security of applications is especially vital in the mobile world. We need to use different tools to hide our IP against attackers or other companies which can try to copy our products. It's rather simple when using web technologies. All your code sits on the server under your full control, and no one except you has access to sources and implementation details. It's especially difficult for mobile devices, where you have to ship applications compiled in a format understandable for OS, i.e. Android or iOS. One of the techniques especially useful in hiding our secrets is obfuscation. Obfuscation makes programs, i.e. source or machine code, difficult for humans to understand. It isn't irreversible, but most people will give up sooner.
There are different methods used to obfuscate applications. To name a few:
- Rename class and methods
- Encryption of strings and other constants
- Methods inlining
- Proxy methods
- Virtualization of code
- Tamper detection mechanisms
- Anti-debug mechanisms
- Control-flow obfuscation
- Junk classes and methods
Do I need it?
In iOS it is especially crucial to use any kind of obfuscation. Due to Objective-C architecture any dissection of iOS applications is rather simple. You've probably heard about class-dump, cycript or Clutch. These tools make it very easy to dump and analyze any application built by you. This makes you vulnerable to anyone who wants to look into your code. He can even modify behavior, graphics and release it as his own.
What about the others?
In the Android world we have the amazing ProGuard made by Eric Lafortune, the speaker of 2014's Mobile Central Europe. ProGuard is in fact industry standard, it's well documented and everyone uses it. ProGuard not only makes applications more secure, but it creates compact code by shortening class and methods names and removing dead code.
That's for Android, but what about iOS? It's much worse. There are some tools, but almost all of them are commercial:
For over a year we were working on a project where security is especially important. We thought of something much simpler, yet very useful. We couldn't find a tool that could be good for us, so we developed our own. Now we turned it into reusable piece of software.
How does it work?
We parse the Objective-C portion of Mach-O object files. Parse all classes, properties, methods and i-vars defined in that file. Then we read all system frameworks doing the same (parsing Objective-C code structure). Then for each symbol from your executable that isn't present in system frameworks we generate a random identifier consisting of letters and digits. The generated list of symbols is then formatted as a header file with C-preprocessor defines. This file is then included in your .pch file. When you compile your application next time every class or method present in header file will get a new name.
We built the first version completely in
BASH. What's interesting, is that it was only 274 lines long. We still use it in one of our projects. iOS-Class-Guard is the second release, rewritten completely from scratch as an extension for class-dump. Our goal was to cover all of the aspects of iOS app development. We've tried to leave as little as possible not obfuscated.
- Storyboards and XIBs - if you're using Interface Builder to create UI for your app our tool will automatically find them and obfuscate them.
- CoreData - this one is a bit trickier. The greatest benefit of our tool (generating obfuscated symbol names randomly) becomes the biggest obstacle in fully supporting
CoreData. Even when a model is unchanged between obfuscator runs, symbols would get different identifiers. This could lead to, e.g. wiping out whole persistent store or app crash (depending on implementation). So, for now, we've decided to exclude symbols found in
- CocoaPods - we also thought about external dependencies in your project. If you're including 3rd party code in your project, it'd be obfuscated as if it was your code. What if you've decided to go with CocoaPods? We thought about that, too. All dependencies added to your workspace will get obfuscated, as long as source code for them is included.
- Crash Dumps - from time to time we all get them. It's never a nice moment, but they help to fix issues with our apps. So you might wonder how to track the bug when the crash dump you've received contains only obfuscated symbols. We also prepared a tool to handle that. Our tool generates a symbols mapping file, which can be later used to reverse the process and replace obfuscated symbols in a crash dump file.
- Symbol names deduction - this one is also a bit tricky. Objective C provides many ways to write the same part of code, i.e. you can define getter and setter but use
.notation in your code as if it was a property and vice versa. To make it even worse, you can define custom getters and setters. We've tried to make our tool as robust as we could. So we're matching method symbols with properties, we also handle standard property conventions for Objective C, i.e. using
isprefix for boolean properties. For now, we don't handle custom getters/setters which do not comply with convention.
When creating iOS Class Guard one of our goals was to create a tool which will seamlessly integrate with your normal development workflow. We’ve tried to keep required code base changes at minimum level. To start working with our tool you’ll have to do 2 things: first, add an empty header to your project, where symbols will be kept and add it to your precompiled header. Second, modify the script, which we provide, with your project settings and run it before you release the app. The script will take care of generating new symbols.
For details how to install and integrate it with your project please check out iOS-Class-Guard GitHub page.
Future is bright!
For now we only support
Rename class and methods from a long list of obfuscation techniques. But our approach allows us to further enhance iOS-Class-Guard with other methods, i.e.:
strings obfuscation. We're releasing it now, because we think that even such a small utility may be interesting to developers and companies that want to make they application more secure. We are looking for contributors, there's long list of features that can be added.
One final thing to note: iOS Class Guard itself is not the silver bullet for security of your application. However, it will definitiely make your application harder to read by an attacker.
- Kamil TrzcińskiLead Software Engineer
- Błażej MarcinkiewiczLead Software Engineer
- Tomasz GrynfelderSenior Software Engineer