General Overview

Before going any deeper on this subject, we need to clarify a huge ambiguity regarding signing for versioning and signing for protecting.

A strong name signature is after all a set of information regarding an assembly. It may contain version number or culture information, but it will definitely contain a public key and a signature.

And regardless of the mathematical details of the public/private key pair, the strong name is intended to guarantee evidence about the origin of a given assembly, so that by loading an assembly, you are sure it’s the one you want to load and not another that looks just like it.

You have to distinguish between digitally signing and strong name signing. The common aim is to determinate if the source of our assembly is trusted or not, but when we talk about digitally signing, we are talking about a digital certificate which can come from different certificate authorities and Public Key Infrastructure source. If an assembly must be strong named (or strongly named), this step should be done before digitally signing it.

In addition to providing some benefits like versioning and giving name uniqueness to an assembly, strong name provides a strong integrity check, and here is the point of this article! By strongly naming an assembly, you are supposed to ensure that your binary has not been tampered with since it was compiled or built.

What interests us, as reverse engineers concerned by software protections, is the similarity between the behaviors of a traditional WIN32 application protected with a Cyclic Redundancy Checksum and a strongly named “dot NET” Assembly. As was said earlier, this will prevent the assembly from being changed, or in other words from being patched. Most software vendors rely on this, which is really not safe at all since strong name is not for security and must not be considered as a protection. We will see why in detail…

Signing an Assembly with a Strong Name

Understanding the two cryptographic concepts of hashing and digital signing is important to understand how strong name works.

Hashing is essentially used to verify data integrity so that we can determine if the message (data) was altered or not. Hashing is an algorithm capable of producing another data with smaller and/or fixed length. In our context, data refers to an assembly, so our assembly is used as an input for an algorithm hash, such as SHA-1 (as it happens on strong naming) or MD5 to produce a “theoretically?” unique output.

Hashing is irreversible and the hash value produced cannot be decrypted, so if two assemblies produce the same hash value, we can deduce that they are the same. If the value of a previously calculated hash changed, this means that the assembly itself has been changed.

By previously knowing the calculated hash of an assembly, we can determine if this last is tampered or not. And to protect this hash value itself from being tampered too, digital signing is used.

Beyond mathematical details and complexities, the concept of digital signing is quite simple and clear. Every digital signature depends on a public and a private key which are obviously related. If an assembly (data) is encrypted using the public key, it can be decrypted only using the private key.

Basically, by strong naming an assembly, a hash value is calculated, and then it’s encrypted using the private key previously generated by the vendor. Then it’s placed along the public key in the signed assembly itself so the Common Language Runtime (CLR) can validate the assembly at runtime by comparing the decrypted hash stored in the signed assembly, using the private key stored among other information, and a new calculated hash. If the two hashes match, the assembly is loaded; otherwise, it crashes. The figure below describes this process:

This is the basics of how strong name works, so every strong name essentially contains the name of an assembly, its version number and its culture information. If provided, the whole provides a unique hash / identity for every signed assembly.

Before strong name signing an assembly, we need to generate a public/private key pair, and obviously the dot NET Framework SDK provides tools for assigning a cryptographic signature to any built assembly. This includes the Strong Name tool “sn.exe” which will help us in building the key pair we need.

The first step in strong name signing is generating a key pair. The “sn.exe” tool is located in “C:Program FilesMicrosoft Visual Studio 8SDKv2.0Bin” and is a command line based tool, so start Microsoft CMD and use this command to generate a new key pair:

Sn –k MyKeyPair.snk

This way, we obtain a random key pair (MyKeyPair.snk) which contains both private and public key. We can of course extract the public key from the key pair obtained and place it in a separate file, but we will not enter in details on this since our main goal is to demonstrate that strong name must not be considered as a protection because of how weak it is!

Well, now by using MyKeyPair.snk, we will sign an assembly. There are several ways to do it: either by adding the correct custom attribute to your AssemblyInfo.vb or AssemblyInfo.cs source:

[assembly: AssemblyKeyFile(@"....MyKeyPair.snk")]

<Assembly: AssemblyKeyFile(“....MyKeyPair.snk”)>

Or directly through Microsoft Visual Studio IDE via project’s properties – click on signing tab, check “Sign the assembly” then browse to the .snk file:

By building your project, you get a strong name signed assembly.

Determining if an Assembly is Strongly Named or Not

There are several approaches applicable to determine if an assembly has a strong name or not. I’ll show you some of them. The first one uses the same tool that helped us in generating our key pair file: the sn.exe tool.

For this, we run it using the following command: sn –vf MyAssembly.exe (or MyAssembly.dll)

The result when tested on a strongly named assembly is:

Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.
Assembly ‘CrackMe4-Signed.exe’ is valid

But when tested on a non signed assembly:

Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42

Copyright (c) Microsoft Corporation. All rights reserved.
CrackMe4-unSigned.exe does not represent a strongly named assembly

Using the same tool, we can also explore the public key of a signed assembly using the following command: sn –tp MyAssembly.exe (or MyAssembly.dll).

ILDASM, the Microsoft Intermediate Language Disassembler, can provide more details about strong name. To know more about handling this tool, please refer to previous articles about Demistyfying Dot NET Reverse Engineering. By loading a strongly named assembly using this utility, which is found in somewhere like C:Program FilesMicrosoft SDKsWindowsv7.0Abinildasm.exe, you can double-click the “MANIFEST” section to explore its content:

If the assembly we are analyzing was not strongly named, the .publickey directive should be missing. Obviously, any other tool like Reflector and ILSpy will do the same work.

Actually, strong name does not survive to round trip engineering, which means if you modify the Intermediate Language of a strong name protected assembly then recompile it, it’s not supposed to work.

Removing Strong Name from an Assembly

There are several ways to remove a strong name from a protected assembly. I’ll try to demonstrate some “easy” ways to un-protect any strong name protected assembly. In order to achieve this, in addition to ILDASM and ILASM, we will need a hex editor and a tool called CFF Explorer which you can find in the reference section.

Try to run our target to see what it says and let’s practice:

Basically, we need to change the string loaded even if this is a strong name protected assembly. Start by disassembling our target using ILDASM to produce an IL file, which is the attached CrackMe#4 –BreakingStrongName, then search for this string:

Change it and reassemble the IL file using ILASM:


C:WindowsMicrosoft.NETFrameworkv4.0.30319>ilasm “”


Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Operation completed successfully

Now our target refuses to run because it’s strong name protected and, as said before, strong name does not survive in round trip engineering, which we did by disassembling, editing IL code, then reassembling it.

Now let’s get back to ILDASM and see the content of the MANIFEST section:

Actually this is the value of the public key of our target’s strong name, which can be located on the IL file produced by ILDASM after dumping the loaded assembly as seen here (search for the string “RSA1″):

The first way to remove a strong name from an assembly is by simply removing these directives and its content which will lead to something simillar to this:

Then change the string loaded by the target with whatever you want, recompile it and test it:

And yes, strong name is weak and we changed the string loaded!

This is the first method you can use to remove strong name from an assembly. Now let’s discover how we can remove it using CFF Explorer.

Load our target on CFF Explorer. This tool provides an important section when dealing with dot net assemblies which is .NET Directory:

According to the structure of a managed executable file, the Common Language Runtime headers are put in the .text section and the header file is defined as a structure:

Want to learn more?? The InfoSec Institute Reverse Engineering course teaches you everything from reverse engineering malware to discovering vulnerabilities in binaries. These skills are required in order to properly secure an organization from today's ever evolving threats. In this 5 day hands-on course, you will gain the necessary binary analysis skills to discover the true nature of any Windows binary. You will learn how to recognize the high level language constructs (such as branching statements, looping functions and network socket code) critical to performing a thorough and professional reverse engineering analysis of a binary. Some features of this course include:

  • CREA Certification
  • 5 days of Intensive Hands-On Labs
  • Hostile Code & Malware analysis, including: Worms, Viruses, Trojans, Rootkits and Bots
  • Binary obfuscation schemes, used by: Hackers, Trojan writers and copy protection algorithms
  • Learn the methodologies, tools, and manual reversing techniques used real world situations in our reversing lab.

typedef struct IMAGE_COR20_HEADER
USHORT MajorRuntimeVersion;
USHORT MinorRuntimeVersion;
// Symbol table and startup information
ULONG Flags;
union {
DWORD EntryPointToken;
DWORD EntryPointRVA;
// Binding information
// Regular fixup and binding information
IMAGE_DATA_DIRECTORY ExportAddressTableJumps;

And to provide a closer look at the marked fields:

Offset Size Field Description
16 4 Flags Binary flags. In ILASM, you can specify thisvalue explicitly by the directive .corflags<integer value> and/or the command lineoption /FLAGS=<integer value>. Thecommand line option takes precedenceover the directive.
32 8 StrongNameSignature RVA and size of the hash data for this PEfile, used by the loader for binding andversioning.

Flags = 0000000B means COMIMAGE_FLAGS_ILONLY (0×00000001) |COMIMAGE_FLAGS_32BITREQUIRED ((0×00000002)| COMIMAGE_FLAGS_STRONGNAMESIGNED (0×00000008). This means that the image file contains IL code only with no embedded native unmanaged code. This image file can only be loaded on a 32-bit processor and is protected with a strong name signature. So 0×00000001 + 0×00000002 + 0×00000008 = 0×00000011, which is B in hexadecimal.

The trick is to change the value of the Flags field by changing COMIMAGE_FLAGS_STRONGNAMESIGNED from 0000000B to 00000003, and changing the StrongNameSignature Size and StrongNameSignature RVA to 0. But this is not everything. Keep on analyzing the target using CFF Explorer by clicking on Metadata Streams -> Tables -> Assembly:

The Strong Name signature field of the CLR contains the RVA and size of the strong name hash value. After creating and hashing the image file to stronglly name it, the resulting hash blob is written into the space allocated to it inside the image file.

To make it easy and clear, we have to set Flags’ and PublicKey’s values to zero.
So to completely remove any strong name authenticity related checks, we have to make these changes:

Offset Original Value Changed Value
00000418 0000000B 00000003
00000428 0001C4C0 00000000
0000042C 00000080 00000000
0001BCEE 00000001 00000000
0001BCF2 04F7 0000

You can perfom these changes directly using CFF Explorer or by looking for the value using its given offset using a hexadecimal editor. To change a value using CFF Explorer, just double click on it and type in the new value, then File -> Save as.

Let’s try the new saved file. Now disassemble it, change the string and reassemble it as we previously did:

This is how easy you can get rid of strong name protection ! You can find in the references section below a generic tool that can remove strong name from any dot NET assembly.