Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>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:</p> <pre><code>+-----------+ | your code | +-----------+ | +----------+ +-------------+ +-----------+ | UIDevice |&lt;-----&gt;| liblockdown |&lt;=====&gt;| lockdownd | (trusted data) +----------+ +-------------+ +-----------+ untrusted user trusted user </code></pre> <p>When the device is jailbroken, all 4 components can be replaced.</p> <hr> <p>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.</p> <p>For example, UDID Faker relies on a plist file <code>/var/mobile/Library/Preferences/com.Reilly.UDIDFaker.plist</code>. Therefore, you could check if this file exists:</p> <pre><code>NSString* fakerPrefPath = @"/var/mobile/Library/Preferences/com.Reilly.UDIDFaker.plist"; if ([[NSFileManager defaultManager] fileExistsAtPath:fakerPrefPath])) { // UDID faker exists, tell user the uninstall etc. } </code></pre> <p>it also defines the method <code>-[UIDevice orig_uniqueIdentifier]</code> which could be used to bypass the faker:</p> <pre><code>UIDevice* device = [UIDevice currentDevice]; if ([device respondsToSelector:@selector(orig_uniqueIdentifier)]) return [device orig_uniqueIdentifier]; else return device.uniqueIdentifier; </code></pre> <p>Of course the spoofer could simply rename these things.</p> <hr> <p>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 <strong>different</strong> from UIKit. Therefore, you just need to check if the function pointer of the <code>-uniqueIdentifier</code> method is within the acceptable range.</p> <pre><code>// get range of code defined in UIKit uint32_t count = _dyld_image_count(); void* uikit_loc = 0; for (uint32_t i = 0; i &lt; 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 &lt; uikit_loc) { // tainted function } </code></pre> <hr> <p>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.</p> <pre><code>+-----------+ | your code | +-----------+ | +----------+ +-------------+ +-----------+ | UIDevice |&lt;--. | liblockdown |&lt;=====&gt;| lockdownd | (trusted data) +----------+ | +-------------+ +-----------+ | +------------+ ‘--&gt;| UDID Faker | +------------+ </code></pre> <p>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. </p> <pre><code> +-----------+ | your code | +-----------+ | +----------+ +-------------+ +-----------+ | UIDevice |&lt;--. | liblockdown |&lt;=====&gt;| lockdownd | (trusted data) +----------+ | +-------------+ +-----------+ | +------------+ ‘--&gt;| UDID Faker | +------------+ </code></pre> <p>(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.)</p>
    singulars
    1. This table or related slice is empty.
    1. PODetect UDID spoofing on the iPhone at runtime
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USkennytm
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PODetect UDID spoofing on the iPhone at runtime
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COWow, thanks for your elaborated answer, KennyTM! Perfect!
      singulars
      1. PO
      1. USkenn
    2. COThank you very much for your detailed answer! I'm partly using your code but I get some warnings, maybe you can help me!? I've included `mach-o/dyld.h`. The line `uikit_loc = _dyld_get_image_header(i);`raises the warning _Semantic Issue: Assigning to 'void *' from 'const struct mach_header *' discards qualifiers_ and `if (funcptr < uikit_loc)`: _Semantic Issue: Comparison of distinct pointer types ('IMP' (aka 'id (*)(id, SEL, ...)') and 'void *')_ How can I remove those warnings? Thank you :)
      singulars
      1. PO
      1. USStefan
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload