Компиляция C# собственному компоненту?

Я думаю, что несколько смущен компиляцией байт-кода.NET к собственному коду, или возможно я смущен конечным результатом. Поэтому терпите меня, поскольку я пытаюсь отсортировать то, что я думаю, что понимаю, таким образом, можно помочь мне выяснить то, что я пропускаю.

То, что я хотел бы сделать, скомпилировать мое приложение, записанное в C# вниз к обычному собственному коду как, я добрался бы, если я записал это в C. Мое обоснование не имеет никакого отношения к производительности, а скорее с определенной степенью защиты. Я понимаю, что моя конечная цель не является невозможной (или даже действительно настолько трудной) обойти, но я просто испытываю желание инвертировать x86 блок, является более трудным, чем инвертирование, что Отражатель дает мне.

Прямо сейчас, если я бросаю свое приложение C# в Отражатель, я в основном возвращаю свой исходный код. Обычно, когда я бросаю свои неуправляемые приложения C/C++ в IDAPro и использую декомпилятор HexRays, я не вполне получаю ту же степень декомпиляции назад, и я должен обратиться к прохождению посредством x86 дизассемблирования для понимания логического потока. Это - мое понимание, что такая большая декомпиляция прибывает из Отражателя из-за приложения, находящегося в MSIL вместо более краткого собственного кода, который HexRays пытается декомпилировать.

У меня нет опасений по поводу клиентской машины, все еще нуждающейся во времени выполнения.NET, я не пытаюсь обойти любое из этого. Я хотел бы запустить нормальные программы путаницы программного обеспечения как upx на моей программе и выполнении его, поскольку перестал работать двоичный файл.NET.

Это было мое понимание от этого связанного вопроса это ngen делает то, что я хочу. Я попытался использовать ngen. Но после копирования выходного файла от C:\Windows\assemblies\...\applicationName.ni.exe каталог где-нибудь я могу дважды щелкнуть, и пытающийся работать он производит ошибку об этом не быть "действительным приложением Win32". Далее, когда я бросаю applicationName.ni.exe в Отражатель я получаю тот же вывод, как я сделал от просто applicationName.exe. С тех пор applicationName.ni.exe как предполагается, собственный код, я ожидал Отражатель к ошибке, но это не сделало. Если это способ, которым я, как предполагается, делаю это, почему Отражатель все еще давал мне такую большую декомпиляцию?

Так, только для суммирования моего основного вопроса снова: Как я могу скомпилировать свою программу.NET в собственный двоичный файл, который не будет так легко декомпилировать Отражатель? Или то, каковы некоторые лучшие практики для защиты продукта, записанного на языке.NET от новичка, перепроектирует?

Если бы мне нужен другой инструмент, я предпочел бы что-то свободное и не что-то как Codewall.

Спасибо!

ОБНОВЛЕНИЕ: Я понимаю, что то, что я ищу, могло бы ограничить некоторые функции языка как Отражение, но я думаю все хорошо с этим. Ни один из моего кода не делает никого явного Assembly.Load вызовы или что-либо вида. Но не могли они просто быть замененными GetProcAddress/LoadLibrary вызовы так или иначе?

64
задан Community 23 May 2017 в 12:02
поделиться

5 ответов

ngen.exe работает не так. Он просто запускает JIT-компилятор заранее для создания модуля .ni.exe или .ni.dll. Этот двоичный файл не содержит метаданных, а только машинный код, сгенерированный из IL для тел методов. CLR все еще должен найти исходную сборку. Только тогда он сможет определить, что существует образ ngen-ed, чтобы он мог использовать машинный код из него, а не генерировать его из IL сборки.

Ngen.exe ускоряет время горячего запуска вашего приложения, то есть все.

Мой обычный совет всем, кто может быть заинтересован в дизассемблировании моих сборок, - указать их на sourceforge.net. Он имеет терабайты исходного кода, написанного и поддерживаемого программистами, которые обычно лучше меня. Иногда даже с хорошими комментариями. Если ваш обфускатор не Работать хорошо, а потом присмотреться к лучшему. Их много.

29
ответ дан 24 November 2019 в 15:51
поделиться

Spoon (ранее Xenocode ) есть продукт, который может удовлетворить ваши потребности . Мы используем его для пользовательского интерфейса установщика на основе WPF, поэтому нам не нужно загружать .net, чтобы загрузить саму программу установки.

8
ответ дан 24 November 2019 в 15:51
поделиться

Если вы хотите защитить свой код, обычно используется обфускатор. Dotfuscator какое-то время находится в гонке вооружений с отражателями, и мы используем его в наших продуктах. На практике, однако, опытный человек может легко прочитать запутанный код.

Компиляция в собственный код лишает смысла наличие управляемого языка. Основное преимущество заключается в том, чтобы позволить целевой среде выполнения JIT-кодировать IL в нечто оптимально приемлемое для целевого ЦП. Если вы хотите иначе, вы можете использовать что-то вроде опции опережения в моно .

17
ответ дан 24 November 2019 в 15:51
поделиться

NGEN добавляет собственный код, но не удаляет MSIL. Следовательно, любой инструмент, работающий с MSIL, по-прежнему может работать. Это также необходимо для отражения, что было бы очень сложно для настоящего собственного компилятора.

7
ответ дан 24 November 2019 в 15:51
поделиться

Я могу отступить и спросить, зачем вам нужен этот тип защиты. Я не пытаюсь утверждать, что вам не нужна защита, но я думаю, что стоит понять мотивацию.

Например, если вам нужна защита, потому что у вас есть алгоритм в вашей системе, где было бы разрушительно безопасность, если кто-то перепроектировал его, вам может потребоваться другой подход. Это означает, что в алгоритме есть изъян, и никакое обфускация или нативная компиляция вам здесь не помогут.

Если дело касается IP, то я думаю, что обфускация, вероятно, ваш лучший подход. Это все равно, что запереть вашу дверь. Кто-то может взломать замок и войти внутрь, но он делает это намеренно, а не просто входит в дверь.

4
ответ дан 24 November 2019 в 15:51
поделиться
Другие вопросы по тегам:

Похожие вопросы: