I don't give a f#%k about the color of my messages but being able to see them from a website/windows desktop would be useful. This doesn't achieve that.
> I do now have a fully working iMessage client that runs on Windows and sends messages via an up-to-date macOS High Sierra installation running on my rMBP.
Are iMessage communications signed with an apple device specific key?
I imagine part of the reason that it has proven to be so difficult to reverse engineer, is that it somehow utilises an apple devices secure enclave?
It uses some combination of the serial number and the NIC (at least on Macs, probably not on iOS) to authenticate with Apple. That's why it's fiddly on Hackintoshes.
They couldn't use the enclave because not all currently supported Macs have it, but maybe in 10 years when all of the old ones fall off the support tree.
The "always on mac functioning as a proxy server" is the same type of solution that the author spent the entire article figuring out how to implement. The only time he mentions the proxy server as something to be avoided is when the he talks about not wanting to be forced to run that proxy server on an older version of OSX.
> But I wanted to do this and I wanted to do it right. I wanted an elegant approach that I could deploy on the same machine I still used from time to time, without being stuck on an ancient (and insecure) legacy version of OS X that could suddenly be blocked from the iMessage network at any point.
Android only.
I don't give a f#%k about the color of my messages but being able to see them from a website/windows desktop would be useful. This doesn't achieve that.
This software requires a server component to be run on a mac. It's not self-contained.
So does the one in the article.
Doesn't this solution as well?
> I do now have a fully working iMessage client that runs on Windows and sends messages via an up-to-date macOS High Sierra installation running on my rMBP.
Are iMessage communications signed with an apple device specific key? I imagine part of the reason that it has proven to be so difficult to reverse engineer, is that it somehow utilises an apple devices secure enclave?
It uses some combination of the serial number and the NIC (at least on Macs, probably not on iOS) to authenticate with Apple. That's why it's fiddly on Hackintoshes.
They couldn't use the enclave because not all currently supported Macs have it, but maybe in 10 years when all of the old ones fall off the support tree.
This appears to be the option he didn't want to use, an always on mac functioning as a proxy server.
The "always on mac functioning as a proxy server" is the same type of solution that the author spent the entire article figuring out how to implement. The only time he mentions the proxy server as something to be avoided is when the he talks about not wanting to be forced to run that proxy server on an older version of OSX.
> But I wanted to do this and I wanted to do it right. I wanted an elegant approach that I could deploy on the same machine I still used from time to time, without being stuck on an ancient (and insecure) legacy version of OS X that could suddenly be blocked from the iMessage network at any point.
No API for airmessage?