Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile: http://www.excelforum.com/member.php...o&userid=25756
View this thread: http://www.excelforum.com/showthread...hreadid=391909

The only way is to have some executable with key code in that so that it
cannot be broken into, such as a DLL or a COM addin.

--

HTH

RP
(remove nothere from the email address if mailing direct)


"fallingrock"
wrote in message
...

Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile:
http://www.excelforum.com/member.php...o&userid=25756
View this thread: http://www.excelforum.com/showthread...hreadid=391909

Physical denial is about the only sure way.

There are password crackers for every built in protection mechanism.

--
Regards,
Tom Ogilvy

"fallingrock"
wrote in message
...

Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile:
http://www.excelforum.com/member.php...o&userid=25756
View this thread: http://www.excelforum.com/showthread...hreadid=391909

I don't disseminate any of my projects but only produce them for work and
install them on our system. To prevent a staff member from taking one of them
if/when they leave the company, I include code in the Workbook_Open event
that looks for a simple text file and code phrase inside that file. If it
cannot be found then it won't open. They can make copies all they like but
can't open them outside of this environment. The people who would take my
stuff arn't skilled enough to crack VBProject protection.

Regards,
Greg



"fallingrock" wrote:


Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile: http://www.excelforum.com/member.php...o&userid=25756
View this thread: http://www.excelforum.com/showthread...hreadid=391909

The only problem with events is that they are macros and anyone can open a
workbook and turn macros off.

They may not be able to get to the VBE code (???), but they can get to all
the worksheets...
(or some one could).

It all depends on the people...

For the most part - protection only helps prevent "accidents".

--
steveB

Remove "AYN" from email to respond
"Greg Wilson" wrote in message
...
I don't disseminate any of my projects but only produce them for work and
install them on our system. To prevent a staff member from taking one of
them
if/when they leave the company, I include code in the Workbook_Open event
that looks for a simple text file and code phrase inside that file. If it
cannot be found then it won't open. They can make copies all they like but
can't open them outside of this environment. The people who would take my
stuff arn't skilled enough to crack VBProject protection.

Regards,
Greg



"fallingrock" wrote:


Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile:
http://www.excelforum.com/member.php...o&userid=25756
View this thread:
http://www.excelforum.com/showthread...hreadid=391909

I agree Steve. But in my case, the code is all I am concerned about.
Typically, the code is the important issue for developers. In my case, the
data isn't confidential and anyone can setup worksheet formattng. And my
projects are basically dysfunctional without the code.

Worksheet and workbook (as opposed to file open) protection can be broken in
seconds for those in the know. When I think of the people in my office and in
my industry who potentially would want my stuff, except for our IT guy, few
if any could even break worksheet protection. They wouldn't even know how to
implement VBA code. Therefore, the strategy I mentioned is of value for most
situations. After spending a zillion hours developing something we tend to
overestimate its perceived value to others.

Regards,
Greg

"STEVE BELL" wrote:

The only problem with events is that they are macros and anyone can open a
workbook and turn macros off.

They may not be able to get to the VBE code (???), but they can get to all
the worksheets...
(or some one could).

It all depends on the people...

For the most part - protection only helps prevent "accidents".

--
steveB

Remove "AYN" from email to respond
"Greg Wilson" wrote in message
...
I don't disseminate any of my projects but only produce them for work and
install them on our system. To prevent a staff member from taking one of
them
if/when they leave the company, I include code in the Workbook_Open event
that looks for a simple text file and code phrase inside that file. If it
cannot be found then it won't open. They can make copies all they like but
can't open them outside of this environment. The people who would take my
stuff arn't skilled enough to crack VBProject protection.

Regards,
Greg



"fallingrock" wrote:


Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile:
http://www.excelforum.com/member.php...o&userid=25756
View this thread:
http://www.excelforum.com/showthread...hreadid=391909

As you are probably aware, there is a well know technique to have an
introductory worksheet that is normally kept xlVeryHidden. On close it is
made visible and all others are made xlVeryHidden. On open, if macros are
enabled, the introductory sheet is made xlVeryHidden and the others are made
visible. No problem. However, if macros are disabled, all you will see is
this sheet telling you to enable macros in order to use the wb - i.e. the
others remain xlVeryHidden.

I don't go to this bother because (so far at least) it's unnessecsary for my
projects. But it's something I do consider because worksheet functions can
get complex and may be something to protect.

Regards,
Greg


"Greg Wilson" wrote:

I agree Steve. But in my case, the code is all I am concerned about.
Typically, the code is the important issue for developers. In my case, the
data isn't confidential and anyone can setup worksheet formattng. And my
projects are basically dysfunctional without the code.

Worksheet and workbook (as opposed to file open) protection can be broken in
seconds for those in the know. When I think of the people in my office and in
my industry who potentially would want my stuff, except for our IT guy, few
if any could even break worksheet protection. They wouldn't even know how to
implement VBA code. Therefore, the strategy I mentioned is of value for most
situations. After spending a zillion hours developing something we tend to
overestimate its perceived value to others.

Regards,
Greg

"STEVE BELL" wrote:

The only problem with events is that they are macros and anyone can open a
workbook and turn macros off.

They may not be able to get to the VBE code (???), but they can get to all
the worksheets...
(or some one could).

It all depends on the people...

For the most part - protection only helps prevent "accidents".

--
steveB

Remove "AYN" from email to respond
"Greg Wilson" wrote in message
...
I don't disseminate any of my projects but only produce them for work and
install them on our system. To prevent a staff member from taking one of
them
if/when they leave the company, I include code in the Workbook_Open event
that looks for a simple text file and code phrase inside that file. If it
cannot be found then it won't open. They can make copies all they like but
can't open them outside of this environment. The people who would take my
stuff arn't skilled enough to crack VBProject protection.

Regards,
Greg



"fallingrock" wrote:


Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile:
http://www.excelforum.com/member.php...o&userid=25756
View this thread:
http://www.excelforum.com/showthread...hreadid=391909

Greg,

We agree!

The "blank" or "message" sheet is great to discourage people. More
importantly it's a great way to make a one-workbook-fits-all
and than restrict the users to their own pages...

I sometimes hide sheets just to make the envirorment cleaner for the user.

And again - anything I can do to help the user "not mess wit stuff"...
keeps the project healthier.

As you may have noticed - your code for unprotected cells only has become a
favorite of mine.
It really helps when creating forms on the worksheet... and protects those
massive formulas...

Thanks for your support...

--
steveB

Remove "AYN" from email to respond
"Greg Wilson" wrote in message
...
As you are probably aware, there is a well know technique to have an
introductory worksheet that is normally kept xlVeryHidden. On close it is
made visible and all others are made xlVeryHidden. On open, if macros are
enabled, the introductory sheet is made xlVeryHidden and the others are
made
visible. No problem. However, if macros are disabled, all you will see is
this sheet telling you to enable macros in order to use the wb - i.e. the
others remain xlVeryHidden.

I don't go to this bother because (so far at least) it's unnessecsary for
my
projects. But it's something I do consider because worksheet functions can
get complex and may be something to protect.

Regards,
Greg


"Greg Wilson" wrote:

I agree Steve. But in my case, the code is all I am concerned about.
Typically, the code is the important issue for developers. In my case,
the
data isn't confidential and anyone can setup worksheet formattng. And my
projects are basically dysfunctional without the code.

Worksheet and workbook (as opposed to file open) protection can be broken
in
seconds for those in the know. When I think of the people in my office
and in
my industry who potentially would want my stuff, except for our IT guy,
few
if any could even break worksheet protection. They wouldn't even know how
to
implement VBA code. Therefore, the strategy I mentioned is of value for
most
situations. After spending a zillion hours developing something we tend
to
overestimate its perceived value to others.

Regards,
Greg

"STEVE BELL" wrote:

The only problem with events is that they are macros and anyone can
open a
workbook and turn macros off.

They may not be able to get to the VBE code (???), but they can get to
all
the worksheets...
(or some one could).

It all depends on the people...

For the most part - protection only helps prevent "accidents".

--
steveB

Remove "AYN" from email to respond
"Greg Wilson" wrote in message
...
I don't disseminate any of my projects but only produce them for work
and
install them on our system. To prevent a staff member from taking one
of
them
if/when they leave the company, I include code in the Workbook_Open
event
that looks for a simple text file and code phrase inside that file.
If it
cannot be found then it won't open. They can make copies all they
like but
can't open them outside of this environment. The people who would
take my
stuff arn't skilled enough to crack VBProject protection.

Regards,
Greg



"fallingrock" wrote:


Anyone have some idea, tricks, code, suggestions, examples of how to
reduce if not prevent Excel-based products (like an Excel Template)
from being used by a person who did not buy it (i.e., illegal
copying
and sharing)?


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile:
http://www.excelforum.com/member.php...o&userid=25756
View this thread:
http://www.excelforum.com/showthread...hreadid=391909

Greg,

Your idea sounds secure enough. It doesn't involve a registry change o
a scan of the user id. Simply write a file to their hard drive (somewha
like a cookie), then open and read a key phrase from that file befor
allowing the Excel template to launch a new instance. I can code that
But, that will take an installer app to write the txt file to dis
(somewhere on C: drive, I presume) right? Got a reference o
recommendation for an installer? Maybe Excel could do this the firs
time it is run, i the text file is supplied and somehow disquised fro
its true purpose.

Thanks all for the response to this "can't be done" thread

--
fallingroc
-----------------------------------------------------------------------
fallingrock's Profile: http://www.excelforum.com/member.php...fo&userid=2575
View this thread: http://www.excelforum.com/showthread.php?threadid=39190

First, be advised that I'm no computer expert. Just a guy trying to be
recognized as the office guru on Excel. I don't have to widely distribute a
product to make a living. So I just manually install the file myself. I
misspoke when I said that you can't open the file as Steve pointed out. You
can open it with macros disabled of course. See our comments if you havn't
already.

Maybe Excel could do this the first
time it is run, i the text file is supplied and somehow disquised from
its true purpose.

You can install a text file using Excel and add text in case the above
implies that you thought you couldn't. Text is optional actually. A file with
the given name need only exist at a certain location.

The idea (if that's what you meant) of the template modifying itself on
first use after installing the cookie will work for my situation since I can
walk away with the floppy afterwards. I only need worry about staff copying
the file off the system after it has already been used. Granted, this will
only save me the step of manually installing the file. Obviously, if you are
distributing the template then they will just save the original floppy/CD
which can be reused.

Just throwing out this idea which is probably dumb: If your programs are
highly specialized involving only a small number of sales then it may be
feasible to always distribute a demo version first. The demo version is
really a ruse which also installs the cookie. The client then must purchase
the full version from you to obtain full functionality and don't know that
they have the cookie installed. So all legitimate clients first run the demo
version and then the real version. If someone makes a copy of the full
version or walks off with the floppy then it won't work. I don't believe
anyone has a good answer for this situation.

Regards,
Greg






"fallingrock" wrote:


Greg,

Your idea sounds secure enough. It doesn't involve a registry change or
a scan of the user id. Simply write a file to their hard drive (somewhat
like a cookie), then open and read a key phrase from that file before
allowing the Excel template to launch a new instance. I can code that.
But, that will take an installer app to write the txt file to disk
(somewhere on C: drive, I presume) right? Got a reference or
recommendation for an installer? Maybe Excel could do this the first
time it is run, i the text file is supplied and somehow disquised from
its true purpose.

Thanks all for the response to this "can't be done" thread.


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile: http://www.excelforum.com/member.php...o&userid=25756
View this thread: http://www.excelforum.com/showthread...hreadid=391909

Worksheet and workbook (as opposed to file open) protection can be broken in
seconds for those in the know. When I think of the people in my office and in

See for example this simple code for unprotecting a password protected
worksheet, including a real life example:

Excel do not password protect sheets properly
http://www.pvv.org/~nsaa/excel.html#12

Regards
Nikolai

As we have been trying to point out:
There is no perfect way to protect Excel. Protection is the wrong word.
It is really a minor
safety feature that helps prevent messing with sensitive features of a
workbook.

There are ways to make it more difficult for users to have access to
sensitive areas - but few (if any) are perfect.

Greg has found a method that works well in his environment. So if you want
to add safety to your workbooks - take Greg's advice.
--
steveB

Remove "AYN" from email to respond
wrote in message
ups.com...
Worksheet and workbook (as opposed to file open) protection can be broken
in
seconds for those in the know. When I think of the people in my office and
in

See for example this simple code for unprotecting a password protected
worksheet, including a real life example:

Excel do not password protect sheets properly
http://www.pvv.org/~nsaa/excel.html#12

Regards
Nikolai

If you give the user the install package (which you will need to do), why
can't they distribute that to whomever they wish. The only thing that would
enforce checking the text file would be running a macro. Running the macro
is easily disabled even by the most novice user. Hiding sheets is again,
trivial protection. Why wouldn't your user, no matter how computer
illiterate have a "Greg" (local office guru) in the office. If you really
have something to protect, then you are pretty much wasting your time
pursing the routes suggested. Also, if this is really a template
(file=New), then no code runs before the new instance is created.

Anyway, do what you want. Have fun.

--
Regards,
Tom Ogilvy

"fallingrock"
wrote in message
...

Greg,

Your idea sounds secure enough. It doesn't involve a registry change or
a scan of the user id. Simply write a file to their hard drive (somewhat
like a cookie), then open and read a key phrase from that file before
allowing the Excel template to launch a new instance. I can code that.
But, that will take an installer app to write the txt file to disk
(somewhere on C: drive, I presume) right? Got a reference or
recommendation for an installer? Maybe Excel could do this the first
time it is run, i the text file is supplied and somehow disquised from
its true purpose.

Thanks all for the response to this "can't be done" thread.


--
fallingrock
------------------------------------------------------------------------
fallingrock's Profile:
http://www.excelforum.com/member.php...o&userid=25756
View this thread: http://www.excelforum.com/showthread...hreadid=391909

Good example on your site of easily breaking the hidden sheet protection
approach. LOL

--
Regards,
Tom Ogilvy

wrote in message
ups.com...
Worksheet and workbook (as opposed to file open) protection can be broken
in
seconds for those in the know. When I think of the people in my office
and in

See for example this simple code for unprotecting a password protected
worksheet, including a real life example:

Excel do not password protect sheets properly
http://www.pvv.org/~nsaa/excel.html#12

Regards
Nikolai

I am well aware of the code example you quoted. In fact, I've quoted it
myself in former posts. The truth is, you can actually unprotect a worksheet
with just two lines of code. I am not willing to share this because, in my
view, this would be a disservice to the Excel community. But this statement
does underscore the poor protection issue.

Regards,
Greg

" wrote:

Worksheet and workbook (as opposed to file open) protection can be broken in
seconds for those in the know. When I think of the people in my office and in

See for example this simple code for unprotecting a password protected
worksheet, including a real life example:

Excel do not password protect sheets properly
http://www.pvv.org/~nsaa/excel.html#12

Regards
Nikolai

I am not willing to share this because, in my
view, this would be a disservice to the Excel community.

Why is this a disservice? The code is freely aviable on a lot of sites.
People should be aware of this so they can take propper measurements to
protect themselves. Why havn't Microsoft fixed this problem?...

This is maybe the first time the code appears (according to
http://www.militaryfairy.co.uk/Docs/...Passwords.html) at a
newsgroup:
http://groups.google.com/group/micro...=UTF-8&rnum=17


Sub InternalPasswords()
'Original (?)by Bob McCormick on NG:
'microsoft.public.excel.misc on 22 May 2001.
'Adapted for workbook passwords Norman Harker 19 Nov 2002
'Breaks workbook and worksheet password protection.
'Works for either workbook or worksheet passwords or both
'"comment out" the nested if functions to make applicable.

It is a disservice because people use protection to help protect (even
though it doesn't).
And any thing that defeats this is actually doing a criminal act (even if it
is minor).
It would be like people being able to figure out your pin number, account
password, etc...

Just because the code is available - doesn't make it right.

Do you favor having sites on the internet that show people how to make
bombs? I don't!

Would you favor having your Social Security Number available on the
internet? I don't!

These things and more are possible - but morally and ethically - they don't
belong...

--
steveB

Remove "AYN" from email to respond
wrote in message
oups.com...
I am not willing to share this because, in my
view, this would be a disservice to the Excel community.

Why is this a disservice? The code is freely aviable on a lot of sites.
People should be aware of this so they can take propper measurements to
protect themselves. Why havn't Microsoft fixed this problem?...

This is maybe the first time the code appears (according to
http://www.militaryfairy.co.uk/Docs/...Passwords.html) at a
newsgroup:
http://groups.google.com/group/micro...=UTF-8&rnum=17


Sub InternalPasswords()
'Original (?)by Bob McCormick on NG:
'microsoft.public.excel.misc on 22 May 2001.
'Adapted for workbook passwords Norman Harker 19 Nov 2002
'Breaks workbook and worksheet password protection.
'Works for either workbook or worksheet passwords or both
'"comment out" the nested if functions to make applicable.

It's a disservice because, unlike your examples, it can be done with just two
lines of code (I'm serious). Two lines can obviously be reproduced from
memory. In other words, you can literally break ws protection in about the
same time as someone who knows the password. At least the other examples
require a little preparation and VBA knowledge. It's a disservice because
it's my impression that only very few know the code to this point. IMO, it's
best to keep it this way. When I discouvered I was dissapointed.

This NG often gives the opinion that ws protection is useless. Weak as hell
no doubt. But I personally find that it still keeps the majority from
screwing things up. Not that they wouldn't be quite happy to do so. They just
don't know how.

Regards,
Greg

" wrote:

I am not willing to share this because, in my
view, this would be a disservice to the Excel community.

Why is this a disservice? The code is freely aviable on a lot of sites.
People should be aware of this so they can take propper measurements to
protect themselves. Why havn't Microsoft fixed this problem?...

This is maybe the first time the code appears (according to
http://www.militaryfairy.co.uk/Docs/...Passwords.html) at a
newsgroup:
http://groups.google.com/group/micro...=UTF-8&rnum=17


Sub InternalPasswords()
'Original (?)by Bob McCormick on NG:
'microsoft.public.excel.misc on 22 May 2001.
'Adapted for workbook passwords Norman Harker 19 Nov 2002
'Breaks workbook and worksheet password protection.
'Works for either workbook or worksheet passwords or both
'"comment out" the nested if functions to make applicable.

There is a protection system called CD-Cops Crypto (
http://www.linkdata.com/crypto.htm ) which provides protection for
Excel workbooks, by encrypting the file and only allowing it to be
opened from the original CD-ROM.

Kind regards,
Terry

Greg Wilson wrote:
It's a disservice because, unlike your examples, it can be done with just two
lines of code (I'm serious). Two lines can obviously be reproduced from
memory. In other words, you can literally break ws protection in about the
same time as someone who knows the password. At least the other examples
require a little preparation and VBA knowledge. It's a disservice because
it's my impression that only very few know the code to this point. IMO, it's
best to keep it this way. When I discouvered I was dissapointed.

This NG often gives the opinion that ws protection is useless. Weak as hell
no doubt. But I personally find that it still keeps the majority from
screwing things up. Not that they wouldn't be quite happy to do so. They just
don't know how.

Regards,
Greg

" wrote:

I am not willing to share this because, in my
view, this would be a disservice to the Excel community.

Why is this a disservice? The code is freely aviable on a lot of sites.
People should be aware of this so they can take propper measurements to
protect themselves. Why havn't Microsoft fixed this problem?...

This is maybe the first time the code appears (according to
http://www.militaryfairy.co.uk/Docs/...Passwords.html) at a
newsgroup:
http://groups.google.com/group/micro...=UTF-8&rnum=17


Sub InternalPasswords()
'Original (?)by Bob McCormick on NG:
'microsoft.public.excel.misc on 22 May 2001.
'Adapted for workbook passwords Norman Harker 19 Nov 2002
'Breaks workbook and worksheet password protection.
'Works for either workbook or worksheet passwords or both
'"comment out" the nested if functions to make applicable.