I’ve written an Automator action that allows you to write python scripts directly inside your Automator workflow.

“Run Python Script” Automator action (catchy title) is written using Python and PyObjC (now built-in to Mac OS X 10.5). Apple already provides “Run AppleScript” and “Run Shell Script” actions with Automator which give Automator a high degree of flexibility. However Python is my preferred scripting language and by writing a custom action purely for Python I was able to take advantage of some PyObjC features that in my opinion make my action superior to the provided Apple scripting action. I’m releasing all the source code to the action under the BSD Open Source license.

One of the main advantages of the action is that Python (with the help of PyObjC) understands the AppleEvent descriptors that Automator uses to pass data between workflow actions. This allows the user to create a custom action that accepts and provides data of any type. In contrast Apple’s “Run Shell Script” action can only accept and provide text (usually limited to file paths). Some work does need to be done to make working with any data (which is represented by NSAppleEventDescriptor objects) more convenient.

The default Python script for a new action in a workflow follows:

import sys

def main(input, *args, **kwargs):
    '''Your script goes here.'''
    print 'Hello world'
    return sys.stdout

This is pretty simple. The action will optionally convert the input into Python types (currently limited to converting typeAlias AppleEvent descriptors into path strings) to allow simple processing. Output is (optionally) converted from Python types to native Automator types. See the Examples directory for more.

The following screenshot shows the action used in a real workflow. This workflow asks the user for a keyword and then the Python action downloads photos from the morguefile public stock photo archive that are related to the keyword. Once download it performs some processing on the files (scales them to 640 by 480) and produces a PDF “Contact Book” from the images.

The source code uses a 10.5 specific technique to create Python based bundles. It also has a simple Python syntax colouring NSTextView (using Python itself to colourise the source).

I’m calling the Action a 0.1 release and have some plans/ideas for further releases. See the TODO list.

Update: I’ve added a sample script showing how to upload files to Amazon S3 from within a workflow.

The code in subversion is a lot newer than the binary I’m linking to. If possible do a checkout and build the plugin yourself.

Update: This Automator action has issues on Snow Leopard and some Leopard versions. Use at your own risk.

Update: Automator’s “Run Terminal Script” looks like it supports and understands Python native. That means, although my .action was better (syntax highlighting, better control of input and output, better logging, etc), I probably won’t bother to update it to Snow Leopard.

AquaticPrime uses “RSA encryption to provide excellent security – the same that is used to protect government documents”. This makes it sound like AquaticPrime is a great solution for Software Developers wanting to prevent piracy by adopting a software licensing scheme. A lot of Macintosh Small Business developers are using or are considering using AquaticPrime.

Unfortunately for them, AquaticPrime is incredibly easy to crack. I am not a computer security expert and I am definitely not a software cracker, but I was able to crack an application that used AquaticPrime in less than thirty minutes with almost no preparation time. In fact, I am pretty sure that my crack will work with almost all applications that use AquaticPrime.

Aquatic Prime uses a technique similar to one discussed by Allan Odgaard on his blog. Public Key cryptography techniques are used to generate linked public and a private keys. The private key is kept by the software developer and the public key is shipped inside the application’s binary. When a user buys a copy of the software, a license file is signed using the private key. The software can then use its public key to verify that the license key was signed by the public key. Someone trying to steal a copy of the software would be unable to forge their own license files because the public key works with one and only one private key.

The technique I used to defeat AquaticPrime involved creating my own private and public keys (using the AquaticPrime utility itself) and then generating a fake license key (registered to a “John Doe”) using the new private key. The trick then was cracking the test application and convincing it to use my public key instead of the real key.

To track the application, I needed a way of writing code that could be executed by the targeted application. Fortunately, there are a plethora of methods to do that on Mac OS X: Application Enhancer, MachInject, InputManagers, and SIMBL plugins are just some of the many ways of forcing third-party applications to run foreign code. I chose to use a SIMBL plugin because I had never used SIMBL before and wanted to learn a little about it. Creating a SIMBL plug-in turned out to be incredibly easy and I had my code running inside the targeted application in just a few minutes. In a couple of minutes more, I had created an object that was masquerading as an AquaticPrime object. The final step was to make my masquerading object ignore the application’s public key and use my fake public key instead. Once this was achieved I loaded my (or rather John Doe’s) fake license key into the application and found that I had cracked the application.

It really was as simple as that. Of course there were a few WTF moments and application crashes, but nothing unusual during development (especially development of this kind). The code currently only works with AquaticPrime’s Objective-C interface, but the same principles can be used for the pure C interface too. I have tried this technique on two shareware applications and it worked fine with both. I am reasonably confident that it should work with most AquaticPrime using applications.

The method used to defeat AquaticPrime isn’t particularly obscure, and in fact is just one of many methods that could be used to defeat it. However this method is particularly nice in that you’re not really hacking the application using a more brute force method. You’re merely providing it with bad data, which it then uses to validate your bad license (kind of like Garbage In, Garbage out), in all other ways AquaticPrime is working as normal and is blissfully unaware that it has been cracked. This means that some of the techniques that developers can use to find out if their software has been cracked are impossible.

AquaticPrime is a well written, documented and marketed piece of software. But it suffers from this huge design flaw. AquaticPrime is exceptionally easy to crack, either with this method or with a variety of other, possibly cruder methods. Many of these methods are equally applicable to other registration schemes, so it is somewhat unfair to single AquaticPrime out. But because AquaticPrime provides all the source code and headers to anyone, it makes it really easy for anyone to crack. Although hiding the source code would have been a form of “security through obscurity“, this would have at least slowed me down considerable. As it was, I was handed everything I needed to crack this software on a plate. And if I can crack this software in less than 30 minutes, I am sure crackers who do this thing professionally would have had even less trouble.

Even more worrying, this technique doesn’t just work on a single application, it will work on all applications that use AquaticPrime. I don’t know how many applications out there use AquaticPrime, but each is vulnerable to the same crack and all would be cracked essentially “for free”. There are some things a developer could do to shore up this vulnerability, but in reality most solutions are probably just as easily cracked.

Links:

Subversion Repository: http://toxic-public.googlecode.com/svn/tags/BlogTag_20070927_729/Spotlight/mdfind2/

Binary: http://toxic-public.googlecode.com/svn/tags/BlogTag_20070927_729/Spotlight/mdfind2/Output/mdfind2.tar.bz2

Now the real trick will have to happen tomorrow (uh – later today) when I’ll need to take the Iron Coder theme and apply it to my project. I’m hoping for a really tacky theme, like Elvis Presley impersonators or Pink Lawn Flamingos. Jonathan ‘Wolf’ Rentzsch really picked a great API (all hail the chairman) and I am sure he won’t let us down with his choice of theme.

I’m not the only one starting coding early – I know a few people wont have much time during the second day of the competition so are hoping to score points on their use of the API alone. The beauty of this competition (I think, this is still our first attempt so who really knows how things will turn) is that it just encourages cool hacks.

More linke: http://zacwhite.com/blog/?p=36

• Support for Intel architecture.
• UTType now includes Python’s OS Creator code.
• Slightly better error handling
• Python Metadata Importer shouldn’t die when indexing Python files it doesn’t understand.

Direct download:

Python Metadata Importer.dmg

Source code:

http://toxic-public.googlecode.com/svn/tags/BlogTag_20070927_729/Projects/Spotlight/Python%20Metadata%20Importer/

About Python Metadata Importer:

Allows Spotlight to import and index Python script source code. Various metadata are imported from the source code including function and class names, version, author and description.

Related Postings:

• Python Metadata Importer Released for Tiger
• Spoke at phad.org meeting tonight
• Lisp Metadata Importer
• Ruby Spotlight Importer
• Python Metadata Importer 1.0.1 Release
• Python Metadata Importer Released for Tiger
• Conf Metadata Importer
• Creating a Generic Config File Spotlight Importer