Scanning .NET Assemblies for References

Introduction

As part of my work on running code in isolation, or sandbox, I set out to investigate how can we restrict what the hosted code runs, or, at least, find out what it is trying to do.

I was interested in finding out what references does an assembly have, not just assembly references, but what types and methods it is actually accessing, from other assemblies. I ran into an old acquaintance, Mono.Cecil, which can helps us do just that, as I'll explain.

Introducing Mono.Cecil

From it's page on the Mono Project site: "Cecil is a library written by Jb Evain to generate and inspect programs and libraries in the ECMA CIL format. With Cecil, you can load existing managed assemblies, browse all the contained types, modify them on the fly and save back to the disk the modified assembly."

Cecil is part of Mono Project, a most interesting initiative, which you should be aware of, if not already. It started in the old days of .NET Framework, when it wasn't open-source and platform-agnostic and only ran on Windows. Of course, here we are not interested in code weaving, but in code inspection: we can use Cecil to inspect all of the instructions inside an assembly, and, for each, figure out if it's a method call. We will only be interested in method calls to outside libraries. For example: calls to Process.Start, TcpListener, SqlConnection, etc, might be considered problematic; we can use Cecil to check an assembly against our blacklist.

Introducing ReferencesScanner

ReferencedScanner is my new project for getting external references for an assembly. It consists of a type Reference that holds method references, and an IScanner contract:

public record struct Reference(System.Reflection.MethodBase Method);

public interface IScanner
{
    IEnumerable<Reference> GetReferences(string assemblyName);
}

As you can see, the Reference record struct is, for now, just a holder of MethodBase references, which can either be constructor instantiation (ConstructorInfo) or method calls (MethodInfo). From it, you can see what type and assembly was called, as well as the method itself, of course.

There are a few extensions to IScanner that allow us to pass in Assembly or Type objects, but, the core GetReferences method takes as its only parameter the path of an assembly (.dll or .exe).

Sample usage:

Assembly asm = ...;
IScanner scanner = new ReferencesScanner();
var references = scanner.GetReferences(asm);

ReferencesScanner is the only provider implementation, which uses Mono.Cecil to get IL information from the target assembly. For now, I kept it very simple: it will ignore references to method calls on strings, objects, or other primitive types.

The purpose of this project is solely getting all references from an assembly, so that we can get a glimpse of what it's supposed to do.

Future Work

I may want to try out other code inspectors other than Cecil and also a few more things, such as integrating with Isolator. This project will always be very simple, I suppose. Let me know if you'd be interested in having something else.

Conclusion

You can find the code and package on the following locations:

GitHub: https://github.com/rjperes/ReferencesScanner

Nuget: https://nuget.org/packages/ReferencesScanner

Location: Coimbra, Portugal

Comments

Post a Comment

Popular posts from this blog

C# Magical Syntax

Introduction This post is an update to an old one on my  old blog  and it was inspired by my latest posts on C# versus Java . You may not have realized that some of the patterns that you’ve been using for ages in your C# programs are based on conventions, rather than on a specific API. What I mean by this is, some constructs in C# are based on some magical methods with well-defined names which are not defined in any base class or interface, but yet just work. Let’s see what they are. Enumerating Collections You are probably used to iterating through collections using the foreach statement. If you are, you may know that foreach actually wraps a call to a method called GetEnumerator , like the one that is defined by the IEnumerable and IEnumerable<T> interfaces. Thus, you might think, the magic occurs because the collection implements one or the two, but you would be wrong: it turns out that in order to iterate through a class using foreach all it takes is that the c...
Read more

OpenTelemetry with ASP.NET Core

Image
Introduction I wrote a post not too long ago about the building blocks of telemetry , or distributed tracing , with ASP.NET Core. Now I'm going to talk about how we can see it working using an open source bundle, otel-lgtm . Mind you, this may not be 100% suitable for production, but for development purposes, it should be fine, all concepts apply, of course. I won't cover everything about OpenTelemetry here, but should hopefully give you some insights as to what's there and how you can make good use of it. First, lets see what some of the concepts are. If you're interested in learning more about metrics, I suggest having a look at my post on this topic . OpenTelemetry OpenTelemetry  (OTel) provides a single, open-source standard, and a set of technologies to capture and export metrics, traces, and logs from your cloud-native applications and infrastructure. OTel is both a standard and a reference implementation that builds on other standards, such as W3C Distributed Tr...
Read more

ASP.NET Core Middleware

Image
Introduction This post is another of those "back to basics", still, there was one thing or two that I feel were not properly discussed elsewhere, hence this post. The ASP.NET Core Pipeline and Middleware You may know that ASP.NET Core defines a pipeline. This is where the incoming requests are processed and the response submitted. Each component in the pipeline - a middleware - can do things with the message (the request), such as check if it is authenticated and have rights to access the requested resource, turn the request into an MVC-style controller and action invocation, log it, and what not. You can read more about it here . The ASP.NET Core pipeline, from Microsoft The order by which the middleware is added to the pipeline matters. For example, the authorisation middleware must come after the authentication one, static files must come before routing, and exception handling must come before everything. The middleware order, from Microsoft A middleware is just a piece of...
Read more