launchd, I'm coming for you

# Default: Print for system (user 0). This does the same as  launchctl print-disabled system
Zephyr:~ morpheus$ ~/Documents/shared/10.11/launchd/jlaunchctl print-disabled
disabled services = {
        "com.apple.AEServer" => true
        "com.apple.ManagedClientAgent.enrollagent" => true
        "com.apple.usbmuxd" => false
        "com.apple.rpmuxd" => false
        "com.apple.ftpd" => true
        "com.apple.mrt" => false
        "com.apple.stackshot" => false
        "com.apple.dynamic_pager" => false
        "org.ntp.ntpd" => false
        "com.apple.pacemaker" => true
}
# This does the same as  launchctl print-disabled user/501
Zephyr:~ morpheus$ uid=501 ~/Documents/shared/10.11/launchd/jlaunchctl print-disabled
disabled services = {
        "com.apple.TMHelperAgent.SetupOffer" => false
        "com.apple.FileStatsAgent" => true
}
login item associations = {
}
# uid= is required when looking for a per-user service:
Zephyr:~ morpheus$ jlaunchctl print com.apple.tccd
Error:  113 - Could not find specified service
Zephyr:~ morpheus$ uid=501 ./jlaunchctl print com.apple.tccd
com.apple.tccd = {
	active count = 2
	path = /System/Library/LaunchAgents/com.apple.tccd.plist
	...
	...

Likewise try uid=501 jlaunchctl print and jlaunchctl print (implicitly does the same as launchctl print system), and remember uid=... when printing a per-user service, as without it you will get error 113. While I was at it, I added a simple command - lookup - which will enable you to see if a Mach port is reachable or not (by name). Super useful for iOS. If a port isn't reachable, expect error 3.

If you read the source..

You'll see that I have #if 0 blocks showing the Mach messages used in each of the launchctl requests. You are encouraged to get to them yourself, and it's quite easy to reproduce:

• Start launchctl with no arguments under lldb
• Set a breakpoint on xpc_pipe_routine
• Run with whatever request argument you want to test
• When the breakpoint hits, set another breakpoint on mach_msg
• continue on the first two hits of mach_msg - these are the setup messages of the XPC pipe
• mem read $rdi to see the content of the third message. You'll see something like:

  (lldb) mem read $rdi
  # Note the mach_msg header
  0x100200118: 13 15 13 80 b8 00 00 00 1b 03 00 00 13 04 00 00  ....?...........
  0x100200128: 07 0b 00 00 00 00 00 10 01 00 00 00 03 0a 00 00  ................
  #                                    XPC Magic
  0x100200138: 00 00 00 00 00 00 11 00 21 43 50 58 05 00 00 00  ........!CPX....
  0x100200148: 00 f0 00 00 80 00 00 00 06 00 00 00 73 75 62 73  .?..........subs
  0x100200158: 79 73 74 65 6d 00 00 00 00 40 00 00 02 00 00 00  ystem....@......
  0x100200168: 00 00 00 00 66 64 00 00 00 b0 00 00 68 61 6e 64  ....fd...?..hand
  0x100200178: 6c 65 00 00 00 40 00 00 00 00 00 00 00 00 00 00  le...@..........
  0x100200188: 72 6f 75 74 69 6e 65 00 00 40 00 00 c4 02 00 00  routine..@..?...
  0x100200198: 00 00 00 00 6e 61 6d 65 00 00 00 00 00 90 00 00  ....name........
  0x1002001a8: 10 00 00 00 63 6f 6d 2e 61 70 70 6c 65 2e 6b 65  ....com.apple.ke
  0x1002001b8: 78 74 64 00 74 79 70 65 00 00 00 00 00 40 00 00  xtd.type.....@..
  0x1002001c8: 01 00 00 00 00 00 00 00 03 0a 00 00 00 00 00 00  ................
  

  and the serialization is readily evident. And interesting if ,say, you wanted to fuzz it to find faults in launchd's handling.

Note that most methods actually require you to pass a file descriptor (via file ports) to launchd. This is clever, but sucks, because it means there's no easy way (convoluted popen()notwithstanding) to get the data in a machine-friendly format which can be digested programmatically.

Update: I added a small XPC snooping library in the snoop/ directory inside the tar. Super simple, and really nothing fancy - the ages-old DYLD_INSERT_LIBRARIES trick, etc. But useful, since it uses xpc_copy_description() to dump XPC messages aplenty. Fascinating stuff. Expect more - much more - when I get to the XPC explication in MOXiI 2.

Speaking of MOXiI 2..

Both launchd and libxpc would benefit from more transparency - you know, just in case there is a certain 0-day vulnerability (or two three) in the implementation of XPC. The 2^nd edition of MOXiI will therefore have a lot more than this. launchd now has a dedicated chapter (I'm kicking SpringBoard and WindowServer to their own chapter), and XPC is covered in depth likewise in a chapter. 

Update: And I'm glad to say I have libxpc.dylib fully reversed :-) Anyone interested in OpenXPC? ;-)

.. and Technologeeks' Training

If you're reading this and following my articles, check out Technologeeks' Training on OS X and iOS Internals. This reverse-engineering oriented course is delivered by yours truly and goes even deeper than MOXiI 2 does, with practical and hands-on exercises. Our 2015 dates are full, but they tell me we're planning more training right around January 18^th, 2016! Updates through@Technologeeks, or emailing info@you.know.where.

Comments/Feedback

Through the website forum please. Technologeeks' Twitter doesn't normally respond to Twitter conversations or questions, but you can follow them for more updates on my work, as well as training

Greets

windknown, qwupz, and - how can I forget - launchderp :)