老規(guī)矩，我們拿到一個apk依舊是先分析它的java代碼

再來看一下so庫

先看一下getFlag()

動態(tài)調(diào)試一波flag

qekfz@q2^x/t^fn0mF^6/^rbqanqntfg^E`hq|

再回頭看下java代碼會發(fā)現(xiàn)就是讓輸入的文本使用Native方法Encrypt加密后等于上面哪個字符串

那我現(xiàn)在再來看一下Encrypt函數(shù)是什么東西

光是看這個偽代碼，其實(shí)這里已經(jīng)很明顯了的，但是我打算跑起來試試，這樣更加直觀嘛

第一次調(diào)用在 public String getSecret(String string)
str = ((env)->GetStringUTFChars)();
傳值：KE3TLNE6M43EK4GM34LKMLETG
返回：JD2SKMD5L32DJ3FL23KJLKDSF
這就明白了，--i str取地址--，就是對應(yīng)的ASCII碼值的上一位

encrypt("KE3TLNE6M43EK4GM34LKMLETG").substring(5, 8) = MD5
（再說咯，java層的getSecret函數(shù)調(diào)用了MessageDigest.getInstance（），這里里面的算法就那么兩個個md5，sha，不是就會報錯NoSuchAlgorithmException，其實(shí)猜也很好猜）

那現(xiàn)在我們也就清楚了encrypt做了什么事了，本著簡單的重復(fù)操作都應(yīng)該交給代碼的思想，剩下的也就交給idea寫段小代碼解決

于是乎我們得到了：rflag{Ar3_y0u_go1nG_70_scarborough_Fair}

看樣子像是flag，但是試了一下居然給我失敗。。。無語了
只要祭出frida大法來看看參數(shù)為什么不對

emmm 多了一個q導(dǎo)致算出來的md5不一樣。。。

回頭檢查了 一下，發(fā)現(xiàn)在分析native的時候查看寄存器的時候多看了上一位并沒什么卵用，地址也不對的q，肯爹東西，為什么讓兩個字符串靠的如此之近。。。，還偏偏手賤 a 錯了。。。

所以flag應(yīng)該是：flag{Ar3_y0u_go1nG_70_scarborough_Fair}

還是附上apk下載地址，喜歡的小伙伴點(diǎn)個贊，或者自己去嘗試一下
https://www.lanzous.com/iay0oud