Safeguarding Excel Products from Piracy

[fallingrock]

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)?

[Bob Phillips]

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" <[email protected]>
wrote in message
news:[email protected]...
>
> 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
>

[Tom Ogilvy]

Physical denial is about the only sure way.

There are password crackers for every built in protection mechanism.

--
Regards,
Tom Ogilvy

"fallingrock" <[email protected]>
wrote in message
news:[email protected]...
>
> 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 Wilson]

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

[STEVE BELL]

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" <[email protected]> wrote in message
news:[email protected]...
>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 Wilson]

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" <[email protected]> wrote in message
> news:[email protected]...
> >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 Wilson]

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" <[email protected]> wrote in message
> > news:[email protected]...
> > >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
> > >>
> > >>
> >
> >
> >

[STEVE BELL]

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" <[email protected]> wrote in message
news:[email protected]...
> 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" <[email protected]> wrote in message
>> > news:[email protected]...
>> > >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
>> > >>
>> > >>
>> >
>> >
>> >

[fallingrock]

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.

[Greg Wilson]

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

[[email protected]]

>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

[STEVE BELL]

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
<[email protected]> wrote in message
news:[email protected]...
> >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
>

[Tom Ogilvy]

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" <[email protected]>
wrote in message
news:[email protected]...
>
> 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
>

[Tom Ogilvy]

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

--
Regards,
Tom Ogilvy

<[email protected]> wrote in message
news:[email protected]...
> >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
>

[Greg Wilson]

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

"[email protected]" 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
>
>

[[email protected]]

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

[STEVE BELL]

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
<[email protected]> wrote in message
news:[email protected]...
>> 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.
>

[Greg Wilson]

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

"[email protected]" 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.
>
>

[[email protected]]

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
>
> "[email protected]" 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.
> >
> >

[falcus]

The protection in excel at workbook & sheet level is rubbish .

A simple function will unlock either, I can post the function upon request. The password used to unlock the sheet / workbook doesn't need to be the same lenght or even the same char string.