リバースエンジニアリング対策 / セキュリティ・ハードニング Reverse Engineering Hardening

Flutter 製 Parky モバイルアプリに対するリバースエンジニアリング（以下 RE）の 現実的な脅威と、Parky として採用する多層防御（Defense in Depth）を記述する。 本書の位置づけは 非機能要件（§10.4 セキュリティ） を補完する「実装・運用ガイド」。ビルドコマンド・外部ダッシュボード設定・リリース前 チェックリストまで踏み込む。

This document covers the realistic reverse-engineering (RE) threats against Parky's Flutter mobile app and the defense-in-depth measures Parky adopts. It complements Non-functional Requirements (§10.4 Security) as an implementation & operations guide — build commands, external dashboard settings, and a pre-release checklist.

11.1 脅威モデル — Flutter AOT の現実 11.1 Threat model — the reality of Flutter AOT

Flutter のリリースビルドは Dart を AOT コンパイルしてネイティブ ARM / x64 バイナリ（Android: libapp.so、iOS: App.framework）に落とす。 React Native や Cordova のように JavaScript がまるごと読めるわけではないが、 完全なブラックボックスでもない。

Flutter release builds AOT-compile Dart into native ARM / x64 binaries (Android: libapp.so, iOS: App.framework). Unlike React Native or Cordova, the JavaScript isn't there to read — but it is not a black box either.

代表的な攻撃ツール Common attack tools

• reFlutter — Flutter engine 自体を patch して通信フック / SSL Pinning bypass。Flutter 界隈の定番。
• Blutter / Doldrums — Dart snapshot をパースしてクラス名・メソッド名・文字列リテラルを復元。
• Frida / objection — 実行時にフック・関数書き換え。
• apktool / Ghidra / IDA Pro — バイナリの静的解析。

• reFlutter — patches the Flutter engine itself for traffic hooking / SSL pinning bypass. The go-to tool in the Flutter scene.
• Blutter / Doldrums — parses the Dart snapshot to recover class names, method names, string literals.
• Frida / objection — runtime hooking and function replacement.
• apktool / Ghidra / IDA Pro — static binary analysis.

クライアントで「見えるもの」の三層 What's visible in the client — three tiers

想定攻撃者と現実的な守備範囲 Attacker profile vs. realistic defense

11.2 対応ロードマップ 11.2 Mitigation roadmap

11.3 リリースビルド手順（必須） 11.3 Release build procedure (required)

リリース提出用のビルドは、必ず mobileapp/prototype/flutter/scripts/build_release.sh （Windows では build_release.cmd）経由で作成する。 手動で flutter build を叩くと --obfuscate や --split-debug-info のつけ忘れでストアに平文バイナリを上げる事故が発生する。

Always produce store-submission builds via mobileapp/prototype/flutter/scripts/build_release.sh (or build_release.cmd on Windows). Running flutter build by hand risks forgetting --obfuscate / --split-debug-info and shipping a plaintext binary to the store.

事前準備 Prerequisites

以下の環境変数を export してから実行する。値は 1Password の PJ｜Parky 配下（Supabase/プロジェクト認証, Mapbox/アクセストークン）から取得。

Export these environment variables before running. Values come from 1Password under PJ｜Parky (Supabase/project auth, Mapbox/access token).

export SUPABASE_URL="https://<project>.supabase.co"
export SUPABASE_ANON_KEY="eyJhbGci..."
export MAPBOX_ACCESS_TOKEN="pk.eyJ1..."
# （任意）BFF baseUrl を dev 以外に向けたい場合
# export PARKY_API_BASE_URL="https://api.parky.co.jp"

実行 Run

# macOS / Linux — Android + iOS 両方
bash scripts/build_release.sh all

# 個別
bash scripts/build_release.sh android   # AAB のみ
bash scripts/build_release.sh ios       # IPA のみ（macOS 限定）

# Windows（Android のみ）
scripts\build_release.cmd

スクリプトがやること What the script does

• flutter pub get
• flutter build appbundle --release --obfuscate --split-debug-info=build/symbols/<ts>/android
• flutter build ipa --release --obfuscate --split-debug-info=build/symbols/<ts>/ios（macOS 時）
• 必要な --dart-define を環境変数から自動で組み立てて注入
• シンボル出力先を JST タイムスタンプ付きで保存（build/symbols/YYYY-MM-DD_HH-MM/）

• flutter pub get
• flutter build appbundle --release --obfuscate --split-debug-info=build/symbols/<ts>/android
• flutter build ipa --release --obfuscate --split-debug-info=build/symbols/<ts>/ios (on macOS)
• Assembles required --dart-define flags from env vars
• Writes symbols to a JST-timestamped dir (build/symbols/YYYY-MM-DD_HH-MM/)

シンボルファイルの運用（重要） Symbol file operations (critical)

11.4 外部ダッシュボード設定チェックリスト 11.4 External dashboard settings checklist

token がバイナリから抜かれても別のアプリ / ドメインから使えなくする設定。 これがダッシュボード側の一度きりの作業で最も費用対効果が高い。

Settings that make extracted tokens useless outside the registered app/domain. One-time dashboard work — highest ROI of any measure here.

11.5 クライアントコードの書き方ルール 11.5 Client-side coding rules

• 秘密鍵・service_role・管理者 token はクライアントに絶対に入れない。値として書かないのはもちろん、assets にも置かない。
• 金額確定 / 権限判定 / 抽選 / ポイント付与 / プロモコード検証は必ずサーバー RPC / BFF で行う。クライアントは UI 表示用の「見せる値」だけを扱う。
• リリースで print() / debugPrint() を残さない。必要な場合は logger パッケージで level を Warning 以上に絞る。
• デバッグフラグ・test hook は kReleaseMode ガードで確実に無効化。
• 機密情報は flutter_secure_storage（Keychain / Keystore）以外に置かない。SharedPreferences は平文なので NG。
• Deep Link のクエリ / パスは受け取ったら必ずバリデーション。パラメータから DB 操作に直結させない。
• debug ビルドを絶対にストアに提出しない（AOT でなく JIT、Dart コードが丸見え）。
• OpenAPI 生成物（lib/generated/parky_api/）にクライアント固有の隠したいロジックを足さない。公開仕様そのものなので隠蔽意味なし。

• Never ship secret keys, service_role, or admin tokens in the client — not in code, not in assets.
• Always do fee confirmation, authorization, lotteries, point grants, and promo-code checks via server RPC / BFF. The client only handles "what we show" values.
• No leftover print() / debugPrint() in release. Use logger with level ≥ Warning when needed.
• Gate debug flags and test hooks with kReleaseMode reliably.
• Sensitive data only in flutter_secure_storage (Keychain / Keystore). SharedPreferences is plaintext — not acceptable.
• Always validate deep link query / path parameters. Never wire them straight into DB ops.
• Never submit a debug build to the stores (JIT, Dart is wide open).
• Don't sneak hide-worthy logic into the generated lib/generated/parky_api/. It is the public spec — obscurity is impossible.

11.6 リリース前チェックリスト 11.6 Pre-release checklist

ストア提出前に以下を全て満たすこと。

Verify every item before store submission.

• ☐ scripts/build_release.sh 経由でビルドした（素の flutter build は使っていない）。
• ☐ build/symbols/<ts>/ を CI artifact / 1Password / Supabase Storage のいずれかに退避した。
• ☐ Mapbox token に URL / Bundle ID 制限が入っている（§11.4）。
• ☐ Supabase 全テーブル RLS enable、anon ポリシーは自分の行のみ。
• ☐ print() / debugPrint() の新規混入が lib/ 直下に無い（generated/ は除外）。
• ☐ kReleaseMode ガードがテスト用 UI / モックデータ切替に付いている。
• ☐ デバッグビルドを間違えて出していない（Flutter は flutter run が JIT なので注意）。
• ☐ 最低バージョンチェックが app_config または Remote Config に設定済み。
• ☐ Sentry / Crashlytics のシンボルアップロードが完了している（クラッシュ解析可能な状態）。

• ☐ Built via scripts/build_release.sh (no bare flutter build).
• ☐ build/symbols/<ts>/ archived to CI artifacts / 1Password / Supabase Storage.
• ☐ Mapbox token has URL / Bundle ID restrictions (§11.4).
• ☐ RLS enabled on every Supabase table; anon policies restricted to own rows.
• ☐ No new print() / debugPrint() under lib/ (excluding generated/).
• ☐ kReleaseMode guards present around test UI / mock-data switches.
• ☐ No accidental debug submission (watch out — flutter run is JIT).
• ☐ Minimum version check configured in app_config or Remote Config.
• ☐ Sentry / Crashlytics symbol upload completed (crash reports decodable).

11.7 将来の強化項目 11.7 Future hardening

• Firebase App Check（Play Integrity + App Attest） 導入 — FCM 導入に相乗りして、Workers BFF 側で App Check token を必須検証にする。
• SSL Pinning（dio_certificate_pinning）— reFlutter で外される前提だが、量産 bot / MITM プロキシ抑止には有効。
• Root / Jailbreak 検出（flutter_jailbreak_detection）— 警告のみ。ユーザー体験を壊さない範囲で。
• 文字列暗号化 — API エンドポイント等のリテラルを実行時まで暗号化（効果は限定的、過剰最適化の典型）。
• Play Integrity / App Attest 直接統合 — App Check を使わず個別統合する場合のオプション。

• Firebase App Check (Play Integrity + App Attest) — ride along with FCM integration; require App Check tokens on the Workers BFF.
• SSL Pinning (dio_certificate_pinning) — assumed bypassable by reFlutter but still blocks mass bots / MITM proxies.
• Root / Jailbreak detection (flutter_jailbreak_detection) — warning only; keep UX intact.
• String encryption — encrypt API-endpoint literals until runtime (limited gain; the classic over-optimization).
• Direct Play Integrity / App Attest integration — alternative if not using App Check.