Method names compiled in exe?

Question

Do they get class, method, and variable names in MSIL after compiling a Windows application project into EXE?

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

eg. Therefore, if the ARE methods are called through the name:

• Keep names shorter , better performance for named-lookup.
• Keeping cryptic names is more difficult to decompile.

Answer 1

Yes, they are in IL - they launched Reflector , and you will see them. If they did not get into the IL, you could not build against them like libraries. (And yes, you can reference .exe files as if they were class libraries.)

However, all of this is permitted in JIT.

Keep the names readable so you can keep the code in the future. The performance problem is unlikely to make any measurable difference, and if you want to confuse your code, do not do this at the source code level (where you read the code) - do it using a specially created obfuscator.

EDIT: As for the included one - why not just run Reflector or ildasm and find out? From memory, you lose the local variable names (which are in the pdb file if you create it), but more on that. Private method names and private variable names still exist.

Answer 2

Yes Yes. I do not think that there will be a noticeable increase in productivity due to the use of shorter names. There is no gain in readability.

Answer 3

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

Answer 4

Usernames are included in IL regardless of whether they are private or public. In fact, all of your code is also included, and if you use Reflector, you can practically read the entire source code of the application. It remains to debug the application, and I think that there may be tools for this.

You have to FREE (and I can’t stress this anymore) confuse your code if you create packaged applications that have multiple clients and competition. Fortunately, there are a number of obfuscators.

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

Answer 5

• Keep names short, better performance for named-lookup.

How does that matter? I'm not sure how virtual machines look for identifiers, but I'm sure this is not a search for direct string comparisons. That would be the worst way to do this.

• Keep the names cryptic, harder to decompile.

Honestly, I don't think obfuscating the code really helps. Most competent developers there have already developed a “sixth sense” to quickly figure it out, even if identifiers, such as method names, are completely useless, because very often the source code that they need to maintain or improve already has these problems (I'm talking about names methods like "DoAllStuff ()").

In any case, security through obscurity is usually a bad idea .

Answer 6

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

[EDIT]

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

Answer 7

I think they are added, but the length of the name will not affect anything, due to 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 say.