奋飞安全

public class MainActivity extends AppCompatActivity {

    static {
        System.loadLibrary("native-lib");
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        com.qiyi.test.Test.getInstance().init();
        com.qiyi.test.Test.getInstance().start();

        TextView tv = findViewById(R.id.sample_text);
        tv.setText(stringFromJNI());
    }

    public native String stringFromJNI();
}

看到这里，经验丰富的同学鼻子应该已经动了一下。

这个App自己先加载了一个 native-lib，然后又通过 Test.getInstance().init() 去加载另一个so，最后再调用 start()。这个结构就很适合拿来演示 Jadx看调用链，IDA看so实现。

1:mainactivity

Test.java 里面是这样的：

public class Test {
    private static final Test ourInstance = new Test();

    public static Test getInstance() {
        return ourInstance;
    }

    private Test() {
    }

    public synchronized void init() {
        System.loadLibrary("test");
    }

    public synchronized void start() {
        com.qiyi.test.NativeHandler.getInstance().start();
    }
}

再看 NativeHandler.java

public class NativeHandler {
    private static final NativeHandler ourInstance = new NativeHandler();

    public static NativeHandler getInstance() {
        return ourInstance;
    }

    private NativeHandler() {
    }

    public native void start();
}

到这里，其实已经很明确了：

Java层先加载 native-lib
然后再加载 test
最终 NativeHandler.start() 这个native方法，大概率会落进 libtest.so

如果是以前，我们下一步多半就是手工点Jadx，翻so，找JNI。但今天咱们不自己干，今天要体验一下当李老板的快乐。

三、先让Jadx干活

先把APK丢给Jadx，然后在Codex里开口：

连接 JADX MCP，先从 MainActivity 开始分析这个 APK 的调用链。重点找：
1. 哪些 so 被加载了
2. Java 层如何走到 native 方法
3. com.qiyi.test.Test 和 NativeHandler 分别负责什么
请用清晰的调用路径输出结果。

1:jadxprompt1

这种活很适合Jadx MCP。

因为它擅长处理的，正是逆向前期最费手的那部分：

找类
找方法
找调用关系
先把零散入口收拢成一条主链

很快Codex就能把第一段链路摸出来：

MainActivity.onCreate
  -> Test.getInstance().init()
  -> System.loadLibrary("test")
  -> Test.getInstance().start()
  -> NativeHandler.getInstance().start()
  -> native void start()

1:jadxresult1

这一步的价值看上去不惊艳，但很实用。

因为很多时候逆向刚开始最烦的，不是算法太难，而是入口太多。你明明知道东西在so里，但是Java层到底是谁把它调进去的，得先理顺。

Jadx MCP 在这里干的活，本质上就是：

“帮你先把门牌号找到。”

再追一步

既然 NativeHandler.start() 已经浮出来了，就继续让Codex问：

继续在 JADX MCP 里分析 NativeHandler.start 对应的 native 声明位置，告诉我它最可能落到哪个 so，给出判断依据。

这个问题比一句“帮我逆向一下”有效得多。

范围收窄之后，Codex 给出的判断通常会稳很多。

这里Codex通常会给出一个很合理的判断：

NativeHandler.start() 是 native 方法
Test.init() 显式加载了 test
Test.start() 直接调用了 NativeHandler.start()
所以这个native实现最可能在 libtest.so

这一步的作用，不是立刻拍板结论，而是先把 native 落点缩到一个足够小的范围，方便后面进 IDA 继续核实。

1:jadxresult2

四、轮到IDA出场

Jadx把Java层的路摸清楚之后，就该让IDA MCP接手了。

这时候直接把 libtest.so 丢进IDA，然后继续给Codex下命令：

连接 IDA MCP，分析 libtest.so。
请优先做这几件事：
1. 列出导入函数和可疑入口
2. 查找 JNI 相关符号、JNI_OnLoad 或 native 注册痕迹
3. 判断 Java 层的 NativeHandler.start 最可能对应到 so 里的哪个实现
不要泛泛而谈，直接给定位过程。

1:idaprompt1

这个so有个特点，挺适合演示：

它是个 stripped so。

啥叫 stripped？就是那种“脸洗得很干净，名字全没了”的状态。你不能像看Java代码那样，直接看到一堆明晃晃的方法名。

所以这时候IDA MCP的价值就出来了。

它可以先看导入符号，再找JNI相关痕迹，再从函数行为去反推哪个地方像 start() 的实现。

这个so里比较显眼的一段逻辑，是对 __android_log_print 做了处理。

1:idalibtest

对应的native代码大概是这样：

static int (*orig_log_print)(int prio, const char* tag, const char* fmt, ...);

static int my_libtest_log_print(int prio, const char* tag, const char* fmt, ...)
{
    va_list ap;
    char buf[1024];
    int r;

    snprintf(buf, sizeof(buf), "[%s] %s", (NULL == tag ? "" : tag), (NULL == fmt ? "" : fmt));

    va_start(ap, fmt);
    r = __android_log_vprint(prio, "Dobby_libtest", buf, ap);
    va_end(ap);
    return r;
}

__attribute__((constructor)) static void ctor() {
    DobbyHook((void *) DobbySymbolResolver(NULL, "__android_log_print"),
              (void *) my_libtest_log_print,
              (void **) &orig_log_print);
}

看到这段，基本味道就出来了。

这不是单纯导出一个JNI函数完事，它在库加载阶段就先用 DobbyHook 把 __android_log_print 给拦了。

这就很适合写文章，因为它有戏剧性：

Java层负责把so请进来
so一进场就先动系统日志
然后再等Java层去调native方法

IDA最擅长的是什么

很多同学会觉得，既然Jadx都能看Java层了，那IDA是不是只是锦上添花？

还真不是。

Jadx擅长的是：

帮你快速理解Java世界
找调用链
找native声明
看谁加载了哪个so

IDA擅长的是：

看so真实干了什么
在符号不全的时候继续往下走
看导入、交叉引用、构造函数、初始化逻辑
判断这段native代码到底是做计算、做注册、还是做hook

一个看楼上，一个看地下室。你不能让Jadx去替IDA，也不能让IDA去替Jadx。

五、让Codex两路会师

前面这两步，单看都不新鲜。

真正有意思的是第三步：让Codex把两边结果收回来，自己拼成一条完整链路。

这时候继续下指令：

结合 JADX MCP 和 IDA MCP 的结果，把这条完整链路串起来：
MainActivity -> Test -> NativeHandler -> libtest.so
要求用逆向文章的写法输出，像是在给读者讲解，不要写成审计报告。

1:codexmerge

这里我特意让它按“逆向讲解”的口吻来整理，目的很简单：输出要像一篇能直接拿来读的分析笔记，而不是一份生硬的审计摘要。

Codex 收完两边结果之后，基本能整理出这样一条链路：

MainActivity 启动时先加载 native-lib
onCreate() 中调用 Test.getInstance().init()
init() 里执行 System.loadLibrary("test")，也就是加载 libtest.so
libtest.so 在加载阶段通过 constructor 执行初始化逻辑
初始化逻辑里调用 DobbyHook，把 __android_log_print 做了替换
随后 Java 层执行 Test.getInstance().start()
start() 再转到 NativeHandler.start()
NativeHandler.start() 最终进入 libtest.so 中对应的native实现

看到这里，文章的核心其实已经出来了。

今天真正要演示的，不是某个算法有多牛。而是 Codex 能不能替你把 Java 层和 Native 层的结果先串起来。

答案是：能，而且挺适合干这个。

1:callchain

六、再补一刀，验证调用顺序

到这里，静态链路基本已经串起来了。但逆向不能只停留在“看起来像”，最好还是再补一轮动态验证，把调用顺序真正钉死。

这时候可以直接让 Codex 按当前上下文整理一版 Frida 验证思路：

根据当前分析结果，生成一个 Frida hook 思路，验证 Java 层和 native 层的调用顺序，但不要写成大而全模板，只给关键点。

1:fridaprompt

这时候让它出思路，会比一上来直接丢一句“写个 Frida 脚本”更靠谱。

因为前面的上下文它已经都拿到了：

Java入口是谁
System.loadLibrary("test") 在哪
NativeHandler.start() 是关键点
libtest.so 里还有日志hook行为

有了这些信息，再去生成 Hook 点位和验证顺序，命中率会高很多。

这也是 MCP 最实用的地方之一：先把样本喂到位，再让模型开口，输出通常会扎实不少。

七、总结

以前的逆向流程，更像是你一个人左手拿Jadx，右手拿IDA，嘴里叼着Frida，脑子里还得记着前面谁调了谁。

现在如果把Codex接进来，感觉就有点不一样了。

它并不能直接替你变成逆向高手。但它很适合先干这些活：

帮你找调用链
帮你整理类和方法关系
帮你在Jadx和IDA之间回收信息
帮你把“入口在哪、链路怎么走”先理顺

真正值钱的部分，还是你来判断：

这个native逻辑重要不重要
这个so里哪块值得深挖
这个Hook行为到底意味着什么
下一步是该上Frida，还是该继续IDA

说白了，Codex不是来抢你饭碗的。它更像是刚入行的实习生，跑得快，记性好，不嫌累。前提是你得告诉它先去哪、看什么、怎么回报。

古法逆向有没有用？当然有。

但现在的问题已经不是“要不要用AI”，而是你会不会让AI替你先把脏活干掉。

1:ffshow

多一双眼睛的人，不一定更聪明，但一定看得更快。

关注微信公众号，最新技术干货实时推送

Jadx也想要翅膀

Thu, 25 Dec 2025 16:38:38 +0800

一、目标

Jadx : "我也很想进步，古法太繁琐了，现在的年轻人都玩不转。"

fenfei : "这个可以有。"

二、步骤

安装

mcp是什么咱们就不解释了，刚来的同学可以翻翻前情提要回顾一下 http://91fans.com.cn/post/idamcp/

今天我的新朋友是 jadx-ai-mcp

https://github.com/zinja-coder/jadx-ai-mcp

她的安装分两部分

去到 /Users/fenfei/Desktop/tool/jadx-1.5.3/bin 目录下面执行

./jadx plugins --install "github:zinja-coder:jadx-ai-mcp"

下载 jadx-mcp-server 对接 AI 用

https://github.com/zinja-coder/jadx-ai-mcp/releases/download/v5.0.0/jadx-mcp-server-v5.0.0.zip

开工

找个软柿子捏一下

就用之前的 http://91fans.com.cn/post/txtread/ ,咱们换AI来搞 Jadx打开，然后文件 → 首选项 → 插件

1:jadxplugin

这说明插件部分安装OK

然后给 AI IDE 配置上 MCP Server

{
  "mcpServers": {
    "jadx": {
      "command": "/opt/miniconda3/envs/jadxmcp/bin/python",
      "args": [
        "/Users/fenfei/Desktop/tool/jadx-mcp-server/jadx_mcp_server.py"
      ],
      "alwaysAllow": [
        "get_android_manifest",
        "search_classes_by_keyword",
        "get_class_source",
        "search_method_by_name"
      ]
    }
  }
}

细心的同学可能发现和之前IDA的MCP配置有很大的不一样。

AI这玩意还在迅猛发展，百家争鸣，所以MCP的协议有很多种，具体这两种协议哪种先进，可以问问 AI。

咱们是实用主义着，先不纠结原理了，连上了就行，在 AI IDE里呼唤神龙…

连接jadx mcp, 定位 token=rOW60Ct5iGxgRX0Olulcz9IXtWiGmAO7cbL7Y%2FU0tOc%3D 这个 token计算的位置，然后写个Frida hook 脚本

然后就是默默的等待，想起了 Chrome的恐龙游戏，我感觉在等待 AI干活的过程中，应该来个是男人就下500层的小游戏。怪不得李老板喜欢玩扫雷，原来他把我当AI了，发布命令，然后边玩扫雷，边等我的结果。

有了AI 咱们也能过上李老板的日子了，越来越有盼头了。

AI 写完了，我就不贴代码了， (小声告诉你，贴知识星球了)

任务完成
已成功定位token计算位置并创建Frida hook脚本 token_hook.js

Token生成流程分析
根据反编译代码，token rOW60Ct5iGxgRX0Olulcz9IXtWiGmAO7cbL7Y%2FU0tOc%3D 的生成流程：

主要方法: Token.Companion.m() - getToken方法

输入: URI路径 + 参数Map
计算: hash_timestamp 格式的字符串
使用AES加密（密钥: 7A3II/M5Ja0S4gdf）
Hash计算: Token.Companion.k()

拼接: uri + 排序后的参数 + "mVjdXyqwjlEptwYY"
使用MurmurHash算法计算hash值
AES加密: AES.Companion.b()
算法: AES/CBC/PKCS5Padding
密钥: 7A3II/M5Ja0S4gdf
IV: 16-Bytes--String
输出: Base64编码
Hook脚本功能
脚本会拦截以下关键方法：

Token.getToken() - 捕获token生成
MurmurHash.d() - 捕获hash计算
AES.encodeAES() / AES.decodeAES() - 捕获加解密
SignatureUtil.sign() - 捕获签名生成
Token.getHash() - 捕获内部hash计算
Token.getUrlParamsByMap() - 捕获参数拼接
使用方法：

frida -U -f <包名> -l token_hook.js --no-pause

说的有模有样的，赶紧跑下代码试试。

我去，没效果

不对 没有hook到

AI 又开始干活了，咱们继续扫雷。

过了几分钟，新的代码又搞完了，继续跑。还是没有效果

还是没有

AI 继续干活，咕嘟嘟，干了一通，扔给我了一个新的代码

[+] TokenUtil.f() - Calculate Hash
    Input1: /v1/category/female
    Input2: channel=zxf2019_19206_001&os=Android&package=cn.ttkmfxs.novel&udid=01bb90d6de80f3cb01bb90d6de80f3cb&v=3.3.24.R
    Hash: -1926105764

[+] TokenUtil.e() - AES Encrypt
    Plain: -1926105764_1766754803859

[+] AES.b() - Encrypt
    Value: -1926105764_1766754803859
    Key: @cLjKxIl7hlto3tR
    Encrypted: nADo5PoDE0nEwN6gKB9L8WF9OzAmwqviEgy/ljE1DI0=
    Encrypted: nADo5PoDE0nEwN6gKB9L8WF9OzAmwqviEgy/ljE1DI0=
    Generated Token (URL encoded): nADo5PoDE0nEwN6gKB9L8WF9OzAmwqviEgy%2FljE1DI0%3D

oh yeah，这次成功了。感觉和玩大转盘差不多，多玩几次，总会有惊喜。

三、总结

有种赛博求签的感觉，心诚则灵。理解了有些人有事就扑通跪倒在佛像前面，感情佛祖也是AI的一种。

基本功还是得有的，不然被ai骗人都不知道咋回事。

1:ffshow

天地无穷期，生命则有穷期，去一日，便少一日；富贵有定数，学问则无定数，求一分，便得一分。

关注微信公众号，最新技术干货实时推送

不让我用？这个真不能忍 - 某视频App强制启动

Sat, 20 Dec 2025 10:09:49 +0800

一、目标

1:show

朋友给我发了一个看直播的App,刚一启动，硕大的弹窗就崩脸上了。这个真忍不了，盘它。

二、步骤

Jadx

先给他拆开，搜字符串，激活本应用

<string name="unknown_device">当前设备暂不支持激活本应用。</string>

代码里面没找到痕迹，在资源里面居然找到了。反编译的类列表太干净了，感觉可能加固了。

1:show

也没有发现这个字符串在代码中被调用的地方，肯定是加固了

关门，上AI

万能的AI，帮我生成一个 Frida hook脚本，捕获 res/layout/dialog_double_button.xml 弹窗显示位置和堆栈，

有了AI，人人都是工程师

// Hook AlertDialog.show()
var AlertDialog = Java.use("android.app.AlertDialog");
AlertDialog.show.implementation = function() {
    console.log("\n================================================================================");
    console.log("[*] AlertDialog.show() 被调用 ");
    console.log("================================================================================");

    console.log("\n[*] 调用堆栈:");
    console.log(Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Exception").$new()));
    console.log("================================================================================\n");

    return this.show();
};

跑一下，没反应，frida直接挂了。

先不急着问AI，咱们之前分析这个App大概率加固了，所以检测frida应该是基操。

咱们换上魔改版的Frida

https://github.com/Ylarod/Florida

再跑一下

================================================================================
[*] AlertDialog.show() 被调用
================================================================================

[*] 调用堆栈:
java.lang.Exception
        at android.app.Dialog.show(Native Method)
        at com.gXXX.tv.gXX.utils.x2.a(NoticeUtils.java:125)
        at com.gXXX.tv.gXX.activity.BaseActivity.g(BaseActivity.java:1)
        at com.gXXX.tv.gXX.activity.BaseActivity.onLoginEvent(BaseActivity.java:6)
        at com.gXXX.tv.gXX.activity.WelcomeActivity.onLoginEvent(WelcomeActivity.java:1)
        at java.lang.reflect.Method.invoke(Native Method)

这次比较顺利，逮住了

脱壳

这次脱壳用的是老朋友 BlackDex

https://github.com/ZiTanIOI/newBlackDex

这次感觉是猛壳，所以在软件设置里勾上深度脱壳和主动调用

双手合十，默念芝麻开门

图灵保佑，壳拖出来了。

Jadx一下，然后搜索 onLoginEvent

打开 BaseActivity.onLoginEvent

1:login

这哥们也真累，一堆判断，一言不合就掀桌子退出。

不怕，哥是有AI的，把整个onLoginEvent函数的代码喂给AI

请帮我生成Frida Hook脚本，hook住onLoginEvent函数的所有判断，定位一下到底是在哪里退出的。

吭哧吭哧，AI给我生成了一堆代码，看的眼花缭乱。

这不行，还得古法上，硅基暂时让步，碳基上位。我们观察一下这个函数的代码还是很规整的，每次判断退出都会有提示。

呼唤AI

请帮我生成Frida Hook脚本，hook住com.gXXX.tv.gXX.activity.BaseActivity.c , 加上异常处理，没有找到这个类就100毫秒之后重试 。

因为这个是加壳应用，所以需要给壳一个解密的时间，直接hook是找不到 com.gXXX.tv.gXX.activity.BaseActivity 类的。

AI写的代码就是漂亮

Java.perform(function() {
    console.log("[*] 开始Hook BaseActivity.c");

    function tryHook() {
        try {
            var BaseActivity = Java.use("com.gXXX.tv.gXX.activity.BaseActivity");

            BaseActivity["c"].overload('java.lang.String').implementation = function(str) {
                console.log("BaseActivity.c is called: str=" + str);
                this["c"](str);
            };


            console.log("[+] BaseActivity.c Hook成功");
            return true;

        } catch (e) {
            console.log("[-] Hook失败: " + e.message);
            return false;
        }
    }

    function hookWithRetry() {
        if (!tryHook()) {
            console.log("[*] 100ms后重试...");
            setTimeout(hookWithRetry, 100);
        }
    }

    hookWithRetry();
});

好了，发现提示

onLoginEvent false showErrorTerminalDialog and SendErrorPingback

原来第一个判断 isTerminalFailStatus 就挂掉了

啥也不说了，增加一个 Hook

let BaseLoginTask = Java.use("com.gXXX.tv.gXX.service.task.BaseLoginTask");
BaseLoginTask["isTerminalFailStatus"].implementation = function (i) {
    console.log(`BaseLoginTask.isTerminalFailStatus is called: i=${i}`);
    let result = this["isTerminalFailStatus"](i);
    console.log(`BaseLoginTask.isTerminalFailStatus result=${result}`);
    return false;
    // return result;
};

完美收工。

三、总结

不要给你的对手太明显的提示。

不要太相信AI，如果你不知道自己在干什么，AI也不知道。

脱壳是玄学，多试几个方案，万一运气到了呢？

1:ffshow

雪之妙在能积，云之妙在不留，月之妙在有圆有缺

关注微信公众号，最新技术干货实时推送

给你的Ida插上翅膀

Fri, 19 Dec 2025 11:46:43 +0800

一、目标

“小x同学，把0x1011218f 的函数中的花指令去除掉”。

最近飞哥已经陷入到AI中无法自拔，感觉以后古法分析都快要成非遗了，以后的标题都得是"传承三十年，古法纯手工去花指令，定位关键算法"。

二、步骤

你的Ida Python在哪里？

首先你得知道你的ida python是谁？在哪里？

原则一，不要用系统的python，不然你乱七八糟装一堆包，把系统的python干坏了，就废了，最好创建一个虚拟环境，这个python只给ida用

/Applications/IDA Professional 9.1.app/Contents/MacOS

目录下面找到 idapyswitch

fenfei@fenfei-Mac-Studio MacOS % ./idapyswitch
The following Python installations were found:
    #0: 3.13.0 ('') (/opt/homebrew/Cellar/python@3.13/3.13.5/Frameworks/Python.framework/Versions/3.13/Python)
    #1: 3.12.0 ('') (/opt/homebrew/Cellar/python@3.12/3.12.10/Frameworks/Python.framework/Versions/3.12/Python)
    #2: 3.11.0 ('') (/opt/homebrew/Cellar/python@3.11/3.11.12/Frameworks/Python.framework/Versions/3.11/Python)
    #3: 3.10.0 ('') (/opt/homebrew/Cellar/python@3.10/3.10.17/Frameworks/Python.framework/Versions/3.10/Python)
    #4: 3.9.0 ('') (/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/Python3)
    #5: 3.9.0 ('') (/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/Python3)
Please pick a number between 0 and 5 (default: 0)

可以看到我现在ida 用的是 py3.13

然后使用 conda 装个虚拟环境，然后里面也装python3.13

conda create -n ida_env python=3.13

修改 /Applications/IDA Professional 9.1.app/Contents/MacOS/python/init.py

增加一行 sys.path.append("/opt/miniconda3/envs/ida_env/lib/python3.13/site-packages")

恭喜你，从此以后你的ida python就专款专用了

可以确认一下你的配置是否正确，

插上翅膀

https://github.com/mrexodia/ida-pro-mcp

mcp是什么？这个得问ai

MCP 一般指的是 Model Context Protocol（模型上下文协议）。

一句话版理解（先看这个）

MCP = 给 AI 规定的一套“插件 / 外挂接口标准”

就像：

USB 是硬件接口标准
HTTP 是网络接口标准
MCP 是 AI 调用外部能力的接口标准

其实你就理解成，ida mcp 可以让AI ide 直接操作你的ida

我们开始安装 ida mcp

# 进入ida专用py环境
conda activate ida_env
pip uninstall ida-pro-mcp
pip install https://github.com/mrexodia/ida-pro-mcp/archive/refs/heads/main.zip
ida-pro-mcp --install

ok了，安装完毕，打开 ida ，找个样本反编译，然后 Edit → Plugins → MCP

[MCP] Server started:
  Streamable HTTP: http://127.0.0.1:13337/mcp
  SSE: http://127.0.0.1:13337/sse
  Config: http://127.0.0.1:13337/config.html

这就是启动成功，

配置AI IDE

打开你常用的 AI IDE，包括不限于 Cursor / CodeGeeX / Trae / Codebuddy

配置 MCP

{"mcpServers":{"ida":{"transport":"sse","url":"http://127.0.0.1:13337/sse","alwaysAllow":["idb_meta","list_funcs","disasm","decompile","lookup_funcs","analyze_funcs","get_bytes"]}}}

出来这个效果

1:idamcp

可以开始了

从ida mcp中，请把 0x101159B88 函数的花指令去掉

从ida mcp中，请帮我分析一下 xid 是如何生成的， 生成frida hook 脚本 跟踪一下。

嗯真香

三、总结

感觉ai进步了，以前红极一时的 AI Prompt 没那么重要了，反正我说的 AI 基本都能听懂。

古法纯手工还有没有意义？有个网友说过你不会的别指望 ai 会，你能用 ai 搞出来是因为你会

1:ffshow

插上翅膀的人是天使，插上翅膀的老鼠是蝙蝠

关注微信公众号，最新技术干货实时推送

别被外壳骗了，那只是柔软的伪装 - 某小说App Token算法分析

Mon, 13 Oct 2025 13:18:21 +0800

一、目标

1:token

今天的目标是这个 token 参数的算法,这个样本比较适合初学者，难度1星。

二、步骤

脱壳

先把apk拉进jadx

1:ke

很明显不对劲，这种只有2-3个类的，就是加壳之后的明显特征，至于加了什么壳， qihoo 已经很明白告诉我们了，就是数字壳。

之前的教程我们介绍过 FRIDA-DEXDump脱壳或者刷个脱壳rom，当然最方便的还是找个脱壳云服务。(私信给我，我把云服务的地址发你)

字符串查找

1:token

这种 com.bytexxx / com.baidx / com.ss 之类的看上去就很妖艳的都是大厂的sdk，都是来迷惑你的道心的。

只有像这种带着app包名中类似单词的才是你的小清新。

token长得很想base64，所以我们点 com.novel.basic.token.Base64 进去看看,看上去是一个自己实现的base64类。

没看出有啥特别的，先不管，我们从左边展开类名，看看 com.novel.basic.token 包下面还有哪些类？

1:tokensrc1

神奇的是，我们没有找到 com.novel.basic.token 包，也许是dump的时候丢了。更神奇的是，我们找到了一个 com.novel.basic.token.xz 包，里面有个看上去浓眉大眼的 TokenUtil类

public class TokenUtil {
    ...

public static String g(Map<String, String> map) {
        ArrayList<String> arrayList = new ArrayList(map.keySet());
        Collections.sort(arrayList);
        StringBuffer stringBuffer = new StringBuffer();
        for (String str : arrayList) {
            String str2 = map.get(str);
            stringBuffer.append("&");
            stringBuffer.append(str + "=" + str2);
        }
        return stringBuffer.toString().substring(1, stringBuffer.length());
    }

    public static String h(String str, String str2) {
        String str3;
        try {
            str3 = e(f(str, str2) + "_" + System.currentTimeMillis());
        } catch (Exception e) {
            e.printStackTrace();
            str3 = "";
        }
        return d(str3);
    }

    public static void i(String[] strArr) throws Exception {
        HashMap hashMap = new HashMap();
        hashMap.put(PackageDocumentBase.OPFTags.packageTag, "com.mianfeinovel");
        hashMap.put("os", "android");
        hashMap.put("v", "1.0.1");
        hashMap.put("channel", "blf1298_12243_001");
        hashMap.put("udid", "aaaaaaaaaaaa");
        String g = g(hashMap);
        System.out.println("/v1/recommend/female?" + g + "&token=" + h("/v1/recommend/female", g));
    }

...
}

从 i 函数上分析， token的运算很有可能是 h函数干的，那就啥也不说了，hook先

Hook验证

function main() {
    Java.perform(function () {
        var threadef = Java.use('java.lang.Thread');
        var threadinstance = threadef.$new();

        let TokenUtil = Java.use("com.novel.basic.token.xz.TokenUtil");
        TokenUtil["h"].implementation = function (str, str2) {
            console.log(`TokenUtil.h is called: str=${str}, str2=${str2}`);
            let result = this["h"](str, str2);
            console.log(`TokenUtil.h result=${result}`);
            return result;
        };

    });
}

setTimeout(main, 5000);
// setImmediate(main);

由于是加壳应用，所以需要延迟个几秒再去hook对应的函数，给壳一点加载的时间。

跑一下，运气不错，就是我们要的结果

[M2010J19SC::cn.ttkmfxs.novel ]-> TokenUtil.h is called: str=/v1/ipcn, str2=channel=zxf2019_19206_001&ip=&os=Android&package=cn.ttkmfxs.novel&udid=01bb90d6de80f3cb01bb90d6de80f3cb&v=3.3.24.R
TokenUtil.h result=B993s65X5IwPTsXrgV%2F2rNvCYKcIjT4lyXrthojQ0LY%3D

三、总结

这个样本的算法比较清晰，可以直接扣出java代码，或者让ai转成其他的语言。

很多加壳应用最大的难点就是壳，敲开壳之后就是一马平川了。

做逆向运气很重要，真的。

1:ffshow

坚硬只是表现

关注微信公众号，最新技术干货实时推送

程序员跑路了，李老板要求把App换个图标和名称

Mon, 19 May 2025 12:48:32 +0800

一、目标

李老板：奋飞呀，给咱们开发Android App的程序员删库跑路了，明天投资人就要过来，咱们得把App换个图标和名字呀？

奋飞：这个得先把五一的加班费结一下。

二、步骤

拆包

Android App的安装包Apk文件本质上是一个zip压缩包，直接把后缀改成zip，就可以解压，然后修改完再压缩回去不就行了？本文完……

现实是没有那么简单的，作为逆向工程师，必须要把简单的事情复杂化，这样才能体现你的价值。

解压在我们这里不叫解压，叫拆开安装包，简称拆包。是不是立马高大上了。

因为Apk的安装包有一些特殊处理，所以我们需要用特殊的工具去拆包 apktool

# d 拆包
# f 待拆包的apk
# o 输出拆包结果的文件夹
apktool d -f example.apk -o tmp_apk_dir

修改文件

App的名字等字符串信息一般都是放在

…/tmp_apk_dir/res/values/strings.xml

这个xml文件里面

把 <string name="app_name">xx本子</string>

改成 <string name="app_name">李老板本子</string>

App的图标一般都是放在

tmp_apk_dir/res/mipmap-xhdpi/icon.png

其他的mipmap-xxx文件夹是不同分辨率下的图标，可以统统给他换了。

打包，签名

修改好了之后就可以用 apktool重新打包了

apktool b tmp_apk_dir -o unsigned_new.apk

签名文件是为了证明这个apk是你的，防止被别人篡改，所以咱们修改了apk之后，由于没有原始的签名文件，只能生成一个新的。

keytool -genkey -v -keystore my-release-key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias mykey

参数解释：

-keystore my-release-key.jks：生成的签名文件名。

-keyalg RSA：加密算法。

-keysize 2048：密钥长度。

-validity 10000：证书有效期（单位：天）。

-alias mykey：密钥别名，可自定义。

最后一步就是给重新打包的apk做签名了

apksigner sign --ks my-release-key.jks --ks-pass pass:fenfei --ks-key-alias mykey --out your_app_new.apk unsigned_new.apk

1:setup

看上去没啥问题，不过我们细心的码农还是会启动验证一下,看看有没有问题。

1:start1

坏蛋，果然给我们埋坑了。

过坑

跑路的程序员还是厚道，明明白白告诉咱们是由于签名被篡改了。

上jadx，搜索签名被篡改

1:modify1

需要把这个 if判断干掉

问了一下AI，把对应的 Smail 代码中对应的 if-nez p1 改成 if-eqz p1 就行了

TIP:

| if-nez p1 | 如果 p1 != 0，则跳转（非零成立） |

| if-eqz p1 | 如果 p1 == 0，则跳转（零成立） |

真的没必要去学Smail语法了，现成的AI在嗷嗷待哺

三、总结

由于apk修改起来太容易了，所以程序员gg们会在里面埋更多的坑。加壳反调试混淆前面还有无数困难等着你。

李老板决定还是招个程序员鼓励师比较靠谱。

1:ffshow

非真空不宜谈禅，非真旷不宜饮酒。

关注微信公众号，最新技术干货实时推送

结合AI对WhatsApp的分析（三）

Sun, 13 Apr 2025 11:52:20 +0800

一、目标

书接上文结合AI对WhatsApp的分析（二），我们找到了 jnidispatchOO ，下一步就是搞定它的具体算法。

二、步骤

先HOOK

let JniBridge = Java.use("com.whatsapp.wamsys.JniBridge");
JniBridge["jnidispatchOO"].implementation = function (i, obj) {

        let bCls = Java.use('[B')

        if(i == 3){
                let buffer = Java.cast(obj, bCls);
                let rc1 = Java.array('byte', buffer);

                console.log(` ---- JniBridge.jnidispatchOO is called: i=${i}, obj=${buf2hex(rc1)}`);
        }

        let result = this["jnidispatchOO"](i, obj);

        if(i == 3){
                let buffer2 = Java.cast(result, bCls);
                let rc2 = Java.array('byte', buffer2);

                console.log(` ---- JniBridge.jnidispatchOO result = ${buf2hex(rc2)}`);
        }
        return result;
};

跑一下

 ---- JniBridge.jnidispatchOO result = 3045022031c495bb8bf2bbe39124b0c539cc0929e3d6cf1960874ecd019a0e7412160506022100a056754c60d842fd2e12aa06fd00aae06999d8808e213875424e4489ce26ff28

// 对应的 base64 = MEUCIDHElbuL8rvjkSSwxTnMCSnj1s8ZYIdOzQGaDnQSFgUGAiEAoFZ1TGDYQv0uEqoG/QCq4GmZ2ICOITh1Qk5Eic4m/yg=

确认了眼神，这次没错了

上Jadx

public static Object jnidispatchOO(int i, Object obj) {
    ...
     case 3:
        byte[] bArr2 = (byte[]) obj;
        C51032Wh c51032Wh = (C51032Wh) INSTANCE.jniCallbacksIJniCallbacks.A04.get();
        if (!AbstractC17350u8.A01() || bArr2 == null) {
            return null;
        }
        // 这个 A01.A07 应该就是计算H的位置
        return c51032Wh.A01.A07(bArr2, c51032Wh.A00.A0J());
    ...
}

// X.17J
 public byte[] A07(byte[] bArr, byte[] bArr2) {
        byte[] bArr3 = null;
        if (!A06()) {
            return null;
        }
        A02(C00Q.A01, bArr2);
        long elapsedRealtime = SystemClock.elapsedRealtime();
        try {
            try {
                                // 从android的KeyStore拿到密钥
                KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
                keyStore.load(null);
                KeyStore.Entry entry = keyStore.getEntry(A01(), null);
                if (entry instanceof KeyStore.PrivateKeyEntry) {
                    Signature signature = Signature.getInstance(AbstractC15060oI.A01(C15080oK.A02, this.A02, 2075));
                    signature.initSign(((KeyStore.PrivateKeyEntry) entry).getPrivateKey());
                    signature.update(bArr);
                                        // H 就是这里来的
                    bArr3 = signature.sign();
                } else {
                    Log.e("blacknoise/Not an instance of a PKEntry");
                    this.A04.A0H("attestation-nosign", "cannot sign payload, att pair missing", true);
                }
            } catch (Exception e) {
                Log.e("blacknoise/exception on pair sign", e);
                AbstractC213314r abstractC213314r = this.A04;
                StringBuilder sb = new StringBuilder();
                sb.append("unable to sign payload: ");
                sb.append(e.getMessage());
                abstractC213314r.A0F("attestation-nosign", sb.toString(), e);
            }
            return bArr3;
        } finally {
            C17K c17k = new C17K();
            c17k.A00 = Long.valueOf(SystemClock.elapsedRealtime() - elapsedRealtime);
            c17k.A02 = "att-sign";
            this.A06.CG2(c17k);
        }
    }

我们再 Hook一下 java.security.Signature.getInstance

var Signature = Java.use("java.security.Signature");

Signature.getInstance.overload("java.lang.String").implementation = function(algorithm) {
        console.log(`/* TID ${gettid()} */` + "[*] Hooked Signature.getInstance");
        console.log("    Algorithm: " + algorithm);
    return this.getInstance(algorithm);
};

// 打印
/* TID 10091 */[*] Hooked Signature.getInstance
    Algorithm: SHA256withECDSA

这次形势明朗了 SHA256withECDSA

App生成一对ECDSA的公钥和私钥，本地用私钥给数据做sign，把公钥和sign结果传给服务器，服务器用公钥去做verify。

把这些数据扔给AI，AI轻松就把Demo代码写好了。

新的问题，证书不对。

公钥上传的位置只有一种可能，放在请求头的 Authorization

新的问题是，AI给我生成的公钥是91个字节，明显小于 Authorization

继续问AI

ME: MIIFHDCCAwSgAwIBAgIJANUP8luj8tazMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNV(完整的Authorization头贴上去) 为什么这个证书这么长，我只需要SHA256withECDSA的公钥证书，应该是91个字节才对

AI: 你贴的是一大串 Base64 编码后的证书链，这其实是**X.509 证书（或多个）**的完整内容，被编码成了一大段字符串，常见于 .pem 或 .crt 文件中。
确实看起来非常长，但这并不是“公钥”的长度，而是整个证书的编码内容。

解答你的两个关键疑问：
❓ 1. 为什么这个证书这么长？
因为它不仅仅包含公钥，而是包含了：

签名算法标识（如 SHA256withECDSA）
公钥（你想要的）
证书所有者信息（issuer, subject, 序列号等）
有效期（not before / not after）
签名值
扩展字段（可能还包含 CA 标识、密钥用法等）
这些内容都被 ASN.1/DER 格式编码，然后再被 base64 编码，所以变得很长。

❓ 2. 我只需要 SHA256withECDSA 的公钥部分，应该是 91 字节左右，怎么提取？
你说的“91字节”是 ECDSA P-256（secp256r1）曲线上的压缩公钥长度：

压缩格式：33 字节
未压缩格式：65 字节
公钥 DER 编码结构，整体会有 91 个字节左右（SEQUENCE -> BIT STRING -> ECPoint）

需要哪种？可以直接发一句：“帮我提取公钥（hex）”之类的，我马上给你。

必须要，帮我写个python代码把里面的 SHA256withECDSA 提取出来，然后写个 verify 的Demo。

三、总结

AI不能直接帮你写好ws的H算法，但是能按照你的思路辅助你把H算法写出来。

1:ffshow

AI只是强健的四肢+翅膀，你才是大脑，决定飞向哪里

关注微信公众号，最新技术干货实时推送

结合AI对WhatsApp的分析（二）

Sat, 29 Mar 2025 11:52:07 +0800

一、目标

书接上文结合AI对WhatsApp的分析（一），我们已经定位了 H 参数，下一步就是分析一下它的来历。

二、步骤

堆栈定位

H 被计算的位置有两种可能，一种是java层，一种是Native层，我们先顺着堆栈往上找

1:stack1

柿子得找软的捏，我们先从java层找起，hook 这个 com.whatsapp.wamsys.JniBridge.jvidispatchIOOOOOOOOOO

let JniBridge = Java.use("com.whatsapp.wamsys.JniBridge");

JniBridge["jvidispatchIOOOOOOOOOO"].implementation = function (i, obj, obj2, obj3, obj4, obj5, obj6, obj7, obj8, obj9, obj10) {
    console.log(`======== JniBridge.jvidispatchIOOOOOOOOOO is called: i=${i}, obj=${obj}, obj2=${obj2}, obj3=${obj3}, obj4=${obj4}, obj5=${obj5}, obj6=${obj6}, obj7=${obj7}, obj8=${obj8}, obj9=${obj9}, obj10=${obj10}`);


    let bCls = Java.use('[B')
    let buffer = Java.cast(obj6, bCls);
    let rc = Java.array('byte', buffer);

    console.log("obj6 = " + buf2hex(rc));

    buffer = Java.cast(obj7, bCls);
    rc = Java.array('byte', buffer);
    console.log("obj7 = " + buf2hex(rc));

    let result = this["jvidispatchIOOOOOOOOOO"](i, obj, obj2, obj3, obj4, obj5, obj6, obj7, obj8, obj9, obj10);
    console.log(` ======== JniBridge.jvidispatchIOOOOOOOOOO result=${result}`);
    return result;
};

跑这个 hook 的时候，可以先把之前的Base64的hook代码注释掉，这样看上去清晰一些。

jvidispatchIOOOOOOOOOO 的入参是一大堆明文，返回值是 0 。貌似是成功的意思，

摸不到头脑，这时候不得不怀疑 H 是在Native层去计算的，下一步的解决方案就是Native层的Trace，然后汇编层一行一行去找。不过悲催的是，这条路是错的，我就不给大家展开了，下次走对了，我再介绍这个玩法。

frida模块化编程,代码也要精致生活

在进行下一步之前，我们先把代码整整，一个js越写越多，多的都有几千行了，太不帅了，咱们得搞个起码的模块化，把一些常用的函数封装到单独的js中，buf2hex 之类的

首先新建一个目录 utils ,在目录下面新建一个byteTolib.js，然后把buf2hex拷贝进去，函数名之前加一个export

// 将意大利面条代码改造成米其林餐厅
// ./utils/byteTolib.js
export function buf2hex(buffer) {
....
}

// ws2demo.js
import {
    buf2hex,
} from "./utils/byteTolib.js";

然后在ws2demo.js加一个import就可以调用buf2hex函数了。

实际跑的时候不再是直接跑ws2demo.js

而是先启动一个控制台

frida-compile -w ws2demo.js -o ws2demo-agent.js

把ws2demo.js编译成ws2demo-agent.js，这个控制台就不要关了，他会监控原始文件的修改，实时生成编译后的文件。

frida -Uf com.whatsapp --runtime=v8 -l ws2demo-agent.js

在另外一个控制台中实际执行ws2demo-agent.js，这下代码就清晰多了

JNI Trace

飞哥已经花了几天功夫走了一下弯路，证明了H的计算不在Native里面，但是我们从java的堆栈X.6zL这些类里面又没有发现蛛丝马迹。

真相只有一个，那就是Native中通过JNI调用java来计算。要分析这种类型的调用，我们只需要参照以前的文章 Trace大盘点 ,用上飞哥独家定制的jniTreace工具。

在hook jvidispatchIOOOOOOOOOO的时候增加一个 hook_all_jni()

ffJNITrace: ======== /* TID 18362 */ JNIENv->CallObjectMethod java/lang/Class->0x6f6eb168 0x81
...
ffJNITrace: ======== /* TID 18362 */ JNIENv->CallStaticObjectMethodV java/lang/Class->0x7082dd30 rc = 0x75
...

ffJNITrace:/* TID 18362 */  JNIENv->GetByteArrayElements was called args[1] = 0x29, args[2] = 0x0
ffJNITrace: ======== byteLen = 71
ffJNITrace: ======== 3045022100830c97dd97a5526a29d6b8639b26b341a50b629d40462ed0b992b8521e47972502200e09492a06883ddb4d4350bb65ef9f1796d309e5c87245cba4842d994d14302b

又接近了一点，本以为可以从 CallObjectMethod 或者 CallStaticObjectMethodV 找到线索，也许是我的hook代码有问题，这里还是没有精准定位的东西。

traceClass

从之前的分析来看 com.whatsapp.wamsys.JniBridge 类可能是个很重要的类，我们把它也trace上

traceClass("com.whatsapp.wamsys.JniBridge");

再跑一下，

....
*** exiting com.whatsapp.wamsys.JniBridge.jnidispatchOO
ffJNITrace: ======== /* TID 18938 */ JNIENv->CallStaticObjectMethodV java/lang/Class->0x9e37e2e0 rc = 0x29
ffJNITrace:/* TID 18938 */  JNIENv->GetByteArrayElements was called args[1] = 0x29, args[2] = 0x0
ffJNITrace: ======== byteLen = 70
ffJNITrace: ======== 304402205492ecfb34b84941e1179d1e7aab840f6430e55a279f7f6958f20d29a2efefbd022006a9dce0cebc6d02b6e3359384bfb82a30c0e77c9fdd8aed89e2963e3029da29

兄弟们，这下跑不掉了，就是 jnidispatchOO

三、总结

当Java层过于干净时，记得检查它有没有Native层的"外国亲戚"，每个完美的隐身，都可能在JNI调用中露出马脚。

1:ffshow

你要是一直被带着跑，就像跟着波浪起起伏伏；但如果你能看透一切波动，直接做那片安静的水，那你就赢了！

关注微信公众号，最新技术干货实时推送

结合AI对WhatsApp的分析 (一)

Thu, 13 Mar 2025 15:46:38 +0800

一、目标

1:main

好希望未来的世界是这样的:

小X同学，请帮我写一个ws的H算法，并且详细解释入参和结果。

可惜现实是这样的

1:ws1

也好，起码飞哥还不至于失业，李老板还得老老实实给我发工资。然后含泪退掉了他偷偷买的4090，原计划他准备搭个DeepSeek来优化我的。

二、步骤

遇事不决先问AI

工具是死的，人是活到。个人认为目前的AI，抹平了初级程序员和中级的程序员之间的技术差距。但是抹平不了李老板和入门级的程序员之间的技术差距。

作为一个有证的程序员，应该这样问AI才靠谱

1:ws2

这里面的关键信息就是 AES SHA256 和 libwhatsapp.so 了，

找朋友 libwhatsapp.so

我们遇到的第一个困难就是，最新版的apk里面只有libsuperpack.so 和 libunwindstack.so，并没有我们期待的 libwhatsapp.so

不过这也难不倒我们，继续问AI呗。这次 AI给出了几个方案，它怀疑 WhatsApp 可能已经将多个 .so 库合并进一个单独的 libsuperpack.so 文件，减少 APK 体积并提高加载效率。

所以我们先安装Apk，然后用上最原始的查找大法

find / -name 'libwhatsapp.so' -type f

# 结果出来了
/data/user/0/com.whatsapp/files/decompressed/libs.spo/libwhatsapp.so

IDA

这个 H 一看就是个Base64，所以第一反应就是 hook java的 base64函数，但是没有结果，那就说明大概率是在 so里面做的base64。

这时候就请IDA上场了。

我感觉下一个版本的ida可能就会增加AI窗口了，咱们直接输入一个:

请帮我标出这个so中做Base64操作的函数，并且生成frida Hook的代码

好吧，在ida没有更新之前，只能飞哥上场了。

挂上心爱的 FindCrypt插件

1:ida1

啥也不说了，先Hook它

    let libWhatsAppAddress = Module.findBaseAddress('libwhatsapp.so');
    console.log(" ==> libwhatsapp : " + libWhatsAppAddress)

    let offset = 0x89F7C8;
    let funcAddr = libWhatsAppAddress.add(offset);
    Interceptor.attach(funcAddr, {
        onEnter: function(args) {
        },
        onLeave: function(retval) {

            console.log('--> retval: ' + retval);
            try {
                let strIn = Memory.readUtf8String(retval);
                console.log(strIn);
            } catch (e) {
                Log( "#### Base64 A Rc Error");
            }

            console.log(`/* TID ${gettid()} */ =======  Base64 A retval ====`);
        }
    });

跑一下，熟悉的味道

1:rc1

三、总结

再强调一遍，以后的程序员只会有一种，利用辅助AI工具的程序员。不会使用AI的程序员一定是要被淘汰的。

早用早享受，不用担心AI会替代你，AI的出现只会让你的工作更加高效。以此为理由找李老板提加工资。

1:ffshow

这台机器不会取代我们任何一个人

关注微信公众号，最新技术干货实时推送

DeepSeek分析DeepSeek App

Mon, 17 Feb 2025 11:28:22 +0800

一、目标

山中方一日，世上已千年。Chatgpt的喧嚣感觉还在昨天，DeepSeek已经迎面而来。今天我们就在DeepSeek的帮助下来分析DeepSeek App

POST https://chat.deepseek.com/api/v0/chat/completion HTTP/2
host: chat.deepseek.com
x-ds-pow-response: eyJhbGdvcml0aG0iOiJEZWVwU2Vla0hhc2hWMSIsImNoYWxsZW5nZSI6ImNlYmFiNGFhOGU1MDk1NTY2NmY1ODk4MTZjNjY4MTExNDRlMDU2YThmNDFjNDNhNDNiZDc4Y2VkYzRiNWY0YTEiLCJzYWx0IjoiODM2MGY4YzkyMDVjOTZjMzJiN2EiLCJzaWduYXR1cmUiOiIxMGI3ODQ5YjFlNjIwM2IyODhkYzQ5NzVhMWUyMzc1M2VkOWQ2ZmI2NTY5NjRiOGU4NmRhZWJhYjM2MjhhNDBjIiwiYW5zd2VyIjo3NzkwNiwidGFyZ2V0X3BhdGgiOiIvYXBpL3YwL2NoYXQvY29tcGxldGlvbiJ9
x-client-platform: android

我们今天的目标是 x-ds-pow-response

二、步骤

Jwt?

eyjh开头，很像是jwt，所以第一反应就是去jwt在线解密一下。结果很遗憾，不是jwt

DeepSeek登场

把x-ds-pow-response的内容复制进DeepSeek的对话框，大大方方的问他， x-ds-pow-response可能是什么加密算法？

不出意外的话，意外出现了

服务器繁忙，请稍后再试。

应对方法是使用App :)

`x-ds-pow-response` 看起来像是一个包含某种加密或哈希算法响应的HTTP头部字段。根据你提供的内容，它包含了一个JSON对象，其中包含以下字段：

- `algorithm`: 指定了使用的算法，这里是 `DeepSeekHashV1`。
- `challenge`: 一个挑战字符串，可能是用于验证或防伪的随机值。
- `salt`: 盐值，用于增加哈希的复杂性。
- `signature`: 签名，可能是对某些数据进行哈希或加密后的结果。
- `answer`: 一个数值，可能是对挑战的某种计算结果。
- `target_path`: 目标路径，指示这个响应应该被应用到哪个API路径。

从这些信息来看，`DeepSeekHashV1` 可能是深度求索公司自定义的一种哈希算法，用于生成某种形式的数字签名或验证码。这种算法可能结合了挑战、盐值和目标路径来生成一个唯一的签名，以确保请求的完整性和来源的真实性。

由于这是自定义算法，具体的加密或哈希细节没有公开的标准可以参考。如果你需要更深入的了解，可能需要查阅深度求索公司的官方文档或联系他们的技术支持。

联系官方技术支持有点扯了，不过他为什么知道里面包含了Json对象，并且还知道这些明文？

继续问问，反正也不花钱？

问: 你怎么知道x-ds-pow-response的内容里面包含DeepSeekHashV1 ？

答: 我理解你的疑问。实际上，我并没有直接访问或解析你提供的 `x-ds-pow-response` 内容的能力。我的回答是基于你提供的文本内容进行的推测和分析。

在你提供的 `x-ds-pow-response` 中，有一个 JSON 对象，其中包含了一个字段 `"algorithm": "DeepSeekHashV1"`。这个字段明确指出了使用的算法是 `DeepSeekHashV1`。因此，我根据这个信息推断出 `x-ds-pow-response` 可能使用了 `DeepSeekHashV1` 这个算法。

如果你有更多关于这个字段的具体信息或上下文，我可以进一步帮助你分析和理解。

这个回答我不满意，看来我问的不对。

问: 如何从eyJhbGdvcml0aG0iOiJEZWVwU2Vla0hhc2hWMSIsImNoYWxsZW5nZSI6ImNlYmFiNGFhOGU1MDk1NTY2NmY1ODk4MTZjNjY4MTExNDRlMDU2YThmNDFjNDNhNDNiZDc4Y2VkYzRiNWY0YTEiLCJzYWx0IjoiODM2MGY4YzkyMDVjOTZjMzJiN2EiLCJzaWduYXR1cmUiOiIxMGI3ODQ5YjFlNjIwM2IyODhkYzQ5NzVhMWUyMzc1M2VkOWQ2ZmI2NTY5NjRiOGU4NmRhZWJhYjM2MjhhNDBjIiwiYW5zd2VyIjo3NzkwNiwidGFyZ2V0X3BhdGgiOiIvYXBpL3YwL2NoYXQvY29tcGxldGlvbiJ9
提取出 DeepSeekHashV1 字符串，请用python代码实现？

答: 要从 `eyJhbGdvcml0aG0iOiJEZWVwU2Vla0hhc2hWMSIsImNoYWxsZW5nZSI6ImNlYmFiNGFhOGU1MDk1NTY2NmY1ODk4MTZjNjY4MTExNDRlMDU2YThmNDFjNDNhNDNiZDc4Y2VkYzRiNWY0YTEiLCJzYWx0IjoiODM2MGY4YzkyMDVjOTZjMzJiN2EiLCJzaWduYXR1cmUiOiIxMGI3ODQ5YjFlNjIwM2IyODhkYzQ5NzVhMWUyMzc1M2VkOWQ2ZmI2NTY5NjRiOGU4NmRhZWJhYjM2MjhhNDBjIiwiYW5zd2VyIjo3NzkwNiwidGFyZ2V0X3BhdGgiOiIvYXBpL3YwL2NoYXQvY29tcGxldGlvbiJ9` 中提取出 `DeepSeekHashV1` 字符串，可以按照以下步骤实现：

1. 这是一个 Base64 编码的字符串，首先需要将其解码为 JSON 格式。
2. 解码后，解析 JSON 对象，提取 `algorithm` 字段的值。

以下是 Python 代码实现：

```python
import base64
import json

# Base64 编码的字符串
encoded_str = "eyJhbGdvcml0aG0iOiJEZWVwU2Vla0hhc2hWMSIsImNoYWxsZW5nZSI6ImNlYmFiNGFhOGU1MDk1NTY2NmY1ODk4MTZjNjY4MTExNDRlMDU2YThmNDFjNDNhNDNiZDc4Y2VkYzRiNWY0YTEiLCJzYWx0IjoiODM2MGY4YzkyMDVjOTZjMzJiN2EiLCJzaWduYXR1cmUiOiIxMGI3ODQ5YjFlNjIwM2IyODhkYzQ5NzVhMWUyMzc1M2VkOWQ2ZmI2NTY5NjRiOGU4NmRhZWJhYjM2MjhhNDBjIiwiYW5zd2VyIjo3NzkwNiwidGFyZ2V0X3BhdGgiOiIvYXBpL3YwL2NoYXQvY29tcGxldGlvbiJ9"

# 解码 Base64 字符串
decoded_bytes = base64.b64decode(encoded_str)
decoded_str = decoded_bytes.decode('utf-8')

# 解析 JSON 对象
data = json.loads(decoded_str)

# 提取 algorithm 字段的值
algorithm = data.get("algorithm")

print("提取的 algorithm 值:", algorithm)
```

### 代码说明：
1. **Base64 解码**：使用 `base64.b64decode` 将 Base64 编码的字符串解码为字节数据，然后转换为字符串。
2. **JSON 解析**：使用 `json.loads` 将解码后的字符串解析为 Python 字典。
3. **提取字段**：从字典中提取 `algorithm` 字段的值。

### 输出结果：
```plaintext
提取的 algorithm 值: DeepSeekHashV1
```

### 注意事项：
- 如果输入的 Base64 字符串无效，`base64.b64decode` 会抛出异常。
- 如果 JSON 格式不正确，`json.loads` 也会抛出异常。
- 确保输入的字符串是完整的 Base64 编码数据。

woo，这才答道点子上了，原来就是个Base64，程序员还是得用代码来说话。

把Base64解一下，明文出来了

{"algorithm":"DeepSeekHashV1","challenge":"cebab4aa8e50955666f589816c66811144e056a8f41c43a43bd78cedc4b5f4a1","salt":"8360f8c9205c96c32b7a","signature":"10b7849b1e6203b288dc4975a1e23753ed9d6fb656964b8e86daebab3628a40c","answer":77906,"target_path":"/api/v0/chat/completion"}

challenge,salt,signature,answer 这四个值是我们关注的要点了。

Jadx出马

搜索文本 DeepSeekHashV1

package com.deepseek.crypto;

/* loaded from: classes.dex */
public final class PowCalculator {

    /* renamed from: a, reason: collision with root package name */
    public static final PowCalculator f12608a = new PowCalculator();

    static {
        System.loadLibrary("rscrypto");
    }

    private final native long nativeCalculateDeepSeekHashV1Pow(String str, String str2, long j9);

    public final long a(long j9, String str, String str2) {
        return nativeCalculateDeepSeekHashV1Pow(str, str2, j9);
    }
}

先Hook这个 nativeCalculateDeepSeekHashV1Pow函数再说

        let PowCalculator = Java.use("com.deepseek.crypto.PowCalculator");
        PowCalculator["nativeCalculateDeepSeekHashV1Pow"].implementation = function (str, str2, j9) {
            console.log(`PowCalculator.nativeCalculateDeepSeekHashV1Pow is called: str=${str}, str2=${str2}, j9=${j9}`);
            let result = this["nativeCalculateDeepSeekHashV1Pow"](str, str2, j9);
            console.log(`PowCalculator.nativeCalculateDeepSeekHashV1Pow result=${result}`);

            var stack = threadinstance.currentThread().getStackTrace();
            console.log("Rc Full call stack:" + Where(stack));

            return result;
        };

跑一下

PowCalculator.nativeCalculateDeepSeekHashV1Pow is called: str=79385dcd26da6f3e7276_1739766754276_, str2=ce96433fd479a8648ba29145c2520a787102e145b2f8998ea81ddfe010c3d5a8, j9=144000
PowCalculator.nativeCalculateDeepSeekHashV1Pow result=63312
Rc Full call stack:dalvik.system.VMStack.getThreadStackTrace(Native Method)
 ds: java.lang.Thread.getStackTrace(Thread.java:1841)
 ds: com.deepseek.crypto.PowCalculator.nativeCalculateDeepSeekHashV1Pow(Native Method)
 ds: com.deepseek.crypto.PowCalculator.a(SourceFile:1)
 ds: C6.h.g(SourceFile:59)
 ds: C6.s.s(SourceFile:44)
 ds: za.a.j(SourceFile:6)
 ds: Wa.D.run(SourceFile:104)
 ds: db.a.run(SourceFile:127)

入参有 challenge,salt 返回值是下一次的 answer。

到此为止，我们知道了answer的生成，但是 challenge,salt,signature这三位大哥还是不知道。

顺着堆栈找

顺着这次hook的堆栈一直往上早。把有疑点的函数都hook上，结果绕了半天，没啥收获。

本来想问问DeepSeek这几个值是怎么来的，不过感觉应该没啥用。 AI呆住了，人脑上线了。问下DeepSeek应该如何描述这种情况。

技术文档版

「当AI系统触发逻辑僵局时，人工智控模块自动激活接管协议。」

（解析：采用"逻辑僵局-激活接管"的技术术语，符合系统架构文档的专业语境）

科幻叙事版

「量子矩阵的辉光骤然凝滞，生物神经元的星火在数据深渊中重燃。」

（解析：通过"量子矩阵-生物神经元"的意象对立，构建赛博朋克风格的场景画面）

商业方案版

「智能运算流中断0.3秒后，人类决策引擎无缝衔接启动，保障服务连续性。」

（解析：用"运算流-决策引擎"的工业隐喻，突出系统可靠性的商业价值）

哲学思辨版

「当算法陷入认知迷雾，意识的灯塔穿透数据海啸指引航向。」

（解析：通过"迷雾-灯塔"的隐喻体系，引发对人工智能局限性的深层思考）

应急响应版

「侦测到AI决策树坍缩，立即启动人类指挥官协议，完成μ级秒差切换。」

（解析：使用"坍缩-μ级秒差"等精准表述，强调应急响应的及时性）

诗歌化表达

「硅基的月光在逻辑悬崖搁浅，碳基的朝阳已攀上认知峰巅」

（解析：借"硅基-碳基"的物质属性差异，构建科技与人文交融的意境）

我喜欢这句话硅基的月光在逻辑悬崖搁浅，碳基的朝阳已攀上认知峰巅

Fiddler搜索

捍卫一下碳基生命的尊严，我认为challenge,salt,signature这三位大哥可能是服务器返回的。

搜一下吧 cebab4aa8e50955666f589816c66811144e056a8f41c43a43bd78cedc4b5f4a1

{
    "code": 0,
    "msg": "",
    "data": {
        "biz_code": 0,
        "biz_msg": "",
        "biz_data": {
            "challenge": {
                "algorithm": "DeepSeekHashV1",
                "challenge": "cebab4aa8e50955666f589816c66811144e056a8f41c43a43bd78cedc4b5f4a1",
                "salt": "8360f8c9205c96c32b7a",
                "signature": "10b7849b1e6203b288dc4975a1e23753ed9d6fb656964b8e86daebab3628a40c",
                "difficulty": 144000,
                "expire_at": 1739764288699,
                "expire_after": 300000,
                "target_path": "/api/v0/chat/completion"
            }
        }
    }
}

真相只有一个，本地死活找不到的时候，大概率就是服务器返回的了。Fiddler以后应该可以接入DeepSeek,直接提示我。这样量子矩阵的辉光就不容易凝滞了。

三、总结

以后的程序员只会有一种，利用辅助AI工具的程序员。不会使用AI的程序员一定是要被淘汰的。目前为止(以后的事就不好说了)再好的AI也是工具，要完成任务，决定性的因素还是掌握AI的人。

小时候看的小人书里，有个武林高手绝招是脑袋后面的辫子，叫神鞭。后来解放了，辫子剪了，人家依然是高手，叫神枪手。这位高手淡淡的说：鞭没了，神还在。

1:ffshow

当算法陷入认知迷雾，意识的灯塔穿透数据海啸指引航向

关注微信公众号，最新技术干货实时推送

浏览器内存漫游是什么鬼？

Tue, 05 Nov 2024 16:56:03 +0800

一、目标

进化之路上很重要的一个标志就是使用工具。js混来混去，导致很难厘清这个算法的前因后果，如果有个工具，可以把js运行过程中的所有变量的值都记录下来，那么针对流程混淆的js来说，就是大杀器了。

https://github.com/JSREI/ast-hook-for-js-RE 把所有涉及到变量改动的地方，都hook住，实现了一个变量值级别的Trace。可以很方便的搜索到你感兴趣的变量值是再哪一行代码赋予的。

二、步骤

安装阿里Anyproxy

AnyProxy是阿里开源的一个抓包工具，其原理与fiddler、charles一样，AnyProxy界面更简洁。

在mac系统下，先安装node

brew install node

然后安装 AnyProxy

brew install anyproxy

查看AnyProxy版本

anyproxy --version

最后安装AnyProxy证书

anyproxy-ca

在Chrome浏览器中安装 SwitchyOmega 插件

Anyproxy启动之后默认监听端口是 8001

我们在SwitchyOmega中创建一个情景模式proxy,代理到端口 8001

1:ast1

这样所有通过chrome调试的js都会被Anyproxy处理一遍。

开始干活

把ast-hook-for-js-RE代码clone下来

git clone https://github.com/JSREI/ast-hook-for-js-RE.git

然后进入到 ast-hook-for-js-RE目录,启动anyproxy

cd  /Users/xxx/Desktop/gitsrc/ast-hook-for-js-RE

//  启动anyproxy  myrules.js 判断js文件和解析html中的文件来替换 hook
anyproxy --rule ./src/proxy-server/myrules.js --intercept

使用JetBrains全家桶中的WebStorm IDE来打开ast-hook-for-js-RE项目，展开api-server.js，运行它

1:ast1

来个例子

http://91fans.com.cn/jsdemo/demo1.html

首先在Chrome里面打开这个链接，可以发现sign的计算是在 H5guard.js 里面完成的。这个js还是混的不算狠的，正好可以作为咱们入门的例子。

打开demo页面，进入开发者调试模式

1:ast1

你会发现，js代码中所有的变量都包裹上了 cc11001100_hook

它就会把所有的变量计算结果都会记录下来。

你可以使用

hook.search
hook.searchByName
hook.searchByValue

来搜索感兴趣的变量值，然后就可以定位到这个值被赋值的代码位置。

三、总结

趁手的工具可以使你的工作事半功倍，打磨和修改工具的能力也是很重要的。

1:ffshow

学道历千魔而莫退，遇辱坚百忍以自持

关注微信公众号，最新技术干货实时推送

初试js反混淆

Sat, 28 Sep 2024 17:46:06 +0800

一、目标

最近js玩的花样越来越多了，本来简洁方便的一门开发语言，现在混淆的一塌糊涂。今天我们就介绍几种常见的反混淆方案。

混淆的本质就是等价替换，把 a = 12 ,替换成 a = 100 - 8 + 5 - 15 - 70。把 "push" 替换成 "\u0070\u0075\u0073\u0068", 基本上就让你调试起来很难受了。

反混淆就是一个逆过程，上古时期用的是最简单的正则匹配，然后再替换。现在时代进步了，我们有了一个更强大的工具抽象语法树 (Abstract Syntax Tree)，简称 AST ,它以树状的形式表现编程语言的语法结构，树上的每个节点都表示源代码中的一种结构。这样可以更方便的实现对源代码的处理。

二、步骤

先搭个架子

最近比较喜欢用JetBrains全家桶，先用WebStorm创建一个Node js项目，然后在工程目录下面执行

npm install @babel/core --save-dev

来安装js的@babel库,用于将JS源码转换成语法树AST

# 更换成淘宝镜像
npm config set registry https://registry.npmmirror.com
# 查看当前镜像
npm config get registry

结果不好使，问下了谷哥，哥说，可能是使用了代理，被乱七八糟的代理影响了npm，可以尝试禁用代理：

npm config delete proxy
npm config delete https-proxy

哥是对的，现在好使了

Show me the code

var parser = require("@babel/parser");  // 将JS源码转换成语法树AST
var template = require("@babel/template").default;  // 为parser提供模板引擎
var traverse = require("@babel/traverse").default;  // 遍历AST树节点操作
var types = require("@babel/types");  // 操作节点，比如判断节点类型，生成新的节点等
var generator = require("@babel/generator").default;  // 将语法树AST转换为js代码

var fsrw = require("fs");   // 文件读取

var jscode = fsrw.readFileSync("./input/demo2.js", {encoding: "utf-8"});  // 读取原始混淆文件
var ast_parse = parser.parse(jscode);  //将JS源码转换成语法树AST


// 做处理
var traverses_2 = {
    ......
}

console.log(" traverses 处理 \\u00 ======== ");
traverse(ast_parse, traverses_2)

// 生成还原后的js文件
var ast_js_code = generator(ast_parse);
fsrw.writeFileSync('./output/demo2_out.js', ast_js_code.code)

这就是一个基础的AST反混淆处理框架。

先把待处理的文件读取出来，转成语法树AST，然后针对性的做处理，最后生成还原后的js文件

Demo1 \uxxx 转换

第一个例子是

var e = "\u002e\u0068\u006f\u006c\u0064\u0065\u0072";
...

它把字符串做了一次unicode编码，我们还原的时候只需要做个正则匹配，把 '\uxxx' 的字符串的extra 属性移除，就会重新解析成正常的字符串了

var traverses_2 = {
    // B. 处理Unicode字符串，针对"\u0068\u0065\u006c\u006c" 》》'hell'
    StringLiteral(path) {
        cur_node = path.node;
        if (cur_node.extra && /\\[ux]/gi.test(cur_node.extra.raw)) {
            cur_node.extra = undefined;
        }
    },
}

得到的结果就是

var e = ".holder"

Demo2 a = 100 - 8 + 5 - 15 - 70 表达式替换

var a = 100 - 8 + 5 - 15 - 70;
var b = 1;
console.log(a+b);

这个js就有点小复杂了，我们需要一个分析工具 https://astexplorer.net/

1:ast1

从这个解析里面看一看出，a的值是一个二元表达式(BinaryExpression) 套着一个二元表达式，我们需要把每个二元表达式的结果计算出来，然后一层一层往上吐结果，这不就是妥妥的递归嘛。

function evaluateBinaryExpression(path) {
    let left = path.node.left ;
    let right = path.node.right;
    let operator  = path.node.operator;

    console.log(left);
    console.log(right);
    console.log(operator);

    // 递归处理左、右两边
    if (types.isBinaryExpression(left)) {
        left = evaluateBinaryExpression(path.get('left'));
    }
    if (types.isBinaryExpression(right)) {
        right = evaluateBinaryExpression(path.get('right'));
    }

    console.log(" =================== ");
    console.log(left);
    console.log(right);

    // 如果左右两边都是数字类型，计算结果并替换
    if (( isNumericLiteral(left)|| types.isUnaryExpression(left) )  &&  (isNumericLiteral(right) || types.isUnaryExpression(right) ) ) {
        try {
            const leftValue = getNodeValue(left);
            const rightValue = getNodeValue(right);
            const evalResult = eval(`${leftValue} ${operator} ${rightValue}`);

            console.log( `${leftValue} ${operator} ${rightValue}` + " = " + evalResult);
            // if(evalResult >=0)
            path.replaceWith(types.numericLiteral(evalResult));
            return path.node;
            // else
            //    path.replaceWith(types.unaryExpression('-', types.numericLiteral(Math.abs(evalResult))));
        } catch (e) {
            console.log("Failed to evaluate numeric expression:", e);
        }
    }

    // 如果左右两边都是字符串类型，拼接结果并替换
    else if (isStringLiteral(left) && isStringLiteral(right) && operator === "+") {
        const leftValue = getNodeValue(left);
        const rightValue = getNodeValue(right);
        const evalResult = leftValue + rightValue;
        path.replaceWith(types.stringLiteral(evalResult));
        return path.node;
    }

    return null;
}


var traverses_3= {
    BinaryExpression(path) {
        evaluateBinaryExpression(path); // 递归处理
    }
}

跑一下，搞定

var a = 12;
var b = 1;
console.log(a + b);

三、总结

js反混淆基本上就是一次模版批量替换的套路，以前我们仅仅依赖查找替换，然后高级一点就是正则替换，现在有了AST解析，就更加灵活了。后面咱们在继续介绍一些高阶的用法。

1:ffshow

角弓玉剑，桃花马上春衫，犹忆少年侠气

关注微信公众号，最新技术干货实时推送

QBDI使用指南

Mon, 25 Dec 2023 08:40:19 +0800

一、目标

今天给大家介绍一个新朋友, QBDI

它可以快速集成到你的frida脚本里面来进行汇编级的Trace

二、步骤

安装

在Androd上使用QBDI非常方便,先去官网下载一个最新版本

https://github.com/QBDI/QBDI/releases/download/v0.10.0/QBDI-0.10.0-android-AARCH64.tar.gz

针对我们Frida的使用,主要是里面的两个文件 libQBDI.so 和 frida-qbdi.js , 前一个是注入库,后一个是js的封装

然后把 libQBDI.so 放到 /data/local/tmp 目录

adb push libQBDI.so /data/local/tmp

使用

第一种用法是主动调用目标函数来Trace

由于需要加载 frida-qbdi.js 模块,所以这里我们需要用到frida的模块开发。通常的方法是采用大胡子的 https://github.com/oleavr/frida-agent-example 一个使用TS的模版。

不过懒得再去学一个TS语言了，所以我们今天用另外一个办法

index.js

import {
    VM,
    InstPosition,
    VMAction,
    Options,
    MemoryAccessType,
    AnalysisType,
    RegisterAccessType,
    OperandType,
    SyncDirection
} from "./frida-qbdi.js";

.... call fridaQBDI

然后使用 frida-compile 编译

// 编译
frida-compile -w index.js -o frida-qbdi-agent.js
// 启动Hook
frida -Uf com.example.myapplication --runtime=v8 -l frida-qbdi-agent.js

主动调用

考虑apk中的so里面有一个addTestFenfei函数

extern "C" int addTestFenfei(){
    int a = 2;
    int b = 3;
    int c = a ^ b;
    c = c + a + b;
    LOGD("addTestFenfei : %d", c);
    return c;
}

我们在warp_vm_run.js里面就可以用下面的方式来主动调用

/**
 * warp_vm_run的函数定义不要修改
 * @param {*} vm_run_func   会调用qbdi的vm.call
 * @param {*} log_file_path 日志文件的路径
 */
export default function warp_vm_run(vm_run_func, log_file_path) {
    let libnative_name = "libmyapplication.so"; // 替换为你的.so库的名称
    let func_name = "addTestFenfei";

    let libnative_base = Process.findModuleByName(libnative_name).base;
    console.log("warp_vm_run libnative_base 0x" +  libnative_base.toString(16));

    // 获取native方法地址
    const func_addr = Module.findExportByName(libnative_name, func_name);
    console.log("func_addr = " + func_addr);

    let ret = vm_run_func(null,func_addr, [], log_file_path,false);
        console.log(ret);
}

然后挂上心爱的frida执行

Failed to load /data/local/tmp/libQBDI.so (dlopen failed: couldn't map "/data/local/tmp/libQBDI.so" segment 1: Permission denied)

报错了，木有权限，那就给它

#setenforce 0

每一行的执行代码，寄存器变化和内存读写就都打印出来了

start vm.call ===
0x77d5661b00 [libmyapplication.so!0x1eb00]         stp        x29, x30, [sp, #-16]!         r[FP=0x77d6b03100 LR=0x2a SP=0x77d6b03080]   w[SP=0x77d6b03070]
memory write at 77d6b03070, data size = 8, data value = 77d6b03100
memory write at 77d6b03078, data size = 8, data value = 2a
0x77d5661b04 [libmyapplication.so!0x1eb04]         mov        x29, sp         r[SP=0x77d6b03070]   w[FP=0x77d6b03070]
0x77d5661b08 [libmyapplication.so!0x1eb08]         adrp        x8, #172032          w[X8=0x77d568b000]
0x77d5661b0c [libmyapplication.so!0x1eb0c]         ldrb        w8, [x8, #3912]         r[X8=0x77d568b000]   w[W8=0x1]
memory read at 77d568bf48, data size = 1, data value = 1
0x77d5661b10 [libmyapplication.so!0x1eb10]         cbz        w8, #32         r[W8=0x1]
0x77d5661b14 [libmyapplication.so!0x1eb14]         adrp        x1, #-40960          w[X1=0x77d5657000]
0x77d5661b18 [libmyapplication.so!0x1eb18]         adrp        x2, #-40960           w[X2=0x77d5657000]
0x77d5661b1c [libmyapplication.so!0x1eb1c]         add        x1, x1, #1895         r[X1=0x77d5657000]   w[X1=0x77d5657767]
0x77d5661b20 [libmyapplication.so!0x1eb20]         add        x2, x2, #806         r[X2=0x77d5657000]   w[X2=0x77d5657326]
0x77d5661b24 [libmyapplication.so!0x1eb24]         mov        w0, #3          w[W0=0x3]
0x77d5661b28 [libmyapplication.so!0x1eb28]         mov        w3, #6          w[W3=0x6]
0x77d5661b2c [libmyapplication.so!0x1eb2c]         bl        #148868         r[SP=0x77d6b03070] w[LR=0x77d5661b30]
0x77d56860b0 [libmyapplication.so!0x430b0]         adrp        x16, #16384         w[X16=0x77d568a000]
0x77d56860b4 [libmyapplication.so!0x430b4]         ldr        x17, [x16, #3032]         r[X16=0x77d568a000] w[X17=0x78cb2dd788]
memory read at 77d568abd8, data size = 8, data value = 78cb2dd788
0x77d56860b8 [libmyapplication.so!0x430b8]         add        x16, x16, #3032         r[X16=0x77d568a000] w[X16=0x77d568abd8]
0x77d56860bc [libmyapplication.so!0x430bc]         br        x17         r[X17=0x78cb2dd788]
0x77d5661b30 [libmyapplication.so!0x1eb30]         mov        w0, #6         w[W0=0x6]
0x77d5661b34 [libmyapplication.so!0x1eb34]         ldp        x29, x30, [sp], #16         r[SP=0x77d6b03070]  w[FP=0x77d6b03100 LR=0x2a SP=0x77d6b03080]
memory read at 77d6b03070, data size = 8, data value = 77d6b03100
memory read at 77d6b03078, data size = 8, data value = 2a
0x77d5661b38 [libmyapplication.so!0x1eb38]         ret         r[LR=0x2a]
cost is 0.063s
0x6

如果要调用有参数的函数，可以这么来做

let ret = vm_run_func(null,func_addr, [2,3], log_file_path);

Hook替换

有些时候，我们不想构造参数去主动调用函数，而是想在app执行的过程中，去hook替换目标函数，然后打印它的真实流程。

这里要注意的就是两点， 1是替换，2是更新上下文，也就是更新寄存器的值

在traceCodeQBDI.js文件 vm_run函数里面，

// postSync 是否同步回来
function vm_run(ctx,func_ptr, args, log_file_path,postSync) {
    let start_time = new Date().getTime();

    let vm = new VM();
    vm.setOptions(Options.OPT_DISABLE_LOCAL_MONITOR | Options.OPT_BYPASS_PAUTH | Options.OPT_ENABLE_BTI)

    var state = vm.getGPRState();
    vm.allocateVirtualStack(state, 0x100000);

    // 同步寄存器
    if(postSync){
        console.log("==== synchronizeContext FRIDA_TO_QBDI ");
        state.synchronizeContext(ctx,SyncDirection.FRIDA_TO_QBDI);
    }

    ......

    // 同步寄存器
    if(postSync){
        console.log("synchronizeContext QBDI_TO_FRIDA ====");
        state.synchronizeContext(ctx,SyncDirection.QBDI_TO_FRIDA);
    }
    return ret;

}

然后在warp_vm_run中做替换

export default function warp_vm_run(vm_run_func, log_file_path) {
    let libnative_name = "libmyapplication.so"; // 替换为你的.so库的名称

    let libnative_base = Process.findModuleByName(libnative_name).base;
    console.log("warp_vm_run libnative_base 0x" +  libnative_base.toString(16));

    // hook替换
    //*
    let env = Java.vm.tryGetEnv();
    console.log(JSON.stringify(env));

       let func_name = "Java_com_example_myapplication_MainActivity_FFTestAdd";
       let func_addr = Module.findExportByName(libnative_name, func_name);
    console.log("Hook func_addr = " + func_addr);

    Interceptor.replace(func_addr,new NativeCallback(function (vmEnv,vmContext,a,b){
        console.log(" ============== ");
        console.log("[+] " + func_addr.sub(libnative_base) + "(" + a + ", " + b + ") called");

        // 恢复被替换的函数入口
        Interceptor.revert(func_addr);
        Interceptor.flush();
        console.log(env.handle);

        // // qbdi执行
        var retVal = vm_run_func(this.context, func_addr, [vmEnv,vmContext,a,b],log_file_path,true);
        // 继续替换吧
        warp_vm_run(vm_run_func,log_file_path);

        const resultStr = env.stringFromJni(retVal);
        console.log("Result: " + resultStr);

        return retVal;
    }, "pointer", ["pointer", "pointer","int","int"]));
    // */


}

这样执行就可以打印出实际app跑的时候的指令了。

三、总结

指令级的Trace还有很多应用场景，比如只打印XOR指令，或者只监控SVC指令。

参考资料

https://github.com/lasting-yang/frida-qbdi-tracer

https://blog.quarkslab.com/why-are-frida-and-qbdi-a-great-blend-on-android.html

1:ffshow

当星星变成星空，梦想也就近在咫尺了

关注微信公众号，最新技术干货实时推送

代码还原小试牛刀(二)：魔改的MD5

Mon, 13 Mar 2023 15:48:52 +0800

一、目标

李老板: 奋飞呀，AI都把代码还原的活给干了，咱们这个代码还原的教程还要写吗？

奋飞: 当然要写了，AI是AI，那是批量化流水线操作，能有我这种纯手工还原的代码帅？我这可是有温度的代码。总不能有了翻译软件，你就不学英语了吧？当然日语可以不用学了。

有个名人说过：你永远赚不到超出你认知范围外的钱。所以奋飞说：你无法指挥AI干超出你认知范围外的活。

二、步骤

2、条件断点 3、数据打印

我们要想知道程序运行到 0x1170 时 x4=0xdd89ca68 的来历，那就需要从前面的代码开始Trace，

往上找了找在 0x1144 有个判断，说明前面经过了若干次循环。

.text:0000000000001144 7F 01 08 EB                 CMP             X11, X8
.text:0000000000001148 88 CC FF 54                 B.HI            loc_AD8

为了分析起来方便，我只想在最后一次循环的时候Trace代码来分析，这样就需要条件断点了。

在做条件断点之前，我们先把 X11 和 X8 的值打印出来。

debugger.addBreakPoint(module.base + 0x1144, new BreakPointCallback() {
    @Override
    public boolean onHit(Emulator<?> emulator, long address) {
        Arm64RegisterContext ctx = emulator.getContext();
        int iX11 = ctx.getXInt(11);
        int iX8 = ctx.getXInt(8);;

        System.out.printf("X11 = %d , X8 = %d\n", iX11,iX8);

        return true;
    }
});

跑一下，

X11 = 64 , X8 = 64

奇怪只打印了一次，那说明这里不是循环，或者是个假循环。

那就继续往上找吧

text:0000000000000C8C 8C 81 00 91                 ADD             X12, X12, #0x20 ; ' '
.text:0000000000000C90             ; 156:       while ( v24 < 0x10 );
.text:0000000000000C90 03 FA FF 54                 B.CC            loc_BD0
.text:0000000000000C94 FE 17 50 29                 LDP             W30, W5, [SP,#0x110+var_90]
.text:0000000000000C98 11 03 19 4A                 EOR             W17, W24, W25

感觉这个 0xC94 应该是最后一次计算的位置了。 (我们可以先在 0xC94 下一个断点，如果只触发一次说明可用，如果触发多次，说明它在循环体里面。)

5、Trace代码

Unidbg Trace代码有两种方式，一种是直接写代码来实现，把Trace结果存入traceCode1.log

try {
  // Trace 的范围是 0xC94 到 0x1170
    emulator.traceCode(module.base+0xC94, module.base+0x1170).setRedirect(new PrintStream(new File("traceCode1.log")));
} catch (IOException e) {
    throw new IllegalStateException(e);
}

另一种是在调试命令行输入Trace命令。

先在 0xC94下断点，进入调试窗口，输入 traceCode 命令然后直接回车即可。

traceCode
Set trace LinuxModule{base=0x40000000, size=12288, name='libnative-lib.so'} instructions success.

如果要把Trace结果保存到文件，就加上文件名 traceCode traceCode1.log

然后 c 命令继续执行，Trace结果就出来了。

开始还原算法

在Trace结果里面搜索 0xdd89ca68 ，发现他是通过 0x68ca89dd 翻转来的

0x40001154: "rev w4, w22" w22=0x68ca89dd => w4=0xdd89ca68

这里遇到不熟悉的指令可以很自然的咨询AI了

1:ai1

我们先把 0x68ca89dd 相关的结果挑出来，原则就是从结果向入参回溯。

0x40001048: "add w12, w12, w15" w12=0x47448b48 w15=0x93f6f2bb => w12=0xdb3b7e03

0x40001098: "orn w12, w12, w11" w12=0xdb3b7e03 w11=0x49ac16b => w12=0xfb7f7e97
0x4000109c: "eor w12, w12, w16" w12=0xfb7f7e97 w16=0xa96ba62 => w12=0xf1e9c4f5
0x400010a0: "add w12, w12, w15" w12=0xf1e9c4f5 w15=0x93f6f2bb => w12=0x85e0b7b0
0x400010b0: "add w12, w12, w15" w12=0x85e0b7b0 w15=0x4212f2e5 => w12=0xc7f3aa95

0x4000107c: "add w11, w11, w17" w11=0xffa26fc9 w17=0x2cc489bc => w11=0x2c66f985
0x40001088: "add w11, w11, w17" w11=0x2c66f985 w17=0xf3d1564b => w11=0x20384fd0
0x4000108c: "ror w11, w11, #0xb" w11=0x20384fd0 => w11=0xfa040709

0x400010b4: "ror w12, w12, #0x1a" w12=0xc7f3aa95 => w12=0xfceaa571
0x40001090: "add w11, w11, w16" w11=0xfa040709 w16=0xa96ba62 => w11=0x49ac16b

0x400010b8: "add w12, w12, w11" w12=0xfceaa571 w11=0x49ac16b => w12=0x18566dc

0x40001048: "add w12, w12, w15" w12=0x47448b48 w15=0x93f6f2bb => w12=0xdb3b7e03

0x40001098: "orn w12, w12, w11" w12=0xdb3b7e03 w11=0x49ac16b => w12=0xfb7f7e97
0x4000109c: "eor w12, w12, w16" w12=0xfb7f7e97 w16=0xa96ba62 => w12=0xf1e9c4f5
0x400010a0: "add w12, w12, w15" w12=0xf1e9c4f5 w15=0x93f6f2bb => w12=0x85e0b7b0
0x400010b0: "add w12, w12, w15" w12=0x85e0b7b0 w15=0x4212f2e5 => w12=0xc7f3aa95

0x4000107c: "add w11, w11, w17" w11=0xffa26fc9 w17=0x2cc489bc => w11=0x2c66f985
0x40001088: "add w11, w11, w17" w11=0x2c66f985 w17=0xf3d1564b => w11=0x20384fd0
0x4000108c: "ror w11, w11, #0xb" w11=0x20384fd0 => w11=0xfa040709

0x400010b4: "ror w12, w12, #0x1a" w12=0xc7f3aa95 => w12=0xfceaa571
0x40001090: "add w11, w11, w16" w11=0xfa040709 w16=0xa96ba62 => w11=0x49ac16b

0x400010b8: "add w12, w12, w11" w12=0xfceaa571 w11=0x49ac16b => w12=0x18566dc

0x40001108: "add w22, w12, w22" w12=0x18566dc w22=0x67452301 => w22=0x68ca89dd

然后打开 VSCode开始写代码

int w12,w11,w15;

w12 = w12 | ~w11          // 0x40001098: "orn w12, w12, w11" w12=0xdb3b7e03 w11=0x49ac16b => w12=0xfb7f7e97
w12 = w12 ^ w16                 // 0x4000109c: "eor w12, w12, w16" w12=0xfb7f7e97 w16=0xa96ba62 => w12=0xf1e9c4f5

// 上面这两步 其实就是
// w12 = (w12 | ~w11) ^ w16

w12 = w12 + w15                                // 0x400010a0: "add w12, w12, w15" w12=0xf1e9c4f5 w15=0x93f6f2bb => w12=0x85e0b7b0
w12 = w12 + Num_w15(常量)        // 0x400010b0: "add w12, w12, w15" w12=0x85e0b7b0 w15=0x4212f2e5 => w12=0xc7f3aa95
w12 = w12 >> 0x1a;        // 0x400010b4: "ror w12, w12, #0x1a" w12=0xc7f3aa95 => w12=0xfceaa571
w12 = w12 + w11;                // 0x400010b8: "add w12, w12, w11" w12=0xfceaa571 w11=0x49ac16b => w12=0x18566dc

是的，还原算法就是这么的朴实无华而又枯燥无味。

w12 = (w12 | ~w11) ^ w16 这个算式让我们有点兴奋

他和标准MD5 算法的 I 非常相似。

//F,G,H,I四个非线性变换函数
#define F(x,y,z) ((x & y) | (~x & z))
#define G(x,y,z) ((x & z) | (y & ~z))
#define H(x,y,z) (x^y^z)
#define I(x,y,z) (y ^ (x | ~z))

这样的话可能我们就可以轻松一点，在标准MD5算法的框架上去还原，只找出里面魔改的部分。

忍不住用AI了

把这个枯燥无味的过程扔给 Cursor 会怎样

用C语言还原w12的计算过程，添加中文注释

0x40001048: "add w12, w12, w15" w12=0x47448b48 w15=0x93f6f2bb => w12=0xdb3b7e03

0x40001098: "orn w12, w12, w11" w12=0xdb3b7e03 w11=0x49ac16b => w12=0xfb7f7e97
0x4000109c: "eor w12, w12, w16" w12=0xfb7f7e97 w16=0xa96ba62 => w12=0xf1e9c4f5
0x400010a0: "add w12, w12, w15" w12=0xf1e9c4f5 w15=0x93f6f2bb => w12=0x85e0b7b0
0x400010b0: "add w12, w12, w15" w12=0x85e0b7b0 w15=0x4212f2e5 => w12=0xc7f3aa95

0x4000107c: "add w11, w11, w17" w11=0xffa26fc9 w17=0x2cc489bc => w11=0x2c66f985
0x40001088: "add w11, w11, w17" w11=0x2c66f985 w17=0xf3d1564b => w11=0x20384fd0
0x4000108c: "ror w11, w11, #0xb" w11=0x20384fd0 => w11=0xfa040709

0x400010b4: "ror w12, w12, #0x1a" w12=0xc7f3aa95 => w12=0xfceaa571
0x40001090: "add w11, w11, w16" w11=0xfa040709 w16=0xa96ba62 => w11=0x49ac16b

0x400010b8: "add w12, w12, w11" w12=0xfceaa571 w11=0x49ac16b => w12=0x18566dc

#include <stdio.h>

int main() {
    unsigned int w12 = 0x47448b48;
    unsigned int w15 = 0x93f6f2bb;
    unsigned int w11 = 0xffa26fc9;
    unsigned int w17 = 0x2cc489bc;
    unsigned int w16 = 0xa96ba62;

    w12 = w12 + w15;
    printf("w12 = %x\n", w12);

    w12 = (w12 | ~w11);
    printf("w12 = %x\n", w12);

    w12 = w12 ^ w16;
    printf("w12 = %x\n", w12);

    w12 = w12 + w15;
    printf("w12 = %x\n", w12);

    w12 = w12 + 0x4212f2e5;
    printf("w12 = %x\n", w12);

    w11 = w11 + w17;
    printf("w11 = %x\n", w11);

    w11 = w11 + 0xf3d1564b;
    printf("w11 = %x\n", w11);

    w11 = (w11 >> 11) | (w11 << (32 - 11));
    printf("w11 = %x\n", w11);

    w12 = (w12 >> 26) | (w12 << (32 - 26));
    printf("w12 = %x\n", w12);

    w11 = w11 + w16;
    printf("w11 = %x\n", w11);

    w12 = w12 + w11;
    printf("w12 = %x\n", w12);

    return 0;
}

感觉比我写的好，程序员要进化出一个新品种了，就是给AI写 prompt

三、总结

以前觉得当leader很幸福，啥活都不用干，直接指挥小弟干活就行。

后来真当了leader才发现，我去，你得A语言到Z语言都会，不然做php的小弟说这玩意实现不了，做Flash的小弟说这个功能得做一个月。

AI也是如此，机械重复性的工作它比你做的好，创意和指路的活还得你自己干。

1:ffshow

决定战争胜负的是人，而不是一两件新式武器。这一论断永远都不过时

关注微信公众号，最新技术干货实时推送

安卓高版本安装系统证书 HTTPS 抓包 - 终极解决方案

Sun, 05 Mar 2023 18:10:06 +0800

一、目标

要抓App的包，首先需要App信任抓包软件的证书。

不过从Android 从 7.0 开始，系统不再信任用户 CA 证书，所以你需要把 CA 证书安装到系统 CA 证书目录。

如果你是用Magisk越狱的话，这个工作就比较简单了，只需要安装一个模块 Move Certificates。

不过今天的故事从我刷了一个新rom开始，这个rom比较奇怪，刷完之后 adb连上直接就是root状态，但是App却没法获取root状态。

我去，这不就是误打误撞刷了一个隐藏root的rom吗？这下我可舍不得装Magisk了。

那现在的问题就是如何把证书安装到系统目录？

二、步骤

霸王硬上弓

计算证书名

openssl x509 -subject_hash_old -in charles-ssl-proxying-certificate_saved.pem

算出数值，比如3a1074b3

然后把原Charles证书charles-ssl-proxying-certificate_saved.pem改名为 3a1074b3.0

最后把 3a1074b3.0 文件拷贝到 /system/etc/security/cacerts/ 目录下面。

搞定~~

理想很丰满，现实很骨感，/system 大概率是不可写的，即使你有root权限，也写不进去。

问了下谷哥，哥说，可以把 /system 重新 mount 成可读写的，不过我没有成功。

之前有两种方式成功过。

1、安装RootExplorer.apk，把/system 加载成可读写。

2、adb reboot recovery 进入之前刷的 twrp ,在twrp下去写入 /system

不过这次翻车了，RootExplorer没法加载可读。 twrp写完 /system 之后这个rom发疯了，设置进不去了，老报崩溃。

师夷长技

想起了 Http Toolkit这个抓包软件，它有个 Android Device via ADB 模式，居然可以顺利抓包。

说明它可以利用ADB把证书写入到 /system , 毕竟我的ADB是有Root权限的。

太神奇了，它是怎么实现的呢？

这下又开始了漫长的谷歌之旅，最后在他们官网找到一篇文章，详细讲述了通过有root权限的adb 来写入系统证书的神奇方案。

1、通过 ADB 将 HTTP Toolkit CA 证书推送到设备上。

2、从 /system/etc/security/cacerts/ 中复制所有系统证书到临时目录。

3、在 /system/etc/security/cacerts/ 上面挂载一个 tmpfs 内存文件系统。这实际上将一个可写的全新空文件系统放在了 /system 的一小部分上面。将复制的系统证书移回到该挂载点。

4、将 HTTP Toolkit CA 证书也移动到该挂载点。

5、更新临时挂载点中所有文件的权限为 644，并将系统文件的 SELinux 标签设置为 system_file，以使其看起来像是合法的 Android 系统文件。

关键点就是挂载一个内存文件系统，太有才了。

Show me the Code

# htk-inject-system-cert.sh
set -e # Fail on error
# Create a separate temp directory, to hold the current certificates
# Without this, when we add the mount we can't read the current certs anymore.
mkdir -m 700 /data/local/tmp/htk-ca-copy
# Copy out the existing certificates
cp /system/etc/security/cacerts/* /data/local/tmp/htk-ca-copy/
# Create the in-memory mount on top of the system certs folder
mount -t tmpfs tmpfs /system/etc/security/cacerts
# Copy the existing certs back into the tmpfs mount, so we keep trusting them
mv /data/local/tmp/htk-ca-copy/* /system/etc/security/cacerts/
# Copy our new cert in, so we trust that too
cp /data/local/tmp/c88f7ed0.0 /system/etc/security/cacerts/
# Update the perms & selinux context labels, so everything is as readable as before
chown root:root /system/etc/security/cacerts/*
chmod 644 /system/etc/security/cacerts/*
chcon u:object_r:system_file:s0 /system/etc/security/cacerts/*
# Delete the temp cert directory & this script itself
rm -r /data/local/tmp/htk-ca-copy
# rm ${injectionScriptPath}
echo "System cert successfully injected"

内存文件系统嘛，重启之后肯定就失效了，所以保存成脚本，抓包之前跑一下，也不是很麻烦的。

三、总结

有时候神奇的技术就是一层窗户纸，捅破了，你会惊叹，原来这么简单。

掌握了新的方案之后，未来就可以举一反三了。

参考 https://httptoolkit.com/blog/intercepting-android-https/

https://github.com/httptoolkit/httptoolkit-server/blob/8a4b4d283fbe98694ddd09a44d6e9c9941aa91e2/src/interceptors/android/adb-commands.ts

1:ffshow

着眼总是浮游观化颇领幻趣

关注微信公众号，最新技术干货实时推送

代码还原小试牛刀(一)：魔改的MD5

Wed, 22 Feb 2023 11:56:39 +0800

一、目标

2023年了，MD5已经是最基础的签名算法了，但如果你还只是对输入做了简单的MD5，肯定会被同行们嘲笑。加点盐（salt）是一种基本的提升，但在这个就业形势严峻的时代，仅仅加盐肯定不够了。

今天我们就来讲一讲魔改的MD5，让这个算法高大上起来。

1、菜卷

最简单的魔改方法就是改变MD5的初始参数，

     context->state[0] = 0x67452301;
     context->state[1] = 0xEFCDAB89;
     context->state[2] = 0x98BADCFE;
     context->state[3] = 0x10325476;

把这四个参数修改一下就行了。通过修改这些参数，我们可以改变MD5的运算结果。但这种方法实在太简单了，卷不起来。

接下来，我们要介绍更高级的卷法。

2、肉卷

md5会进行64轮运算，每轮运算都会用到一个常量，组成一个常量表K。

K原始值的计算方式是 2^32 * |sin i |，而后取其整数部分。

那么有理想的同学就可以更改这个K值，比如把 sin改成 cos或者tan之类的，这样就可以卷起来了。

3、卷中卷

//F,G,H,I四个非线性变换函数
#define F(x,y,z) ((x & y) | (~x & z))
#define G(x,y,z) ((x & z) | (y & ~z))
#define H(x,y,z) (x^y^z)
#define I(x,y,z) (y ^ (x | ~z))
//x循环左移n位的操作
#define ROTATE_LEFT(x,n) ((x << n) | (x >> (32-n)))

要真正卷起来，我们需要改变MD5中的四个非线性变换函数F、G、H、I。我们可以加上异或或者减少与操作，整个算法就换了个面貌。这种高级卷法可以忽悠住老板，让算法高大上起来。

我们今天的目标是尝试还原一个魔改之后的MD5算法，通过这次实践来了解算法还原的基本方法。

这个样本我们的入参是字符串: "1677038066553"

返回值是32个字符： "DD89CA684D91818B970710F75A75743D"

二、步骤

第一步

我们需要用Unidbg跑通算法，比起上古时期用ida调试的前辈，Unidbg的出现直接把算法还原的难度降了一个数量级。

第二步

我们需要把结果Z通过反向推导一步一步回到原始输入A。这种方法叫做倒果为因，是逆向分析的一种基本套路。

我们假设这个样本是MD5或者是魔改的MD5，我们可以用以下几种方法来还原算法：

1、调试断点

2、条件断点

3、数据打印

4、Trace内存读写

5、Trace代码

1、调试断点

逆向分析是经验科学，虽然有一些基本套路，但是还是以试为主，先用IDA打开 libnative-lib.so，从 Exports 导出表里面找到导出函数 Java_com_littleq_cryptography_md5_MainActivity_sign

这个函数的开始地址在0x1234, 结束地址在0x12B4,但是主要的代码逻辑在函数sub_A3C里面，我们先在sub_A3C函数的末端下个断点试试，

text:00000000000011D4 E0 07 40 F9                 LDR             X0, [SP,#0x110+var_108]
.text:00000000000011D8 03 00 00 90+                ADRL            X3, aSSSS ; "%s%s%s%s"
.text:00000000000011D8 63 EC 0A 91
.text:00000000000011E0 E4 83 01 91                 ADD             X4, SP, #0x110+var_B0
.text:00000000000011E4 E5 43 01 91                 ADD             X5, SP, #0x110+var_C0
.text:00000000000011E8 E6 03 01 91                 ADD             X6, SP, #0x110+var_D0
.text:00000000000011EC E7 C3 00 91                 ADD             X7, SP, #0x110+var_E0
.text:00000000000011F0 01 00 80 92                 MOV             X1, #0xFFFFFFFFFFFFFFFF
.text:00000000000011F4 02 08 80 52                 MOV             W2, #0x40 ; '@'

这个 0x11D8 很像是格式化字符串。

我们在Unidbg里面给 0x11D8 下个断点

    Debugger debugger = emulator.attach();
    debugger.addBreakPoint(module.base + 0x11D8);

运行一下，顺利的断下来了

debugger break at: 0x400011d8 @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0xbffff690(-1073744240) x1=0x0 x2=0x4 x3=0xbfffed20 x4=0x40230200 x5=0x402302c0 x6=0x1 x7=0xbffff708 x8=0x0 x9=0x0 x10=0x1 x11=0x0 x12=0x8 x13=0x8 x14=0x8
>>> x15=0x8 x16=0x40228d70 x17=0x40177ddc x18=0x8 x19=0x4cf3a208 x20=0x400012b8 x21=0x0 x22=0x68ca89dd x23=0x3d74755a x24=0x72e737bb x25=0xddf5ac1 x26=0xd0d5adc6 x27=0x8b81914d x28=0xf7100797 fp=0xbffff680
LR=RX@0x400011d4[libnative-lib.so]0x11d4
SP=0xbffff570
PC=RX@0x400011d8[libnative-lib.so]0x11d8
nzcv: N=0, Z=1, C=1, V=0, EL0, use SP_EL0
start + 0xae8
=> *[libnative-lib.so*0x011d8]*[03000090]*0x400011d8:*"adrp x3, #0x40001000"
    [libnative-lib.so 0x011dc] [63ec0a91] 0x400011dc: "add x3, x3, #0x2bb"
    [libnative-lib.so 0x011e0] [e4830191] 0x400011e0: "add x4, sp, #0x60"
    [libnative-lib.so 0x011e4] [e5430191] 0x400011e4: "add x5, sp, #0x50"
    [libnative-lib.so 0x011e8] [e6030191] 0x400011e8: "add x6, sp, #0x40"
    [libnative-lib.so 0x011ec] [e7c30091] 0x400011ec: "add x7, sp, #0x30"
    [libnative-lib.so 0x011f0] [01008092] 0x400011f0: "mov x1, #-1"
    [libnative-lib.so 0x011f4] [02088052] 0x400011f4: "mov w2, #0x40"
    [libnative-lib.so 0x011f8] [5bfdff97] 0x400011f8: "bl #0x40000764"

在Arm汇编里面，调用一个函数之前，会把入参存入到 x0,x1,x2 ……

从这段代码可以看出地址 0x400011f8 会调用 0x40000764 函数，并且传入了 7个参数，从x0，一直赋值到x7。

Unidbg的调试虽然有些简陋，但是已经够用了，有如此神器在手，你还要啥自行车？

调试命令先掌握以下几个：

s 单步步入，就是遇到函数调用会进入。

n 单步步过，遇到函数调用不会进入函数。

c 继续执行

b 下断点

r 取消当前断点

m 查看内存

我们先 s s s 几下，单步执行到 0x400011f8

debugger break at: 0x400011f8 @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0xbffff690(-1073744240) x1=0xffffffffffffffff x2=0x40 x3=0x400012bb x4=0xbffff5d0 x5=0xbffff5c0 x6=0xbffff5b0 x7=0xbffff5a0 x8=0x0 x9=0x0 x10=0x1 x11=0x0 x12=0x8 x13=0x8 x14=0x8
LR=RX@0x400011d4[libnative-lib.so]0x11d4
SP=0xbffff570
PC=RX@0x400011f8[libnative-lib.so]0x11f8
nzcv: N=0, Z=1, C=1, V=0, EL0, use SP_EL0
start + 0xb08
=> *[libnative-lib.so*0x011f8]*[5bfdff97]*0x400011f8:*"bl #0x40000764"

这个时间点，入参都已经准备好了，我们来一个一个看看这些入参。

mx7

>-----------------------------------------------------------------------------<
[10:40:26 646]x7=unidbg@0xbffff5a0, md5=d6c164ca9ef531557fc14e1bf7173663,
size: 112
0000: 35 41 37 35 37 34 33 44 00 B3 22 40 00 00 00 00    5A75743D.."@....
0010: 39 37 30 37 31 30 46 37 00 8D 09 40 00 00 00 00    970710F7...@....
0020: 34 44 39 31 38 31 38 42 00 77 12 40 02 00 00 00    4D91818B.w.@....
0030: 44 44 38 39 43 41 36 38 00 1B 17 40 02 00 00 00    DD89CA68...@....
0040: 31 36 37 37 30 33 38 30 36 36 35 35 33 80 00 00    1677038066553...
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
^-----------------------------------------------------------------------------^

可以看到这次调用函数 0x40000764，基本就是在组装最后的结果了。

我们要做的就是找到这些结果生成的位置，来分析最终结果是如何计算出来的，也就是 Y → Z 的过程。

4、Trace内存读写

现在我们已经知道了结果Z的位置，下一步就是需要知道谁计算出了Z。

这就需要用到Unidbg的一个强大功能：内存读写监控

这一次我们先把调试断点下早一点，在 sub_A3C 函数开头就断下来。

debugger break at: 0x40000a3c @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0x40004000 x1=0xbffff690 x2=0x0 x3=0x1 x4=0x0 x5=0x1 x6=0x0 x7=0x0 x8=0xfffe0a70 x9=0x3002 x10=0x0 x11=0x1 x12=0x3 x13=0x40003018 x14=0x40003028
>>> x15=0x1 x16=0x40228910 x17=0x0 x18=0x17 x19=0xfffe1640 x20=0xbffff708 x21=0x0 x22=0x0 x23=0x0 x24=0x0 x25=0x0 x26=0x0 x27=0x0 x28=0x0 fp=0xbffff6f0
LR=RX@0x40001280[libnative-lib.so]0x1280
SP=0xbffff690
PC=RX@0x40000a3c[libnative-lib.so]0xa3c
nzcv: N=0, Z=0, C=1, V=0, EL0, use SP_EL0
start + 0x34c
=> *[libnative-lib.so*0x00a3c]*[ff8304d1]*0x40000a3c:*"sub sp, sp, #0x120"

traceWrite 0xbffff5d0 0xbffff5d8
Set trace 0xbffff5d0->0xbffff5d8 memory write success.
c
[11:41:41 656] Memory WRITE at 0xbffff5d8, data size = 1, data value = 0x0, PC=RX@0x40001168[libnative-lib.so]0x1168, LR=null
[11:41:41 657] Memory WRITE at 0xbffff5d0, data size = 8, data value = 0x0, PC=RX@0x4000116c[libnative-lib.so]0x116c, LR=null
[11:41:41 661] Memory WRITE at 0xbffff5d8, data size = 1, data value = 0x0, PC=RX@0x401b48cc[libc.so]0x648cc, LR=RX@0x401b48c8[libc.so]0x648c8

traceWrite 就是监控写内存命令。

看上去0xbffff5d0这段内存，写入 DD89CA68 数据的位置是： 0x116c

text:000000000000114C 14 00 00 90+                ADRL            X20, unk_12B8
.text:000000000000114C 94 E2 0A 91
.text:0000000000001154 C4 0A C0 5A                 REV             W4, W22
.text:0000000000001158 E0 83 01 91                 ADD             X0, SP, #0x110+var_B0
.text:000000000000115C 21 01 80 52                 MOV             W1, #9
.text:0000000000001160 22 01 80 52                 MOV             W2, #9
.text:0000000000001164 E3 03 14 AA                 MOV             X3, X20
.text:0000000000001168 FF A3 01 39                 STRB            WZR, [SP,#0x110+var_A8]
.text:000000000000116C FF 33 00 F9                 STR             XZR, [SP,#0x110+var_B0]
.text:0000000000001170 7D FD FF 97                 BL              sub_764

0x116c 的指令 STR XZR 是写入没错，但是看上去不像是写入数据，而是把 SP,#0x110+var_B0 这个地址的数据清零。

那我们重来一次，(Unidbg的优点就是可以无限重放，比真机调试App方便了不知道多少倍。)

这次往前一点点，在 0x114C 下断点。

断下来之后，每s单步一次之后，就去查看 m0xbffff5d0。

最后发现跑完 0x1170 , 0xbffff5d0内存的值就改变成了， DD89CA68 。这说明 0xbffff5d0 是 sub_764 函数去写的。

debugger break at: 0x40001170 @ Function64 address=0x40001234, arguments=[unidbg@0xfffe1640[libandroid.so]0x640, 1853170425, 2008362258]
>>> x0=0xbffff5d0(-1073744432) x1=0x9 x2=0x9 x3=0x400012b8 x4=0xdd89ca68 x5=0xe6cd8e62 x6=0x24523012 x7=0x29b9c389 x8=0x40 x9=0x40318041 x10=0xbffff5e0 x11=0x40 x12=0x3d5ebb2b x13=0x6450c165 x14=0xfc63b7e7
>>> x15=0x49ac16b x16=0xac6af723 x17=0xf3d1564b x18=0x18 x19=0x4cf3a208 x20=0x400012b8 x21=0x0 x22=0x68ca89dd x23=0x3d74755a x24=0x72e737bb x25=0xddf5ac1 x26=0xd0d5adc6 x27=0x8b81914d x28=0xf7100797 fp=0xbffff680
LR=null
SP=0xbffff570
PC=RX@0x40001170[libnative-lib.so]0x1170
nzcv: N=0, Z=1, C=1, V=0, EL0, use SP_EL0
start + 0xa80
=> *[libnative-lib.so*0x01170]*[7dfdff97]*0x40001170:*"bl #0x40000764"

不过回到 0x1170,我们发现了一串熟悉的数字 x4=0xdd89ca68 ，好吧，我们的问题又变成了 x4的值是怎么算出来的？

三、总结

首先要习惯看Arm汇编，一步一步单步调试，然后熟悉寄存器的变化。特别对一些关键数字要敏感。

要掌握Unidbg的基础调试命令。

常见的加密算法要熟悉一下，在开发环境里多调试几遍，熟悉它的算法流程。

1:ffshow

多方分别，是非之窦易开；一味圆融，人我之见不立。

关注微信公众号，最新技术干货实时推送

奋飞安全

关于奋飞

精华导航

第一章 实例操练

1、Android App操练

1.1、 签名类

1.1.1、 某电商App签名算法解析(一) 重点是找sign的思路

1.1.2、 某电商App签名算法解析(二)

1.1.3、 AndroidNativeEmu模拟执行计算出某电商App sign

1.1.4、 某种草电商App签名算法解析(一)

1.1.5、 某生鲜App签名算法解析(一)

1.1.6、 某生活服务App返回数据密文解析(一) Android Device Monitor定位

1.1.7、 某生活服务App请求数据密文解析(二) 从Base64说起

1.1.8、 某站App签名算法解析(一)

1.1.9、 某段子App签名计算方法(一)

1.1.10、 某段子App协议分析(二)

1.1.11、 某小视频App v8.x 签名计算方法(一) 先从抓包说起

1.1.12、 某小视频App v8.x 签名计算方法(二) sig和__NS_sig3

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

1.1.13、 某电商App anti-token 签名计算方法 学学objection

1.1.14、 某电商App Sign签名算法解析 内部类的Hook

1.1.15、 某二手电商App x-sign签名分析 类成员变量的分析

1.1.16、 某影评书评社区App _sig签名分析

1.1.17、 某汽车资讯App 返回数据解密

1.1.18、 某搬家App _sign签名算法解析

1.1.19、 某足球资讯App sign签名算法解析

1.1.20、 搞个大点的 某团购App mtgsig

1.1.21、 中华PS App sig签名分析

1.1.22、 某潮牌电商App newSign签名分析

1.1.23、 某资讯App signature签名分析 (一)

1.1.24、 再搞个大点的 某小视频App X-Gorgon 分析

1.1.25、 某社交App cs签名算法解析(一) SSL双向认证

1.1.26、 某社交App cs签名算法解析(二) 都是套路

1.1.27、 某NFT交易平台App wtoken分析

1.2、so直接调用

1.2.1、 借鸡生蛋之SandHook的使用(一)

1.2.2、 借鸡生蛋之某电商App签名so的使用(二)

1.2.3、 借鸡生蛋之某电商App签名so的使用(三)

1.3、 RPC调用

1.3.1、 frida + Flask rpc调用

1.3.2、 Xposed + NanoHTTPD rpc调用

1.3.3、 android连真机签名公网ip更新方案

1.3.4、 Sekiro + Xposed 签名解决方案

1.3.5、 Frida + AndroidAsync 实现 RPC

第二章 进阶学习

1、反混淆

1.1、 Unicorn反混淆

1.1.1、 Unicorn反混淆：恢复被OLLVM保护的程序(一)

2、反调试

3、反反调试

3.1 Tracerid检测

3.1.1 某电商App反反调试

4、分析技巧

4.1 Frida分析技巧

4.1.1 算法还原的助手(一) 先让时间停下来

5、就不分类

5.1

5.1.1 Trace大盘点

第三章 模拟执行

1、AndroidNativeEmu

1.1、基础

1.1.1、 AndroidNativeEmu使用指南

1.2、实例

1.2.1、 AndroidNativeEmu模拟执行计算出某电商App sign

1.2.1、 AndroidNativeEmu中Hook gettimeofday和lrand48来验证签名值

1.3、反模拟执行

1.3.1、 一种对抗AndroidNativeEmu的方法

1.6、系列教程

1.6.1、 AndroidNativeEmu模拟执行大厂so实操教程(一) 如何搞一个类

1.6.2、 AndroidNativeEmu模拟执行大厂so实操教程(二) 增加成员函数

1.6.3、 AndroidNativeEmu模拟执行大厂so实操教程(三) 填jmethodID相同的坑

1.6.4、 AndroidNativeEmu模拟执行大厂so实操教程(四) 函数功能实现

1.6.5、 AndroidNativeEmu模拟执行大厂so实操教程(五) 增加字段(成员变量)

1.6.6、 AndroidNativeEmu模拟执行大厂so实操教程(六) 补齐jni函数

1.6.7、 AndroidNativeEmu模拟执行大厂so实操教程(七) 构造参数来调用Native函数

2、Unidbg

2.1、基础

2.1.1、 Unidbg使用指南(一)

2.2、实例

2.2.1、 Unidbg模拟执行大厂so实操教程(一) 先把框架搭起来

第一章实例操练

1.1、签名类

1.1.1、某电商App签名算法解析(一) 重点是找sign的思路

1.1.2、某电商App签名算法解析(二)

1.1.4、某种草电商App签名算法解析(一)

1.1.5、某生鲜App签名算法解析(一)

1.1.6、某生活服务App返回数据密文解析(一) Android Device Monitor定位

1.1.7、某生活服务App请求数据密文解析(二) 从Base64说起

1.1.8、某站App签名算法解析(一)

1.1.9、某段子App签名计算方法(一)

1.1.10、某段子App协议分析(二)

1.1.11、某小视频App v8.x 签名计算方法(一) 先从抓包说起

1.1.12、某小视频App v8.x 签名计算方法(二) sig和__NS_sig3

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

1.1.13、某电商App anti-token 签名计算方法学学objection

1.1.14、某电商App Sign签名算法解析内部类的Hook

1.1.15、某二手电商App x-sign签名分析类成员变量的分析

1.1.16、某影评书评社区App _sig签名分析

1.1.17、某汽车资讯App 返回数据解密

1.1.18、某搬家App _sign签名算法解析

1.1.19、某足球资讯App sign签名算法解析

1.1.20、搞个大点的某团购App mtgsig

1.1.21、中华PS App sig签名分析

1.1.22、某潮牌电商App newSign签名分析

1.1.23、某资讯App signature签名分析 (一)

1.1.24、再搞个大点的某小视频App X-Gorgon 分析

1.1.25、某社交App cs签名算法解析(一) SSL双向认证

1.1.26、某社交App cs签名算法解析(二) 都是套路

1.1.27、某NFT交易平台App wtoken分析

1.2.1、借鸡生蛋之SandHook的使用(一)

1.2.2、借鸡生蛋之某电商App签名so的使用(二)

1.2.3、借鸡生蛋之某电商App签名so的使用(三)

第二章进阶学习

第三章模拟执行

1.3.1、一种对抗AndroidNativeEmu的方法

第一章基础

第二章进阶学习

2.1.1、最新的Xposed模块编写教程2020

3.1.1、手把手教你搭个Frida + Sekiro Rpc框架

1.1.1、代码还原的技术 ARM汇编入门教程(一) Hello World!

1.1.2、代码还原的技术 ARM汇编入门教程(二) 加减乘除

第四章实用技巧

1.1.1、手把手教你从Apk中取出算法