3 ms·

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

by orbitur 10y ago

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

saurik 10y ago
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 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.)
- harisriskantha 10y ago
  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 :)

by orbitur 10y ago

saurik 10y ago

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

harisriskantha 10y ago
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 :)