Let’s invent a hypothetical situation. You’re the software architect for an Objective-C application framework at a large company. This framework is used by many thousands of developers to create all sorts of applications for a particular platform.
However, you have a problem. Developer Technical Support are reporting that some third-party developers are using a tool called class-dump to discover the undocumented methods on your framework’s classes, and are calling them directly in application code. This is leading to stability and potentially other issues, as the methods are not suitable for calling at arbitrary points in the objects’ life cycles.
You immediately reject the distasteful solution of making the private method issue a policy problem. While you could analyse third-party binaries looking for use of undocumented method selectors, this approach is unscalable and error-prone. Instead you need a technical solution.
The problem in more detail
Consider the following class:
@interface GLStaticMethod : NSObject {
@private
int a;
}
@property (nonatomic, assign) int a;
- (void)doTheLogThing;
@end
@interface GLStaticMethod ()
- (void)logThis;
@end
@implementation GLStaticMethod
@synthesize a;
- (void)doTheLogThing {
[self logThis];
}
- (void)logThis {
NSLog(@"Inside logThis: %d", self->a);
}
@end
Clearly this -logThis method would be entirely dangerous if called at unexpected times. Oh OK, it isn’t, but let’s pretend. Well, we haven’t documented it in the header, so no developer will find it, right? Enter class-dump:
/*
* Generated by class-dump 3.3.2 (64 bit).
*
* class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2010 by Steve Nygard.
*/
#pragma mark -
/*
* File: staticmethod
* Arch: Intel x86-64 (x86_64)
*
* Objective-C Garbage Collection: Unsupported
*/
@interface GLStaticMethod : NSObject
{
int a;
}
@property(nonatomic) int a; // @synthesize a;
- (void)logThis;
- (void)doTheLogThing;
@end
OK, that’s not so good. Developers can find our private method, and that means they’ll use the gosh-darned thing! What can we do?
Solution 1: avoid static discovery
We’ll use the dynamic method resolution feature of the new Objective-C runtime to only bind this method when it’s used. We’ll put our secret behaviour into a function that has the same signature as an IMP (Objective-C method implementation), and attach that to the class when the private method is first used. So our class .m file now looks like this:
@interface GLStaticMethod ()
void logThis(id self, SEL _cmd);
@end
@implementation GLStaticMethod
@synthesize a;
+ (BOOL)resolveInstanceMethod: (SEL)aSelector {
if (aSelector == @selector(logThis)) {
class_addMethod(self, aSelector, (IMP)logThis, "v@:");
return YES;
}
return [super resolveInstanceMethod: aSelector];
}
- (void)doTheLogThing {
[self logThis];
}
void logThis(id self, SEL _cmd) {
NSLog(@"Inside logThis: %d", ((GLStaticMethod *)self)->a);
}
@end
What does that get us? Let’s have another look at class-dump’s output now:
/*
* Generated by class-dump 3.3.2 (64 bit).
*
* class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2010 by Steve Nygard.
*/
#pragma mark -
/*
* File: staticmethod
* Arch: Intel x86-64 (x86_64)
*
* Objective-C Garbage Collection: Unsupported
*/
@interface GLStaticMethod : NSObject
{
int a;
}
+ (BOOL)resolveInstanceMethod:(SEL)arg1;
@property(nonatomic) int a; // @synthesize a;
- (void)doTheLogThing;
@end
OK, so our secret method can’t be found using class-dump any more. There’s a hint that something special is going on because the class provides +resolveInstanceMethod:, and a really dedicated hacker could use otool to disassemble that method and find out what selectors it uses. In fact, they can guess just by looking at the binary:
heimdall:Debug leeg$ strings staticmethod NSAutoreleasePool alloc init setA: doTheLogThing release drain logThis resolveInstanceMethod: v8@0:4 c12@0:4:8 i8@0:4 v12@0:4i8 NSObject GLStaticMethod Ti,N,Va Inside logThis: %d
You could mix things up a little more by constructing strings at runtime and using NSSelectorFromString() to generate the selectors to test.
Problem extension: runtime hiding
The developers using your framework have discovered that you’re hiding methods from them and found a way to inspect these methods. By injecting an F-Script interpreter into their application, they can see the runtime state of every object including your carefully-hidden instance methods. They know that they can call the methods, and can even declare them in categories to avoid compiler warnings. Where do we go from here?
Solution 2: don’t even add the method
We’ve seen that we can create functions that behave like instance methods – they can get access to the instance variables just as methods can. The only requirement is that they must be defined within the class’s @implementation. So why not just call the functions? That’s the solution proposed in ProCocoaAppSec – it’s a little uglier than dynamically resolving the method, but means that the method never appears in the ObjC runtime and can never be used by external code. It makes our public method look like this:
- (void)doTheLogThing {
logThis(self, _cmd);
}
Of course, logThis() no longer has an Objective-C selector of its very own – it can only get the selector of the method from which it was called (or whatever other selector you happen to pass in). Most Objective-C code doesn’t ever use the _cmd variable so this isn’t a real drawback. Of course, if you do need to be clever with selectors, you can’t use this solution.
Conclusion
Objective-C doesn’t provide language-level support for private methods, but there are technological solutions for framework developers to hide internal code from their clients. Using these methods will be more reliable and easier to support than asking developers nicely not to use those methods, and getting angry when they do.
