|
They would have to resubmit the license request file (basically, the unsigned XML file) and have it resigned and reissued. This is, however, similar to current public key cryptography. If you change your key, you must redistribute it and your old public key won't work anymore with the new private key. The computer's SID 1) isn't supposed to change unless you change domains, and 2) uniquely identifies the computer, just like your private key identifies you.
Speaking of domains, if you change the domain name in ActiveDirectory, the server certificates and everything the CA has signed is invalid. In public key cryptography, uniqueness is required somewhere so that you can verify signatures (basically, the encrypted hash).
I guess one could say that no content / application protection scheme is 100% effective and versatile. This one just uses standard cryptography practices that have been proven time and time again. It still isn't the best because of problems like you pointed out, but it'll work in most cases - a large most.
Besides, think of it like Microsoft activation thingy. If you change something major, you have to reactivate and probably will end up calling Microsoft. Your customers could have the same option where they explain the situation, so you can verify their credentials (perhaps a business ID or passphrase) and resign the file however you see fit.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
What about using the MAC address of the computer instead of the SID?
-Nick Parker
|
|
|
|
|
That's a possibility, but if memory serves me correctly, that can be changed, too. Besides, isn't this on the NIC and not the computer as a whole? Swapping out the NIC - which happens much, much more often than changing the computer's SID - would render the license invalid.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Heath Stewart wrote:
Besides, isn't this on the NIC and not the computer as a whole? Swapping out the NIC - which happens much, much more often than changing the computer's SID - would render the license invalid.
Good point, good conversation though.
-Nick Parker
|
|
|
|
|
Is it worth posting an article to cover this topic (which you seem to know a lot about)? Myself and seemingly many other CPians would be interested to read the full story.
Derek Lakin.
Try the Code Store for instant integrated access to an online repository of .NET components.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Yeah, I could probably do that. It shouldn't take too much time and I've already got the code ready. In case I don't remember to post when I finish here, just keep an eye out for it. Probably'll be about a week since I'm pretty swamped at work.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
Great! I'll keep an eye out for it
Derek Lakin.
Try the Code Store for instant integrated access to an online repository of .NET components.
I wish I was what I thought I was when I wished I was what I am.
Salamander Software Ltd.
|
|
|
|
|
Hi, I was wondering if you ever got to write the article about this? I am very interested and it sounds exactly like what i want. Even some sample code would be great
--Adam Turner
|
|
|
|
|
No, not yet unfortunately. I just finished moving (though not unpacking) and have a deadline at work coming up soon. I do plan on writing bits of the article within the next couple of weeks, though, so stay tuned.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
I finally found some time to write the article: http://www.codeproject.com/dotnet/xmldsiglic.asp[^]
I hope this helps.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----
|
|
|
|
|
|
Am I reading this right? A virtual machine just to manage application rights? How does it affect the program? I mean, it seems like it'd be effective, but not necessarily efficient.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
The virtual machine thing is mostly fluff.
What they basically do is embed a piece of code within your .exe. I believe someone posted a related article on Cp about doing such things.
Then, anytime you start the .exe it checks a license key somehow and, depending on the result, starts an internet-driven activation process. This process is meant to let/force users buy the software.
|
|
|
|
|
There is a possible upcoming project at my place of employment that would require the .NET Framework to be installed onto client machines. Is there a way to push the framework to client machines from a Windows 2003 Server through an ASP.NET application?
Thanks In Advance.
Tony
|
|
|
|
|
Negative. What you could do is include a command in the user's startup script to run dotnetfx.exe from a server with the /silent switch (or something like that) and let them know to leave their desks for a few minutes.
Hawaian shirts and shorts work too in Summer.
People assume you're either a complete nut (in which case not a worthy target) or so damn good you don't need to worry about camouflage...
-Anna-Jayne Metcalfe on Paintballing
|
|
|
|
|
Thanks!
I will look into this through SMS also.
Tony
|
|
|
|
|
Actually, the .NET framework uses a Windows Installer file (MSI) with a separate CAB. If you use ActiveDirectory or have SMS server (which I saw that you do), you can certainly push it out to machines. Just don't use AD's Computer installation method because it only advertises information in the MSI and .NET's MSI has nothing to advertise!
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
As far as I know PInvoke just invokes a method in new unmanaged instance. Is it possible to pass the result from hosted object to the specific host instance that created hosted object without security problem?
|
|
|
|
|
I maybe missing something here, but to my knowledge: there is no such thing as "new unmanaged instance" -- there is just "unmanaged instance". Assuming that you are hosting CLR -- this is an instance. If this is true: then why can't you declare your unmanaged callback functions as exported. And now mark there prototypes in your managed portion as DllImported and call them.
Why this shouldn't work?
Now about "security problem"? As I understand, you are hosting managed code in unmanaged -- therefore, by defenition your application is not secured right from the beginning -- why would you want to enforce security in the middle of execution? Or maybe I'm missing something?...
|
|
|
|
|
Sorry for confusion, to simplify, please think about
applications such as asp.net. IIS probably hosting
those scripts, execute them in its hosted appdomain,
then get their output back to IIS.
I'd like to know how it works.
|
|
|
|
|
He's calling managed code from an unmanaged DLL. How would P/Invoking anything help? At the very least, the managed method he's calling would have to bind to a specific DLL which isn't very modular and is very restrictive.
To the original poster, have you tried creating an instance of a Delegate (it uses an AutoDual interface, which Microsoft always tells you not to use, BTW ) Once you have an instance to that, you should be able to get what you need from there.
Just a thought.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
I'm seriously confused here.
From what I understand you have the following scenario:
1. Unmanage instance, lets name it (U) is hosting AppDomain and loads managed assembly, lets name it (M);
2. Now (U) calls some fuction or creates a clas or etc. inside of (M);
Original question was: how now (M) can call back fuction(s) inside of (U)?
My answer was:
what stopes you from declaring some entry points in (U) as Exported, through dllexport or .DEF file, and then declaring them in (M) using DllImport Attribute. If above is done, then you can call those entries from (M) directly into (U).
Maybe I didn't understand perfectly the scenario, but from what I understand: "He's NOT calling managed code from an unmanaged DLL", but opposite -- he wants to callback from managed into unmanaged host...
Regards,
Igor
|
|
|
|
|
Right, so he's going to P/Invoke a method from a specific DLL and use that in a managed method to emulate a callback. So, that DLL is the only DLL that can be used for a callback and no DLLs can be used instead. If that managed method isn't careful in its implementation, calling the P/Invoked method when the DLL isn't there could lead to problems like exceptions being thrown. It's restrictive, as I said, and is not modular at all.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|
|
So, it "could be restrictive, not modualr and etc"... And I'm not arguing with that.
But, the main thing is: "He wants to CALLBACK from MANAGED to UNMANAGED" and therefore P/Invoke could help, which you originally dismissed!
Now, about "restrictive, not modular and etc": Sure if you implement managed callback through DllImport, you basically HARD CODED necessaty of having UNMANAGED Implementation loaded --> and that is why it's not flexible enough. However, that's exactly how P/Invoke works -- You are not questioning necessaty of user32.dll, gdi32.dll and etc. to support CLR OS calls...
Said that: there are ways of performing interpretive P/Invoke, but I thought it's out of the scope of original question.
Regards,
Igor
|
|
|
|
|
No, I get it - completely. P/Invoke could do it, yes, but it is RESTRICTIVE! He has to P/Invoke the unmanaged method in his managed code. Right there, that ties it to a specific DLL and that is the restrictive part. Then, in the managed code, he has to call that P/Invoke'd method. If he assumes that the method was found (i.e., the DLL exporting it is present) and, in fact, it wasn't found, the consequences could be bad if not handled right.
Trust me - I know how P/Invoke works. I get into the meat of .NET and have read all the documentation countless times. All I'm saying is that P/Invoke ties the code to one DLL.
Besides, you're also assuming that he has access to the source of the assembly. What if he's doing something in the .NET assemblies, part of the .NET framework. He can't add an external method and he can't make the message body call the P/Invoke'd method. A wrapper might be possible, but painful. My idea about instantiating a Delegate from unmanaged code (since it implements IDispatch, calling its methods are easy) and passing that to the callback parameter of whatever he's calling. He would still be to have a small assembly (or emit one) that receives the callback. Using your idea in that might work, but hard-coding it into the "target" assembly (if he can even change the assembly) isn't necessarily a good idea. If he can insure that these two assemblies will always be present together and that he doesn't want to ever replace the unmanaged DLL, sure it might work. Frankly, I just don't swing that way because I like to make my code versatile, instead of paying for it later.
Reminiscent of my younger years...
10 LOAD "SCISSORS"
20 RUN
|
|
|
|