Ah, the never-ending quest of debugging on macOS applications – a rollercoaster ride of exasperation and determination! As developers, we’re often stuck in the labyrinthine maze of Apple’s restrictions, scratching our heads as we grapple with the desire to delve deeper into other people’s our code. The tech giant seems to have taken debugging as a secret art, guarding it behind layers of red tape and obscure documentation. Yet, our relentless spirit leads us to unravel the mysteries and force debug our macOS apps!
Normally, you are kinda allowed to debug your own apps, but not really. You can debug your own apps, but only if you have the source code. You can debug your own apps, but only if you have the source code and you sign them with your own developer certificate. You can debug your own apps, but only if you have the source code and you sign them with your own developer certificate and you have the source code for all the frameworks you use. You can debug your own apps, but only if you have the source code and you sign them with your own developer certificate and you have the source code for all the frameworks you use and you have the source code for all the frameworks those frameworks use. You can debug your own apps, but only if you have the source code and you sign them with your own developer certificate and you have the source code for all the frameworks you use and you have the source code for all the frameworks those -
You get the idea.
Yes, the paragraph above was written by codepilot, but it was TOO funny not too keep it in. 😂
Let’s go to the actual stuff:
Imagine you have a signed application that does not want to be debugged at all and magically crashed with a SIGKILL signal. What do you do? You did not even patch it or break signatures!
Maybe try attaching to the process directly instead of starting it from lldb? Nope
Maybe try a different tool (frida) since lldb might have random issues? Nope
Maybe try the “ugly” gdb? Nope
And it’s at this point that you start searching on google, and the 90% of results are garbage since they assume it’s your app and you missed the entitlement. That’s right, the funny man that was disallowing you to debug was in fact a missing entitlement.
And now comes the fun part:
- Read the current entitlements as follows (replace
daw.appwith the actual app name):
codesign --display --xml --entitlements daw.entitlements daw.app
- Open
daw.entitlementsin any text editor and insert the following text just before</dict></plist>at the end of the file (if the key is already there just change the value to true):
<key>com.apple.security.get-task-allow</key><true/>
- Apply the new entitlements as follows (replace
daw.appwith the actual app name):
codesign -s - --deep --force --options=runtime --entitlements daw.entitlements daw.app
In some cases this is enough and you can finally debug the application :D
But you wish it was this simple right?
Sometimes you might encounter the resource fork, Finder information, or similar detritus not allowed error, which basically means that “Another file inside the .app is telling you to fuck off and doesn’t want you to change the binary entitlements”
So what do we do?
According to Apple this protection was added in macOS Sierra, and an easy fix is to just remove the extended attributes and sign again:
xattr -cr daw.app;codesign -s - --deep --force --options=runtime --entitlements daw.entitlements daw.app
You just now have to hope that the binary does not check itself when running for modification of its entitlements, but that is an exercise left for the reader 🥸
Sources: