CLOVE 後台同官方系統，點樣連起來？完整證據鏈、九個追問同查證教學
2026-09-27 更新： 下文直接開啟管理入口／JS 嘅步驟係歷史記錄，現時入口回傳 401。請改用最新 Wayback 時間線、存檔核對同港澳台退款準備。401 唔代表功能已刪除；原有證據包同簽章保留原樣。
CLOVE 官方程式同後台登入頁用緊同一組公開 Firebase 專案設定，Google 回傳嘅授權網域清單亦都同時列住 clove.jp、oripa.clove.jp 同 clv-admn-next.vercel.app。
重點
- 兩份程式共用專案
clove-v2-prd、專案編號 385949280493。 - 2026-09-05 03:56 UTC 兩份 Google 回應逐位元組相同。
- 保存紀錄列 24 個 Wayback 副本，Arquivo.pt 20 個待確認。
一個管理網址，可以被講成仿站。一張截圖，可以俾人質疑剪裁。但係當公司公告、官方程式、Google 專案設定同較早嘅網頁封存，逐段接上同一條線，問題就唔可以淨係靠一句「同我哋無關」帶過。
呢篇把來源攤開。你可以唔同意本鸚鵡嘅判斷，但係應該有機會自己核對：我哋讀到乜、邊啲資料對得上，同邊一段仲要平台攞紀錄出嚟。
查證基準：2026 年 9 月 5 日。本文所列嘅九種講法係預先分析嘅可能解釋，唔係 CLOVE 已經作出嘅回應。
唔相信？開原始碼自己睇：三步圖解
唔使先信本鸚鵡。開個網址，把個名貼入搜尋框，原始碼就喺眼前。 以下四張都係實際 Chrome 畫面；撳圖可以放大。
第一步：認清後台登入入口，再對 Google 張清單
先開呢個後台登入入口，佢會帶你去登入頁。張圖畀你認清入口；要確認佢同 CLOVE 官方系統嘅關聯，再睇下一張清單。
官方網站同後台登入頁嘅程式，用緊同一組專案設定。Google 回傳嘅同一專案清單，仲同時列出 clove.jp、oripa.clove.jp、clv-admn-next.vercel.app。開 Google 回應嘅保存原件，自己逐個對。呢份資料支持兩邊喺專案設定上有關聯；清單唔係公司擁有權證書。
第二步：直接開兩份公開前端程式
唔使帳號，唔使撳登入。直接開：
- 操作定義：2902-8f2cdd12f9517a68.js——睇完整操作名稱同傳入參數。
- 日本管理頁：list-0f33ebdda397cc72.js——睇頁面點樣提交卡池 ID、讀返結果。
見到密密麻麻嘅字好正常：呢啲就係網站發畀瀏覽器嘅程式文字。唔使改任何嘢，下一步直接搜尋。
第三步：撳 Ctrl＋F，貼入呢個完整名稱
Windows／Linux 撳 Ctrl＋F；Mac 撳 ⌘＋F。貼入下面成段，唔好加空格，再撳 Enter：
scheduleAssignGuaranteedWinOripaUsers操作定義檔搵到 2 處；日本管理頁檔搵到 3 處。 呢個係2026年9月5日本次讀到嘅版本；之後網站換咗檔，可以對返下方原始包嘅保存版本。
個名真係存在，管理頁亦真係有處理佢嘅回傳結果。 呢一步，任何人都可以自己查。後端點揀人、喺邊次付費交易執行，就要再對平台嘅執行同交易紀錄。
圖解同程式讀回日期：2026-09-05。圖片、來源同檔案指紋。今次圖解係新增補充；既有 ZIP 保留各自嘅封存版本同簽章。
先用一間店，把成條線講明白
想像一間店有個你未見過嘅後房。我哋要做五件事：
- 睇店主介紹。 公司自己有冇講過，呢個品牌係自己嘅服務？
- 對表格編號。 店面同後房嘅資料，有冇寫住同一個部門號碼？
- 查登記地址簿。 提供系統嘅 Google，係咪都把兩個地址列埋一齊？
- 翻舊副本。 較早由其他人保存嘅資料，同今日睇到嘅一唔一樣？
- 問工作做過未。 手冊寫住有一項工作，仲要攞值班紀錄，先知幾時做過。
頭四步已經有得逐份打開嘅材料。第五步，要靠實際執行同交易紀錄。同一間店嘅關係接上咗，唔等於已經睇到邊個把邊份獎品交畀邊個。
「店、後房、地址簿」係幫你理解嘅比喻。下面保留真實來源：地址簿對應系統嘅授權跳轉清單，唔可以當成店契或者員工名冊。
打開原始資料同詳細對照
第一條線：公司自己把產品連咗埋一齊
TrustHub 官網把「クローブオリパ」列做旗下服務，連去 oripa.clove.jp。Apple 嘅 Clove 頁面列出供應商 TRUST HUB, K.K.；公司原發公告同 SMBC 2024 年 10 月 15 日公告，一樣支持 TrustHub 同 Clove 產品嘅關係。
呢一步答嘅係「公司同產品有冇關係」。跟住落嚟，先輪到管理網站。
第二條線：官方前台同管理登入頁，指去同一個專案
把 clove.jp 官方程式同管理登入頁程式擺埋一齊，搵得到相同嘅公開 Firebase 設定：
| 識別項目 | 兩份程式嘅共同值 |
|---|---|
| 專案 ID | clove-v2-prd |
| App ID | 1:385949280493:web:224ed7999dd0740cfdc4e4 |
| 認證網域 | clove-v2-prd.firebaseapp.com |
兩份程式嘅公開設定 key 雜湊都一樣，完整對照喺身份包嘅 identity-chain-sources.json。呢啲係公開應用程式嘅專案識別資料。Firebase 文件講明，呢類 key 用嚟識別專案；本身唔可以當成後台登入權限。
有人可以複製一段公開程式。所以，調查唔可以停喺「設定一樣」。下一步先係今次補件嘅關鍵。
第三條線：Google 回傳嘅清單，一樣列咗管理網域
2026 年 9 月 5 日 03:56 UTC，分別用上面兩份程式嘅公開設定識別資料，喺 Google 嘅公開專案設定端點攞到 HTTP 200 回應。兩份回應逐位元組相同，專案編號都係 385949280493。
入面嘅 authorizedDomains 同時包括：
clove.jporipa.clove.jpclv-admn-next.vercel.app
關聯已經延伸到 Google 回傳嘅專案設定。 要把呢個管理網域講成同官方系統完全冇關，就要同時交代：佢點解會出現喺呢個專案嘅授權網域清單。
呢個欄位嘅用途都要講準：Google 定義係登入元件可以跳轉嘅授權網域。佢支持專案設定層面嘅技術關聯，唔會列出公司法律持有人、Vercel 帳戶持有人或者當日操作員。要查到邊個加咗網域、幾時加、邊個控制部署，就要接上 IAM、設定變更同部署歷史。
兩份 Google 原始 JSON 都喺身份包嘅 public-captures/，共用 SHA-256：
7a574650bdfa74f1460bb31500d691ff8d6a386660b56cfe21239675e936228b第四條線：較早嘅第三方封存，令版本有跡可尋
Wayback 喺 2026 年 8 月 23 日 02:14:55 UTC 保存嘅官方 JS，同 9 月 5 日保存嘅官方 JS 逐位元組相同。咁即係話，呢份官方程式唔係今次整理先至出現。
佢嘅 SHA-256 係：
df59333f5c2ff7ff223e7b321575fd86c6d6aaaa86622f84fa9946ecf70204fa管理登入 JS 嘅 9 月 5 日封存一樣同保存原件相同。SMBC 同公司公告另有讀得到嘅副本；Apple 副本讀得到，但係同今次下載嘅內容雜湊唔同，唔可以寫成完全相同嘅原件。
較早嘅官方 JS，唔可以替今日嘅 Google 設定補返成段歷史。每份材料嘅時間，要各自保留。
而家連得到嘅係：公司 → Clove 產品 → 官方程式同管理程式嘅共同專案 → Google 清單入面嘅管理網域。 對呢條鏈有異議，就要指出邊一份來源有錯、邊一段推導唔成立。
身份接上咗，再睇後台究竟做乜
日本、v2、香港同兩個美國庫存管理版本，都有用戶分配排程嘅介面實作。日本管理程式包括揀商品、輸入檢查、提交排程同讀取結果；共用操作定義列出 scheduleAssignGuaranteedWinOripaUsers。跨版本原始連結見主文。
今次完整上下文亦保留咗「アド確定オリパ」提示。嗰段呼叫提交 oripaIds，即係卡池／商品 ID；冇喺呢段操作入面輸入任意中獎者嘅用戶 ID。資格分配係要查清楚嘅具體解釋，唔可以畀函數嘅英文名蓋過。
身份關聯，答嘅係「呢套程式同邊個嘅系統相連」。執行紀錄，先答到「佢做過乜」。 呢個係同一條調查嘅下一段，唔可以攞前一段冒充後一段。
九種可能講法，逐項對照
下面每一項都列出現有材料追問得到嘅地方，同埋把爭議真正講清楚要用邊啲紀錄。平台日後如果回應，應該另附原文、日期同出處，唔好把下列假設改寫成佢講過嘅話。
1.「呢個係仿站，同我哋無關」
好似講「後房唔係我嘅」。咁就請把相同編號同地址簿上面嘅連接，一齊解釋清楚。
打開原始資料同詳細對照
複製品牌外觀，解釋唔到成條關聯。官方 JS、管理 JS 嘅共同專案，加埋 Google 回應入面嘅管理網域，令「完全無關」呢句要有具體說明。核對得到嘅答案係 Vercel 專案同團隊控制紀錄、Google 授權網域變更歷史，同公司同開發商嘅部署關係。淨係講「唔係我哋嘅」，答唔到呢啲資料。
2.「嗰個只係外判、舊版或者測試環境」
好似講「呢個係外判嘅舊工作室」。可以，請攞出佢幾時用過、替邊個做嘢嘅紀錄。
打開原始資料同詳細對照
管理共用程式指去幾個 api.prd.*.clove.jp 主機，亦同官方頁面共用專案設定。呢點令環境用途變成查得到嘅問題。prd 呢個命名本身，仍然證明唔到正式執行；版本對應、部署日期、路由配置同流量紀錄，先判斷得到邊段時間服務乜嘢用途。
3.「截圖或者程式畀你改過」
好似講「你換咗嗰張紙」。咁就把紙嘅原件同其他人保存嘅副本，一張張對。
打開原始資料同詳細對照
請指出檔案、位置同差異。讀者可以把公開包入面嘅原始位元組、SHA-256、當時來源同第三方封存互相比對。對得上嘅 Wayback 副本增加咗獨立比對點；時間戳就固定所簽嘅雜湊。雜湊只證明檔案一唔一致，時間戳唔會替文章嘅推論背書。
4.「只係冇用過嘅程式」
好似講「手冊有寫，但係從來冇做過」。查值班簿同工作紀錄，先知答案。
打開原始資料同詳細對照
而家展示嘅係候選商品查詢、介面檢查、操作呼叫同回應處理連成嘅流程，足夠追問用途。要查有冇執行過，仍然要睇後端 resolver 版本、工作建立同完成紀錄，仲有對應嘅資料表。介面已經整合同曾經執行，應該各用對應資料回答。
5.「只係正常嘅アド確商品資格分配」
好似講「我只係派優惠場嘅入場券」。咁就睇當時公開嘅入場規則，同實際派畀邊個一唔一致。
打開原始資料同詳細對照
呢個解釋有上下文支持，一定要正面核對。請列出揀人規則、資格條件、適用商品 ID、購買限制、付款前嘅公開說明，同分配結果；再講清楚佢同普通獎池嘅邊界。如果紀錄顯示佢只分配已經披露嘅優惠資格，判斷就應該跟住紀錄走。如果用途超出披露範圍，爭點亦會變得清楚。
6.「冇指定得獎者，亦冇付費玩家受影響」
要證明某個客人受影響，就要攞嗰個人嘅收據同結果嚟對。而家仲未有呢條完整對照。
打開原始資料同詳細對照
而家嘅公開材料，冇一條完整嘅交易對照，足以直接駁返呢句話。要把商品 ID、執行時間、工作 ID、分配結果、付款同得獎紀錄連埋一齊，再同玩家付款嗰陣睇到嘅條件比較。公開版本應該匿名化；完整資料可以交畀獲授權嘅獨立審查者核對。唔可以把一個函數名，寫成每個玩家一定輸嘅證明。
7.「封號只係處理多帳戶，唔係滅證」
請人離場，同燒咗佢張收據，唔係同一件事。要查嘅係原因，同紀錄仲喺唔喺度。
打開原始資料同詳細對照
官方條款確實有針對多帳戶呢類情況嘅帳戶措施。所以，封號本身證明唔到報復或者滅證。爭議個案要睇措施時間、具體理由、申訴處理，同交易資料嘅保存、備份同匯出安排。冇咗登入入口，同平台刪晒所有紀錄，係兩件要分開查證嘅事。
8.「只係 AI 分析錯咗」
唔使信分析者個名。打開原件；睇錯咗就改，亦畀其他人接住查落去。
打開原始資料同詳細對照
AI 報告代替唔到來源。呢篇提供嘅係下載得到嘅公開程式、設定回應同封存副本；任何人都可以指出誤讀。之前把 adminSoftDelete 歸去指定日本 list 檔嘅引證，已經撤咗：喺嗰個檔同已經解碼嘅歷史副本入面，搵唔到呢個字串。更正一個錯誤，同時亦要求其餘證據逐項受檢驗。
9.「系統已經改咗」
今日換咗新手冊，舊手冊仲係舊手冊。新舊各寫乜，要按日期對。
打開原始資料同詳細對照
新版本可以改變今日嘅功能，改寫唔到舊版本曾經公開提供嘅內容。比對嗰陣請附更新日期、版本、修改範圍同部署紀錄。刪除或者修改本身，亦唔可以自動當成認錯、報復或者曾經操控抽獎嘅證據。
原始資料、公開分析同封存證明
資料直接擺喺本站。兩個 ZIP 係畀讀者查證嘅公開重整版：原始回應同程式保留原位元組，說明文字重新寫過；內部編輯筆記唔會混入公開稿。包內 DISTRIBUTION.json 逐檔列出保留、重整同省略嘅項目，SHA256SUMS.txt 用嚟核對呢一版內容。
呢啲新 ZIP 各有自己嘅 RFC 3161 時間戳；檔名加上 .tsr 就係對應簽章，.tsq 就係請求。原封存包嘅舊雜湊同舊簽章，另外存喺 prior-seals/，只對應原包，唔可以攞嚟驗證重整之後嘅新 ZIP。最早嘅來源包另外保留來源清單嘅簽章，簽嘅係嗰份清單。
截至今次整理，保存紀錄列出 24 個讀得到嘅 Wayback 來源副本，同一份 Archive.today 歷史文章。歷史文章保留當時嘅文字，更正以現版主文為準。Arquivo.pt 嘅 20 個記錄仲要公開整合確認，Google 設定嘅 Wayback 工作未完成，Perma.cc 冇完成回執；呢啲唔計入保存成功。
唔使靠本鸚鵡，自己落手查
第一步：核對你下載嘅係邊一份
下載 ZIP 同 release.json，比較檔案大細同 SHA-256。Windows 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 憑證同簽署憑證，喺同一個資料夾行：
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 官方方法自己獨立攞憑證。信任基礎係嗰間時間戳機構同佢嘅憑證鏈；呢度冇話用 Bitcoin 錨定。時間戳證明對應嘅雜湊喺簽發嗰陣已經存在，唔證明網站作者身分、實際抽選結果或者指控成立。
最後要接上嘅，係玩家嘅交易
而家，身份關聯已經有得逐段重查嘅材料。真正釐清到玩家有冇受損嘅，係同一批商品嘅規則、分配、付款、結果同帳戶措施紀錄。
如果平台交代得到，就把紀錄擺上枱。如果資料互相矛盾，就指出矛盾喺邊。 呢個係本鸚鵡要求嘅答案，亦係一篇公開調查應該接受嘅檢驗。
本鸚鵡對 CARDZ.GAME 嘅推薦立場同邀請碼披露，放咗喺主文末段。推薦唔可以替 CLOVE 嘅證據加分；同一把尺，一樣用嚟檢視我推薦嘅平台。
常見問題
呢條證據鏈證明咗 CLOVE 操控抽獎未？
未。而家連得到嘅，係公司、Clove 產品、官方同管理程式嘅共同專案 clove-v2-prd，同 Google 授權網域清單。要答「佢做過乜」，仍然要平台交執行同交易紀錄。
我自己點驗份 ZIP？
下載 ZIP 同 release.json，對檔案大細同 SHA-256，再喺包嘅根目錄行 python verify_files.py 核對 SHA256SUMS.txt。時間戳就用同名 .tsr 加 cacert.pem、tsa.crt 行 openssl，見到 Verification: OK 就算過。
封存副本有幾多份？
保存紀錄列出 24 個讀得到嘅 Wayback 來源副本，另加一份 Archive.today 歷史文章。Arquivo.pt 嘅 20 個記錄仲要公開整合確認，Perma.cc 冇完成回執，呢啲唔計入保存成功。
下一步
想睇調查主文，去CLOVE 後台分配同帳戶條款。想睇網紅加成同宣傳鏈，去神抽背後嘅秘密。
資料來源
- TrustHub 官網，核實 2026-09-05
- Google 專案設定保存原件，核實 2026-09-05
- Wayback 保存嘅官方 JS，核實 2026-09-05
- 官方條款，核實 2026-09-05
- 下載清單、SHA-256 同簽章資料，核實 2026-09-05