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

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

12 голосов
/ 10 сентября 2011

Если я генерирую сборку, нормально ли, что 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сборка.Это нормально?.

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

Пожалуйста, помогите мне понять это «маленькое что-то», которого я здесь упускаю.

Ответы [ 2 ]

14 голосов
/ 10 сентября 2011

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

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

EDIT

После установки .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 не требуется для выполнения, метаданные нужны, потому что все строки и другие соответствующие данные, которые нужны программе, содержатся в метаданных. Итак, Нген копирует все метаданные в раздел .IL собственного исполняемого файла и копирование кода IL в качестве запоздалой мысли

4 голосов
/ 10 сентября 2011

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

...