Skip to main content

Detect UDID spoofing on the iPhone at runtime



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?


Comments

  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.)

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex