Bytecode/TclPro de-compiler
EG
a Tcl/TK script has been compiled by, say TclPro or another
similar tool, would it be possible to de-compile it and get
at the original source code? Or, say, if you mistakenly
deleted the source file, but you have the compiled
executable, would it be possible to restore the source code?
TIA,
Eric
**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****
Jeffrey Hobbs
> I was having a discussion with a friend the other day: Once
> a Tcl/TK script has been compiled by, say TclPro or another
> similar tool, would it be possible to de-compile it and get
> at the original source code? Or, say, if you mistakenly
> deleted the source file, but you have the compiled
> executable, would it be possible to restore the source code?
Theoretically, yes, just as you can disassemble any binary (and
some programs will make C code out of it again). However, I
don't think Scriptics has considered the need for this, so such
is highly unlikely to exist right now.
** Jeffrey Hobbs jeff.hobbs @SPAM acm.org **
** I'm really just a Tcl-bot My opinions are MY opinions **
Stephan Uyttebroeck
>
> EG wrote:
> > I was having a discussion with a friend the other day: Once
> > a Tcl/TK script has been compiled by, say TclPro or another
> > similar tool, would it be possible to de-compile it and get
> > at the original source code? Or, say, if you mistakenly
> > deleted the source file, but you have the compiled
> > executable, would it be possible to restore the source code?
>
> Theoretically, yes, just as you can disassemble any binary (and
> some programs will make C code out of it again). However, I
> don't think Scriptics has considered the need for this, so such
> is highly unlikely to exist right now.
>
I hope they never create a disassembler, since protection of our
Tcl source code was the main reason we bought their TclPro software.
--
______ __ __ Stephan Uyttebroeck
/\ ___\ /\ \/\ \ Senior Software Engineer @ Frontier Design
\ \___ \ \ \ \_\ \ __ Abdijstraat 34, B-3001 Heverlee, Belgium
\/\_____\ \ \_____\ /\_\ phone +32(16)391440 | fax +32(16)406076
\/_____/ \/_____/ \/_/ email stephan_u...@frontierd.com
_______________________________________________________________________
Jeffrey Hobbs
> Jeffrey Hobbs wrote:
> > EG wrote:
> > > a Tcl/TK script has been compiled by, say TclPro or another
> > > similar tool, would it be possible to de-compile it and get
> > > at the original source code? Or, say, if you mistakenly
> > Theoretically, yes, just as you can disassemble any binary (and
> > some programs will make C code out of it again). However, I
> > don't think Scriptics has considered the need for this, so such
> I hope they never create a disassembler, since protection of our
> Tcl source code was the main reason we bought their TclPro software.
Scriptics doesn't have to be the ones that create it. Anyone with
enough free energy can try and figure out how to reverse engineer
byte codes. As I said, you can take any regular binary and get C
code back with some disassemblers, so protection of code in that
way is always limited. In the end, it is whatever copyrights you
have on the code that are the only legal protection.
Stephan Uyttebroeck
I fully agree with that, but I believe that the byte codes discourages
99.99% of the people ever trying it.
lvi...@cas.org
According to Stephan Uyttebroeck <ste...@frontierd.com>:
:I fully agree with that, but I believe that the byte codes discourages
:99.99% of the people ever trying it.
I don't know if I agree with your percentage. However, it's the percent
not discouraged whom you should be most worried about - the percent
discouraged is likely to be a superset of a nearly equal sized group of
people who would never have stolen your code anyways. The ones who
would have stolen your code is likely to consider the 'encoding' a
challenge - and THEY will freely distribute the scripts to crack the
encoding mechanism to others of the same intent.
So basically, the ones who are the best customers are penalized while the
ones who steal the work are going to do so anyways (if the work is 'work'
stealing in their sight).
--
<URL: mailto:lvi...@cas.org> Quote: Saving the world before bedtime.
<*> O- <URL: http://www.purl.org/NET/lvirden/>
Unless explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Stephan Uyttebroeck
>
> According to Stephan Uyttebroeck <ste...@frontierd.com>:
> :I fully agree with that, but I believe that the byte codes discourages
> :99.99% of the people ever trying it.
>
> I don't know if I agree with your percentage. However, it's the percent
> not discouraged whom you should be most worried about - the percent
> discouraged is likely to be a superset of a nearly equal sized group of
> people who would never have stolen your code anyways. The ones who
> would have stolen your code is likely to consider the 'encoding' a
> challenge - and THEY will freely distribute the scripts to crack the
> encoding mechanism to others of the same intent.
True, but I should have pointed out that protection of the intellectual
property was only part of the reason we use an 'encoding' mechanism.
In the past we distributed our code unencoded and were then bitten by
huge support costs of those 'best' customers who did their own bit of
'customization' until it was broken, then contacted customer support and
'forgot' to tell about their changes...
Shipping 'encoded' gives us at least more chance of having the same
software
at our customer sites, and thus we can help them better when real
problems
arise. And yes, we do take 'bug reports' and 'enhancement requests'
quite
seriously.
>
> So basically, the ones who are the best customers are penalized while the
> ones who steal the work are going to do so anyways (if the work is 'work'
> stealing in their sight).
>
--
Jeffrey Hobbs
> lvi...@cas.org wrote:
> > According to Stephan Uyttebroeck <ste...@frontierd.com>:
> > :I fully agree with that, but I believe that the byte codes discourages
> > :99.99% of the people ever trying it.
> >
> > I don't know if I agree with your percentage. However, it's the percent
> > not discouraged whom you should be most worried about - the percent
> True, but I should have pointed out that protection of the intellectual
> property was only part of the reason we use an 'encoding' mechanism.
> In the past we distributed our code unencoded and were then bitten by
> huge support costs of those 'best' customers who did their own bit of
> 'customization' until it was broken, then contacted customer support and
> 'forgot' to tell about their changes...
This is a very important point for companies that distribute Tcl code
to customers. I was at a company where the above was also a problem.
Of course, it was complicated by the fact that Tcl scripting was a feature
of the system, and certain parts were supposed to be modifiable (while
others should just be left untouched). I would bet that if you asked the
IT managers who distribute byte-coded scripts why they wanted it, this
problem would be more importantly cited than intellectual property stuff.
lvi...@cas.org
According to Jeffrey Hobbs <Jeffre...@icn.siemens.de>:
:Of course, it was complicated by the fact that Tcl scripting was a feature
:of the system, and certain parts were supposed to be modifiable (while
:others should just be left untouched).
I sure wish we could dream up some alternatives to closing the source 'for
the good of the customer' (ie to make our maintenance jobs possible -
I don't mean this in a negative way, however it sounds here) though.
By locking the source code up in some obscure manner means that customers
with a NEED to modify (to work around local filesystem names, bugs,
customizations, etc.) are stuck working against the system in some fashion.
Can we brainstorm on some alternatives?
For instance, some sort of digital signature/checksum that is generated
against the source code - if the signature doesn't match, then maintenance
knows that some changes have occured.
Or perhaps some method of a problem reporting which diffs a module against
some kind of 'static' version (cdrom, web, whatever) to show the maintenance
person any changes.
Or perhaps a style of development that encourages and supports creating
one's own versions of the fixed code, with changes, etc. The original is
encoded as you do now. However, when the customer needs to customize,
they get a utility which provides them the source for the code. They
modify that source and put it into a localization directory, which is
referenced before the authority directory. Then, when a problem report
is being made, one compares what's in the directory with the authority to
get a picture of what is localized.
JeroenHoppenbrouwers
files) to distribute as is (readable/editable), and which to compile to byte
codes. The runtime interpreter can eat both types of file. You can deliver most
of your app compiled with the user-modifiable parts in source. If you wrap the
source statement that includes the user part in a catch, you'll catch most of
the stupid mistakes, and you can always direct the user to replace the file
with some original files to see if the problem is located in or outside the
user module.
On top, you can wrap all calls to the user file in catch-es as well. Bit of
overhead, good way of pointing to the villain.
The same trick works with wrapped programs. Most files are hidden inside the
executable, some are sourced in live from the file system. Works like a charm
for us.
--
dr.ir. Jeroen Hoppenbrouwers, Senior Researcher at | Stop recycling code;
Infolab, Tilburg University, The Netherlands | start recycling ideas!
http://infolab.kub.nl/people/hoppie
Jeffrey Hobbs
> I sure wish we could dream up some alternatives to closing the source 'for
> the good of the customer' (ie to make our maintenance jobs possible -
> For instance, some sort of digital signature/checksum that is generated
> against the source code - if the signature doesn't match, then maintenance
> knows that some changes have occured.
md5 checksum of the like? This is easy enough, and Kupries has done
some Tcl specific stuff along these lines already (although it isn't
really necessary).
> Or perhaps some method of a problem reporting which diffs a module against
> some kind of 'static' version (cdrom, web, whatever) to show the maintenance
> person any changes.
This too is trivial, but ...
> Or perhaps a style of development that encourages and supports creating
> one's own versions of the fixed code, with changes, etc. The original is
> encoded as you do now. However, when the customer needs to customize,
> they get a utility which provides them the source for the code. They
And this is something of the ideal. However, they all fail a bit at the
original intent - having a portion of the code sacrosanct, while another
portion is modifiable. Generally, whatever you have the customer
customize should be very forgiving, or very bullet-proof to be able to
catch customer problems. Checksums and diffs tell you what the user
has changed:
1) The customer admits to changing something
2) If the customer lets you into their version of the code base
It's surprising how often you can't get to point 2, or how many
run-arounds you get in point 1.
With your last point, it is kind of a meta version of "restore defaults",
but sometimes you are working on something where two good fixes were
applied, and 1 bad one... A tricky situation.
Of course, I prefer my method of just writing bug-free code <duck and
run>...