Question

Jailbroken iPhones get on my nerve as it taints some fundamental APIs on iOS, by using MobileSubstrate.

http://www.iphonedevwiki.net/index.php/MobileSubstrate

I believe many apps use UDID as a mean to authenticate a device and/or a user since it’s semi-automatic and handy, but you should be aware of this problem: UIDevice is not as tamper-proof as it should be. There’s an app called UDID Faker, which easily enables you to spoof someone else’s UDID at runtime.

http://www.iphone-network.net/how-to-fake-udid-on-ios-4/

Here’s the source code of it:

//
//  UDIDFaker.m
//  UDIDFaker
//

#include "substrate.h"

#define ALog(...) NSLog(@"*** udidfaker: %@", [NSString stringWithFormat:__VA_ARGS__]);
#define kConfigPath @"/var/mobile/Library/Preferences/com.Reilly.UDIDFaker.plist"

@protocol Hook
- (NSString *)orig_uniqueIdentifier;
@end

NSString *fakeUDID = nil;

static NSString *$UIDevice$uniqueIdentifier(UIDevice<Hook> *self, SEL sel) {  

    if(fakeUDID != nil) {
                 ALog(@"fakeUDID %@", fakeUDID);
        /* if it's a set value, make sure it's sane, and return it; else return the default one */
                return ([fakeUDID length] == 40) ? fakeUDID : [self orig_uniqueIdentifier];

    }
    /* ... if it doesn't then return the original UDID */
    else {
        return [self orig_uniqueIdentifier];
    }
}

__attribute__((constructor)) static void udidfakerInitialize() {  

    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
        NSString *appsBundleIdentifier = [[NSBundle mainBundle] bundleIdentifier];
        ALog(@"Loading UDID Faker into %@", appsBundleIdentifier);


        NSDictionary *config = [NSDictionary dictionaryWithContentsOfFile: kConfigPath];
        fakeUDID = [config objectForKey: appsBundleIdentifier];
        [fakeUDID retain];

        if(fakeUDID != nil) {

                ALog(@"Hooking UDID Faker into %@", appsBundleIdentifier);
                MSHookMessage(objc_getClass("UIDevice"), @selector(uniqueIdentifier), (IMP)&$UIDevice$uniqueIdentifier, "orig_");
        }

    [pool release];
}

As you can see, uniqueIdentifier method in the UIDevice class now returns fakeUDID on any apps.

It seems that Skype and some other apps detect this sort of taint, but I don’t know how to do it.

What I wanted to do is: When tainted UIDevice is detected upon launch, alert and exit(0).

Ideas?

Answer 1

There isn’t a truly safe way to check if the UDID is real. The UDID is got via liblockdown, which communicates to lockdownd via a secure channel to receive the UDID:

+-----------+
| your code |
+-----------+
      |
+----------+       +-------------+       +-----------+
| UIDevice |<----->| liblockdown |<=====>| lockdownd |   (trusted data)
+----------+       +-------------+       +-----------+
         untrusted user                   trusted user

When the device is jailbroken, all 4 components can be replaced.

---

One method to detect the presence of UDID Faker is to check if some identifications (files, functions etc.) unique to it exists. This is a very specific and fragile counter-attack, as when the method of detection is exposed, the spoofer could simply change the identification to conceal their existence.

For example, UDID Faker relies on a plist file /var/mobile/Library/Preferences/com.Reilly.UDIDFaker.plist. Therefore, you could check if this file exists:

NSString* fakerPrefPath = @"/var/mobile/Library/Preferences/com.Reilly.UDIDFaker.plist";
if ([[NSFileManager defaultManager] fileExistsAtPath:fakerPrefPath])) {
   // UDID faker exists, tell user the uninstall etc.
}

it also defines the method -[UIDevice orig_uniqueIdentifier] which could be used to bypass the faker:

UIDevice* device = [UIDevice currentDevice];
if ([device respondsToSelector:@selector(orig_uniqueIdentifier)])
   return [device orig_uniqueIdentifier];
else
   return device.uniqueIdentifier;

Of course the spoofer could simply rename these things.

---

A more reliable method lies in how Mobile Substrate works. Injected code must be located in a dylib/bundle, which is loaded into a memory region different from UIKit. Therefore, you just need to check if the function pointer of the -uniqueIdentifier method is within the acceptable range.

// get range of code defined in UIKit 
uint32_t count = _dyld_image_count();
void* uikit_loc = 0;
for (uint32_t i = 0; i < count; ++ i) {
   if (!strcmp(_dyld_get_image_name(i), "/System/Library/Frameworks/UIKit.framework/UIKit")) {
     uikit_loc = _dyld_get_image_header(i);
     break;
   }
}

....

IMP funcptr = [UIDevice instanceMethodForSelector:@selector(uniqueIdentifier)];
if (funcptr < uikit_loc) {
   // tainted function
}

---

Anyway UDID Faker is a very high level hack (i.e. it can be easily avoided). It hijacks the link between UIDevice and liblockdown by supplying a fake ID.

+-----------+
| your code |
+-----------+
      |
+----------+       +-------------+       +-----------+
| UIDevice |<--.   | liblockdown |<=====>| lockdownd |   (trusted data)
+----------+   |   +-------------+       +-----------+
               |   +------------+
               ‘-->| UDID Faker |
                   +------------+

Thus you could move the code asking the UDID lower to the liblockdown level. This can be used for apps for Jailbroken platforms, but this is not possible for AppStore apps because liblockdown is a private API. Besides, the spoofer could hijack liblockdown (it’s very easy, I hope no one does it), or even replace lockdownd itself.

                   +-----------+
                   | your code |
                   +-----------+
                         |
+----------+       +-------------+       +-----------+
| UIDevice |<--.   | liblockdown |<=====>| lockdownd |   (trusted data)
+----------+   |   +-------------+       +-----------+
               |   +------------+
               ‘-->| UDID Faker |
                   +------------+

(I’m not going to show how to use liblockdown here. You should be able to find sufficient information from the site you’ve linked to.)