 What
is Snob? ( Contents)
If you distribute
the source code of the whole or part of your project
distribution and want to protect your intellectual
property embodied in the code, Snob is an inexpensive
and versatile tool for you to achieve this goal.
Even if you are
distributing a pre-compiled library, you may want to
obfuscate the names that are not part of your API
because relocation tables in the library (and/or its
modules) do contain names from your source code.
"Snob"
sntands for "simple (or stupid, if you
like it better) name obfuscator".
Snob removes comments and replaces meaningful names
(identifiers) in your source code with meaningless and
similarly looking ones. This makes the code very hard to
read for a human being (but not a computer). As a usual
practice, a name obfuscator is used when the source code
containing proprietary knowledge needs to be
distributed. When a reader encounters your obfuscated
code, at the very least he understands that you wanted
to protect it and that it is not really for human eyes.
If he still wants to figure out how the code works, the
task is much harder if the names are meaningless.
Snob is freely
configurable to your project's programming languages and
to your needs in removing unwanted comments and
obfuscating names in an unrecoverable way.
This
flexibility is achieved by wide use of regular
expressions in Snob configuration. Among the many
choices in third-party regular expressions support
Snob uses arguably the best: PCRE library package,
which is open source software, written by Philip
Hazel, and
copyright the University of Cambridge, England. See
ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/
 What
is in Snob for me? (
Contents)
Here are a few cases
where you may favor name obfuscation and comments
removal:
 Code in a script language ( Contents)
If
your deliverable is, say, in JavaScript, everyone
can see client-side code by looking at the source of
the Web page. Even with the server-side scripts, you
do not necessarily want your customer to understand
the inner workings of the code.
Sometimes, a piece
of your project is just handy to write in Perl or a
shell script language. When the delivery time comes,
you may regret that you need to expose your code.
(Granted, those things are cryptic enough in
themselves but there are quite a few fluent speakers
of those languages.)
Same goes for
Python, Basic, and pretty much any interpreted
language.
Compiled code: Library
deliverables ( Contents)
In a way, the only
case where none of your names are exposed is a
standalone executable (OK, maybe with calls to standard
or third-party shared libraries/DLLs).
If your deliverable contains a library, the latter is
going to have some of the original code's names in its
relocation table. And, of course, your shared library
(or DLL, as the case may be) exposes names of exported
interfaces. If you deliver a static (linkable) library,
it has names internal to the library in relocation
table(s).
Mixed source and compiled code
( Contents)
A typical middleware
deliverable contains a pre-built library (or source code
to build it) and accompanying "glue" or API layer such
as necessary header files, sample application in source
code format and source code helping to integrate your
product into your customer's.
In this scenario,
you want to be selective and decide what comments to
keep and what comments to remove from your source code,
which names should stay intact and which should be
obfuscated.
 How does Snob work? (
Contents)
Snob makes a copy
of your project directory tree structure and populates
it with processed versions of files it recognizes in the
project directory tree.
Language configuration
( Contents)
For Snob to
recognize a file, its filename's extension (implying the
programming language) must be known to Snob. For a file
filename.foo,
Snob looks for the language-specific configuration file
dotfoo.snob.
Snob has natural rules for inheriting and overriding the
configurations in the project directory tree; it gives
you an additional freedom to configure the same language
differently in different subdirectories.
Language-specific
configuration provides for complete flexibility by using
the syntax of regular expressions. You can, for
instance, decide to keep or remove certain comments
selectively (such as explanatory comments vs. PC-Lint
or other tool-oriented comments, such as, e.g., Doxygen).
Project configuration
( Contents)
Snob allows you to
designate certain files as API files; the names there
will not be obfuscated and,depending how exactly they
are designated, they will or will not have their
comments stripped.
You can also
describe to Snob a set of words that should not be
obfuscated. This is handy to prevent erroneous
obfuscation of names coming from any third-party code,
and Snob itself can be empoyed as a tool for fishing for
those names.
 Is it hard to configure Snob? ( Contents)
If you have basic
configuration for your programming language(s)
pre-configured, configuring Snob for your project (or,
it may be said, configuring your project for Snob) is
really simple.
The harder part is
to get the language-specific configurations right.
First, check whether your programming language support
is posted on the download
page. We hope to post donated language configurations
there for all to use.
If you are out of
luck and need to create the basic configuration
yourself, you have the following options:
- Do it, maybe, using an
existing configuration as a template, and keep the
configuration all to yourself
- Do it, maybe, using an
existing configuration as a template, and share the
configuration with everyone by sending it to snob@macroexpressions.com
- Ask MacroExpressions to
make a configuration by writing to snob@macroexpressions.com
- Stop using Snob
With options (1) and
(2), you would have to wade through some regular
expressions, which may be even fun.
With
options (2) and (3), the resulting basic
configuration will be posted online, free to any
Snob user. One day you give, another day you
receive...
 Any debugging aids? (
Contents)
Your best debugging
aid is your build environment. If the obfuscated project
doesn't build, there must be a problem with project or
language configuration.
Your second best aid
is your regression test: Make sure the obfuscated
project works the same way as the original.
And if you do your
language-specific configuration yourself, do it on a
toy-size project first.
 How about a convincing example? ( Contents)
The source code included in
the downloadable C-SLang
distribution is obfuscated with Snob. By
intention (and by configuration) only private header
files in the distribution are obfuscated, except
published interfaces. See if you find non-API header
files there readable.
 How do I include Snob in my toolchain? ( Contents)
You probably don't
want to run Snob every time you build your project (such
as a post-link phase).
For your release candidate, all you need to do is to run
Snob on your project directory. And it is handy to have
the snob.exe in the PATH in your system.
It would be wise to
build the obfuscated version of the project (if it needs
compilation) and run the same regression tests on it as
you do on the original project. If the results differ,
there is a problem with Snob configuration, which you've
got to fix (or there is a bug in Snob itself). Normally,
you need to configure Snob only once for your project
and then use the same configuration as long as you don't
add new languages to the project.
If
you have any difficulties configuring or integrating
Snob, please, contact us
and we will be happy to help.
|
