Why doesn’t Objective-C have namespaces? It seems like a simple feature that would make some class names more readable (AVMutableVideoCompositionLayerInstruction anyone?) and axe the silly letter prefixes on class names. Is this mainly because of backwards compatibility? Is it harder to implement namespaces than it seems?
I don't know the answer but I suspect "it's harder than it looks" is probably it. You would have to introduce support in the compiler and linker in a way that doesn't break existing software. And while this is obviously possible (C++ has already done it) presumably the tool chain team have had higher priorities on their plate. e.g. in the recent past we have had garbage collection, GCD, blocks and Objective-C 2.0 appear so we can't say they have been doing nothing.
Namespace support is the one thing that I would dearly love to see introduced to Objective-C.
I don't know if you want to know if there is some official decision.
But namespace like many other feature are choice, choice made by the language contributor.
PHP only recently introduced Namespace, and for example Java use package that act like namespace or python use modules.
I think that there is an overhead in namespace implementation, mainly because Objective-c is dinamically typed so at runtime you have to make some check to resolve the namespace, to resolve default behaviour,etc.. and I can suppose that because Objective-c is also used in embedded enviroment (AKA iPhone) speed is very important.
You've to wrap everything I've said in a big IMHO ;D
Update:
I found this very interesting discussion http://clang-developers.42468.n3.nabble.com/Adding-namespaces-to-Objective-C-td1870848.html#a1872744 on the clang developer website explaining the reason why is definitely non-trivial to implement namespace in Obj-C.
Related
I'm new to disassembling and reverse engineering binaries, so forgive me if this question is nonsensical or impossible.
In the past when I've tried reverse engineering macOS binaries, analyzing the ones written in Objective-C yielded a lot of useful information, because generally all of the Objective-C classes and their method names were easily retrievable, making it a lot easier to figure out what any particular method did.
I'm trying to analyze a binary written in Swift (technically a combination of Swift and Objective-C), and most of the functions now have no symbol. There are some Objective-C methods that I can retrieve as usual, and a few functions that have a Swift-style mangled name, but nearly all of the rest have no symbol. I know a lot of those have to be Swift methods.
Is there anyway to figure out what this binary's Swift classes are and their associated methods like I can with Objective-C?
Using a tool like Hopper Disassembler reveals the mangled names of some Swift classes (usually a symbol like _TtC4Something25SomethingElse) and I can get a list of its instance variable names and their offsets, but no method names.
Note: the binary in question is an x64 macOS binary, not an iOS binary.
Usually reverse engineeing is the process of extracting meaningful constructs and descriptions from assembly. What you've done so far is usually only the first part of a "normal" reverse engineeing task.
This may sometimes be a tedious process, which involves mapping structures and understanding the meaning of functions directly from thier assembly code.
There are pleanty of reverse engineeing tutorials and other sources, and a good understanding of the relevant assembly language is required.
I really recommand this book (it's legally available online, original version is chm released by author) and this cannot easily be covered in a single SO question.
You might also want to get more specific help in the reverse engineeing SE beta.
I hope I pointed you in the right direction.
There are lots of oop languages, but I couldn't find any that has conveniences like garbage collection, but compiles natively to machine code. Sort of like between C and java/c#. One interesting language I found was Vala, but that's limited to the GNOME platform and is not that well-known
Go is probably closest.
But why on earth do you want it natively compiled anyway?
JIT compilation of portable bytecode has proved to be an extremely effective strategy. It compiles down to native code at runtime (so you get up to the performance of native code after the first few iterations) and it avoids the issues of having to build and manage platform-specific compiled binaries.
Are you thinking about C++? That is in high usage and can be compiled on nearly any (major) platform.
In the case you want to use an oo language that compiles down to native code you will "always" have to use header files and stuff as the elf format doesn't support oo (There is no class information in elf).In case you want to use classes from external libs you need to make the compiler aware somehow about the fact that there are classes, functions, etc. that are declared outside of your project. In C++ this is solved by the use of header files. So that's, I think, a major drawback in native object oriented languages. To resolve that issue a few tweaks would need to be made to elf/loader/linker in order to support the kind of features (like "linking" against "classes") you might expect. Even though mechanism for garbage collection could be implemented even in native languages. But that seems no good for os implementation.
There are C++ libs to do that for userspace apps like:
Boehm collector
Smart pointers
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 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.
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...