ionCubeでコンパイルされたコードはどの程度安全ですか？
私は ionCube を使用して、作成したコードを顧客から隠蔽しています。
コード内にパスワードを保存し、ionCubeエンコーダーでそれをコンパイル（暗号化ではない）する場合、潜在的なハッカーがそのパスワードを入手する可能性はありますか？
たとえば、ionCubeでコンパイルされたPHPコードの一部をリバースエンジニアリングすることは可能ですか？
または、完全な暗号化されたソースファイルがある場合、コンパイルされたページで get_defined_vars() のようなコマンドを送信できますか？
はい、コンピュータ内で実行されているものはすべてリバースエンジニアリングすることが可能です。それは常にある時点で常にメモリにロードされ、その時点で暗号化/復号化/解凍/e.t.c。されるため、プロセッサはそのようなコードを処理できます。
あなたのケースでは、変数にハードコードされたパスワードが最終的に使用されます。そして使用できるように、最初は暗号化されていません...
通知：この回答の作成者は、ionCubeと提携しています。 ionCubeの従業員が提出した回答やコメントは、善意をもって、利益相反の対象となる可能性があることに注意してください。
エンドユーザーやほとんどのPHP開発者でさえ知識が不足しているため、「おせっかいな顧客は、コンパイルされたコードから暗号化キーを抽出するのにそれほど問題はないだろう」などの考えが多少伸びますが、ここでの答えは良いです。 PHPエンジンを変更してランタイムデータを有効な方法で公開するために必要です。
バイトコード保護は、コードを別の言語であるバイトコードにコンパイルすることに基づいており、バイトコードとメタデータを発見しにくくし、取得するかどうかを理解するために最善を尽くしています。 ionCubeはコードをコンパイルし、さまざまな手法を使用してバイトコードを保護し、非標準のPHP実行エンジンを使用して、PHPとは異なるバイトコードを使用できるようにします通常生産します。これは、他のいくつかのソリューションと比較すると、ランタイムローダーコンポーネントのサイズが比較的大きいことを説明しています。
PHPのようなget_defined_vars()などの関数を使用すると、同じエンコーダーのコピーによって生成されたエンコード済みファイルでのみ機能するようにファイルをエンコードできるため、失敗する可能性があります。エンコードされたファイルがエンコードされていないファイルに置き換えられた場合。同様に、変数の難読化を使用すると、そのような関数の結果が混乱する可能性があります。
PHPがオープンソースであっても可能なことにはがある制限があります。また、保護の目標とランタイムパフォーマンスのバランスをとる際のトレードオフ、および特に、共有サーバー。たとえば、mysqli_connect()へのパスワードは十分に保護されている場合がありますが、ハッカーはmysqlライブラリまたはPHP mysqliライブラリラッパーを変更し、PHPを再コンパイルして、実行時のパスワード。ただし、これは実際には問題にならない場合があり、デフォルトのPHPインストールとの互換性が不要であれば、セキュリティを強化する方法があります。ユースケースに最も適した戦略を理解するために、ionCubeに連絡してアドバイスを得ることが推奨されます。
あまり安全ではありませんが、外部からの干渉を回避するために使用できます。 100％中50％未満の安全性だと言います。古いバージョンのionCubeを部分的に逆コンパイルするためのインターネット上のツールはたくさんあります。
例- ionCubeデコーダー
コードを保護するために、他の暗号化ツールを選択することをお勧めします。