The problem with 9Rays, Inc.'s Spices.Net is figuring out where to begin.

This tool offers a considerable number of features in its suite for code analysis. You can study the code in depth, in ways that you can't accomplish when using other products. For example, you can view both the DOS header and the NT headers for the executable. You can also diagram your application, create documentation for it, and even sign it from within the application.

Spices.Net does some things exceedingly well, but as you'll see, it doesn't measure up in other ways.

First, let's talk about some of the impressive features. When you decompile code, you can choose which language to use, not just the usual Intermediate Language (IL). The language support in the main application includes IL, C#, Visual Basic, Delphi, J#, and Microsoft C++.

You also have a high level of control over the obfuscation process, and can reverse it as necessary (unless you specify that the obfuscated module not allow disassembly). I began with a simple example, so I could see how the various features worked. Then I moved on to a complex project, representing a real world environment. As part of the review, I also looked at DLLs, to determine just how well Spices.Net would work in various environments.

Exploring Code

The Explorer, shown in Figure 1, is one of the more interesting parts of the application. As with ILDASM, it shows you the assemblies' properties, classes, and settings. However, the output you receive is more detailed, and possibly easier to read. In addition, you also see any resources the assembly requires, and any references it makes. Consequently, you see the application in its entirety, rather than bits and pieces.

Figure 1: Explorer shows you everything about the application from a .NET perspective.

Unfortunately, Spices.Net kept telling me that it couldn't resolve a particular assembly. Invariably, I'd point out the right location for the assembly, and then everything went well for the rest of the session. This particular problem only seems to happen on computers with multiple versions of the .NET Framework installed, so you may never see it. However, you may run into situations where Spices.Net can't find its own assemblies. The program kept telling me that it couldn't resolve the NineRays.Utils.XmlSerializers.dll file. Unfortunately, I couldn't seem to find this file either.

You can use the Explorer to discover a significant amount of information about your application. Right click any entry; you'll see what might be the world's longest context menu, as shown in Figure 2. Many people will find the list of things you can do a little intimidating, but I adjusted to the wealth of features quickly. This review doesn't discuss all of those entries in detail — there simply isn't room — but I'll discuss the important highlights.

Figure 2: The Explorer context menu contains a wealth of things you can do with any given entry.

I often want to see how someone else writes their code, as a way to improve my own coding techniques. I tried the decompiler first. This feature works flawlessly, and is an impressive technical feat.

I wrote the example shown in Figure 1 using C#, and was curious how Spices.Net would decompile it to Visual Basic. The results shown in Figure 3 aren't precisely the way I would write the code, but they do work. You probably wouldn't want to use Spices.Net to translate code from one language to another, but it works fine to learn new coding techniques.

Figure 3: The decompiler performs well even when you move to a language other than the one originally used to write the application.