一、目标
今天的目标是 手机号加密，app变化太快，以前都是明文的。
TIP: 某小视频App v10.2.30.24518
二、步骤
字符串匹配
也许是手机号都是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一遍再说。
我们登上并非我们所选择的舞台,演绎并非我们选择的剧本
TIP: 本文的目的只有一个就是学习更多的逆向技巧和思路，如果有人利用本文技术去进行非法商业获取利益带来的法律责任都是操作者自己承担，和本文以及作者没关系，本文涉及到的代码项目可以去 奋飞的朋友们 知识星球自取，欢迎加入知识星球一起学习探讨技术。有问题可以加我wx: fenfei331 讨论下。
关注微信公众号: 奋飞安全，最新技术干货实时推送
