site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, Lassi -- Treat a person as he is, and he will remain as he is. Treat him as he could be, and he will become what he should be. --Jimmy Johnson _______________________________________________ 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... Thanks for the clear reply. The DYLD_IMAGE_SUFFIX works on libraries that have _debug version, but not on others. At least it gets me to hook into libSystem. DYLD_NEW_LOCAL_SHARED_REGIONS didn't work, at least not with mprotect(), didn't yet try vm_protect(). On VM_PROT_COPY sounds exactly what I need. I'll try out something, but just to clarify my understanding: 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. I am not sure I followed this entirely, but with a few trials this is how I understood it. I start with page protected with VM_PROT_READ | VM_PROT_EXECUTE (from dylib). To modify that page, I start with VM_PROT_READ | VM_PROT_COPY, which automatically makes it writable, then modify the page, and then set protections back to VM_PROT_READ | VM_PROT_EXECUTE. I have had partial success with this, but some things are not right -- I get further, but not as far as I would like to. I'll get back on this when I have had a chance to debug things further. This email sent to site_archiver@lists.apple.com