Isn’t it funny that every tech commenter was like “Apple would have to re-engineer their whole iMessage stack if they want to cut off access to Beeper Mini”?
That would seem to imply that tech commenters know less than Apple about Apple’s own servers. Shocking.
My bet is that is Apple comments at all, they will talk about closing a security vulnerability rather than cutting off android users.
You would have be dumb enough to buy apple products to believe that.
A public statement about this being for security can’t possibly be more dumb than Beeper purchasing an open source cross-platform iMessage proof of concept which specifically spoofs old, fake Apple devices, publicizing and commercializing it with a monthly subscription, and crying foul when Apple swiftly finds that same repository on GitHub and patches the method.
You know, that sounds exactly like what closing a security vulnerability would entail.
The thing with this service is, if I understand it correctly, that they were using someone else’s device ID to send messages.
So, say for example that someone started using my Mac Mini’s ID (my Mac being located in Madrid, Spain) to send iMessages in the US….
People expected Apple not noticing it?
It worked when it was some hacker’s project because at that time, a few stolen Apple device IDs didn’t raise too many red flags. But at a large scale, and used by a company, it may be easy for Apple to detect.
And don’t be fooled: the system worked by stealing someone else’s legitimate device ID, and pose as it to send messages to the system. So, this company could be making money by using you Apple device ID. I’m not ok with that.
That’s Beeper Cloud you’re describing. Beeper Mini reverse engineered the iMessage stack to create a gateway between Google Cloud Messaging (GCM) and Apple’s servers. The Android devices were natively initiating and sending iMessage traffic on-device, not through an intermediate Mac server.
Issues of reverse engineering a proprietary service aside, they were also charging an (arguably, exorbitant) fee for their solution. Its early demise was pretty much guaranteed from the start.
I was under the impression that interaction with Apple’s servers required some kind of “proof” (honor system really) that you’re using an Apple device, which used device ID that was spoofed; just like how Hackintosh had done for push notifications for years.
Worth noting that Hackintosh got to a point where someone wrote scripts to generate random strings to brute force until they encounter a valid device ID, so they’d literally assume someone else’s legitimate device to get push notifications.
It looks like you’re correct: the Python POC apparently simulates some kind of Apple library with a virtual x86 core to generate validation data for device registration, and spoofs the request to Apple’s servers by pretending to be a MacBook Pro 18,3 running macOS 13.2.1.
So not only is it unsurprising that Apple patched this early, they also probably did it in the easiest way possible of blocking the combination of this particular MacBook device and whatever validation payload was being generated.
Why a company would purchase the rights to an open sourced iMessage POC, commercialize it with a subscription and then go “surprised pikachu face” when Apple finds the exploit and blocks it… that’s entirely beyond me. Original dude must’ve made a fat paycheck though.
Thanks for digging into this and confirming my understanding!
On a quick glance, this looks to be more secure the the old Hackintosh push notification (where it was based solely on a single device ID/serial number), but rather, some kind of certificate based identity system. This makes it more secure because without access to Apple’s private signing keys, it should be very difficult to get a certificate signed by Apple to spoof the interaction. Though, I wonder how were the devices getting it in the first place, and if that part would be the next vector that’d need to be compromised (i.e.: if you get a signed certificate during device activation, then it’d be possible to swipe a signed certificate from a Mac you own; or that activation process itself becomes the next attack vector).
Having interacted very briefly with Eric Migicovsky a long time ago (due to Pebble), this does not surprise me that much. He’s a great guy, and appears to want to do the right thing to help everyone. Beeper wanted to do it in the cloud with Mac systems/VMs, which is a costly endeavour. This POC would allow the interaction to run natively without themselves essentially MITM’ing all users, so it would save their company a lot of money. POC was done allegedly by some high school kid, and given Eric’s Pebble fame, I think he’s just thrilled that they could save some money and help some kid get started.
In all cases, it is certainly interesting to see how this has been playing out, and I’d be curious to see how this continue to play out, because I doubt this will be the end of this story.
Beeper mini still needed a device serial for it to register with apple’s serial which makes it easy for Apple to see a swath of fake device serials being registered.
Why would Apple have to reverse engineer their own protocol?
Re- not reverse-engineer.
D’oh. Shouldn’t have commented before getting out of bed.
That didn’t take long. Unsurprised though.
This is the second service in as many weeks to be shut down offering this service, right?
Yep; different circumstances though.
Beeper Mini was shut down by Apple, which allegedly identified the requests from Beeper Mini and terminated access to its servers.
Nothing Chat/Sunbird, on the other hand, was shut down from themselves, because they were caught mishandling user information. The method itself was not shut down, rather they discontinued their own implementation. (Fwiw, Beeper has a similar implementation on another product of theirs, which remains functional as far as I know. )
It’s down as well.
deleted by creator
With pypush the error seems to come when generating validaiton data (it either gets stuck endlessly or shows a error saying no cert found). Pypush is still able to communicate with apples sms gateway (and the gateway still sends sms replies). Additionally 2fa codes are still triggered and sent.
The weirdest part is even if you import your own real mac serial (data.plist) the same issue arises (I tried with my personal 2011 mac mini).
I wonder if the issue specifically relates to pypush trying to spoof a m1 mac using a intel mac serial, or the uncanny vally of registering a phone number through a mac serial.
Gotta keep up the social pressure to bully more people into buying iPhones.
No one bullies anyone. It’s a choice.
You’re right. Bullying is a choice.
It is, but that’s not what happening. Downvoting because you don’t agree - so is bullying by negating any comment you don’t agree with.
I don’t think you’ve been around a group of American teenagers recently. There’s a point where people stop caring, but people absolutely are borderline bullied of for not having an iPhone lol
Good. Beeper Mini was a gross hack based on an edge case trick that they shouldn’t have been charging for.
I honestly have to hand it to the kid who discovered this in the first place.
Man’s still in high school, yet managed to find a high profile iMessage exploit while doing something he clearly enjoyed doing, knew the full value of what he’s discovered, sold it off to a company he likely surmised was frothing at the mouth for technology like this, and walked away with a huge wad of cash at the end of the day. He’s easily going places.
It wasn’t really a hack though so much as it manipulated the way it identifies itself to Apples servers. Apple obviously changed something there in retaliation so it’s not working now, but depending on the severity of the change they could get around this.
Honestly though it won’t last long. Eric has a history of being overly ambitious and it’s why Pebble failed.
I detailed it in a previous comment of mine, but it spoofs an identity request by pretending to be an early M1 MacBook whilst providing fake validation data from an old Intel-era macOS library. Apple servers then believed it was a real MacBook and handed over all encryption keys needed to establish E2EE communication over iMessage.
Hack or not a hack, it most definitely is a weird edge case scenario (the specific combination of new MacBook model with old validation data) which is probably why it all worked to begin with.