0

Background

We are looking to permit 3rd parties to upload compiled .NET.Core assemblies as plugins into custom AssemblyLoadContexts.

Objective

But the assembly needs the for security issues first, and if it fails, dumping the whole context.

Examples

For example:

  • we may want the Plugin to only Reference Assemblies that contain APIs, and not lower assemblies that provide integration services (to the db, etc.)
  • we may want to exclude the assembly if it is making calls to any type that has System.IO for example.
  • Spot the use of new() so we can log what they are instantiating via an override of IServiceDepency?
  • We'll learn, and the list will grow over time...

Constraints

Preferably, we'd like to do the inspecting with framework and/or freely available packages, rather than as per: Inspecting contents of compiled assemblies

Questions

  • Can Roslyn be used for decompilation -- or is it only a code compiler?
  • Could anyone point to a very simple example to get started?

Thank you!

Sky
  • 55
  • 7

1 Answers1

0

Roslyin is a compiler technology and can't decompile compiled code.

You can look at the compiler code and learn the IL generation patterns to decompile the code or use something like ILSpy.

Paulo Morgado
  • 14,111
  • 3
  • 31
  • 59
  • Thanks for the confirmation on Roslyn's capabilities. And recommending ILSpy, which I tried and was sucessful at getting a correct list of References (ie ensuring it talks to an Application layer assembly (where APIs are) and not lower down. But...as to not touching the harddrive for example...that's less clear. Not as simple as checking for "Sysem.IO.File.Open"/etc being in the code base. Due to can invoke another library, which in turn invokes the IO.etc....But so could have legitimate use of 3rd party libs that do have such methods -- but not called. Can't walk tree yet :-( – Sky Sep 27 '22 at 21:50