では、アプリケーションと同じ (またはそれ以上の) 特権レベルを持つプロセスがアプリケーションを操作できないようにしようとしていますか?
それは失敗する運命にあるタスクです。セキュリティチェックを追加した場合、攻撃者がisSecure()メソッドを単純なreturn true;.
要件を明確にする必要があると思います (少なくとも、探しているものを理解するのに苦労しています)。
セキュリティ関連の分野では、問題に取り組み始める前に、常に次の 2 つの質問に答える必要があります。
あなたの場合、Java クライアントのクラス ファイルが変更されないように保護しようとしていると思います。その場合、答えは (潜在的な) 攻撃者が何をできるかによって異なります。
攻撃者が実際にクライアントが実行されているマシンの管理者権限を持っている場合、基本的に何もできません。上記の saua が指摘しているように、実行しているシステムを信頼できない場合は、運命にあることになります。
攻撃者がクライアント マシンに到達する前にしかクラス ファイルを変更できない場合、JAR ファイルに署名することで、クライアントはその操作を検出できます。
代わりにjarファイルに署名したいですか？
カスタム Transformer を追加することで、Intrumentation を介して必要なことが可能になるはずです。http://java.sun.com/j2se/1.5.0/docs/api/java/lang/instrument/package-summary.htmlを参照してください。
クラスが定義されたときにバイトコードを取得するため、カスタムクラスローダーも仕事をします。
誰かが私のクライアントを改ざんしたかどうかをサーバー側で検出するにはどうすればよいですか?
それはいけません。インターネット上では、あなたが犬かどうかは誰もわかりません ;-)
真剣に: クライアントに関する仮定を行うためのサーバー側の唯一のオプションは、ネットワーク経由で送り返される情報にあります。プロトコルを暗号化し、リバース エンジニアリングを十分に困難にすることで、侵入者によるクライアントのハッキングを困難にすることができますが、不可能ではありません。
NGSCB (以前は Palladium と呼ばれていました) は、これをより安全にするように設計されていますが、これには独自の問題があります。
独自のクラスローダを作成して手動でチェックするか、コードに署名して Java ランタイムに任せることができます。
jar に署名すると、コードが変更されないように保護されます。署名には、秘密鍵に基づく署名の作成が含まれます。公開鍵は、これらの署名とともに jar に埋め込まれています。Java は公開鍵に対して署名を検証し、変更されたクラスのロードを拒否します。
ハッキングされたクライアントを防ぐのは少し難しくなります。まず、攻撃者はプロトコルをリバース エンジニアリングする必要があります。Java難読化ツールを使用してこれを防止するための一歩を踏み出すことはできますが、最終的に攻撃者は通信を監視し、トラフィックからプロトコルをリバース エンジニアリングすることができます。クライアントとサーバーの通信を暗号化したとしても (SSH や HTTPS などの既に暗号化を行っているプロトコルを使用することを考えると、これは簡単ではありません)、最終的には中間者攻撃を受けやすくなります。 .
一体何を守ろうとしているのですか？
クライアントでは、jar内のクラスファイルへのパス名を使用してgetResourceAsStreamを呼び出すことができます。
それはあなたの質問の一部に答えます（「どうすればバイトコードを取得できますか」）。他の答えは、より大きな問題をうまくカバーしています。