[转]Breaking Bad With DTrace
Source：http://initwithfunk.com/blog/2013/05/31/breaking-bad-with-dtrace/
I’ve spent an unwise amount of time recently on a problem that arose when me and my Code Schoolcolleagues were developing the challenges for our upcoming course on MapKit. All of the challenges assume that the user has given the app permission to use it’s current location, and our KIF tests in the simulator wouldn’t work unless we could somehow programmatically confirm this alert box:
KIF tests run in the simulator and are built to a different target, so using private API’s isn’t a problem (KIF wouldn’t work unless it used a ton of private API’s). Jim Puls from Square (the makers of KIF) was helpful enough to chime in this thread to share how they do it at Square: by method swizzling the crap out of theCLLocationManager class, replacing startUpdatingLocation, location, and locationServicesEnabled with their own versions so the user location mechanics would be wholesale replaced, thus getting around the permission alert box.
We followed their advice and ended up mocking out CLLocationManager (see how in this gist) and it worked well enough, but I was unsatisfied that we had to mock out the entire location machinery just to get rid of that permissions alert box. It wasn’t elegant code.
…perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away…
Antoine de Saint-Exupéry english.stackexchange.com/38837/…
I decided to keep searching for a more elegant solution and I started at what I thought was the most obvious place: UIAlertView.
Searching for UIAlertView
If I could find the code where the offending UIAlertView is actually created then I would know which code to mock out and hopefully bypass permissions. To do this, I could have swizzled some UIAlertView init methods or added a symbolic breakpoint in Xcode, but I had recently come across Mark Dalymple’sexcellent three part series on DTrace (1, 2, and 3), and this seemed like a good opportunity to use it for a worthy real-world problem.
I created a new blank iOS 6.0 project with a single MKMapView that wants to show the current user location (you can ⬇download the project here). I built and ran the app for the simulator to verify that it brought up the alert box and to create a binary that I would later use in Instruments as a target for a custom DTrace instrument.
Instruments is powered by DTrace and by using it it made a couple of things easier, like launching an app in the simulator as it attached DTrace probes and logged the results, as well as a cleaner interface for viewing call stack information. To create custom DTrace probes in Instruments, start by opening Instruments from Xcode:
And then create a new blank document:
Use ⌘B to build a new instrument, and you should come across this screen:
Which presents a nice interface for creating custom DTrace scripts. To find all methods (class or instance) called on UIAlertView, I ended up with this:
The part to pay attention to is this group of boxes here:
Next up I needed to the choose the target this instrument would run against
You have to pick the executable that was built for the simulator, which you can find in ~/Library/Application\ Support/iPhone\ Simulator/6.0/Applications/. In there you might see many directories with randomly generated names:
You’ll have to dig through the noise to find the executable you want:
Now all that’s left is to hit the record button and hope we can find out where that UIAlertView is being initialized:
As you can see, there were 3 UIAlertView method calls that all came from [UIWindow keyWindow], and one from a performSelector, but that doesn’t help us much. Let’s update that probe to record both the module (in this case the class name), and the name of the method
Now it’s a little easier to see what’s going on. It looks like [UIWindow keyWindow] calls private class method+_alertWindow on UIAlertView.
Could this be where our location permissions alert box is being created. Fortunately, our instrument’s probe automatically records the stack trace information for each of the events recorded. To view the stack trace information, we just need to select an event and open the right hand side drawer:
The stack trace of the _alertWindow calls are all the same, and lead to a dead end. They don’t seem to be related to location at all but instead are triggered on normal app startup routines. The only other hit we got,+_initializeSafeCategory, is related to Accessibility and not location.
This is a dead end.
Well, not exactly. Using DTrace I was able to eliminate the possibility that the UIAlertView was created inside the TestingCurrentLocation process, which means it has to be created in another process. So I knew that somehow, my TestingCurrentLocation process was communicating with another outside process which was responsible for location permissions. Apple doesn’t want to give app developers the chance of getting around the location permissions box for privacy reasons, so they would want to lock it down in another process.
The Mystery Process
So my next goal was to figure out what this mystery outside process was. I knew that my app process and the mystery process had to communicate, which led me to research the XPC Services API which “provides a lightweight mechanism for basic interprocess communication integrated with Grand Central Dispatch (GCD) and launchd” and is an integral part of App Sandboxing, so it seemed like an interested place to start. I tried logging all methods called on parts of the Objective-C API, like NSXPCConnection, andNSXPCInterface, but there was nothing there. The next most obvious thing to probe was the c API, specifically the xpc_connection_create function. Here is how I created the probe I to log all the calls toxpc_connection_create with the caller and the name of the service with which to connect:
As you can see, probing this function turned out to bear some real fruit. It found a call toxpc_connection_create that was creating a connection to something named com.apple.locationd.registrationand the call stack confirmed that this being triggered by setting the map to display the users location:
Running sudo ps aux | grep locationd showed that their was indeed a locationd process running in the simulator located at/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk/usr/libexec/locationd(there was also one running at /usr/libexec/locationd which is the location daemon for Mac OS X.)
locationd
This gave me a new process to probe for information. But what should I look for? I knew that if a user allowed an app in the simulator to get their location, they wouldn’t be asked again even if the simulator was restarted (only by resetting the simulator would the location permissions alert box come up again). So I knew that there had to be somewhere on the filesystem where locationd was storing the permission authorizations for simulator apps. If I could find this file (most likely a preferences file), I could possibly inject authorization for an app before it ever ran, thus never displaying the alert box even on the apps first run in the simulator.
So how do I find what files the locationd process is opening and reading and writing to? Well, that’s where the syscall DTrace provider comes in, which allows you to probe all system calls (like open, read,write, chdir, etc.). This provider makes it really easy to find out which files a process is opening and writing to by probing the open and write functions. For example, here is a DTrace script for printing out all the files opened by the locationd process:
locationopens.d
1 2 3 4 5 |
|
This script will trace all system calls to open* (* is a wildcard), but only on processes with the name “locationd” (the /execname == "locationd"/ line defines a predicate for the probe). The code between the curly-braces is the action to perform on each match. Inside the curly-braces we are printing the first argument to open, which is the path of the file (to find out which arguments a system call takes, use man 2 syscall which in this case would be man 2 open). We have to use copyinstr to copy data from the process into the kernel’s address space (where DTrace runs).
Running this with dtrace -s locationopens.d (make sure you have root priviledges: run sudo -i to start a new shell in root) and then running our TestingCurrentLocation app in the simulator results in a couple hundred lines that look like this:
1 2 3 4 5 6 7 8 9 10 11 12 |
|
We can get rid of some of the noise by running dtrace with the -q option, like so:
1 2 3 4 5 6 7 8 9 |
|
Okay that’s a lot of file opens, and it would take awhile going through every single one looking for clues. What I really want to know is: what files does locationd write to when a user taps the “OK” button in the location alert box, and what data does it write? For that we are going to need another DTrace script:
locationwrites.d
1 2 3 4 5 |
|
Here we are tracing all calls to write* and printing out the path name using the first argument (arg0) which is a file descriptor (for more on using file descriptors in DTrace, read this tutorial). We are also printing out the second argument (arg1) which is a buffer of the contents written to the file. Now if we run the script just before we confirm we want to allow this app to use our current location, we will know where locationd is writing to save this information.
This results in just one trace match writing to a file at ??/locationd/clients.plist. If we run the locationopens.dscript again while grepping for clients.plist we can find the full path to this file:
1 2 |
|
The solution
When I opened this file for the first time I had to find someone in the office to high-five. Here it was, the file that tells locationd, and thus apps in the simulator, whether or not the user has permitted use of location information. I could convert the clients.plist file into xml using plutil -convert xml1 clients.plist and then open it up and see what was inside:
clients.plist
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
Property List’s (.plist) are a strange format but not impossible to read. The real important bit seemed to be the Authorized key which was set to <true/>. I tried changing that to <false/> and rerunning the app in the simulator and my app no longer had access to location information and also didn’t bring up the location permission alert box. If I removed the entire <dict></dict> block representing my app, the location permission alert box would show back up the next time I ran the app in the simulator.
I now had full control over that location alert box. All I had to do was write over the clients.plist file with the xml already crafted in a way to give my app access to location information. For our upcoming MapKit course, we’re doing it inside our executor server (which is written in ruby), kind of like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
The code above runs before the app is launched in the simulator, and it works perfectly. We were able to get rid of the nasty CLLocationManager mocking and I was finally able to move on to something more productive.
But trying to solve this problem did lead me to learn a lot more about DTrace. Before, DTrace just seemed like this magical thing used by superhero programmers. Now that I’ve used it so solve a real problem, it’s not so magical anymore, and I am already starting to think of other problems I could solve using it that I wouldn’t have been able to before. I hope that by writing about how I used DTrace to solve this problem, it will lead you to try it out the next time you are stuck on something similar. If you do, please let me know how you did by getting in touch with me on my twitter.
