I’m not sure how this will go for Beeper, but I do think the fact that this iMessage implementation exists and that it works means that Apple will finally be forced to (a) take RCS seriously, which was already starting to happen; and (b) consider making the iMessage app x-platform (with functional Android and browser implementations, even if it requires an Apple ID to use). If they don’t do this, given that a high school student reversed their protocol and a startup launched a working x-platform commercial implementation (probably on a shoestring budget), it will be very hard for the governments of the world to believe iMessage’s insistence on being Apple-hardware-only is anything but an anti-competitive move.
Yes, in response to regulatory pressure, especially in the EU, they capitulated and announced RCS support would be coming to iMessage eventually. That is good. But there is always a background concern that they will seek to satisfy the letter of regulation but not the spirit.
For example: how much of the RCS standard to implement, whether to drag feet on roll out, whether to track the standard as it changes, and whether to diverge iMessage farther from RCS are still open questions inside Apple.
I think the ethical move would be for Apple to fully support RCS in iMessage, and also to make an x-platform opt-in iMessage app available across platforms, even if that x-platform app is tied to an Apple ID. Heck, there’d even be a benefit for those Apple users who aren’t all-in on using Apple on every single device. I think this release of Beeper / pypush / etc. will create some natural pressure for this outcome, which would make the iMessage network more akin to Telegram, Signal, LINE, etc. just with built-in support on Apple hardware.
Ironically, iMessage is (just barely) not popular enough in the EU for their monopoly regulation to kick in. But, iMessage is popular enough in the US for the same regulation to apply, but… the US doesn’t have the same regulatory framework. So, I’d say, this reversing work is even more important now.
When making an IDS registration request, a binary blob called “validation data” is required. This is essentially Apple’s verification mechanism to make sure that non-Apple devices cannot use iMessage.
Note: The binary that generates this “validation data” is highly obfuscated. pypush sidesteps this issue by using a custom mach-o loader and the Unicorn Engine to emulate an obfuscated binary. pypush also bundles device properties such as the serial number in a file called data.plist, which it feeds to the emulated binary.
So it sounds like:
This will be fairly easily banned by blocking serial numbers that are used too frequently.
This relies on tricking Apple to believe that the session is “authentic” as in rooted in Apple hardware.
I wonder how Beeper intends to build a reliable product on this. Are they just going to throw a fit an apologize if Apple shuts it down?
There is no company here, but they might find themselves acquired. I do not like Apple’s rent extraction games, but I’m not sure if I like the carriers more. It’s just a bad situation all the way around.
What do you mean specifically in the case of Apple and iMessages/Messages.app? Is your claim is that their choice to keep iMessage only on Apple hardware does not add value to the consumer? That argument would need justified, as it isn’t self-evident. Also, a strong argument would need to discuss the costs and benefits {(a) to Apple and (b) to customers} of supporting iMessages on other hardware, would it not? What is the calculus?
This project has been purchased by Beeper, please contact them with any questions about licensing.
I’m only just now seeing Beeper on another site, so the first questions I have are: is Beeper based on this? Or, did Beeper independently RE iMessage and then buy this competitor project…?
This is all pretty neat but I can’t see it lasting all that long. The Verge article linked in an earlier comment contains:
Migicovsky believes he’s on the right side of the law (he points to a copyright carveout for reverse engineering and says there’s no Apple code in Beeper Mini);
But then the linked repo says:
pypush currently uses the Unicorn CPU emulator and a custom MachO loader to load a framework from an old version of macOS, in order to call some obfuscated functions.
The macOS binary is used for registering with Apple’s servers from a Mac. In Beeper’s blog post, they talk about a completely separate mechanism for registering involving SMS . I’m guessing the reason they don’t need the blob is by using this second registration method that can only work on a phone.
As a European, I see little use for iMessage because everybody is using Signal or WhatsApp already. In US the blue bubble has been important culturally.
There’s that social “blue bubble” thing that @pimeys mentioned.
But the real upside is that if your iMessage-using contacts’ devices see that you’re an iMessage user, their messages to you will be encrypted end-to-end. They will also have an easier time creating group messages that include you, because iMessage has some interface deficiencies creating SMS group threads.
This glosses over the biggest advantage of iMessage vs. SMS: iMessage removes the carrier from the equation entirely, and doesn’t require the user to have a phone. iMessage users can communicate with other iMessage users over the IP network, rather than over the carrier network, which means I can text my friends from my MacBook, my iPad, or my iPhone, without needing to have a SIM for any of them. SMS messages (green bubbles) breaks this feature, requiring me to have my SIM-enabled phone within some small distance of my Macbook for message-forwarding to work. This, in a word, sucks. It means I can’t text on a plane, for instance.
iMessage exclusivity is anti-competitive and bad, but as a technology, iMessage is far, far, far superior to SMS and RCS. Blue bubbles isn’t a social stigma because people like the color blue, it is because texting with a green bubble is a significantly worse user experience than texting with blue bubbles.
Blue bubbles isn’t a social stigma because people like the color blue, it is because texting with a green bubble is a significantly worse user experience than texting with blue bubbles.
This is true, but not exclusively so. At least here in the US, green bubbles also carry social stigma around (perceived) wealth. Google claims that iMessage dominates because of bullying. I don’t think it’s fair to claim that the blue/green bubble dynamic is solely due to iMessage being a superior experience (which to be clear, it is).
iMessage removes the carrier from the equation entirely, and doesn’t require the user to have a phone.
That first part is certainly one reason that I like end-to-end encryption. I didn’t mean to omit the second part. It just wasn’t front of mind for me because it still requires an Apple device right now. And while I do use a macbook much of the time, I still spend enough time on a Linux laptop and desktop (which don’t get to participate in this device- and carrier-independence) that I wasn’t thinking about that side of it.
For people who do use devices that can participate in that, I’m sure that makes texting with blue bubbles better than texting with green bubbles.
For others, it is more related to the group chat UX, the tapback annoyances, and a few other papercuts. And I’d like my chats to be encrypted because carriers are happy to mine them for creepy purposes, given the opportunity.
I’m not sure how this will go for Beeper, but I do think the fact that this iMessage implementation exists and that it works means that Apple will finally be forced to (a) take RCS seriously, which was already starting to happen; and (b) consider making the iMessage app x-platform (with functional Android and browser implementations, even if it requires an Apple ID to use). If they don’t do this, given that a high school student reversed their protocol and a startup launched a working x-platform commercial implementation (probably on a shoestring budget), it will be very hard for the governments of the world to believe iMessage’s insistence on being Apple-hardware-only is anything but an anti-competitive move.
There was news a few weeks ago that Apple announced they’ll adopt RCS. Not sure what came first, but it’s already happening.
Yes, in response to regulatory pressure, especially in the EU, they capitulated and announced RCS support would be coming to iMessage eventually. That is good. But there is always a background concern that they will seek to satisfy the letter of regulation but not the spirit.
For example: how much of the RCS standard to implement, whether to drag feet on roll out, whether to track the standard as it changes, and whether to diverge iMessage farther from RCS are still open questions inside Apple.
I think the ethical move would be for Apple to fully support RCS in iMessage, and also to make an x-platform opt-in iMessage app available across platforms, even if that x-platform app is tied to an Apple ID. Heck, there’d even be a benefit for those Apple users who aren’t all-in on using Apple on every single device. I think this release of Beeper / pypush / etc. will create some natural pressure for this outcome, which would make the iMessage network more akin to Telegram, Signal, LINE, etc. just with built-in support on Apple hardware.
Hmm. A negative development today on the point of EU regulation:
iMessage will reportedly dodge EU regulations, won’t have to open up
Ironically, iMessage is (just barely) not popular enough in the EU for their monopoly regulation to kick in. But, iMessage is popular enough in the US for the same regulation to apply, but… the US doesn’t have the same regulatory framework. So, I’d say, this reversing work is even more important now.
There is lots of interesting context in this blog post by Beeper: https://blog.beeper.com/p/how-beeper-mini-works and this blog post by the person who reversed the protocol: https://jjtech.dev/reverse-engineering/imessage-explained/.
The most concerning bit is:
So it sounds like:
I wonder how Beeper intends to build a reliable product on this. Are they just going to throw a fit an apologize if Apple shuts it down?
There is no company here, but they might find themselves acquired. I do not like Apple’s rent extraction games, but I’m not sure if I like the carriers more. It’s just a bad situation all the way around.
What do you mean specifically in the case of Apple and iMessages/Messages.app? Is your claim is that their choice to keep iMessage only on Apple hardware does not add value to the consumer? That argument would need justified, as it isn’t self-evident. Also, a strong argument would need to discuss the costs and benefits {(a) to Apple and (b) to customers} of supporting iMessages on other hardware, would it not? What is the calculus?
I’m only just now seeing Beeper on another site, so the first questions I have are: is Beeper based on this? Or, did Beeper independently RE iMessage and then buy this competitor project…?
It seems like Beeper is using actual Mac in a datacenter for this: https://youtu.be/ji5HwS3bhlU?t=358 (which means confidentiality concerns).
EDIT: It looks like the recently released Beeper Mini is actually based on this RE work: https://www.theverge.com/2023/12/5/23987817/beeper-mini-imessage-android-reverse-engineer
This is all pretty neat but I can’t see it lasting all that long. The Verge article linked in an earlier comment contains:
But then the linked repo says:
The macOS binary is used for registering with Apple’s servers from a Mac. In Beeper’s blog post, they talk about a completely separate mechanism for registering involving SMS . I’m guessing the reason they don’t need the blob is by using this second registration method that can only work on a phone.
What’s the upside of an Android user being recognised as an iMessage user?
As a European, I see little use for iMessage because everybody is using Signal or WhatsApp already. In US the blue bubble has been important culturally.
There’s that social “blue bubble” thing that @pimeys mentioned.
But the real upside is that if your iMessage-using contacts’ devices see that you’re an iMessage user, their messages to you will be encrypted end-to-end. They will also have an easier time creating group messages that include you, because iMessage has some interface deficiencies creating SMS group threads.
Thanks. I was hoping that the social capital aspect wasn’t the end goal.
This glosses over the biggest advantage of iMessage vs. SMS: iMessage removes the carrier from the equation entirely, and doesn’t require the user to have a phone. iMessage users can communicate with other iMessage users over the IP network, rather than over the carrier network, which means I can text my friends from my MacBook, my iPad, or my iPhone, without needing to have a SIM for any of them. SMS messages (green bubbles) breaks this feature, requiring me to have my SIM-enabled phone within some small distance of my Macbook for message-forwarding to work. This, in a word, sucks. It means I can’t text on a plane, for instance.
iMessage exclusivity is anti-competitive and bad, but as a technology, iMessage is far, far, far superior to SMS and RCS. Blue bubbles isn’t a social stigma because people like the color blue, it is because texting with a green bubble is a significantly worse user experience than texting with blue bubbles.
This is true, but not exclusively so. At least here in the US, green bubbles also carry social stigma around (perceived) wealth. Google claims that iMessage dominates because of bullying. I don’t think it’s fair to claim that the blue/green bubble dynamic is solely due to iMessage being a superior experience (which to be clear, it is).
That first part is certainly one reason that I like end-to-end encryption. I didn’t mean to omit the second part. It just wasn’t front of mind for me because it still requires an Apple device right now. And while I do use a macbook much of the time, I still spend enough time on a Linux laptop and desktop (which don’t get to participate in this device- and carrier-independence) that I wasn’t thinking about that side of it.
For people who do use devices that can participate in that, I’m sure that makes texting with blue bubbles better than texting with green bubbles.
For others, it is more related to the group chat UX, the tapback annoyances, and a few other papercuts. And I’d like my chats to be encrypted because carriers are happy to mine them for creepy purposes, given the opportunity.