Java / C＃-リバースエンジニアリングが懸念される場合、AOTをいつ検討する必要がありますか？
長いものと短いものは本当に質問のタイトルにあります。 MSILやJavaバイトコードなどの中間言語にコンパイルする言語の場合、リバースエンジニアリングやセキュリティ機能を無効にするハッキングなどの懸念がある場合は、AOT（事前）コンパイルを行う必要があります。難読化だけでなく考慮されますか？明らかに、私が想像できない答えは1つもないため、この質問には少し揺れ動く余地がありますが、何かを配布する前にAOTコンパイルを実行することと、難読化して送信することを検討し始めるのはいつですか？
これに出くわし、なじみのない人のために：
AOTコンパイラに関するウィキペディアのエントリ： http://en.wikipedia.org/wiki/AOT_compiler
Mono AOTコンパイラ機能： http://www.mono-project.com/AOT
.NETアセンブリ（および、Java .classファイルも）にはある種のハッシュ値が含まれていると思います。classまたはアセンブリのロード時にハッシュ値が失敗した場合は、 、私はそれが拒否され、例外がスローされると信じています。したがって、誰かが16進エディターをアセンブリまたは.classファイルに移動することを決定した場合、ハッシュ値がどのように計算されたかを知り、ファイルのその部分を更新する必要があります。正しい値でも。
さらに、.NETアセンブリは 厳密に名前が付けられている にすることもできます。これは、アセンブリの整合性と来歴を保証するのにも役立ちます。
配布しないでください。 WebまたはCitrixなどを介して公開します。ブルームバーグはそれを行う数十億ドルのビジネスを構築しており、そのユーザーはそれを気に入っています。 （まあ、AOTや難読化ではあまり快適さを提供できないようです）。
難読化だけでなく、AOT（事前）コンパイルを検討する必要がありますか？
おそらくあなたの意図ではありませんが、それは「難読化ではなくAOTコンパイルを使用する必要がある」と解釈できます。これは、AOTコンパイル>難読化を意味します。これは必ずしも当てはまるわけではありません。実際、アセンブリでREを実行する人を少なくともわずかに苛立たせるので、適切な難読化はAOTコンパイルよりも優れていると私は主張します。しかし、長期的には、どちらもあまり役に立ちません。十分な時間があれば、何でも割れる可能性があります。
異なるバージョンを維持することは非常に困難になります。 C++のような言語を使用するか、Javaに固執している場合は、難読化するだけでなく、カスタムクラスローダーを使用できます。すべてのコードは時間とともにREすることができます。私はあなたのためにあなたの仕事をして難読化する法律を信頼します。