Re: [ADVANCED-DOTNET] A performace comparison between the TCP and HTTP remoting channels.
I'm curious as to what your use case is for this. Do you need to send 5000 messages between two machines in less than 5 seconds? Why would you even care about the performance of http on a single machine? Are you thinking about using http to talk between app domains on a single machine? -Original Message- From: Nicko Cadell [mailto:discuss-develop-advanced-dotnet;THEBAP.ORG] Sent: Monday, October 21, 2002 9:04 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] A performace comparison between the TCP and HTTP remoting channels. I have got some results from testing with the .NET framework 1.1 beta, both in a native 1.1 environment and a mixed 1.0 and 1.1 environment. Note these are all results from comparing TCP and HTTP remoting channels, not web service, which also use HTTP transport, but are hosted in IIS. Running locally on a .NET framework 1.1 beta TestChannels -client Connecting to localhost Testing TCP Channel Done with RegularMethod batch! 3.688 Done with RegularMethodReturn batch! 3.844 Done with OneWay batch! 2.969 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 13.219 Done with RegularMethodReturn batch! 13.593 Done with OneWay batch! 16.485 DONE Testing HTTP Channel Interestingly here the TCP channel and the HTTP channel are slightly faster than under 1.0. The [OneWay] TCP channel has made great improvements and is now faster than the regular method (as it should be). But the HTTP channel's [OneWay] method is going backwards, now it is not only slower under 1.1 than it was under 1.0, but it is now slower than the regular methods. Running with a client on a .NET framework 1.1 beta and the server running on a .NET framework 1.0 sp2. TestChannels -client=hebe Connecting to hebe Testing TCP Channel Done with RegularMethod batch! 3.093 Done with RegularMethodReturn batch! 3.266 Done with OneWay batch! 11.421 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 10.578 Done with RegularMethodReturn batch! 10.906 Done with OneWay batch! 4.422 DONE Testing HTTP Channel Again the across machine version of the tests runs faster than the local across process tests, however the results are more pronounced. The HTTP channel is nearly 3 seconds faster than locally on the same machine. The TCP [OneWay] call is still slow 2.9 seconds locally = 11.4 seconds across the network, but at least it is not the 86.3 seconds it used to take! The HTTP [OneWay] methods are running twice as fast in this combination as previously in a 1.0 to 1.0 networked config. Running with the client on .NET framework 1.0 sp2 and the server running on .NET framework 1.1 beta. TestChannels.exe -client=cupid Connecting to cupid Testing TCP Channel Done with RegularMethod batch! 3.766 Done with RegularMethodReturn batch! 3.984 Done with OneWay batch! 8.203 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 11.829 Done with RegularMethodReturn batch! 12.421 Done with OneWay batch! 9.688 DONE Testing HTTP Channel With the client running on the old 1.0 framework we loose some of our speed shown above. However the [OneWay] methods are again showing interesting results. The TCP channel methods are faster! But the HTTP methods are slower! It looks like the 1.1 framework will make some positive speedups to the remoting layer, but what is going on with those OneWay methods? 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] A performace comparison between the TCP and HTTP remoting channels.
Hi, i have a small suggestion for your benchmarks in which i'mspecially interested : asynchronous calls (BeginInvoke/EndInvoke). I think it'd be interesting to test the performance between both .net versions (1.0 and 1.1). Can you do the same tests with this type of method call? Regards, Manuel - Original Message - From: Nicko Cadell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 21, 2002 3:04 PM Subject: Re: [ADVANCED-DOTNET] A performace comparison between the TCP and HTTP remoting channels. I have got some results from testing with the .NET framework 1.1 beta, both in a native 1.1 environment and a mixed 1.0 and 1.1 environment. Note these are all results from comparing TCP and HTTP remoting channels, not web service, which also use HTTP transport, but are hosted in IIS. Running locally on a .NET framework 1.1 beta TestChannels -client Connecting to localhost Testing TCP Channel Done with RegularMethod batch! 3.688 Done with RegularMethodReturn batch! 3.844 Done with OneWay batch! 2.969 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 13.219 Done with RegularMethodReturn batch! 13.593 Done with OneWay batch! 16.485 DONE Testing HTTP Channel Interestingly here the TCP channel and the HTTP channel are slightly faster than under 1.0. The [OneWay] TCP channel has made great improvements and is now faster than the regular method (as it should be). But the HTTP channel's [OneWay] method is going backwards, now it is not only slower under 1.1 than it was under 1.0, but it is now slower than the regular methods. Running with a client on a .NET framework 1.1 beta and the server running on a .NET framework 1.0 sp2. TestChannels -client=hebe Connecting to hebe Testing TCP Channel Done with RegularMethod batch! 3.093 Done with RegularMethodReturn batch! 3.266 Done with OneWay batch! 11.421 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 10.578 Done with RegularMethodReturn batch! 10.906 Done with OneWay batch! 4.422 DONE Testing HTTP Channel Again the across machine version of the tests runs faster than the local across process tests, however the results are more pronounced. The HTTP channel is nearly 3 seconds faster than locally on the same machine. The TCP [OneWay] call is still slow 2.9 seconds locally = 11.4 seconds across the network, but at least it is not the 86.3 seconds it used to take! The HTTP [OneWay] methods are running twice as fast in this combination as previously in a 1.0 to 1.0 networked config. Running with the client on .NET framework 1.0 sp2 and the server running on .NET framework 1.1 beta. TestChannels.exe -client=cupid Connecting to cupid Testing TCP Channel Done with RegularMethod batch! 3.766 Done with RegularMethodReturn batch! 3.984 Done with OneWay batch! 8.203 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 11.829 Done with RegularMethodReturn batch! 12.421 Done with OneWay batch! 9.688 DONE Testing HTTP Channel With the client running on the old 1.0 framework we loose some of our speed shown above. However the [OneWay] methods are again showing interesting results. The TCP channel methods are faster! But the HTTP methods are slower! It looks like the 1.1 framework will make some positive speedups to the remoting layer, but what is going on with those OneWay methods? 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] A performace comparison between the TCP and HTTP remoting channels.
Questions: (a) How is the performance difference whenever the code that you are calling actually does something? (b) Most of the shown differences are easily explained considering the protocol characteristics of HTTP vs. reused sockets. What other results do you expect? -cv -Original Message- From: Nicko Cadell [mailto:discuss-develop-advanced-dotnet;THEBAP.ORG] Sent: Montag, 21. Oktober 2002 16:04 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] A performace comparison between the TCP and HTTP remoting channels. I have got some results from testing with the .NET framework 1.1 beta, both in a native 1.1 environment and a mixed 1.0 and 1.1 environment. Note these are all results from comparing TCP and HTTP remoting channels, not web service, which also use HTTP transport, but are hosted in IIS. Running locally on a .NET framework 1.1 beta TestChannels -client Connecting to localhost Testing TCP Channel Done with RegularMethod batch! 3.688 Done with RegularMethodReturn batch! 3.844 Done with OneWay batch! 2.969 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 13.219 Done with RegularMethodReturn batch! 13.593 Done with OneWay batch! 16.485 DONE Testing HTTP Channel Interestingly here the TCP channel and the HTTP channel are slightly faster than under 1.0. The [OneWay] TCP channel has made great improvements and is now faster than the regular method (as it should be). But the HTTP channel's [OneWay] method is going backwards, now it is not only slower under 1.1 than it was under 1.0, but it is now slower than the regular methods. Running with a client on a .NET framework 1.1 beta and the server running on a .NET framework 1.0 sp2. TestChannels -client=hebe Connecting to hebe Testing TCP Channel Done with RegularMethod batch! 3.093 Done with RegularMethodReturn batch! 3.266 Done with OneWay batch! 11.421 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 10.578 Done with RegularMethodReturn batch! 10.906 Done with OneWay batch! 4.422 DONE Testing HTTP Channel Again the across machine version of the tests runs faster than the local across process tests, however the results are more pronounced. The HTTP channel is nearly 3 seconds faster than locally on the same machine. The TCP [OneWay] call is still slow 2.9 seconds locally = 11.4 seconds across the network, but at least it is not the 86.3 seconds it used to take! The HTTP [OneWay] methods are running twice as fast in this combination as previously in a 1.0 to 1.0 networked config. Running with the client on .NET framework 1.0 sp2 and the server running on .NET framework 1.1 beta. TestChannels.exe -client=cupid Connecting to cupid Testing TCP Channel Done with RegularMethod batch! 3.766 Done with RegularMethodReturn batch! 3.984 Done with OneWay batch! 8.203 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 11.829 Done with RegularMethodReturn batch! 12.421 Done with OneWay batch! 9.688 DONE Testing HTTP Channel With the client running on the old 1.0 framework we loose some of our speed shown above. However the [OneWay] methods are again showing interesting results. The TCP channel methods are faster! But the HTTP methods are slower! It looks like the 1.1 framework will make some positive speedups to the remoting layer, but what is going on with those OneWay methods? 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.
[ADVANCED-DOTNET] Exceptions and the WinForms Paint event
[I had no joy with this on the Windows Forms list last week, so would like
to put it to the advanced list. Apologies to those who have already seen
it.]
If I have an unhandled exception in a normal event handler, such as a
button click, the debugger drops me in at the exception site. E.g.
private void button1_Click(...) {
int naughty = 2;
int bang = 10/(naughty-2); // debugger highlights this line
}
But if I have an unhandled exception in the Paint event, the debugger drops
me on the Application.Run statement. E.g.
static void Main() {
Application.Run(new Form1());
} // debugger highlights this line
private void panel1_Paint(...) {
int naughty = 2;
int bang = 10/(naughty-2); // but I want to be here!
}
The call stack is all Windows Forms methods (apart from my Main): there's no
sign of my Paint handler in the call stack.
Do other people see this behaviour?
Can anyone explain why it happens? (The call stack bottoms out in a method
called PaintWithErrorHandling: I guess this is throwing a new exception
instead of just rethrowing mine. But why would it do that?)
And on a more practical note, are there any good ways to persuade the
debugger to catch Paint-related exceptions at their site?
--
Ivan Towlson
White Carbon
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] A performace comparison between the TCP and HTTP remoting channels.
Well 5000 is just an arbitrary number to average the timing across. 10 is too small and throws up unpredictable effects, 100 takes too long to run. In this case 5000 gives nice repeatable results. As the TCP and HTTP channels both run over sockets they could be implemented similarly, just with different control syntax and error handleling, however the different in performance indicates that they are not similarly. Also a test like this shows up interesting stats, especially to do with the [OneWay] calls. One implementation detail is that the client does not guarantee that the server will receive a [OneWay] call. In fact if there is no server running at all the [OneWay] calls will be lost, however because the client waits for an ACK or a timeout it is very very slow to make [OneWay] calls without a server running to receive them. Surely if the client does not guarantee to deliver the [OneWay] call (or preserve the ordering of calls) then it could delegate the sending to a worker thread and return immediately even before it has tried to send the call? - Original Message - I'm curious as to what your use case is for this. Do you need to send 5000 messages between two machines in less than 5 seconds? Why would you even care about the performance of http on a single machine? Are you thinking about using http to talk between app domains on a single machine? - Original Message - From: Nicko Cadell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 21, 2002 3:04 PM Subject: Re: A performace comparison between the TCP and HTTP remoting channels. I have got some results from testing with the .NET framework 1.1 beta, both in a native 1.1 environment and a mixed 1.0 and 1.1 environment. Note these are all results from comparing TCP and HTTP remoting channels, not web service, which also use HTTP transport, but are hosted in IIS. Running locally on a .NET framework 1.1 beta TestChannels -client Connecting to localhost Testing TCP Channel Done with RegularMethod batch! 3.688 Done with RegularMethodReturn batch! 3.844 Done with OneWay batch! 2.969 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 13.219 Done with RegularMethodReturn batch! 13.593 Done with OneWay batch! 16.485 DONE Testing HTTP Channel Interestingly here the TCP channel and the HTTP channel are slightly faster than under 1.0. The [OneWay] TCP channel has made great improvements and is now faster than the regular method (as it should be). But the HTTP channel's [OneWay] method is going backwards, now it is not only slower under 1.1 than it was under 1.0, but it is now slower than the regular methods. Running with a client on a .NET framework 1.1 beta and the server running on a .NET framework 1.0 sp2. TestChannels -client=hebe Connecting to hebe Testing TCP Channel Done with RegularMethod batch! 3.093 Done with RegularMethodReturn batch! 3.266 Done with OneWay batch! 11.421 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 10.578 Done with RegularMethodReturn batch! 10.906 Done with OneWay batch! 4.422 DONE Testing HTTP Channel Again the across machine version of the tests runs faster than the local across process tests, however the results are more pronounced. The HTTP channel is nearly 3 seconds faster than locally on the same machine. The TCP [OneWay] call is still slow 2.9 seconds locally = 11.4 seconds across the network, but at least it is not the 86.3 seconds it used to take! The HTTP [OneWay] methods are running twice as fast in this combination as previously in a 1.0 to 1.0 networked config. Running with the client on .NET framework 1.0 sp2 and the server running on .NET framework 1.1 beta. TestChannels.exe -client=cupid Connecting to cupid Testing TCP Channel Done with RegularMethod batch! 3.766 Done with RegularMethodReturn batch! 3.984 Done with OneWay batch! 8.203 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 11.829 Done with RegularMethodReturn batch! 12.421 Done with OneWay batch! 9.688 DONE Testing HTTP Channel With the client running on the old 1.0 framework we loose some of our speed shown above. However the [OneWay] methods are again showing interesting results. The TCP channel methods are faster! But the HTTP methods are slower! It looks like the 1.1 framework will make some positive speedups to the remoting layer, but what is going on with those OneWay methods? 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] A performace comparison between the TCP and HTTP remoting channels.
I have got some results from testing with the .NET framework 1.1 beta, both in a native 1.1 environment and a mixed 1.0 and 1.1 environment. Note these are all results from comparing TCP and HTTP remoting channels, not web service, which also use HTTP transport, but are hosted in IIS. Running locally on a .NET framework 1.1 beta TestChannels -client Connecting to localhost Testing TCP Channel Done with RegularMethod batch! 3.688 Done with RegularMethodReturn batch! 3.844 Done with OneWay batch! 2.969 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 13.219 Done with RegularMethodReturn batch! 13.593 Done with OneWay batch! 16.485 DONE Testing HTTP Channel Interestingly here the TCP channel and the HTTP channel are slightly faster than under 1.0. The [OneWay] TCP channel has made great improvements and is now faster than the regular method (as it should be). But the HTTP channel's [OneWay] method is going backwards, now it is not only slower under 1.1 than it was under 1.0, but it is now slower than the regular methods. Running with a client on a .NET framework 1.1 beta and the server running on a .NET framework 1.0 sp2. TestChannels -client=hebe Connecting to hebe Testing TCP Channel Done with RegularMethod batch! 3.093 Done with RegularMethodReturn batch! 3.266 Done with OneWay batch! 11.421 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 10.578 Done with RegularMethodReturn batch! 10.906 Done with OneWay batch! 4.422 DONE Testing HTTP Channel Again the across machine version of the tests runs faster than the local across process tests, however the results are more pronounced. The HTTP channel is nearly 3 seconds faster than locally on the same machine. The TCP [OneWay] call is still slow 2.9 seconds locally = 11.4 seconds across the network, but at least it is not the 86.3 seconds it used to take! The HTTP [OneWay] methods are running twice as fast in this combination as previously in a 1.0 to 1.0 networked config. Running with the client on .NET framework 1.0 sp2 and the server running on .NET framework 1.1 beta. TestChannels.exe -client=cupid Connecting to cupid Testing TCP Channel Done with RegularMethod batch! 3.766 Done with RegularMethodReturn batch! 3.984 Done with OneWay batch! 8.203 DONE Testing TCP Channel Testing HTTP Channel Done with RegularMethod batch! 11.829 Done with RegularMethodReturn batch! 12.421 Done with OneWay batch! 9.688 DONE Testing HTTP Channel With the client running on the old 1.0 framework we loose some of our speed shown above. However the [OneWay] methods are again showing interesting results. The TCP channel methods are faster! But the HTTP methods are slower! It looks like the 1.1 framework will make some positive speedups to the remoting layer, but what is going on with those OneWay methods? 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] URGENT! IIS only serving partial href-exe files
Here's the situation: when I launch a .NET WinForms .exe over http by directly typing in the url it works every time. When I launch it via a hyperlink sometimes it works but usually it doesn't. I tcpTraced this and what is happening is that when it is launched via the link the .exe only gets partially downloaded. Each subsequent click on the link downloads another 4076 bytes or so. Anyone know why IIS would only be partially serving out the .exe? The only difference between the GET that works and the GET that doesn't is the one that doesn't work has a Referer: line and the case of the filename is slightly different (but I tried matching it in the url-direct method of launching it and it still worked). 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.
[ADVANCED-DOTNET] .NET Framework 1.1 CAS
My questions are on this: In .NET Framework 1.1, applications that receive less than full trust from the runtime code access security system can no longer call shared managed libraries unless the library writer specifically allows them to. Does this mean that applications with less than full trust can't call the .NET Framework libraries? Or is it intended to make sure that shared library writers do all the right security stuff. If they don't do anything, then apps with less than full trust can't call into them. 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] Exceptions and the WinForms Paint event
Ivan, If you are using VS7, you can go to Debug|Exceptions to bring up
the Exceptions dialog, click on the 'Common Language Runtime Exceptions'
Item in the list and down in the control groups at the bottom select
When the Exception is throw: Break in the debugger radio button. Hit OK
then start debugging. You'll now break in the debugger at the place
where the exception is thrown.
I suspect that you are winding up in your own code when the exception is
thrown because that's the first place on the stack that symbols were
loaded for.
Mike
-Original Message-
From: Ivan Towlson [mailto:ivan.towlson;WHITE-CARBON.COM]
Sent: Monday, October 21, 2002 8:16 AM
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Exceptions and the WinForms Paint event
[I had no joy with this on the Windows Forms list last week, so would
like
to put it to the advanced list. Apologies to those who have already
seen
it.]
If I have an unhandled exception in a normal event handler, such as a
button click, the debugger drops me in at the exception site. E.g.
private void button1_Click(...) {
int naughty = 2;
int bang = 10/(naughty-2); // debugger highlights this line
}
But if I have an unhandled exception in the Paint event, the debugger
drops
me on the Application.Run statement. E.g.
static void Main() {
Application.Run(new Form1());
} // debugger highlights this line
private void panel1_Paint(...) {
int naughty = 2;
int bang = 10/(naughty-2); // but I want to be here!
}
The call stack is all Windows Forms methods (apart from my Main):
there's no
sign of my Paint handler in the call stack.
Do other people see this behaviour?
Can anyone explain why it happens? (The call stack bottoms out in a
method
called PaintWithErrorHandling: I guess this is throwing a new exception
instead of just rethrowing mine. But why would it do that?)
And on a more practical note, are there any good ways to persuade the
debugger to catch Paint-related exceptions at their site?
--
Ivan Towlson
White Carbon
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
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.
