406 replies to this topic

[eep357]

nvram -x -p will give current non-sudo'd variables in xml format, here's example from real mac where my hack just has bluetooth, volume and computer name. I just took pic of it in plist editor cause it was easier to see and for me to cross out a couple personal bits. The "fmm-mobileme-token-FMM" variable has my email, an icloud server address, my name, etc. all included in it. The platform-uuid is exactly the same as my hardware-uuid in system profle. Since it's an older mackbook 2,1 it has "00000000 00001000 800000" followed by my ethernet mac address. Does anyone know if any macs that can run ML still use this older format for UUID? Changed values can be maintained by using rc.shutdown.local file in /private/etc/, I helped p.H do this to keep backlight brightness from resetting on each reboot but would need to refresh my memory(the one in my head) on any further details
 Untitled.jpg   90.01K   181 downloads

the fact that there's a freakin push token in there may be the key
Slice already included the rc.shutdown.local to keep nvram settings in a version of Clover(not sure if in current release) so once variables are set they should stick when reloaded at boot with a launch daemon

[Pene]

@eep357: nvram outputs only a very partial list of vars.

To actually output all your vars you would need to use a tool such as dmazar's DumpUefiCalls: http://www.projectos...indpost&p=23766
I added there a recent compile, with instructions how to use on real Macs.

[G5rocks]

eep357, on 03 January 2013 - 08:33 PM, said:

The platform-uuid is exactly the same as my hardware-uuid in system profle. Since it's an older mackbook 2,1 it has "00000000 00001000 800000" followed by my ethernet mac address. Does anyone know if any macs that can run ML still use this older format for UUID?

Yes iMac 7,1 (late 2007, the first aluminium iMac) uses 00000000 00001000 800000 MAC address as UUID - iMac 7,1 is the oldest iMac supported by Mountain Lion.

[Pene]

G5rocks, on 03 January 2013 - 08:57 PM, said:

Yes iMac 7,1 (late 2007, the first aluminium iMac) uses 00000000 00001000 800000 MAC address as UUID - iMac 7,1 is the oldest iMac supported by Mountain Lion.

Same for MBP3,1 which is also supported by ML.

[Trauma!]

Not on 2011 Macbook Air.

[rcork]

Pene, on 03 January 2013 - 08:51 PM, said:

@eep357: nvram outputs only a very partial list of vars.

To actually output all your vars you would need to use a tool such as dmazar's DumpUefiCalls: http://www.projectos...indpost&p=23766
I added there a recent compile, with instructions how to use on real Macs.

Can this be used to dump calls during runtime? From the DumpUefiCalls.inf file it sounds like you can only dump runtime calls in a virtual machine. Ideally we would like to watch the calls during the iMessage authorization to see what it's accessing.

[ZackehSoul]

fffeee, on 03 January 2013 - 09:44 AM, said:

I think you've misunderstood what rcork was saying about missing keys.  I think he's referring to the fact that there are dozens(?) of values in the SMC that aren't documented or are otherwise unknown.  When you enable debug logging you'll see several things OS X requests from the non-existent SMC that FakeSMC doesn't have an answer for.  It seems unlikely that people are spamming the right data into undocumented and unknown values with any hope of success.

I know what he's talking about (unless there are two issues in FakeSMC which are similar), I'm merely saying that others said they have attempted to get around that issue. How? I don't know, but I trust they knew what they were doing.

flux84, on 03 January 2013 - 06:53 PM, said:

As mentioned, setting those nvram values after being booted, even if you restart imagent, doesn't seem to have any effect.

If there is a way to get Chameleon/Chimera to set nvram values on boot, I have a real MacPro3,1 running ML to get values from to match my MacPro3,1 Hack to.

You can do this using an ML VM, the nvram values are set upon VM startup - could be a way to test it before bothering working out how to do it on Chameleon etc?

[flux84]

ZackehSoul, on 03 January 2013 - 10:43 PM, said:

You can do this using an ML VM, the nvram values are set upon VM startup - could be a way to test it before bothering working out how to do it on Chameleon etc?

I think I still have a 10.8.1 VM kicking around - if I can dig it up tonight I'll try a few things out.

[DavidMIRV]

Was the curl request ruled out ? I just want to chime in and add when I did that (curl --data-ascii @im  https://service.ess....nticateUser     login info in 'im' file) I got a valid auth-token and no error. But yet I cannot login to imessage. it gives that empty request error

1/3/13 3:19:04.292 PM Messages[3594]: [Warning] Empty account query with service: iMessage

[rcork]

DavidMIRV, on 03 January 2013 - 11:22 PM, said:

Was the curl request ruled out ? I just want to chime in and add when I did that (curl --data-ascii @im  https://service.ess....nticateUser���� login info in 'im' file) I got a valid auth-token and no error. But yet I cannot login to imessage. it gives that empty request error

1/3/13 3:19:04.292 PM Messages[3594]: [Warning] Empty account query with service: iMessage

The error seems to lie with the register call. That is where the error is returned.

[Pene]

rcork, on 03 January 2013 - 10:41 PM, said:

Can this be used to dump calls during runtime? From the DumpUefiCalls.inf file it sounds like you can only dump runtime calls in a virtual machine. Ideally we would like to watch the calls during the iMessage authorization to see what it's accessing.

I'm not sure actually. I asked dmazar in the DumpUefiCalls thread.

DavidMIRV, on 03 January 2013 - 11:22 PM, said:

1/3/13 3:19:04.292 PM Messages[3594]: [Warning] Empty account query with service: iMessage

That one sometimes gives the impression that it could be some kind of bug in iMessage.
I might be mistaken, but I think I didn't get that error if I skipped the initial wizard (Not Now -> Skip -> Not Now), and set the account in Messages->Preferences->Accounts. In any case, the behaviour of iMessage and its error messages were much more consistent for me when setting the account in the latter.
Do you get the same error if you set it there?

[flux84]

flux84, on 03 January 2013 - 10:49 PM, said:

I think I still have a 10.8.1 VM kicking around - if I can dig it up tonight I'll try a few things out.

Seems that the MLB and ROM variables are volatile and set by EFI upon boot, even in a VM.  Other variables save and get restored without issue, but not these.

[dwmc]

For what it's worth, if I delete fmm-mobileme-token-FMM ('sudo nvram -d fmm-mobileme-token-FMM'), I'm still able to login to iMessage and the variable does not reappear in NVRAM.  However, some funky stuff happens with iCloud... I got an error when trying to sign out of iCloud after deleting it, but it succeeded on the second attempt.  Signing back in to iCloud re-instantiates the token in NVRAM, with different contents (new token).  This is on an Early 2009 17" MacBook Pro.

Given that I'm not clued in to all that's passed back and forth and cached between various things such as imagent and apsd, this may or may not be helpful.  I'll do some more digging.

[DavidMIRV]

Pene, on 04 January 2013 - 12:14 AM, said:

I'm not sure actually. I asked dmazar in the DumpUefiCalls thread.


That one sometimes gives the impression that it could be some kind of bug in iMessage.
I might be mistaken, but I think I didn't get that error if I skipped the initial wizard (Not Now -> Skip -> Not Now), and set the account in Messages->Preferences->Accounts. In any case, the behaviour of iMessage and its error messages were much more consistent for me when setting the account in the latter.
Do you get the same error if you set it there?

Even If I skip I get the same sequence of events in the syslog - I completely cleared out all the messages settings ..

1/3/13 5:46:20.405 PM Messages[9263]: [Warning] Empty account query with service: iMessage
1/3/13 5:46:20.931 PM com.apple.SecurityServer[17]: Session 100032 created
1/3/13 5:46:34.528 PM imagent[9260]: [Warning] *** Listener ID: com.apple.mail  does not have capability: (Status), not allowing request
1/3/13 5:46:34.529 PM imagent[9260]: [Warning] 1   IMFoundation						0x00007fff8b76abe2 IMLogBacktraceToDepth + 69
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 2   imagent							 0x000000010025fde8 imagent + 81384
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 3   imagent							 0x0000000100260f6a imagent + 85866
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 4   CoreFoundation					  0x00007fff8dcc263c __invoking___ + 140
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 5   CoreFoundation					  0x00007fff8dcc24d7 -[NSInvocation invoke] + 263
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 6   CoreFoundation					  0x00007fff8dcc26a9 -[NSInvocation invokeWithTarget:] + 57
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 7   IMFoundation						0x00007fff8b7675d5 im_local_object_peer_event_handler + 7128
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 8   IMFoundation						0x00007fff8b7676b3 im_local_object_peer_event_handler + 7350
1/3/13 5:46:34.530 PM imagent[9260]: [Warning] 9   IMFoundation						0x00007fff8b767767 im_local_object_peer_event_handler + 7530
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 10  Foundation						  0x00007fff8c094677 __NSThreadPerformPerform + 225
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 11  CoreFoundation					  0x00007fff8dc4e101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 12  CoreFoundation					  0x00007fff8dc4daed __CFRunLoopDoSources0 + 445
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 13  CoreFoundation					  0x00007fff8dc70dc5 __CFRunLoopRun + 789
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 14  CoreFoundation					  0x00007fff8dc706b2 CFRunLoopRunSpecific + 290
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 15  Foundation						  0x00007fff8c09c89e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 268
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 16  Foundation						  0x00007fff8c03518a -[NSRunLoop(NSRunLoop) run] + 74
1/3/13 5:46:34.531 PM imagent[9260]: [Warning] 17  imagent							 0x00000001002540ab imagent + 32939
1/3/13 5:46:34.532 PM imagent[9260]: [Warning] 18  libdyld.dylib					   0x00007fff839427e1 start + 0
1/3/13 5:46:34.532 PM imagent[9260]: [Warning] 19  ???								 0x0000000000000001 0x0 + 1
1/3/13 5:46:34.532 PM imagent[9260]: [Warning] *** Listener ID: com.apple.CalendarAgent  does not have capability: (Status), not allowing request
1/3/13 5:46:34.533 PM imagent[9260]: [Warning] 1   IMFoundation						0x00007fff8b76abe2 IMLogBacktraceToDepth + 69
1/3/13 5:46:34.533 PM imagent[9260]: [Warning] 2   imagent							 0x000000010025fde8 imagent + 81384
1/3/13 5:46:34.533 PM imagent[9260]: [Warning] 3   imagent							 0x0000000100260f6a imagent + 85866
1/3/13 5:46:34.533 PM imagent[9260]: [Warning] 4   CoreFoundation					  0x00007fff8dcc263c __invoking___ + 140
1/3/13 5:46:34.533 PM imagent[9260]: [Warning] 5   CoreFoundation					  0x00007fff8dcc24d7 -[NSInvocation invoke] + 263
1/3/13 5:46:34.533 PM imagent[9260]: [Warning] 6   CoreFoundation					  0x00007fff8dcc26a9 -[NSInvocation invokeWithTarget:] + 57
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 7   IMFoundation						0x00007fff8b7675d5 im_local_object_peer_event_handler + 7128
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 8   IMFoundation						0x00007fff8b7676b3 im_local_object_peer_event_handler + 7350
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 9   IMFoundation						0x00007fff8b767767 im_local_object_peer_event_handler + 7530
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 10  Foundation						  0x00007fff8c094677 __NSThreadPerformPerform + 225
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 11  CoreFoundation					  0x00007fff8dc4e101 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 12  CoreFoundation					  0x00007fff8dc4daed __CFRunLoopDoSources0 + 445
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 13  CoreFoundation					  0x00007fff8dc70dc5 __CFRunLoopRun + 789
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 14  CoreFoundation					  0x00007fff8dc706b2 CFRunLoopRunSpecific + 290
1/3/13 5:46:34.534 PM imagent[9260]: [Warning] 15  Foundation						  0x00007fff8c09c89e -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 268
1/3/13 5:46:34.535 PM imagent[9260]: [Warning] 16  Foundation						  0x00007fff8c03518a -[NSRunLoop(NSRunLoop) run] + 74
1/3/13 5:46:34.535 PM imagent[9260]: [Warning] 17  imagent							 0x00000001002540ab imagent + 32939
1/3/13 5:46:34.535 PM imagent[9260]: [Warning] 18  libdyld.dylib					   0x00007fff839427e1 start + 0
1/3/13 5:46:34.535 PM imagent[9260]: [Warning] 19  ???								 0x0000000000000001 0x0 + 1

[dwmc]

I have not seen Messages reading from NVRAM, but it appears that imagent does when you try to sign in to your iMessages account...


dwm@hackintosh:/Users/dwm% pgrep imagent
477

dwm@hackintosh:/Users/dwm% gdb --pid=477
...

0x00007fff8306c686 in mach_msg_trap ()
(gdb) break IORegistryEntryFromPath
Breakpoint 1 at 0x7fff81fdbe24
(gdb) cont
Continuing.

Breakpoint 1, 0x00007fff81fdbe24 in IORegistryEntryFromPath ()
(gdb) bt
#0  0x00007fff81fdbe24 in IORegistryEntryFromPath ()
#1  0x0000000100fed9e3 in IMDDSAuthID ()
#2  0x0000000100ff7589 in IMDDSAuthID ()
#3  0x0000000100fc6a11 in IMDAppleIDClientIdentifier ()
#4  0x00007fff8b59e912 in MessageLogStatistic ()
#5  0x00007fff8895c407 in IMMMSEmailAddressToMatch ()
#6  0x00007fff85cb783c in _xpc_connection_call_reply ()
#7  0x00007fff8b6330b6 in _dispatch_client_callout ()
#8  0x00007fff8b6380c8 in _dispatch_main_queue_callback_4CF ()
#9  0x00007fff86ccd0fe in __CFRunLoopRun ()
#10 0x00007fff86ccc6b2 in CFRunLoopRunSpecific ()
#11 0x00007fff8219b89e in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] ()
#12 0x00007fff8213418a in -[NSRunLoop(NSRunLoop) run] ()
#13 0x0000000100f810ab in _mh_execute_header ()
#14 0x00007fff830a47e1 in start ()

[flux84]

dwmc, on 04 January 2013 - 02:27 AM, said:

I have not seen Messages reading from NVRAM, but it appears that imagent does when you try to sign in to your iMessages account...

This makes sense because imagent actually makes the connection and signs in, and stays signed in in the background.  At least that has been my understanding.

[fffeee]

Among other things, imagent is also how you can receive a FaceTime call without running FaceTime. CoreIM (like System) isn't a documented Framework in the Developer library however, so digging into it will require an adventurous spirit.

[dannymichel]

This is all a little too technical for me. Has anyone in this thread actually fixed it?

[iBlacky]

dannymichel, on 04 January 2013 - 11:17 AM, said:

This is all a little too technical for me. Has anyone in this thread actually fixed it?

Nope.

[dannymichel]

From what I'm piecing together from this thread – the little I can understand in it, the likelihood of this ever being fixed is snowing to none, am I right?