首先，拿到一款app，二話不說，抓包。
這個就是它的文章詳情的包。可以看到部分解碼正常，部分亂碼。這是它自定義的協議格式。亂碼部分爲文章內容。
看一下它的響應格式
使用了字節流傳輸。
接下來使用jadx打開它的app，分析一下。
這裏採用逆向分析。
一般根據這些閱讀類的app，喜歡在本地寫一些緩存文件，用來提升用戶體驗。我們去文件目錄下找找看下有沒有這些我們比較敏感的文件。
看我們發現了啥。打開看看
這不就是文章的內容了嗎？ 說明在這之前，它已經完成了內容的解密。 可以發現這些文件都是以.deb結尾。那我們到jadx裏搜一下
只有一處，非常完美。
這裏我們使用frida專門hook此方法,打堆棧，查看調用情況。
可以看到它確實調用了該方法，返回了我們期待的文件路徑。 根據調用棧，我們看下它的上層函數
其中a2就是我們的文件路徑，然後傳到了m19274a中，最後又返回了a2。 我們進入到這個函數看它進行了啥操作。
可以基本猜想這裏是寫入文件的操作。 重點再觀察一下EasyEncrypt.mbb37b這個函數。
繼續使用frida hook這個函數。
這裏因爲它的返回值是字節， 沒辦法直觀看到結果。我們這裏轉一下字符串。方便觀察。
可以看到這個函數確實最終轉成了字符串。
我輸入的字節是不是我們從響應裏得到的呢？ 這裏需要摘取部分片段搜索一下。
從抓包軟件中隨便複製一行
把16進制轉成java字節碼
然後去搜索剛纔frida hook的參數裏，去搜下這傳數字。確定下傳入參數。
可以發現傳入參數確實有這串字節碼
但是卻轉換失敗了。 我們看下最後成功的字節碼
實際通過m6637b這個函數轉換成功的字節碼是這一串。 通過觀察整個調用情況，發現總共經過了兩次m6637b這個函數的轉換。 第一次參數是我們請求接口中獲取的字節碼，第二次纔是可以通過此函數轉成字符串的字節碼。所以現在的問題是，怎麼由第一步結果的字節碼，轉成第二次參數的字節碼。
我們看下b的調用棧，看有沒有更多信息。
這是m6637b第一次調用的調用棧。進去看一下。
可以看到它這個首先對我們響應的字節流用m6637b這個函數進行了一次處理，之後又用gzip完成了一次解壓縮。 那我們把第一次的值進行解壓縮，看一下解壓縮完畢的值是不是第二次調用m6637b函數的參數 。
轉換代碼 
最後結果
拿到這串結果，去hook到的數據裏搜一下。
結果發現剛好是這組字節碼轉成的字符串。 也就是說只經過了一次m6637b函數處理和gzip解壓縮就可以完成解密。那和之前分析的不符。之前分析的明明是調用了兩次m6637b函數才完成的解密。後來通過hook EasyEncrypt中的另一個函數才知道原因。
解壓縮完畢調用 mbb35a這個函數，之後再調用繼續調用mbb37b函數，也能還原數據。 現在解壓縮之後就可以的話,那後面兩步是可以省略的。