> 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?
If the hacker has admin access to your box, you are done. If they don't, you can secure the files on that box via NTFS security. The way I see it, solving the problem has nothing to do with the CLR. It has everything to do with configuring the underlying platform. In terms of how hard it is to reverse engineer stuff to look for weak points: it's not too hard. It takes a while, but anyone can learn x86, and that's the only real skill required. I once hacked a legal copy of AutoCAD I had just to see if I could do it. Took me about four hours, and they use a supposedly secure setup where you need to plug an actual piece of hardware into the machine before the program will run. I have a friend that used to compare efforts to secure part of a system when the foundation was insecure to building a giant castle wall with a moat in front of it, but leaving a nice flower-lined path up to the back door, which is made of Nerf. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
