Added support for ImplMap entries and relationships for .NET binaries

[Czatar]

Output for the "dotnetImplMap" key in the metadata shows the name of the DLL paired with a list of functions used from the DLL. Determining relationships works the same way as "dotnetAssemblyRef" entries.

[nightlark]

Suggested change

	def get_implmap_info(im_info, imp_modules):
	def get_implmap_info(im_info, imp_modules):

This is doing a bit more than just getting the implmap -- maybe call it add_implmap_info or insert_implmap_info instead to capture that it is also modifying part of the SBOM.

[nightlark]

What were the URLs/doc links that you referenced for info on how .NET determines where to look for the DLLs listed in ImplMap?

[Czatar]

I was mistaken about unmanaged code loading being the same as loading assemblies. I got my sources mixed up, but I found the one that relates to ImplMap (PInvoked) libraries and included it. From what it looks like, if it's not the assembly/application directory, it's the system32 folder (default unless someone overrides the loading function).

[nightlark]

In addition to probing directories similar to .NET (or instead of depending on if we can determine whether or not this applies to loading unmanaged libraries), it looks like we need to have code that looks for relationships according to https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/default-probing#unmanaged-native-library-probing and searches for names/paths according to https://learn.microsoft.com/en-us/dotnet/standard/native-interop/native-library-loading when a relative path is given.

[nightlark]

I don't think the get_windows_pe_dependencies function does what we want when a dependency is specified using absolute paths -- the function itself constructs a list of probe directories relative to the software, which when the given path is absolute we don't care about searching, and then it calls the find_installed_software function internally to find a match, which appends the file name for an import (which in this case would be an absolute path) to each probe directory given in turn.

For an example of a program in C:/PrgFiles/Program.exe an absolute import of C:/SomeFolder/Dep.dll looks like it would result in the function trying to search for something like C:/PrgFiles/C:/Somefolder/Dep.dll.

For matching an import listed as an absolute dependency, I think we can have a loop that just looks for a Software entry with an install path that just matches the absolute import name, without any of the probe directory things in it.

ref_abspath = pathlib.PureWindowsPath(refName)
# iterate through all sbom entries
for e in sbom.software:
    # Skip if no install path (e.g. installer/temporary file)
    if e.installPath is None:
        continue
    if isinstance(e.installPath, Iterable):
        for ifile in e.installPath:
            # PureWindowsPath is case-insensitive for file/directory names
            if ref_abspath == pathlib.PureWindowsPath(ifile):
                # matching probe directory and filename, add relationship to list
                relationships.extend(Relationship(dependent_uuid, e.uuid, "Uses"))

[nightlark]

I don't think the line calling get_windows_pe_dependencies should be present - haven't confirmed, but in that function it is appending refName (which in this case is an absolute path such as C:/Somefolder/Dep.dll) with the path software is located in, so it will just be searching for garbage paths like C:/Program Files/softwareinstalldir/C:/Somefolder/Dep.dll that are actually invalid path names on Windows (: is not allowed in folder names) so the files it is looking for should never exist.