Luaエグゼキューターが特別に厄介な理由
ファイブエムのチートの多くはC/C++のDLLとして存在し、従来の注入モジュールのシグネチャスキャンで検出できます。Luaエグゼキューターは違います。ファイブエムの正規のスクリプティングランタイムの中で任意のLuaを実行するため、ほとんどの静的チェックからは正規のゲームスクリプトとまったく同じに見えます。エグゼキューターのバイナリに対するシグネチャスキャンは役に立ちますが、そのバイナリは小さく、頻繁に書き直され、簡単に再パッケージできます。検知はランタイム層でも行う必要があります。
ローダーへのシグネチャ検知
最初の防衛線は、ローダーのプロセスと、ローダーがファイブエムにマップするDLLに対するシグネチャ検知です。Ravenのシグネチャパックは最も活発なローダー系統を追跡し、1〜7日の頻度で更新されます。これで手を抜いたエグゼキューターはすぐに捕まり、残りもリリースのたびに再パッケージを強いられます。その分だけ時間を稼げます。
ランタイムの整合性チェック
ローダーのシグネチャに加えて、RavenはLuaランタイム自体の整合性も検証します。どのネイティブハンドラーがパッチされたか、どのイベント登録が存在するか、グローバルなLua状態に外部のテーブルが追加されていないかを監視します。エグゼキューターはペイロードを届けるために、通常これらのうち少なくとも1つを差し込む必要があるため、ローダーのバイナリ自体が未知でもこの層でフラグが立ちます。
安全網としてのサーバーサイド検証
ローダーのシグネチャとランタイムのチェックの両方をバイパスできたとしても、エグゼキューターはその権限で何かをしなければならず、それは通常、正規のスクリプトなら起こさないサーバーイベントを発生させることを意味します。サーバーサイドのイベント検証層（/how-it-works/event-validationを参照）は、許可されていない発信元からのイベントをブロックし、妥当な範囲を外れたペイロードを拒否します。Lua経由の所持金付与、アイテムの複製、車両スポーンの氾濫、プレイヤーのテレポートは、すべて同じ検証ゲートに突き当たります。
Luaエグゼキューターの検知に「完了」がない理由
エグゼキューターの作者はローダーを絶えず書き直します。1つシグネチャが出るたびに、そのリリースの顧客をまるごと失うからです。検知は継続的です。今日動いているエグゼキューターは1〜7日で検知され、その利用者はグローバルBANデータベースに入ります。更新履歴の2026-04-21の勧告エントリーが最近の例で、Redengineのイベント発火パターンを、クライアント側のチェックがすべてバイパスされても動くルールとしてサーバー側で塞いだ事例です。