There seem to be many ways to Codesign and even an app that is no longer supported, but it's all a bit confusing, and I'm more confused after reading a similar thread on here called, "New to Codesign."

Is there a simple way to Codesign one app or one plugin after it's been installed?

Thanks!

 

Code:

Apple has locked down macOS a lot lately, and some of the main components of this lockdown are code-signing, notarization, quarantine, and Gatekeeper. Even applications signed with legit code-signing certificates (CSCs) will not launch on Catalina, if they haven't been notarized by Apple. (Some might launch, but they will in all likelihood be translocated to an ad-hoc sandbox, losing functionality, file system access, throwing errors etc.) It's the same for cracked software: as part of a crack, one or more files in an application bundle will have to be modified, and this breaks the integrity of the app's original code signature. Some cracking teams re-sign the app bundle with their CSC, but in almost all cases without an Apple-issued CSC, and definitely without notarization. Therefore, cracked applications will fail upon launch at first.

The reason is Gatekeeper, which blocks the app's execution. In the past you have often heard that you should disable Gatekeeper, but that's definitely not necessary, and if at all, it should only be a last resort. The reason is that Gatekeeper itself doesn't jump into action by default. Rather, the Gatekeeper scan is triggered by an extended attribute (XA) called com.apple.quarantine. Every file downloaded in the GUI by traditional means to the user's macOS volume will receive such a quarantine XA. So the way to get a non-notarized application or command-line interface (CLI) to launch or execute is simply to remove the quarantine XA from the file.

This should be the first step to undertake, after you have downloaded a file containing a cracked app. If it's a zip or any other archive, don't expand it just yet; if it's a DMG, don't mount it just yet. Before you do that, you have to remove the quarantine XA first. The reason is that this XA is inherited by all files that will be extracted from the archive, or copied to your volume from the DMG. The command to dequarantine a file is xattr -dr com.apple.quarantine /foo … please note that /foo is just a placeholder for the full path; in Terminal or iTerm, you can just type in "xattr -dr com.apple.quarantine", add one more whitespace, and then drag the file you want to dequarantine and drop it into the Terminal/iTerm window: the actual path will we printed, and you can just hit [RETURN]. Please also note that sometimes there are quarantine XAs attached to a cracked (or legit!) app, even if you removed the XA from your download. This happens when e.g. a developer's build processes slap those XAs onto code that is later nested in the final build, or when a cracker doesn't remove his own system's quarantine XAs from the app before or after applying the crack & distributing it. So sometimes you have to also dequarantine the final app again that you've copied into your Applications folder. To see if there are any XAs left from the originating file system, you can run xattr -l /foo

In many, if not most cases, removing the quarantine XA is sufficient to get an application running that is cracked, unsigned, without code-signing integrity, validly signed but not notarized, or signed with a third-party certificate: the dequarantine procedure will ensure that Gatekeeper remains asleep, and that the app, upon first launch, will not be scanned. Since it might be too tedious for some users to always remove the quarantine manually, there are some automated ways to do it: you can use the application Hazel to automatically run the above command on every file downloaded to any of your download locations, or you can use Rixstep's freeware tool Keymaster Solo, or you can use Rixstep's appleclean command-line utility, which removes the quarantine XAs of all files in the folder that it's executed in. The problem with these automated or broad approaches is that you will dequarantine all downloaded files, even the ones that don't need it. So you also have the option to use our own DeQuarantine shell script, distributed as a Platypus app, which you can use to manually remove the quarantine XA using the GUI. Of course, you can also create your own Finder QuickAction in Automator that will run the xattr -dr com.apple.quarantine command.

Some applications, however, are secured more tightly, e.g. by applying library validations or self-checks on their own code signature. A good cracker can find those self-checks in the code and disable them. Other problems might arise from applications that are cracked, but not re-signed by the cracker: some applications might just fail even with the quarantine XA removed, or the application wants to install privileged helper tools that macOS will block, if the code signature has not been applied correctly, or the application has certain components or functionality that otherwise require a valid & unbroken code signature. Then you probably have to re-codesign the app yourself. First you need to remove all XAs and Finder detritus from an application with the command xattr -cr /foo—otherwise code-signing will fail. The next step is the signing itself, which always revolves around the basic command codesign --force --sign <commonName> /foo … the argument <commonName> is the x.509 common name of the CSC you are using. If you don't have a CSC in your macOS keychain, just use the dash - to give your app a so-called ad-hoc signature.

There are three ways to go about code-signing an app, two quick & dirty approaches, and one discrete approach. Interestingly, the quick & dirty approaches often work, and you can use our own tool CodeSigner for some of the procedures below. But you can also do it manually: with the first quick & dirty approach you apply a standard code-signing run (for the command see above), and if that doesn't work, you can apply a deep code-signing run with the basic command codesign --force --sign <commonName> --deep /foo … please note that if the target is not writable, you either have to move it to a location owned by you, e.g. the Desktop, apply the code-signing there, and then move the target back. Or you can leave the target where it is, and execute the codesign command with root privileges by running it as sudo codesign instead of just codesign. If you sudo-codesign a target with a non-Apple CSC, the process will only seemingly work, because the signature will be invalid ("unavailable"): sudo-signing apparently only works with ad-hoc signatures or with CSCs issued by Apple. If you don't have an Apple-CSC, and if you don't want to apply an ad-hoc signature, you have to move the target to a location that is writable, and change the ownership of the target, e.g. from root:wheel or root:admin to you, e.g. to 501:20. Then you can codesign with your own third-party CSC, move the target back, and switch ownership back to its original setting.

The more discrete approach is to first examine the cracked app with the command codesign --verify --deep --strict --verbose=4 /foo to see which components in the app bundle have been altered. The codesign command will print a list of modified or added files at the end of the output. If the modified code is a nested bundle, e.g. an updater app within a framework, you have to execute this command for the nested bundle as well. Then you just need to re-sign only those modified or added components one by one, without using the --deep argument, starting with the file that is located deepest in the app bundle, and work your way up until you reach the root of the bundle. As the last step, you sign the app bundle itself, again without using the --deep argument. Please don't forget to always run the xattr -cr /foo command, unless you use a file manager that doesn't leave behind detritus like macOS Finder does. The discrete way to re-sign is often necessary with apps that are more complex, that have nested code, special frameworks, or will try to install privileged helper tools. Sometimes it's sufficient to use an adhoc signature, but in many cases, especially with privileged helpers, you will need a real CSC; it doesn't need to be a CSC issued by Apple, so a third-party CSC, e.g. a self-signed root, could already be enough. Nota bene: to get a Safari extension to work, you will most probably need to re-sign using an Apple-issued CSC, and you can get an Apple Development CSC for free, if you have an Apple ID, a free Apple developer account, and Xcode installed.

But sometimes even the discrete way to re-sign an app bundle will fail. This is often due to certain requirements or entitlements slapped onto specific components during the original signing process performed by the developer. You can print or export those original requirements and entitlements, when you examine the uncracked trial version of an app. The command codesign -dvvvv --requirements reqs.txt --entitlements ents.xml /foo will export the original requirements and entitlements of a file, and if you re-sign a file, you can add those original entitlements & requirements with codesign --force --sign <commonName> --requirements /bar/reqs.txt --entitlements /bar/ents.xml /foo … please note that like /foo, the term /bar is just a placeholder for the actual path. Before applying requirements and entitlements during code-signing, you first have to examine the contents of req.txt and ents.xml, because (a) they might need cleaning up, especially the xml, and (b) those files might contain references to the original developer's CSC or the Apple Team ID. If that's the case, you need to substitute those parts to reflect your own code-signing certificate.

But using the method of applying specific requirements or entitlements is usually not necessary, not even for a crack that wants to install a privileged helper tool. We have yet to come across an app that requires such an approach. Usually, if you sign a privileged helper or an auxiliary service, it's sufficient if the code signature of the helper is the same as the one of the main app bundle. The codesign command will not add any specific entitlements, but it will at least automatically add a basic version of the right requirements to the cracked executable. The only thing that's necessary in most cases is that the signature of the cracked component matches that of the main app bundle.

However, it can still happen that an app doesn't launch, for example if it's a crack that doesn't disable signature self-checks or library validation, which you might e.g. encounter in security- or privacy-related software. A new code signature applied to a non-working crack after-the-fact will most likely fail. In those cases, you can only ask or hope for a better crack. A quick remedy is to disable a specific part of SIP, macOS' system integrity protection: restart your Mac and boot into Recovery Mode using [CMD]-R, open the Recovery Terminal and execute csrutil enable --without fs, which will keep all system protections enabled except for filesystem security. If this is too much of a risk for you, and if a better crack isn't on the horizon, then the only option left is to buy a software license & go legit.

 

Yeah, I had a plugin not launch and ended up trashing it . . . more trouble than it's worth.