Logo



Subscribe:
RSS 2.0 | Atom 1.0
Categories:
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Sign In
[Giagnocavo]Michael::Write()

 Sunday, November 28, 2004
Cracking Code 4: Replacing a strong name

In my last article, someone commented that editing an assembly would create a problem if the assembly is strong named. They are correct. If an assembly has a strong name and is tampered with, you'll get a System.IO.FileLoadException: Strong name validation failed for assembly <foo>.

Strong names are to identify an assembly. They are "strong" because the identification is provided with cryptographic means, rather than just the name of the file. The system is designed to ensure the assembly is what it claims to be, and public key cryptography proves it. Against malicious people, it can ensure someone can't drop an assembly signed with one of your trusted publisher's keys and get you to trust their assembly more than you should. It's NOT meant to be a way to stop people from editing and running assemblies on their own machine.

I was hoping there was a simple way to replace the strong name on an assembly, but I don't believe there is. Then again, there's a LOT of stuff that ships with .NET, so perhaps I just overlooked it. If so, let me know. At any rate, I wrote a tiny program to replace the strong name on an assembly. Let me explain it.

Somewhere in the assembly, a public key is provided (otherwise the runtime wouldn't know what to verify against!). Then, there is a hash of the assembly, and the hash is signed with the private key. When the assembly is modified, the hash will change, the signature will no longer match and the runtime will refuse to load the assembly. A cracker usually won't have access to the private key, and thus can't resign. However, one can simply replace the public key in the assembly with our own public key, and resign using our own private key. Problem solved.

A quick word to those who are thinking "Can't I just use SN -Vu to skip verification checking?". No, this doesn't work. Verification skipping only applies to partially (delay signed) assemblies, not to fully signed assemblies. If you somehow manage to get verification skipping working on fully signed assemblies, I'd love to know.

My program is a very simple tool with nothing amazing in it (except for a very slow search algorithm). All it does is take an assembly and a keyfile, replace the public key, and call SN -R <assembly> <keyfile> to resign. Here's how you'd use it:

1. Take Some.exe, a strongly named assembly. Modify it.
2. Note that attempting to load Some.exe will fail.
3. Create a new keyfile by running "SN -k mykey.snk". (SN is the StrongName utility that ships with the .NET Framework SDK).
4. Ensure you have the .NET Framework SDK (bin) in your path.
5. Change the public key and resign via "SNReplace Some.exe mykey.snk".

That's all. You can run "SN -Tp Some.exe" before and after to see that the public key has indeed changed. "SN -v Some.exe" will verify things are in order.

Download: SNReplace.exe (16 KB) Source: SNReplace.cs.txt (2.72 KB)
Code | Security
Sunday, November 28, 2004 7:20:21 AM UTC  #    Comments [12]  |  Trackback Tracked by:
"http://reversengineering.wordpress.com/2007/08/05/cracking-code/" (http://rever... [Pingback]
"http://cypvori.biz/george-ryan.html" (http://cypvori.biz/george-ryan.html) [Pingback]
" Como crackear assemblies..... con nada de experiencia" (la visión de un ingeni... [Trackback]

Monday, November 29, 2004 8:51:54 AM UTC
Hi Michael

It IS possible to fool the CLR to skip the strong name verification of a strong named assembly. All you need to do a tweak a particular byte in the assembly metadata. Please follow this thread:
http://www.google.co.uk/groups?hl=en&lr=&threadm=%23UDXSOX0EHA.3820%40TK2MSFTNGP11.phx.gbl&rnum=2&prev=/groups%3Fq%3DRahul%2BKumar%2Bgroup:*security*%26hl%3Den%26lr%3D%26selm%3D%2523UDXSOX0EHA.3820%2540TK2MSFTNGP11.phx.gbl%26rnum%3D2
Rahul Kumar | rawwoolAT NOSPAMyahoo dot com
Monday, November 29, 2004 1:59:00 PM UTC
Wow, very interesting. I'm going to check into it and see what's going on. If what Frank says is true, I'd think that to be a security problem for many companies. Interesting indeed.
Michael Giagnocavo | mggAT NOSPAMAtrevido dot net
Monday, November 29, 2004 8:18:33 PM UTC
And even easier: just register the original strong-named assembly in the GAC and then overwrite it with patched one. Works like a charm. Of course, you have to have certain priviliges, but usually this is not an issue, right?
XapoH
Tuesday, November 30, 2004 1:14:34 AM UTC
sn -Vr
caspol -s on|off
LF
Tuesday, November 30, 2004 2:41:31 AM UTC
Mike,

if I have my assemblies strongly signed and I use Linkdemand to check the immediate caller, it means that I can modify the public key and fool the security checks?

Patrick.
Patrick Mac Kay
Wednesday, December 01, 2004 3:51:46 AM UTC
XapoH, can you go into more detail? I installed a test into the GAC, then overwrote it (C:\windows\assembly\test.exe\blabla\test.exe), and was not able to get it to load.

LF, you're right, it's -Vr, not -Vu. At any rate, as I put in my article, no, that does not work. Turning off caspol didn't do the trick either.

Thanks for the suggestionss, but they are all *system* settings -- not something you can distribute in a patch. As usual, a good patch will modify as little as possible. Disabling system security, playing with the GAC, etc. violate this basic idea.
Michael Giagnocavo | mggAT NOSPAMAtrevido dot net
Wednesday, December 01, 2004 3:55:41 AM UTC
Patrick: By replacing the strong name, you can play with items on the local disk. If a user has access to the exe and can modify it, he can do anything (basic principal of security). He could just remove the linkdemands.

Now, according to that newsgroup thread, you can set one byte to zero and make the framework not check the strong name, but other programs still consider it a strong name. I haven't been able to repro it yet. Also, the poster in the thread (Frank) appeared to say it only had to do with references loading, and not the .NET framework applying CAS. i.e., it wouldn't work just for a cracked program. I'm gonna look into it and see what's the real story.
Michael Giagnocavo | mggAT NOSPAMAtrevido dot net
Thursday, December 02, 2004 8:43:29 PM UTC
Mike, I did it with .dll files. Not sure if you really can install .exe in GAC. Don't have any in mine...
XapoH
Thursday, December 02, 2004 8:46:04 PM UTC
Hmm, I'll have to check into that then.
Michael Giagnocavo | mggAT NOSPAMAtrevido dot net
Saturday, December 04, 2004 12:13:00 PM UTC
I have noticed that some assemblies use an AssemblyKeyName registered with the Crypto Service Provider instead of using an AssemblyKeyFile. Do you think this option provides better security and how easily is this type of strong naming cracked?
Gary B
Sunday, December 05, 2004 2:26:52 AM UTC
Gary, as far as cracking, no, using a key or container makes no difference.
Michael Giagnocavo | mggAT NOSPAMAtrevido dot net
Sunday, June 04, 2006 12:34:18 AM UTC
It seems that Fusion in .NET Framework 2.0 recognizes that the assembly has a public key and hence it knows that it must validate that key using the strong name signature. Unlike previous versions of .NET Fusion checks that the strong name signature data directory in the CLR header has valid values. So turning off some bytes makes no difference now.

Is there any way around that or finally it's well-protected?
Dahaka | that dot dude dot isAT NOSPAMgmail dot com
Name
E-mail
Home page

Comment (HTML not allowed)  

Enter the code shown (prevents robots):
Live Comment Preview