Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It seems that at least the push notification registration part uses a "leaked/extracted" FairPlay private key [1]. As far as I understand, FairPlay certificates/keys should be unique to each iDevice. Couldn't Apple trivially ban all subscriptions originating from this fake device? The comment says you know how to generate more; does Beeper Mini generate one for each install? Why would Apple believe those certificates are authentic?

P.S.: the source repo mentioned in the comment (https://github.com/MiUnlockCode/albertsimlockapple) is 404.

[1] https://github.com/JJTech0130/pypush/blob/main/albert.py#L16



Snazzy Labs did an overview video [1] about this implementation. According to them, reusing a specific hardware token is such s common practice that Apple would need to "redesign their entire authentication and delivery strategy" to mitigate this problem. I guess we'll see how this statement holds up in the coming weeks/months.

[1] https://youtu.be/S24TDRxEna4?t=5m38s


This didn’t really say much. Apple definitely knows about Hackintosh users, they mostly just don’t care. The question is whether they will actually do something if made to care.


They 'don't care' because they know that the M series processors were coming and now there is a built in death counter coming for Hackintoshes...the day they drop Intel support.

June 5, 2028: Intel hardware will reach "vintage" status after having been discontinued five years prior, ending most of Apple's service and parts support for Intel hardware.

June 5, 2030: Intel hardware will reach "obsolete" status after having been discontinued seven years prior, ending all of Apple's service and parts support for Intel hardware.


> They 'don't care' because they know that the M series processors were coming and now there is a built in death counter coming for Hackintoshes

No, they don't care because they don't think about it at all. Hackintosh's numbers never mattered, it's always been too onerous to maintain even when it was at its easiest.


This is too high profile. Apple is absolutely, 100% going to kill this and it’s gonna screw this over for those of us who leverage iMessage in Hackintosh environments.


You might be right, but if ever there was a regulatory environment under which Apple would think twice, this might be it.


Apple may be reluctant to kill this exactly because it is high profile, given the current anti-trust investigations.


It's been around for ages, and Apple has taken no action so far.


It has never been this easy and it has never been behind a subscription fee.


Yes it has... Beeper, before Beeper Mini.

Using the aforementioned Mac Mini server farm method.


We're talking about a company that changes CPU architectures for their ecosystem every few years, completely seamlessly. If redesigning their entire authentication and delivery strategy is what it will take to mitigate this problem, Apple will do it.


What problem? Increased compatibility?


From Apple's perspective, yes. Social pressure to buy Apple devices to use Apple's messaging app is part of Apple's marketing strategy.

Apple also claims that blocking devices by serial number or similar unique hardware identifiers is a key part of its anti-spam strategy. If true, an end-run around that will likely create problems for users as well.


The creator of this is screwing things up for everyone. If it was an obscure, open source project Apple would probably let it slide and we’d be able to enjoy this indefinitely. This has been the case for Hackintosh stuff and the like.

But no, the author had to make a dumb, flashy looking website that looks like they’re advertising a product built around reverse engineered Apple tech. I bet they get a Cease and Desist by the end of the week and the hole is patched shortly after.


Isn't apple implementing full RCS support next year?


There is no encryption in the RCS standard, so of course no encryption.


The current state of affairs re encryption is an accident of history that I would bet doesn’t last much longer once Apple gets formally involved.

“Apple says it won't be supporting any proprietary extensions that seek to add encryption on top of RCS and hopes, instead, to work with the GSM Association to add encryption to the standard.”

https://www.techradar.com/phones/iphone/breaking-apple-will-...


I think so, but something makes me think they're not going to do it in a way that gives RCS users full parity with iMessage users.


Not encryption, apparently. And the blue iMessage bubbles indicate encryption, so RCS bubbles will be green.


Apple has control issues. If they don't control it or at least sign off on it, they want it to be incompatible with their hardware.

Hell, they don't even allow alternative browsers on their iOS devices. All the non-Safari browsers are just Safari in a (Chrome, Firefox, etc) skin


One man's increased compatibility is another's security vulnerability.


Bridging the blue bubble moat.


Does this look like the same file from the deleted repo? https://github.com/rdxunlock/albertsimlockapple/blob/main/AL...

I'd love to see an open source version of Beeper with no analytics. I'd be happy to host my own notification server.


The python library they provide should be a good start at least: https://github.com/JJTech0130/pypush


Beeper already advertises the self-hosting route: https://github.com/beeper/self-host


I hope they open source their client app or at least makes it possible to connect to other matrix server. For me, their client app is the best matrix client in terms of UI.





Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: