[1] https://blog.nektra.com/2020/01/12/reflecting-on-16-years-of...

Anecdote: we reverse engineered several Microsoft products and before Microsoft Windows 7 launch we were contacted by Microsoft QA and they offered us support to check if our software was compatible with it! BTW, our software was installed in millions of computers around the globe. For example, Trend Micro used our software for supporting their antivirus in Outlook Express and Windows Mail.

Our Deviare Hooking Engine [1] was eclipsed when Microsoft Detours [2] turned to an MIT license and free. Even when our was superior in several ways. This is why I wrote that you should continuously fight for "adversarial interoperability".

[1] https://github.com/nektra/Deviare2

[2] https://www.microsoft.com/en-us/research/project/detours/

If you know anybody that can help please let me know because I want to get back to maintaining the project.

If the use of this software is against their rights in some way, the end users running it would be the ones in violation. Publishing original software is protected expression.

So it's even worse than the risk of being taken down. Way worse.

https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-w...

An open source client for an API need not include any non-original works.

The situation seems very similar to the AACS key leak back in the day: https://en.wikipedia.org/wiki/AACS_encryption_key_controvers...

It targets games, so manages to be useful without having to emulate or re-implement the majority of the OS.

That means Jack Shit in a world where a lawsuit can ruin a person's life regardless of its legal merit, with zero consequences for the corporation that filed it even if it gets tossed out by a judge eventually.

LPT: Live as if human/constitutional rights didn't exist. Because if push ever comes to shove, you will quite possibly find that they indeed don't exist in practice.

Obviously that outcome is something he wants, but I still think its interesting.

[0]: https://www.theverge.com/2023/12/5/23987817/beeper-mini-imes...

There's probably a cliff in complexity. Once Apple starts requesting signed attestations from the secure enclave on the devices that have one, it's game over.

They probably don't just yet, since still too many people use iMessage on first-party clients that don't have one, e.g. Intel laptops without a T1 or T2.

Note that iPhones already receive SMS spam and fraud just like every other phone.

However, you are correct that the blue bubble is no longer a guarantee that the bad actor is using an iPhone.

Whether the number uses iMessage or not is totally irrelevant.

Like the legal action that is currently protecting us from robocalls?

I don’t know if iMessage registration requires bidirectional SMS verification, though. If it does, that would be significantly harder to spoof than just caller IDs.

Spam protection should be on the recipient, rather than the sender.

I would think that’s the biggest issue right now. If spammers can register “real” iMessage accounts at scale without Apple hardware, Messages becomes less pleasant, very quickly.

If it ever becomes popular, there will be a lot of duplicate serial numbers. That's easy to detect and ban.

(perhaps different sets of data can be used, but it must be something that Apple already has, and the user has already provided (i.e. the iMessage email or the iMessage phone number, from the iPhone's enabled Settings)

I spent a number of days with them where they were trying to work out if they were fake. The serial number was real but they were fairly sure the number had been taken from a real product and reused, but were unable to say for sure.

I ended up just returning them (because of the ebay return window) but found it interesting that Apple couldn't easily check this, and was very aware of the issue.

No matter the method it would be a scorched earth approach. I suspect the number of people actually using Beeper will be far below a rounding error for Apple.

Right now they can probably just ban known-spam-originating devices, which is much more effective than banning iCloud accounts since there is a much higher cost to the spammers.

That and reading the books is actually about the only thing it can do right now.

And as part of Security Updates they have patched vulnerabilities just in the relevant apps.

So there is nothing technical stopping them. It's just been customary to treat iOS as a product where all features ship together.

Actual updates require the app binary/bundle to be mutable.

But mainly it's because base Android (AOSP) can be arbitrarily modified by the OEM; and Google doesn't want to have to trust installations of Google Play Services that have been arbitrarily modified by OEMs.

(Especially because those versions would likely all act differently-enough from one-another that they would be forced to loosen their server-side, network-traffic-fingerprint-based "authentic Android device" detection that allows them to ignore/block bots pretending to be Android devices.)

By shipping Google Play Services through the store, they can ensure that, on devices that run it, it's exactly the same code for every device that runs it, with no OEM alterations. (And they can also include various checks to reject devices that would try to alter that code at load time. This is the real reason why e.g. Huawei devices are blocked from using Google Play Services — they try to patch unspecified parts of the Play Services code while loading it, "breaking the integrity of the platform" from Google's perspective.)

In the sense that the app is just a wrapper around a system framework, sure. But changing that framework would be an OS release.

It's not deeply integrated into the iOS by any normal definition. It's just shipped together.

Btw, maybe related, on iOS I have "app privacy report" enabled, to show me a list of apps and the recent entitlements they used. Every Apple app, even those that don't need access to them, is shown as having recently accessed my Contacts. I find this weird. Anyone know why they do that? e.g. I've never even used the Health app and yet it's accessing my Contacts for some reason.

They would need to accept and verify a flag from messages that the copycats can't reproduce. At the very least that would require a client update from anyone using official iMessage clients, which covers many millions of devices.

Unless they're able to hook into already existing flags/keys on the devices since they already verify application signatures and a whole other host of things.

Apple can probably do it, but much like jailbreaking how fast can they release breaking changes?

edit, because i used the wrong turn of phrase

Even if short lived they could onboard a lot of Android users and then use RCS once it’s supported.

Some others:

- Find my device features including Bluetooth ping networking (airtags, Tile, Android's upcoming network)

- Airdrop/Nearby Share

- Bluetooth LE proximity pairing (at least I doubt this works when pairing cross ecosystem)

- Carplay/Android Auto

- Airplay/Google Cast

Are there any headunits that only support one or the other? The cheap Chinese unit I got last year supports wireless for both. It would be nice to have an open protocol though, so third parties could develop alternative UIs.

Another Apple ecosystem that can be used by non-Apple devices. OpenHaystack [0] has been working well for quite a while.

[0] https://github.com/seemoo-lab/openhaystack

You can buy tags from AliExpress for $5 that implement it. I've been using a few for a couple of months, and no issues so far.

The last commit and release is from october.

the EU is fundamentally interested in these changes regardless of consumer welfare. this is sour grapes because they fail at tech by every conceivable metric and by degrading everything to a common feature set and commoditizing certain standards, they hope to give domestic companies a prayer. that it prevents innovation and improvements is merely a secondary concern for the hard-headed anti-Americans in brussels.

Another way to read this: Apple has a superior product because they perform anti-competitive practices and don't allow other companies to out-product them. And when they do, they buy them/shut them down before anyone is the wiser.

https://www.theverge.com/2021/4/27/22406303/imessage-android...

In short, Eddy Cue proposed in 2013 that Apple owning the best-in-class messaging app would be a win, and even mentioned the cost being low. Phil Schiller shut him down, arguing it would remove a barrier preventing iPhone parents from buying their kids Android phones.

That reads like anti-competitive motivation to me. In particular, it looks like tying, where two unrelated products are connected artificially. The wikipedia article on anticompetitive behaviors has a section on tying, and mentions another case involving Apple that bears some resemblance involving iPods being artificially restricted to only playing tracks either from iTunes or direct CD rips.

So I think the anti-competitive angle has some real merit.

The innovation claim, though, I have a harder time with. I don't see how releasing Messages for Android implies design-by-committee. They could just release it, like Beeper Mini just did, but without the reverse engineering part.

Honestly, this reads more like marketing spin to cover anti-competitive behaviour than a forum post.

The same is also true, say about AirDrop, if apple makes it "Open" and they have to make a breaking change for security or whatever reason, they can't feasibly even make an update available for non-apple devices let alone enforce it.

Now "Apple" has broken your non-apple device and along with it their reputation.

Open is good, but the cost is non-zero.

Universal in this context is referring to the ability to use a single app across protocols rather than the ability to use a single app across platforms.

It's what EU mandated and from March '24 all major chat apps have to be able to communicate with each other.

It's taken straight from OS X 10.8 (more precisely from an Update Combo on their download portal). It's calling NACInit, NACKeyEstablishment and NACSign functions from it (which have no entry points but with reverse engineering the offsets have been figured out). They are themselves relying on OS X system functions to get device information. The Python code is using Unicorn to emulate it and patch the calls to those functions to stubs returning pre computed values from a Mac machine (stored in a data.plist file). All clients are using the same machine identifier. IIRC, nobody did get its account locked but if the Apple ID has not been used at all it might fail (it depends on the donor device that generated data.plist, if it's a hackintosh for example it will likely not work).

Wonder what the actual app is doing since this is just the PoC.

I'm an Apple user who has no need for this app. But I really appreciate that Beeper has the balls to reverse engineer the protocol and build a business around it while fully expecting a lawsuit. That's some old school hacker shit and I'm here for it.

Apple tried and failed to sue Corellium for emulating their hardware, and now Corellium has a viable business around it. I don't see why Beeper should fare any differently. They just need to be prepared for a fight, both legally (lawsuits) and technically (ongoing game of cat-and-mouse).

Copying and modifying binary with proprietary license is not OK.

It’s legal for Apple to distribute Apple binaries. It is not legal for someone else to distribute Apple binaries.

Copying a binary from installer to app folder: not distribution

Putting the binary on a USB and giving it to your buddy: gray area, not worth prosecuting, but maybe technically distribution

Uploading the binary to a GitHub repo titled “Apple binaries here”: obviously distribution

But it's more like a ticket, or an NFT. It's a unique blob that was sold to you. You should be able to transfer it.

Apple's best argument here might be that the blob is meant for one person, and distributing it this way is like sharing a ticket to the cinema between multiple people. I can't enter the cinema, then come outside and pass you the ticket so you can enter it too.

That sounds nice and all, but what happens when the first bill comes due from their legal team?

I think if it comes to it, Apple will wind up looking very bad in a trial. Their behavior here is deeply anticompetitive. iMessage is just too important to modern text communication to be as locked down as it is.

If Apple doesn’t want to make an Android app, they should at least make an API so other developers can.

What do you mean; if a private company creates something, and enough people buy/use it, at some point it becomes a common good? I like the idea of iMessage being open, but I don't like the idea of forcing Apple under government threat to open it

iMessage is so important today, especially to young Americans, that its exclusivity to iOS has become a significant barrier to Android or other operating systems from being competitive.

It’s up to regulators and the court system to decide whether that is a violation of antitrust law. But if it is, then yes, the government should force them to open it. That’s what it means to enforce antitrust law.

Honest question, I've been texting since t9 and have never owned an Apple device.

The problem is when you have one person in a group that is on Android when everybody else is on Apple. This causes the iMessage conversation to use SMS instead. To signify this in the app, texts appear as green bubbles instead of blue, so it’s obvious when it happens.

This is bad because SMS is totally obsolete. It causes images and videos to be shared in extremely low resolution, along with problems of messages not getting delivered reliably and other missing features.

So effectively to the iPhone user, Android users very visibly cause group chats to be super crappy in iMessage.

This is not the fault of the Android user really, because it’d work way better if Apple supported RCS like Android phones do, but many people have a very strongly negative impression of Android due to this.

In fact, some iPhone users put social pressure on people with Android devices due to this in the form of excluding them from group chats or complaining about how they cause problems.

Apple has been perpetuating this problem because it suits them. People know this, but it’s Android and Android users that suffer regardless due to Apple’s dominant market position.

Of course many other messengers offer most of these features too, but for some reason, no alternative has been able to establish itself in the US.

Eventually, someone will send spam using this app, at which point automated systems at Apple will “console ban” the hardware identifier shared by all of the app’s customers. The project presumably has a library of valid hardware identifiers collected and ready to go, and eventually that’ll be drained by spammers faster than revenue versus device purchasing allows for. Apple can just wait silently as the app exhausts their pool of hardware identifiers, each banned by pre-existing anti-spam automation, without ever acknowledging their existence.

[0]: https://github.com/Dadoum/imd-apple-services

So would be curious if they have already sought legal advice which says they are in the clear.

The book doesn't talk about it too much, but presumably these handles could be limited-use (time-based or only granting a capability to send a certain number of messages) and could be revoked.

I know it would probably be off-putting to give each person I meet a different GUID for contacting me (kind of like telling them your email address is @), but it might reduce the spam I receive.

[0] if you're searching the ebook, they're called "golden enums" in the text

However, considering that I'd except they'd know better than to just outright take a binary from MacOS and use it in their app (assuming that's actually the case..).

The relevant policy can be found at: https://support.google.com/googleplay/android-developer/answ...

"We don’t allow apps that interfere with, disrupt, damage, or access in an unauthorized manner the user’s device, other devices or computers, servers, networks, application programming interfaces (APIs), or services, including but not limited to other apps on the device, any Google service, or an authorized carrier’s network."

From what I understand your app connects to APNS without permission from Apple.

I have personally had my Google Play Developer account banned for making an app that connected to a 3rd party service

>the iMessage protocol and encryption have been reverse engineered by jjtech, a security researcher. Leveraging this research, Beeper Mini implements the iMessage protocol locally within the app. All messages are sent and received by Beeper Mini Android app directly to Apple’s servers. The encryption keys needed to encrypt these messages never leave your phone. Neither Beeper, Apple, nor anyone except the intended recipients can read your messages or attachments. Beeper does not have access to your Apple credentials.

>We built Beeper Mini by analyzing the traffic sent between the native iMessage app and Apple’s servers, and rebuilding our own app that sends the same requests and understands the same responses.

https://blog.beeper.com/p/how-beeper-mini-works

i’ve run multiple 3rd-party signal clients, even alongside the official apps, and never seen any problems or warnings.

[flare]: https://gitlab.com/schmiddi-on-mobile/flare

It would be nice if third party clients were allowed to connect, but it's totally understandable if they don't want to allow it. Servers cost money, and misbehaving client apps that you have no control over sound like a pain in the ass.

With the trouble Apple goes through to ensure you are accessing APNS from an Apple device including obfuscating the signing algorithm and requiring unique hardware identifiers I think it’s safe to assume they don’t want 3rd parties accessing their services.

Well what did it do with the service?

This write up adds so much more to that respect. It would have been easy to botch this, it would have been easy to do a worse implementation that would have caused problems for users whether they cared or not, but Beeper seemingly took the time to get right.

Congrats to Eric and the team on the launch!

This could literally allow things like Universal Clipboard to work on Linux and Windows - by using the method presented here to access the iCloud Keychain and generating Continuity keys and placing them there - then the iPhone will broadcast its clipboard data encrypted with those keys via BLE. If I understand all of this correctly.

I would like to live in a world where I could use Beeper without worry but I don't feel like we currently live in that world. Am I wrong?

I've been using Beeper for close to six months, and it's been a dream.

Btw, this is mostly unrelated, but do you work for a large company? I'd assume most security teams would have a problem with a setup like this.

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

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

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.

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.

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

https://github.com/xxCabin/albertsimlockapple/blob/main/ALBE...

This also seems related:

https://github.com/unicode99/MiUnlock/blob/main/activator.ph...

> Over time, we will be adding all networks that Beeper supports into Beeper Mini, including SMS/RCS, WhatsApp, Messenger, Signal, Telegram, Instagram, Twitter, Slack, Discord, Google Chat and Linkedin. We'll also bring Beeper Mini to desktop and iOS.

I'm interested, even if it's paid. I'd love to have most of those apps gone and use a cleaner one.

(Please correct me if I'm wrong; the architecture of their product is pretty confusing.)

Edit: I mean a code for Beeper Mini on Android - not desktop

where are you located?

Thus, for many socio-economic groups, iPhone is definitely king in the US, and for them iMessage is just the default way to message people because when it was introduced it was the default way to use SMS on iPhone. A restaurant in Texas famous for their funny signs put this out, https://twitter.com/ElArroyo_ATX/status/1693316647677825160 , and tons of people (myself included) could immediately relate.

It's actually weird and silly when they send me text messages and somehow I end up in the same conversation multiple times - like once 1:1, once in a group chat with myself included twice or more (as a number, as an email, as a second number). It's a bizarre experience and usually iPhone user can't see anything wrong :D

[0] https://en.wikipedia.org/wiki/Trillian_(software)

[1] https://en.wikipedia.org/wiki/Trillian_(character)

now I'm reliving the chaos of the late-00s/early-10s instant messaging apocalypse when AOL sunsetted AIM. Clients like Trillian were absolutely necessary before AIM shut down. Everybuddy was a good linux-friendly client. When I still spent time on IRC, I really really liked Bitlbee [1] with ERC [2]. Gaim was one of the first open-source projects I ever contributed to.

(I'm not saying that there's a connection there, but rather that all the chat protocols started getting used less around the same time for the same reason, which was smartphones becoming commonplace in late-00s.)

[0] https://en.wikipedia.org/wiki/Ayttm

[1] https://www.bitlbee.org/

[2] https://www.gnu.org/software/emacs/erc.html