Patching strong name .NET assembly

[jjhsd]

I am cracking a software written in .NET and having two problems:

a) How can I map MSIL to the original binary file's offset to find the exact bytes (offset) i want to patch? MSIL only provide VRA.

b) the assembly is a strong name assembly, i guess by changing any bit, the checksum will be void, how can i defeat this?

any one knows?

TIA.

[Shub-Nigurrath]

look here ..

three parts article on Learn to protect your .NET assemblies from being Tampered

http://www.codeproject.com/dotnet/NeCoder01.asp
http://www.codeproject.com/dotnet/NeCoder02.asp
http://www.codeproject.com/dotnet/NeCoder03.asp

[jjhsd]

Thank you for your reply.

I have checked this article. However I don't think it's gonna to be helpful, as the program has used some obfuscator. I wish i could patching the binary file without recompiling it from MSIL.

I just found a solution to problem a). So b) will be the only remaining problem. after I patched the file and tried to resign them with my own key pair, the application doesn't run any more. U_U
Actually i think this problem is quite generally. There will be more and more applications written in .NET in the future, and strong name assemblies will be one of the most common things to be implemented as part of software's secutires.

[SystemeD]

Hi,
If you're working with a Windows app the easiest way to solve b) is fooling the CLR patching the Strong Name Signature size from 80h to 00h. In this way the CLR thinks that the assembly is not strongnamed. The offset for this byte change from assembly to assembly but usually you can find it at the beginning of the file (from 200h to 300h)...

You can find useful infos here...
h**p://www.woodmann.net/forum/showthread.php?threadid=4389

Regards,
SystemeD

[Shub-Nigurrath]

try also to disassemble using IDA.

There are two basic types of MSIL (miscrosoft intermediate language) disassemblers.
ILDASM, Reflector and the like use the Reflection api to disassemble a dot net assembly.
IDA does not use the reflection api, instead it examines the bytes of the dot net assembly to disassemble.
The distinction between the two methods above is useful because many of the current crop of dot net protectors have the ability to stop disassembly via the reflection api. This is achieved by placing invalid meta data in the CLR (common language runtime) header of the file. This meta data is ignored during the execution of the program so it runs fine."

Of course the MSIL you get could be a nightmare..

[SystemeD]

Another difference is that you can recompile MSIL generated by ILDASM and I didn't succede doing the same with IDA.
I wonder if there is a way to do that...
Any suggestion?
SystemeD

[jjhsd]

Thank you.

I have checked URL SystemeD passed to me. How can i patch mscoree.dll? I tried to run the second attachment, but it seems it is not a patch.

[SystemeD]

I didn't try the attachment but I suggest you to not patch mscoree.dll because it's a framework .net assembly and it would be better achieve your result, patching your app and not the framework. Try to disassemble the prog, find a way to recognize the strong name signature lenght inside the file and patch it.
Remember the "/adv" option while running ILDASM, it will give you more advanced feature when dumping (i.e. dump metadata and so on).
Good luck

[jjhsd]

actually i guess by patching mscoree.dll will be the easiest way to bypass strong name code tampering check. once we turn it "off", then we can patching any .NET application without worrying about strong name issue. it is an once-off solution. ^__^

[jjhsd]

Originally Posted by SystemeD

I didn't try the attachment but I suggest you to not patch mscoree.dll because it's a framework .net assembly and it would be better achieve your result, patching your app and not the framework. Try to disassemble the prog, find a way to recognize the strong name signature lenght inside the file and patch it.
Remember the "/adv" option while running ILDASM, it will give you more advanced feature when dumping (i.e. dump metadata and so on).
Good luck

Thanks SystemeD.
Here are some updates. I found the byte where strong name signature's length is stored. Search for 00 80 00 and it is around 0x1020. change it to 00 00 00 will bypass the checkings.

I tested this on three programs. It seems this position is fixed. I have patched two programs by myself (LLBLGen Pro and ReSharper).

for anyone who can read Chinese and interested in reverse engineering, pelase check this article:

hxxp://www.cnblogs.com/feidao/archive/2004/08/17/32555.aspx

at the very beginning, the author mentioned he tried to rewrite the CheckSum and GetExpirationDate function but failed. The reason is he didn't patch the signature length byte, if it is changed from 80 to 00, then the program will be fully cracked. That's the thing i tried two days ago.

anyway, thanks for all the people who helped me. I have learned a great deal! ^__^