[danaris]

Based on my understanding, Beeper is using false or duplicate Apple device credentials in order to authenticate with Apple as "being a legitimate iMessage endpoint".

There's no need to take the—rather draconian—step of locking out all Apple users who are using Apple IDs through the browser; all Apple needs to do is ban the false device IDs and possibly close the loophole that allows Beeper to create them.

Any time you see something that looks like a jailbreak, at its heart is a vulnerability in the device or service that is being jailbroken. That is, fundamentally, a security flaw, and fixing that security flaw is all that's necessary to prevent the jailbreak. The fact that this one is with one of Apple's services, rather than with iPhones or other Apple devices, means that they don't even have to push out some software/firmware update and hope everyone applies it: all they have to do is update their own servers, and Beeper will be locked out again.

[milkytron]

I don't think they're using false or duplicate Apple devices for this. I think that it may be likely they are using AWS resources for it: https://aws.amazon.com/ec2/instance-types/mac/

When AWS first came out with these, this was my first thought. People could spin up an EC2 instance and use it for iMessage, and Beeper came to be shortly after this feature went live in AWS.

[danaris]

Not fake devices, fake credentials. Beeper Mini is explicitly using a different method to access the iMessage system than Beeper and some other previous services; it's not spinning up virtual Macs and bouncing off them. Because of that, it also doesn't require you to hand your Apple ID login & password over to Beeper in cleartext just to make it work.

At least, from what I've read over the past few days.

[venusenvy47]

I don't think the credentials are faked. The author's blog post seems to give the details. He is publishing a public key to Apple's servers and figured out how to read the public key of other users. It seems like he is using the normal Apple encryption path from there. Although I don't fully understand the details.

https://jjtech.dev/reverse-engineering/imessage-explained/