某车联网App 通讯协议加密分析(三) Trace Block

公众号: 奋飞安全
• 阅读 535

一、目标

之前我们已经用unidbg跑通了libencrypt.so,那么如何判断跑出来的结果是对是错?再如何纠正unidbg跑错误的流程,是我们今天的目标。

v6.1.0

二、步骤

找到明显的接口来判断

checkcode是加密,加密的结果确实不好判断是否正确。不过我们可以试试解密,能解密就是对的,简单粗暴。这里解密函数是 decheckcode 。

public void callB() {
    String strA = "FlK6XicivmCwPSE3sk6b71m9WbWd/gYZtlajqGXhEXXjmWEZziR51rVWSEDwUUi4UN9RnoCGbLNmqI80Fiog4Sw==";
    String methodName = "decheckcode(Ljava/lang/String;)Ljava/lang/String;";
    DvmObject ret = dvmClass.callStaticJniMethodObject(emulator, methodName,strA);
    String strOut = (String)ret.getValue();
    System.out.println("call decheckcode: " + strOut);
}

跑一下,这个结果明显不对,死心了

call decheckcode: fac34ffa581987c7a1ffa5b876ca96ce

分析问题

结果不对,肯定是过程不对。

那么解决方案就是 分析对比unidbg运行的流程和app运行的流程 有哪里有不同?

对比运行流程有三个粒度, 函数、代码块和代码。 (在ida里按空格,出现的流程图中的每个块就是代码块)

我们今天主要要对比 decheckcode函数,所以先从代码块的粒度来做Trace。

Trace Block

unidbg提供一个BlockHook,每运行到一个代码块就触发这Hook,我们就利用他来做Trace Block

// 保存需要用frida Hook的Block的地址
public static Map<Integer, Integer> subTraceMap = new HashMap<Integer, Integer>();
// 保存命中的Block地址的次数,命中次数太多的就忽略掉。
public static Map<Integer, Integer> calcMap = new HashMap<Integer, Integer>();

// 入参是so基地址,   需要Trace代码的开始地址和结束地址
private void traceBlock(final long baseAddr, final long starAddr, final long endAddr) {
    emulator.getBackend().hook_add_new(new BlockHook() {
        @Override
        public void hookBlock(Backend backend, long address, int size, Object user) {
            // 代码块需要大于20个字节,  块太小 影响 frida的 hook
            if (size > 20) {
                Instruction[] insns = emulator.disassemble(address, 4, 0);

                int iSize = insns[0].getSize();
                int iUseAddr = 0;

                if (iSize == 4) {
                    // ARM模式 4字节
                    iUseAddr = (int) (address - baseAddr);
                } else {
                    // THUMB模式 2 字节 ,hook的时候 + 1 ,
                    iUseAddr = (int) (address - baseAddr) + 1;
                }

                if (calcMap.containsKey(iUseAddr)) {
                // 保存命中次数
                    int iValue = calcMap.get(iUseAddr);
                    calcMap.put(iUseAddr, iValue + 1);

                    // 4次以上的调用就不显示了, 也不用frida Trace了
                    if (iValue > 3) {
                        subTraceMap.remove(iUseAddr);
                    } else {
                        System.out.println("  " + "sub_" + Integer.toHexString((int) (address - baseAddr)) + " ");
                    }

                } else {
                    calcMap.put(iUseAddr, 1);
                    subTraceMap.put(iUseAddr, 1);

                    System.out.println("  " + "sub_" + Integer.toHexString((int) (address - baseAddr)) + " ");
                }
            }
        }

        @Override
        public void onAttach(UnHook unHook) {

        }

        @Override
        public void detach() {

        }

    }, starAddr, endAddr, 0);

}

Trace Block结束之后,把命中的代码块地址都打印出来,用于在Frida中去hook

public void PrintHookSubInfo(){
    System.out.println("subTrace len = " + subTraceMap.size());
    String strOut = "";
    for (Map.Entry<Integer, Integer> entry : subTraceMap.entrySet()) {
        int iShow = entry.getKey();
        // 为了和unidbg显示一致这里处理下
        if(iShow % 2 != 0){
            iShow = iShow -1;
        }
        strOut = strOut + "  ,['sub_" + Integer.toHexString(iShow ) + "','0x" + Integer.toHexString((int)entry.getKey() ) + "']";
    }
    System.out.println(strOut);
}

有了这两个函数就可以干活了

public void callB() {
    traceBlock(module.base,module.base,module.base  + module.size);
  ...
        String methodName = "decheckcode(Ljava/lang/String;)Ljava/lang/String;";
        DvmObject ret = dvmClass.callStaticJniMethodObject(emulator, methodName,strA);
  ...
    PrintHookSubInfo();
}

在执行 decheckcode 之前去做Trace, 执行之后去打印所有命中的Block地址。

Tip:

这个样本没那么复杂,所以就直接Trace所有代码范围,讲究人是需要缩小范围,只Trace自己感兴趣的部分。

Find native function Java_com_bangcle_comapiprotect_CheckCodeUtil_decheckcode => RX@0x4002b1bc[libencrypt.so]0x2b1bc
  sub_2b1bc
  sub_2b20c
  sub_2b238
  sub_2b254
  sub_2b270
  sub_2b28c
  sub_2b2a8
  sub_2b2c4
  sub_2b2e0
  sub_2b2fc
  sub_2b318
  sub_2b334
    ...

subTrace len = 127
  ,['sub_21400','0x21400']  ,['sub_21c00','0x21c00']  ,['sub_22200','0x22200']  ,['sub_2b604','0x2b604']  ...

Trace的结果出来了,命中的地址列表也打印出来了,一共命中了127个地址块。

frida Hook 对比

把命中的地址列表导入到frida里面去hook,然后就可以对比出来 unidbg跑的流程和App跑的流程的差别了。

function hook_suspected_function(targetSo) {
    const funcs = [
        ['sub_21400','0x21400']  ,['sub_21c00','0x21c00']  ,['sub_  ...
          ];

    for (var i in funcs) {
        let relativePtr = funcs[i][1];
        let funcPtr = targetSo.add(relativePtr);
        let describe = funcs[i][0];
        let handler = (function() {
            return function(args) {
                // console.log("\n");
                console.log(TAG + describe);
            };
        })();
        Interceptor.attach(funcPtr, {onEnter: handler});
    }
}


function traceNative() {
    var targetSo = Module.findBaseAddress('libencrypt.so');
    console.log(TAG +" Trace ############# libencrypt.so: " +targetSo);
    hook_suspected_function(targetSo);
}

// 然后在hook  decheckcode的时候打印Trace结果
Interceptor.attach(targetSo.add(0x2B1BC ),{
    onEnter: function(args){
        traceNative();

        var strCls = Java.use('java.lang.String');

        var strA = Java.cast(this.context.x2, strCls);
        console.log(TAG + "-------- decheckcode a = " + strA);

    },
    onLeave: function(retval){
        var strCls = Java.use('java.lang.String');
        var strRc = Java.cast(retval, strCls);
        console.log(TAG + "-------- decheckcode rc = " + strRc);

    }
});

对比结果

对比的方法比较low,先把unidbg Trace Block的结果复制到文本文件1,然后把frida hook打印的结果复制到文本文件2。 最后开启 Beyond Compare 来对比

某车联网App 通讯协议加密分析(三) Trace Block

1:cmp

过程虽然很low,但是结果可一点都不low,从对比的结果看,大家之前都是好朋友,不过 sub_18650 之后就开始分道扬镳了。

这时候就需要问问ida了。

某车联网App 通讯协议加密分析(三) Trace Block

1:fopen

这里fopen了一个文件,文件名是做了base64。

base64谁不会呢,随便写两行代码就可以解出来了 /proc/%d/cmdline

这又在考我们的android编程知识了,问了下谷哥,哥说了,这是在读进程名,对于apk来说,进程名就是他的包名。

回想在 unidbg中 有个不起眼的报错

[11:26:48 927]  INFO [com.github.unidbg.linux.ARM64SyscallHandler] (ARM64SyscallHandler:1309) - openat dirfd=-100, pathname=/proc/2256/cmdline, oflags=0x0, mode=0

这也是在提醒我们,读取进程名失败了。

重定向io

unidbg是支持这种情况的,先让 CaranywhereDemo 多继承一个 IOResolver 来做io重定向

public class CaranywhereDemo  extends AbstractJni implements IOResolver<AndroidFileIO> {
    ...

    public Caranywhere(String apkFilePath) throws DecoderException, IOException {
      ...
            emulator.getSyscallHandler().addIOResolver(this);
      ...
    }

    FileResult<AndroidFileIO> f1;

    public FileResult<AndroidFileIO> getF1(String pathname, int oflags) {
        if (f1 == null) {
            f1 = FileResult.<AndroidFileIO>success(new ByteArrayFileIO(oflags, pathname, "com.xxx.aeri.caranywhere".getBytes()));
        }
        System.out.println("new f1==" + pathname + "===" + vm.getPackageName());
        return f1;
    }

    @Override
    public FileResult<AndroidFileIO> resolve(Emulator<AndroidFileIO> emulator, String pathname, int oflags) {
        System.out.println(pathname);
        if ("/proc/self/cmdline".equals(pathname) || ("/proc/" + emulator.getPid() + "/cmdline").equals(pathname)) {
                        return getF1(pathname, oflags);
        }

        return null;
    }
}

ok了,这几步又和App跑的一样了,大家又是好朋友了。

不过问题还是没有解决,跑出来的结果还是不对,木有解密成功。而且貌似这个app还有坑,hook点一多就摆烂,直接崩溃。

得找新武器对付它了,期待下一章的大结局吧。

三、总结

何以解忧,唯有Trace。

能下断点Debug的App,一定就逃不出手心了。所以现在App的关注点都是抵抗Debug,抵抗下断点。

结果不对,就和正确的结果去对比流程,跑的和你一模一样,总没毛病吧?

某车联网App 通讯协议加密分析(三) Trace Block

1:ffshow

凡说之难 在知所说之心 可以吾说当之

Tip:

: 本文的目的只有一个就是学习更多的逆向技巧和思路,如果有人利用本文技术去进行非法商业获取利益带来的法律责任都是操作者自己承担,和本文以及作者没关系,本文涉及到的代码项目可以去 奋飞的朋友们 知识星球自取,欢迎加入知识星球一起学习探讨技术。有问题可以加我wx: fenfei331 讨论下。

关注微信公众号: 奋飞安全,最新技术干货实时推送

点赞
收藏
评论区
推荐文章
某汽车社区App 签名和加解密分析 (二) : Frida Dump so
一、目标App安全的主战场在Native层,分析Native层的so,最趁手的兵器就是Frida和Unidbg了。今天我们的目标是某汽车社区Appv8.0.1so的分析。二、步骤特征字符串定位我们在上一篇教程已经定位了,数据加密和解密函数再java层的位置。按照常理来说,这个java类文件中,应该有个System.loadLibrary("
某电商App 返回数据加密解密分析(四)
一、目标最近在抓包某电商App的时候发现一个加密数据,它在做通讯地址请求的时候,请求数据做了加密。返回数据中的地址信息也是密文。今天我们的目标就是这个数据的加密解密。App版本:v10.3.0二、步骤分析一下1、数据的结尾是"",说明是Base64编码,那么我们可以尝试去HookBase64相关函数,然后打印堆栈。2、返回数据格式是json,那么我
某神奇App data加密算法解析(一)
一、目标李老板:奋飞呀,我遇到一个超级牛掰的App,它请求的时候有个data参数加密,用尽了你介绍的所有的方法,都找不到它是如何加密的。奋飞:子曾经曰过,老板的嘴,骗人的鬼。有这么牛掰的App,那么我们这帮兄弟早就失业了。某神奇Appv10.1.0点社区随便打开一篇有评论的文章今天的目标就是这个data二、步骤搜索特征字符串目标是data,所以我
浅谈加密算法 aes
一、目标搞了这么多期签名和加密解密,今天我们聊聊高大上的东西:加密算法。加密算法我们整体可以分为:不可逆加密算法和可逆加密算法。不可逆加密算法常见的不可逆加密算法有MD5,HMAC,SHA1、SHA224、SHA256、SHA384,和SHA512。他们的特点是,不能从加密后的结果解密出原文,主要用于校检数据的一致性,防止篡改数据,我们之前分析的大部分s
某车联网App 通讯协议加密分析(二) Unidbg手把手跑通
一、目标有一段时间没有写unidbg相关的文章了,这个样本挺合适,难度适中,还适当给你挖个小坑。所以后面是一个系列文章,包含unidbg补环境,TraceBlock对比流程,TraceCode定位差异。掌握好这一系列套路,Native分析可以算入门了。这次先来把so用unidbg跑通v6.1.0二、步骤DumpsoIDA打开 libencryp
某小说App返回数据 解密分析
一、目标李老板:奋飞呀,最近被隔离在小区里,没啥可干的呀。奋飞:看小说呀,量大管饱。我们今天的目标就是某小说Appv20210953二、步骤搜索url字符串App请求小说内容的时候没有加签名,但是返回的数据是加密的。那么我们先去jadx搜索一下这个url(novelcontent),看看有没有发现。结果是没有收获。那么很有可能这个url不是在apk中写
某车联网App 通讯协议加密分析(四) Trace Code
一、目标之前我们已经通过TraceBlock来比对了Unidbg和App跑的结果。现在他们运行的流程都差不多了,但是结果还是不对,今天我们就要通过TraceCode进行更细致的对比。v6.1.0二、步骤缩小Trace的范围TraceCode那么好使,我们为什么不一上来就Trace一遍?因为TraceCode的粒度太细了,一上来就搞,跑出几百万行
Wesley13 Wesley13
3年前
JAVA_RSA_的加解密
RSA为非对称加密算法。数字签名的过程:1、对明文数据进行HASH加密,不可逆;2、对加密后的数据再用RSA的私钥进行二次加密。数字签名的验证过程:1、对明文数据进行HASH加密,不可逆;2、用RSA的公钥对数字签名后的数据进行解密;3、把1的结果和2的结果进行比较是否相等。RSA加密的过程和解密的过程都需要三步:加/解密、分组、填充。这三部分每
Wesley13 Wesley13
3年前
JAVA加解密算法设计与应用
业务场景APP移动端、WEB、桌面端、第三方平台密码等敏感数据加密设计如app端登录密码加密设计对于登录密码不需要进行解密只需要加密算法结合规则进行比较就能得到密码正确与否方法一(签名保证安全)1.密码等敏感信息取Md5值对所有值(加上timestamp)
Wesley13 Wesley13
3年前
Go加密解密之DES
一、DES简介DES(DataEncryptionStandard)是对称加密算法,也就是加密和解密用相同的密钥。其入口参数有三个:key、data、mode。key为加密解密使用的密钥,data为加密解密的数据,mode为其工作模式。当模式为加密模式时,明文按照64位进行分组,形成明文组,key用于对数据加密,当模式为解密模式时,key用于对数据解
公众号:  奋飞安全
公众号: 奋飞安全
Lv1
奋飞,国家高级信息系统项目管理师,独立安全研究员。 http://91fans.com.cn/
文章
60
粉丝
4
获赞
44