一、目标
今天的目标是 手机号加密，app变化太快，以前都是明文的。
二、步骤
字符串匹配
也许是手机号都是1xx开头，也许是这个加密字符串有个特征头。 反正经过我们观察，发现它大概率是 3sCt 开头。
而这种加密算法大概率是在Native层去做的。所以我们首选是去 hook_libart 里面的 GetStringUTFChars 和 NewStringUTF。
结果木有结果。
Base64
这个 3sCt 开头的字符串，很像Base64的结果。我们尝试用Base64去解一下，发现能解开。
那就毫不犹豫的尝试 Hook android.util.Base64 。
依然木有结果，这就比较神奇了，唯一的解释是 App木有用标准的Base64库函数，而是自己写了一个Base64算法。毕竟Base64的算法满天飞，有手就行。
搜字符串 "mobile"
现在死马当活马医吧。只能尝试去搜搜字符串了。
结果并不多，比较有重大嫌疑的就是这两处了。
我们点进去分析 m434739f 函数
这个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;
}跑一下
没错，就是这个 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一遍再说。
我们登上并非我们所选择的舞台,演绎并非我们选择的剧本
关注微信公众号，最新技术干货实时推送
