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.
Related
Of course, I don't actually need it to highlight anything, I'll take care of that, however, it would be great if there would be a library that can parse text and can in an abstract manner tell me which words should I highlight and how should I treat them (as functions, vars, etc). I think (not sure) Clang would be an option, but seems really heavy duty for my purposes.
Yes libclang is the way to go.
Watch this video (captured at 2010 LLVM Developers' Meeting) for more info, which presents the libclang API and should give you a really good overview of how to use the API.
You may probably be interested in the others videos here too.
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.
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.
see also VB.NET Static Code Anaylsis
For better or for worst we now have a VB.NET coding standards document that is based on a C# coding standard as enforced by StyleCop.
For example
the number of spaces you should put in each side of a “+” sign etc
all instance Members (fields and methods!) must be access as “me.fieldName”
all shared members must be accessed as “className.fieldName”
As I tend to think:
If it’s in a requirements document it
should be check for by an automatic
system
I am looking for (ideally free) tools that will check for that short of rules on VB.NET code, as these are style issues that don’t make it into the compiled output, FxCop is not useful.
(I would personally match rather that we just check for important things like duplicated code and single reasonability for each class (so no more multi thousand line classes!), but as I need to keep to the coding standard document I wish to have a tool to help me do so.)
see also Enforcing using the class name whenever a shared member is accessed.
About the bounty.
I am looking for a list of VB.NET code checking tools, with a short summery of what each tool can do and its limitations. If the tools are not free, please include some ideal of cost.
Does anyone have experience using CodeRush/Refactor! or ReSharper with VB.NET to check for this type of coding style issues?
I know of no free source code analysis tools with good VB support. There are, however, at least two commercial tools that may be suitable:
submain CodeIt.Right
SSW Code Auditor
Personally, I prefer the CodeIt.Right rule authoring mechanism, so I would favour it if considerable custom rule development were planned. However, if you just want to use out-of-the box rules, Code Auditor ships with quite a few more code style rules than CodeIt.Right, most of whose built-in rules target the compiled IL (like FxCop).
The only ones I know of are:
Microsoft's FxCop
Of course, this only operates on compiled assemblies, so doesn't give the same functionality as StyleCop, and certainly won't help with things like naming schemes.
However, the closest thing is:
Aivosto's Project Analyzer v9.0 for Visual Basic, VB.NET and VBA
The full version is not free, but this is the closest thing to StyleCop for VB.NET that I can find.
There have been a number of calls for a VB.NET version of Microsoft's StyleCop, such as those in this thread on the code.msdn.microsoft.com site. That same thread also gives some good insight into why a VB.NET version doesn't exist.
I use ReSharper on a daily basis and I find it fine for both code formatting and for solving naming issues. It allows to configure how naming must be enforced, how issues are displayed (hint, suggestion, warning, etc) and provides a precise code formatter (space, paranthesis, line breaks, this qualifier, etc).
Note that I don't know if it can be run in batch mode.
Turning Option Explicit on by default is always a great idea and should be standard practice. I would argue it should be turned on by default in VS out of the box. But it doesn't come close to enforcing the out of the box rules that StyleCop does for C#, nor does it allow for you to create your own rules.
The whole reason for StyleCop's existence is because FxCop only works on compiled assemblies, leaving web projects out in the cold for a similar tool. With StyleCop, web developers get the same great rule enforcement and tight VS integration. It is a great tool for any C# developer.
It is unfortunate that it is only C# capable, a VB version would satisfy a large community that is left wanting something similar.
There already is a very good style tool built into the VB compiler. It is called Option Explicit On, put it at the top of the source code file or use Tools + Options + Project and Solutions + VB Defaults, Option Explicit = On. If that wasn't turned on previously there could be a mountain of errors when you compile your code after changing that.
If it is clean or already turned on, consider that you are 95% close to writing clean C# code and that the language doesn't really matter anymore.
What are the programming features that are missing in C++ and Java ?
For eg. You can't do recursive programming in QBasic ? You can't dynamically allocate memory in QBasic.
What would be the good to have features in C++, Java.
I think Lisp Programmers will be able to add a few.
I miss lambda expressions.
This answer deals only with C++
Things I miss from the syntax, or the standard library:
RegExp as part of the standard library
Threads as part of the standard library
Pointer to member methods (not objects!)
Properties would be nice (I have seen codes that emulate this via C++ preprocessor... note an nice looking code).
Some lower level networking API (sockets!), and higher level API (give me this file from this ftp, submit "this" to this site via POST).
This is the list of things I would like to see, but I assume other people will disagree with me.
Memory garbage collector is nice.
A n interface for a GUI toolkit - let MSVC map it to win32, and on Linux... (good question!)
A stable ABI. In C it's a standard - but on C++ we are still missing a few decades. I want also stable ABI between compilers - I want to compile one library in MinGW, the other with CL and all should work.
This is the list of things I want to see, but I know they will not get away:
Compatibility with C. Really, it's a myth right now. using namespace std killed it.
Include, headers. Most of the information is already available in the DLL/so/a/"library", do we really need to keep this bad decision from 30 years ago? If needed the compilers should keep information in the binaries.
The need for Makefiles - the compiler should be smart enough to know what to do with this code, from the code itself. Pascal is doing it quite good. I think also D.
(I might be wrong, please correct me) The official standard openly and freely available for viewing. Why should I pay for the official papers? Do I need to do it for HTTP? UTF8? Unicode?
I think this is a very subjective question. From a theoretical point of view there's nothing "missing" in Java because you can do everything you want to from the perspective of the outcome as an application.
As with QBasic - recursion may not be possible but that doesn't prevent you from changing your recursive algorithm to an iterative algorithm. Programming language theory tells us that you can do this with every recursive problem. So there's also nothing missing here.
I think what you mean are features that are "nice to have" - and here everyone has to decide for himself. I'd even say there are features in the language which would have been "nice not to have" such as static imports - but again this is my subjective opinion...