OT: Obfuscate or not?
Kevin Walzer
a shareware Tcl/Tk application I am developing, I ask your indulgence.
I'm trying to decide: obfuscate my code or not? I'll be using some kind
of wrapping mechanism to deploy the application (starkits/freewrap/etc),
so it will look like a single executable anyway: but I'm wondering if
converting the scripts to bytecode via compiler (and then deploying with
tbcload) is a necessary extra step.
The registration script is really the only part that I hesitate to
release in a non-obfuscated mode. However, the research I've done shows
that if someone is determined enough, they will crack or pirate the
program anyway, or input a valid serial number that they got from some
underground website. I don't think the average end user is going to take
time to figure out how to unwrap a starkit and then decipher the
registration code.
Past threads on this list have tended to deal with this question in a
different context than mine--providing source code from a consulting
engagement, for instance. The only *shareware* Tcl/Tk application that
I'm familiar with is AlphaTk, which does not obfuscate its code as far
as I can tell. However, I'd like a bigger sample to analyze before
deciding.
Any advice is appreciated. Thanks.
Robert Heller
In a message on Fri, 06 Jan 2006 14:17:40 -0500, wrote :
KW> This is more of a business than a technical question, but as it concerns
KW> a shareware Tcl/Tk application I am developing, I ask your indulgence.
KW>
KW> I'm trying to decide: obfuscate my code or not? I'll be using some kind
KW> of wrapping mechanism to deploy the application (starkits/freewrap/etc),
KW> so it will look like a single executable anyway: but I'm wondering if
KW> converting the scripts to bytecode via compiler (and then deploying with
KW> tbcload) is a necessary extra step.
KW>
KW> The registration script is really the only part that I hesitate to
KW> release in a non-obfuscated mode. However, the research I've done shows
KW> that if someone is determined enough, they will crack or pirate the
KW> program anyway, or input a valid serial number that they got from some
KW> underground website. I don't think the average end user is going to take
KW> time to figure out how to unwrap a starkit and then decipher the
KW> registration code.
KW>
KW> Past threads on this list have tended to deal with this question in a
KW> different context than mine--providing source code from a consulting
KW> engagement, for instance. The only *shareware* Tcl/Tk application that
KW> I'm familiar with is AlphaTk, which does not obfuscate its code as far
KW> as I can tell. However, I'd like a bigger sample to analyze before
KW> deciding.
What it ultimately comes down to is: "How worth it is it to just buy a
ligit registration code?" If the price tag is too high (for what the
end-user actually gets), then it is worth pirating (one way or
another).
You need to make sure that paying for the registration code gets the
end-user enough value for their money. This usually means some sort of
support channel (eg toll free help line, with real live people who
really know the answers to questions or know how to get the answers
quickly).
Most general end-users (non programmers!) will find even clear text,
commented computer source code more than sufficiently obfuscated,
without further obfuscation hacks. If your tool is geared specificly
to actual computer programmers (eg it is something like a compiler or
other such tool) you probably are out of luck WRT obfuscation in
general, unless the price is 'right'. This may mean that your price
will be a token amount (eg $US5.00 or $US10.00) and you won't make any
money *selling the product*. You will have to depend on selling other
things, like hard copy reference manuals and support contracts and
training and the like. Oh, one way to mildly obfuscate the registration
code is to hand re-code it in C and compile it into a .so or .dll file.
It is still possible to crack it (by disassembling the object code and
going from there).
KW>
KW> Any advice is appreciated. Thanks.
KW>
\/
Robert Heller ||InterNet: hel...@deepsoft.com
http://www.deepsoft.com/ ||FidoNet: 1:321/153
http://www.deepsoft.com/~heller /\
walto...@gmail.com
who use your program, then the more likely it is to be cracked.
Almost every major program nowadays is being pirated or has some sort
of crack being circulated on the web. I think it's inevitable. But I
also think you should make it as difficult as possible.
If you just freewrap it with no obfuscation, then it won't take long
for someone to crack it. It isn't that difficult to distribute the
program with tbcload (I do it with some of my apps), so why not do it?
Kevin Walzer
>
> If you just freewrap it with no obfuscation, then it won't take long
> for someone to crack it. It isn't that difficult to distribute the
> program with tbcload (I do it with some of my apps), so why not do it?
>
This is what I've decided to do. Thanks for the advice.
--
Cheers,
Kevin Walzer, PhD
WordTech Software - "Tame the Terminal"
http://www.wordtech-software.com
sw at wordtech-software.com
Dennis LaBelle
I don't know if this will help your decision, but....
I will be releasing a new version of freeWrap in a couple of weeks. It
includes automatic encryption for all source code files in the wrapped
application. For now, it will use the encryption method originally found in
PKzip.
I currently have it working under Windows and am working on debugging the
Linux version.
Dennis LaBelle
walto...@gmail.com
bytecode or PKZIP.
By the way, will the PKZIP encryption in the new Freewrap also encrypt
wrapped bytecode files?
Dennis LaBelle
Jeff Hobbs
That is still somewhat pointless when freewrap has to unencrypt
the sources and feed them open to Tcl (which has full
introspection functionality). Tcl bytecodes can also be
reassembled, but are "more secure" than any interim encryption
scheme that inevitably has to feed raw Tcl to the interpreter.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
Bryan Oakley
> walto...@gmail.com wrote:
>
>> That sounds great, Dennis. I wonder which is more secure -- Tcl
>> bytecode or PKZIP.
>>
>> By the way, will the PKZIP encryption in the new Freewrap also encrypt
>> wrapped bytecode files?
>
>
> That is still somewhat pointless when freewrap has to unencrypt
> the sources and feed them open to Tcl (which has full
> introspection functionality).
Though as part of your product you can rename the "info" command to
something else and make it that much harder for someone to use Tcl to
get proc names and bodies.
Still, if they were never in plain text to begin with (ie: already in
byte codes) it makes it that much harder.
It all depends on how serious the threat is that someone will hack your
code, and how devestating that would be to you if they did.
Dennis LaBelle
> walto...@gmail.com wrote:
>> That sounds great, Dennis. I wonder which is more secure -- Tcl
>> bytecode or PKZIP.
>>
>> By the way, will the PKZIP encryption in the new Freewrap also encrypt
>> wrapped bytecode files?
>
> That is still somewhat pointless when freewrap has to unencrypt
> the sources and feed them open to Tcl (which has full
> introspection functionality). Tcl bytecodes can also be
> reassembled, but are "more secure" than any interim encryption
> scheme that inevitably has to feed raw Tcl to the interpreter.
>
Come on.....Let's be realistic here.
I am assuming that someone who is interested in "protecting" their
code/program will not give the user access to something like the console
window. And for Unix environments they would also disable the send command.
Without access to the console or send and all files encrypted the
application should be relatively secure.
walto...@gmail.com
run commands. Off the top of my head, they could try inserting code
into one of the standard wrapped files like freewrap.tcl or create a
pkgIndex.tcl file. Personally, I like to use tbcload and Freewrap
together for sensitive programs, and having the encryption will
definitely help ease the paranoia.
I´ve tried overwriting the console and info commands before, but they
are apparently used by other standard commands as they both cause
errors.
Dennis LaBelle
Exactly how is anyone going to change any of the wrapped files if they are
all encrypted!?
walto...@gmail.com
state used in conjunction with tbcload, but I didn't make that clear.
But, for example, putting a pkgIndex.tcl file in the working directory
might get it sourced if the developer uses a 'package require' command
to load wrapped extensions, with or without encryption and bytecodes.
My point is that I think there are always ways a program can be cracked
that neither of us will think of, and so more security is better, which
is why I am glad you are re-implementing encryption in Freewrap.