For programming and/or technical savvy researchers:

Here is our scenario?
We have developed an ?Add-on? module for an existing commercial
software.   We want to be able to secure our module from end users
(customers) and other outsourced programmers that we might give the
source code to.  We?d like to protect ourselves by making sure no one
can use the software for free.

One of the questions is: 
Our module is released as an .exe or a .dll file.  Is there ANY way
that an end user can see the contents of that file?  For example, if
that program calls another dll , can an end user ever ?hack? (or
reverse engineer) the .exe file in any way to see what is being called
and what parameters are being exchanged?  We want to avoid the
possibilities of a hacker looking at the .exe content and make some
sense of it. We do not want them to replace it with a fake dll to
override ours.

The other question is:
What are some logical ways for us to secure our code via software
implementation?  We don?t want to use hardware, such as USB tokens.  
We thought about adding a field into our .INI (initialization file)
that contained some kind of random generated security code.  This will
work by protecting us from end users (our customers) that want to use
the software for free.  However, it doesn?t seem like it would help us
protect ourselves from other programmers we give the source code to.

Currently, when the software is run, our module gets loaded and reads
configuration values from a plain text .INI file.  We could possibly
add another module that the original module calls, and have the new
module do the security implementation.   But we are stuck as to how
the new module will implement the security.  The outsourced
programmers have full access to the add-on module?s source code.

The answer we are looking for will tell us how to secure our module
given the above scenario.   We are not looking for someone to program
code for us.  Please ask for clarification before you answer the
question, in case any part is unclear.

Why not just create a secondary external library or executable to
check for the licensing and only provide it in compiled form to your
outsourcers?  This is done all the time with java applications -- some
classes are just provided precompiled so that their contents won't be
discovered.

Secondly, are you opposed to using the registry to store the
information currently in the INI file?  See the following other Google
Answers question (and the comment dealing with the "hash"):

http://answers.google.com/answers/threadview?id=388053

WRT to the first question the short answer is yes.  Someone with
access to the binary can easily use a decompiler to gain access to an
approximation of your source code.  This is why some programmers will
run an obfuscator on their code prior to compiling the release.  Alas
even if the code is obfuscated, someone who is committed to figuring
out what your code is doing can just watch the stack while it is
running and see every call that is being passed.

Code that is sandboxed (a'la Java) can be more challenging to examine
once it has been obfuscated.  If you really want to protect yourself
from your external programmers, then giving them the source code is a
bad idea.  What would be far better is to give them compiled code and
have the interfaces well documented.  If they are using your code as a
component of a larger project then you will be well served to build in
test interfaces and logging mechanisms so that they will be able to
see how their code performs against your interfaces without tracing
everything in memory space.  I also strongly recommend that whomever
bears responsibility for this task read Greg Hoglund's excellent book
"Exploiting Software".  His co-author, Gary McGraw, is the foremost
expert in creating secure software, while Greg is a master of reverse
engineering.  The ISBN is: 0201786958