We will publish (as open source) by he end of the week our ThonaConsulting.Licensing.LicenseManager class, which should be a little harder to hack :-)
Why? Well, we basically use signed XML configuration files - you can not just replace a je/jne with a jmp, when the reach into the class picks up a config value. Now, this is not advertisement - this is going to be real open source, for free use. The problem, though, still stands - we are, like everyone else, relying on making it HARD for people to modify assemblies. So, HOW DIFFICULT is it to change the CLR to load assemblies that have been modified? I assume it is not trivial - maybe it is simply technical, but IMHO you get a lot of points where you have the signature as an important part (like linking into the GAC), and so it might be a LOT of things to modify. Let me second this question - anyone has any metrics? Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Trey Nash [mailto:tnash@;DIGITRIX.COM] Sent: Dienstag, 22. Oktober 2002 02:53 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.
