Restrict access to Class library

[kejpa]

So I thought that I'd better make a class library of some of the frequently used classes instead of including them into each and every project.

But I don't like the idea of them to be used by others (though highly unlikely), is there a way of restricting the usage of MY dll's?

 

TIA

/Kejpa

[mskeel]

Do you mean protecting your DLL's so other people can't use them or are you talking about protections for classes so other classes can't use them (private vs public etc.)? For the former, obfuscation and strong naming; the latter, good interfaces and sufficient abstraction. Obfuscation buys you some protection from simple hacking (which you can read about extensively throughout these forums). Strong naming tells the world that this DLL is YOUR DLL. If someone reverse engineers it, gets your code and compiles it themselves or something, then they can't pass it off as being yours becuase they can't strongly name it the same as you did with your private key. Short of encryption (which is a little overkill) this is the probably the best you can do.

 

Really, though, what would be the big deal if someone else used your stuff? If it's so useful to you, surely it would be useful to others as well?

[DiverDan]

Yes, mskeel, some dlls are worth protecting.

 

kejpa, I have my dlls look for the presence of my main program in their startup path. If its not found then they return an error message. However, that only keeps honest people honest.

[mskeel]

Yes' date=' mskeel, some dlls are worth protecting.[/quote']Well, obviously, DiverDan. Otherwise Micrsoft would have been out of business a long time ago!

 

What would a person have to do to use another DLL in its compiled form? At the minimum you would have to get a hold of the API for the library. Ildasm or a reflector would be all required for that. Why not just compile the DLL code into the main application? Why keep it as a library at all?

 

What I was driving at before -- are you just trying to mark territory or do you have concerns about protecting propreitry algorithms or information?

[DiverDan]

From kejpa'a post he's worried about others using his dlls. And I hope you're joking about not using dlls. In only one of my programs, dlls have removed over 400,000 lines of code from the exe. Since a dotnet dll only takes declaring the dll to access it's properties, kejpa's concerns become very real. But not even Microsoft can stop a hack, so the best you can do is just make it difficult to utilize the dll.

[mskeel]

And I hope you're joking about not using dlls. In only one of my programs' date=' dlls have removed over 400,000 lines of code from the exe.[/quote']That's great. And no, I'm not joking. I don't know the extent of the code under discussion and I'm not going to pretend that I do. I do know that if it truly is a concern and it isn't a lot of code, then perhaps it was inappropriate to move the code into a library. I think DLLs are great -- they help to properly design a system, encourage code reuse, and make sharing code easy. Of course that's part of the problem, isn't it. It's all about trade-offs. If Protection rates a 10, and size of executable only a 4 (or if we're only talking about a small amount of code) there would be nothing wrong with moving code back into the main executable.

From kejpa'a post he's worried about others using his dlls.

I can read his post. It still doesn't answer why. If I knew why it was so important it would make it easier to recomend a course of action. Perhaps DLL's aren't appropriate. Perhaps the code in question is already publicly available elsewhere so it doesn't really matter if it is protected or not. Perhaps the DLL is essential to the preservation of national security and warrents heavy encryption.

 

While fragile code, such as that suggested by DiverDan, certainly would make unauthorized use of a library significantly more difficult, care must be taken while testing and deploying to ensure that simple mistakes don't break the entire system. How anoying would it be if you created an update for the main version but didn't update the DLL to check for the new version (or hash or whatever) and the whole application broke becuase you forgot to distribute an updated DLL. And doesn't that defeat the purpose of a shared library? I guess it woudn't really be shared at that point. I suppose there are other methods for creating fragile code. Again, back to trade-offs. What is more important to you?

 

I've seen converters for Java that will take a Java program and compile it to native Win32 code, libraries (jar files, right?) and all. Is there something like that for .Net? Then you wouldn't have to worry about the IL which is really what makes all of this so easy.

 

And what was wrong with obfuscating the application, again? Would that not actually prevent a person from viewing the library in a usable format? Combine that with the introcution of some fragile elements and you might have a winning combination..

[IngisKahn]

I'd suggest using internal constructors and do caller validation in a factory class.

 

IL is just register-less, processor agnostic assembly code. It has nothing to do with making it easy to use the code elsewhere. It's the .NET metadata contained in the assemblies that does that.

 

When you obfuscate an assembly, it only obfuscates internal names, not any publicly available names. Otherwise it would break any DLL you obfuscate.

[Nerseus]

I think what you want is a license file; do a google search for "License Compiler", with the quotes. I've not done that myself, but I would guess that would work for you. That would keep others from using your DLL. If you want to protect the algorithms (the actual code inside), you're probably best off using an obfuscator. That will only make it harder for people to see your code - you can never truly hide it all.

 

-nerseus

[kejpa]

I think what you want is a license file; do a google search for "License Compiler"' date=' with the quotes. I've not done that myself, but I would guess that would work for you. That would keep others from [b']using[/b] your DLL. If you want to protect the algorithms (the actual code inside), you're probably best off using an obfuscator. That will only make it harder for people to see your code - you can never truly hide it all.

 

-nerseus

Thanx Ner,

I probably would have to use some licensing. Will look into that as a part of today's mission :)

 

mskeel: I'm fully aware of that any .NET program is easily reverse engineered and that you need to obfuscate if it's rocket science or big secrets you're dealing with. But that won't stop anyone from using my DLL.

 

The reason for making a library is code reuse. I don't want to copy and paste the same code files over and over again. I make a utility dll for the projects I'm doing and have the most common gadgets available and tested (and not modifyable! :p ) at once.

 

Thanx again.

/Kejpa

[mskeel]

When you obfuscate an assembly' date=' it only obfuscates internal names, not any publicly available names. Otherwise it would break any DLL you obfuscate.[/quote']I'm pretty sure I've seen an obfuscator that would obfuscate an entire system -- the exe's and dll's -- in such a way that it did not break the system but made it extremely difficult to use. The result was public library method DoProprietaryAlgorithm() is turned into A() throughout the entire system. So the public interfaces are maintained, but all context clues as to what something might be are useless.

 

You could still technically use the DLL, but it is debatable as to whether such use would be woth while. It would invovle significant work to reverse engineer and map the obfuscated method names to what you think they do (by either reading IL or writing a reverse engineering program). So you could call A() or B() or C() until you're blue in the face but without knowing that the decimal you pass in to D(decimal A) is expected by be in inches and will be converted into meters you're pretty much in the dark. Though the attacker will technically be using the dll (lnking to it, calling it), he won't actually be doing anything useful with it (he has no idea what it does). You will have, essentially, prevented a hacker from using your library. It's not 100% but nothing really is.

 

It looks like a better solution is available, so it doesn't really matter. I've never used the License Compiler before. It looks pretty cool, I'll have to do some experiments with it and see how it works. Thanks for pointing that out and setting me straight. Looks like perhaps you could ditch some of your homegrown protection code and give it a shot too, eh, DiverDan?

 

A quick question on this subject: Can you still decompile the code if it has gone through the License Compiler? Wouldn't you just have to decompile it, then recompile it without the liscense to use it then?

[Nerseus]

@mskeel:

I haven't used the Licence Compiler. My guess is that it just prevents usage unless you have a valid license. Most 3rd party controls work this way. It means you have to buy a license (if one is for sale) to use the DLL. It doesn't prevent anyone from decompiling (nothing does) or looking at the code through Reflector - at least, I don't think the License Compiler does any obfuscation. If you truly wanted to hide the internals you would need to obfuscate.

 

Can you simply decompile and recompile the code in a .NET DLL that used a license to get around the license? I have no idea - you could test it out and let us know :)

 

-nerseus

[Diesel]

License Provider's only work for classes inherited from Control.

 

Yes, you can reflect a license class the same as any other.

 

Microsoft's standard implementation merely checks a text file to see if a key is in the file, if not you can decide whether the control will be allowed to be used at run/design time

 

Most people that use the license provider create their own implementation

 

It doesn't sound like your library is a control, so the license provider wouldn't do any good.

 

I would follow IngisKahn's suggestions.

 

And anyway, how would anyone get access to your library? If your posting it online and not selling it, might as well give the source code.

[DiverDan]

For myself I'm going to try an obfuscator fairly soon. Both the NFPA National Electrical Code and one of my customers have both openly stated that they want to "copy" Volts, one of my programs, because of its ease of use, tables, and formulae....what sweet hearts the are! The tables alone took months of input and I'm not going to give them away for free to anyone.

 

btw I just found out today that Volts won another Product of the Year award from another electrical publication!

[Diesel]

Those *******s.

[mskeel]

btw I just found out today that Volts won another Product of the Year award from another electrical publication!

Congrats, man! I tried out a demo of one of your programs a little while back and it was pretty sweet. I think it was a pi calculator..

 

http://www.remotesoft.com/salamander/

And I succesfully decompiled the .Net Framework System.Data library, though I am unsure if that was protected in any way. The Microsoft Team is amazing. Just skimming through it, It looks like they put insane amounts of work into making .Net such a great language. If you ever were interested in "how's this implimented" you can just decompile it. Really, though you won't gain much from it.

Edited September 10, 2005 by mskeel

[Diesel]

Shared Source CLI

[DiverDan]

Here's what I found on Shared Source CLI:

The Shared Source Common Language Infrastructure (previously codenamed Rotor) is Microsoft's shared source implementation of the CLI, the core of .NET. Shared source is not real open source (e.g. it's not suitable for commercial use) but it makes it possible for programmers to examine the implementation details of many .NET libraries, as well as for hackers to create and use modified CLI versions. Microsoft provides the Shared Source CLI as a reference CLI implementation and expects it to be of real value to students learning cross-platform compiler technologies, class system design guidelines, and so on, being the real-world illustration to their lectures.

 

How can be of any help here as we are talking about protecting commerical applications?

[Diesel]

And I succesfully decompiled the .Net Framework System.Data library, though I am unsure if that was protected in any way. [/Quote]

 

I was giving keel an alternate location to view example source of the .net framework.

 

All you can do with .net is obfucsate or create native pe's.