Jump to content

iMessage not working - iCloud/Internet etc working - Changed boot.plist file and network.plist file - Help

hamzab

By hamzab,
in OSx86 10.8 (Mountain Lion)

 Share
418 posts in this topic

Recommended Posts

rcork
rcork
Posted
Posted

It will contain an auth token in the plist, and you use that token when you generate a PEM-encoded CSR to send back to the service. This isn't going to fix your iMessage in one step, I'm trying to see where it is failing.

 

When iMessage talks to various web services it prepends some headers to the POST like:

 

 

x-ds-client-id: t:(hexadecimal string to identify software or computer/device)
x-protocol-version: 4
x-vc-profile-id: D:(the profile-id)
x-vc-auth-token: (the auth token)

 

So, for whatever reason, it seems likely that the ds-client-id that is generated by your virtual machine or Hac is probably failing, and it isn't widely known what the method used for generating that is. Or, some people have mentioned they have logs showing a failure here when it is successful in logging in.

 

when i execute the curl command you posted above i receive the xml formatted plist with the auth-token, profile-id and status keys. How can i check for the x-de-client-id?

  • Like 1
Link to comment
Share on other sites
iFIRE
iFIRE
Posted
Posted

I have the problem, FaceTime and App Store iTunes all is ok, but Messages not working

 

 

bash-3.2# curl --data-ascii @f https://service.ess.apple.com/WebObjects/VCProfileService.woa/wa/authenticateUser

Warning: Couldn't read data from file "f", this makes an empty POST.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>message</key><string>status = 5008, missing required key: username</string>

<key>status</key><integer>5008</integer>

</dict>

</plist>

bash-3.2#

Link to comment
Share on other sites
fffeee
fffeee
Posted
Posted

when i execute the curl command you posted above i receive the xml formatted plist with the auth-token, profile-id and status keys. How can i check for the x-de-client-id?

 

Your results are confirming that the issue lies entirely with the x-ds-client-id. Thank you for taking the time to test. As for how to check for the x-de-client-id, that's where we're going to be stuck. We don't even know why the one it was sending previously isn't valid after the Dec 18th maintenance that Apple did, or if this is intentional or an outage condition they are going to resolve.

 

The good news is that you're able to authenticate successfully and that the problem isn't at the account level. It is likely that the client-id is being calculated in a different way for some reason, but without further work I don't know that. If I can spend time today in layer 4 I'll do so and post my findings.

Link to comment
Share on other sites
rcork
rcork
Posted
Posted

I have the problem, FaceTime and App Store iTunes all is ok, but Messages not working

 

 

bash-3.2# curl --data-ascii @f https://service.ess....uthenticateUser

Warning: Couldn't read data from file "f", this makes an empty POST.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!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 = 5008, missing required key: username</string>

<key>status</key><integer>5008</integer>

</dict>

</plist>

bash-3.2#

 

Change @f to @[name of plist]. For example, i copied the xml from @fffeee's post into a file named imsg.plist. Then the command is curl --data-asci @imsg.plist .....

Link to comment
Share on other sites
fffeee
fffeee
Posted
Posted

…

Warning: Couldn't read data from file "f", this makes an empty POST.

…

bash-3.2#

 

You aren't doing it right. The file you reference needs to contain a plist with your credentials. If you aren't clear what you're doing, it's fine, you don't need to help and what you get back will not get you on iMessage anyway, it's just to confirm where the issue lies.

 

And for the love of god, don't run random curl commands as root ;)

 

One thing that may be interesting is that I can get iMessage on my Hac to enumerate the email addresses associated with the account. That doesn't appear to require a valid x-ds-client-id though, but does explain why I can successfully login to iCloud on my Hac, and then initiate the login to iMessage and see it list my email addresses before it fails to register. Getting a list of email addresses for an AppleID doesn't require that string.

Link to comment
Share on other sites
eep357
eep357
Posted
Posted

I'm also seeing the push service making a connection too x.courier.sandbox.push.apple.com which I've not seen before. Connection to x.courier.push.apple.com is part of token/auth but what's up with the sandbox one? Is same seen on real Mac?

--------------------------------------------------------------------------

what needs to be done, preferably on real Mac first: after patching applepushserviced, editing hosts file and extracting a valid cert from keychain is seting up a middle-man proxy server which requires redirecting push connections to your server and setting up X.509 certificates for SSL authentication.

The push protocol uses SSL for client and server authentication. You need to extract the valid certificate and give it to the proxy so it can authenticate itself as valid Mac against Apple. You also need to make the Mac trust your proxy since you are impersonating Apple's servers.

The above info and tools to create proxy and extract certs, edit host file etc. is all at https://github.com/meeee/pushproxy. It's primarily focused on iOS but includes everything for OSX too.

Link to comment
Share on other sites
fffeee
fffeee
Posted
Posted

I'm also seeing the push service making a connection too x.courier.sandbox.push.apple.com which I've not seen before. Connection to x.courier.push.apple.com is part of token/auth but what's up with the sandbox one? Is same seen on real Mac?

 

That happens all the time; APN can be used by just about anything and doesn't appear to be related to the iMessage registration or initialization process. Yes it will probably use your Token and yes, it probably has your AppleID (it's just XMPP traffic after all) but I don't think it's involved in our iMessage problem.

 

I have mitm'ed successful iMessage registrations from my rMacBookPro10,1 and a MacMini5,3 and don't have a Hac available until I get home to compare, but I'll be able to see what my Hac is sending for a client-id if anything and if it's even resembling what my Macs send.

 

I don't know where to begin figuring out how it builds an x-ds-client-id that is way out of my league. I'm not willing to share my x-ds-client-ids from my Macs either since they're apparently uniquely identifying in some way. Worst case scenario is using a proxy to intercept and replace bad data with good data, but that is too fiddly and I'd rather just not have iMessage on my Hac than have to deal with that nonsense.

 

FWIW I'm using mitmproxy to observe/record and play back my iMessage sessions. Talking about how to do that is out of scope for this conversation but if you're comfortable with tools like tcpdump and can install python modules you can probably get it rolling on your own.

  • Like 1
Link to comment
Share on other sites
eep357
eep357
Posted
Posted

@fffeee: aren't virtualized OSX's only Apple supported when running from Mac which is running OSX server?

 

That happens all the time; APN can be used by just about anything and doesn't appear to be related to the iMessage registration or initialization process. Yes it will probably use your Token and yes, it probably has your AppleID (it's just XMPP traffic after all) but I don't think it's involved in our iMessage problem.

 

I have mitm'ed successful iMessage registrations from my rMacBookPro10,1 and a MacMini5,3 and don't have a Hac available until I get home to compare, but I'll be able to see what my Hac is sending for a client-id if anything and if it's even resembling what my Macs send.

 

I don't know where to begin figuring out how it builds an x-ds-client-id that is way out of my league. I'm not willing to share my x-ds-client-ids from my Macs either since they're apparently uniquely identifying in some way. Worst case scenario is using a proxy to intercept and replace bad data with good data, but that is too fiddly and I'd rather just not have iMessage on my Hac than have to deal with that nonsense.

 

FWIW I'm using mitmproxy to observe/record and play back my iMessage sessions. Talking about how to do that is out of scope for this conversation but if you're comfortable with tools like tcpdump and can install python modules you can probably get it rolling on your own.

I think an intercept proxy is needed, at least until enough info is gathered on x-ds-client-ids. With all this and new experimental GPU, I'm officially back in testing mode which makes having my install on RAID-0 a huge PITA(for example can't boot with -x or -f) and non-SSD so slow I want to cry, ergo I will break my array, update sandforce firmware while I have the chance, and do two fresh SSD install's to begin experimenting with.
Link to comment
Share on other sites
fffeee
fffeee
Posted
Posted

If I were in your position I'd not sweat iMessage, you have enough on your plate ;) I'm dealing with some new storage shenanigans myself.

 

I did watch iMessage in dtrace enough to see that it does write a 40 byte value into keychain at least temporarily, which may be the client-id, but I can't find any occurrence of the values of mine in the keychain files afterwards.

 

Also I noticed that before it writes 40 bytes of data to keychain, it generates a series of random data using DevRandomGenerator. 16bytes, then 8bytes, then 8bytes, and a final 8bytes. Could that be where the 40byte client-id is generated? Maybe! Is it actually making a random string for that? Maybe! More likely is that it is using some sort of cipher against a known value to calculate those bits, I suspect. May be helpful to someone that it's 16, 8, 8, and 8 though.

 

@fffeee: aren't virtualized OSX's only Apple supported when running from Mac which is running OSX server?

 

Yes, but those don't work either. (Confirmed on my MacMini5,2)

 

what needs to be done, preferably on real Mac first: after patching applepushserviced, editing hosts file and extracting a valid cert from keychain is seting up a middle-man proxy server which requires redirecting push connections to your server and setting up X.509 certificates for SSL authentication.

…

 

FWIW I think this is the wrong path to take. I don't believe APN is involved in this at all, my use of dtrace and mitmproxy to hijack the https sessions that iMessage/imagent makes doesn't give me any reason to believe APN is even used by registration or initialization. I'm not an expert on undocumented APIs or anything, though. I don't intend to discourage someone from attempting it anyway, but I don't know how that will help anyone figure out how a client-id is being generated, and that is absolutely where this process is breaking down.

 

Sorry for my ninja-edits on my last post, I didn't realize it was re-quoting into my previous post.

Link to comment
Share on other sites
rcork
rcork
Posted
Posted

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.

  • Like 1
Link to comment
Share on other sites
rcork
rcork
Posted
Posted

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

 

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/

  • Like 1
Link to comment
Share on other sites
eep357
eep357
Posted
Posted

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?

Link to comment
Share on other sites
fffeee
fffeee
Posted
Posted

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)

 

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.

Link to comment
Share on other sites
rcork
rcork
Posted
Posted
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.

Link to comment
Share on other sites
eep357
eep357
Posted
Posted

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

Link to comment
Share on other sites
eep357
eep357
Posted
Posted

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###

Link to comment
Share on other sites
fffeee
fffeee
Posted
Posted

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.

Link to comment
Share on other sites
eep357
eep357
Posted
Posted

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!" :wallbash:

Link to comment
Share on other sites
ZackehSoul
ZackehSoul
Posted
Posted

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.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...