В поисках утилиты, которая шифровала бы IL код(обфускатор) я набрел на такую утилиту(protector):
http://www.remotesoft.com/salamander/protector.html
Она заменяет в сборках IL код на native не трогая метаданные. Соответственно у меня сразу возникли такие вопросы:
как такое приложение может выполняться? Ведь сборки с native кодом не могут быть работоспособными в силу следующих причин:
Когда приложение запускается, то и CLR и JIT компилятор подразумевают, что в сборке IL код. И JIT сканирует сборку и начинает компилировать необходимый код в native, предполагая, что он компилирует IL код, а так мы ему подсуним native код.

Как тогда будут происходить дела с межплатформенностью???
Ведь благодаря JIT компилятору и IL коду, нам не надо задумываться об архитектуре платформы, и платформенно зависимый native код генерируется с учетом архитектуры данного компьютера, на котором запустили приложение.
А тут в сборке не будет IL кода, JIT не будет компилировать native код с учетом под конкретную платформу(потому что ему нечего будет компилировать), и native код, который создаст эта утилита в сборке не будет межплатформенным.
Ну и межъязыкового взаимодействия между сборками тоже не будет.
может кто прояснить ситуацию?

IMHO, всё предельно просто:
1. Метаданные остаются для описания сборки, хотя, возможно, они слегка изменяются
2. Можно даже предположить, что утилита просто берёт файл из ГАКа
3. IMHO, на межплатформенность можно вообще положить - я не видел ни одной .NET проги под юникс. А может кто-нибудь видел такие?
4. Различия в архитектуре компьютера - наверное идёт адаптация под PIII или PII
Не знаю как сейчас, но раньше все эти адаптации были достаточно убогими.

Цитата

Ну и межъязыкового взаимодействия между сборками тоже не будет.

А там и так его нет. Взаимодействие происходит в рамках одного языка - IL.

Цитата

А там и так его нет. Взаимодействие происходит в рамках одного языка - IL.

Ну вот о том и речь, если бы взаимодействие происходило в пределах IL, то если в сборке native код, то взаимодействия бы не было.
Но взаимодействие просиходит из-за метаданных. Поэтому межъязвковое взаимодействие остается.

Цитата

я не видел ни одной .NET проги под юникс. А может кто-нибудь видел такие?

Я видел.
DotGNU project
Mono project
вполне рабочие проекты .Net под Linux, и это только те, о которых я слышал.
ссылка на скриншоты DotGNU :
http://www.gnu.org/projects/dotgnu/screenshots.html

Цитата

IMHO, всё предельно просто

Оказалось, что это не так.

На самом деле JIT не сканирует код. В начале все (почти все) указатели в таблицах методов (или как они называются) указывают на точку входа в JIT, который компилирует код и изменяет указатель в таблице, чтобы он указывал на скомпилированный код.
Т.е. в таблицах метаданных, в которых находится и сам IL код, указатель для каждой ячейки таблицы с IL кодом указывает на точку входа в JIT. И когда кусок кода IL среда хочет скомпилировать, она просто дергает за этот указатель, и для этого куска кода срабатывает JIT. Поэтому, если в сборках(точнее в ее таблицах)содержится не IL код, а native, то адрес указателя для определенного куска native кода уже указывает не на точку входа в JIT, а сразу на себя, потому что это уже готовый скомпилированный код, и тем самым мы не вызываем JIT для компиляции этого куска кода, а зразу исполняем его. Правильно?
Везде пишут, что JIT сканирует код перед тем как его начать компилировать и определяет какие сборки необходимо еще загрузить. Но ведь такого быть не может. Ведь он компилирует только IL код, а IL код содержит только инструкции, поэтому даже просканировав IL код, нельзя определить какие типы нам понадобятся и какие сборки для этого надо загрузить. Это определяет CLR.

Цитата(Gazon @ 14.1.2005, 15:49)

Поэтому, если в сборках(точнее в ее таблицах)содержится не IL код, а native, то адрес указателя для определенного куска native кода уже указывает не на точку входа в JIT, а сразу на себя, потому что это уже готовый скомпилированный код, и тем самым мы не вызываем JIT для компиляции этого куска кода, а зразу исполняем его

Если я тебя правильно понял, то данная утилитка не только скрывает данные из сборок, она также позволяет повысить производительность .NET-приложения. Я имею в виду, что первый запуск приложения будет происходить не медленнее, чем последующие, так как код уже откомпилирован в native, следовательно компилировать его "на лету" нету смысла. И еще скомпилированый код будет храниться в самой сборке, а не в системном кэше, что убережет его от удаления.

И еще такой вопрос. Эта утилита при компиляции IL в native использует системный JIT или собственные алгоритмы?

Всегда полезно читать ФАК:

Цитата

How does remotesoft protector work? Microsoft .NET assemblies are easy to decompile because they use Common Intermediate Language (CIL), which contains enough information for reverse engineering. Our protector does not use CIL code, instead, it emits pseudo-native code, and thus can not be decompiled. At run time, pseudo-native code is transformed to native format.To make it even more secure, the pseudo-native code is also encrypted.

Не думаю чтобы это было эффективнее IL.

Еще у них одна хорошая утилита есть: вырезает только необходимое для твоей программы из .NET framework и линкует вместе с твоей программой. Таким образом твоя программа возрастает в объеме не очень сильно, но программа не требует установки .NET framework.

Цитата

Всегда полезно читать ФАК:

......
Во дают.
А на главной странице утилиты вот как они объясняют про утилиту:

Цитата

Our protector is not an obfuscator, rather it converts the decompilable Microsoft Intermediate Language code (MSIL or CIL) of your assemblies into native format while keeping all .NET metadata intact, and thus it provides the same level of protection as native C/C++ code. Further more, it offers code, string and resource encryption, and therefore, it provides even better protection than native C/C++ code.

А из Faq'a выясняется, что это никакой не native код, а всего-лишь псевдо-native, который всего лишь скрывает IL и он во время исполнения программы также компилится JIT'ом в native.
Ух как я зол.

Это сообщение отредактировал(а) Gazon - 14.1.2005, 18:27