# CLOVE 後台同官方系統，點樣連起來？完整證據鏈、九個追問同查證教學

**一個管理網址，可以被說成仿站。一張截圖，可以被質疑剪裁。但當公司公告、官方程式、Google 專案設定與較早的網頁封存，逐段接上同一條線，問題就不能只靠一句「與我們無關」帶過。**

呢篇將來源攤開。你可以唔同意本鸚鵡嘅判斷，但應該有機會自己核對：我哋讀到乜、邊啲資料對得上，同邊一段仲要平台攞紀錄出嚟。

[先睇調查主文](/hk/guides/clove-scam/) · [直接下載原始資料](#downloads) · [自己動手查證](#verify)

查證基準：2026 年 9 月 5 日。本文所列的九種說法是預先分析的可能解釋，**並非 CLOVE 已經作出的回應**。

## 先用一間店，把整條線講明白

想像一間店有個你未見過的後房。我們要做五件事：

1. **看店主介紹。** 公司自己有沒有說，這個品牌是自己的服務？
2. **對表格編號。** 店面與後房的資料，有沒有寫同一個部門號碼？
3. **查登記地址簿。** 提供系統的 Google，是否也把兩個地址列在一起？
4. **翻舊副本。** 較早由別人保存的資料，是否與今天看到的一樣？
5. **問工作做過沒有。** 手冊寫有一項工作，還要拿值班紀錄，才能知道何時做過。

前四步已有可以逐份打開的材料。第五步，要靠實際執行與交易紀錄。**同一間店的關係接上了，不等於已經看見誰把哪份獎品交給誰。**

「店、後房、地址簿」是幫助理解的比喻。下面保留真實來源：地址簿對應系統的授權跳轉清單，不能當成店契或員工名冊。

<details>
<summary>打開原始資料與詳細對照</summary>

## 第一條線：公司自己將產品連咗起來

[TrustHub 官網](https://trusthub.jp/)把「クローブオリパ」列為旗下服務，連到 `oripa.clove.jp`。[Apple 的 Clove 頁面](https://apps.apple.com/hk/app/clove/id1631035982)列出供應商 TRUST HUB, K.K.；[公司原發公告](https://prtimes.jp/main/html/rd/p/000000001.000059394.html)及 [SMBC 2024 年 10 月 15 日公告](https://smbc-cf.com/news/data/2024/10/news_20241015.pdf)，也支持 TrustHub 與 Clove 產品的關係。

這一步回答的是「公司與產品有沒有關係」。接着，才輪到管理網站。

## 第二條線：官方前台與管理登入頁，指向同一專案

把 [clove.jp 官方程式](https://clove.jp/_next/static/chunks/pages/_app-087b8d6889c74648.js)與[管理登入頁程式](https://clv-admn-next.vercel.app/_next/static/chunks/pages/signIn-ac96f3ec7e9b1cbe.js)放在一起，能找到相同的公開 Firebase 設定：

| 識別項目 | 兩份程式的共同值 |
| --- | --- |
| 專案 ID | `clove-v2-prd` |
| App ID | `1:385949280493:web:224ed7999dd0740cfdc4e4` |
| 認證網域 | `clove-v2-prd.firebaseapp.com` |

兩份程式的公開設定 key 雜湊也相同，完整對照在身份包的 `identity-chain-sources.json`。這些是公開應用程式的專案識別資料。[Firebase 文件](https://firebase.google.com/docs/projects/api-keys)說明，這類 key 用來識別專案；本身不能當作後台登入權限。

有人可以複製一段公開程式。所以，調查不能停在「設定一樣」。下一步才是這次補件的關鍵。

## 第三條線：Google 回傳的清單，也列了管理網域

2026 年 9 月 5 日 03:56 UTC，分別使用上述兩份程式的公開設定識別資料，從 Google 的公開專案設定端點取得 HTTP 200 回應。兩份回應逐位元組相同，專案編號都是 `385949280493`。

其中的 `authorizedDomains` 同時包括：

- `clove.jp`
- `oripa.clove.jp`
- `clv-admn-next.vercel.app`

**關聯已經延伸到 Google 回傳的專案設定。** 要把這個管理網域解釋為與官方系統毫無關係，就必須同時交代：它為何出現在這個專案的授權網域清單。

這個欄位的用途也要說準：[Google 定義](https://docs.cloud.google.com/identity-platform/docs/reference/rest/v1/TopLevel/getProjects)是登入元件可跳轉的授權網域。它支持專案設定層面的技術關聯，並不列出公司法律持有人、Vercel 帳戶持有人或當日操作員。要查到誰加入網域、何時加入、誰控制部署，就要接上 IAM、設定變更與部署歷史。

兩份 Google 原始 JSON 都在身份包的 `public-captures/`，共用 SHA-256：

```text
7a574650bdfa74f1460bb31500d691ff8d6a386660b56cfe21239675e936228b
```

## 第四條線：較早的第三方封存，讓版本有跡可循

[Wayback 在 2026 年 8 月 23 日 02:14:55 UTC 保存的官方 JS](https://web.archive.org/web/20260823021455id_/https://clove.jp/_next/static/chunks/pages/_app-087b8d6889c74648.js)，與 9 月 5 日保存的官方 JS 逐位元組相同。這表示這份官方程式並非只在本次整理時才出現。

它的 SHA-256 是：

```text
df59333f5c2ff7ff223e7b321575fd86c6d6aaaa86622f84fa9946ecf70204fa
```

[管理登入 JS 的 9 月 5 日封存](https://web.archive.org/web/20260905034032id_/https://clv-admn-next.vercel.app/_next/static/chunks/pages/signIn-ac96f3ec7e9b1cbe.js)也與保存原件相同。SMBC 與公司公告另有可讀副本；Apple 副本可讀，但與本次下載的內容雜湊不同，不能把它寫成完全相同的原件。

較早的官方 JS，不能替今天的 Google 設定補上整段歷史。每份材料的時間，必須各自保留。

**目前可以連起來的是：公司 → Clove 產品 → 官方程式與管理程式的共同專案 → Google 清單中的管理網域。** 對這條鏈提出異議，需要指出哪一份來源有錯、哪一段推導不成立。

## 身份接上了，再看後台到底做甚麼

日本、v2、香港及兩個美國庫存管理版本，都有用戶分配排程的介面實作。[日本管理程式](https://clv-admn-next.vercel.app/_next/static/chunks/pages/oripa/list-0f33ebdda397cc72.js)包含選取商品、輸入檢查、提交排程及讀取結果；[共用操作定義](https://clv-admn-next.vercel.app/_next/static/chunks/2902-1b4cb7dff6c6ef54.js)列出 `scheduleAssignGuaranteedWinOripaUsers`。[跨版本原始連結見主文](/hk/guides/clove-scam/)。

這次完整上下文也保留了「アド確定オリパ」提示。該段呼叫提交 `oripaIds`，即卡池／商品 ID；沒有在這段操作中輸入任意中獎者的用戶 ID。資格分配是需要查清的具體解釋，不能被函數英文名稱蓋過。

**身份關聯，回答「這套程式與誰的系統相連」。執行紀錄，才回答「它做過甚麼」。** 這是同一條調查的下一段，不能用前一段冒充後一段。


</details>

## 九種可能說法，逐項對照

以下每一項都列出現有材料能追問的地方，以及能把爭議真正說清楚的紀錄。平台日後若回應，應另附原文、日期及出處，不把下列假設改寫成它說過的話。

### 1.「這是仿站，與我們無關」

像說「後房不是我的」。那就請把相同編號和地址簿上的連接一起解釋。

<details>
<summary>打開原始資料與詳細對照</summary>

複製品牌外觀，解釋不了整條關聯。官方 JS、管理 JS 的共同專案，加上 Google 回應中的管理網域，使「完全無關」需要具體說明。可核對的答案是 Vercel 專案及團隊控制紀錄、Google 授權網域變更歷史，以及公司與開發商的部署關係。單說「不是我們的」，沒有回答這些資料。

</details>

### 2.「那只是外判、舊版或測試環境」

像說「這是外判的舊工作室」。可以，請拿出它何時使用、替誰工作的紀錄。

<details>
<summary>打開原始資料與詳細對照</summary>

[管理共用程式](https://clv-admn-next.vercel.app/_next/static/chunks/pages/_app-6827489be620db89.js)指向多個 `api.prd.*.clove.jp` 主機，並與官方頁面共用專案設定。這讓環境用途成為可查的問題。`prd` 命名本身仍不能證明正式執行；版本對應、部署日期、路由配置及流量紀錄，才可以判定哪段時間服務甚麼用途。

</details>

### 3.「截圖或程式被你改過」

像說「你換了那張紙」。那就把紙的原件與別人保存的副本，一張張對。

<details>
<summary>打開原始資料與詳細對照</summary>

請指出檔案、位置及差異。讀者可以把公開包內的原始位元組、SHA-256、當時來源及第三方封存互相比對。相符的 Wayback 副本增加了獨立比對點；時間戳則固定所簽雜湊。雜湊只證明檔案是否一致，時間戳不會替文章的推論背書。

</details>

### 4.「只是沒用到的程式」

像說「手冊有寫，但從未做過」。查值班簿與工作紀錄，才知道。

<details>
<summary>打開原始資料與詳細對照</summary>

目前展示的是候選商品查詢、介面檢查、操作呼叫及回應處理連成的流程，足以追問用途。要查是否執行過，仍要看後端 resolver 版本、工作建立與完成紀錄，以及相應資料表。介面已整合與曾經執行，應各用對應資料回答。

</details>

### 5.「只是正常的アド確商品資格分配」

像說「我只是派優惠場的入場券」。那就看當時公開的入場規則，與實際派給誰是否一致。

<details>
<summary>打開原始資料與詳細對照</summary>

這個解釋有上下文支持，必須正面核對。請列出選人規則、資格條件、適用商品 ID、購買限制、付款前的公開說明，以及分配結果；再說清楚它與普通獎池的邊界。若紀錄顯示它只分配已披露的優惠資格，判斷就應跟着紀錄走。若用途超出披露範圍，爭點也會變得明確。

</details>

### 6.「沒有指定得獎者，也沒有付費玩家受影響」

要證明某個客人受影響，得拿那個人的收據與結果來對。現在還沒有這條完整對照。

<details>
<summary>打開原始資料與詳細對照</summary>

目前公開材料沒有一條完整的交易對照，足以直接駁倒這句話。需要把商品 ID、執行時間、工作 ID、分配結果、付款及得獎紀錄連起來，並與玩家付款時看到的條件比較。公開版本應匿名化；完整資料可交由獲授權的獨立審查者核對。不能把一個函數名，寫成每個玩家必輸的證明。

</details>

### 7.「封號只是處理多帳戶，沒有滅證」

請人離店，與燒掉他的收據，不是同一件事。要查的是原因與紀錄還在不在。

<details>
<summary>打開原始資料與詳細對照</summary>

[官方條款](https://clove.jp/terms)確有針對多帳戶等情況的帳戶措施。因此，封號本身不能證明報復或滅證。爭議個案需要措施時間、具體理由、申訴處理，以及交易資料的保存、備份與匯出安排。失去登入入口，與平台刪掉所有紀錄，是兩件需要分別查證的事。

</details>

### 8.「只是 AI 分析錯誤」

不用相信分析者的名字。打開原件；看錯了就改，也讓其他人接着查。

<details>
<summary>打開原始資料與詳細對照</summary>

AI 報告不能替代來源。這篇提供的是可下載的公開程式、設定回應及封存副本；任何人都可以指出誤讀。此前把 `adminSoftDelete` 歸到指定日本 list 檔的引證，已撤下：在該檔及已解碼歷史副本中未找到此字串。更正一個錯誤，同時也要求其餘證據逐項受檢驗。

</details>

### 9.「系統已經改了」

今天換了新手冊，舊手冊還是舊手冊。新舊各寫甚麼，要按日期對。

<details>
<summary>打開原始資料與詳細對照</summary>

新版本可以改變今天的功能，不能改寫舊版本曾公開提供的內容。比對時請附更新日期、版本、修改範圍及部署紀錄。刪除或修改本身，也不能自動當作認錯、報復或曾經操控抽獎的證據。

</details>

<h2 id="downloads">原始資料、公開分析與封存證明</h2>

資料直接放在本站。兩個 ZIP 是供讀者查證的公開重整版：原始回應與程式保留原位元組，說明文字重新編寫；內部編輯筆記不混入公開稿。包內 `DISTRIBUTION.json` 逐檔列出保留、重整及省略的項目，`SHA256SUMS.txt` 用來核對這一版內容。

- [公開來源包：HTTP 回應、JS、WARC 與封存回執](/reports/clove-evidence/clove-sources-public-20260905.zip)
- [身份證據包：Google 設定、公司來源、程式上下文與四份補件](/reports/clove-evidence/clove-identity-public-20260905.zip)
- [五語公開分析稿與核對工具包](/reports/clove-evidence/clove-analysis-public-20260905.zip)
- [下載清單、SHA-256 與簽章資料](/reports/clove-evidence/release.json)

這些新 ZIP 有各自的 RFC 3161 時間戳；檔名加上 `.tsr` 即是對應簽章，`.tsq` 是請求。原封存包的舊雜湊與舊簽章另存於 `prior-seals/`，**只對應原包，不能拿來驗證重整後的新 ZIP**。最早的來源包另保留來源清單的簽章，簽的是該清單。

截至本次整理，保存紀錄列出 24 個可讀 Wayback 來源副本，以及[一份 Archive.today 歷史文章](https://archive.md/lYFbI)。歷史文章保留當時文字，更正以現版主文為準。Arquivo.pt 的 20 個記錄仍待公開整合確認，Google 設定的 Wayback 工作未完成，Perma.cc 沒有完成回執；這些不計入保存成功。

<h2 id="verify">唔使靠本鸚鵡，自己落手查</h2>

### 第一步：核對你下載的是哪一份

下載 ZIP 與 `release.json`，比較檔案大小和 SHA-256。Windows PowerShell 可執行：

```powershell
Get-FileHash -Algorithm SHA256 -LiteralPath .\clove-identity-public-20260905.zip
```

解壓後，在包的根目錄執行隨附的 `python verify_files.py`，逐一核對 `SHA256SUMS.txt`。它只讀本機檔案，不連線，也不執行證據包內的 JS。

### 第二步：沿着來源找到原文

公開來源包從 `capture-manifest.json` 查網址、保存時間、HTTP 狀態及檔案；身份包從 `additional-public-manifest.json` 與 `identity-chain-sources.json` 查起。Apple、公司公告及 SMBC 的部分補件沒有保留下來完整 HTTP 標頭，清單有明寫，不把缺失補成 HTTP 200。

用文字編輯器開啟兩份 JS，搜尋 `clove-v2-prd`、App ID 及認證網域；再開 `public-captures/admin-firebase-public-config.json`，核對 `projectId` 與 `authorizedDomains`。對照 Google 欄位定義，便能自己判斷這條連接能支持甚麼。

### 第三步：讀操作的前後文

在日本 list 檔搜尋 `scheduleAssignGuaranteedWinOripaUsers`、`oripaIds`、`アド確定オリパ` 及 `ユーザーの自動割り当て予約`。看提交參數、候選商品及回應處理，再到共用 chunk 核對操作定義。只截取英文函數名，會漏掉決定用途的上下文。

四份較晚找回的 JS 在 `recovered-missing-entries/`，雜湊與舊清單一致，但取得時間是 9 月 5 日；它們不會被改寫成原包當時已收錄。

### 第四步：核對第三方時間與簽章

Wayback 網址內的 14 位數字是該副本的 UTC 時間。打開實際 replay，核對最後落到的網址與檔案雜湊；提交工作成功不等於已經有可讀副本。動態頁面的 HTML 不同，也不應直接判定造假。

要核對新 ZIP 的時間戳，下載同名 `.tsr`，以及本站提供的 [FreeTSA CA 憑證](/reports/clove-evidence/cacert.pem)和[簽署憑證](/reports/clove-evidence/tsa.crt)，在同一資料夾執行：

```sh
openssl ts -verify -data clove-identity-public-20260905.zip -in clove-identity-public-20260905.zip.tsr -CAfile cacert.pem -untrusted tsa.crt
```

成功結果為 `Verification: OK`。也可以依 [FreeTSA 官方方法](https://www.freetsa.org/index_en.php)獨立取得憑證。信任基礎是該時間戳機構與其憑證鏈；這裡沒有宣稱 Bitcoin 錨定。時間戳證明對應雜湊在簽發時已存在，並不證明網站作者身分、實際抽選結果或指控成立。

## 最後要接上嘅，係玩家嘅交易

現在，身份關聯已有可以逐段重查的材料。真正能釐清玩家是否受損的，是同一批商品的規則、分配、付款、結果與帳戶措施紀錄。

**如果平台能交代，就把紀錄放到桌面上。如果資料互相矛盾，就指出矛盾在哪裡。** 這是本鸚鵡要求的答案，也是一篇公開調查應接受的檢驗。

本鸚鵡對 CARDZ.GAME 的推薦立場與邀請碼披露，放在[主文末段](/hk/guides/clove-scam/)。推薦不能替 CLOVE 證據加分；同一把尺，也用來檢視我推薦的平台。
