iMessage, explained(jjtech.dev)
jjtech.dev
iMessage, explained
https://jjtech.dev/reverse-engineering/imessage-explained/
162 comments
My prediction is that Apple will start to use attestation (device check) to lock down iMessage. The problem is that this would require a software update for older devices.
They already partially do.
> 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_...
> 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_...
remote attestation would mean it's not possible to pull out the binary and run it externally
you'd need the key from the TPM/secure enclave too, which is much much harder to extract
you'd need the key from the TPM/secure enclave too, which is much much harder to extract
TPM did not get key from nowhere. The key need to come from network or locally generated as long as it is not preloaded when manufacturing. And in either way, it should be possible to intercept/fake it.
Apple devices with a secure enclave have the ability to attest to their identity, and also attest that keys were generated on a secure enclave (this functionality is very locked down for privacy preservation purposes, but is certainly available to Apple). If Apple is willing to lock out any device shipped without a secure enclave (which would probably be an excessive number of Macs at the moment - the iMac only started shipping with a T2 in the 2020 model, although the iMac Pro did have a T1 earlier than that) then it's absolutely possible to restrict access to actual Apple hardware with no risk of key interception.
> as long as it is not preloaded when manufacturing
which is exactly what happens
which is exactly what happens
It's only a matter of time until a company starts selling TPM dumps, right?
You can't "dump" a TPM. That's the whole point. They are designed such that the cryptographic secrets they hold (including ones loaded at manufacturing) are unrecoverable without an electron microscope and nation-state level resources (and even then, it would be extremely difficult if not impossible on modern process nodes).
> You can't "dump" a TPM.
> unrecoverable without an electron microscope and nation-state level resources (and even then, it would be extremely difficult if not impossible on modern process nodes).
Oh, so you can. It's only a matter of time.
> unrecoverable without an electron microscope and nation-state level resources (and even then, it would be extremely difficult if not impossible on modern process nodes).
Oh, so you can. It's only a matter of time.
Even with an electron microscope you wouldn't extract a root key it would just be a device key which they would then ban.
There's plenty that one would be able to do with a device key before it is banned.
maybe, but for a task like this it doesn't really scale
Apple aren't going to allow one phone to attest 5000 new iMessage clients
Apple aren't going to allow one phone to attest 5000 new iMessage clients
That's... amusingly, also a thing in Chinese marketplaces, for a similar purpose.
iCloud Activation Lock, on non-cellular devices (eg, Wi-Fi only iPads), relies on the device's serial number, Wi-Fi MAC, and Bluetooth MAC addresses as the three identifiers required to clear the Activation Lock check. Via special debug cables (eg, a "DCSD cable") there are ways to write in new SysCfg data to the flash to change those variables. This can also be done to Apple Watches (pre-Series 6) with a special dock also sold on the Chinese market.
You can (sort of easily) get your hands on a "clean" serial/MACs set for under $10-15 or so on the market.
iCloud Activation Lock, on non-cellular devices (eg, Wi-Fi only iPads), relies on the device's serial number, Wi-Fi MAC, and Bluetooth MAC addresses as the three identifiers required to clear the Activation Lock check. Via special debug cables (eg, a "DCSD cable") there are ways to write in new SysCfg data to the flash to change those variables. This can also be done to Apple Watches (pre-Series 6) with a special dock also sold on the Chinese market.
You can (sort of easily) get your hands on a "clean" serial/MACs set for under $10-15 or so on the market.
Interesting. I assume this is mostly used to "wash" stolen devices to make them appear legitimate for resale? I'm surprised Apple designed the hardware to allow this without any sort of authentication.
Apple already provides security updates to all iOS devices made in the last 5ish years at least, so it would probably take a pretty trivial number of years for them to have an update deployed to nearly all iOS devices that see active use.
The iPhone 5s (released ten years ago) received an update earlier this year.
It would require a hardware update for older devices I believe, ie any that don’t have TPMs
I think that is how BBM worked, but I could be wrong. I'd be surprised if it is part of the over arching OS security. Sounds like something that should be in their lockdown mode at the very least.
Maybe, but they also just announced RCS support: https://9to5mac.com/2023/11/16/apple-rcs-coming-to-iphone/ so maybe they've just decided that this is a good opportunity to take the charge opening things up.
Learning the contract is great, thank you for the work! How about the infra stack used by imessages? Does anyone have intel on that? The scale is incredible, which always makes me wonder how it can be so good while other apple web services (forums, dev portals, etc) can be so buggy and half baked
The actual mind-blowing scale is that Apple's push notification service isn't just carrying iMessages. It's also carrying push notifications for every third-party messaging app.
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?!
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?!
Centralized notifications is not a "genius solution", it is the "only possible solution" for power-constrained devices, if you think about it. Same thing applies to Android: in ideal world it keeps a single connection open to GCM servers to listen for notifications for ALL apps on the device, and then routes messages to the appropriate applications they are intended for.
I never said centralized notifications is conceptually a genius solution. I said actually building a system that can handle so many billion notifications is impressive. I'm curious how it works internally...
OMG I love this. Go get em! Also, this is perfect material for Hack Club. You should join! https://hackclub.com/
This is phenomenal work. You should write a little on how you got into this whole field. There are high school and college kids all over reddit struggling how to excel at technical stuff, learn programming, get a job in tech, and I feel like they can really benefit from your perspective.
I don't disagree with what you say, but I would be surprised if it was any sort of secret sauce and not "just" an incredible amount of grinding, the seemingly zero-cost energy reservoir you can tap into as a young adult if you really like what you're doing and possibly an enlightened parent or a role model.
> possibly an enlightened parent or a role model
This is typically the 'secret sauce'.
This is typically the 'secret sauce'.
I was once asked how I got to where I am, where others in my situation might not have, my response was: “Parents that gave a damn”. It wasn’t about pressuring me, it was about recognising my interest in computers, and fostering that interest as much as was financially possible given our circumstances (which were often dire). My parents aren’t technical, but they did what they could, and I wouldn’t be the engineer I am without that.
I grew up with a foster mother that actively "suppressed" what I did on the computer, banning me for a month if I didn't get changed immediately after school.
Now I've become a senior engineer, but I'm kinda shotty at it, chaotic good in solving problems, but issues with authority and process.
Who knows, maybe I would've became a "run of the mill" engineer if she helped.
Now I've become a senior engineer, but I'm kinda shotty at it, chaotic good in solving problems, but issues with authority and process.
Who knows, maybe I would've became a "run of the mill" engineer if she helped.
As an engineering manager I see problems with authority and process as something usually positive.
This usually leads to more things getting done “right” than “wrong”. IME.
Having the same issues/traits I’m not sure how that gets formed - my upbringing was limitless in many ways.
This usually leads to more things getting done “right” than “wrong”. IME.
Having the same issues/traits I’m not sure how that gets formed - my upbringing was limitless in many ways.
It's not grinding though. My highschool years were also super productive when it came to programming-related things, while I have seen most of my peers, aside from select few, really struggle despite their willingness. So maybe there is some secret sauce that can help others to get good a this. Maybe it's a mindset or attitude, etc...
I don't know. I definitely did grind programming a lot as a teenager and for a few years as a young adult. But the grinding was effortless to me. It was as if this type of activity was replenishing my energy reserves instead of making me tired. I rarely needed to take breaks and indeed frequently forgot to eat or sleep when deep in my sessions. So it wasn't a struggle at all, but it was still a grind I would say. Or maybe I am misunderstanding the word and it would be better to say it was a lot of time spent, at the very least.
I don't think anyone can do this, I think you need to have that connection with programming where it is harder resist it than it is to do the work. But it doesn't mean people like the author of the article have a secret sauce and them recounting their experience to their peers to inspire them isn't worth much to them as a result I would expect. It's the "draw the rest of the fucking owl" type a thing I think.
BTW I don't mean to say I was a super duper genius as a teenager for whom programming was like breathing. I refused to study anything, I only enjoyed discovering things myself and I had no direction in my programming knowledge collection at all. A more disciplined person would have beaten me easily, and many have. Despite the ease with which programming came to me I didn't do that much productive stuff. I was mostly just having immense amounts of fun and joy. I do feel a bit sad sometimes about not getting a bigger edge now, but realistically, when push comes to shove, I wouldn't change it anyway.
I don't think anyone can do this, I think you need to have that connection with programming where it is harder resist it than it is to do the work. But it doesn't mean people like the author of the article have a secret sauce and them recounting their experience to their peers to inspire them isn't worth much to them as a result I would expect. It's the "draw the rest of the fucking owl" type a thing I think.
BTW I don't mean to say I was a super duper genius as a teenager for whom programming was like breathing. I refused to study anything, I only enjoyed discovering things myself and I had no direction in my programming knowledge collection at all. A more disciplined person would have beaten me easily, and many have. Despite the ease with which programming came to me I didn't do that much productive stuff. I was mostly just having immense amounts of fun and joy. I do feel a bit sad sometimes about not getting a bigger edge now, but realistically, when push comes to shove, I wouldn't change it anyway.
Willingness is almost antithetical to having the motivation to grind in my mind. In order to do something persistently, you need to trade something for it, and often times you need to ignore the fact that the trade isn't worth it, or not have anything else competing for that attention in the first place; in otherwords, some level of compulsion as well as willingness.
It's the same with skateboarding, or any other interest that is difficult, time consuming, character building, and that requires obsession.
The defining characteristic of programming, as opposed to some others, is that it's complex and only intellectually demanding, whereas the others are some combination of physical and mental stress. People don't know how to navigate that from the beginning, but the ones who have the disposition to simply throw themselves at it regardless of failure, repeatedly, figure it out eventually.
The ones who actually succeed in a career of it are probably the ones who figured out how to dial it back as an obsession, and stop when they're 10hrs in to take a different approach.
It's the same with skateboarding, or any other interest that is difficult, time consuming, character building, and that requires obsession.
The defining characteristic of programming, as opposed to some others, is that it's complex and only intellectually demanding, whereas the others are some combination of physical and mental stress. People don't know how to navigate that from the beginning, but the ones who have the disposition to simply throw themselves at it regardless of failure, repeatedly, figure it out eventually.
The ones who actually succeed in a career of it are probably the ones who figured out how to dial it back as an obsession, and stop when they're 10hrs in to take a different approach.
"just" is doing a lot of work in this construction. Regardless what a person's constellation of privileges is, it always takes an incredible amount of grinding and that's pretty damn cool / laudable / praiseworthy all by itself.
The secret sauce has never been secret
The secret sauce has never been secret
That's my point.
In highschool I had basically all day to work on my own stuff. Finishing stuff early, free periods, and doing my own thing when I wasn't supposed to gave me all the time I needed to create and release an app in about 6 months. I was very productive.
[deleted]
Genuine question - can a topic really be `opertunistic` or is that author typo? I love these `referer`-type misspellings that become fossilized over generations
Unfortunately, there are many typos in my code :P
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...
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...
That "missing plural S in PascalCased (or camelCased) names" is something I see semi-often!
Congratulations on this amazing work :)
Congratulations on this amazing work :)
The code doesn't seem to use it, but I think it would be a misspelling by the author, as it's probably an integer code.
At the protocol level, they are indeed just integers:
https://theapplewiki.com/wiki/Apple_Push_Notification_Servic...
More on this: https://news.ycombinator.com/item?id=38531759
pypush, the open source project behind today’s developments in the iMessage reversing news, is licensed under MongoDB’s Server Side Public License and owned by Beeper (JJTech sold the rights to Beeper, per discord). Although this library is fantastic, I do think that the extremely copyleft license could have implications on where we see this used.
Time for some reverse reverse engineering.
> When making an IDS registration request, a binary blob called “validation data” is required. This is essentially Apple’s verification mechanism to make sure that non-Apple devices cannot use iMessage.
I wonder, will this be in violation of the EU's DSA and/or DMA once they are in force?
I wonder, will this be in violation of the EU's DSA and/or DMA once they are in force?
DSA and DMA do not magically grant you the permission to do whatever you want with Apple's servers, nor force they Apple into having to serve any particular valid response to the requests you make.
In whatever way Apple is going to comply with DSA and DMA, this ain't it.
In whatever way Apple is going to comply with DSA and DMA, this ain't it.
I don't know the legal text, but improving interop specifically between messaging services seems to be a goal of the DMA, according to the EU parliament [1]:
> 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...
> 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...
European regulations work on a policy level not on a technical level.
In other words, Apple having technical limitations isn’t illegal per se, Apple refusing to facilitate interoperability might be illegal (although future RCS adoption will meet the requirements).
The above assumes that iMessage meets the regulations threshold, which it currently doesn’t according to Apple based on user numbers, but that’s a different debate.
In other words, Apple having technical limitations isn’t illegal per se, Apple refusing to facilitate interoperability might be illegal (although future RCS adoption will meet the requirements).
The above assumes that iMessage meets the regulations threshold, which it currently doesn’t according to Apple based on user numbers, but that’s a different debate.
Especially now that iOS is getting RCS. First-party cross-platform iMessage is nothing more than a nerd’s pipe-dream.
And I’m completely fine with that.
And I’m completely fine with that.
Looking at the Beeper Mini announcement [1], they clearly state that a user doesn't need an Apple ID to register their phone number and send/receive iMessages. Also, they describe direct, device-to-Apple interactions.
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.
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.
I just downloaded Beeper Mini on my android phone and after giving me a fail error when trying to send an SMS to Apple to register my phone, it then popped up asking for my apple id.
Absolutely amazing work.
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.)
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.)
the fact that you're in high school is incredible. keep it up!
Not many make it that far!
It’s 2023 and I’m still really shocked how hard it is to download all your iMessages and archive or search through them.
Huh.
So Android's push notification service is built on their instant messenger (GTalk),
and Apple's instant messenger is built on their push notification service.
How cute.
How cute.
Note: Android doesn’t use GTalk for notifications anymore, and the GTalk servers don’t exist any more [1].
[1]: https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...
[1]: https://arstechnica.com/gadgets/2021/08/a-decade-and-a-half-...
A few days later, seems apple has begun locking down iMessage further
This is good. This iMessage back door would have allowed spoofing of phone numbers, hijacking sms from non iMessage users, and lots of spam
[deleted]
Gonna repeat myself since iMessage hasn't improved one bit after four years. I also added some edits since attacks and Signal have improved.
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...
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...
While I will definitely agree that Signal is more secure:
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.
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.
If third party client has optional E2EE, it's not exactly a merit to Apple, aside perhaps them not explicitly blocking such development.
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.
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.
> There is a newer version of the iMessage encryption (sometimes called "pair-ec") which uses ECIES.
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.
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.
> 7. iMessage allows undetectable key insertion attacks.
https://security.apple.com/blog/imessage-contact-key-verific...
https://security.apple.com/blog/imessage-contact-key-verific...
Whoa, nice to see there's some progression finally! It's weird the blog appears to discuss key insertion, but not MITM attacks. Is there an official source that explicitly states it protects from those too? Also if it's for MITM too, is there a TOFU warning or is it only for a changing fingerprint, and is the warning soft (BTW the fingerprint just changed) or hard (please accept the new keys/fingerprint)? Can you mark the fingerprints verified like in Signal?
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...
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...
Unfortunately I have no idea, or else I would've written a longer comment!
> It’s not really designed to be an encryption system as much as it is a text message system that happens to include encryption.
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."
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."
> iMessage uses RSA instead of Diffie-Hellman. This means there is no forward secrecy.
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/...
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/...
I didn’t realize signal was so secure. Is this common to ga even post quantum guarantees?
Could you please elaborate, I didn't quite catch what you meant.
I would like to point out how awesome it is that someone in high school is making this caliber of a post. I've thought at least a dozen times over the last 20 years how i would like to understand macOS internals, and this person is deconstructing it. well done!
Fully agree, but you're even burying the lede here. He didn't just write the blog post, he wrote pypush itself.
I have confirmed with him that he hadn't been born yet when Steve Jobs announced the first iPhone. I feel old.
[deleted]
Reverse engineering iMessage has been touted as some holy grail meme for what... 10+ years now?
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.
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.
[deleted]
I just got an iPhone for the first time, and it is a noticeably better device than my previous Android phones.
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.
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.
After my gaming computer started rebooting (probably needs a new power supply in order to hit peak power draw), I tried out my new M2 Pro for gaming again.
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 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.
Ehh yeah the prospect of using such patching software doesn't appeal, and I don't want to run the risk that games work poorly or not at all even with that kind of fiddling (which is something I abhor about Linux, so why would I want it on my expensive and supposedly superior Macbook).
Just want to throw out there that ~20 years ago I sometimes got better framerates in linux than windows on the same hardware for certain FPS games
Personally, the approach I took to this was just to game on consoles. In my personal experience, the upgrade cycle is far far better for me. I don't feel like I've missed anything as a result either.
But the internet keeps saying the iPhone is just marketing. /s
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’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 think Google does a good job with the Pixel line. I believe it is likely they are the 2nd most secure consumer phones after iPhone due to their quick updates and Google's good security record. The fact that I can easily side load apps on Android make it a much better, ad free experience for me.
Personally, for communication I never use a device platform specific/locked app/service. Maybe you could keep using the app(s) whatever you were.
I’m curious, what do you use then?
There are lots of choices depending on your community and desired feature set: whatsapp, fb messenger, instagram messenger, telegram, signal, discord, or the direct messaging features of other programs like Slack.
imessage is an outlier in that it also has a bidirectional link with SMS. I just read today that FB messenger used to have this (who knew?) but no longer does. My reading of the EU's complaint is that if imessage didn't have this feature they would not be in trouble since they'd be no different from the other services in being a silo. Weird!
imessage is an outlier in that it also has a bidirectional link with SMS. I just read today that FB messenger used to have this (who knew?) but no longer does. My reading of the EU's complaint is that if imessage didn't have this feature they would not be in trouble since they'd be no different from the other services in being a silo. Weird!
Unless I’m mistaken literally all of these services are locked down too, and few have E2E encryption…
iMessage is indeed “Apple-only” but the rest is on “all” platforms only for purely economical reasons, as much as iMessage is on Apple platforms only for the same reason.
At least iMessage falls back to SMS (soon RCS) when available, which is much more ubiquitous than the rest tbh…
If you truly want to avoid a lock down you should host your own messaging solution.
At least iMessage falls back to SMS (soon RCS) when available, which is much more ubiquitous than the rest tbh…
If you truly want to avoid a lock down you should host your own messaging solution.
I don't know why you're getting downvoted, but I'll throw my hat in this ring as well:
Some of those services require individual opt-in to turn on e2ee. Some of them don't support e2ee for group messaging. Of the services listed that do support e2ee, I have the most trust in Apple's (well, Signal's, but..) being "actually" [0] and "only" [1] end-to-end encrypted. The entire basis of that trust is the money they've spent positioning themselves in the market as a privacy-focused brand.
Meta runs three of the listed services (whatsapp, facebook messenger, instagram), and their positioning is not exactly "privacy-focused". I haven't looked into Telegram much, but I would want to at least understand how they generate revenue before trusting them. Neither Discord nor Slack are what I would call privacy-focused. Signal is probably better than iMessage in terms of how much I trust their company, their clients, and their protocol, but its adoption is so vanishingly small among my friends that I stopped asking people if they used it.
[0] I've seen services in the past [0a] that have tried to argue that as long as every link is encrypted from originating client through servers to destination client, or from originating client to destination server, then it's "end to end encrypted"
[0a] https://news.ycombinator.com/item?id=21528437
[1] that is, not only are message contents (and as much metadata as is feasible) encrypted such that the same ciphertext passes all the way through the system and the recipient's client can decrypt the ciphertext, but also 1. the intermediary service doesn't have a copy of the recipient's secret key and 2. the plaintext wasn't encrypted also to a public key belonging to the intermediary service or some other party.
edit This other comment https://news.ycombinator.com/item?id=38537444 talked sense into me -- Apple doesn't seem to have designed iMessage to keep up with the times, crypto-wise. There's a huge, aging installed base that admittedly gets updates more often than any other competitor in their space, but that still means that iMessage has to be able to talk to them. I guess this is similar to the deprecation of SSL 0.9 and TLS 1.0; browser vendors collectively decided to kill them when a low enough proportion of servers were using them, but I don't know if Apple would be willing to cut off the older devices to make things better for owners of newer ones.
Some of those services require individual opt-in to turn on e2ee. Some of them don't support e2ee for group messaging. Of the services listed that do support e2ee, I have the most trust in Apple's (well, Signal's, but..) being "actually" [0] and "only" [1] end-to-end encrypted. The entire basis of that trust is the money they've spent positioning themselves in the market as a privacy-focused brand.
Meta runs three of the listed services (whatsapp, facebook messenger, instagram), and their positioning is not exactly "privacy-focused". I haven't looked into Telegram much, but I would want to at least understand how they generate revenue before trusting them. Neither Discord nor Slack are what I would call privacy-focused. Signal is probably better than iMessage in terms of how much I trust their company, their clients, and their protocol, but its adoption is so vanishingly small among my friends that I stopped asking people if they used it.
[0] I've seen services in the past [0a] that have tried to argue that as long as every link is encrypted from originating client through servers to destination client, or from originating client to destination server, then it's "end to end encrypted"
[0a] https://news.ycombinator.com/item?id=21528437
[1] that is, not only are message contents (and as much metadata as is feasible) encrypted such that the same ciphertext passes all the way through the system and the recipient's client can decrypt the ciphertext, but also 1. the intermediary service doesn't have a copy of the recipient's secret key and 2. the plaintext wasn't encrypted also to a public key belonging to the intermediary service or some other party.
edit This other comment https://news.ycombinator.com/item?id=38537444 talked sense into me -- Apple doesn't seem to have designed iMessage to keep up with the times, crypto-wise. There's a huge, aging installed base that admittedly gets updates more often than any other competitor in their space, but that still means that iMessage has to be able to talk to them. I guess this is similar to the deprecation of SSL 0.9 and TLS 1.0; browser vendors collectively decided to kill them when a low enough proportion of servers were using them, but I don't know if Apple would be willing to cut off the older devices to make things better for owners of newer ones.
WhatsApp (this mostly - I live in India). SMS.
Telegram (2 groups). Discord (3 groups).
Signal (with 1 friend) and iMessage (with 2 friends) — these 2 apps are more of a hobby (a thing?), we four usually use WhatsApp.
I mean I could fight it or just fall line. I fought and lost :D
Notifications off for all.
Telegram (2 groups). Discord (3 groups).
Signal (with 1 friend) and iMessage (with 2 friends) — these 2 apps are more of a hobby (a thing?), we four usually use WhatsApp.
I mean I could fight it or just fall line. I fought and lost :D
Notifications off for all.
> Maybe you could keep using the app(s) whatever you were.
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.
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.
If you're already using Thunderbird as mail client, you can integrate Google Messages add-on [1] into Thunderbird app which I have been using happily for over a year without much trouble (sans the incoming texts notification feature). Seemingly this add-on has all features akin to the Google Messages Android app.
[1] https://addons.thunderbird.net/en-us/thunderbird/addon/googl...
[1] https://addons.thunderbird.net/en-us/thunderbird/addon/googl...
I've never comprehended the use of separate email clients, personally lol
I am from India - WhatsApp is messaging here. Scratch that - WhatsApp is communication here. So that’s not really a choice. Maybe you’d have the app for your region unless you’re from USA where I’ve heard it’s iMessage.
In Australia it's iMessage and FB Messenger, mostly. But that's also dependent on where you or your family is from: I came here from NZ, so iMessage/Messenger is normal, but my Indian friends use WhatsApp as a matter of course!
Here in Japan, if you don't use LINE, you won't have any friends. Absolutely no one uses SMS messaging for anything personal.
I am not sure there is anything comparable in the US to the way WhatsApp is used in other parts of the world. People just default use SMS texting in the US and Canada. A lot of people do have WhatsApp here though
> the iPhone is nudging me further to giving a Macbook/OSX a try one day,
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?
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?
My last phone was a Samsung Galaxy A50, and it was pretty good as far as the hardware went. But I felt that Android was bad; I couldn't help but notice that a number of the apps loaded very slowly and had other small glitchy issues. Nothing that would compel a person to switch phones, just a lot of mostly minor inconveniences, except for 2 that really stick out right now: the Android messages web app always had a hard time connecting to my phone even when the phone was clearly on, had the messages app open, and was connected to same wifi as my computer; and second, Chrome recently just started becoming unopenable (like it would open and then immediately close for some reason).
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.
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.
>the Android messages web app always had a hard time connecting to my phone even when the phone was clearly on, had the messages app open, and was connected to same wifi as my computer; and second, Chrome recently just started becoming unopenable (like it would open and then immediately close for some reason).
Those are definitely annoying and off putting. On my pixel 5 chrome always worked well (but I use other browsers), and messages app was trouble free...
Wonder if it was a problem with that model of phone you had.
But it's true, apples ecosystem is definitely a draw
Those are definitely annoying and off putting. On my pixel 5 chrome always worked well (but I use other browsers), and messages app was trouble free...
Wonder if it was a problem with that model of phone you had.
But it's true, apples ecosystem is definitely a draw
Windows Phone Link does support iMessage now.
Windows 11 only for iPhones. Sigh.
surprisedpikachu.gif
edit: just set it up and gave it a test--seems to work pretty well!
edit: just set it up and gave it a test--seems to work pretty well!
I don't believe they actually did any reverse engineering for Windows Phone Link. iOS makes SMS/iMessages available over Bluetooth as part of its support for the Message Access Profile [1], intended for sending messages using a car infotainment system. This requires a physical iOS device to be located in proximity of the Windows device.
[1]: https://support.apple.com/en-us/102842
[1]: https://support.apple.com/en-us/102842
It works... "ok" but doesn't handle group messages. I find sometimes it just doesn't connect. They do post frequent updates though so there's clearly an active team managing the app.
I love being able to easily send URLs and other copy+paste items to my iMessage contacts from Windows!
I love being able to easily send URLs and other copy+paste items to my iMessage contacts from Windows!
Not sure if that will ever improve.
I don’t really use the Mac for gaming.
However, Apple Silicon may change the landscape
I don’t really use the Mac for gaming.
However, Apple Silicon may change the landscape
Look into Beeper for iMessage support on Linux and Windows!
A much more major issue with Macs is planned obsolescence. It’s the only reason I am not buying any Macs.
My late-2013 MacBook Pro recently gave up the ghost. I'd used it daily in the ten years it worked. Are there other PC manufacturers who make laptops that are still useable after ten years?
Both desktop and laptop computers have been perfectly serviceable for that long for a while now. Computers are "good enough" for tbe overwhelming majority of tasks most users (note, most regular users, not the HN crowd) would throw at them
Desktops, I'd agree. My experience with most Windows laptops, non-Thinkpad class, is that they physically haven't been able to survive that long. Like, people rag rightly on the butterfly keyboard era of Macbook Pros, but until recently you'd see pretty drastic hinge or keyboard or touchpad or case failures on even fairly expensive laptops. Especially as you get into more slimline/ultrabook form factors; I've seen some really bludgeoned Dells and HPs in particular. (Though I liked my Spectre x360 aside from the party where it fell apart in normal everyday use.)
I recently took a 2012 rMBP out of rotation (~five years dedicated use, the last five intermittently as a Logic Pro workstation) and now it's a Kubernetes homelab node. But I took it out because Thunderbolt 3 now means I can just slot my M1 Max into my workspace and don't need a dedicated box; the keyboard, touchpad, hinge, screen, and case are all pristine, I didn't remove it due to hardware expiry.
I recently took a 2012 rMBP out of rotation (~five years dedicated use, the last five intermittently as a Logic Pro workstation) and now it's a Kubernetes homelab node. But I took it out because Thunderbolt 3 now means I can just slot my M1 Max into my workspace and don't need a dedicated box; the keyboard, touchpad, hinge, screen, and case are all pristine, I didn't remove it due to hardware expiry.
> other PC manufacturers who make laptops that are still useable after ten years?
my Lenovo Thinkpads are working great after 12 yrs, with 16G ram and disk upgraded to 4TB SSD
my Lenovo Thinkpads are working great after 12 yrs, with 16G ram and disk upgraded to 4TB SSD
I mean if we're playing anecdata, my spouse has been through 4 mac laptops in the same period, which have given up the ghost in various different ways.
Apple hardware is mediocre at best.
2020 MacBook Air with i5 is unbearably slow.
I have Samsung ATIV 700T with i5 from 2014 and it feels much faster than 2020 i5 MacBook.
You can now say that it is the problem with Intel and that M1-2-3 are so much better but I have some Intel i7 laptops from 2016 and 2021 and they also blow Intel Mac away in speed and reliability and are comparable in speed with M2 that is sitting next to 2020 Mac.
2 other older MacBooks are falling apart (2009 and G4) wheres even older Dells and comparable HPs are still feeling robust...and are used more than decrepit Apple hardware.
My 2013 MacBook lasted 9 years (I'd still be using it if the battery connector wasn't shot.) In my experience Mac's last a lot longer than my equivalent PC's, although w/ an initial premium of course.
And traditional PC makers have a problem with unplanned obsolescence. A lot of consumer hardware does not receive updates from the manufacturer after the device is off shelves.
> In order to generate the “validation data”, pieces of information about the device such as its serial number, model, and disk UUID are used.
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.
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.
"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."
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.
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.
I think the engineering on this project is a great step forward, I am not a lawyer but I think it’s possibly actually especially a step forward if Apple pulls the plug on this because it will add that much more ammunition to the case regulators have against Apple using their services as gatekeepers.
> "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."
For some, being a hacker is a fashion and a phase. Much like being a punk.
For some, being a hacker is a fashion and a phase. Much like being a punk.
> Even if this stops working, this was a fantastic exercise to learn and practice reverse engineering.
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.
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.
To me, the more concerning paragraph is the next one:
> 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.
> 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.
> 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.
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.
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.
I get it and it may be true in this case that Apple can too easily pull the plug, adversarial interoperability has a long history: https://www.eff.org/deeplinks/2019/06/adversarial-interopera...
The messaging space also had the amazing Adium client during the last round of messaging wars, and less amazing Trillian as reverse engineered clients distributed or sold. I for one am excited to see this space heating back up.
And Miranda and Kopete and more. Might have used them all at some point.
Trillian used to be amazing. It is up there in my memory as about as life changing as Winamp was for me personally.
I remember being jealous I couldn't use Trillian because I didn't have a way to pay for it. Running AIM, ICQ and MSN all at the same time.
Ah man, it was glorious. I was really just in awe at how I could talk to all my various friends in one app, regardless of which platform they were on. Such a great app. I recently went to the webpage for the app and see it's sort of a shell of its former self and is some sort of business tool now. Kind of a bummer, but such fond memories of how amazing it was back in the peak of the various instant messaging tools, before unlimited text messaging was an affordable option.
>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.
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.
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.
> Software development is about doing the things the right way, not exercising in futility.
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.
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.
wow, haven't read something this off-base ina while
[deleted]
devaiops9001(1)
More and more often, I see titles that are not capitalized.
Is it a new trend ?
Is it a new trend ?
I guess most of the people never knew the titles are different.
I was hoping this would explain why iMessage allows invisible messages and attachments. I really can't think of any reason why Apple would want to implement something like that, but they've been predictably used to infect devices.
If you are talking about malware, then there's no need for Apple to implement something like invisible messages. Malware essentially just exploits the parser, takes over execution, and never executes the code to display messages or puts them into the chat history.
This has nothing to do with the iMessage protocol itself. Invisible messages looks like a bug, as it depends on the current UI and rendering repercussions. May be if you file a bug on them they may respond.
I just got done adding APNs to one of my dashboard apps.
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 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.
The protocol between your backend server and Apple, and between Apple and the phone, are completely different. So this comment seems almost off-topic...
No, it’s not off-topic. I’m not claiming to have reverse-engineered that stuff (I have successfully reverse-engineered internal Apple tech in the past, and it hasn’t ended well. I’ve been writing Apple software, sometimes, at a fairly low level, for quite a while). I suspect there may be other reasons for the downvotes. It isn’t really something I’m losing much sleep over.
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.
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.