source protection

Summary

source protection is the topic of making deployed code inscrutable to users

See Also

Protecting a TCL program against piracy

Cameron Laird's personal notes on Tcl compilers

Tools

TclApp

prowrap

tbcload

lriobf

creates starkit where the embedded scripts are encrypted

procomp

Molebox encrypted Windows exe

GE ICE Tcl compiler

dis2asm

combination of tcl::unsupported::disassemble and tcl::unsupported::assemble

TikEn, an encrypter for tclkit starpacks

Tclkit starpack encrypter (latest 1.4)

Rationale

• One may wish to prevent the user of an application from knowing what is being done algorithmically, out of security concerns.
• One may wish to prevent the user from knowing what is being done out of intellectual property concerns
• One may wish to prevent the user from modifying the code out of maintenance support concerns
• One may wish to prevent the user from modifying the code to prevent abuse (for instance, to hopefully limit the amount of cheating one might do in multi-player games)

Description

It is possible to combine the various forms of deployment with some form of encryption. Encryption will, of course, incur a performance penalty.

The compiling solutions in Tcl Dev Kit/TclPro and the GE ICE Tcl compiler offer decent protection because they actually obfuscate in such a way that not even runtime introspection would reveal your code. The latter is arguably the best, as it translates to compilable C code, but it only works for Tcl 8.0.

[Why Java, C, ... aren't really all that hot for security.]

[Distinguish obfuscation and full-blown encryption.]

It is practical to deliver encrypted Tcl-coded applications. Steve Blinkhorn, for example, has written, "Various of my Tclkit-based projects are delivered using blowfish encryption, with some extra attention given to the security of keys. There's nothing especially difficult about doing this with single-file Starpacks, and the actual encryption code is miniscule - I routinely build starkits with multiple versions of a mini-extension for various platforms, with little impact on the overall size. For instance, a version of tclhttpd with some custom code (including encryption) packaged up as a single-file executable with tclkit has 300Kbytes or so to spare for a document tree and still fits on a 3.5" floppy, is in live use now, doesn't crash and supports some quite complex client-server transactions with a Metakit database (the code for which, of course, comes as part of the Tclkit executable).

With a two-file (Starkit) solution, it is possible to update client software on remote sites transparently, so far as the user is concerned, and on a user-by-user basis, because the .kit file looks to the executable like a file system."

JBR: It doesn't seem possible to deliver a script that can be executed by the Tcl interpreter that cannot be viewed by a determined individual. If the boot strap application code can find and use a decryption key so can the attacker. This is the underlying and inescapable flaw in all encrypted content delivery schemes (DRM).

Kroc - It doesn't really matter because Tcl interpreter can runs strings human beings can't understand.

The Tcl interpreter runs byte code. Last I checked it can be formatted and understood.