Можем ли мы разобрать (используя ILDasm) NGen-ed сборку?

Если я NGen сборки, нормально ли, что ildasm все еще разбирает его?

Ok. Я написал библиотеку классов HelloWorld, а последующая dll называется NGenILDasmTest.dll. - > Целевое для .Net fw 4.

Из командной строки Vs 2010 я сделал

gacutil -i NGenILDasmTest.dll

Я видел сборку, установленную в GAC. И я побежал ildasm, чтобы я мог посмотреть на IL. Пока все хорошо.

Затем я запустил

ngen NGenILDasmTest.dll

(Я не указал никаких параметров для ngen). И эта сборка успешно скомпилирована. Я нашел его с именем NGenILDasmTest.ni.dll в папке

C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9

Теперь, когда я запускаю ildasm, как показано ниже

ildasm "C:\Windows\Assembly\NativeImages_v4.0.30319_32\NGenILDasmTest\81d49dd4c7df22fb3df530402b58ffc9\NGenILDasmTest.ni.dll"

Я мог видеть содержимое сборки Ngen-ed. Это нормально?.

С технической точки зрения, Ngen генерирует собственные процессоры для IL (и, по-видимому, помещает его под C:\windows\Assembly\NAtiveImages_V4. ##### _ 32 - в моем случае). Если это так, как я могу видеть сборку NGen-ed как IL с использованием ILDasm?

Пожалуйста, помогите мне понять, что "немного чего-то", что мне здесь не хватает.

Ответ 1

Сборник NGEN'ed является собственным кодом IL плюс. ИЛ не удаляется. Часто возникает путаница в том, что сборки NGen содержат только собственный образ. Исходная информация по-прежнему необходима для метаданных.

Microsoft, похоже, не имеет очень конкретной информации о внутренних компонентах сборки NGen. Большая часть информации, которую мы знаем, относится к обратному проектированию.

ИЗМЕНИТЬ

После установки .NET Framework 1.1 (yay..) - похоже, что .NET 1.1 NGen лишает IL. Похоже, что начиная с v2 - IL хранится. Похоже, что существует противоречивая информация, лежащая вокруг. Точная причина этого изменения не кажется известной.

Существует хорошая статья о некоторых внутренних функциях ngen (и о том, как это очень плохая идея для обфускации) здесь: http://www.woodmann.com/forum/entry.php?68-Rebuilding-native-.NET-exes-into-managed-.NET-exes-by-Exploiting-lefotver-IL...

Теперь интересная вещь о Ngen заключается в том, что она не устраняет IL или метаданные, потому что в то время как код IL не нужен для выполнения, метаданные есть, потому что все строки и другие соответствующие данные о том, что потребности программы содержатся в метаданных. Итак, Ngen копирует все метаданные в .IL-раздел родного exe и копирует IL-код в качестве запоздалой мысли

Ответ 2

Если вы посмотрите на быстрое/простое обфускацию, напишите сборку смешанного режима в С++, которая будет загрузчиком вашей собственной сборки (она загрузит устаревшие .NET FW 4.0 через COM в собственный код и использует общедоступные интерфейсы объявленный из управляемой части, trough.tlb, сгенерированный для вашей управляемой сборки), хранящийся как зашифрованный ресурс (с использованием RSA), и шифрует собственный код на С++, а затем подписывает обе сборки. Это предотвратит запуск ILDASM вашей сборки, позволяя вам отлаживать и строить проект (используя события сборки)