** Summary **

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


** See Also **

   [Protecting a TCL program against piracy]:   

   [http://phaseit.net/claird/comp.lang.tcl/tcl_compilers.html%|%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]


** 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 [deployment%|%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
[Starpack]s, and the actual encryption code is miniscule - I routinely
build [starkit]s 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.
  

<<categories>> Category Concept