About one year ago I had a so-called aha moment and decided to write a book. I had two or three subjects in mind, first choice was HTML Panels’ Licensing Solutions – i.e. how to build trial versions, anti-piracy systems, and the like. Luckily, and I really mean: luckily, I changed my mind and tackled a topic appealing to a slightly broader audience: the HTML Panels Development course was born.
Still, licensing systems in the context of HTML Panels are a soft spot of mine (see my old post about partial serial number verification), and I wish I had time to write that book! I did build, from my biased point of view, very good prototypes back then: for instance implementing RSA encryption, or server-side automatic licensing files delivery to be used in conjunction with e-commerce providers. Whatever you choose to do, you’re protection system must rely on secured code that nobody can look at – which is what this article is all about.
As a due preamble, there’s no such a thing as unbreakable software. Let’s admit however that you and I, we’re possibly not building stuff that has very much appeal to the international crackers community, no? For whatever reason we like to keep our code hidden (privacy, licensing systems as a form of respect to paid users…), chances are that the malice level of our wannabe pirates is not worldwide top-notch. Neither we want to die in the process of keeping our code protect, and spend too many sleepless nights over that.
As an engineer I collaborate with uses to say, “I would rather spend time building and earning money on new products”. So, a fair compromise in my opinion is to do the best that we can, being aware of both the context our products belong to (their price, spread, number of users, etc.) and the resources needed to protect them. So my own goal is to make it “sealed enough”. Where to put the bar, it’s up to you.
The tale of JsxBin
To make things clear, it’s not binary at all but more like an advanced form of cyphertext – a sealed box we could trust. In fact we trusted it so much that (despite being the task utterly boring, and illegal too) one would have tried to reverse-engineer it, either (a) because of a very twisted idea of fun (b) to enjoy his/her own failures as the JsxBin safeness confirmation. I know you know JsxBin if you’re reading this, but here it is what it looks like:
Theory says that, like with any other cyphertext, given an infinite number of plain text and cypher pairs (say, Jsx and corresponding JsxBin), you can find the key to decode it. Which is what ExtendScript Toolkit (aka ESTK) provides you: just start with
var a; and inspect the resulting JsxBin code, then keep adding complexity and write down your findings. On and on and on… until you’re bored to death (unless you’re a cryptography enthusiast).
You will understand me if I’m vague here – we’re at the dangerous intersection of legal and privacy issues – but lately JsxBin proved to be… not as sealed as we liked to think. I’m not saying that everybody can flip and turn it back into readable code in a snap (can you? can somebody you know?), but the probability that somebody can decypher your JsxBin isn’t zero anymore. I’d say quite small, but not zero.
Minifiy, Optimize, Obfuscate?
I’ve been using these terms loosely, but they express different ideas.
Minification is the process of compressing your code, usually to be delivered faster over the internet, consuming less bandwidth; depending on the minifier you pick up, variable names can be changed as well, so that:
Obfuscation finally is the process to transform the source code to make it harder to understand. As a funny example, here it’s what
Don’t ask me how it works, but it does – if you don’t believe me, copy & paste that in ESTK and run it. Now imagine the face of somebody opening your JSX and finding there a bunch of Jap emoticons
First, when testing a service, try to beautify _the _uglified code. You may find out that apparently excellent services such as this one, which compresses some code from a blogpost of mine this way:
…the very same website provides a twin service able to perfectly restore / beautify its own obfuscated code, making the whole obfuscation page… quite pointless – no? Second, always do test your code thoroughly. ExtendScript may seem to work, but in fact it may not.
alert() gets an extreme makeover:
And this is the resulting PNG:
Above, all the settings that I’ve been able to use in the free tier. Good news: at least with them, ExtendScript code is perfectly fine and happy, so this is definitely an option. According to them, that security level is low – they provide more advanced features – yet again, it depends on who you think you’re dealing with when protecting your code.
Made by the very talented InDesign developer Marc Autret, JsxBlind tackles the issue of code protection from a different perspective. It presupposes JsxBin as the source and outputs JsxBin as well, so you need to:
- Export to binary the original, plain Jsx using ESTK. You get a JsxBin file (nothing different from what we’re used to).
- Process the above JsxBin through JsxBlind. You get another JsxBin file.
According to Marc, if somebody decoded the JsxBlind-ed JsxBin, it would get scrambled variables and function names:
JsxBlind is provided for free – refer to the original blogpost for all the details. Please note that, depending on your coding style, function names obfuscation (which is optional) may or may not work. Moreover, ExtendScript support varies among Creative Cloud applications: Marc is an InDesign developer so that is his platform of choice, Photoshop seems to work as well, but do test your obfuscated code before shipping.
I’ve shown here 4 valid alternatives – let me sum up here my own operative and strategic suggestions.
- Keep in mind the reason why you’re protecting your code, and balance the resources you’re putting into this process, versus the results you’re getting and your actual needs.
- JsxBin isn’t dead. The large majority of those who might be involved into the evil business of spying your code don’t have any key to open that lock.
- Do always test your obfuscated code. ESTK non outputting parsing errors doesn’t mean that your scripts will work as expected. For instance don’t hardwire variable params inside strings, always use String interpolation (I faced this very issue myself calling
Please let me know your thoughts in the comments below!
The Photoshop HTML Panels Development Course
If you’re reading here, you might be interested in my Photoshop Panels development – so let me inform you that I’ve authored a full course:
- 300 pages PDF
- 3 hours of HD screencasts
- 28 custom Panels with commented code
Check it out! Please help me spread the news – I’ll be able to keep producing more exclusive content on this blog. Thank you!