C #을 네이티브로 컴파일 하시겠습니까?

C #을 네이티브로 컴파일 하시겠습니까?

---

.NET 바이트 코드를 네이티브 코드로 컴파일하는 것에 대해 다소 혼란 스럽거나 최종 결과에 대해 혼란 스러울 수 있습니다. 그러니 내가 이해한다고 생각하는 것을 분류하려고 노력할 때 참아 주시면 내가 놓친 것이 무엇인지 알아낼 수 있도록 도와주세요.

내가하고 싶은 것은 C로 작성한 애플리케이션을 C로 작성 했을 때 얻을 수있는 일반 네이티브 코드로 컴파일 하는 것입니다. 내 추론은 성능과 관련이 없지만 어느 정도의 보호와 관련이 있습니다. 나는 나의 최종 목표가 피하는 것이 불가능하지 않다는 것을 이해합니다. 그러나 나는 x86 어셈블리를 뒤집는 것이 Reflector가 제공하는 것을 뒤집는 것보다 더 어렵다고 느낍니다.

지금 내 C # 애플리케이션을 Reflector에 넣으면 기본적으로 소스 코드를 다시 가져옵니다. 일반적으로 관리되지 않는 C / C ++ 애플리케이션을 IDAPro에 넣고 HexRays 디 컴파일러를 사용할 때 동일한 수준의 디 컴파일을 얻지 못하며 논리 흐름을 이해하기 위해 x86 디스 어셈블리를 거쳐야합니다. HexRays가 디 컴파일을 시도하는보다 간결한 네이티브 코드 대신 MSIL에있는 응용 프로그램으로 인해 Reflector에서 이러한 훌륭한 디 컴파일이 발생한다는 것을 알고 있습니다.

나는 여전히 .NET 런타임이 필요한 클라이언트 컴퓨터에 대해 걱정하지 않으며, 그 중 어느 것도 우회하려고하지 않습니다. upx내 프로그램에서와 같은 일반 소프트웨어 난독 화 프로그램을 실행하고 싶습니다 . .NET 바이너리가 실패하면 수행합니다.

이 관련 질문 에서 ngen내가 원하는 것을 이해 하는 것이 었습니다. 나는 ngen. 그러나 C:\Windows\assemblies\...\applicationName.ni.exe디렉토리에서 다른 곳으로 출력 파일을 복사 한 후 두 번 클릭하여 실행하려고하면 "유효한 Win32 응용 프로그램"이 아니라는 오류가 발생합니다. 또한 applicationName.ni.exeReflector에을 던지면 applicationName.exe. applicationName.ni.exe은 네이티브 코드 여야 하므로 Reflector에서 오류가 발생할 것으로 예상했지만 그렇지 않았습니다. 이것이 내가 이것을해야하는 방식이라면 왜 Reflector가 여전히 나에게 그렇게 큰 디 컴파일을 줄까요?

그래서, 내 주요 질문을 다시 요약하면 : Reflector가 그렇게 쉽게 디 컴파일하지 않을 네이티브 바이너리로 .NET 프로그램을 어떻게 컴파일 할 수 있습니까? 또는 초보자 리버스 엔지니어로부터 .NET 언어로 작성된 제품을 보호하기위한 몇 가지 모범 사례는 무엇입니까?

다른 도구가 필요하면 Codewall 같은 것이 아닌 무료를 선호합니다 .

감사!

업데이트 : 내가 찾고있는 것이 Reflection과 같은 언어의 일부 기능을 제한 할 수 있다는 것을 이해하지만 나는 괜찮다고 생각합니다. 내 코드 중 어떤 것도 명시 적 Assembly.Load호출이나 그런 종류의 작업을 수행하지 않습니다 . 하지만 GetProcAddress/LoadLibrary어차피 전화 로 대체 할 수 는 없나요?

---

방금 VS2015 및 Windows 8.1 에서 .Net Native의 유효성을 검사하고 (올바르게 구성된 경우 .proj를 검사하여 유효성 검사) 특정 아키텍처 (과잉 일 수 있음, 유효성 검사하지 않았을 수 있음) 용으로 빌드하면 기본 파일이 생성되어 " 내가 찾고있는 "코드 를 리버스 엔지니어링하기가 더 어렵다. DotPeek (JetBrains의 무료 .Net 디 컴파일러)를 통해 .dll 을 읽을 수 없습니다."

---

그것은 ngen.exe가 작동하는 방식이 아닙니다. .ni.exe 또는 .ni.dll 모듈을 생성하기 위해 JIT 컴파일러를 실행합니다. 이 바이너리 파일에는 메타 데이터가 포함되어 있지 않으며 메서드 본문에 대해 IL에서 생성 된 기계 코드 만 포함됩니다. CLR은 여전히 ​​원래 어셈블리를 찾아야합니다. 그래야만 사용할 수있는 ngen-ed 이미지가 있는지 확인할 수 있으므로 어셈블리의 IL에서 생성하는 대신 기계 코드를 사용할 수 있습니다.

Ngen.exe는 앱의 웜 시작 시간을 단축합니다.

내 어셈블리를 분해하는 데 관심이있는 모든 사람에게 일반적인 조언은 sourceforge.net을 가리키는 것입니다. 일반적으로 나보다 나은 프로그래머가 작성하고 유지 관리하는 테라 바이트의 소스 코드가 있습니다. 때로는 좋은 의견도 있습니다. 난독 화기가 제대로 작동하지 않으면 더 나은 것을 찾으십시오. 많이있다.

---

어제 Build 2014 에서 Microsoft는 .NET Native . FAQ 에 따르면 "... 처음에는 .NET Native를 사용하는 Windows Store 앱에 중점을두고 있습니다. 장기적으로는 모든 .NET 응용 프로그램에 대한 기본 컴파일을 계속 개선 할 것입니다."

---

코드를 보호하려면 난독 화자가 일반적인 접근 방식입니다. Dotfuscator 는 한동안 리플렉터와 함께 군비 경쟁을 해왔고 우리는 우리 제품에 그것을 사용합니다. 그러나 실제로 숙련 된 사람은 난독 화 된 코드를 쉽게 읽을 수 있습니다.

네이티브 코드로 컴파일하면 관리 언어를 사용하려는 목적이 무효화됩니다. 주요 이점은 타겟 런타임이 IL을 타겟 CPU에 가장 적합한 것으로 JIT 할 수 있도록하는 것입니다. 그렇지 않은 경우 mono 의 Ahead-of-time 옵션 과 같은 것을 사용할 수 있습니다 .

---

Spoon (이전 Xenocode)에는 귀하의 요구에 맞는 제품이 있습니다 . WPF 기반 설치 프로그램 UI에 사용하므로 설치 프로그램 자체를로드하기 위해 .net을 부트 스트랩 할 필요가 없습니다.

---

NGEN은 네이티브 코드를 추가하지만 MSIL을 제거하지는 않습니다. 따라서 MSIL에서 작동하는 모든 도구는 계속 작동 할 수 있습니다. 리플렉션을 위해서도 이것이 필요합니다. 진정한 네이티브 컴파일러에게는 매우 어려울 것입니다.

---

이것은 조용하고 좋은 무료 난 독기입니다 : eazfuscator

---

이것은 마침내 Microsoft의 .NET Native 컴파일러를 사용하여 가능합니다.

관리 코드 (C # 또는 Visual Basic)로 작성되고 .NET Framework 및 Windows 10을 네이티브 코드로 대상으로하는 앱의 릴리스 버전을 자동으로 컴파일합니다.

..

• 앱은 네이티브 코드의 우수한 성능을 제공합니다.

• C # 또는 Visual Basic으로 계속 프로그래밍 할 수 있습니다.

• 클래스 라이브러리, 자동 메모리 관리 및 가비지 수집, 예외 처리를 포함하여 .NET Framework에서 제공하는 리소스를 계속 활용할 수 있습니다.

앱 사용자에게 .NET Native는 다음과 같은 이점을 제공합니다.

• 빠른 실행 시간

• 일관되게 빠른 시작 시간

• 낮은 배포 및 업데이트 비용

• 최적화 된 앱 메모리 사용

그러나 .NET 네이티브는 네이티브 코드에 대한 컴파일 이상을 포함합니다. .NET Framework 앱이 빌드되고 실행되는 방식을 변화시킵니다. 특히:

• 미리 컴파일하는 동안 .NET Framework의 필수 부분이 앱에 정적으로 연결됩니다. 이를 통해 앱은 .NET Framework의 앱 로컬 라이브러리와 함께 실행되고 컴파일러는 전역 분석을 수행하여 성능을 향상시킬 수 있습니다. 결과적으로 앱은 .NET Framework 업데이트 후에도 지속적으로 더 빠르게 시작됩니다.

• .NET 네이티브 런타임은 정적 사전 컴파일에 최적화되어있어 우수한 성능을 제공 할 수 있습니다. 동시에 개발자가 매우 생산적이라고 생각하는 핵심 반사 기능을 유지합니다.

• .NET Native는 정적 사전 컴파일 시나리오에 최적화 된 C ++ 컴파일러와 동일한 백엔드를 사용합니다.

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

이것은 VS.NET 2015에서만 사용할 수 있습니다.

---

뒤로 물러서서 왜 이런 유형의 보호를 찾고 있는지 물어볼 수 있습니다. 보호가 필요하지 않다고 주장하는 것은 아니지만 동기를 이해할 가치가 있다고 생각합니다.

예를 들어, 누군가가 리버스 엔지니어링하면 보안에 치명적인 알고리즘이 시스템에 있기 때문에 보호를 원하는 경우 다른 접근 방식을 고려해야 할 수 있습니다. 이는 알고리즘에 결함이 있으며 난독 화 또는 네이티브 컴파일이 도움이되지 않음을 의미합니다.

If is a matter of IP, then I think obfuscation is probably your best approach here. It is kind of like putting a lock on your door. Someone can break the lock and get in, but they are intentionally doing it as opposed to just walking in the door.

---

This is possible using the IL2CPU compiler. IL2CPU is developed by the same people who make COSMOS (C# Open Source Managed Operating System) and is only available by downloading cosmos. IL2CPU produces ASM files which can be compiled through Nasm (some other assemblers may work but it is best to use nasm). the only problem with IL2CPU is that it is built in to the Cosmos Project and it is quite difficult to get it to run on its own.

---

Other answers mention Microsoft's .NET Native compiler but do not tell you how to do that.

Here is a tutorial using CoreRT on how to compile your C# project to native code.

Note: I also had to comment out the following line for everything to work:

<!-- <add key="helloworld" value="https://api.helloworld.org/v3/index.json" /> -->

The output is a roughly 4MB sized executable:

Indeed, the code is no longer readable with .NET decompilers and IDA Pro (a native code disassembler) recognizes it as native code.

참고URL : https://stackoverflow.com/questions/1921656/compiling-c-sharp-to-native