某小视频App v10.x 手机号加密算法分析

某小视频App v10.x 手机号加密算法分析

一、目标

今天的目标是 手机号加密，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一遍再说。

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

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。