Компилирование C # для Native? - PullRequest
62 голосов
/ 17 декабря 2009

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

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

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

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

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

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

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

Спасибо!

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

Ответы [ 11 ]

29 голосов
/ 17 декабря 2009

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

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

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

20 голосов
/ 15 июня 2015

Я просто проверен .Net Native на VS2015 & Windows 8.1 (при правильной настройке проверьте .proj для проверки) и сборка для конкретной архитектуры (может быть излишней, не проверенной) создаст собственный файл, который даст вам код " сложнее для обратного инжиниринга ", который вы ищете, который я не смог прочитать .dll через DotPeek (бесплатный декомпилятор .Net от JetBrains).

17 голосов
/ 03 апреля 2014

Вчера, в Build 2014 , Microsoft объявила о .NET Native . Согласно FAQ , «... Изначально мы ориентируемся на приложения Магазина Windows с .NET Native. В долгосрочной перспективе мы продолжим улучшать собственную компиляцию для всех приложений .NET».

16 голосов
/ 17 декабря 2009

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

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

8 голосов
/ 17 декабря 2009

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

7 голосов
/ 17 декабря 2009

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

5 голосов
/ 08 сентября 2010

это бесплатный обфускатор, который тихо хорош: eazfuscator

4 голосов
/ 29 октября 2015

Наконец-то это возможно, используя Microsoft .NET Native compiler

Он автоматически компилирует версию выпуска приложений, написанных в управляемом коде (C # или Visual Basic) и предназначенных для .NET Framework и Windows 10, в собственный код.

..

• Ваши приложения будут обеспечивать превосходную производительность нативного кода.

• Вы можете продолжить программирование на C # или Visual Basic.

• Вы можете продолжать пользоваться ресурсами, предоставляемыми .NET Framework, включая библиотеку классов, автоматическое управление памятью и сборку мусора, а также обработку исключений.

. Для пользователей ваших приложений .NET Native предлагает следующие преимущества:

• Быстрое время выполнения

• Постоянно быстрое время запуска

• Низкие затраты на развертывание и обновление

• Оптимизированное использование памяти приложения

Но .NET Native включает в себя не только компиляцию в нативный код. Он преобразует способ создания и выполнения приложений .NET Framework. В частности:

• Во время предварительной компиляции необходимые части .NET Framework статически связаны с вашим приложением. Это позволяет приложению работать с локальными библиотеками приложений .NET Framework, а компилятор - выполнять глобальный анализ, чтобы обеспечить выигрыш в производительности. В результате приложения запускаются стабильно быстрее даже после обновлений .NET Framework.

• Среда выполнения .NET Native оптимизирована для статической предварительной компиляции и, таким образом, способна обеспечить превосходную производительность. В то же время он сохраняет основные функции отражения, которые разработчики считают столь продуктивными.

• .NET Native использует ту же серверную часть, что и компилятор C ++, который оптимизирован для сценариев статической прекомпиляции.

https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx

Доступно только в VS.NET 2015.

4 голосов
/ 17 декабря 2009

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

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

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

3 голосов
/ 04 августа 2013

Это возможно при использовании компилятора IL2CPU. IL2CPU разработан теми же людьми, которые делают COSMOS (C # Open Source Managed Operating System) и доступны только при загрузке космоса. IL2CPU создает файлы ASM, которые можно скомпилировать через Nasm (некоторые другие ассемблеры могут работать, но лучше использовать nasm) единственная проблема с IL2CPU заключается в том, что он встроен в Космос, и его довольно сложно запустить самостоятельно.

...