macOS Executing binaries with objective-c

exactly how careful do you need to be about the availability of this thing? Are your users technical and known to be malicious, or do you just want to prevent casual access to this binary? Do you have the source for this thing such that it could simply be made a subroutine that you can call within the new program?

The answers to these will have a big impact on how you implement this. I would say that you could write the file to a temporary location, exec it (via system(), NSTask, etc.), and remove the binary as soon as the exec occurs. The inodes will still point to the data, and the reference count will stay 1 as long as the program is executing, but once it stops it will be "gone" from the filesystem, and without heroics the user couldn't access this file through the filesystem after you've removed it.

-Lee

Is your application something along the lines of Steam? I myself don't know how it works, I imagine that the "protected" application itself is designed to authenticate with Steam, and that Steam is not just a simple wrapper that encrypts the application.

WhiteRabbit said:

Is your application something along the lines of Steam? I myself don't know how it works, I imagine that the "protected" application itself is designed to authenticate with Steam, and that Steam is not just a simple wrapper that encrypts the application.

Click to expand...

Basically, that is what Steam does.

There are many problems with trying to encrypt and run arbitrary binaries. Especially since on OS X, a raw binary is usually assumed to be part of a bundle, and will access the bundle in ways you can't predict. Therefore, the bundle resources need to be on disk somewhere, and unencrypted. The moment you can use NSBundle to get a file, so can a user on the filesystem.

You'd have to write an encryption shim that loads the encrypted binary, decrypts it in RAM, and jumps into the entry point using assembler. Although your resource blobs are still in the clear.

You would need to look at the APIs that let you load and manipulate Mach-O binaries to do such a thing.

The more secure route will require middleware (that you write) which interacts with the service, validates the license, and decrypts the binary, and the data assets (wrapping around the normal loading methods). If the authors of the apps want to distribute independent of your service as well, then you will also need a stub version of the middleware that they can compile into the app which doesn't actually integrate with the service.

EDIT: I personally would rather go the route of shimming the app, as it gives the user a double-clickable icon to launch the app. Requiring a user to launch your service in order to launch the app is not a good user experience. Also, you have to assume that: A) resources and other data need to be on the filesystem for an OS X app to run, thus exposing them to attack, and B) The user will be able to figure out where you hide any data, including encrypted disk images, and will thus be able to gain access. If the apps you are accessing via the service can run unchanged, then a user will be able to figure out where it is hiding and gain access to the unencrypted binary and resource data.

Thus, it seems to me that letting the app 'hang out' on the filesystem is going to happen anyways, so let the user see it, and secure the code/data via some other means.