[Feature] Strip a type

[MulleDK19]

It'd be nice with a feature to strip specific types after obfuscating. For example, I like to use constants for the obfuscation instead of having the options directly in the Feature property.

[assembly: System.Reflection.Obfuscation(Exclude = false, Feature = ObfuscationConstants.MaximumProtection)]

internal static class ObfuscationConstants
{
    internal const string Preset = "preset(minimum)";
    internal const string ControlFlow = "+ctrl flow";
    internal const string RefProxy = "+ref proxy";
    internal const string Constants = "+constants";
    internal const string Renaming = "+rename(mode=sequential,flatten=false)";
    internal const string MaximumProtection = Preset + ";"
                                              + ControlFlow + ";"
                                              + RefProxy + ";"
                                              + Constants + ";"
                                              + Renaming;
}

The obfuscation attribute is of course stripped, but the ObfuscationConstants class remains, allowing anyone to see exactly which options I used for obfuscation.

It'd be nice if you could mark certain types like this with an attribute to have that type stripped after obfuscation. This would have no implications with consts, since they're inlined by the compiler and the type isn't actually used for anything.

Or perhaps just have it strip any non-public classes that consist purely of consts.

[mkaring]

Something like this will be added. Stripping unused internal members, types and constants.

[MulleDK19]

Cool. Careful, though. I'm not sure that should be a default on. Could cause issues with InternalsVisibleTo assemblies, unless you add checks for that.

[mkaring]

Type stripping will be a protection, just like all the other features. So it has to be enabled manually. The <InternalsVisibleTo> will be supported properly supported once this feature is there.

But it will be some time until this feature is implemented. There is a lot of work that needs to be done before to allow proper support. It will be done in any case, because I am planning to include a new packer that allows merging assemblies (ilmerge style) and if that is done, it's likely required to strip any code that isn't actually needed after merging is done.

[wmjordan]

I am planning to include a new packer that allows merging assemblies (ilmerge style) and if that is done, it's likely required to strip any code that isn't actually needed after merging is done

There's a thing called il-repack, which also uses dnlib to merge assemblies. I currently use it to merge assemblies and remove some types or members with it (by applying a programmer-specific attribute to a type or a member, explicitly--that feature was implemented by me :)), prior to passing the stuff to ConfuserEx.