I wouldn't really refer to this scenario as "hacking" per se. More like violating the terms of the licensing/stealing/etc.
In fact, what you are sketching is quite trivial. The CLR isn't going to help at all. You could, for instance, strongly-name your assemblies and load them locally (i.e., not in the GAC). This would buy you run-time verification checking (as opposed to the GAC, which only does install-time). Unfortunately, since we can assume that the "cracker" owns his own machine, he could just turn off verification (as discussed previously), reverse-engineer your code (see Anakrino), remove any licensing checks, and then re-compile the assemblies. Since verification is turned off, all bets are as well. Re-distributing the "cracked" assembly would be relatively easy as well -- you could even provide a Installer (like Chris Sells' does with Wahoo) that would turn off verification. This would assume that the end-users are local admins with the ability to turn off verification. For this scenario, you'd have to wait for something like Palladium... John John St. Clair Prosjekt- og teamleder Reaktor AS > -----Original Message----- > From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED- > [EMAIL PROTECTED]] On Behalf Of Trey Nash > Sent: Tuesday, October 22, 2002 2:53 AM > To: [EMAIL PROTECTED] > Subject: Re: [ADVANCED-DOTNET] tamper proof assembly question > > Hi all, > > OK, let me explain a little further. :-) I'm not looking at a scenario > where I'm trying to avoid people hacking into a machine remotely. > > Many apps out there require serial numbers. The compiled code of the app, > whether it be IL or i386 assembly, typically will boil down to a junction > point in the code where you can simply replace a 'je/jne' with 'jmp' (in > the i386 assembly case.) See what I mean? Hacker finds that weak point, > hex edits the exe, and it's hacked. > > Now then, suppose we want to rely on the CLR to prevent this. The CLR > then becomes the target. The hacker then would have to hack the CLR to > allow it to load assemblies without varifying their integrity. My > question is, does anyone have a metric as to how difficult this will be > for a determined hacker? > > Thanks, > > -Trey > > > One of the worst case scenarios would be for someone to ship a hacked > > mscorlib then somehow run sn.exe on the deployment machine to turn off > > verification checking on mscorlib. There are 3 problems the bad guy has > > to overcome: > > > > 1. getting the fake mscorlib onto the machine > > 2. getting sn.exe onto the machine (it only ships with the sdk and not > > the redist) > > 3. running the application (sn.exe) under an admin account > > > > So at least make 2 harder by only putting the redist on to deployment > > machines. > > > > Richard Blewett > > DevelopMentor > > You can read messages from the Advanced DOTNET archive, unsubscribe from > Advanced DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
