406 replies to this topic

[rcork]

I got mitmproxy running on my hack and my retina MacBook Pro so I can start to do some comparisons between the two. Thinking outside the box, the only difference physically from our hacks and real macs is the EFI bios containing the smbios data and the SMC chip.  Seems like we should be able to inject smbios data or SMC keys if that is what apple is using to identify real macs.

[fffeee]

Right on, is your client-ID on your MacBookPro10,x also 40 characters long?

[eep357]

maybe coincidence, but still odd this was posted on 12/18 http://support.apple.com/kb/HT1237

[rcork]

fffeee, on 31 December 2012 - 11:11 PM, said:

Right on, is your client-ID on your MacBookPro10,x also 40 characters long?

Yes it's 40 characters (not going to publish here for obvious reasons).

[rcork]

Ok, did a little more digging with mitmproxy and here's what i've found. I don't believe it's a problem with x-ds-client-id. My hackintosh has a value in this field in the headers. The sequence of service calls is different than on my retina macbook pro.

Sequence on rMBP:
authenticateUser -> getDefaultInvitationContext -> validateHandle -> idsProvisionEmails -> register -> getDependentRegistrations -> getHandles

Sequence on hack:
authenticateUser -> getHandles -> validateHandle -> idsProvisionEmails -> cert-1.0.plist (GET) -> initializeValidation -> register

After the call to the register service it then repeats the cert-1.0, initializeValidation and register call three more times. After the third time, iMessage gives me the usual server encountered error message.

There are a few interesting things here. First, there's a GET method to http://static.ess.ap.../cert-1.0.plist which returns a plist containing certificate data.  Not sure what it's being used for. Then the initializeValidation method is called (which is not called on the macbook pro). The request passes the key "session-info-request" and receives data for "session-info". The next call is register and it returns the following response


<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com...yList-1.0.dtd">
<plist version="1.0">
<dict>
<key>message</key>
<string>status = 5080, Messages Beta is closed</string>
<key>status</key>
<integer>5080</integer>
</dict>
</plist>


I never used iMessages during the beta period so i never researched how people got around this problem when apple disabled Messages on Lion. Maybe that solution would work now?

UPDATE: I just found this article online that said Apple had communicated that Messages Beta would be discontinued on December 14th. That seems to line up with when people starting having this problem

Quote

Apple has announced in recent emails to users that support for this program will end on Friday, December 14.

http://reviews.cnet....on-december-14/

[eep357]

Yup, no "got around" iMessage beta not working in Lion. My macbook 2,1 won't run ML without hacking gma950 drivers and I would rather have iMessage on it than anything else , seems hack was/are using the method as the beta?

[fffeee]

This would indicate that the problem isn't something Apple is actively doing, if our Hacs are sending the wrong sequence for login.  We get valid authenticate users and then Hacs are sending the wrong bits next.  That would fit with the error indicating that the iMessage beta is closed, for whatever reasons we haven't been doing iMessage correctly.  Is the response to authenticateUser roughly the same in both cases?  There isn't a change in what the response is?  (IIRC it just hands back the token)

rcork, on 01 January 2013 - 03:28 AM, said:

Sequence on rMBP:
authenticateUser -> getDefaultInvitationContext -> validateHandle -> idsProvisionEmails -> register -> getDependentRegistrations -> getHandles

Sequence on hack:
authenticateUser -> getHandles -> validateHandle -> idsProvisionEmails -> cert-1.0.plist (GET) -> initializeValidation -> register

How strange!  I'm going to see if I can dig anything up in the Chameleon commit logs about iCloud/iMessage fixes that have been done over the last year.  I remember there were some fixes done regarding iCloud services.

[rcork]

fffeee, on 01 January 2013 - 04:20 AM, said:

This would indicate that the problem isn't something Apple is actively doing, if our Hacs are sending the wrong sequence for login.  We get valid authenticate users and then Hacs are sending the wrong bits next.  That would fit with the error indicating that the iMessage beta is closed, for whatever reasons we haven't been doing iMessage correctly.  Is the response to authenticateUser roughly the same in both cases?  There isn't a change in what the response is?  (IIRC it just hands back the token)



How strange!  I'm going to see if I can dig anything up in the Chameleon commit logs about iCloud/iMessage fixes that have been done over the last year.  I remember there were some fixes done regarding iCloud services.

For the calls that are common, the responses are structurally the same with different data for the fields but nothing to indicate that the hack is being recognized differently.

[eep357]

Here's my Hack, the Certs are http. Will see what iPad does next.

POST https://service.ess.apple.com/WebObjects/VCProfileService.woa/wa/getHandles
	 ← 200 application/x-apple-plist 297B
POST https://service.ess.apple.com/WebObjects/VCProfileService.woa/wa/getHandles
	← 200 application/x-apple-plist 297B										
POST https://service.ess.apple.com/WebObjects/VCProfileService.woa/wa/idsProvisionEmails
	 ← 200 application/x-apple-plist 1.26kB
GET http://static.ess.apple.com/identity/validation/cert-1.0.plist
	 ← 200 text/plain 3.39kB
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/initializeValidation
	 ← 200 application/x-apple-plist 984B
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/register
	← 200 application/x-apple-plist 255B
GET http://static.ess.apple.com/identity/validation/cert-1.0.plist
	 ← 200 text/plain 3.39kB
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/initializeValidation
	 ← 200 application/x-apple-plist 983B
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/register
	← 200 application/x-apple-plist 255B										
GET http://static.ess.apple.com/identity/validation/cert-1.0.plist
	 ← 200 text/plain 3.39kB
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/initializeValidation
	 ← 200 application/x-apple-plist 981B
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/register
	← 200 application/x-apple-plist 255B										
GET http://static.ess.apple.com/identity/validation/cert-1.0.plist
	 ← 200 text/plain 3.39kB
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/initializeValidation
	 ← 200 application/x-apple-plist 983B
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/register
	← 200 application/x-apple-plist 255B

Signing out on iPad (first 4 up to "deregister") then signing back in:

GET http://init.ess.apple.com/WebObjects/VCInit.woa/wa/getBag?ix=1
	 ← 200 text/xml 3.91kB
GET http://static.ess.apple.com/identity/validation/cert-1.0.plist
	 ← 200 text/plain 3.39kB
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/initializeValidation
	 ← 200 application/x-apple-plist 432B
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/deregister
	← 200 application/x-apple-plist 215B									
POST https://service.ess.apple.com/WebObjects/VCProfileService.woa/wa/idsProvisionEmails
	 ← 200 application/x-apple-plist 253B
POST https://service.ess.apple.com/WebObjects/VCProfileService.woa/wa/authenticateUser
	 ← 200 application/x-apple-plist 808B
POST https://service.ess.apple.com/WebObjects/VCProfileService.woa/wa/idsProvisionEmails
	 ← 200 application/x-apple-plist 1.26kB
GET http://static.ess.apple.com/identity/validation/cert-1.0.plist
	 ← 200 text/plain 3.39kB
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/initializeValidation
	 ← 200 application/x-apple-plist 432B
POST https://service2.ess.apple.com/WebObjects/TDIdentityService.woa/wa/register
	← 200 application/x-apple-plist 1.39kB
GET http://init-p01md.apple.com/bag
	 ← 200 application/x-apple-plist 6.38kB
>> GET https://service1.ess.apple.com/WebObjects/TDIdentityService.woa/wa/query?uri=m
	ailto%3Amyemail%40me.com
	 ← 200 application/x-apple-plist 915B

[eep357]

And for both ipad and hack the register requests are the same other than the actual data, only difference is when we get to the response on Hack it gives the iMessage beta is closed response already noted above and then on ipad it gives:

<plist version="1.0">
<dict>
<key>identities</key>
<array>
	 <dict>
	 <key>revision</key>
	 <string>medium sting of numbers and stuff</string>
	 <key>uri</key>
	 <string>mailto:myemaildude@bitchen.com</string>
	 <key>cert</key>
####certstringhere###

[eep357]

I'd wager the x-ds-client-id that's being used is based on this company's tech http://www.xdsnet.ne...escription.html

[fffeee]

I don't think so; that product is essentially file transfer glue.  

FWIW my personal belief is that they're using SAML to handle federated authentication and SSO for iCloud.  It would also explain how they let you reset passwords on a Mac using your iCloud account among other things (like the tokenization of login credentials we're seeing in this thread — Mail.app doesn't send your password to iCloud.com IMAP servers anymore, it uses that tokenization process).  The use of 'ds' as part of the device-id attribute prefix is common in SAML applications, because ds: stands for the W3C XML signature namespace, XMLSig-XSD.

Just a (somewhat) educated guess.

[eep357]

They have a whole suite of enterprise apps for managing iOS and OSX clients and their device identification on a network that include messaging, voip, file transfer, etc, etc. It would be right up their alley, but of course that doesn't mean they have anything to do with it either, especially since Apple likes to keep things in house. Regardless, the Lion beta error must be coming from somewhere, since only ML has Messages now and only 64bit EFI Macs can run ML,  does Clover with a straight 64bit UEFI boot work by chance? I know Clover's not a fix for anyone as far as I've heard, but if there is any config that does work...Just throwing some random thoughts out there at this point as manipulating the the auth via proxy would be way more trouble than it's it worth, and it's better than a 20 page thread full of "mine's broke too!"

[ZackehSoul]

fffeee, on 31 December 2012 - 05:58 PM, said:

Your results are confirming that the issue lies entirely with the x-ds-client-id.  Thank you for taking the time to test.

I got the same info as rcork on both Mac hardware running a working iMessage, and a Hack running a failed one.

[mike5065]

eep357, on 02 January 2013 - 12:53 AM, said:

...does Clover with a straight 64bit UEFI boot work by chance? I know Clover's not a fix for anyone as far as I've heard, but if there is any config that does work...

This post that I've also been following suggests the problem lies with Clover as well.

[techfreak85]

Could it be a FakeSMC issue?

[dtcalvin]

i changed the serialNO and hardware uuid of real mac，but it still did not work。。。。

[fffeee]

This issue is actually indicating to me that some very dramatic changes are coming.  It's very exciting to me that computing is on the verge of such an evolution.

[ZackehSoul]

techfreak85, on 02 January 2013 - 07:46 AM, said:

Could it be a FakeSMC issue?

Nah, don't have it on my installation - and it doesn't use that data as people have faked the info properly and still no-go.

[fffeee]

ZackehSoul, on 02 January 2013 - 07:12 PM, said:

Nah, don't have it on my installation

wat?  Is that a thing now?  Are you using some ancient DSMOS hack?