[jwells89]

> The reason they’re not doing that is because it could have unintended consequences as some are using someone else’s actual device serial number and those people would be inconvenienced.

One is supposed to try to find a plausible (follows certain rules) but invalid serial to use for hackintoshing and not use real serials, but of course in practice there’s always some number of careless users…

[turquoisevar]

Yeah, that's what they're supposed to do, and to the credit of the Hackintosh community, that’s what most tutorials suggest.

But like you said, there are always people who don’t care about others as long as they have theirs.

There is, so far anyway, no reason to go against this best practice because, even though Apple can instantly detect a bogus serial, their currently used scoring threshold still allows you to use iMessage provided you’ve got a non-fresh Apple ID in good standing.

[rezonant]

This is interesting. How do you define "invalid" and why can Apple not also detect such invalidity?

There's been some talk that blocking this for Beeper will also block this for Hackintosh, but are we just talking about iMessage?

Because I have a hard time believing that (A) Apple can't just block this for iMessage without affecting whatever other system services rely on it and (B) That Apple would care if Hackintoshes lose iMessage.

If those two are true, and assuming Beeper Mini also tries to find plausible but invalid serials to use, then Hackintoshes definitely aren't the reason they aren't blocking based on this.

[jwells89]

My understanding is that the serials represent information, including model and date/location of manufacture. It’s therefore possible to create correctly formed but impossible serials, for example one that represents a pre-touchbar 2015 MBP manufactured in Ireland in 2018.

Apple should easily be able to tell when someone has done this.

[turquoisevar]

They indeed used to have data like that encoded in it.

Not too long ago, however, they moved to a completely randomized serial format, perhaps partly because of iMessages shenanigans.

[rezonant]

Hmm, how many bits of entropy are in one of these things? Can we calculate the likelihood of collision?

[nneonneo]

iMessage seems to use quite a lot of information from the hardware aside from the serial number. See https://github.com/JJTech0130/pypush/blob/main/emulated/data... for the data that is used to calculate the "validation blob" to activate iMessage. Several of the keys (not values!) are random-looking gibberish like "kbjfrfpoJU" and "oycqAZloTNDm", while others are normal things like "product-name" and "IOPlatformUUID".

[turquoisevar]

Those random looking keys are derived from the hardware and together with the values they serve as seeds for some of the keys.

Server-side there’s a bunch more information used from the Apple ID.

Together it results in a score and the server then decides if it meets the threshold before deciding to play nice.

[turquoisevar]

Apple can detect this, but they’ve allowed it in most cases when it’s done with an Apple ID in good standing and some history.

Why they allowed it is anyone’s guess, but the leading theory is that they valued not hindering established customers over locking iMessage completely down and perhaps the bad PR that comes with banning someone’s Apple ID over this.

[rezonant]

Well they could block the client itself, independent of blocking the Apple ID. It's the client that sends the serial information. Your Apple ID only gets associated with it indirectly.