Poupou's Corner of the Web

So I started adding a Gtk# GUI on top of my previous Cecil / Dot graph hacks (see here and here to see them). Nothing extraordinary about it, in fact nothing interesting enough to show yet ;-)

Actually most of my weekend hacking wasn't GUI related at all. Most of it has gone into refactoring the existing source code to reduce duplication (as they all evolved from the same code base, the new permview.exe tool) and to move the different tools into plugins.

Plugins are often overrated, and overused, but in this case I know some of them requires quite a lot of memory (e.g. finding all public callers) and many planned (i.e. in a dark corner of my mind) plugins will too have high memory requirements. How much ? well probably more than I have right now, so there's no point having all plugins around at the same time unless necessary (or for a limited number of assemblies).

To make this easier the tool operates on working sets which are simply a list of assemblies and a list of plugins (with their options) to load. So it's possible to work with few assemblies (e.g. mscorlib.dll) in more details or work with all (e.g. every dll under /mcs/class/lib/default/) with fewer plugins.

I also did some low-level class to help generating dot files and couldn't resist trying them off for a new kind of graph (funnier than refactoring the existing ones :-). This graph shows the dependencies between assemblies, in this case the Mono.Security.dll dependencies.

The graph shows all assemblies referenced by Mono.Security.dll either directly (like mscorlib.dll and System.dll) or indirectly (System.Xml.dll being loaded by System.dll). It also shows the references between the referenced assemblies, so we can clearly see the cyclic dependency that exists between the System.dll and System.Xml.dll assemblies. Assemblies loaded via reflection (e.g. via CryptoConfig) are missing as they can't be (in most case) known until runtime.

From a security point of view the graph adds two major informations.

• First the type of caller that can call into the assembly. By default strongnamed assemblies can only be used by fully-trusted code. The CLR enforce this by adding an invisible linkdemand to all publicly methods/classes. Adding a [AllowPartiallyTrusterCallers] attribute at the assembly-level makes the assembly available to partially trusted callers (e.g. code coming from the internet). This can be dangerous if the assembly API isn't designed for such use - which means that most assemblies do not support partial trust.
• Also assemblies compiled with unsafe code, which means that the compiler inserted a [UnverifiableCode] attribute in the unsafe module, are shown in red. The CLR cannot ensure the code in those assemblies isn't messing up your system, so it's nice to know who they are.

And, of course, being both red (unsafe) and accessible from partially trusted callers is far more risky than only one of them could be.

Like the previous graphs assembly dependencies can get very ugly. In fact the worst cases I've seen is for data providers. They have a lot of dependencies themselves (and some even have unmanaged dependencies not show in the graphs) and they often links to System.Windows.Forms.dll to include design-time support (which adds a lot more dependencies).