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

Question

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

Хорошо. Я написал библиотеку классов 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. Это нормально?.

Technically speaking, Ngen generates native CPU instrcutions for the IL (and apparently places it under C:\windows\Assembly\NAtiveImages_V4.#####_32 - in my case). If that is the case, how am I still able to see the NGen-ed assembly as IL using ILDasm?

Please help me understand that 'little something' that I am missing here.

Answer 1

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

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

РЕДАКТИРОВАТЬ:

После установки.NET Framework 1.1 (да..) - кажется, что.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 собственного исполняемого файла и копирует код IL как запоздалую мысль.

Answer 2

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