Comment by saurik | Hacker News Reader

Comment by saurik | Hacker News Reader

> I once even got sent a 40-character, hexadecimal string that wasn’t a valid UDID, and looked nothing like the actual one they eventually sent me. To this day, I still have no idea where they got it from.

A UDID is the result of a SHA-1 calculation: there is no such thing as a 40-character hexadecimal string which is "isn't a valid UDID" by syntax, so this is interesting to me: if the author ever sees this, did you get an error saying that from Apple (in which case we know they have a massive database of every device in existence)?

(Note that UDIDs beginning with 32-bits of F are returned by the APIs that provide app-specific advertising identifiers on the device, so if you saw one of those and decided it was "invalid", that was returned because they used a tool which tried to return a UDID but was using the older public APIs to do that from a sandboxed application.)

(edit: Oh, I just noticed there are comments on the website. I'm stupid, and will copy this there.)

> if the author ever sees this, did you get an error saying that from Apple (in which case we know they have a massive database of every device in existence)

Some sort of data is bundled up in that string: when you add a device's UDID to the Apple dev portal, the confirmation page will tell you what type of device it is (iPad 2, iPhone 7, etc).

I can't recall entering a bad UDID, so I'm unsure what that looks like.

I can tell you with 100% certainty that a UDID is the result of a SHA-1 and so there is no ability to have "data bundled up in that string"; I know this because we've reverse engineered the computation of this string, and there is now tons of software in the wild which just builds it from parts instead of using Apple's APIs. Here's information on the algorithm from our Wiki.

https://www.theiphonewiki.com/wiki/UDID

For Apple to be telling you what kind of device it is, they either have to have a database of all the devices as they are built or a database of devices which have been checking in to their servers. (I'm betting the latter is what is happening here, but the former would be fundamentally more interesting to me.)

Hello! Yes, as orbitur mentioned, Apple tells you the device type after you enter a UDID. The one that didn't work was accepted, but didn't return a device type. We tried it anyway, but the app wouldn't install, which is why I described it as 'invalid'.

> Note that UDIDs beginning with 32-bits of F are returned by the APIs that provide app-specific advertising identifiers on the device, so if you saw one of those and decided it was "invalid", that was returned because they used a tool which tried to return a UDID but was using the older public APIs to do that from a sandboxed application

It did have a bunch of Fs at the beginning, so that is probably the explanation! Thanks :)

Reply on news.ycombinator.com