 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. |
