jard

“80-90% of your classmates [are being filtered out of your life]”

Citation needed.

Meh, it all sounds unsustainable in the end IMO. I mean, OG Beeper Mini was built on piggybacking off of a set of Mac Mini serial numbers, and Apple already plugged that hole.

Even then, internalized testing of an exploit and what actions a company would tolerate from abusing that exploit is very different from what that same company would tolerate once the exploit becomes publicly available. This is coming from personal experience — back in my “seedier” days I’d fuck around with random public APIs for the fun of it to see what I can do, and with my own “internal testing” I found I could get away with a lot. Once I shared that knowledge with others, I found that companies are far more willing to crack down on abuses of their API than my “internal testing” suggested otherwise.

I fully expect that Apple will probably revise the “10-20 accounts per Mac” fact once this fix actually starts to kick off.

That makes sense to me, though personally if I had to buy Mac hardware to enable the bridge I’d be inclined to go all-in with a self-rolled solution anyways, and fully route everything through the Mac. I just can’t bring myself to trust a company like Beeper after their pypush stunt.

The intersection of users who simultaneously use Android/Linux/Windows/Mac/iPhone (I’m part of the latter four) is small to begin with, and then additionally requiring the purchase of a Mac to even enable bridging capability pretty much excludes this to tech enthusiasts interested in bridging their iPhone/Mac with their other devices. Or in other words, it can’t really be advertised as Beeper “Mini” anymore…

So, essentially, it’s just a shitty company-operated clone of BlueBubbles now? What does Beeper offer now that a BlueBubbles solution doesn’t?

For example, it’s possible to self host and proxy BlueBubbles through an Nginx server on a VPS, which, when combined with connectivity to a Mac through local network/VPN handwavium, and proper security/authentication, allows you to securely access your iMessages on a public Internet domain through a web browser. Why should I trust some company’s band-aided implementation of that over rolling my own community-backed solution, especially if that company’s business model revolved around charging for exploitative access to a closed, proprietary protocol?

Apple v. Psystar, 2011: Reverse engineering and circumventing copy protection mechanisms is copyright infringement under the DMCA, 17 U.S. Code § 1201.

Apple v. Corellium, 2023: Fair use doctrine, even when validated, is not an excuse to dismiss claims of circumventing copyright protection mechanisms, and can not be used as a defense against such claims. No ruling can be made on the validity of DMCA counts using fair use doctrine as a defense. Note that this is the exact defense that Beeper claims will protect them against litigation.

I have stated multiple times that Beeper is circumventing a copyright protection mechanism. I linked to the Python PoC, which is freely available for everyone to see. The exploit requires Mac serial numbers to forge an inauthentic Apple device identity, which need to be regenerated with a real, authentic Mac device. Additionally, the exploit needs to simulate an obfuscated macOS library, meaning the exploit itself hasn’t fully “reverse-engineered” the iMessage stack. Mac OS X has notoriously been impossible to simulate on non-Apple hardware, for issues of copyright infringement and license violations because of Apple v. Psystar. Beeper is simulating Mac OS X binary blobs on their servers (which is copyright infringement by Mac OS X’s licensing) for the intent of circumventing another copyright protection mechanism (which is copyright infringement by the DMCA), for the purposes of interoperability (which wouldn’t dismiss DMCA claims because of Apple v. Corellium.) And all of this is to bolster their “Beeper” brand, giving Apple’s lawyers a direct excuse for claims of monetary damages.

Seriously, to any knowledgeable programmer who’s even vaguely familiar with copyright protection and the DMCA, this all screams as a legal dumpster fire just waiting to be set ablaze. It’s a fucking mystery how Beeper was able to get their engineers onboard with the whole thing in the first place, especially since Migicovsky, their co-founder and CEO, is a delusional, egotistical nutcase who doesn’t even understand how his own tech works.

You continue to assert that I haven’t provided factual information. I cite court cases and factual evidence about how the exploit works. Yet you continue to argue like an ostrich sticking its head in the sand, nitpicking on technicalities like “well the kid actually did it, not Beeper.” Yeah, because Apple’s lawyers would care about that.

Any time I attempted to discuss technical details, you pull out your “we’re laymen” and “we don’t know the details like you do, explain it for a layman” bullshit excuses to reduce things down to a strawman that you can then attack — I did this in genuine good faith, by the way, in the hopes that we can come to a mutual understanding!

I’m only responding now because you’re misrepresenting my arguments in bad faith to a third party. Otherwise, I’m not going to argue any further with someone whose stance is entirely and hopelessly sided against by existing case law and the entire body of copyright law, who doesn’t understand how the DMCA works, who doesn’t understand any basic tenets about how copyright fundamentally works, and even more egregiously, who refuses to take in new information that contradicts their worldview.

The complexities of this legal shit is why I fully stay away from reverse engineering proprietary protocols owned by trillion dollar companies, and don’t rely on the arguments of random clueless Redditors (or Redditor-likes, because that’s all Lemmy is nowadays) to bail me out of an inevitable massive lawsuit. You, as a self-admitted layman, seem to think otherwise. Dunning-Kruger and/or trolling in full effect. That’s why I blocked you.

(IANAL, TINLA, speak to your own lawyer, yada yada yada.)

You honestly should stop, you’re a self-admitted layman who has no idea what they’re talking about and refuses to listen to anyone. I’m not sure if this is some elaborate attempt at trolling, or if this is another example of Dunning-Kruger, but my block list goes nom nom nom.

deleted by creator

deleted by creator

deleted by creator

deleted by creator

Because:

1. they’ve obtained permission to do so. A trillion dollar company like Apple is going to go through every legal hoop possible to avoid litigation from competing companies by any means. Meanwhile, Beeper purchased an exploit from a high-schooler, developed without Apple’s knowledge, and began commercializing it. No attempt was made to securely and ethically disclose this security vulnerability; Beeper went straight to profiteering.
2. as you stated: (“Apple … reverse engineered a lot of stuff to make it work on apple products”), this is solely to achieve interoperability with Apple products. Beeper charged a subscription for a security exploit, their goals were no longer to solely achieve interoperability but to profit off of their reverse engineering attempt. Existing case law makes this illegal in both the US and the EU.

Apple already publicly announced they’re working on both implementing RCS to (Apple) Messages and working to get E2EE into the RCS Universal Profile, so this whole “anti-competitive, anti-interoperability” argument falls flat.

At the end of the day, this app was an attempt to commercialize a high-profile exploit which threatened the security of iMessage. Politicians like Senator Warren making these criticisms of “monopolistic behavior” are, as usual, being tech-illiterate buffoons.

https://appleinsider.com/articles/23/11/16/apples-flavor-of-rcs-wont-support-googles-end-to-end-encryption-extension/amp/

I couldn’t find a non-tabloid source or a direct link to an Apple statement in the moment, but that doesn’t mean they’re not going to do it. It’s already been reported by the media as “stated-by-Apple”, and if that’s not the case I’m sure Apple will gladly rectify things themselves.

deleted by creator

Various Apple statements on the matter, I’ll link to the r/UniversalProfile post celebrating it. (As it turns out, the post did not actually say anything about E2EE. It’s a statement that’s been shared on several different tabloids though.)

It’s the most logical approach to achieve interoperability because, while Google RCS already supports E2EE, it is pretty much the antipode of interoperability: only Google and Samsung are allowed true access to gRCS’s APIs. Apple being additionally granted access would effectively establish a messaging duopoly, as there would be no reason to use anything other than Google Messages and iMessage. There’s a reason why these APIs don’t exist in the AOSP.

I don’t understand why they continue to do this? Apple’s already working on adding E2EE to the RCS Universal Profile and implementing it into iMessage, so the need for a “blue bubble” in Android is going to become moot.

I get the whole thing about interoperability, but when your app’s business model revolves around charging people money to access a glorified exploit (Apple themselves stated this was the case, but you can easily verify this by looking at the source code of Beeper’s own PoC), to then follow up with more hacks and workarounds that will inevitably get patched, the sustainability of such an operation becomes dubious.

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.

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.

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.

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.