Hacker News Reader

Comment by kitsune_ | Hacker News Reader

http://forums.dropbox.com/topic.php?id=12498

"more pertinent is the fact that none of the integrations we do with the Finder are actually supported by Apple. this means that it takes significant reverse engineering of the Finder to make icon overlays/contextual menu items to work. Apple completely removed support for contextual menu items in SL (it's possible to have right click options, but it's not possible to have a submenu, or a submenu with options that change dynamically based on context).

in order to make these integrations work we have to inject code into the finder to make in memory replacements of finder code with our own (many complexities/details of hackery omitted). if it were easy, you'd see more products than just Dropbox able to do it ;-)"

also: http://forums.dropbox.com/topic.php?id=938

View on HN

I had no idea installing Dropbox meant they were modifying the Finder. Why isn't there an option to disable this?

Note that they are injecting code into the running Finder process, which is very different from patching the Finder binary. That would be very bad.

They are injecting code into running Finder process? Hmmm, so they figured one of the jump instructions target address in Finder process ( for a function invocation, most likely the code to show the pop-up), and changed that location to jump to a different address where they injected their code? Don't you need root privileges to muck with Finder's process space? I see dropbox process running with non-privileged uid. Wonder, how they managed to change the VMM space of Finder process to inject code. Any thoughts? Please correct me, if I am totally off the mark here.

I think there are some hooks in OSX/Cocoa for doing this, although I don't claim to actually understand it.

There is the SIMBL system which people used to write native plugins for Safari, I guess that's probably stopped since it has an actual extension framework now.

http://www.culater.net/software/SIMBL/SIMBL.php

Then there's TotalFinder, which uses in-memory patching to add tabs and all sorts of other leet stuff into Finder. I highly recommend it. In their docs they say it works similarly to SIMBL.

http://totalfinder.binaryage.com/

Thanks for the info. On further digging, I found this useful link - http://www.culater.net/wiki/moin.cgi/CocoaReverseEngineering

which provides some insights into accomplishing what Dropbox did.

So, hijacking shared libraries. I doubt they're actually changing the Finder process in memory. I bet their changes are localized to the library they hijack.

A process can't change the address space of another process, period. Even if one is a root process. Separation of address spaces is a basic security service provided by the operating system. So I'm also puzzled how they are able to modify memory in Finder's address space.

The closest thing I can think of is that Finder executes arbitrary processes on behalf of the user. That is, when I double click on something, Finder has to do the fork-exec dance to launch that application. A process fork, however, creates an entirely separate address space for the new process. I would be shocked if Finder did not do that. So, yes, I'm also wondering what it is they do.

Not true, at least on OS X:

http://www.slideshare.net/rentzsch/dynamic-overriding

https://github.com/rentzsch/mach_star

I don't know if this is how Dropbox works, but it seems likely.

The first chunk of those slides talk about library hijacking. Say, you define your own version of malloc, make sure the application links to your version of malloc, and play your tricks from there. Process isolation has not been violated.

The last five slides seem to be doing this: http://www.blackhat.com/presentations/bh-usa-09/DAIZOVI/BHUS...

Slide 4 is the difference: OSX is BSD running on top of Mach. So these techniques use the Mach layer to get around basic process protection. This is terribly insecure.

Yeah, the injection stuff was what I was referring to.

Apple apparently changed OS X in 10.4.4 to only allow root or procmod group to do this http://guiheneuf.org/mach%20inject%20for%20intel.html

Dropbox does in fact use mach_star.

> A process can't change the address space of another process, period. Even if one is a root process. Separation of address spaces is a basic security service provided by the operating system. So I'm also puzzled how they are able to modify memory in Finder's address space.

Sure you can. Every major PC OS (Windows, Mac, Linux) has a debugging API that, in fact, does allow you to read and write the memory of other processes. Windows even has a convenient function to allocate blocks of memory in other processes' address space, and another function to spawn a thread in another process with an arbitrary entry point - which makes this sort of thing relatively easy to do.

Mind you, the primitives provided can be a bit difficult to work with, but it's far from impossible.

A process can't change the address space of another process, period.

Don't forget ptrace.

I had, but that's not the situation I had in mind. You can only use ptrace on a child process. You can't use ptrace to attach to, say, another user's process.

You can attach to any of your processes, that's how debuggers work! Ever used gdb to attach to a running process and debug it on the fly? This is done with ptrace() with the PT_ATTACH flag.

Now ptrace is known to be severly limited on Mac OS X, but there are ways around it: http://uninformed.org/index.cgi?v=4&a=3&p=14

See PT_ATTACH, and wouldn't both Finder and Dropbox be running as the user?

> A process can't change the address space of another process, period. Even if one is a root process. Separation of address spaces is a basic security service provided by the operating system.

That is not even close to true, on any operating system.

Thanks for the clarification. I was thinking may be they were mucking with shared libraries. I found this useful link on digging further. Doesn't seem like too much of black art. http://www.culater.net/wiki/moin.cgi/CocoaReverseEngineering

I'm not convinced that patching code into a running process [1] is any better than patching the binary on disk. That's the sort of thing that a fully secured system would not allow.

[1] Of course excluding programs that have an actual plugin interface, and the "patching" just constitutes using that interface.

This would also break the code signing for Finder, I believe. (also bad)

This is the most interesting comment for me personally. Thanks.

Reply on news.ycombinator.com