[Question] Scenario where the dylib library to load is out side of the target process' sandbox container

[calvinq]

Hi Experts, Really impressive idea and great work from great people. Thank you all!

I have studied the code of mach_inject, and got a basic idea on how it is working. Basically it injects a code into the target process, run that piece of code from the target process, and then that code will do a dlopen() function call to load more interesting code to run.

I am think the scenario that if the dylib library dlopen() tries to open is out of the sandbox container of the target process, that is, the target process is not allowed to access the library, then dlopen() function call will fail. Any way to overcome this? Or my understanding is wrong?

Thanks and appreciate if any comment.

Calvin

[rodionovd]

Hi, @calvinq Sure there's a workaround: you should rather copy your payload into your target's sandbox container!

For an example implementation see my RDInjectionWIzard project: it has a method for generating a «sandbox-friendly» path for the given payload/target pair.

[rtibdewal]

Another workaround could be to copy dylib in folders like /System or /Library or their subfolders, etc. All apps can definitely load dylib from these locations.

Ofcourse, not recommended, not a good practice, you need root privileges to copy stuff their and all those crap.

But it's something possible and can be used.

[calvinq]

Thanks for reply and sharing your ideas. It's good to know there are secret APIs: sandbox_check() and sandbox_container_for_pid().

Later I figured out a way to overcome it, that is, to copy the whole content of the dylib into the target process' address and then load from there, using NSCreateObjectFileImageFromMemory() function. The problem for this is that, NSCreateObjectFileImageFromMemory() is deprecated.

[rtibdewal]

Why do you say NSCreateObjectFileImageFromMemory() is depricated? No such information is mentioned in the document. Unless I am looking at wrong documentation.

https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/MachOReference/Reference/reference.html#//apple_ref/c/func/NSCreateObjectFileImageFromMemory

[rodionovd]

@rtibdewal take a look at the header of «Object File Image Functions» section:

The use of these functions is discouraged. You should use the more efficient functions described in “Dynamic Loader Compatibility Functions.”

Also, if you open mach-o/dyld.h you'll see:

extern NSObjectFileImageReturnCode NSCreateObjectFileImageFromMemory(const void *address, size_t size, NSObjectFileImage *objectFileImage) 
__OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_1,__MAC_10_5,__IPHONE_NA,__IPHONE_NA);