本文へ移動
Fizor LogoFizor/

FIZOR DOCUMENTATION

手動Luraph保護リリース

このガイドは、管理者がライセンス制Scriptを手動でLuraphへ渡し、検証済みの成果物だけを公開するPhase 1の手順です。FizorはLuraphを自動操作せず、Luaをサーバー上で実行しません。

前提と制限

  • Phase 1の手動Luraph保護はライセンス制Scriptだけで利用できます。free for allのScriptでは選択できません。
  • MANUAL_LURAPHのreleaseは、保護成果物を配信できない場合にraw sourceへフォールバックしません。
  • Executorへ配信されたartifactは観測、保存、変更され得ます。難読化と実行時認証は取得を完全に防止する仕組みではありません。
  • Fizorが生成するのは認証ランタイムを注入したprepared.luaまでです。実際のLuraph処理は管理者が外部で行います。
  • prepared.luaや難読化済みartifactへ、ライセンスキー、Loader/runtime token、署名秘密、LuraphやFizorのmanagement keyを追加しないでください。公開origin、release/build IDなどの公開識別子だけを含めます。

公開フロー

状態は次の順に進みます。

text
保護モードを選択
  → raw sourceからreleaseを作成
  → prepared.luaを生成・保存
  → 管理者がLuraphで手動処理
  → 同じreleaseへartifactをアップロード
  → 管理者専用staging Loaderで検証
  → READY
  → publish

1. 保護モードとreleaseを作成する

  1. AdminのScript一覧で対象Scriptの「リリース」を開きます。
  2. 「保護モード」で「手動Luraph」を選びます。free for allが有効なら、先にライセンス制へ変更してください。
  3. UTF-8のraw .luaファイル（最大1 MiB）をアップロードしてreleaseを作成します。バージョンは自動採番されます。

保護モードを変更しても、既存releaseへ保護成果物は後付けされません。対象モードで新しいreleaseを作成してください。

2. prepared.luaを生成する

  1. 対象releaseのbuild IDを記録します。
  2. 「注入済みLuaを生成」を実行します。
  3. 画面に外部HttpGetまたはloadstringの警告が出た場合、そのreleaseをLuraphへ渡さないでください。依存Luaをbundleへ取り込むか、依存先と実行内容を確認してraw sourceを修正し、新しいreleaseからやり直します。
  4. 状態が「難読化待ち」になったら「prepared.luaを保存」でダウンロードします。
  5. 画面のprepared SHAと、対象releaseのバージョンおよびbuild IDを作業記録へ残します。

prepared.luaにはraw sourceだけでなくFizorの認証ランタイムが含まれます。raw source単体をLuraphへ送っても、保護releaseとして公開できる正しいartifactにはなりません。

3. Luraphで手動処理する

保存したprepared.luaを管理者がLuraphへ手動で送ります。FizorからLuraph APIを呼ぶ処理や、実Luraphの自動検証はPhase 1にありません。

作業を並行する場合は、入力ファイル、Luraph出力、Fizorのrelease ID、build IDを一組として管理してください。別release用のLuraph成果物を取り違えてアップロードしないでください。

4. artifactをアップロードする

  1. Luraphの出力がLuaファイルであることを確認します。
  2. 入力に使ったprepared.luaと同じrelease行で「難読化済みLuaをアップロード」を選びます。
  3. アップロード後、状態が「検証中」になり、artifact SHAとサイズが表示されることを確認します。

公開済みartifactは置き換えられません。修正が必要なら新しいbuildを持つreleaseを作成し、prepareからやり直します。

Phase 1の管理画面にはbuildを破棄して再生成する専用操作はありません。 「難読化待ち」の同一buildは「注入済みLuaを生成」を再実行して同じ prepared.luaを再保存できます。upload後または検証後にbuild自体を やり直す場合は、新しいreleaseを作成してprepareから再開してください。 専用の破棄・再生成UIとrelease.protection.discard監査は後続phaseで追加します。

5. stagingで検証する

  1. 「ステージングLoaderを発行」を実行します。
  2. 表示されたLoaderを、管理者だけが操作する検証用Executorで実行します。
  3. 期待する機能と終了処理を確認し、artifact内の認証ランタイムがrelease/build IDをattestして状態がREADYになるのを待ちます。

staging Loaderは短命かつ一回限りです。Fizorが生成するstaging Loaderには一時tokenが含まれますが、そのtokenをartifact、prepared Lua、別のLoaderへ転記しないでください。Loader本文やtokenをチケット、チャット、ログへ貼らず、期限切れまたは使用済みなら新しく発行します。

staging中にartifactが開始したtask、接続、UIなどは検証終了時に停止し、検証用Executorの状態を破棄してください。FizorサーバーはLuaを実行して安全性や動作を検査しません。

6. READY後に公開する

MANUAL_LURAPHのreleaseはREADYになった後だけ「公開」を実行できます。DRAFT、AWAITING_OBFUSCATION、VERIFYING、FAILEDからのpublishは拒否され、raw sourceも代替配信されません。

通常利用者はStable Loaderを、実行時にscript_keyを渡して起動します。

lua
script_key = "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"
loadstring(game:HttpGet("https://example.com/loader/<script-id>.lua"))()

script_keyは利用者が実行時に渡すライセンスキーです。配布するartifactや固定のLoader sourceへ実値を埋め込まないでください。Loader sessionとruntime authorizationは短命かつ一回限りで、再利用は拒否されます。

失敗、再試行、rollback

staging attestationに失敗するとartifactはFAILEDになります。

  1. 失敗したstaging Loaderを破棄し、再利用しません。
  2. release/build ID、Luraphへ渡した入力、出力を照合します。
  3. 同じraw sourceを再処理する場合もprepared.luaを再保存し、正しいreleaseの成果物として再アップロードします。
  4. raw sourceや依存関係を直す場合は新しいreleaseを作成します。

公開後に問題が見つかった場合は「直前版へロールバック」を使用します。rollback先は、以前にstaging検証を通過して公開されたartifactだけに限定してください。未検証artifactやraw sourceを緊急フォールバックとして公開してはいけません。rollbackは既存runtime sessionを失効させるため、利用者は新しい認証で再読み込みします。

作業後はローカルのprepared.lua、Luraph出力、staging Loader、clipboard履歴を組織の保管方針に従って削除またはアクセス制限し、Lua本文、キー、token、署名、nonceをログや監査メモへ残さないでください。

次に読む