|Home » Learning Curve » Developers Workshop
Details on a coming update, and a little bit of history.
SACRAMENTO (Rixstep) — CLIX is free, has always been free, and will always be free. The reason? Because knowledge is free and should always be free.
CLIX started many many years ago as an attempt to 'cut through the bullshit' that found its way onto the new Apple 32-bit platform. Parallels with Windows experiences a few years earlier were abundant.
Less than scrupulous programmers took 'free source' and wrapped it in cutesy MFC ribbons and sold it as their own product. Some of them wanted only fame, and charged nothing. But this was not always the case.
The most egregious example then was an app called 'Depandancy' [sic] from Eschalon Software [sic] which used 'tool' APIs to show what DLLs a program was dependent on. The price? $50. The product was promoted at ZD Net and got over 50,000 downloads.
The problem was that the program did very little, only a fraction of what this program did, a free offering and top-5 download at Beverly Hills Software for years.
What Dependancy did can be seen in the third panel from the top ('Modules'). But X-tool's 'Modules' panel does even more, and the app as a whole does more still.
It dumps data; enumerates process allocation blocks, heaps, and threads; provides full data on loaded modules, including IDs, virtual address and size, usage stats, and file system path. The main panel enumerates process IDs, parent process IDs, priorities, threads, and more. As well as navigating up and down dependency chains.
For free. An advanced developers tool. A complete run of the 'tool help' library.
Also often found: people using Berkeley sockets code. (Windows was new to the web, the web was new too.)
Then Apple came out with their new system, based on NeXTSTEP, with FreeBSD at the bottom. Few Apple users knew UNIX™.
Here it wasn't about free source but finished compiled programs already on disk that people knew nothing about.
And yet they were sold. Not all, but some of them. And some of them, like the infamous Cocktail, pulled a 'bait and switch' on users, getting them to unwittingly download and overwrite an older free version with a time-limited commercial version without telling people they were shafting themselves in the process.
The apps themselves? Mostly rubbish. One can't complain if it's free, it can be argued, but do people know what they're getting?
People were getting ripped off. Clearly something had to be done. But how?
[The CLIX page has a small sampling of the comments received from people once they caught on. Ed.]
Term's Little Helper
The first clue came with a product called 'Term's Little Helper'. It too had a graphical user interface, with entry fields, radio buttons, tick boxes, the works - but the difference was that, when you were ready and clicked that 'OK' button, Term's Little Helper showed you what your actual command line would have been.
And that's very helpful. An educational tool!
The only drawback was that you were limited to what was already there. You couldn't add new lists and tick boxes of your own.
From a corporate app to collate telephone lists, and another app to collate data on motion pictures, gradually came a hybrid (still on Windows) that could be used to collate anything.
This was quickly ported to the new platform.
And the above design was more or less what we'd been looking for.
Title, Category, Description, and Command Line is what we needed. Along with a way to pipe commands through and get the output (stdout, stderr) on screen.
From this fifteen years ago...
To this today.
But it had to be for free. Because knowledge is free and should always be free.
So the deal was 'OK, we work one day on this, we can afford one day, let's see what we get'. And we did.
That first day was 14 hours long, but we had an app. And it was free.
CLIX had two immediate unexpected benefits.
- For the professional, there was finally a way to collect oft-used commands.
- For the adept, there was a way to learn more about the Rock Solid Foundation™.
What the 'carpetbaggers' on the platform used to do was 'rummage in the bins' - the four basic 'binary' directories - and then create scripts to run the programs therein. And yes, it looked like magic, like real programming. But it wasn't.
So what we did at this site - in off-hours, coffee breaks, etc - was rummage too, and create CLIX commands to give people things they should have got for free. We amassed several thousand such commands, and, we think, organised and formulated them a lot better than the carpetbaggers.
[Note: Marcel Bresink is not a carpetbagger. His books are very good, his apps authentic 'real' programming. Ed.]
There were any number of security issues with Apple's new platform, not in the least due to third-party developers.
A common practice was to offer privilege escalation and pass unencrypted passwords in the clear on a command line.
Ordinary punters may be puzzled, wondering where that 'command line' could be, especially as they might not be running Terminal.app at the time, but hackers can find it, be so sure of that!
CLIX is immune here. Nothing is passed (or 'echoed') in the clear. Anywhere. The system itself takes care of it.
Further 'anomalies' were found in the corruption of the $PATH variable, something demonstrated by a colleague with a brilliant 'proof of concept' exploit published here. (This was a matter for the owners of bash who refused to admit there was an issue, and refused to plug the breach.)
Another issue was the so-called 'sudo grace period' and how it could be exploited by malware to 'piggyback' into root. (Apple fixed most of these issues over time.)
But CLIX has always gone a lot farther - see below, way way below.
As it became clear that there was no way to enforce or ensure binary integrity - code-signing is easily defeated - the number one task became to find a way to cryptographically seal a binary from the inside that no force from the outside could break.
Sort of like Houdini, but the other way around.
As can be expected, this took quite some time to create - it sounds like an impossibility because it is.
But it works - and it's been in use for over ten years.
And we gave a name to the technology - we call it Houdini.
Of considerable importance - and exposure (collaboration) with a number of very skilled hackers helped - is making sure that rogue processes (trojans) don't try to communicate with legitimate software. All subprocesses run by CLIX are checked for their authenticity.
Something unexpected happened when CLIX was first released, somewhat due to how Apple organised their newsletters back then. Today everything is mostly sealed like a gadget from Planet Groovy™, but back then everything was open. And Apple had special newsletters for programmers. CLIX was submitted to one of those newsletters.
What hadn't been (couldn't have been) understood was that pundits, who were not programmers, also subscribed to those newsletters. So news of CLIX spread like wildfire.
But that wasn't the big surprise. The big surprise was the reaction of the legacy Mac users, who might never before have seen Unix. They were enthralled. The classic platform without the command line had users in droves who were suddenly embracing it.
Command lines and command lines, but systems need skilled users. Yet today? Today it's mostly 'tap tap' and not much more.
The CLIX update is being tested. Things are looking good. Goes out to full ACP users, then Xfile users, then as the freebie.
- Built on 10.7 for 10.6. The reason for this should be obvious.
- Built on 10.7 for High Sierra 10.13.2. Compatibility is everything.
- Multiple icons. Four in number. Original, a richer version, two for 10.12 and beyond.
- Only authorised subprocesses. No messing with the process table. (What's that, they ask...) CLIX will only launch its subprocesses if it first establishes that CLIX itself spawned them.
- Passwords never shown in the clear. CLIX entry fields must be secure or else the whole kit and caboodle comes down.
- No tampering at runtime. So you wait until CLIX launches and then tamper with the binary? CLIX checks for integrity every time something sensitive is performed. Pass the test or CLIX shuts down.
- Computer sleep. CLIX knows when your computer is going to sleep. Your password must be removed in all possible places in such case. Try this: enter a password, save it, re-invoke the sudo password sheet again, put your computer to sleep (the leftmost menu) and then rouse it again. See what happened?
- Path sanitisation. You can tamper with $PATH but you can't tamper with a kernel value. CLIX always uses the kernel's value. Our colleague Georg long ago wrote a brilliant script to show how other tools, such as Apple's Terminal.app, can be pwned. Use the ACP Text Services to automatically expand command paths for ultimate safety.
- Cleanups. CLIX cleans up things both before and after running a command. No 'grace period' allowed, no matter how lax the user settings. The same happens - asynchronously - after a command. No one can piggyback on CLIX, unlike Terminal and other apps.
- Sealed by Houdini. The CLIX binary is sealed by 'Houdini', a concept and an invention we came up with. Houdini is a cryptographic seal applied from the inside and placed on the outside. (Or was it the other way around?) (Yes you read that right.) (Yes you did.) This took about half a year to develop - and it's not easy to implement, to say the very least.
Apple's standard tools (eg code-signing) are easily exploitable: protection is not at kernel level. As we discovered nine years ago. But of course fanboys normally opt for a snooze instead.
[But watch out if they unify with iOS, watch very carefully. Ed.]
But, at the end of the day, the ultimate question is: does anyone use the macOS platform anymore?
Tap on your Apple mobile device to register your response.
CLIX: Learn how to fish (老子)
CLIX: Safer than Terminal?
CLIX: Legally Hacking - Introduction
CLIX False Beginners (1)
CLIX False Beginners (2)
CLIX False Beginners (3)
Cool Clever Stuff with CLIX
Cool Clever Stuff with CLIX II
Cool Clever Stuff with CLIX III
1st Time CLIX?
The Zero Time Stamp Timeout
'If you can't type - click'
Too Much Sudo Fun
ACP Text Services: Resolve Path
CLIX & Lion
Cookie Tin Tips I
Cookie Tin Tips II
Cookie Tin Tips III
Cookie Tin Tips IV
Cookie Tin Tips V
CLIX 1.7.2(a) 'Ilgaz'
20070623,00 - Script Kiddies
OS X Server
Dudley Dursley's Dilemma
The Wizards of OS X™
CocktailTE: Arsenic & Other Laces
Sudos & Sudon'ts
The CLIX Files
ACP, AWS, CLIX, & Tiger
CLIX, ACP Web Services 1.8.0a
CLIX 22.214.171.124: 5,000 Commands
Bloat Warfare Workshop Second Edition
A Leopard Cleanup Script
CLIX 1.7.2d 'pk' - Explosive Action!
PRISM: Staying Under the Radar
New CLIX Stuff 2008-02-24
Keep a Clean Machine
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, Microsoft, IBM, Barclays Bank, 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 Material and Software © Rixstep All Rights Reserved.
Apple, the Apple logo, Macintosh, OS X, and macOS are registered trademarks of Apple Inc in the US and/or other countries. Other trademarks and registered trademarks may be the property of their respective owners.