All Your Attribute Are Belong To Us

Unite.

Get It Try It

There's no danger really. Not more than there was two, five, ten, twenty years ago. The big danger has always been the Windows platform. That platform is wide open and will always be susceptible to attack.

Windows is still based on filesystem intrinsics from MS-DOS. That concoction had just over half a dozen file attributes, none of which could protect your files. The closest to protection was 'read-only' which could be removed by any user. There was no limit to system access anywhere. Anyone able to access the physical machine owned it. Put another more sophisticated way, there was no 'access control', much less the necessary mandatory access control adopted by the industry today.

Risking another slight detour: mandatory access control means that you as a user must - not can but must - determine the access rights to files you create. These rights in turn imply 'ownership' of files. But MS-DOS doesn't have ownership. You own the computer? You own everything on it.



The Windows Registry is the perfect place for crooks to hide. Early editions of Microsoft's Registry Editor let the user specifically decide whether changes would be saved to disk. Current versions save everything automatically in realtime. Many users balk at using the Registry Editor, as it seems so dangerous. Yet it's precisely here the crooks will hide. And wreak havoc.

A filesystem that can't protect a single file. A jungle known as the Registry where bad things can hide and never be found. That sounds like a turkey shoot. And indeed it was, and is. Anything can be perpetrated on a Windows machine. People who use Windows, be it for professional purposes or leisure purposes, are fools. There is no other word for it - they're fools.

Unix wasn't designed to be an Orange Book super-secure system. It just adapts that way. Unix was designed for collaborative use by a core crew of about twenty-five whiz-kid PhDs who liked to play around. Superficially they needed to also develop a system to process patent applications. But the system itself, Unix, was specifically designed to be a safe working environment for wild programmers that could also accommodate the more stereotypical uneducated 'end user'.

Access control wasn't discretionary. You couldn't opt to not protect your files. Access control was mandatory. Everything you saved to disk, everything you created, had an owner - you. Ownership extended to 'group rights', so any one of the user groups you belonged to could also be assigned rights to your files.

Directories were also files. In fact, directories were only files. Files that were read like any other file, but in a different context. Directories, as ordinary files, had read, write, and execute access.

You could, for example, make files or directories available for writing but not for reading. It was all up to you, the file's owner. As for executing? That's how you had to mark program files. Or scripts. Without that permissions bit, nothing would run.

Regarding directories, the executable bit meant you had the right to 'enter' that directory and learn about its contents.

Writing to a directory meant you could change the contents of a directory. That you could rename files in that directory, could remove files from that directory, could add files to it. Without that write bit, you could do nothing.

It became very clear that directories and files could in fact be protected, unlike the chaos that existed on Windows. Take the classic Visual Basic DLL trick. There is no comparable scenario for a Unix machine.

What the perpetrator would do is this. First off, be sure you understand what a DLL is. A DLL is a 'dynamic linked library', a shared library. For VB, they're always located in the Windows 'system' directory. They load and can start to run their code as soon as the Visual Basic program loads. That's the cute part.

So what the perp does is pick a likely DLL for the application they're going to corrupt, reverse engineer it a bit, add the nasty payload code they want in there, then optimise it until they get it back to the same exact size as the original (or pad it up).

There's also a 'resource' in Windows executables known as 'version info'. The perp makes sure this info is identical in the new module that's being created.

Finally, the perp has already made a note of the time stamps on the original DLL, and sets identical time stamps for the corrupted replacement module.

Then it's time to move the module in. But how to do this? Easy. Any old typical trojan trick. Some download the unsuspecting user is tricked into taking.

Most importantly: are there any restrictions on this by Windows? Of course not. At the very best, Microsoft has a kernel thread which intermittently checks the 'integrity' of system modules after the fact. It has to be after the fact because Windows is incapable of preventing sabotage before the fact. Incapable.

You can't do that on Unix. None of it. Files are owned by users whose accounts even admins can't touch, the files are located in directories which are just as well-protected, and those directories are often embedded in further super-protected directories. Ordinary users - even administrators - can't get at them. The system itself is impenetrable. That's the way Unix was designed. Not to protect against intruders at the time, but only against wild and crazy experimental code. But it still works fine for today's hazards. It protects.

Windows can't do any of that. There's no danger really. Not once you get off Windows.

Almost all the world is on Unix. Most web servers run Unix. The most popular web server is Apache, and FreeBSD has been very popular as a server OS. IBM's mainframe systems are still out there, but otherwise it's Unix. IBM will often run Red Hat Linux inside one of their mainframe systems.

That's on the one side. All alone on the other side? C:\WINDOWS.

Apple's 'Mac vs PC' advert campaign tried to drive this home. Until they decided it was better to portray their Macs as 'unsafe' instead. Then the marketing angle changed 180°. Now the Mac is unsafe again.

It was a necessary move. For Apple's business, that is.

Now the big danger is not the Windows trojan, but Apple.



It's hard to put into concise words what Apple did, but they worked hard at it. All that energy could have been put into more productive projects but instead was wasted on this. You almost have to give them credit, in a weird twisted sort of way, and the credit mostly goes to their marketing department, who must have overseen the whole thing.

What Apple achieved was the near-perfect convergence of seeming utility with near-total market control. Nothing but nothing should escape them. Every launch of every program on every computer anywhere in the world would be controlled, every one of them approved or disapproved by Apple. In realtime. You click on your favourite app and suddenly it won't run any longer. Because Apple, thousands of miles away, stopped you. Let that sink in.

Give tribute to Caesar. Every exchange of funds between vendor and consumer is through Apple who choose to levy a 30% tax which inevitably must be passed on to the consumer.

The prospect of even conceiving of such a scheme must have been daunting. How does one go about accomplishing it? What kind of CPU is necessary at runtime to implement it? And the strange NeXT application architecture means applications aren't single-file but huge bundles. Hives of files with a top directory hiding its file extension 'app'. And all this must be checked. And sealed.

To even think of it, to even think it could be possible...

_CodeSignature/CodeResources is a property list file. This property list file for Xcode is 81,751,344 bytes. That's eighty megabytes that have to be read into memory before the system even contemplates letting the application run. Let that sink in.

'files', it starts as its highest key. The 'value' of 'files' is a dictionary. A further recursive set of key-value pairs. Files in the bundle are now listed with relative paths as the keys. The values of the keys are message digests stored in a binary data format. Each value for each listed file must be checked.

There are 510,067 key-value pairs in the Xcode CodeResources file. Over half a million files which must be checked for integrity by reading in those files and comparing with the message digest values stored in CodeResources. One match that's off, and the system can refuse to launch.

How many CPU clocks does that take?

Then the seal itself. The executable, found in MacOS, has to be sealed with Apple's own root certificate. Only Apple can verify the authenticity of that certificate. A simple 'phone home' will do it. But is any of this really that simple?

All this is needed to launch your application. So much time and work, just to use your Calculator...

To what purpose? To prevent you the user from being whacked by a Windows virus? We're talking Unix here. Apple's Rock Solid Foundation™. Can this platform really be whacked by a hacker in his underpants at a computer thousands of miles away? What are the odds? Has Unix survived this long, evolved into Linux and Red Hat Linux, which IBM bought recently for thirty-four billion dollars, only to be lacking the kind of system protection scheme available from Apple? Are the millions of Unix web servers which dominate (three quarters) the entire planet all susceptible to attack without Apple's level of protection? Is the sky falling on everyone but Apple?

The fanboys don't dare ask. They're too afraid. From where they're sitting, it all seems easy enough as is. They tap-tap-tap, they buy their apps at Apple's App Store and only at Apple's App Store, it just works - like purchasing a track at iTunes. They don't notice anything wrong.

They can't get stuff like Android users can. Android users can get stuff anywhere. Apple fanboys can only get stuff at Apple's App Store. But they don't mind.

But every master plan, no matter how diabolical, has a weakness. An Achilles Heel. Remember what Carrie Fisher and her friends told the pilots? Apple's plan, as brilliant as it is, with all those years of hard work on design and implementation, has such a weakness. A small gap. And it's precisely that gap that Rixstep's Keymaster Technology exploits.

Starting now, using this Technology in the new ACP/Xfile/Keymaster Test Drive, you can again download software from anywhere you want without being worried about Apple. Your software will not be put in quarantine, you will not be limited in your use of your own software. Most importantly: the vendors no longer need to cryptographically seal their products and pay the 30% tribute to Apple. And the cost to you, dear consumer, can go back down by 30% to where it once was. To where it should be.

Coming soon, a Rixstep utility that strips code seals and CodeResources gunk from existing software bundles and makes them like new again.

Vendors and consumers on Apple's computers... Unite.

Consumers can now buy their products outside Apple and save 30%. After all, it's the same company and the same product otherwise. The Apple App Store may initially be the best first marketplace - at least for now - but once the word gets out...

Vendors with a big enough following are now able to cut out Apple entirely. Are you a vendor who would like to try out this solution? Then drop a line.

See Also
ACP/Xfile Test Drive

You've obviously heard of us, otherwise you wouldn't be here.
We're known for telling the truth even if it's not in our interest.
We're now telling you to beware Apple's walled garden. Don't get locked in.
What you've seen so far may be only the beginning of something far far worse.
Download our Test Drive and at least check out our free Keymaster Solo.
That's the first step to regaining your freedom. See here.