前言

dfa 攻击相关资料，可参考之前的文章 从黑盒攻击模型到白盒攻击模型
样本来自龙哥星球，需要获取可加星球。上述链接有二维码

Tips：这个样本要比前两个复杂很多，主要不是很好定位注入点，所以后面会省略很多 trace 过程，直接贴最终代码

so

先来分析 so

依旧是导出窗口搜索 java，目标函数是 checkcode

打开之后就看到有 ollvm 混淆，真是又臭又长

随便瞄一眼这里看到了 aes 相关的符号

然后到导出窗口里搜索一下 aes 这里有两个加密函数，可以 hook 一下，看看最终走的那个函数，我这里 hook 走的是 encrypt1 函数

点进来分析一波，一个函数就是 pandding 数据填充，很明显了，然后有个 for 循环调用 EncryptOneBlock 函数，继续分析

这里点进来没有具体的函数，hook 之后发现是调用的了 0x4dcd

ida 跳转过来之后就是 aes 的核心逻辑了，白盒查表逻辑，最外层一个 for 循环，就是轮数，里面有多个 do while 循环，后面就要开始 trace 了，看看找找在哪里注入

最后是有个 base64 逻辑，所以在执行前 hook 一下，获取 aes 的加密结果

unidbg

架子搭起来

package com.qinless.linglingbang.v8014;

import com.github.unidbg.AndroidEmulator;
import com.github.unidbg.Module;
import com.github.unidbg.linux.android.AndroidEmulatorBuilder;
import com.github.unidbg.linux.android.AndroidResolver;
import com.github.unidbg.linux.android.dvm.*;
import com.github.unidbg.memory.Memory;

import java.io.File;
import java.io.IOException;

public class EncryptAesTest extends AbstractJni {
    private final AndroidEmulator emulator;
    private final VM vm;
    private final Module module;

    public String apkPath = "";

    EncryptAesTest() {
        emulator = AndroidEmulatorBuilder.for32Bit().build();
        final Memory memory = emulator.getMemory();
        memory.setLibraryResolver(new AndroidResolver(23));

        vm = emulator.createDalvikVM(new File(apkPath));
        vm.setJni(this);
        vm.setVerbose(true);

        DalvikModule dm = vm.loadLibrary("encrypt", true);
        module = dm.getModule();
        dm.callJNI_OnLoad(emulator);
    }

    public static void main(String[] args) {
        EncryptAesTest encryptAesTest = new EncryptAesTest();
        encryptAesTest.destroy();
    }

    private void destroy() {
        try {
            emulator.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

跑起来，过程会有些环境需要补，都是些简单的，自行补一下

public void callCheckCode() {
    DvmObject<?> dvmObject = vm.resolveClass("com/bangcle/comapiprotect/CheckCodeUtil").newObject(null);

    dvmObject.callJniMethodObject(
            emulator, "checkcode(Ljava/lang/String;ILjava/lang/String;)Ljava/lang/String;",
            new StringObject(vm, "aaaaa"), 5, new StringObject(vm, "bbbbb")
    );
}

public void inlineHook() {
    emulator.getBackend().hook_add_new(new CodeHook() {
        @Override
        public void hook(Backend backend, long address, int size, Object user) {
            if (address == (module.base + 0x164EC)) {
                Arm32RegisterContext ctx = emulator.getContext();

                System.out.println("aes result: " + QLUtils.bytesToHexString(ctx.getR0Pointer().getByteArray(0, 16)));
            }
        }

        @Override
        public void onAttach(UnHook unHook) {
        }

        @Override
        public void detach() {
        }
    }, module.base + 0x164EC, module.base + 0x164EC, null);
}

调用目标函数，再通过 inlinehook 获取 aes 加密结果

运行代码，结果也是成功获取到了

---

这里简单说下博主的分析流程吧

• 1、先确定输入

• 2、根据输入数据的地址，进行 traceRead

• 3、再根据 traceRead，分析合适的注入点

选择 traceRead 的原因也是因为，静态分析 so 实在看不出来啥，动态调试，又太麻烦了，最好的办法就是通过 trace

---

寻找输入大家可以自行分析，我这里就直接进行 hook 了，地址 0x4DCC

该函数有四个参数，参数二就是我们的数据，也是填充后的输入，保存地址 0x403b1000，然后进行 traceRead

这里 trace 了 16 个字节，ida 跳过去看看在哪里的读取的

发现在这里有读取，然后又写入了新的地址，那我们在 debugger 一下看看

断下来，数据是存到这个地址里了

看下地址数据，发现是空的 n 单步执行

在看一下，写入了一字节数据，那直接 traceWrite 这个地址看看

这里写入的 16 字节数据，正好是我们的输入，那就在 traceRead 看看那里读取了

在这里，同一地址，读取了 16 次，ida 看看

这里是在 for 循环里，那我们是不是可以在 for 循环开始，直接修改这个地址的数据，实现注入，感觉没啥毛病尝试一下

注入成功，加密结果变了，这次代码就不贴了，大家自行写一下即可

然后就是多次注入，获取密文，在计算出主密钥

最后

最后计算出主密钥的图就不贴了