从一道题目(阿里2014 Crackme_2)开启unidbg还原算法入门（转载）

转载链接 一个学弟写的文章，我来转载一下，据我所知阿里2014这个题目 分析最明白的应该就是这个学弟的文章了

从一道题目开启unidbg还原算法入门

Trace环境搭建

Trace其实就是记录指令的运行以及内存的状态变化。如果能跑trace就可以在文本里面观察值的变化以及变化行为。能够更好的让我们关注内存数据在运行中的变化。

我们从前两篇文章里面其实已经知道，apk的lib其实是在初始化的时候修改的内存数据，所以我们需要在还没初始化的时候就设置trace逻辑。

下面是我写的unidbg trace逻辑

public void trace(){

    String traceFile = "unidbg-android/src/test/java/com/ctf/trace.txt";

    PrintStream traceStream = null;

    try{

        traceStream = new PrintStream(new FileOutputStream(traceFile), true);

    } catch (FileNotFoundException e) {

        e.printStackTrace();

    }

    //核心 trace 开启代码，也可以自己指定函数地址和偏移量

    emulator.traceCode().setRedirect(traceStream);

}

然后要在加载目标so之前运行并且调用这个函数就可以

Trace文件分析

寻找修改flag逻辑

看trace文件分析对比点，从这里可以发现基地址是0x12000000,我们查看4450的地址其实就是 flag对比的点。

那我们只需要看是哪里修改了4450这个内存地址就可以了，只需要加一行代码

AliCrackme_obj.emulator.traceWrite(0x12004450,0x124e4e40+0x12);

发现log输入如下

让我们在binary ninja里面找到对应的地方

欸？这是什么情况。这里要介绍一个概念，叫做smc:

代码自修改（Self-Modifying Code, SMC）是指程序在运行时修改自身指令的技术，这种技术可以用于增强软件的保护，使其更难被逆向工程分析和破解。主要通过运行时修改内存中的指令来实现，使得反汇编结果与实际执行逻辑不符，增加分析的难度。

也就是说，这个代码在运行的时候，修改了这段代码的执行逻辑，所以在静态的时候没有办法看出相关的逻辑，需要动态调试或者静态还原这个代码逻辑。

其实unidbg 已经帮我们还原了，在这里面看，已经是被还原的逻辑了。字节码都已经改变了。其实如果想省事一点，直接解析这个trace,然后直接对着binary ninja patch 就可以了。但是笔者想从头到尾去分析这个apk，所以我们继续看是在修改代码。

寻找修改代码逻辑

省略

总结

这个题目虽然比较老，但是应该有的东西都有，msc、反调试、指针动态获取等，用来入门正好。随便给大家留一个作业，请分析这个app lib的所有运行逻辑