Apple Mercenaries

Despite the media hype, Apple's cryptographic seals are not secure.

Get It Try It

To an ordinary human being, the atmosphere inside Apple's One Infinite Loop must be downright nauseating. What's happening to Apple's core operating systems is criminal, an effrontery to those who respect OS technology. It's a toxic mixture brought on by a few people who resented the fact that NeXT actually saved them from bankruptcy (and made them look the fools in the process) and later by a limitless greed for the power and riches normally reserved for the 'major players'. With no clue about how their wanton acts of destruction would affect their systems down the line, they went at it, pulled out wires at random, destroying entire chains of APIs. And hey, if things go terribly wrong, and they're bound to, given how things work there, they just hire on a few more neophytes to clean up the broken code.

It's impossible to define 'Apple'. Steve Jobs couldn't, and he cofounded the company. When Steve Jobs returned in 1997 and spoke in public about it, he couldn't say what the company represented or what it would become.

The one thing that perhaps summarises 'Apple' is an aversion to technology. Several software 'evangelists', as they like to call them and of course including the infamous Guy Kawasaki, unite under a banner of actually being allergic to all things technical. Guy's well-known book on his history at Apple is available online for free today. Find it and download it and take a look. It makes no sense. It's totally lacking in the kind of logical real-world thinking normally associated with the industry.

Nasty comments by Cabel Sasser such as open source needing a 'PhD in Torvalds' say it all. Apple fanboys, both outside and inside the Morlock catabombs, hate technology. They fear it. They have a genetical aversion to it, built into their DNA. How else to explain their exuberance at seeing a new gadget that will let them receive phone calls and also play Angry Birds?

That isn't beauty. Consumer products aren't beautiful. They sell well or they don't. They have no intrinsic beauty, any more than the biblical golden calf.

Apple fanboys, both inside and out, can't see the beauty in this, nor perceive the beauty in the thinking behind it.

main()
{
    printf("Hello world.\n");
}

If you showed them Brian Kernighan's leading paragraph on the explanation, they'd be bored. Their eyes would glaze over.

Programmers today are mercenaries. They're not in it for the beauty of their field. They're in it for the money. Aesthetics are not considered. Theirs is a nihilistic world. Bigger and bigger corporations gear up to make millions on micropayments whilst the real innovators live in cold-water flats, trying to achieve something of true benefit. The Morlocks will co-opt you when the time comes, if they think they can profit by you, but they'll neither show nor feel regard for you personally. You'll be discarded as soon as they figure out how to cut you out of the loop.

Apple in particular have come upon the ultimate in latter-day slave labour. Why waste money hiring on people to sit in stuffy little cubicles, and give them reasonable wages, together with health insurance and dental plans, when they can get you for free, and even get you to pay them up front for the 'privilege'? Why, indeed?

You can create and market and sell software for open source platforms such as FreeBSD and Linux with no up-front costs or application fees or membership fees, a rancorous idea that would never float in those worlds. You can do that as well for Microsoft platforms. You can even do that for Google's Android platform, if that's your cuppa. But you can't do that with Apple.

Working with Apple... Ahem... First you need to join their so-called 'Developer Programme'. This will cost you USD 100 up front. (Actually that's a lie. It costs only $99. See? You're saving money already!) That USD 100 gets you nothing save access to the Apple software, including development tools, that used to be free and openly available.

Now you set about to write your Minimum Opus, completely oblivious to the fact that Apple will nevertheless ignore you and prioritise the 'big league players' they so gleefully work with to create the products that will continue to attract consumers to their platforms. You're the 'token n*gger'. You're the shining example they can use so they can argue that they're still being 'fair'. And so far it's only cost you US 100. It costs them nothing. They don't pay your wages. They don't provide health insurance or a dental plan. It's a cruel world and you're the sucker.

Finally, at long last, you have something to show for your efforts. It's time to submit to Apple. Note that the product you have yourself will not be the same as the product, if you're lucky, that Apple will release on your behalf. Your product, if approved, and it's a long and very arbitrary process, will be altered by Apple. All Apple will tell you is that your product has been cryptographically sealed. It can no longer be altered, even by you. Not a single byte anywhere can be tampered with. And only through a long and egregious process could you ever hope to know if Apple actually changed anything in your code. Your product is no longer yours. Oh yes, you'll get shit if something goes wrong, but you no longer have control. Apple took control.

Technically speaking, there are any number of standard Unix operations you can no longer use. Those operations are fine on any other Unix, but not here. For reasons that vary, you can't use them any longer. Perhaps it's a far-fetched fear that something bad might happen to your customers, through no fault of your own. But it's more likely that you may have inadvertently exposed a few warts in Apple's own code. You may have made them look bad by merely writing better code yourself. There are so many strange links in the tangled web of lies at Apple that it's impossible to say.

Or perhaps they simply don't like you. You have a reputation for speaking out, for holding those in 'power' accountable, for embarrassing Apple. Then you can count on your product being denied.

And if your product is approved? What happens then? Consider the fact that your consumers will be running code with a cryptographic seal, where that seal is held in place by a so-called root certificate that belongs to Apple and only Apple. How can your system verify the authenticity of that seal, of that root certificate that supposedly belongs to Apple? Why by phoning home of course! This means that, at least in theory but more likely also in practice, your application launches, no matter where you are on the planet, are in realtime monitored by Apple. This of course means that Apple can log all activity on your computer. It also means that they can throw the so-called 'kill switch' on your software anytime they want.

Is this the kind of software you want? Is this the kind of world you want to live in?

Your consumers discover a bug in your product. They alert you. They're not entitled to an immediate fix. You may be capable of fixing the error in a matter of minutes. But it doesn't matter. You can't get that fix to them.

Instead you'll have to submit your product to Apple again.

Who tests your product at Apple? Perhaps, the first time around, your product was tested by someone in a really good mood. He had a good weekend. He ate well and drank well and got laid several times each day. He liked your program. That day he liked everything and everyone.

But, since then, things have gone a bit sideways for him. His wife refuses to carry his child, she's already had two abortions she admits to, their marital bed is cold and he mostly sleeps alone in the guest room, and, as for food, he mostly eats takeouts on his own and he doesn't know where his wife eats, or mostly even where she is, and she's not often home at night either. In fact, she's talking about going home to her mother, divorcing him and taking him to the cleaners, and the neighbours are even talking about how he's been abusive towards her and seems to have a history of visiting Beverly Hills hotel rooms with Harvey Weinstein. To top it all off, this morning his car wouldn't start and he was forced to call the towing company. And it's been raining.

And then he sees your program on his virtual desk.

Apple's system is built for total control and for maximum profit for Apple. That system isn't built for you. That system didn't have you in mind at all. That system is not built to promote open source or creativity or maximum throughput to the consumer. But you still get to keep a generous 70% of the money you make.

You've noticed that Apple will never quote their 30% commission, three times tne industry norm? Never. You the creator get to keep 70%. Isn't that grand?

Fighting the XA

Several document-based Rixstep applications combat Apple XAs. What they use is a delayed method call to cleanse XAs after the fact, by waiting until the insidious document controller (NSDocumentController) is finished impregnating your files. This is an arbitrary timed delay, as there's no way to programmatically know when the controller is done. The delay value may change over time to keep pace with the controller.

[Apple no longer save files the way the original NeXT code saved files. NeXT code actually saved. Apple code obliterates old files, then creates new ones in their stead. You can see this in the change of inode. Apple never open an existing file for writing.]

At least one application - Rixedit - also looks for XAs upon opening files, this because the extremely annoying 'last used' attribute is sometimes impregnated already on opening a file.

This additional code costs of course, but it can be removed as soon as Apple come to their senses (which unfortunately may be never).

Several applications also implement Rixstep's proprietary 'Seahaven Technology' which taps into system notifications generated by Safari on every download. Note that this is limited to notifications from Safari, not the system as a whole, and will not be sufficient unto itself.

Several other applications tap into Apple's answer to directory notifications, the turbo system known as 'file system events' (FSEvents). This system was likely created for the benefit of Spotlight, an Apple technology strictly not used at Rixstep. But the FSEvents streams provide an incredible amount of data on everything happening in your system, and just viewing the activity going on all the time can be quite the shock. This collection is most readily seen in the Rixstep application Changes. Believe us, what Apple can do to an innocent system is downright brutal.

The weapon using the technology assembled in Changes is Keymaster. Keymaster taps into FSEvents streams and counteracts (neutralises, nullifies) the actions of Apple on your files, protecting their 'innocence'. You are once again free to do as you please on your own computer, without being stuffed into restrictive cubbyholes by Apple. Keymaster can selectively stand sentry at any directory in your file system, record intrusions by Apple, and remove what Apple have done.

Other Cocoa applications and command line tools are also made available for batch processing and for investigation and amelioration of issues with individual files. Several high-profile ACP file management applications also alert you instantaneously to the presence of these damaging Apple XAs.

You'll need a better and safer platform as time goes on, but your situation will be doable for now with Rixstep's ACP. The wisest investment you can make right now.

Apple & CLIX

CLIX is perhaps the software title Rixstep are most known for. CLIX is a highly sensitive piece of software. Countless lines of code have been devoted to protecting the application's integrity. To date, no one has succeeded in cracking the application.

Part of the reason for this 'impregnability' is an integrity protection system proprietary to Rixstep. Code-named 'Houdini', this technology has certain similarities to the real counterpart. The challenge at the Rixstep labs was to create a system whereby a 'lock' is placed on the outside, but placed there from the inside. As incongruous or as impossible as that sounds, that was what was needed. It was only a matter of working out how that would be possible.

As opposed to Apple's nefarious schemes, which can be broken, the methods for which were demonstrated over ten years ago for an underwhelmed fanboy audience, the CLIX scheme cannot be broken. The CLIX seal is not applied from the outside, as with Apple seals, meaning they can be removed from the outside as well. The CLIX seal is applied from the inside.

The CLIX 'Houdini' seal offers CLIX users 100% security. Replacing this seal with a cryptographic seal from Apple would endanger CLIX users.

About Rixstep

Stockholm/London-based Rixstep are a constellation of programmers and support staff from Radsoft Laboratories who tired of Windows vulnerabilities, Linux driver issues, and cursing x86 hardware all day long. Rixstep have many years of experience behind their efforts, with teaching and consulting credentials from the likes of British Aerospace, General Electric, Lockheed Martin, Lloyds TSB, SAAB Defence Systems, British Broadcasting Corporation, Barclays Bank, IBM, Microsoft, and Sony/Ericsson.

Rixstep and Radsoft products are or have been in use by Sweden's Royal Mail, Sony/Ericsson, the US Department of Defense, the offices of the US Supreme Court, the Government of Western Australia, the German Federal Police, Verizon Wireless, Los Alamos National Laboratory, Microsoft Corporation, the New York Times, Apple Inc, Oxford University, and hundreds of research institutes around the globe. See here.

All Content and Software Copyright © Rixstep. All Rights Reserved.