> Warning: In order to generate the “validation data”, pieces of information about the device such as its serial number, model, and disk UUID are used. This means that not all validation data can be treated equivalently: just like with Hackintoshes, the account age and “score” determine if an invalid serial can be used, or if you get the “customer code” error.
The "customer code" error is a prompt from Apple, basically an attestation failure -- you have to contact Apple Support to get your Apple ID unlocked once you've tripped the failure. Legitimate customers will breeze right through (eg, just approving your login from your legit device), but Hackintosh users use crafty means to fake their way through the process.[1]
[1]https://old.reddit.com/r/hackintosh/comments/gij9rt/getting_...
you'd need the key from the TPM/secure enclave too, which is much much harder to extract
And the non-messaging apps with notifications too.
And the silent internal notifications. You added a meeting to your calendar on your Mac? Push notification to your iPhone to tell it that the iCloud data changed and it needs to update. Changed a file on iCloud Drive? Push notification to sync your other devices. Got a phone call, and it starts ringing on your Mac too via Continuity? Push notification (encrypted like an iMessage).
Just how many messages are going through that service every second?!
I’m confident in saying at least six.
This is typically the 'secret sauce'.
The secret sauce has never been secret
On the other hand, I'm not sure if this is a typo on Apple's part, but it certainly is weird: you must use "WindowSerial" here[1], not "WindowsSerial" with the extra s
[1] https://github.com/JJTech0130/pypush/blob/8b33c0ee5d540d8ac7...
Congratulations on this amazing work :)
I wonder, will this be in violation of the EU's DSA and/or DMA once they are in force?
In whatever way Apple is going to comply with DSA and DMA, this ain't it.
> Interoperability between messaging platforms will improve - users of small or big platforms will be able to exchange messages, send files or make video calls across messaging apps.
Lock-in mechanisms like the above would at least run counter to that goal.
I also think that enforcing device restrictions on a messaging service is more problematic than on some random API: Messengers are subject to the network effect and usually you can't freely choose which messenger you want to use - it depends on which one the people you want to talk with are on.
In an extreme case, some person or business could choose to exclusively communicate using iMessage. Then you'd have to buy an iPhone just to be able to reach them. This seems like exactly the kind of interop problem the EU is concerned about.
[1] https://www.europarl.europa.eu/news/en/headlines/society/202...
And I’m completely fine with that.
However, this article says:
> IDS is used as a keyserver for iMessage...
> The first step in registering for IDS is getting an authentication token. This requires giving the API your Apple ID Username and Password.
> After registering with IDS, you will receive an “identity keypair”. This keypair can then be used to perform public key lookups.
So how does the Beeper Mini app take an arbitrary Android phone number, register public keys for it with IDS, and perform public key lookup of recipients... all without ever using an Apple ID?
[1] https://blog.beeper.com/i/139416474/security-and-privacy
EDIT - It looks like the answer here is the 'SMS Gateway' which is virtually undescribed in the OP article or anywhere on [1]. Guess that's the secret sauce.
Just one nit: Per the article,
> While the pair format is much more documented and easier to implement, it does not provide forward secrecy using “pre-keys” (similar to Signal) as the new pair-ec format does.
Is there any indication that (modern, i.e. ECIES-using) iMessage really uses pre-keys? As far as I can tell, it only uses a drop-in replacement of ECIES instead of RSA for the encryption (and maybe signature?) part, but that alone does not yield forward secrecy.
If there isn't, I believe this might be a misinterpretation of how RSA, Elliptic Curves, and forward secrecy relate. The Wikipedia article on iMessage seems to propagate the same mistake:
> The post also noted that iMessage uses RSA key exchange. This means that, as opposed to what EFF's scorecard claims, iMessage does not feature forward secrecy.
(The quoted reference actually makes no such claim.)
How cute.
[1]: https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...
iMessage has several problems:
1. iMessage uses RSA instead of Diffie-Hellman. This means there is no forward secrecy. If the endpoint is compromised at any point, it allows the adversary who has
a) been collecting messages in transit from the backbone, or
b) in cases where clients talk to server over forward secret connection, who has been collecting messages from the IM server
to retroactively decrypt all messages encrypted with the corresponding RSA private key. With iMessage the RSA key lasts practically forever, so one key can decrypt years worth of communication.
I've often heard people say "you're wrong, iMessage uses unique per-message key and AES which is unbreakable!" Both of these are true, but the unique AES-key is delivered right next to the message, encrypted with the public RSA-key. It's like transport of safe where the key to that safe sits in a glass box that's strapped against the safe.
2. The RSA key strength is only 1280 bits. This is dangerously close to what has been publicly broken. On Feb 28 2023, Boudet et. al broke a 829-bit key.
To compare these key sizes, we use https://www.keylength.com/en/2/
1280-bit RSA key has 79 bits of symmetric security. 829-bit RSA key has ~68 bits of symmetric security. So compared to what has publicly been broken, iMessage RSA key is only 11 bits, or, 2048 times stronger.
The same site estimates that in an optimistic scenario, intelligence agencies can only factor about 1507-bit RSA keys in 2024. The conservative (security-consious) estimate assumes they can break 1708-bit RSA keys at the moment.
(Sidenote: Even the optimistic scenario is very close to 1536-bit DH-keys OTR-plugin uses, you might want to switch to OMEMO/Signal protocol ASAP).
Under e.g. keylength.com, no recommendation suggest using anything less than 2048 bits for RSA or classical Diffie-Hellman. iMessage is badly, badly outdated in this respect.
3. iMessage uses digital signatures instead of MACs. This means that each sender of message generates irrefutable proof that they, and only could have authored the message. The standard practice since 2004 when OTR was released, has been to use Message Authentication Codes (MACs) that provide deniability by using a symmetric secret, shared over Diffie-Hellman.
This means that Alice who talks to Bob can be sure received messages came from Bob, because she knows it wasn't her. But it also means she can't show the message from Bob to a third party and prove Bob wrote it, because she also has the symmetric key that in addition to verifying the message, could have been used to sign it. So Bob can deny he wrote the message.
Now, this most likely does not mean anything in court, but that is no reason not to use best practices, always.
4. The digital signature algorithm is ECDSA, based on NIST P-256 curve, which according to https://safecurves.cr.yp.to/ is not cryptographically safe. Most notably, it is not fully rigid, but manipulable: "the coefficients of the curve have been generated by hashing the unexplained seed c49d3608 86e70493 6a6678e1 139d26b7 819f7e90".
5. iMessage is proprietary: You can't be sure it doesn't contain a backdoor that allows retrieval of messages or private keys with some secret control packet from Apple server
6. iMessage allows undetectable man-in-the-middle attack. Even if we assume there is no backdoor that allows private key / plaintext retrieval from endpoint, it's impossible to ensure the communication is secure. Yes, the private key never leaves the device, but if you encrypt the message with a wrong public key (that you by definition need to receive over the Internet), you might be encrypting messages to wrong party.
You can NOT verify this by e.g. sitting on a park bench with your buddy, and seeing that they receive the message seemingly immediately. It's not like the attack requires that some NSA agent hears their eavesdropping phone 1 beep, and once they have read the message, they type it to eavesdropping phone 2 that then forwards the message to the recipient. The attack can be trivially automated, and is instantaneous.
So with iMessage the problem is, Apple chooses the public key for you. It sends it to your device and says: "Hey Alice, this is Bob's public key. If you send a message encrypted with this public key, only Bob can read it. Pinky promise!"
Proper messaging applications use what are called public key fingerprints that allow you to verify off-band, that the messages your phone outputs, are end-to-end encrypted with the correct public key, i.e. the one that matches the private key of your buddy's device.
7. iMessage allows undetectable key insertion attacks.
EDIT: This has actually has some improvements made a month ago! Please see the discussion in replies.
When your buddy buys a new iDevice like laptop, they can use iMessage on that device. You won't get a notification about this, but what happens on the background is, that new device of your buddy generates an RSA key pair, and sends the public part to Apple's key management server. Apple will then forward the public key to your device, and when you send a message to that buddy, your device will first encrypt the message with the AES key, and it will then encrypt the AES key with public RSA key of each device of your buddy. The encrypted message and the encrypted AES-keys are then passed to Apple's message server where they sit until the buddy fetches new messages for some device.
Like I said, you will never get a notification like "Hey Alice, looks like Bob has a brand new cool laptop, I'm adding the iMessage public keys for it so they can read iMessages you send them from that device too".
This means that the government who issues a FISA court national security request (stronger form of NSL), or any attacker who hacks iMessage key management server, or any attacker that breaks the TLS-connection between you and the key management server, can send your device a packet that contains RSA-public key of the attacker, and claim that it belongs to some iDevice Bob has.
You could possibly detect this by asking Bob how many iDevices they have, and by stripping down TLS from iMessage and seeing how many encrypted AES-keys are being output. But it's also possible Apple can remove keys from your device too to keep iMessage snappy: they can very possibly replace keys in your device. Even if they can't do that, they can wait until your buddy buys a new iDevice, and only then perform the man-in-the-middle attack against that key.
To sum it up, like Matthew Green said[1]: "Fundamentally the mantra of iMessage is “keep it simple, stupid”. It’s not really designed to be an encryption system as much as it is a text message system that happens to include encryption."
Apple has great security design in many parts of its ecosystem. However, iMessage is EXTREMELY bad design, and should not be used under any circumstances that require verifiable privacy.
In comparison, Signal
* Uses Diffie Hellman + Kyber, not RSA
* Uses Curve25519 that is a safe curve with 128-bits of symmetric security, not 79 bits like iMessage.
* Uses Kyber key exchange for post quantum security
* Uses MACs instead of digital signatures
* Is not just free and open source software, but has reproducible builds so you can be sure your binary matches the source code
* Features public key fingerprints (called safety numbers) that allows verification that there is no MITM attack taking place
* Does not allow key insertion attacks under any circumstances: You always get a notification that the encryption key changed. If you've verified the safety numbers and marked the safety numbers "verified", you won't even be able to accidentally use the inserted key without manually approving the new keys.
So do yourself a favor and switch to Signal ASAP.
[1] https://blog.cryptographyengineering.com/2015/09/09/lets-tal...
There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES. Beeper implements it, I never got around to backporting it to pypush proper.
Also, the new Contact Key Verification (I believe it is the same thing as "key transparency" internally) should prevent the man-in-the-middle.
A lot of the things you mentioned can actually be solved on the pypush side: there's nothing preventing pypush from alerting you when a new key is inserted, or providing you with the fingerprints of each of the keys.
I'm not an expert on these things, but I do think it is time that another analysis by a proper cryptographer was done: the one you linked was from 2015, and a lot has changed since then.
Anyway, the point of iMessage is convenience, if we're being honest here. It provides a reasonable level of security that will keep out all but the most entrenched and determined attackers, and that's really all most people care about.
I commented on the key verification in the other reply, it appears to be opt-in feature, so warnings about key changes are similar to WhatsApp, available if you known about them and you know you need them.
>A lot of the things you mentioned can actually be solved on the pypush side:
Yeah a lot of the problems can usually be fixed by fixing them. :) "At least it's not fundamentally borked" can't be the standard for a multi-trillion dollar company.
>a lot has changed since then
That's just the sad part. 1280-bit keys are still there. RSA is still there. Fingerprints were added but they're opt-in.
Apple can afford to hire Moxie or OWS to implement Signal protocol for them. The fact they treat iMessage as a second class SW in their otherwise high security is ridiculous. People deserve better and they should demand better.
>It provides a reasonable level of security
But that's just it. RSA isn't reasonable. Forward secrecy became the reasonable expectation in new protocols in 2004. It was 'This Love' by 'Maroon 5' years ago. TLS1.3 has already killed RSA entirely. 1280-bit keys haven't weren't acceptable even then. OTR from 2004 used 1536-bit RSA.
If people knew it was borderline ancient in terms of it's technology, they probably wouldn't find the unnecessary risks convenient.
My point is: Apple can afford an overhaul, and they damn well should rewrite the protocol.
Does that scheme definitely use ephemeral keys? Do you know if there is any documentation on it available?
> Beeper implements it, I never got around to backporting it to pypush proper.
Ah, thank you, this is important context! I looked through pypush and couldn't find anything that looks like it might be providing forward secrecy, so I was wondering if that was a misunderstanding of the impact of (only) switching to ECIES, as forward secrecy would require more than that.
https://security.apple.com/blog/imessage-contact-key-verific...
https://restoreprivacy.com/apple-to-introduce-contact-key-ve... apparently states that but I'd rather have something official.
Also it seems to be opt-in, at least for now https://9to5mac.com/2023/10/27/turn-on-contact-key-verificat...
And yet, Apple uses this (flawed?) encryption in lots of other features. It's not a messaging platform that happens to include encryption, it's a messaging platform (iMessage/Madrid) built on top of a generic/reusable encryption system (IDS), and many other Apple protocols are built on top of IDS. Apple's "platform security guide" has several places where they recognize this:
"When a user signs in to iCloud on a second Handoff-capable device, the two devices establish a Bluetooth Low Energy (BLE) 4.2 pairing out-of-band using APNs. The individual messages are encrypted much like messages in iMessage are."
"When an incoming call arrives, all configured devices are notified using the Apple Push Notification service (APNs), with each notification using the same end-to-end encryption as iMessage."
It's (probably, to my knowledge) true that iMessage does not have forward secrecy, but that does not follow from it using RSA:
You can have forward secrecy using RSA (e.g. by exchanging ephemeral RSA encryption keys and RSA-signing these using identity keys), and vice versa you may also not have forward secrecy with (static) Diffie-Hellman.
Ephemeral keys (and/or periodic key rotation) are what yields forward secrecy, not any particular encryption, signature, or key agreement scheme.
> * Uses Diffie Hellman + Kyber, not RSA
iMessage apparently uses ECIES in newer versions of iOS instead of RSA: https://support.apple.com/lt-lt/guide/security/sec70e68c949/...
So proud that a high school student was the one to finally figure it out.
In a world of 100s of thousands of software engineers, "Cybersecurtiy professionals", and so on.
A kid with almost no credentials out-innovates everyone because they have talent and focus. Literally HackerNews! My favorite kind of news.
One downside is that I can't use iMessage on my Windows and Linux computers. Will look into pypush
Honestly, the iPhone is nudging me further to giving a Macbook/OSX a try one day, but the major blocker to me is the poor state of gaming on Macs.
I've been using Codeweavers Crossover to play games that are Windows only, and it's been surprisingly fine. I never fixed my gaming PC (for gaming, at least) and converted it to an at home server. It's been a couple months now. I just lent a friend my GPU.
Epic Games doesn't seem to work, but you could always use Legendary for those titles -- I just don't have any titles on Epic that I want to play.
I'm hoping in one of the future updates that Crossover can activate macOS Sonoma's Game Mode for the games running within Wine, because I assume it'll improve performance even more. I'm also having a bit of buyers remorse -- I didn't plan to use this for gaming, and now I'm wondering how much better an M2 or M3 Max would be for more demanding titles.
I’ve developed for and used both, and I’ve settled on iPhones for the last few generations. Though, I think flagship devices of either are fine nowadays. The ‘slab of glass’ phone is basically a solved problem at this point.
I was using Android Messages, which has a web app. The experience was mediocre because the web app had trouble connecting to my phone all the damn time.
I text some people almost exclusively through Facebook Messenger, and I think the rest I will try to move from text to WhatsApp. Both Meta-owned, unfortunately, but those seem to be easy to use cross-device and almost everybody has them.
Gaming isn't great on Mac (depending on what games you play), but macbooks are great imo. A pro or an air with apple silicon is worth the money. I've never really appreciated the build quality of a mac before.
> I just got an iPhone for the first time, and it is a noticeably better device than my previous Android phones.
In what way? What Android phones did you use in the past?
These are just a couple data points in a bag of info and anecdata that has made me question whether Google is a company whose products are worth investing in, gives a damn, etc.
As to what exactly about the iPhone seems so good in comparison, the things that really stand out are the crisp aesthetics (noticeably better "graphics" than my Samsung) and the speed of everything. It's also just pleasant to touch/interact with--I think part of that is Apple's craftsmanship, and part is simply the fact that the phone is new.
edit: just set it up and gave it a test--seems to work pretty well!
I don’t really use the Mac for gaming.
However, Apple Silicon may change the landscape
Sadly, this is a clear sign the project is going to stop working eventually. At some point, the Apple is simply going to pull the plug.
I remember doing similar tricks when I was a kid. Nowadays I simply won't even care trying. The problem clearly isn't supposed to be solved this way. I'm not even sure if it's a good exercise in programming either. Software development is about doing the things the right way, not exercising in futility.
A better experience would be writing your own message delivery solution, superior to iMessage.
This level of snark is undeserved, and a subtle amount of bitterness/jealousy leaks through.
Even if this stops working, this was a fantastic exercise to learn and practice reverse engineering.
"The problem clearly isn't supposed to be solved this way." No duh, there is no public iMessage API and not even the EU can make that happen. There is nothing wrong with *hacking* a solution to a problem.
"Software development is about doing the things the right way, not exercising in futility." LOL what? Okay thanks Agent Smith, have fun at your BigCo job installing Norton antivirus and pinging me about updating my laptop every 2 weeks.
For some, being a hacker is a fashion and a phase. Much like being a punk.
I agree in principle, but I’d try to avoid running afoul of the Computer Fraud and Abuse Act against one of the most deep-pocketed legal teams in the history of capitalism.
Extremely impressive work, but whether it’s worth the potential risk is another story, personally speaking.
> 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.
The binary being emulated was extracted from an old macOS version and is hosted on GitHub: https://github.com/JJTech0130/nacserver. Apple obviously holds the copyright on this binary, and issuing a takedown would be the easiest way to sink this project. I wonder if the Beeper Android app also includes the file, that would be legally problematic.
Not to be too harsh (maybe to be somewhat harsh given I had such a distaste for what you wrote?), but why would you post this on a site called Hacker News? I can't think of a better implementation of the "hacker ethos" than this project: look at a hard problem, and when the "straightforward" approach doesn't work, find a workaround.
More to your specific point about "Apple is simply going to pull the plug", there are technical and business reasons why they might not want to, at least not quickly. First, as mentioned in the other Beeper thread, there are lots of older Mac devices without a secure enclave, and breaking Beeper would likely break them as well. Second, from a business and regulatory perspective, Apple might have to do a careful dance regarding how to shut this down without looking blatantly anti-competitive.
Reverse engineering is a valuable art that can't be learned just from a canonical reference for "the right way". It cultivates the same skills used in debugging.
I strongly disagree on the first point, and mostly disagree on the second. The first point is antithetical to the hacker mindset.
Software development is about solving problems using computers and code. Some of the most interesting and impactful work I’ve done involved doing things the “wrong” way as a way to get people’s attention. Some of these prototypes raise awareness. Some of them become the precursor to a project that does things “right”. And sometimes, just getting something to work is the only thing that really matters.
Software development is also about trying things and seeing what works for the sake of learning about it. I’ve written tons of code that never made it to production, but the act of writing it taught me so much that the time was well spent.
> A better experience would be writing your own message delivery solution, superior to iMessage.
This completely misses the point. People don’t want a better experience. They just want to use iMessage on Android. They want to be part of the blue bubble group chats.
Building a new “superior” solution just creates another iteration of the current problem and solves nothing.
Sometimes you grow the most when doing things the way you aren’t supposed to.
May be infeasible, due to network effects
Is it a new trend ?
It's a wicked pain in the butt, but I finally got it. The trickiest part was the backend server, which I implemented in ... gasp PHP. I didn't want to load in a whole SaaS, in order to do a very simple push notification, so I had to learn to do it from scratch.
In the process, I learned that there's a lot of wrong information out there, and I had do quite a bit of trial and error.
But it works, and the code is actually wicked simple.
It’s just a fairly typical type of HN comment. I literally, like, yesterday, got it going, and it was a less-than-linear process. My own experience, in hacking the system, has taught me to try to stay inside the lines –something that is increasingly difficult, these days.
This article (which is excellent, and quite worthy of HN) made me think of it. Also, even doing what I did, has its challenges. I didn’t want to distract from the OP, by going into any detail. Maybe, one day, I’ll write it up (I’m fairly good at that kind of thing), but that is something for another day.
