Re: [ADVANCED-DOTNET] tamper proof assembly question
Why bother turning off verification when you can just reverse engineer it (e.g. ILDASM), change the strong name to use a key pair of your own and recompile, with whatever modifications you want in place? If your goal is to stop someone modifying your software and then running the modified version, the only way to achieve this is not to give them your software in the first place. This attack works fine even if there are no bugs in the CLR and you don't have administrative rights on the machine in question. -- Ian Griffiths DevelopMentor - Original Message - From: John St. Clair [EMAIL PROTECTED] 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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] tamper proof assembly question
Craig Andera wrote: There is an additional weakness in this scheme. Because most compilers don't actually record the public key in the client, but rather a 64-bit hash of the public key (the public key token). Which is hard to attack with brute-force, but (I believe) not impossible. I expect someone has already launched just such an attack against the MSFT and ECMA public keys, so they can find other public keys that hash to the same token. It may take a few years, but if it's less than five, that's still a problem. Actually if they find other public keys that hash to the same problem that's not really a big problem - they still don't have a private key that will match... So the brute force attack would, strictly speaking, be to generate public/private key pairs until you came up with one where the public key hashed to the correct value. I think the problem comes down to calculating the SHA-160 hash of 2^63 (on average) public keys. Someone else might know how much CPU that would take. Presumably it's not prohibitively expensive, since MSFT makes the CLR do it once every time it loads a signed assembly. But you also have to generate that many key *pairs*. And MSFT don't generate a key pair every time you load an assembly. Isn't generating key pairs significantly more expensive than generating 160 bit numbers? -- Ian Griffiths 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.
Re: [ADVANCED-DOTNET] tamper proof assembly question
I think the problem comes down to calculating the SHA-160 hash of 2^63 (on average) public keys. Someone else might know how much CPU that would take. Presumably it's not prohibitively expensive, since MSFT makes the CLR do it once every time it loads a signed assembly. But you also have to generate that many key *pairs*. And MSFT don't generate a key pair every time you load an assembly. Isn't generating key pairs significantly more expensive than generating 160 bit numbers? Yeah, Keith Brown and I were exploring down that road. And the question we came up with was, Do they really have to be a valid key pair, or could I choose some other pair of numbers that has the right set of properties but doesn't provide the same strength of encryption that a proper key pair does? In other words, Can I cheat when generating fake pairs? And the unfortunate thing was that neither Keith nor I have the math (maths for you, Ian ;) to know what the real story is. Maybe someone else does? So it might be the case that it's a factor X more expensive than just calculating 2^63 hashes, but it might not. I don't know for sure. And without argument, it would have been more secure for them to record the whole public key, rather than the public key token. I don't buy the argument that they were saving space - 1024 bits versus 64 is not a huge amount of data. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
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.
Re: [ADVANCED-DOTNET] tamper proof assembly question
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.
Re: [ADVANCED-DOTNET] tamper proof assembly question
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.
Re: [ADVANCED-DOTNET] tamper proof assembly question
I would modify that statement: It does not look like relying on the CLR to ensure assemblies have not been tampered is a viable solution. This is only true *in the absence of a secured underlying platform*. IOW, don't bother relying on the CLR if you don't secure the OS. However, If you do secure the OS, then the CLR actually does make it harder to modify signed assembly. So, it comes down to: how hard do you want to make it? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] tamper proof assembly question
Yes, absolutely. Sorry I did not make that distinction before. Thanks, -Trey I would modify that statement: It does not look like relying on the CLR to ensure assemblies have not been tampered is a viable solution. This is only true *in the absence of a secured underlying platform*. IOW, don't bother relying on the CLR if you don't secure the OS. However, If you do secure the OS, then the CLR actually does make it harder to modify signed assembly. So, it comes down to: how hard do you want to make it? You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
[ADVANCED-DOTNET] tamper proof assembly question
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.
Re: [ADVANCED-DOTNET] tamper proof assembly question
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 -Original Message- From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED-DOTNET;DISCUSS.DEVELOP.COM]On Behalf Of Craig Andera Sent: 21 October 2002 22:22 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] tamper proof assembly question 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. If you mean bugs specifically, then I'm not aware of any. There probably are some right now, but I'm not sure why you say there has to be a weak point. There are, however, several issues with the current system. I will elaborate anon. 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? Err, if they can modify things like mscorlib, you're screwed, dude. The whole thing rests on the assumption that the underlying platform is secure. Meaning, you use NTFS with strong passwords, etc. In the absence of file system security, of course, they can just modify your client.exe directly. In other words, we rely upon the CLR being hackproof when we rely upon a strongly named digitally signed assembly being tamper proof. Yes. 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. OK. Here's where I explain what I meant before. First of all, you have to understand what the signature checking really gets you. Two things, really: 1) It tells you that the public key hasn't changed since you built your client. 2) It tells you that the private key used to sign this assembly corresponded to the public key that's embedded in it. Note what this does *not* tell you. A) That the public key belonged to someone you should trust. B) That the public key wasn't changed before you built your client. C) That the person who owns the private key didn't post it on a web page somewhere. D) That the assembly has not been altered since you built your client - it just tells you that if it was altered, whoever had the right private key was the one who did the altering. There is an additional weakness in this scheme. Because most compilers don't actually record the public key in the client, but rather a 64-bit hash of the public key (the public key token). Which is hard to attack with brute-force, but (I believe) not impossible. I expect someone has already launched just such an attack against the MSFT and ECMA public keys, so they can find other public keys that hash to the same token. It may take a few years, but if it's less than five, that's still a problem. I think the problem comes down to calculating the SHA-160 hash of 2^63 (on average) public keys. Someone else might know how much CPU that would take. Presumably it's not prohibitively expensive, since MSFT makes the CLR do it once every time it loads a signed assembly. Of course, this all comes down to this: who are you trying to protect your app against? Your coworkers? Teenagers? Determined hackers? Governments? If the latter, I suggest you unplug the machine from the network and put it in a locked room. In short: It Depends. ;) You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/2002 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/2002 You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
Re: [ADVANCED-DOTNET] tamper proof assembly question
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 #2 isn't really a problem - it's not like SN -Vr does much beyond setting a registry key. So all hacker X has to do is get that reg key set. Now to do this he still needs admin access... Jason You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
