CODEWITHSUNDEEP
c#obfuscation
RenniePet
RenniePet

Reputation: 11658

Which C# method names should not be obfuscated?

I'm working on a C# obfuscation program, and I'm wondering if there are method names that are "hardwired" into the framework and should therefore not be modified. The ones that spring to mind are .ctor, .cctor and Dispose. Are there any others I should avoid modifying?

Edit: To elaborate, and inspired by Paul Alexander (thanks for your answer), I'm doing this by modifying the IL source code. Here are some typical(?) .method statements:

  .method family hidebysig virtual instance void 
          Dispose(bool disposing) cil managed

  .method private hidebysig instance void 
          InitializeComponent() cil managed

  .method public hidebysig specialname rtspecialname 
          instance void  .ctor(class [mscorlib]System.Collections.Generic.List`1<string> twoLetterWords) cil managed

  .method private hidebysig static string[] 
          CreateStringArray() cil managed

I can see that the constructor (.ctor) has a "rtspecialname" option, and Dispose has a "family" option. Is this the sort of thing I should be looking out for?

Upvotes: 0

Views: 2743

Answers (5)

logicnp
logicnp

Reputation: 5836

There are many criteria which should be used to determine when methods should not be renamed:

  • Methods overridding virtual methods from the .Net Base Class Library.
  • ctor and cctor
  • Methods marked specialName and rtSpecialName and runtime.

and some more like exlcuding public methods if obfuscating a dll.

BTW, I am curious as to whether you are doing this as a learning experience or for your own use. If the latter, I would tell you that its better to use a commercial obfuscator instead of spending time on this (focus on your core functionality instead!).

Disclaimer: I work at LogicNP Software, the developers of Crypto Obfuscator

Upvotes: 1

Alexei Levenkov
Alexei Levenkov

Reputation: 100547

More on methods/classes used via reflection: beware of framework or target application using reflection to dicover types and methods. I.e. in ASP.Net MVC classes for processing requests are picked up by name, in SharePoint a lot of third party classes are referenced by name - as result one should not obfuscate particular class names in assembly to be used with such application.

I'd go with approach other obfuscators are using - custom attributes to control obfuscation and separate externally configurable lists of classes/methods that should not be obfuscated. It is impossible to correctly guess what methods can and cannot be obfuscated in general case. I.e. obfuscating public method names is possible only if you know all callers - not always the case.

Upvotes: 1

Paul Alexander
Paul Alexander

Reputation: 32367

The meta data for a given method contains a "special name" flag on methods that cannot be renamed which you can use as a basic heuristic. However to accurately determine the eligibility of a method you have to walk the entire inheritance tree, accounting base classes, interfaces, methods/properties referenced by attribute strings, etc.

Upvotes: 1

Marc Gravell
Marc Gravell

Reputation: 1062820

Don't obfuscate anything to do with serialization unless the names are explicitly stated via attributes; and even then take care - some serializers include type names in the metadata (which may not match for long).

Watch out for convention-based methods; for example ShouldSerializeFoo() and ResetFoo() (twinned with property Foo) - these conventions are common in both serializers and the ComponentModel. There is also a FooHasValue convention for some serializers.

And anything that is going to use reflection is likely doomed... ;p

Upvotes: 2

Darin Dimitrov
Darin Dimitrov

Reputation: 1038820

You should definitely avoid modifying any public method in a public class. Also avoid modifying property getters and setters (get_XXX and set_XXX methods).

Upvotes: 2

Related Questions