Asp Forum - Protecting a COM DLL - microsoft.public.vb.general.discussion

Leo

2/12/2011 3:21:00 PM

I am wondering what the best way to protect a COM DLL from being used
by a developer that has the DLL installed on their machine by an
authorised application whilst not holding a developer liscense? would
it be similar to the suggestions in Beej's thread?

--
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-sep...

7 Answers

Mayayana

2/12/2011 4:04:00 PM

I think what you want is this:

http://support.microsoft.com...

There are probably more pages about it. I remember
it was also detailed in the version of MSDN that came
with VS6, but I can't seem to find it at the moment.

|I am wondering what the best way to protect a COM DLL from being used
| by a developer that has the DLL installed on their machine by an
| authorised application whilst not holding a developer liscense? would
| it be similar to the suggestions in Beej's thread?

Leo

2/13/2011 12:00:00 PM

Mayayana wrote on 13/02/2011 :
> I think what you want is this:
>
> http://support.microsoft.com...
>
> There are probably more pages about it. I remember
> it was also detailed in the version of MSDN that came
> with VS6, but I can't seem to find it at the moment.
>
>> I am wondering what the best way to protect a COM DLL from being used
>> by a developer that has the DLL installed on their machine by an
>> authorised application whilst not holding a developer liscense? would
>> it be similar to the suggestions in Beej's thread?

That only seems to apply to ocx's and the same for MSDN 6a. I want to
create a DLL.

--
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Free usenet access at http://www.eternal-sep...

Mayayana

2/13/2011 2:28:00 PM

| That only seems to apply to ocx's and the same for MSDN 6a. I want to
| create a DLL.
|

Woops. I guess you're right. I started looking through
my installed COM libs. comct232.ocx, for instance, has
4 objects. Two are controls that require a license. Two are
not controls and don't require a license. I guess it breaks
down to classes rather than files/typelibs. Maybe it would
make sense to create your file as an OCX? As Matthew
Curland says in his book, "An OCX is just an ActiveX
DLL with a fancy file extension" (And with a handful of
different typelib flags/Registry settings). It would just
require that you offer a control to be sited on a form. That
only requires that the project use a form somewhere.
Lots of controls work that way: comdlg32, winsock, timer, etc.

It may also be feasible to
turn a DLL into a licensed ActiveX by editing the typelib
to mark your creatable class as requiring a license. But it's
hard to see where that would be worth the trouble, just
for the sake of getting a DLL instead of an OCX. And
I think an ActiveX license is just a long string in a Registry
key, anyway -- easily forged. The licensing
depends not on the sophistication of the method but rather
on the fact that people who use the controls commercially
want to make money, and for that they have to work legally.

If you just don't want others to freeload from your work,
and you're not actually selling a component, the limitations
of COMs alleged "self-documenting" feature should be
sufficient. A typelib, without docs, rarely provides enough
information to make an object usable. This topic has come
up before and some people have suggested using a red
herring extra parameter in function calls in order to make
the lib. unusable to the uninitiated as an extra security
option.

If you want to sell a DLL for others to use in their software
then it seems like a good idea to seriously think about
switching to OCX. Otherwise, how will your customers
deal with it? If they have an OCX their installer can just
register that. The security functionality is built into the
system. If instead you come up with your own protection
scheme then your customers will also have to use that
protection scheme. (In other words, if your DLL won't run
until it checks hardware or reads the Registry, then the parent
software is involuntarily hobbled by the same limitation.)

(nobody)

2/13/2011 2:40:00 PM

Kevin Provance

2/13/2011 8:33:00 PM

This is what I do.

Create a property in your DLL to which you will pass some kind of long
number (recommended) or string. Compare it to the exacted value. If it
matches, set a global var to true.

In the functions or subs you want protected, check the global var for true
before allowing the code to execute.

It's flimsy, but it works. A couple of times I forget to set my key and
wondered why none of the functions in my DLL were working. You could also
set any functions to return a unique number upon failure of the key check,
for your own usage.

"Leo" <ttdhead@gmail.com> wrote in message
news:ij68ha$kg5$1@news.eternal-september.org...
>I am wondering what the best way to protect a COM DLL from being used by a
>developer that has the DLL installed on their machine by an authorised
>application whilst not holding a developer liscense? would it be similar to
>the suggestions in Beej's thread?
>
> --
> ClassicVB Users Regroup! comp.lang.basic.visual.misc
> Free usenet access at http://www.eternal-sep...
>
>

GS

2/13/2011 11:10:00 PM

Kevin Provance formulated the question :
> Create a property in your DLL to which you will pass some kind of long number
> (recommended) or string. Compare it to the exacted value. If it matches,
> set a global var to true.
>
> In the functions or subs you want protected, check the global var for true
> before allowing the code to execute.

This is how I discourage/prevent unlicensed use of my COMAddin.DLLs. It
works okay (so far) since the entry points are public methods of a
class within the DLL.

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup! comp.lang.basic.visual.misc

MikeD

2/14/2011 10:08:00 PM

"Leo" <ttdhead@gmail.com> wrote in message
news:ij68ha$kg5$1@news.eternal-september.org...
> I am wondering what the best way to protect a COM DLL from being used by a
> developer that has the DLL installed on their machine by an authorised
> application whilst not holding a developer liscense? would it be similar
> to the suggestions in Beej's thread?

In the Class_Initialize event of the class module, perform a check using
whatever algorithm you wish for determining if development use is permitted
or not. This might be some of the same things discussed in that thread or
something entirely different. If development use is NOT allowed, raise an
error in the Class_Initialize event. This will prevent the object from even
being instantiated.

You *may* need find out what app is using the DLL, which might be enough for
determining if development use is allowed. Something like this:

Private Declare Function GetModuleHandle Lib "kernel32" Alias
"GetModuleHandleA" (ByVal lpModuleName As String) As Long

Private Const NotLicensedErr As Long = vbObjectError + 5001

Private Function IsMyApp() As Boolean

Dim hModule As Long

hModule = GetModuleHandle("MyApp.exe")
IsMyApp = hModule

End Function

Private Sub Class_Initialize()

Dim sErr As String

sErr = "[DLLAppName] is not licensed for design-time use on this
computer."

If Not IsMyApp Then
'Raising an error will prevent the class from instantiating
Err.Raise NotLicensedErr, , sErr
End If

End Sub

Change "MyApp.exe" to the file name of your actual application. You should
probably also change the name of the function to something other than
IsMyApp, but that doesn't really matter a whole lot.

This WILL prevent you from using the DLL in VB while you're writing your
program (the one using the DLL). So, comment out that code in
Class_Initialize (you don't need to comment out the IsMyApp function since
it's Private) until after you've compiled your program for distribution.
After you've compiled your program, uncomment that code in Class_Initialize
and recompile the DLL for distribution. *Make sure you have the Binary
Compatibility option set !!* If you don't have that set, your program won't
be able to use the recompiled DLL without recompiling the program using the
DLL, and you won't be able to do that because now the DLL won't be able to
be used in VB6.

Now, instead of messing with all this commenting and un-commenting of code
and recompiling, you might want to go with something a little more
sophisticated in determining if development use of the DLL is allowed or
not. I'm not telling you what to do in that regard or even making a
suggestion for that really. The above is really just to show the concept a
little clearer.

The only suggestion I'm really providing is to raise an error in
Class_Initialize if development use should not be allowed. You only need to
do this in class modules of your DLL whose Instancing property is either
MultiUse or GlobalMultiUse.

Finally, with all of that said, if you're only going to be using the DLL in
1 or maybe even 2 different apps, you're probably better off just including
the classes and other modules from your DLL project into your main program.
Then, there's no DLL to even worry about having to protect against anyone
else using simply because it exists on their system.

--
Mike

microsoft.public.vb.general.discussion

Protecting a COM DLL

Leo

Mayayana

Leo

Mayayana

(nobody)

Kevin Provance

GS

MikeD

x Login to ForumsZone