コンパイルされた C は、sudo で「コンパイルされた」Perl バイトコードなどよりもリバース エンジニアリングが難しいと主張するクライアントを持っています。誰でもこれを証明または反証する方法を持っていますか?
2094 次
6 に答える
6
私は perl についてあまり詳しくありませんが、アセンブリにコンパイルされたコードをリバースするのがなぜそれほど醜いのか、いくつかの例を示します。
C コードのリバース エンジニアリングの最も厄介な点は、コンパイルによってすべての型情報が削除されることです。この名前と型の完全な欠如は、IMO の最悪の部分です。
動的に型付けされた言語では、コンパイラはそれに関するより多くの情報を保持する必要があります。特に、フィールド/メソッド/... の名前は、通常、すべての用途を見つけることが不可能な文字列であるためです。
他にも醜いものはたくさんあります。毎回異なるレジスタを使用してパラメータを渡すプログラム全体の最適化など。関数はインライン化されているため、単純な関数の 1 つが多くの場所に表示され、最適化のためにわずかに異なる形式になっていることがよくあります。
スタック上の同じレジスタとバイトは、関数内の異なるコンテンツによって再利用されます。スタック上の配列では特に見苦しくなります。配列の大きさとそれがどこで終わるかを知る方法がないためです。
次に、煩わしいマイクロ最適化があります。たとえば、以前はreturn x/1600. コンパイラは除算が遅いと判断し、定数による除算をいくつかの乗算加算とビットごとの演算に書き直したためです。
于 2011-03-11T20:51:56.147 に答える
2
Perlは本当にリバースエンジニアリングが簡単です。選択するツールは、vi、vim、emacs、またはメモ帳です。
于 2011-03-11T21:11:44.020 に答える
2
なぜ彼らがリバース エンジニアリングを心配しているのかという疑問が生じます。マシン コードを元のソース コードに似たものに戻すことは、通常はバイト コードに戻すよりも困難ですが、ほとんどの悪質な活動には関係ありません。誰かがあなたの秘密をコピーしたり、セキュリティを破ったりしたい場合、元のソース コードの完全な表現に戻さなくても十分に実行できます。
于 2011-03-11T21:24:32.657 に答える
1
わかりました、これについては何年にもわたって十分な議論がありました。ほとんどの場合、結果は決定的なものではありません...主に問題ではないためです。
やる気のあるリバース エンジニアにとって、どちらも同じです。
perl2exe のような疑似 exe メーカーを使用している場合、コンパイルされた C よりも「逆コンパイル」する方が簡単です。perl2exe は perl をまったくコンパイルしないため、少し「隠されている」だけです ( http://www.net-securityを参照)。 .org/vuln.php?id=2464 ; これは本当に古いですが、概念はおそらく同じです (私は調査していないので、確かなことはわかりませんが、私の主張を理解していただければ幸いです) )
実際の製品の保守と開発を賢明かつ持続的に行うことができるように、仕事に最適な言語を検討することをお勧めします。
やる気のある敵対者を止めることは_でき_ない_ことを忘れないでください。自分で書くよりも、元に戻すのに費用がかかるようにする必要があります。
これらの 4 つはそれを困難にするはずです (ただし、不可能ではありません)...
[1] 無意味な計算と複雑なデータ構造の相互作用を行うノイズ コード (ランダムな場所、ランダムなコード) を挿入します (適切に行われた場合、目的が機能ではなくコードを逆にすることである場合、これは大きな頭痛の種になります)。
[2] ビルド プロセスの一部として、いくつかの (異なる) コード難読化ツールをソース コードに連鎖させます。
[3] ハードウェアが存在しない場合にコードの実行を防ぐソフトウェア保護ドングルを適用します。これは、残りの逆転が行われる前に、ドングルのデータへの物理的なアクセスが必要であることを意味します: http://en.wikipedia. org/wiki/Software_protection_dongle
[4] .exe がビルドされた後に (コンパイル方法に関係なく) 保護できるプロテクター (例: Themida http://www.oreans.com/themida.php ) は常に存在します。
... それはリバースに十分な頭痛を与えるはずです。
ただし、これにはすべて費用もかかることを忘れないでください。そのため、達成しようとしていることを常に検討し、選択肢を検討する必要があります。
要するに、どちらの方法も同様に安全ではありません。非コンパイルの perl-to-exe メーカーを使用していない限り、ネイティブ コンパイル済み EXE が優先されます。
これが役立つことを願っています。
于 2011-03-12T01:17:29.493 に答える
1
C は、バイト コンパイルされた Perl コードよりも逆コンパイルが困難です。バイト コンパイルされたすべての Perl コードは逆コンパイルできます。バイト コンパイルされたコードは、コンパイルされた C プログラムのようなマシン コードではありません。コードの難読化手法の使用を提案する人もいました。これらはコードを読みにくくするための単なるトリックであり、Perl ソースの逆コンパイルの難しさには影響しません。逆コンパイルされたソースは読みにくいかもしれませんが、利用可能な多くの Perl 難読化解除ツールと Perl モジュールさえあります。
http://metacpan.org/pod/B::Deobfuscate
Par、PerlAPP、Perl2exe などの Perl パッキング プログラムもソース コード保護を提供しません。Perl がスクリプトを実行できるように、ある時点でソースを抽出する必要があります。ソースでいくつかの暗号化技術を試みる PerlAPP や Perl2exe のようなパッカーでさえ、デバッガーで打ち負かすことができます:
http://www.perlmonks.org/?displaytype=print;node_id=779752;replies=1
誰かがあなたの Perl コードを何気なくブラウジングするのを防ぎますが、パッカーでさえ、スクリプトを実行する前に解凍する必要があります。決心した人は誰でもソースコードを入手できます。
Cの逆コンパイルは、まったく別の獣です。コンパイルが完了すると、マシンコードになります。ほとんどの C 逆コンパイラで最終的にアセンブリ コードになるか、一部の商用 C 逆コンパイラがアセンブリ コードを使用して同等の C コードを生成しようとしますが、それが本当に単純なプログラムでない限り、元のコードを再作成することはほとんどできません。
于 2011-03-12T23:58:13.873 に答える
1
通常、仮想マシンのコードをリバース エンジニアリングする方が簡単です。仮想マシンは通常、言語のターゲットになりやすいように設計されています。つまり、通常、その言語の構造を合理的に簡単かつ直接的に表現します。
ただし、その特定の言語用に設計されていない VM (JVM にコンパイルされた Perl など) を扱っている場合は、実際のハードウェア用に生成されたコードでの作業にずっと近づきます。ソースに合わせてターゲットを設計するのではなく、事前定義されたアーキテクチャをターゲットにするために必要なことは何でもしなければなりません。
于 2011-03-11T21:17:14.673 に答える