In yesterday’s article, I discussed problems which can arise when first running an app downloaded from the Internet, or delivered via AirDrop, which became translocated and then locked out during its first run. Although the process of app translocation was introduced in macOS 10.12 Sierra, it continues to trip users up, and in combination with the more complex Gatekeeper checks in Catalina, may leave you baffled as to why an app won’t complete its first run successfully. This article steps through the processes involved, and explains how you can deal with problems arising in them.

Opening an app which has already completed its first run checks

Before explaining all the additional processes which can take place during a first run, it’s important to understand what Catalina does whenever you open an app which has already cleared those additional checks.

Provided the app is being run from a previously known path, there isn’t a full signature check, although quick checks are performed for services such as TCC, as required. These tolerate many types of error, and can’t be relied upon to verify the integrity of the app, or the provenance of its signature. Neither is the app’s notarization checked at all.

Every app (and command tool) now undergoes a check for malware by XProtect; if that raises a problem, then you’re informed in an alert, and the app is closed. Provided that completes successfully, launch proceeds, Transparency Consent and Control (TCC) builds its entitlements list, and it’s given access to resources accordingly.

Slightly different behaviour may be seen when the app is being run from a new path for the first time: this can trigger a full signature check before the XProtect scan. This is more sensitive to error which might otherwise be tolerated. A slightly damaged app is therefore more likely to open without error when it’s run from its usual location. However, you should then be asking why its signature check is returning errors.

Opening an app for the first time, without a quarantine flag

If the app has no quarantine flag attached, or if the quarantine flag is no longer ‘set’, for example being changed from 0083 to 00c3, then it’s treated as having already been run, and the only additional check which it’s likely to undergo is a full signature check, if it’s being launched from an unknown location.

It’s important to realise that, when you strip a quarantine flag from a downloaded app, you are disabling all the other checks which would normally take place in a full first run: this can allow apps with broken signatures and without valid notarization to run, and no app translocation will take place. When you’re completely confident that the app isn’t malicious in any way, this allows you to bypass first run checks, but should never be undertaken lightly or as a matter of convenience.

Opening a quarantined app for the first time

When the app has a quarantine flag attached, its contents are checked. If the flag value is ‘set’, such as 0081 (AirDrop) or 0083 (Internet), then the app is deemed to be in quarantine, and undergoes full first run checks.

The first of these determines whether it will be moved to a random folder by app translocation. This is specifically designed to combat an exploitation technique known as repackaging, which uses additional files supplied with the app in its folder or other delivery container. Translocation occurs if a quarantined app is still in the same location as any other files supplied with it. So if you drag the app out of its folder and run it from /Applications, translocation won’t occur. If you instead drag the whole folder from its point of delivery into the /Applications folder and run the app from inside its folder, then it will be translocated.

It doesn’t matter where the app has been downloaded to, as it applies to any download location, not just your Downloads folder. If you move the app by a method other than the Finder, then that won’t normally be recognised, and translocation may still occur. It doesn’t apply to ‘secure’ delivery methods such as signed disk images or signed installer packages, though.

Translocation still causes problems in some circumstances. The simple way to prevent it from occurring is to move the app to another folder, such as /Applications. If you really want to keep it together with the other files in its folder, move the app out, which stops translocation occurring, and move it back again.

Next in the sequence is a full signature check, which will usually involve connecting to Apple’s servers to verify the certificates, and check the notarization ticket. A few apps (mainly legacy products) may not contain their own ticket, and macOS may need to check their notarization with Apple. Normally, if an Internet connection isn’t available, these checks can still complete successfully using only local information, but some types of monitoring or blocking to their connections appear able to prevent completion.

Any error in signature(s) and ticket(s) should be taken seriously, as they are good indications that the app has been tampered with, or a certificate/ticket has been revoked. Old apps can have old certificates which have been revoked without any security concerns, but generally revocation should ring alarm bells. Failure of these checks normally results in the app being crashed immediately.

All quarantined apps also undergo scanning for malware by XProtect. If that completes without error, you will then be presented with the First Launch dialog, asking whether you wish to open the app. Provided that you agree, the quarantine flag will be cleared by setting it to 00c1 or 00c3, and the app will be launched, as TCC starts to examine its entitlements.

A short summary of key log messages is given in the Appendix below.

Unsigned and non-notarized apps

The standard requirement for apps in Catalina is that they comply with one of the following:

• The app is signed by Apple,
• The app is delivered from the Mac App Store, thus runs in a sandbox,
• The app is fully signed and has been notarized by Apple.

Apps which meet any of those three criteria should open without problems: the first two categories don’t normally get put into quarantine, and therefore don’t undergo first run checks, which are reserved for quarantined third-party apps.

Running newly-obtained apps which aren’t fully signed or properly notarized is still supported in macOS, and Apple has committed to keeping that facility in macOS. If they’re locally made or distributed, they may not gain a quarantine flag, and can be run normally, as they don’t undergo first run checks. However, if an unsigned or non-notarized app has been put into quarantine, you’ll need to select its icon and use the Finder’s Open command to allow it to bypass first run checks. It will still undergo scanning by XProtect for known malware, but other parts of those checks will necessarily be omitted. Use this bypass only when necessary, and when you have absolute confidence that the app isn’t malicious.

To help you understand first run checks more clearly, the following diagram presents a summary.

and here’s a PDF tear-out: AppFirstRunChecks10152

Appendix: Key log messages during a typical app first run with translocation

SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/4d/x76c3kn158q0mvbcjh8dy12h0000gn/T/AppTranslocation/FD855598-DFCA-4A82-9A0D-229C0C99035B/d/Ulbow.app
GK process assessment: <private> <-- (<private>, <private>)
Gatekeeper assessment rooted at: <private>
GK performScan: <private>, 1, 0
Xprotect is performing a direct malware and dylib scan: <private>
GK Xprotect results: <private>, <private>
GK scan complete: <private>, 4, 0
scan finished, waking up any waiters: <private>
App gets first launch prompt because responsibility: <private>, <private>
GK evaluateScanResult: 0, <private>, 1, 0, 1, 0, 4, 0
GK eval - was allowed: 1, show prompt: 1
Prompt shown, waiting for response: <private>
present code-evaluation prompt
Code evaluation completed: 2
Allowing code due to user approval