Имена методов компилируются в EXE?

Question

Включают ли имена классов, методов и переменных в MSIL после компиляции проекта Windows App в EXE-файл?

• Для запутывание - меньше имен, сложнее для обратного инжиниринга.
• И для производительности - более короткие имена, более быстрый доступ.

например, Так что, если методы вызываются по имени:

• Сохранение имен коротких , улучшенная производительность для именованного поиска.
• Хранить имена загадочно , сложнее декомпилировать.

Answer 1

Да, они в ИЛ - запустите Отражатель и вы их увидите. Если они не окажутся в IL, вы не сможете создать против них библиотеки. (И да, вы можете ссылаться на файлы .exe, как если бы они были библиотеками классов.)

Однако все это решается один раз в JIT.

Сохраняйте имена для чтения , чтобы вы могли сохранить код в будущем. Проблема с производительностью вряд ли изменит какую-либо измеримую разницу, и если вы хотите запутать свой код, не делайте этого на уровне исходного кода (где вы тот, кто прочитайте код) - сделайте это с помощью специального обфускатора.

РЕДАКТИРОВАТЬ: Что касается того, что включено - почему бы просто не запустить Reflector или ildasm и узнать? Из памяти вы теряете имена локальных переменных (которые находятся в файле pdb, если вы его создаете), но это все. Имена частных методов и имена частных переменных все еще там.

Answer 2

Да, они делают. Я не думаю, что при использовании более коротких имен будет ощутимый прирост производительности. Нет никакого способа, которым усиление преодолевает потерю читабельности.

Answer 3

Если вас беспокоит запутывание, проверьте .NET Reactor. Я протестировал 8 различных обфускаторов, и Reactor был не только самым дешевым коммерческим, он был вторым лучшим из множества (самый лучший из них, Dotfuscator Gold).

[EDIT]

На самом деле, теперь, когда я думаю об этом, если все, что вас волнует, это запутывание имен методов, то тот, который поставляется с VS.NET, Dotfuscator Community Edition, должен работать нормально.

Answer 4

• Держите имена короткими, лучше производительность для именованного поиска.

Как это могло повлиять? Я не уверен, как идентификаторы ищутся виртуальной машиной, но я почти уверен, что она не выполняет прямой поиск сравнения строк. Это был бы худший из возможных способов сделать это.

• Сохраняйте загадочные имена, их сложнее декомпилировать.

Если честно, я не думаю, что запутывание кода так сильно помогает. Большинство компетентных разработчиков уже разработали «шестое чувство» для быстрого выяснения вещей, даже если идентификаторы, такие как имена методов, абсолютно бесполезны, поскольку очень часто исходный код, который им нужно поддерживать или улучшать, уже имеет эти проблемы (я говорю об именах методов как "DoAllStuff ()").

В любом случае, безопасность через неизвестность обычно является плохой идеей .

Answer 5

Имена участников включаются в IL независимо от того, являются ли они частными или открытыми. На самом деле весь ваш код тоже включен, и если вы используете Reflector, вы можете практически прочитать весь исходный код приложения. Осталось отладить приложение, и я думаю, что для этого могут быть инструменты.

Вы должны АБСОЛЮТНО (и я не могу подчеркнуть это больше) запутывать свой код, если вы создаете упакованные приложения, которые имеют множество клиентов и конкурентов. К счастью, есть несколько доступных обфускаторов.

Это основная проблема, с которой я столкнулся .Net. Поскольку MS проделывает такую ​​большую работу над этим, почему бы не разработать (или не приобрести) профессиональный обфускатор и не сделать его частью VS. Dotfuscator просто не сокращает его, не версию, которую они имеют для сообщества.

Answer 6

Локальные переменные не включены в MSIL. Поля, методы, классы и т. Д. Переменные основаны на индексе.

Answer 7

Я думаю, что они добавлены, но длина имени ни на что не повлияет, из-за способа поиска имен функций. Что касается запутывания, я думаю, что есть инструменты (Dotfuscator или что-то подобное), которые в основном делают именно то, что вы говорите.