DotNetYOGI

Bindows� Home

2006-01-29T14:10:00.000Z

Want to get started with AJAX based programming? Here is something to give you a headstart:
Bindows� Home

What is The Regulator?

2005-10-11T13:27:00.000Z

The Regulator is an advanced, free regular expressions testing and learning tool...

What is under the hood of .Net String.GetHashCode()?

2005-02-16T15:44:00.000Z

Ever wonder what is the hashing algorithm used inside the .Net String class's GetHashCode() override? Well, here is the fruit of a couple of hours of my labour.
C++ (Unmanaged):
ULONG HashString(LPCWSTR szStr)
{
ULONG hash = 5381;
int c;

while ((c = *szStr) != 0)
{
hash = ((hash << 5) + hash) ^ c;
++szStr;
}
return hash;
}

C++ Managed:

int Class1::HashString(String *szStr)
{
int hash = 5381;
int c;
int len = szStr->Length;
for (int i = 0; i < len; i++)
{
char f = szStr->get_Chars(i);
int c = f;
if (c < 0) c += 256; // Some characters like '£', '¬' are returned with a negative values!
hash = ((hash << 5) + hash) ^ c;
}
return hash;
}

C#:
int HashString(string szStr)
{
int hash = 5381;
int c;
int i = 0;

while(i < szStr.Length)
{
c = (int)szStr[i];

hash = ((hash << 5) + hash) ^ c;
i++;
}
return hash;
}

Enjoy!

Ivan: What is common between Strong Names, Obfuscation and DRM?

2005-01-18T10:22:00.000Z

Another word of wisdom:
Ivan: What is common between Strong Names, Obfuscation and DRM?

Strong Names Explained

2004-11-26T22:19:00.000Z

A neat article explaining the Strong Names using easy to understand examples and pictures:
The Code Project - Strong Names Explained - .NET:

No, Strong Names are NOT for code security :-(

2004-11-24T20:53:00.000Z

Well, finally it seems to have dawned upon me that the .Net strong names are not really meant to secure your code. The last nail in the coffin was the revelation that one can easily tamper an assembly header to disable the strong name verification - without even removing the strong name! This effectively defeats the case of using strong names for cross referencing of assemblies based on strong names.

Read this thread:
Signed assemblies easily cracked?

Спасибо Valery and Danke Frank!

Straight from the horse's mouth

2004-11-21T10:16:00.000Z

If you have been made to think that the strong names are for code security - think again. They are best suited for versioning only.
Some more food for thought from Valery on strong names:
Valery's blog - Strong names are not security related thingies
Valery's blog - Strong names are not security related thingies (Story Continues)

Strong Names, what are they good for?

2004-11-16T10:54:00.000Z

Recently Valery responded to one of my comments on the Microsoft's security newsgroup. It gave me a whole new perspective to think about on the concept of Strong Names and how useful they are:

Strong names are not security related! Stop relying on them for security
reasons and view them only for the purposes they were invented at the first
place - versioning. period.
There are plenty ways of stealing private key. Watching spreading rate of
malware and spyware suggests that stealing private key from personal
computer is trivial task at least on 90% of installed Windows base (refer to
the recent publications with claims* that at least 90% of Windows users have
spyware running on their computers). That will fall even to the script
kiddies.
If we go further - very few could actually handle their private keys good
(if you ask me - I can't handle my private keys). For handling private keys
well (like for example Verisign or Microsoft handles their pks) you would
need tempest protected hardware setup in highly electromagnetically isolated
location guarded with strong locks and live guards. Electromagnetic
radiation, processor heat, power consumption, operation timing and even
sound produced by processor - all that was shown to be able leaking private
keys to adversaries.
No system may be considered secure as long as it doesn't mitigate known
security threats. And strong names used for security reasons do nothing with
regards to key management and key revocation protocols. Leaving key
management and key revocation protocols for in-house implementation would
inevitably lead to security weaknesses.

[*] Even so I refer to 90%, but I believe that claim is quite questionable,
but even halving it to 45% still presents quite threatening picture.

P.S. I have several "strong names " related posts in my blog - if you
interesting you can simply search my blog for strong names.

An Illustrated Guide to Cryptographic Hashes

2004-11-09T13:49:00.000Z

Brilliant article if you want a get a low down on what hashes are!
An Illustrated Guide to Cryptographic Hashes

Compromising a strong name signed assembly

2004-11-07T08:04:00.000Z

I saw this article on the CodeProject, which draws attention to the fact that simply signing an assembly by strong name doesn't guarantee that a hacker cannot turn it into a trojan horse :-( The author shows how easy it is to use the ildasm and ilasm tools to simply remove the publickey and hash algorithm segments from the assembly header in the IL code and recompile the IL code making the assembly unsigned!
Going one step further than that, the hacker could even sign the tampered assembly by his own private key - so potentially fooling the CLR, if the CLR grants trust to an assembly simply if it is signed.
I now more strongly feel that the onus is now on the system administator of the machine(s) to cleverly set trust and evidence based code access security policies for the CLR so that the compromised assemblies fail to execute. This can probably only be achieved if the policy is based on the publisher's identity - be it his public key or his digital certificate.

What is .Net Assembly Signing?

2004-10-30T18:05:00.000Z

I made a presentation to my peers on the .Net's novel approach towards the evidence based code access security technology. Here is a link to that presentation.

Welcome!

2004-10-28T12:22:00.000Z

This is just the regular boring welcome bit. Thank you and please return when passing by...