Hacker News Reader

Comment by MuffinFlavored | Hacker News Reader

As far as I understand, in order to talk to Apple iMessage services/backend (and all auth pieces) you need a "legit" Apple ID and legit Apple hardware model #s / serial #s

If you don't have that, how are they able to get auth tokens / send messages around without basically "exploiting a hidden hack that might get patched"?

View on HN

The hackintosh community has tools to generate those #s. e.g. https://dortania.github.io/OpenCore-Post-Install/universal/i...

But why is it Apple's responsibility to accept a non-legit/unknown serial #?

> But why is it Apple's responsibility to accept a non-legit/unknown serial #?

I don’t think anyone is arguing that it’s Apple’s responsibility to accept fake serial numbers.

The serial number is an implementation detail and not the core issue, which is Apple’s intentional degradation of the non-iMessage experience, and their stance against interoperability.

If this was all about security, they could accept something other than an Apple serial #, and provide a UX that makes it clear the user is interacting with a non-Apple user. This would address most spam/abuse issues.

But we know that this is about lock-in and not security.

> I don’t think anyone is arguing that it’s Apple’s responsibility to accept fake serial numbers.

Can we confirm if that's what is happening here or not? How else is Beeper Mini able to work given Apple's requirement "iMessage auth + read/write requires valid_serial_number"?

The “How Beeper Mini Works” post from a few days ago doesn’t mention the serial number, so I don’t know.

But whether this is happening or not is immaterial to the broader philosophical issues being raised.

For sake of argument, let’s say they’re faking a serial number to make the app work. How does that change the impact of Apple’s anti-interoperability stance?

Again, if the real issue is security, nothing stops Apple from providing a secure alternative. And again, this takes us back to: this isn’t about security.

It’s not, and they don’t. This is a cat and mouse game. Apple is free to block these and people are free to keep trying to get around it. Everyone should be acting in good faith

> It’s not, and they don’t.

> they don't

They (Apple) don't accept requests without a valid serial #, but Beeper Mini is working (for users without iDevices), so there's some kind of exploit, no?

AFAIK they are using a reverse-engineered Apple binary that does the real iMessage - and since Apple doesn't update apps outside of iOS updates, Apple can't, in theory, patch it without also breaking iMessage on older iPhones.

I'd have assumed there'd be something more going on in iMessage, like each device has a private key that needs to sign the messages, and Apple can ban any private keys that leak -- but in theory couldn't they even be prevented from leaking by secure enclave?

I'm just speculating on what would have made sense, but I'm guessing that's not how it's working since Beeper Mini exists. It begs the question: why isn't that the way they do it?

You're asking why cryptographic attestation isn't a requirement to use a service that still supports >10-year old x86 Macs?

Yeah? Asymmetric cryptography has been around a lot longer than a decade.

That's the foundation of attestation, not attestation itself. Macs did not ship with a TPM, and had no facilities for hardware chain-of-trust until the T2 chip in 2017.

But you don't have to have everything in place to do the basics. Use private keys stored normally on the device. If they get stolen or leaked, brick iMessage on those devices and show a message saying, "Your system has been compromised and can't use iMessage until you visit an Apple Store or call 1-800-..." Then just hand out a new private key at the store or over the phone with little friction, but track which customers are given new keys and how often. If there's a trend of someone receiving a bunch of new keys, investigate them before issuing more.

Or just allow a user to obtain a new private key via their iCloud account and associate the key with that account so that it can't be used to send messages unless you're signed into that account.

Newer devices that can protect their keys don't need that, and you phase the old process out over time.

Oh, so what you're saying is equivalent to "Apple should have cryptographically signed serial numbers/UUIDs, instead of accepting user-generated values"

But they already have a record of which serial numbers were actually sold (at least since some point), signing a device token/private key would be redundant and allowing user-generated serials to sign in with degraded trust is a policy choice.

Got it. Well that makes sense for older devices.

Messages has existed longer than the Secure Enclave has.

Secure Enclave doesn't have to exist for the rest of the system to work as I described. (And once Secure Enclave does exist, it can be used to further secure the private keys generated after that date.)

Without Secure Enclave, remote parties (the servers) can't know where the key material came from. I'm assuming because old devices pre-SEP have to be supported, Beeper is exploiting this since there's no required residency or provenance attestation for the keys.

The Intel Management Engine has existed since 2008. Did Apple laptops/desktops avoid this for significantly longer than that?

I wonder why Apple lawyers don't go after Beeper with the CFAA?

Maybe they will… but, also, I bet they can change their systems faster than the court system.

It would be a mis-use of the act.

> CFAA

Computer Fraud and Abuse Act (CFAA)

That's not quite correct. You need a binary blob that's generated by some kernel level stuff I don't fully understand.

Maybe they generate legit-looking fake device serial numbers, that just happen to match real devices most of the time?

How does Apple not know a database of real serial #s that match products it has sold? Why would an API that goes to the lengths of expecting a serial # not validate and instead accept a fake "real-looking" serial # instead of a known- matched-in-the-database real serial #?

Well, Apple does not actually know which serial numbers have been sold. You can still buy Apple products outside of an Apple store, and even at an Apple Store, knowing which serials are sold is logistically difficult.

They could probably implement a process at Apple stores but to do it for third party stores would be more difficult. To avoid simply adding a step for a user to claim a serial number as sold when they set up their Hackintosh or HackiPhone (can we coin this?), you'd probably need a way to authenticate as the store when you mark one off. But there's nothing stopping stores who have excess inventory from selling it off at cost or even a discount when a particular product isn't doing well- and at that point those purchasers will need to be able to mark off serial numbers when they sell those devices.

It's not impossible but it's not terribly likely, at least any time soon.

> Well, Apple does not actually know which serial numbers have been sold.

What about "serial numbers manufactured?"

I'm going to guess "Beeper Mini stealing manufactured-but-not-yet-sold serial #s for themselves" will be shut down super quickly. If you are a user who finally gets a device with a serial # "stolen" by Beeper Mini... that seems like bad luck/bad user experience?

That kind of collision is very unlikely to happen.

It is comparable to someone stealing your Windows license key by guessing randomly.

More on collision: https://stackoverflow.com/a/23253149/

Are Apple device serial numbers hashes, though? Suppose you look through a factory-packed box of iPhones, the kind that Apple resellers get delivered, would their serial numbers not be sequential or at least numerically close to one another?

Reply on news.ycombinator.com