一、目标

一、目标

今天的目标是 手机号加密,app变化太快,以前都是明文的。

main
1:main

二、步骤

字符串匹配

也许是手机号都是1xx开头,也许是这个加密字符串有个特征头。 反正经过我们观察,发现它大概率是 3sCt 开头。

而这种加密算法大概率是在Native层去做的。所以我们首选是去 hook_libart 里面的 GetStringUTFCharsNewStringUTF

结果木有结果。

Base64

这个 3sCt 开头的字符串,很像Base64的结果。我们尝试用Base64去解一下,发现能解开。

那就毫不犹豫的尝试 Hook android.util.Base64 。

依然木有结果,这就比较神奇了,唯一的解释是 App木有用标准的Base64库函数,而是自己写了一个Base64算法。毕竟Base64的算法满天飞,有手就行。

搜字符串 "mobile"

现在死马当活马医吧。只能尝试去搜搜字符串了。

find
1:find

结果并不多,比较有重大嫌疑的就是这两处了。

我们点进去分析 m434739f 函数

findex
1:findex

这个App已经混淆到令人发指了,居然还能出现 atlasEncrypt 这么明显的函数,一定得好好Hook它。

m60341e 也值得我们注意,这个类很像是Base64算法,这也解释了为啥Hook android.util.Base64 木有结果

开始写代码吧

var IKSecurityExCls = Java.use("com.xxxixxxu.android.security.KSecurity");

IKSecurityExCls.atlasEncrypt.implementation = function(a){
    var StrCls = Java.use('java.lang.String');
    var inStr = StrCls.$new(a);

    var result = this.atlasEncrypt(a);
    console.log(inStr + " >>> atlasEncrypt(Hex) " + bytesToHex(result));
    console.log(inStr + " >>> atlasEncrypt(Base64) " + bytesToBase64(result));

    return result;
}

跑一下

rc
1:rc

没错,就是这个 3sCt

三、总结

自定义的Base64算法有个特征,大概率会有个

private static final char[] f323023h = {'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', '-', '_'};

常量数组的定义,所以下次遇到类似的情况可以考虑搜一下这个常量字符串。当然前提是标准的Base64算法,之前我们遇到的魔改的Base64算法,就是打乱的这个常量数组的顺序。

App的分析得一直跟踪,才不会落伍,我们之前分析过这个App,也找到过 KSecurity 这个类。所以下次再遇到它升级后的版本加密了其他东西,可以考虑先把这个 KSecurity 类的函数Hook一遍再说。

ffshow
1:ffshow

我们登上并非我们所选择的舞台,演绎并非我们选择的剧本

100

关注微信公众号,最新技术干货实时推送

100