Before all
哈囉，這是一篇屯了快半年的文章，前幾天收到 Bounty 結果所以可以公開出來惹 XD但是會去識別化
感覺自己今年拆了特別多 APK XD，但通常都是 MitM 抓一下包、找一下各種 Hardcoded 或解 SSL PINNING 之類的過程，剛好這個是打比較仔細的一次想說來講個故事。
另一方面是之前在另一個私人場域報告過這個主題了，很多東西就直接偷簡報吧
真正意義上的 Before all
先來介紹一次這次 Target 的標的
一款類似 Pokemon Go! 的地圖遊戲，不過架構相對簡單就是領寶物而已，值得注意的是 領到的寶物某種意義上直接等價金錢
然後是一款 Android APP，玩家量級大概在 $10^6$ ～ $10^7$
技術性前情提要
這邊使用 BlueStacks 模擬器下載/提取 app，並加上 Burp Suite 做流量側錄，詳細可以看
https://blog.whale-tw.com/2025/02/20/apk-wtf-1/
https://blog.whale-tw.com/2025/03/20/burp-bluestacks/
值得一提的是這次 MitM 的 Binder 我使用的是 sockscap64 工具
接下來將帶大家走入靜態/動態分析的世界！
分析過程
好的，那我們先來做靜態分析，這邊將 APK 拖出後透過 decompile.com、jadx 等工具進行反編譯與拆包。
然後基本上就看到一坨了🤡
我也是沒招了 T_T，來看攔出來的封包吧
登入請求：
開寶箱的請求：
然後就會發現這些看起來很像是簽章的東西 … 格式都長這樣？！
我們來認真思考一下 …
什麼加密方法會長這樣啊，那沒錯！其實就是我們的 DES 系列！
後來我也是想到了一個很好的 grep 方法可以快速定位出可能的相關程式碼，使用 HTTP Header 作為關鍵字 application/json 以及剛剛發現的加密方案 DES，最終鎖定在 /source/rc/e0.java 並循線找到了 /source/d9/f.java
啊哈！
果然剛剛的格式是 密文@密鑰！
既然這樣我們就可以來開始解密過程中的每個欄位了，其中最讓我感到困惑的依然是剛剛的開寶相請求，因為事實上把 signature 解密後會得到…
Decrypt : 1779450268.827181
阿哩喜向？（啊你是誰？）
ok 的，繼續追了一下剛剛 grep 出來的檔案會發現他其實是 經度+緯度+當前的 timestamp + 一個神秘 hardcoded 數字 28552664 + com.google...api.internal.a.I()
其中我追了一下，發現我依然不知道 com.google...api.internal.a.I() 的值是多少
總是追一追就斷了 乁( ˙ω˙ )厂
但蒐集很多組值，把其他已知的值扣一扣後，我發現這個數字居然固定在 220124 ??
這格數字 真的就是 … 好眼熟喔~
戳回去剛剛的 Burp Suite 封包翻了一下，找到改名字的時候送出的請求，原來！是我的 User ID！
至此，我們就可以偽造所有的封包
我有針對參數嘗試進行過各種 injection/ssrf/file upload 等等常見不常見的攻擊，最終發現都沒什麼結果 …
但別忘了一開始提到的，其實只要能穩定的任意開寶箱 + 完成任務，就可以獲得等價金錢的獎勵
利用寶箱地址獲得 api 我可以成功寫自動化程式直接改定位到寶箱位置並完成任務開啟他！
至此，這次的任務已完成！
After all
這篇文章看起來其實一直挺順水推舟的，但實際情況是在分析的過程中，推動的每一步背後可能都藏著無數的猜測、通靈與各式各樣的環境問題，像是我本來還特別作了 anti-ssl pinning 最後才發現自己 proxy server 沒開對 IP TwT，他 ssl pinning 根本做爛了ㄏㄏ
在實戰中要產出一個完整的 Exploit 方向也不竟然是一個這麼容易的過程，雖然這些步驟 + 寫報告大概就花了我一天吧 XD，但主要時間都拿來尋找更有意義的漏洞了。
最近打 PT 的心得感想真的是 app 類真的是一個很大的 Security Edge，像是在另一起 Bounty 遇過 apk 解包後找到以前的 Host， API 接進去就是一整個個資大外洩 + sql injection 2 RCE
還有桌面 .NET APP 解包後翻到一個 json config 檔案目錄，請求後獲得了銀行 Token + 內部系統 IP，進去後又又又又是 SQL Injection 2 RCE
不過這些又都是另外的故事了，基於 NDA 或者我的各種懶惰或者其實就是一些 Old stories 我就不想多提筆撰寫了 XD
好的我現在其實在 NASA 課上
最後他們 patch 的方法是更動態的 key + 速度檢查，基本上應該已經是在風險承擔範圍內可接受的 solution 了，不過未來我總覺得那個 web 肯定可以被打出一些新花樣，只可惜我不熟 ASP.NET …