如何防止 Android App 被反編譯後介面泄露？

01-04

apk如何進行混淆或者什麼操作可以防止URL介面泄露出來？

混淆是無法混淆代碼中的字元串的，所以混淆並不能防止 URL 介面地址泄露。其次，URL 介面地址泄露是無可避免的，抓下包就知道地址了，不需要反編譯。

另外，題主你的目的有問題，不應該是如何隱藏介面地址，而應該是如何提高介面安全（例如如何避免介面通訊內容被泄露），根據我多次抓包以及反編譯國內一些比較出名 APP 的經驗，總結出以下幾點能提高介面安全的方法：

記得 Bilibili 和蝦米音樂都是使用 HTTPS 與服務端進行通訊的。

而如果題主真的連 URL 路由（理解為介面的 Action）都要隱藏的話，有兩種做法：

後端只提供一個介面，前端使用 Post Request - Response 的方式通訊，介面 Action 放在 Request Body 中，然後對 Body 進行加密
乾脆就別用 HTTP 協議了，用 Socket 實現自定義協議吧~

一切混淆都沒有意義，應該從介面自身的安全性入手，做到可以放心的作為公開的REST介面給全世界使用也不會被惡用的程度。

基於java位元組碼的特性，你的混淆是藏不住url的。我們在項目中會對傳輸的內容加密，對上傳的數據帶上表明身份的欄位。然後伺服器做是否響應的判斷。把壓力轉移給伺服器。我個人比較認同這種做法。在不增加服務請求次數的前提下，儘可能把操作放在伺服器端。

使用JNI，把介面都放到JNI中進行調用

迷魂陣，真真假假，假假真真，亦真亦假，亦假亦真，假到真時真亦假，真到假時假亦真。

就像有人在網上發布很多陷阱郵箱，這些郵箱專門給垃圾郵件用的，這些郵箱收到郵件，就會把發件人，發件伺服器等拉黑。

JNI + 加殼可以擋住絕大部分

URL是無法防止泄露的，簡單的抓包就抓到了，即使用https也無法防止。

以我做過多款app的偽客戶端的經驗，我最煩的就是自定義二進位協議+自定義加密，題主可以往這個方向考慮考慮。

對了，還有不要用HTTP/HTTPS，直接用 Socket 通訊，又能攔掉不少水平不夠或者懶得抓包分析的人

客戶端做安全保密沒什麼實際效果，還是服務端控制的好

本人做逆向APK很多年了。代碼混淆，對抗靜態分析，對抗動態調試，對抗模擬器，dex加固，so加固，資源文件加固，xml加固，虛擬機，防dump，大概就這些，希望有幫助。

混淆只能混淆代碼屬性文件，至於請求介面用抓包工具Fidder或者其他軟體就能抓取到介面請求地址，我們需要做的就是加密這些請求，防止惡意請求；主要方法如下：

1、介面放棄http，改用其他協議；（當然也不能也有破解方式，相對安全點吧）

2、使用jni底層進行加密，請求數據加密；

ps：客戶端沒有絕對的安全，我們需要做的就是解決當前的安全問題就夠了！

隱藏意義不大，可以從介面安全入手，比如在header中使用token機制。

你的app能夠與服務端通信

我去分析你的數據流和客戶端輸入的原始數據來逆向你這個加密或者說序列化數據的這麼一個過程來實現這種通信就是有可能的無非是加強數據包的一個加密讓原始數據到發送的數據流的這個映射更複雜安全性更高

這有關於混淆功能和類型的簡單分析，歡迎交流淺談安卓開發代碼混淆技術 - 李大師的文章 - 知乎專欄

涉及私密內容用c++寫，然後用Java調用。

再說API不是通過抓包要就能分析出來嗎？

相對好點的方法是用grpc/thrift之類的rpc framework。如果客戶端比較重，那麼

1）身份驗證，返回個token什麼的，

2）伺服器端做logging，記錄每一個請求

BS雙驗證(自己的產品是五步驗證)才是王道...

服務端認證

需要提升的是介面安全

抓包啥都有了 https照樣輕鬆抓到。

自定義傳輸協議，基於http也可以，就一個請求地址，把方法名參數按照自己的方式組裝，已2進位方式傳輸，自己封包解包。

介面萬一泄露了，在服務端也可以做一些對查詢的限制，比如請求次數限制，每次請求數據下發不會超過多少條等處理