Options

Support for System.Reflection.ObfuscationAttribute

yGuyyGuy Posts: 3
edited January 22, 2015 11:17AM in SmartAssembly
Hi,

I cannot find information about whether SmartAssembly supports the standard (mscorlib.dll) .net System.Reflection.ObfuscationAttribute.
If I have a binary third party software that is consistently annotated with these attributes, how can I instruct SmartAssembly to obfuscate all the members in that .dll and honor the ObfuscationAttribute that is present for some classes and members, which may not be obfuscated due to reflection usage.
I have seen that SmartAssembly supports custom attributes, but since this is a binary third party library, adding custom attributes to the existing binary is difficult at least.

Is this really not supported or just not documented well enough? I was not able to find any information about the ObfuscationAttribute in your documentation.

Thank you for your help!

Sebastian
· Share on Twitter

Comments

  • Options
    Jessica RJessica R Posts: 1,319 Rose Gold 4
    Hi Sebastian,

    Thanks for your post and so sorry for the delay!

    I'm sorry to say that the standard ObfuscationAttribute is not supported at the moment. :/

    It is something we think will be technically feasible and we're considering it for the future, but it unfortunately may be a while since it could lead to a potentially confusing change of behaviour for users that we’d need to carefully think out first.

    (A bit more on this: SmartAssembly currently works on the basis of opt-out--it will try to obfuscate everything unless it is explicitly excluded or marked with a DoNotObfuscate attribute. The standard ObfuscationAttribute is, by definition, opt-in -ie, nothing is obfuscated unless marked with the attribute. If for example, if you have an existing project with our DoNotObfuscate attributes and you merge a new third-party DLL containing Obfuscation attributes--should SmartAssembly continue working as opt-in or as opt-out? We'd still have to work out what SmartAssembly would do in cases like these.)

    Sincere apologies for the inconvenience this causes! I've +1'd our feature request to support the attribute though and if there is any update, I will let you know!

    Jessica Ramos | Product Support Engineer | Redgate Software

    Have you visited our Help Center?


    · Share on Twitter
  • Options
    yGuyyGuy Posts: 3
    I disagree with you on your analysis regarding "opt-in" "opt-out". The standard ObfuscationAttribute also works on the basis of opt-out. You can only specify to "Exclude" elements from obfuscation (which is the same as "not obfuscate") with the attribute. So it's basically a "DoNotObfuscate" Attribute with a different name. Other obfuscators that use the standard attribute work just the same as your system. The other way around is not feasible. It's not always possible to enforce obfuscation to just a subset of members (like obfuscate a class name but not the inner classes' names).

    As far as I understand translating the standard attribute to your proprietary attribute should be trivial and you would do your customers the favor and enable them to use your tool with third party libraries. You could even write an attribute processing tool that ildasms the dll, translates the attributes and does the bundling again.
    · Share on Twitter
  • Options
    jpeirsonjpeirson Posts: 1 New member
    Has there been any progress on this as a feature request? Using System.Reflection.ObfuscationAttribute would simplify integration with SmartAssembly for simple use cases, like force include/exclude members from obfuscation.

    For example, I'd expect the following usages to implicitly map to SA attributes:
    [Obfuscation(Exclude = true, ApplyToMembers = true)]  // --> [DoNotObfuscateType]
[Obfuscation(Exclude = true, ApplyToMembers = false)]  // --> [DoNotObfuscate]
[Obfuscation(Exclude = false)] // --> nothing, behaves as if no SA attribute defined
    · Share on Twitter
  • Options
    jpeirsonjpeirson Posts: 1 New member
    Has there been any progress on this as a feature request? Using System.Reflection.ObfuscationAttribute would simplify integration with SmartAssembly for simple use cases, like force include/exclude members from obfuscation.

    For example, I'd expect the following usages to implicitly map to SA attributes:
    [Obfuscation(Exclude = true, ApplyToMembers = true)]  // --> [DoNotObfuscateType]
[Obfuscation(Exclude = true, ApplyToMembers = false)]  // --> [DoNotObfuscate]
[Obfuscation(Exclude = false)] // --> nothing, behaves as if no SA attribute defined
    · Share on Twitter
Sign In or Register to comment.