How to Tell If Your Mac App Has Been Cracked

Fortifie — Sun, 15 Nov 2026 16:49:58 +0000

Search your app name plus "crack", "cracked" or "free download" on Google, warez and torrent sites, and GitHub. Record those listings by URL and screenshot; do not download from them. If you already have a copy, inspect it with codesign -dv --verbose=4 and spctl -a -vv without launching it, then compare Team ID and cdhash to your release. https://fortifie.xyz/cracked runs the listings search faster, a search of public listings, not proof.

This guide is for the developer who published the app, not for someone seeing a Gatekeeper warning. A cracked copy can appear on a warez site, a torrent index or GitHub without showing up in your analytics.

How to check whether your Mac app has been cracked

Start with a search, not a download. On Google, query your app name plus "crack", "cracked", "free download" or "dmg", and quote the name if it is generic. Repeat those queries on Mac warez sites and torrent indexes, then search GitHub for the app name, your bundle ID, or a distinctive Info.plist string.

Do not download anything from a crack, warez or torrent listing; record that listing by URL and screenshot only. If you already have a copy, for example one a user sent you, keep it in an isolated folder. Do not launch the .app or drag it into /Applications. Mount a disk image if you have to, then point the tools at the bundle inside.

codesign -dv --verbose=4 /path/to/Suspected.app

The codesign(1) man page describes --display (-d) as printing signature information; higher verbosity produces more fields. At --verbose=4 look for Identifier (usually your CFBundleIdentifier), TeamIdentifier (your Apple Developer Team ID), CDHash (the code directory hash for that architecture), and Authority (the certificate chain, typically Developer ID Application on a direct-distribution release).

Compare TeamIdentifier and CDHash to the same output from the build you shipped. Apple's TN3126: Inside Code Signing: Hashes explains that the cdhash uniquely identifies the signed code. Matching values mean an unmodified copy of that signed build. A missing or ad hoc signature, or a different cdhash on a bundle that still looks like your app, can mean a patched or re-signed copy.

For a universal app, codesign --display reports the native architecture of the Mac you are using, so check each slice with --arch arm64 and --arch x86_64. Display does not fully prove the signature is intact. The man page notes that --display is not a complete verification, and that --verify does not apply Gatekeeper or other OS policy. Also run:

codesign --verify --deep --strict --verbose=2 /path/to/Suspected.app
spctl -a -vv /path/to/Suspected.app

spctl --assess (-a) asks the system policy subsystem whether the file would be allowed to run. The default type is execute, and verbose output typically includes accepted or rejected plus a source= line such as Notarized Developer ID or no usable signature. This is a policy check, not the same as opening the app. See Apple's TN3161: Inside Code Signing: Certificates for Team IDs, codesign --verify, and syspolicy_check.

https://fortifie.xyz/cracked is a free search of public listings for your app, not proof.

Don't run the cracked copy

Treat an untrusted copy as malware until you have a reason not to. Warez installers often carry unrelated payloads. Your release records, plus the signature and file comparison below, can confirm whether a copy you already have is your build.

codesign and spctl read the bundle and its signature; they are not the same as launching the app from Finder. For more isolation, inspect the copy in a virtual machine with no development keys or customer data, or just read the signature, Info.plist, resources and hashes.

Confirm it's your build

Match the version and the files

Compare CFBundleShortVersionString, CFBundleVersion and CFBundleIdentifier in the copy's Info.plist to the release you shipped. Then compare file hashes for the main executable and, if you still have it, the shipping archive.

An unmodified leak matches your release exactly: same cdhash, same Team ID, same file hashes. A patched crack will not, because the binary has changed, so also compare the bundle ID, version, icons and other resources.

Record where and when you found it

Keep the URL, the date and time you found it, screenshots, and, for any copy you already have, the codesign and spctl output, the version string, bundle ID, Team ID and cdhash. Do not depend on the listing staying up.

Find the other copies

Listings get mirrored quickly. After you find one listing, search again for the app name and distinctive strings on GitHub, torrent indexes, Mac warez sites, file hosts, and Telegram or similar groups, and record each new listing by URL and screenshot.

https://fortifie.xyz/cracked can run a free search of public listings for your app, not proof.

Send takedowns the right way

This is not legal advice. Talk to a lawyer if needed.

Use a DMCA 512(c) copyright notice, not 1201

A notice under 17 U.S.C. 512(c) is a copyright notice to a service provider that identifies your work and the infringing URL. A claim under 17 U.S.C. 1201 is about circumventing a technical protection measure, not about the hosted copy of your work.

GitHub reviews copyright notices under its DMCA Takedown Policy. In a Hacker News thread about copies of Photopea, a 1201 notice sat unresolved for weeks. File a 512(c) copyright notice that lists your work and the exact URLs. A notice on one URL does not clear every mirror.

Notify the host, then the search engines

Send the notice to the host or platform, then ask search engines to drop the listing:

Google's process for removing content
Microsoft's infringement notices, which cover Bing

What should you do if your Mac app is cracked? Record the listing by URL and screenshot, check any copy you already have without launching it, search for mirrors, file a 512(c) notice with the host and then with search engines, and keep honest licenses working offline. Harden the next release, and skip a hostile update that breaks paying users.

How do you get a cracked app removed from GitHub? File a 512(c) copyright notice that identifies your work and the repository or file URLs, following GitHub's DMCA Takedown Policy, then check for mirrors. A notice on one repo does not clear copies hosted elsewhere.

Keep paying customers working

Do not ship a panic update that breaks honest licenses or adds a new online check that fails offline. A hostile update often misses cracked copies, which will not update, and can anger paying customers. Keep offline use working for valid licenses.

Make the next crack cost more

Code signing and notarization are worth doing, and they are not a crack barrier. Apple's guide to notarizing macOS software describes notarization as a check for malicious components in Developer ID-signed software you distribute, and as a ticket Gatekeeper can use. A patched copy can have its signature stripped or replaced, so your release ticket does not cover the new cdhash. Users can also override Gatekeeper.

In the next build, make the license path slower and more expensive to reverse engineer, including with AI-assisted tools, without turning the app into a maze for paying users. Avoid a single obvious branch that returns "licensed" or "not," and keep the unlock tied to a signed grant that still works offline. This raises the cost of a patch; it does not make cracking impossible.

When to just let it go

Not every listing is worth a week of your time. If the host ignores notices, or chasing mirrors would cost more than the next release, document what you found and move on.

Fortifie Leak Finder searches public GitHub and web results for listings by app name. A name hit is not a confirmed copy of your build: you still do the signature and file comparison above. You can also upload a recovered file you already have; Fortifie hashes it and, for protected JavaScript builds, checks whether it carries your account's fingerprint. Fortifie drafts a takedown notice for you to approve and send; it does not send the notice. https://fortifie.xyz/cracked is a search of public listings, not proof.

FAQ

How do I know if my Mac app has been cracked or pirated?

Search your app name plus "crack", "cracked" or "free download" on Google, warez and torrent sites, and GitHub. Record those listings by URL and screenshot; do not download from them. If you already have a copy, inspect it with codesign -dv --verbose=4 and spctl -a -vv without launching it, and compare the Team ID and cdhash to your release.

Can I stop my Mac app from being cracked completely?

No. Signing, notarization and license hardening raise the cost of a crack. They do not make cracking impossible.

Does a DMCA notice remove a cracked app from GitHub?

GitHub reviews 512(c) copyright notices under its DMCA Takedown Policy. Identify your work and the infringing URLs, then check for mirrors.

Should I use a 512(c) or a 1201 DMCA notice?

For a hosted copy of your app, use a 512(c) copyright notice. A 1201 notice is about circumvention of a technical measure, and it can stall, as developers discussed in the Hacker News thread about Photopea copies on GitHub.

Will notarization stop someone from cracking my app?

No. Notarization tells Gatekeeper that Apple checked your Developer ID-signed software for malicious components. It does not prevent someone from patching a local binary, re-signing it ad hoc, or overriding Gatekeeper.

How do I know a cracked copy is actually my app?

Match the Team ID and cdhash to your release for an unmodified copy. If the binary has been patched, those will not match, so also compare the bundle ID, version, icons and resources.

Should I ship an update that breaks the cracked version?

No. A hostile update often misses people on the cracked copy, who will not update, and it can break paying customers. Keep honest licenses working offline.

Found a clone or a re-skinned copy rather than a crack? Read Someone Cloned My App: How to Prove It and What to Do.

DEV Community: Fortifie