Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

BP source code obfuscaters: secure?

21 views
Skip to first unread message
Message has been deleted

Duncan Murdoch

unread,
Apr 28, 1994, 6:02:11 PM4/28/94
to
In article <ayXiLc...@mjmnode.equinox.gen.nz> man...@mjmnode.equinox.gen.nz (Manfred Marriott) writes:

>Is obfuscating Turbo Pascal source code a "safe" way of securing
>code ....?

>If it is, perhaps if we write/get one, we can get convince s/w
>publishers to release obfuscated code, rather than TPU's, or
>better still, get Borland to put the code for one in BP8, so this
>problem doesn't continue. Any comments?

I think that you are much better off with open source code than with .TPU
files or obfuscated source. When you find bugs or need to make
changes because conditions have changed, you can do the fixes. You won't be
relying on someone who may have gone out of business or lost interest in
the code.

If I can possibly help it, I don't use code when the source is unavailable.
The only exceptions I make are for units that ship with the compiler, and
I'm unhappy about those.


Duncan Murdoch
dmur...@mast.queensu.ca

Chris Chapman

unread,
Apr 28, 1994, 5:10:16 PM4/28/94
to
In article <ayXiLc...@mjmnode.equinox.gen.nz> man...@mjmnode.equinox.gen.nz (Manfred Marriott) writes:

>Is obfuscating Turbo Pascal source code a "safe" way of securing

>code, where any "humanised" names (variables, procedures etc)
>are replaced with random numbers, white space is removed, code
>portions are moved etc? The result is a program that compiles, but
>is essentially unreadable. Such that a very simple 100 line program
>becomes a mammoth 5 hour effort to convert back again?

>If it is, perhaps if we write/get one, we can get convince s/w
>publishers to release obfuscated code, rather than TPU's, or
>better still, get Borland to put the code for one in BP8, so this
>problem doesn't continue. Any comments?


I doubt that it would require 5 hours to figure out 100 lines, since a
pretty printing program could restore all of the program structure very
quickly. However, having nonsense variables and procedure/function names
would certainly secure any very long section of code (maybe a few hundred
lines and up) from all but the most determined.

The problem with this is: the raison d'etre for source code libraries is
exactly so that users **can** figure out what is going on (in inherited
methods, for instance).

If the *only* compatibility problem with the units is that the unit object
structure has changed, then the vendor should simply compile and provide new
units. However, in my experience, the unit problem is usually related to
other language items that have changed significantly, and some *re-writing*
of the unit code is needed (say, by altering the parameter types to be Pchar
instead of strings, or some new disk structure type).

If you're dealing with obfuscated code, then these simple re-writes will be
impossible.

The best solution, IMHO, would be for users to demand source code from unit
providers -- or to demand that the language stop evolving, which none of us
really wants ...

-- chris
-- cc...@bongo.cc.utexas.edu

Louise Burfleet

unread,
Apr 29, 1994, 3:29:55 AM4/29/94
to
In article <ayXiLc...@mjmnode.equinox.gen.nz>,

Manfred Marriott <man...@mjmnode.equinox.gen.nz> wrote:
>Is obfuscating Turbo Pascal source code a "safe" way of securing
>code, where any "humanised" names (variables, procedures etc)
>are replaced with random numbers, white space is removed, code
>portions are moved etc? The result is a program that compiles, but
>is essentially unreadable. Such that a very simple 100 line program
>becomes a mammoth 5 hour effort to convert back again?

It certainly isn't safe.

>If it is, perhaps if we write/get one, we can get convince s/w
>publishers to release obfuscated code, rather than TPU's, or
>better still, get Borland to put the code for one in BP8, so this
>problem doesn't continue. Any comments?

I have in the past used units that have been downloaded from various
BBS's that have been through this process, there is a shareware (I think)
program called Mangler that will convert source code.

As an exercise I wrote a program to take a mangled source file and
convert it back into a readable program.

While Mangler makes it dificult to read code, it certainly does not
make it impossible.

I would prefer to see an option to partly compile a unit, so that a
user could download this file and then the compiler would complete
the compilation into whichever version was being used.

I know this won't help for the huge amount of TP3-6 code that is
available, but it will clear up the problem in the long term.

Louise
------


s...@uno.edu

unread,
May 2, 1994, 4:48:51 PM5/2/94
to
In article <ayXiLc...@mjmnode.equinox.gen.nz>, man...@mjmnode.equinox.gen.nz (Manfred Marriott) writes:
>Most of us know about the problem with the inability of
>Borland/Turbo Pascal to use old versions TPU files.
>If one happens to write all your source, this is not a problem,
>but if you get little TPU's from a BBS or a CD-ROM, it is.

>
>Is obfuscating Turbo Pascal source code a "safe" way of securing
>code, where any "humanised" names (variables, procedures etc)
>are replaced with random numbers, white space is removed, code
>portions are moved etc? The result is a program that compiles, but
>is essentially unreadable. Such that a very simple 100 line program
>becomes a mammoth 5 hour effort to convert back again?
>
>If it is, perhaps if we write/get one, we can get convince s/w
>publishers to release obfuscated code, rather than TPU's, or
>better still, get Borland to put the code for one in BP8, so this
>problem doesn't continue. Any comments?
>
>--
>Manfred Marriott man...@mjmnode.equinox.gen.nz
>Christchurch, New Zealand +64 3 379-9489

I think as good, or better a question that I've never had answered to my
satisfaction is why should an upgrade to the language necessarily break the
older units? Presumably most of the changes from version to version are of
the "Superset" type (i.e. the new features are additions to the language, not
changes in how what's already there works), how hard would it be for the
compiler to detect the unit version and call it accordingly?

Inquiring minds want to know.

-* Stephen *-
Stephen Posey
S...@uno.edu
University of New Orleans

Duncan Murdoch

unread,
May 2, 1994, 6:41:14 PM5/2/94
to

>I think as good, or better a question that I've never had answered to my
>satisfaction is why should an upgrade to the language necessarily break the
>older units?

TPU files aren't independent entities like .OBJ files are. They are already
linked to each other. Your TP 6 .TPU file has already been linked
to the TP 6 System unit. (Code isn't copied, but the .TPU contains hard
coded file offsets from the System.TPU file.) The BP 7 System unit has more
in it, and things are in different places, so the links from your old .TPU
don't work.

It probably wouldn't be too hard to write a new linker that would link TP 6
units to BP 7 units, but each would have its own copy of System, and those
would almost certainly clash with each other so your program wouldn't work.

It's probably possible to write a program to take a TP 6 unit, unlink it
from the TP 6 libraries, figure out corresponding parts of BP 7 for all
those external references, and rewrite it as a BP 7 unit linked to BP 7
libraries. But that's a *lot* more work, and so far nobody has felt like
wasting their time on it.

Duncan Murdoch

Rob Heyes

unread,
May 2, 1994, 10:51:44 PM5/2/94
to
I've heard that the TP* format contains a verbatim copy of some of the
compiler's internal data structures (e.g. symbol table) which are simply
loaded into memory and helps to account for the amazing compilation speed
for which TP & BP are justly famous. ISTR that this information came from
Borland.

Rob
--
Do not let penguins embarrass you if they happen to drop in when you
are just sitting down to dinner. Evening dress is quite optional in
Arctic Circles. Sellar and Yeatman

Rob Heyes r...@brewster.demon.co.uk, rhe...@cix.compulink.co.uk

Erik Johnson

unread,
May 2, 1994, 8:27:00 PM5/2/94
to man...@mjmnode.equinox.gen.nz
-> Is obfuscating Turbo Pascal source code a "safe" way of securing
-> code, where any "humanised" names (variables, procedures etc)
-> are replaced with random numbers, white space is removed, code
-> portions are moved etc? The result is a program that compiles, but
-> is essentially unreadable. Such that a very simple 100 line program
-> becomes a mammoth 5 hour effort to convert back again?
Anybody dedicated enough could probably undo the obfuscation (remember,
this is Pascal, not C). Code highlighting would allow you to get a
sense of the structure, then global search and replaces and some
structuring could get something remotely readable. Of course having
random variable, procedure, function names would make life rough. How
about the library makers license their code, like Turbo Power does.
That makes life much easier for everybody, especially if the library has
quirks that the code can clarify. Our policy is to NEVER purchase
libraries that don't come with source, or don't offer source at an extra
cost (even if it is VERY extra).
0 new messages