Here are some rather simple but still clean and to the point articles about cracking .NET (aka dotnet) programs, including bypassing Strong Name protection:


Building Security Awareness in .NET Assemblies:

Part 1 - Learn to break a .NET Assembly:
http://www.codeproject.com/dotnet/NeCoder01.asp

Part 2 - Learn to protect your .NET assemblies from being tampered:
http://www.codeproject.com/dotnet/NeCoder02.asp

Part 3 - Learn to break Strong Name .NET Assemblies:
http://www.codeproject.com/dotnet/NeCoder03.asp


Questions about these things have been asked several times here before, so I thought I'd make these articles indexed by the forum search engine by posting them here, enjoy.

Hey!

I want to add that the mentioned method for bypassing Strong Names in .net assemblies only works on apps that use some kind of windows forms.. If it's anything other than that it won't work. The reason that this even works in the first place is due to a bug in the .net interpreter.

Anyways, I've worked on trying to find a solution for a .net app that utilizes a DLL file and with Strong Names and so far I haven't found any way to bypass it. If I do eventually succeed I will ofcourse share this information here.

Has anyone experience with .net assemblies which contain invalid metadata(will crash ildasm)? There are some obfuscators that insert invalid metadata to protect assemblies from being disassembled.

readdict, it would be great if you could elaborate on a few things:

1.
Why does it only work on assemblies with Windows Forms in them?

2.
Exactly what is this bug in the interpreter that you're talking about, are you really sure about that?

3.
I'm not very familiar with the internals of .NET assemblies, but what those articles said was exactly what I had been guessing all the time, with my limited knowledge. Namely, that if some code has a digital signature on it, but the interpreter does not require any particular signature, or even any signature at all, you can simply replace the current signature with anything you like, or even remove it, and then patch/run the program to your heart's content? Exactly what prevents this method from always working, e.g. in the cases you mention?

I'd be grateful if you could point us to some binaries that can't be de-strongnamed this way.

I've used it succesfully for console-only (and multi-module) apps.

Delta/Omega red,

It seems that I have mixed up the facts abit, i'm sorry about that. I got some of the information from these forums and other parts I got from experimenting with different .net assemblies... Let me clarify further what I got...

First off some of the info can be found in a thread at this forum:

hxxp://66.98.132.48/forum/showthread.php?t=4389

1. It wasn't when modifying the PublicKey contents but when changing the length of the StrongNameSignature from 80h to 0 that this didn't work with any other .net assemblies than windows forms apps..

But I haven't succeeded in removing the publickey + hash from my console targets yet without making them non-working after recompilation. But with windows forms .net apps I have so far always managed to do so and this is partly the reason that I thought that this applied in all cases, not only with the StrongNameSignature lenght was changed.

But now that Omega red points out that he has successfully managed to reverse .net console apps I'm starting to think that perhaps my targets are using some kind of internal checking that messes this up for me. Also see what I've found out below at 3.

2. No I am not sure about this, I've only read about this in other posts regarding reversal that includes removing the StrongNameSignature. So I cant provide you with any actual proof that this is the case.

3. I have saved some snippets from various sources from back when I was experimenting with this and the one that I find now which explains this somewhat is:

--

Most of the wizard-generated projects in MS Visual Studio .NET place this attribute in a file called AssemblyInfo, but you can put it in any source file you like. When the compiler sees this attribute, it copies the entire public key into the assembly's metadata, and uses the private key to form a digital signature. This is done by hashing the files in the assembly, incorporating those hash values into the manifest for the assembly, hashing the manifest, and, finally, encrypting this final hash value using the corresponding private key and tucking it away as yet another block of metadata in the assembly.

If you look at an assembly's manifest using ILDASM, you'll be able to see its public key quite plainly. What you won't see is the signature or the intermediate hash values. This sometimes confuses people who are learning about strong names. ILDASM doesn't show these things because ILDASM is a disassembler - it is supposed to produce IL that can be compiled into an assembly, and remember that the signature and hash values are output by the compiler (which would be ILASM in this case).

So there you have it. Just because you can use ILDASM doesn't mean you'll be able to access everything in an assembly. You can change the public key, but you won't be able to change the signature or the hash. By changing the public key, you'll render the signature invalid, and the assembly will fail to load.

I might note that the point (at least from Microsoft's perspective) was to not be able to substitute assemblies in a componentized environment. If you built the program with a strong named assembly system, the name, version number, culture code, and public key hash are stored in the manifest. If the runtime comes across an assembly with the same weak name but missing or incorrect strong name, it will fail to execute.

--

Last not but least for Omega red, have a look at hxxp://www.telerik.com and you will find the specific .net component target that I was working on last in which it didn't work by simply removing the publickey and recompiling.

Some additional information about the use of hashes when verfying the contents of the .net files..

--

Integrity of files is guaranteed by hash verification

The runtime must be able to guarantee that the contents of the assembly have not been changed since it was built. That is, it must be able to guarantee the integrity of each assembly it runs. It does this through hash verification: the assembly manifest contains a list of all files that make up the assembly, including a hash of each file as it existed when the manifest was built. As each file is loaded at load time, its contents are hashed and compared with the hash value stored in the manifest. If the two hashes don't match, the assembly fails to load.

--

It seems that in order to bypass the hash verification one has to generate new hash value on the patched/recompliled file(s) or it would fail?

Probably the difference lies in method: messing with binary, or decompiling/changing il/recompiling.
If you decompile signed assembly, remove hashes from ilasm source and then recompile, framework has no means to determine if the original file was signed or not. Ofcourse the file can check its integrity by examining public key or something like that

I've tried both, patching the binary and decompiling/recompling but it makes no difference.. So I suspect that there is some kind of internal check just like you say. I've lost the motivation for this particular target for now but sometime soon I will give it another go.

Do you have any suggestions to other non windows forms .net apps to reverse? preferably one that uses .DLL files.

Here's a thread referring to an example of that.

http://www.woodmann.com/forum/showthread.php?t=6027&highlight=salamander

-nt20

Thanks!
Did you try Xen0C0de, they modified the assembly in some way that even IDA can't load it. I don't know where is the trick atm, if a have time I will work on that and post some news here.

Interesting articles, dELTA, especially part I (part II&III are a little redundant, imho).

I was wondering if a tool like hiew already exist for .NET. You know, you can disassemble assemblies very easy, but what about helping the cracker to patch some opcodes away like we are used to do, in stead of what the guy that wrote the article is doing: re-assembling the asm into an exe file.

And if such a tool doesn't exist yet, would it be useful? I have no interesting projects to do the last days, so maybe...

@readdict

there are two general methods of patching .net assemblies(exe/dll files)
one is to decompile, modify and recompile as the articles delta pointed out,
two is by pure patching

i have previously demonstrated that due to what i believe is a bug in the .net framework you can modify the strong name key size in the clr header to 0 and trick the .net framework into thinking the assembly is not digitally signed (strong named assemblies).
yes this generally works for win forms executables and dll's

for more difficult assemblies, in particular asp.net files, patching the strong name key size alone is not sufficient. You also have to remove the strong name attribute. This involves modifying two bytes just before the RSA signature in the file. This in conjunction with the key size patch will again trick the .net framework into thinking the assembly is not digitally signed and therefore does not check the file.


failing that you could always modify the .net framework itself, always returning true for strong name verifications.

PS. patched versions radcontrols has been released

@the saint
generally ida will load most .net assemblies without complaining about metadata issues
however there are some obfuscators out there that wrap the .net managed code into non managed code in an attempt to stop this process.

Zac

Very interesting stuff there about asp.net files, I'm gonna look into that asap.

I know about modifying the .net framework but I don't like the idea of patching it to achieve the goal.. The target itself should be properly reversed.

When patching the strong name key size and the two bytes just before the RSA signature in the file the dll loads fully without giving an error about the strong name.

But as soon as any function from the dll's are used I get an error msg again.

--
Assembly Load Trace:

WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN

Stack Trace:

FileLoadException: The located assembly's manifest definition with name 'RadDesigner' does not match the assembly reference.
--

As you can see it is the comparison of Public Key Token of the DLL files that fails..

I found this: "the public key token for the assembly is a statistically unique hashed representation of the public key"

I'm researching this and hopefully I'll find a way to either create a new hash (if possible) that matches the patched file or some other solution.

All suggestion are welcome.. I'll keep you posted when/if I get any further on this matter.

btw I forgot about one thing that occured today which I haven't encountered previously.

When I try to complile the .IL file I get this errormsg:

Creating PE file
Error: No entry point declared for executable
Could not create output file, error code=0x80004005

In the PE Header of the .IL file there is a Entrypoint section with a address in it:

Native entry point address: 000234fe

So I don't understand why this happens, anyone who has encountered this before and knows what can be done about it?

This means that your IL file is missing the .entrypoint directive, either because you fucked it up somehow while editing it, of because of some other strange reason. Try to add it manually if it actually wasn't you who deleted it in the first place.


Read the articles below for more info about this and a bunch of other useful .NET IL stuff:

Demystifying Microsoft Intermediate Language:

Part 1 - Introduction:
http://www.devcity.net/net/article.aspx?alias=msil_1_intro

Part 2 - A Short Description of .NET Application:
http://www.devcity.net/net/article.aspx?alias=msil_2_dotnet

Part 3 - Debugging:
http://www.devcity.net/net/article.aspx?alias=msil_3_debug

Ok, then it must be ildasm that messes up somehow with this particular file.. If i just decompile it and then compile it again it gives that error.. So it has nothing to do with my editing.

Anyways, thanks for the info Delta. Now I can try other approaches and see if I can get this working with the .entrypoint present

I finally solved this.

The .entrypoint thing was just a stupid misstake from my side, since this was DLL files I must use the /DLL option for ILASM when compiling. If I dont it expects the file to have the .entrypoint since it thinks that the file is a normal executable.

The Public Key Token issue is caused by any exe/dll that includes the file you have removed the strongname from (dll file). Since when they normally use your targetfile they use the Publickeytoken to verify that the file isn't tampered in any way before executing any of its functions.

So what you have to do is to locate all files that use your targetfile and decompile them, edit them and search for your targets name and you will find something like:

.assembly extern /*23000003*/ TargetName
{
.publickeytoken = (12 34 56 78 99 87 65 43 )
.ver 1:0:0:0
}

Simply delete all the contents of the extern (.publickeytoken / .ver) so that it looks like this:

.assembly extern /*23000003*/ TargetName
{
}

And then recompile the file and it will work with your strongname-less target again

Nice work, thanks for the info.

I found some invalid PropertyMap entries, I will try to fix it and hope that ida will load the fixed assembly

A blog about .NET debugging. Lots of advanced technical info which might not all necessarily be much useful in a hands-on perspective, but it could still be quite interesting.

http://blogs.msdn.com/jmstall/

here is a tool which can change the signature in a modified file:

http://www.atrevido.net/blog/PermaLink.aspx?guid=f772c18a-f389-4c28-bd6a-a30f4ccc84f5

works excellent :-)

Dear all,

Hope you would find the article
Securing Managed Assemblies with Native Exe Interoperability (http://www.geocities.com/krishnapg/SecureAssembly.html) available at http://www.geocities.com/krishnapg/SecureAssembly.html
interesting in this regard.

Thanking you,
Yours,
P.GopalaKrishna.

Hello,

I'm trying to bypass the Strong name protecnion in one signed assembly.
I have removed the signature and recompiled the .il file and then I have loaded the assembly, but when the assembly calls one metod that has a the attribut ".permissionset linkcheck" the program fails:

Request for the permission of type System.Security.Permissions.StrongNameIdentityPermission,
mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.

Then I have removed the entry

.permissionset linkcheck = (3C 00 50 00 65 ....)

But then I get the error

Object reference not set to an instance of an object.

Do you Know how to bypass the StrongNameIdentityPermission?

Thanks

For the simple minded, or those that are looking to do some .Net assembly (RE-configuring), read on.
If you are looking to modify strong named assemblies, or not, on your local server,
step 1. download Microsoft .NET Framework 2.0 SDK Beta from MSDN if you don't have it. For those that insist on the old stuff, you can download the 1.1 release.
step 2. decompile the assembly (run ildasm.exe). It's a good idea to create a subfolder (i.e. IL) for the output *.il, *.res, *.resources, etc.
step 3. edit/patch/whatever the *.il assembly (using notepad or similar)
At this point, better before, it's a good idea to backup the original assembly to a new name or different folder.
step 4. compile using (ilasm.exe)
example below for dll assembly:
ilasm "C:\Program Files\Some Software Folder\IL\Your_assembly.il" /resource:"C:\Program Files\Some Software Folder\IL\Your_assembly.res" /dll /output:"C:\Program Files\Some Software Folder\bin\Your_assembly.dll"
step 5. run PEVerify.exe
example below:
PEVerify "C:\Program Files\Some Software Folder\bin\Your_assembly.dll" /md /il
This will tell you a few things.
1. Is this a strong named assembly
2. Is this a managed code assembly
3. Did you F*** up the modifications in your *.il file
If a strong named assembly, then,
step 6. Delete the assembly from the GAC. On my machine it is here:
C:\WINDOWS\assembly
step 7. run sn.exe to remove the strong named assembly from the verification
process in .Net.
example below:
sn -Vr "C:\Program Files\Some Software Folder\bin\Your_assembly.dll"
This must be done on the computer/server where the bin or GAC libraries are.
step 8. goback and run step 5.
PEVerify should not complain any more about the assembly.
Move the assembly to whatever bin folder if not compiled there already, or
if using GAC, then,
step 9. Run gacutil.exe for your *.dll
example below:
gacutil /i "C:\Program Files\Some Software Folder\bin\Your_assembly.dll"

Voila!!

It's always a good idea to cleanup old .Net temp files before using the new
assembly.
On my WINXP SP1 machine running .Net framework 2.0 it would be here:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.40607\Temporary ASP.NET Files.

Make sure you delete ALL occurrences of the old assembly if not using the GAC, OR make references to your NEW and improved assembly.

You should be good to go after that.

Special note: Yes, some vendors are using obfuscators to trick up decompilers, notably ILDASM. I have had some success in exposing the code using a product
from:
http://www.remotesoft.com/

RemoteSoft DotNet explorer. Excellent tool. If you have the bucks it will
do everything, but at the very least, the free version will let you look
at the assembly and it's internals.

Cheers

You might also look at:
http://www.aisto.com/roeder/dotnet/

In my experience .Net Reflector succeeds where even RemoteSoft's tools fails.

I used the 'resign' method' a while back (figured it out myself) as the 'unpacking' of the SN protection failed for me.