views:

658

answers:

7

Do class, method and variable names get included in the MSIL after compiling a Windows App project into an EXE?

  • For obfuscation - less names, harder to reverse engineer.
  • And for performance - shorter names, faster access.

e.g. So if methods ARE called via name:

  • Keep names short, better performance for named-lookup.
  • Keep names cryptic, harder to decompile.
+3  A: 

Yes, they do. I do not think that there will be notable performance gain by using shorter names. There is no way that gain overcomes the loss of readability.

Serhat Özgel
Does private member names also get included?
Statement
Statement: Yes, they do.
DrJokepu
+13  A: 

Yes, they're in the IL - fire up Reflector and you'll see them. If they didn't end up in the IL, you couldn't build against them as libraries. (And yes, you can reference .exe files as if they were class libraries.)

However, this is all resolved once in JIT.

Keep names readable so that you'll be able to maintain the code in the future. The performance issue is unlikely to make any measurable difference, and if you want to obfuscate your code, don't do it at the source code level (where you're the one to read the code) - do it with a purpose-built obfuscator.

EDIT: As for what's included - why not just launch Reflector or ildasm and find out? From memory, you lose local variable names (which are in the pdb file if you build it) but that's about it. Private method names and private variable names are still there.

Jon Skeet
JIT compiling?! Isn't that how JavaScript is executed? Isn't that the worst case because you have ALL members names available to the reverse engineer+
Jenko
If you are really that surprised that .NET uses JIT compiling, I suggest you read more on .NET before using C#. And yes, you can reverse engineer code - you can do that in any language (theoretically). You can also obfuscate code, so its not like all .NET code is practically open source.
Spodi
The virtual method table is initially populated only with a pointer to the JIT compiler itself, until the runtime first calls the method, then the JIT compiler figures out where the methods code is, and replaces the call to JIT with offset to actual code. This could be different for each machine.
Charles Bretana
... (con't ) There is a great explanatuion for how all this works in Don Box's book "Essential .Net" ...
Charles Bretana
Or in Jeffrey Richter's "CLR via C#" which is also excellent.
Jon Skeet
the two bibles every .Net programmer should read !!!
Charles Bretana
+1  A: 

Local variables are not included in MSIL. Fields, methods, classes etc are. Variables are index based.

Michiel
Like Jon Skeet says, "From memory, you lose local variable names... private variable names are still there."
Jenko
Exactly what I saw after posting my message...
Michiel
A: 

I think they're added, but the length of the name isn't going to affect anything, because of the way the function names are looked up. As for obfuscation, I think there are tools (Dotfuscator or something like that) that basically do exactly what you're saying.

GWLlosa
+1  A: 

Member names do get included in the IL whether they are private or public. In fact all of your code gets included too, and if you'd use Reflector, you can practically read all the source code of the application. What's left is debugging the app, and I think there might be tools for that.

You must ABSOLUTELY (and I can't emphasize it more) obfuscate your code if you're making packaged applications that have a number of clients and competition. Luckily there are a number of obfuscators available.

This is a major gripe that I have with .Net. Since MS is doing so much hard work on this, why not develop (or acquire) a professional obfuscator and make that a part of VS. Dotfuscator just doesn't cut it, not the version they've for community.

Cyril Gupta
Identify your threat model first: What do you expect people to do with unobfuscated code that you don't want them to? While it's nice to believe you have some super awesome code that everyone wants to reverse engineer, practically nobody does. If you do, you shouldn't send it to your customers.
Nick Johnson
+1  A: 
  • Keep names short, better performance for named-lookup.

How could this make any difference? I'm not sure how identifiers are looked up by the VM, but I'm pretty sure it's not doing a straight string comparison lookup. This would be the worst possible way to do it.

  • Keep names cryptic, harder to decompile.

To be honest, I don't think code obfuscation helps that much. Most competent developers out there have already developed a "sixth sense" to figure out things quickly even if identifiers like method names are totally unhelpful since very often the source code they need to maintain or improve already has these problems (I am talking about method names like "DoAllStuff()").

Anyway, security through obscurity is usually a bad idea.

DrJokepu
Using .NET Reflector any first year CS student could figure out your code. Not obfuscating is the equivalent of releasing your app as open source. Open source is not practical for many commercial apps. Either obfuscate or go the extra half-step and make your app open source.
mhenry1384
mhenry1384: No matter how you obfuscate your executable, any competent programmer could easily figure it out. You can generate your code at runtime, which would raise the bar a little bit but not much. Just like most copy protected games get cracked days after being released.
DrJokepu
No, I don't think obfuscation is not worthwhile.
Cyril Gupta
@Cyril Gupta: Could you elaborate your point please?
DrJokepu
mhenry1384: No it's not, because it's not _licensed_ as open source. Just because your users can read the (decompiled) code if they want doesn't mean they can legally do anything with it. And the only difference here between .NET and native code is the difficulty of decompiling.
Nick Johnson
+1  A: 

If you are concerned about obfuscation check out .NET Reactor. I tested 8 different obfuscators and Reactor was not only the cheapest commercial one, it was the second best of the bunch (the best was the most expensive one, Dotfuscator Gold).

[EDIT]

Actually now that I think of it, if all you care about is obfuscating method names then the one that comes with VS.NET, Dotfuscator Community Edition, should work fine.

mhenry1384