Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iMessage, explained

jjtech.dev

Post reply on HN
Print view View original

131–140 of 163 posts

Re: iMessage, explained

#131

Post by mmis1000 »

blibble wrote: post #86
kotaKat wrote: post #12

Earlier quoted context omitted.

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…

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

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.

Re: iMessage, explained

#132

Post by ChrisMarshallNY »

nicolas_17 wrote: post #118
ChrisMarshallNY wrote: post #76

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…

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.

Re: iMessage, explained

#133

Post by mjg59 »

mmis1000 wrote: post #131
blibble wrote: post #86

Earlier quoted context omitted.

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

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.

Re: iMessage, explained

#134

Post by stouset »

nicolas_17 wrote: post #126
CTmystery wrote: post #107

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. Chang…

> Just how many messages are going through that service every second?!

I’m confident in saying at least six.

Re: iMessage, explained

#135

Post by xwolfi »

stouset wrote: post #134
nicolas_17 wrote: post #126

Earlier quoted context omitted.

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. Chang…

> Just how many messages are going through that service every second?! I’m confident in saying at least six.

It's more than bitcoin !

Re: iMessage, explained

#136

Post by thomasahle »

bgorman wrote: post #2

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.

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.

Re: iMessage, explained

#138

Post by SpaceManNabs »

maqp wrote: post #67

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 clie…

I didn’t realize signal was so secure. Is this common to ga even post quantum guarantees?

Re: iMessage, explained

#140

Post by Lockal »

nicolas_17 wrote: post #126
CTmystery wrote: post #107

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. Chang…

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.
Post reply on HN