Почему настолько легко декомпилировать.NET код IL?
Была проблема, задокументированная в посте . Attunity Oracle Conenctor не работает после обновления , в котором выявлена проблема совместимости между версией 5.0 соединителя Oracle и последней версией SSDT (15.9.x по состоянию на 01.02.2009). Пока проблема совместимости не будет решена, де-факто решение заключается в развертывании SSDT версии 15.8.0. Это установит 14.0.3002.113 конструктор служб Microsoft SQL Server Integration Services.
Вот шаги, которые я выполнил для решения:
- Установить 32-битный клиент oracle из центра программного обеспечения
- Установить 64-битный клиент oracle из центра программного обеспечения [117 ] Развертывание файла tnsnames.ora в 32-разрядной установке
- Развертывание файла tnsnames.ora в 64-разрядной установке
- Инструменты данных Microsoft SQL Server, выпуск-15.8.0
- Установка (32-разрядная версия) SSIS Oracle Connector от Attunity версии 5.0
- Установить (64-разрядная версия) SSIS Oracle Connector от Attunity версии 5.0
- Убедитесь, что у вас есть права на чтение и выполнение для обоих элементов 32- и 64-битный каталог клиента
Вот снимки из моей среды ... 
[114 ] Приветствия, Адам
4 ответа
Я думаю, что у Вас уже есть самые важные биты.
- , Как Вы говорите, существует больше доступных метаданных. Я не знаю детали того, что испускается C или компилятором C++, но я подозреваю далекий [еще 110], имена и подобная информация включены в IL. Только посмотрите на то, что декомпилятор знает о том, что находится в конкретном стековом фрейме, например - что касается x86, Вы только знаете, как стек , использовал ; в IL Вы знаете то, что содержание стека представляет (или по крайней мере, тип - не семантическое значение!)
- Снова, как Вы уже упомянули, IL является высокоуровневой абстракцией, чем x86. x86 понятия не имеет, что метод или вызов функции, или событие или свойство и т.д., IL имеет всю эту информацию все еще в нем.
- Обычно C и компиляторы C++ оптимизируют намного в большей степени, чем (говорят) компилятор C#. Это вызвано тем, что компилятор C# предполагает, что большая часть оптимизации может все еще быть выполнена позже - JIT. До некоторой степени имеет смысл для компилятора C# не пытаться сделать много оптимизации, поскольку существуют различные биты информации, которые доступны JIT, но не компилятору C#. Оптимизированный код более трудно декомпилировать, потому что это еще дальше от того, чтобы быть естественным представлением кода первоисточника.
- IL был разработан, чтобы быть скомпилированным в JIT; x86 был разработан, чтобы быть выполненным исходно (по общему признанию через микрокод). Информация, в которой нужен JIT-компилятор, подобна этому, которое хотел бы декомпилятор, таким образом, декомпилятор имеет более легкое время с IL. До некоторой степени это - действительно просто повторное заявление второй точки.
Существует много вещей, которые делают инженерный анализ il довольно легким.
-
информация о Типе. Это крупно. В x86 ассемблере необходимо вывести типы переменных на основе того, как они используются.
-
структура. Информация о структуре приложения более доступна в il дизассемблировании. Это, объединенное с информацией о типе, дает Вам удивительный объем данных. Вы работаете на довольно высоком уровне в этой точке (относительно x86 ассемблера). В собственном ассемблере необходимо вывести структурные макеты (и даже то, что они - структуры) на основе того, как данные используются. Не невозможный, но намного более трудоемкий.
-
имена. Знание названий вещей может быть полезным.
Эти вещи, объединенные, означают, что у Вас есть довольно много данных об исполняемом файле. Il является в основном рабочим на уровне намного ближе к источнику, чем компилятор собственного кода был бы. Более высокий уровень работы байт-кода над, более легкий инженерный анализ, вообще говоря.
C# и IL почти отображаются непосредственный. (Это меньше с некоторыми более новыми функциями C# 3.0.) Близость отображения (и отсутствие оптимизатора в компиляторе C#) делает вещи таким образом 'обратимыми'.
Расширение корректного ответа Brian
, Если Вы думаете весь IL, легко decompilable, я предлагаю писать нетривиальную программу F# и пытаться декомпилировать тот код. F# делает много преобразований кода и следовательно имеет очень плохое отображение от фактического испускаемого IL и исходной кодовой базы. По моему скромному мнению, значительно более трудно посмотреть на декомпилируемый F#, кодируют и возвращают исходную программу, чем это для C# или VB.Net.