site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... At 23:32 +0100 11/2/05, Lassi A.Tuura wrote: We have a debugging type library that parses and modifies the machine code on the fly for certain functions, mainly to insert a jump to "capture" functions which do some special stuff then invoke the original code. The run-time patching appears to work on functions from the main executable, but not on functions from dylibs -- mprotect() on a page of code from the latter always fails, errno is set to 13 (EACCESS, Permission denied). I also tried vm_protect(mach_task_self(), ...), it also fails. I suspect that this fails because shared library code is all stored in a system-wide shared map (0x90000000..0x9FFFFFFF). You can't change the protection on these areas because it would affect all users of the shared map (that is, everyone). One trivial way to work around this is to use _debug variant of the system libraries (by setting the DYLD_IMAGE_SUFFIX environmont variable to _debug). The debug libraries don't load into the shared map, and thus their protection can be modified by you. Another thing to explore might be DYLD_NEW_LOCAL_SHARED_REGIONS. This forces your process (and any of its children) to pick up its own shared region, rather than sharing the system one. I don't know if you'll be able to modify the protection of this shared region, but it's worth a try. Another thing you can try is setting VM_PROT_COPY in your call to vm_protect. This forces the system to make a copy-on-write copy of that section of the shared region, which you can then manipulate. In this case, when you call vm_protect, don't specify VM_PROT_EXECUTE. The max protection on the shared region submap is VM_PROT_READ, so specify VM_PROT_EXECUTE in your vm_protect call triggers an error, even if you also specify VM_PROT_COPY. This email sent to site_archiver@lists.apple.com