OVER TWELVE YEARS AGO, when Apple started down their path to perdition and introduced code-signing as a seeming compensation for their infamous lack of mobile security, we cracked their code-signing mechanism almost accidentally and published the results at our forum.
https://rixstep.com/2/2/20090218,00.shtml
We mentioned at the time that, although we'd not bothered trying to automate the process, we were sure it could be done, as it required only following published APIs.
No attention was given to this piece - and for good reason, it turns out. Apple's control over their media is intense - they didn't want their cash cow to turn up with dry milk.
As Apple's grip on the software market tightened, it became increasingly apparent what they were up to. Today on the desktop alone Apple take home about USD 70 billion per annum, only for independent software titles passing through their servers. This seems outrageous in the obscene, and Apple have consequently been condemned by Forbes, Fortune, and the New York Times.
Given this deplorable state of affairs, we're contemplating the development and release of a free utility to strip Apple software according to the methods outlined above.
In the meantime, we have something else to offer: a full description - without source for the moment - of how one defeats Apple's dreaded Gatekeeper and rescues one's software (and freedom) on one's own computer, one's own property.
Apple's Walled Garden
Apple's walled garden has become something of a concept, but a concept not well understood by the talking heads of the Apple MSM. So let's look a bit at what'is going on, keeping in mind that the ultimate goal for Apple is to make money for nothing.
Apple wins a lot by this approach, even in the long term, at least in theory. If they can control what software runs on their platform, then they can stop software that doesn't make their platform look good. For example, software that looks different or crucially software that shows them up in some way. Apple will often lie to their customer base and keep things hidden and out of sight, their file manager Finder being of course the prime example.
Apple will clean up even if none of their indy developers ever bring a single product to market. That's how the scheme's been designed. The 'ante' into the world of App Store distributon costs $100 per annum. Right there Apple take home hundreds of millions. For nothing.
But when a developer actually has an application for Apple's App Store? The application is submitted to Apple. If they approve, it's code-signed and put on the App Store, and Apple will take 30% off the top in 'Apple tax'.
The software in question is modified by Apple. Apple modify the software's section headers, adding indexes to their own code-signing data and their own root certificate. The system's launch services can determine at launch time if the binaries are further modified. Apple's own Xcode contains mechanisms and instructions on how this is done at the developer level, and Apple have an entire WWDC lecture on this subject. When a software bundle is received and approved by Apple, it is sealed again, this time with Apple's own root certificate.
Certain applications, such as our CLIX, need their own consistency checks for security purposes, and Apple's code-signing is not foolproof but CLIX security must be.
Things happen to a software bundle when it's downloaded onto an Apple system. Apple systems are programmed today to mark almost everything. Initially this mechanism occurred only through Apple's own web browser Safari, but the technology has since migrated into the realm of system services. Safari still sends out a notification when something's been downloaded.
These 'markings' on the download: they're in the form of extended attributes.
Extended attributes are file attributes outside the normal scope of file system attributes. On Apple's platforms they were introduced about the time of the iPhone.
Extended attributes are found on many versions of Unix, but they're never used the way Apple use them. Extended attributes were considered some fifteen years ago for OpenBSD, the by far most secure Unix available, but they were never implemented.
Minding The 'Gap'
A lot of Gatekeeper configuration is built into App Store software. Once Gatekeeper sees a new application, it will enforce this configuration. But what is Gatekeeper?
Gatekeeper is Apple's way of controlling things in their walled garden. It's not represented by a single module such as Gatekeeper.app or Gatekeeper.framework but as a series of interconnected code modules.
But to work with a software bundle on an Apple system, Gatekeeper has to find what it's looking for in the software bundle. Legacy software on an Apple system is ignored. There are too many components in an Apple OS that will never be signed. Gatekeeper must ignore them.
This is the key to defeating Apple.
How does Apple know when to let Gatekeeper regulate a download? By checking the extended attributes - in particular the extended attribute com.apple.quarantine.
The purpose of extended attribute com.apple.quarantine is exactly what the name implies - Gatekeeper is to hold the download in 'quarantine'. Once Gatekeeper isolates a download and puts it in quarantine in its own databases, the game is over - unless the launch services caches are purged.
The trick, therefore, is to rid one's downloads of their extended attributes before Gatekeeper finds them. Normally it'll be the system launch services that alert Gatekeeper. The system launch services will learn about the download first when the user tries to open it. So the trick is to get at downloads before the user does.
Apple had an easier time of it with their mobiles. Those platforms were completely new. Apple built their technology into the kernel there. The mobile kernels need to find the section header in question or they're just not going to run your app. This is impossible on the desktop.
And this is the Achilles Heel of Apple's plan.
What's needed, therefore, is a way to automate 'cleansing' downloads. That's what we've done.
Changes
This discovery came about on an expedition to find an equivalent to Microsoft's (Dave Cutler's) file change notifications.
Contrary to what the name may imply, file change notifications do not work on a per-file basis but a per-directory basis. Cutler's file change notifications are implemented on a very low level and work as synchronisation objects. Apple have a file system events API that's much more sophisticated (some would say too sophisticated). Accessing this API is the key to unlocking Gatekeeper, and use of this access therefore became our Keymaster.
Apple's file system events module can be fine-tuned to notify the client whenever there's been a download. Requests for notifications specify a target directory. The API will report recursively on changes to the specified directory.
A user could in theory watch for all directory changes throughout a system, but that would overburden the system. It's much more sensible to watch only the directories where downloads are expected - such as the default location ~/Downloads. But on Keymaster this of course is configurable.
To Apple - The Way In
The way in. The path to corruption.
Build your app as you always do.
Start the code-signing process.
Check the WWDC clips to review.
Make sure your dependencies are sealed in the correct order.
Finish by signing your main module.
Submit to Apple. (Did you pay your annual $100?)
If approved, Apple will tack on their own root certificate.
You may not at this point make further modifications to your software bundle. If you really need to do this, your software must be submitted again, even if it's a bug fix that your clients are desperately waiting for.
Keymaster - The Way Out
The MO is therefore the following.
Open or create a Keymaster document.
Click 'Go' or select 'Go' from the menu.
Go about your business as before.
Keymaster performs two sweeps upon receiving a notifiction from the file system events module. Should something be amiss, simply stop and restart Keymaster again.
Keymaster is fast, very fast. Keymaster uses low-level APIs to recurse through targeted directories, finds extended attributes, and removes them. You won't even know Keymaster is there. But you won't be nagged or coerced by Apple's Gatekeeper anymore.
Transparency
Apple's extended attributes are visible through all of Rixstep's file management utilities but are not visible with Apple utilities.
The Keymaster Effect
Keymaster makes it possible for users to more easily accept software without going through Apple's App Store. Apple's App Store can provide exposure for vendors but the price is high. Through no achievement of their own, Tim Cook's Apple exact $70 billion in additional fees on a yearly basis. This is part of the reason Apple's been condemned by Forbes, Fortune, and the New York Times.
Visibility
You're not likely to read about this anywhere but at this site. Apple don't want you to read this or know anything about it.
'Given adequate preparation and linkage editing tools, it should be possible to remove code signing from any Apple OS X executable with the greatest of ease. And, given the fact that someone created this codesign tool to add gunk to binaries, it should follow that someone can create another tool to remove it.'