Hi all, Is anyone familiar with any weak points that may exist within the CLR with regards to ensuring files are not tampered with? Given a file that is strong named and digitally signed, we're meant to rest assured that the file is completely tamper proof. However, there has to be a weak point somewhere along the line.
Does anyone know if hackers have ever succeeded in hacking the CLR so that it will pass a file that has been tampered with even though the unencrypted hash of the file will not match after the tampering? In other words, we rely upon the CLR being hackproof when we rely upon a strongly named & digitally signed assembly being tamper proof. I have plans for an unmanaged app to host the CLR and load an assembly. I hope to rely upon the CLR to ensure that the assembly that I am loading has not been altered. Thanks, -Trey You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
