{
	"id": "584b3a60-bcd7-4800-8661-025eb6c1a9da",
	"created_at": "2026-04-06T00:15:16.033301Z",
	"updated_at": "2026-04-10T03:22:39.374405Z",
	"deleted_at": null,
	"sha1_hash": "a6a426dd0a99d8587b3f0d6fc944ae51eb03a492",
	"title": "How to Inject Code into Mach-O Apps. Part II.",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2947440,
	"plain_text": "How to Inject Code into Mach-O Apps. Part II.\r\nBy Jon Gabilondo\r\nPublished: 2022-07-25 · Archived: 2026-04-05 14:15:30 UTC\r\nDynamic Code Injection Techniques\r\nPress enter or click to view image in full size\r\nOrganismo-App-inspector within Microsoft Word 2018.\r\nUpdate !\r\nThis article was written while finding a solution to inject Organismo framework, or any other library, into\r\nhardened applications. The article described a journey to overcome the limitations that prevent code injection,\r\nuntil we stumbled into the final hurdle of AMFI and the Gatekeeper.\r\nGladly, a little research on AMFI brought a surprising solution. You may jump to the end of the article to find out\r\nthe solution to inject code freely on any Mac App. However the content until there is really interesting if you are\r\ninto the details of the OS X (\u0026 iOS) system security.\r\nIn Part I we saw how easy it is to inject code into Mac Apps, from Calculator to Mail, even more surprisingly, into\r\nMicrosoft Apps like Word 2018. Why would such important applications not have a simple protection (hardening)\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 1 of 16\n\nagainst external code injection is not easy to understand. In fairness we must say that in Part I we worked with the\r\ncondition of disabling System Integrity Protection (SIP) which is a major security layer on OS X.\r\nIn Part I we used a dynamic code injection techique using the DYLD_INSERT_LIBRARIES environment\r\nvariable, an old property of the Dynamic Linker ‘dyld’ to load external libraries.\r\nHowever, as one would expect, the simple dynamic code injection used in Part I would not succeed in (important)\r\nApps such as iTunes, Xcode, Photos... These Apps are hardened to instruct the ‘dyld’ to disable the injection\r\ndefined by environment variables as well as to reject code that does not match code signature of the Application.\r\nIn this story we will walk towards finding a solution to inject external code into hardened Apps like iTunes and\r\nXcode.\r\nHardened Runtime\r\nThe Hardened Runtime, along with System Integrity Protection (SIP), protects the runtime integrity of your\r\nsoftware by preventing certain classes of exploits, like code injection, dynamically linked library (DLL) hijacking,\r\nand process memory space tampering.\r\nThere are two ways to harden your Application, the official one is by using entitlements and a less common one\r\nby creating a __RESTRICT segment in the Mach-O binary.\r\nTo harden your Application in Apple’s official way navigate in Xcode to your target’s Signing \u0026 Capabilities\r\ninformation and click the + button. In the window that appears, choose Hardened Runtime.\r\nPress enter or click to view image in full size\r\nThen add the capability ‘Hardened Runtime”. Check in ‘Build Settings’ that “Hardened Runtime” is enabled.\r\nPress enter or click to view image in full size\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 2 of 16\n\nFind Apple’s documenttion here:\nHardening by Entitlements\nWe’ve seen that Xcode allows to harden one Application in a simple manner, but how are they applied to the\nbinary and where are they kept in a binary.\nLet’s start by retrieving the the entitlements of any Application binary, this is done using codesign, lets’ do it on\nMusic.app:\n$ codesign -d --entitlements :- /System/Applications/Music.appExecutable=/System/Applications/Music.a\nThis is the output of the codesign command containing the xml list with the entitlements of the Music.app:\n?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\nUBLIC \"-//Apple//DTD PLIST 1.0//EN\" \"http://www.apple.com/DTDs/PropertyList-1.0.dtd\ncom.apple.PairingManager.Readcom.apple.PairingManager.RemovePeercom.apple.PairingManager.Writecom.apple.amp.artwork.clientcom.apple.amp.devices.clientcom.apple.amp.library.clientcom.apple.application-identifiercom.apple.Musiccom.apple.authkit.client.internal https://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\nPage 3 of 16\n\ncom.apple.avfoundation.allow-system-wide-contextcom.apple.avfoundation.allows-access-to-device-listcom.apple.avfoundation.allows-set-output-devicecom.apple.cdp.recoverykeycom.apple.mediaremote.allowTVPairingcom.apple.private.accounts.allaccountscom.apple.private.applemediaservicescom.apple.private.aps-connection-initiatecom.apple.private.audio.notification-wake-audiocom.apple.private.bmk.allowcom.apple.private.commerceAccountscom.apple.private.fpsd.clientcom.apple.private.notificationcenter-systemidentifiercom.apple.appstoreagentcom.apple.private.rtcreportingdcom.apple.private.security.storage.mo\nbilesync.heritablecom.apple.private.sqlite.sqlite-encryptioncom.apple.private.tcc.allowkTCCServiceAddressBookkTCCServicePhotoskTCCServiceAppleEventskTCCServiceSystemPolicyAllFiles kTCCServiceCamera https://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\nPage 4 of 16\n\n\u003c/array\u003e\r\n\u003ckey\u003ekeychain-access-groups\u003c/key\u003e\r\n\u003carray\u003e\r\n \u003cstring\u003ecom.apple.pairing\u003c/string\u003e\r\n \u003cstring\u003ecom.apple.airplay\u003c/string\u003e\r\n \u003cstring\u003eapple\u003c/string\u003e\r\n\u003c/array\u003e\r\n\u003c/dict\u003e\r\n\u003c/plist\u003e\r\nAt runtime the OSX/iOS needs to validate the operations and resources accessed by the executable, for that it\r\nneeds to know what has the App been validated for, via the entitlements. The entitlements are kept in the binary\r\nMach-O structure itself, in the ‘Code Signature’ setion.\r\nPress enter or click to view image in full size\r\nThe Code Signature section in Music.app binary.\r\nEntitlements is therefore a simple xml list of keys defining the entitlement and its properties. Although Apple\r\ndocuments and offers a handful of them to programmers, internally there might be hundreds.\r\nThe assignment of entitlements to an App is a matter of defining the entitlements xml file in the codesign\r\ncommand:\r\n$ codesign --entitlements entitlements.xml -f -s \"iPhone Distribution: Company (XYZ)\" Payload/Exampl\r\nHardened by __RESTRICT\r\nA __RESTRICT segment is a section in the Mach-O binary file that can be created at link time. The section has\r\nno content. It acts like a flag to instruct the ‘dyld’ to perform code signature validation to all code loaded to the\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 5 of 16\n\nprocess.\r\nSee bellow how does the __RESTRICT section look like in iTunes:\r\nPress enter or click to view image in full size\r\nThe __RESTRICT section in iTunes.\r\nCreating the __RESTRICT segment in Xcode is actually very easy. It is done by adding the following flags into\r\nyour “Other Linker Flags”:\r\n-Wl,-sectcreate,__RESTRICT,__restrict,/dev/null\r\nWhy Is the Injection Rejected\r\nThe __RESTRICT segment flags the ‘dyld’ to activate the code signature validation for all library to be loaded.\r\nWe saw in Part I how the injection in iTunes failed with the following message:\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 6 of 16\n\n“dyld warning: could not load inserted library into hardened process because no suitable image found. Code\r\nsignature in framework not valid for use in process using Library Validation”\r\nPress enter or click to view image in full size\r\nIf we analyse the code signature of iTunes and Organismo we can see they obviously have a different code signing\r\nvalues (certificates):\r\nPress enter or click to view image in full size\r\niTunes code signature values.\r\nPress enter or click to view image in full size\r\nOrganismo code signature values.\r\nApproaches to Overcome Hardening\r\nIn order to overcome the hardening barrier, these are the ideas that come to my mind. From foolish to realistic,\r\nthey are:\r\n1. Build our own tweaked ‘dyld’ and instruct the Application to use it, instead of the default ‘/usr/lib/dyld’.\r\n2. Codesign all software components with your own Certificate.\r\n3. Remove the __RESTRICT segment.\r\nOption 1. Create a Custom dyld\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 7 of 16\n\nThis is certainly a bold idea. To build a custom ‘dyld’ removing all the security measures that would not care\r\nabout SIP or __RESTRICT, sounds exciting. This option comes motivated by two ‘reasonable’ facts. First, the\r\n‘dyld’ code is open source:\r\nsecond, as we saw in part I, the Mach-O binary of every App specifies what dynamic linker must be used. In Mac\r\nOS X is always ‘/usr/lib/dyld’:\r\nPress enter or click to view image in full size\r\nAs of today the macOS 10.14.5 open source site has more than one hundred projects. The Dynamic Linker of OS\r\nX and iOS is right there. Impressive.\r\nPress enter or click to view image in full size\r\nWell, first problem:\r\nBase SDK MacOSX.internal (SDK not found)\r\nMacOSX.internal… Okay… I understand, Apple has its own SDK, makes sense. Can I get it ? Obviously not. So\r\nlets set the Base SDK to what we’ve got by default: ‘macOS’.\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 8 of 16\n\nWhat happens from then on is a never ending compilation attempts with missing includes: _simple.h,\r\nBlock_private.h, coreSymbolicationDyldSupport.h, CrashReporterClient.h, cs_blobs, objc-shared-cache, etc. etc.\r\netc.\r\nGet Jon Gabilondo’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nOne can painstakingly find the missing includes from different packages of the open source, until it makes no\r\nsense to continue. There must be a better way to do it, but it’s nowhere to be found.\r\nThis option ends here. One wonders how does Apple understand open source.\r\nOption 2. Re-Codesigning with Your Certificate\r\nWe assume that the Organismo framework is rejected by the ‘dyld’ because its code signing certificate is different\r\nfrom the one of iTunes. Organismo uses your Developer Certificate, iTunes uses Apple’s Private Certificate.\r\nTherefore we assume that code signing iTunes with our Dev Certificate, the ‘dyld’ will pass the code integrity\r\nvalidation when loading Organismo.\r\nRe-codesigning any App is as simple as (remember to work on a copy of the App !):\r\n$ codesign --deep --force --preserve-metadata=entitlements -s ‘Mac Developer: Jon Gabilondo (HSU……M\r\nChecking the signature with ‘codesign -dvvv’ we can actually see that the signature is now ‘Jon Gabilondo’,\r\nwhich is what we wanted. Let’s run the modified iTunes to see if it runs properly, before we attempt the injection:\r\n$ DYLD_INSERT_LIBRARIES=/path_to/Organismo-mac.framework/Versions/A/Organismo-mac /Users/jongabilondo\r\nPress enter or click to view image in full size\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 9 of 16\n\nThe assumption of having the same code signature was right, partially. It did not consider the ramifications of\r\ndylib dependencies that will always end up in an Apple system dylib with Apple’s Signature. Like we see in the\r\nerror report of the modified iTunes, the dylibs of iTunes have Jon’s signature, but its dependencies always end up\r\nin Apple’s OSX /usr/lib dylibs.\r\nOption 2 not good either.\r\nPress enter or click to view image in full size\r\nError loading dylib because binary is restricted.\r\nIt is always very useful to read Apple’s Code Signing In Depth:\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 10 of 16\n\nOption 3. Removing the __RESTRICT segment\r\nI’m left with the last bullet. If the __RESTRICT segment is the flag that is activating the code signature\r\nvalidation, we might just remove it from the Mach-O binary.\r\nThis approach requires static code modification, which obviuously causes the binary (checksums) invalidation.\r\nBut we know how to recodesign an App with our Dev Certificate so there should be no problem.\r\nRemoving the __RESTRICT segment\r\nSeveral tools could be used to modify a Mach-O binary file, you can choose your favourite. Here I will use iHex\r\neditor. Find the __RESTRICT segment and rename it , for instance to: __XESTRICT. Save the file and codesign it\r\nwith your Dev Certficate.\r\nPress enter or click to view image in full size\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 11 of 16\n\nRenaming the __RESTRICT segment of iTunes Mach-O binary.\r\nNow let’s inject Organismo into iTunes:\r\n$ DYLD_INSERT_LIBRARIES=/path-to/Organismo-mac.framework/Versions/A/Organismo-mac /Users/jongabilondo\r\nThis time Organismo framework was successfully loaded into iTunes.\r\nPress enter or click to view image in full size\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 12 of 16\n\nUpdate for Catalina!\r\nMac OSX Catalina has added new system protections. After changing the RESTRICT section the Apps and re-codesigning with the Dev Certificate it does result in a non valid App.\r\nMusic.app crashes on start. The logs hint to the the taskgated-helper and amfid processes. The error says:\r\nDisallowing com.apple.Music because no eligible provisioning profiles found.\r\nHere the Console logs:\r\nerror 11:06:47.743379+0200 taskgated-helper Disallowing com.apple.Music because no eligible provision\r\n success = 0;\r\n}default 11:06:47.743834+0200 amfid Failure validating against provisioning profiles: No eligible pro\r\nThe taskgated process belong to a daemon that can be found in:\r\n/System/Library/LaunchDaemons/com.apple.taskgated.plist\r\nand the related:\r\n/System/Library/LaunchDaemons/com.apple.taskgated-helper.plist\r\nWhich executables are : /usr/libexec/taskgated and /usr/libexec/tasgated-helper\r\nPress enter or click to view image in full size\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 13 of 16\n\nThe amfid is a daemon of the Apple Mobile File Integrity found in\r\n/System/Library/LaunchDaemons/com.apple.MobileFileIntegrity.plist which launches /usr/libexec/amfi.\r\nPress enter or click to view image in full size\r\nThis is a very interesting article on AMFI:\r\nWe can assume that these two Apple Security daemons are rejecting our codesigned Music.app because the\r\nentitlements it requires are not accepted for our Dev Certificate. To confirm this we can create an entitlements file\r\nbased on Music.app’s entitlements and removing the entries that start com.apple.private.*. The resulting\r\nMusic.app will pass the AMFI and Gatekeeper security validation and it will launch, but it will fail in operations\r\nthat require those entitlements.\r\nThese is a great WWDC video on Gatekeeper and other security updates for Catalina:\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 14 of 16\n\nThe Solution\r\nThe ending of the first version of the article was this one:\r\nFor my purpose of making Organismo App Inspector still work in Catalina and coming versions, the direction to\r\ntake is to get dyld, AMFI and the Gatekeeper ‘out of the way’, i.e. to disable their integrity validation.\r\nThe expression to ‘get them out of the way’, could have not been more premonitory. See the entry on AMFI on\r\niphonewiki.\r\nThe amfi kext recognizes quite a few boot-args, including:amfi_unrestrict_task_for_pid — Allowing the\r\namfi_allow_any_signature — Allowing any digital signature on code, not just Apple’s\r\namfi_get_out_of_my_way — disable amfi\r\ncs_enforcement_disable — Disable code signing enforcement\r\ncs_debug — Debug code signing\r\nWe can set a boot-arg to disable AMFI daemon process completely !\r\n% sudo nvram boot-args=\"amfi_get_out_of_my_way=0x1\"\r\n(careful with the quotes if you copy-paste.)\r\nReboot. The AMFI will disappear from your system. Organismo is free to be injected into any App.\r\n% DYLD_INSERT_LIBRARIES=/path/to/Organismo-mac.framework/Versions/A/Organismo-mac /System/Application\r\nPress enter or click to view image in full size\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 15 of 16\n\nOrganismo injected into Music.app\r\nThanks !\r\nI hope you enjoyed it. You may explore it yourself using Organismo.\r\nSource: https://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nhttps://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://jon-gabilondo-angulo-7635.medium.com/how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191"
	],
	"report_names": [
		"how-to-inject-code-into-mach-o-apps-part-ii-ddb13ebc8191"
	],
	"threat_actors": [
		{
			"id": "08c8f238-1df5-4e75-b4d8-276ebead502d",
			"created_at": "2023-01-06T13:46:39.344081Z",
			"updated_at": "2026-04-10T02:00:03.294222Z",
			"deleted_at": null,
			"main_name": "Copy-Paste",
			"aliases": [],
			"source_name": "MISPGALAXY:Copy-Paste",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1775434516,
	"ts_updated_at": 1775791359,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a6a426dd0a99d8587b3f0d6fc944ae51eb03a492.pdf",
		"text": "https://archive.orkl.eu/a6a426dd0a99d8587b3f0d6fc944ae51eb03a492.txt",
		"img": "https://archive.orkl.eu/a6a426dd0a99d8587b3f0d6fc944ae51eb03a492.jpg"
	}
}