{ "version": "https://jsonfeed.org/version/1", "title": "vw2x", "home_page_url": "https://vw2x.vercel.app", "feed_url": "https://vw2x.vercel.app/feed.json", "description": "Notes on learning, building, and thinking", "icon": "https://vw2x.vercel.app/favicon.png", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" }, "items": [ { "id": "https://vw2x.vercel.app/en/blog/20260327_rethinking-zsh-in-codex", "content_html": "

Why I Started Rethinking zsh

\n

Recently I was debugging an Android native build issue in Codex.

\n

The symptom was odd: on the same machine, in the same repository, the same ./gradlew clean :app:assembleDebug command would succeed when I ran it manually in Codex Desktop's interactive terminal, but fail consistently when the assistant ran it through the tool.

\n

At first glance it looked like an ordinary build failure. I suspected Gradle, the NDK, the JDK, and the cache.

\n

But after checking the daemon process arguments, none of those were it.

\n

The command did not change, the entry point did, and the result changed.

\n

That reminded me of an environment issue I had only half-understood before: what is the difference between zsh -c, zsh -lc, and zsh -ic?

\n

I used to think of them as just a few shell startup variants.

\n

This time, though, I realized the difference is not a syntax detail. It directly decides whether you are getting the same environment.

\n

I First Treated It as a Build Problem

\n

The failure eventually landed in the native build chain, and the errors looked like a broken toolchain:

\n\n

That kind of error is easy to misread.

\n

Because it happened during the build, my attention naturally went to:

\n
    \n
  1. Whether Gradle was broken.
    2. \n
  2. Whether the NDK version was wrong.
    3. \n
  3. Whether the JDK was incompatible.
    4. \n
  4. Whether the CMake/Ninja cache was dirty.
    5. \n
\n

At the same time, one signal was much more important:

\n

Manual terminal execution succeeded, but the tool subprocess failed

\n

That should change the priority.

\n

At that point, the better question was not "is the project broken?" but:

\n

Are those two entry points actually running in the same environment?

\n

That was the key step.

\n

We often assume that because a command runs inside the same app, the environment should be close enough.

\n

What I came to understand here is:

\n

Different execution entry points in the same product can still map to different shell startup environments.

\n

zsh -c, zsh -lc, and zsh -ic Differ in Environment, Not Syntax

\n

Instead of guessing inside the Gradle wrapper, I first cut the problem by shell startup mode.

\n

The result was very direct:

\n\n

Once those three results were in, the problem had already been narrowed down a lot.

\n

It told me at least three things:

\n
    \n
  1. The command text itself was not the issue.
    2. \n
  2. The repository itself was not the issue.
    3. \n
  3. The issue was in the shell initialization chain.
    4. \n
\n

If I reduce it to a rough troubleshooting model, these flags can be remembered like this:

\n\n

What matters is that the startup chain behind them is different.

\n

\"Screenshot\"

\n

From the zsh manual, the startup order can be remembered like this:

\n\n

Mapped back to the three startup modes here, that becomes roughly:

\n\n

That also explains why zsh -lc and zsh -ic are both different from plain zsh -c, yet can still end up with different environments:

\n\n

The easiest mistake here is to treat "it is also zsh" as "the environment should be roughly the same".

\n

That is not true.

\n

Once the startup flags differ, the initialization file chain can differ too, and so can the final environment variables.

\n

How I Narrowed It Down to Shell Environment

\n

Debugging is not "guessing with experience". It is knowing that you do not control the whole system, stepping back, and using variable control and binary search.

\n

1. Admit It Is Not a Single-Command Problem, but an Entry-Point Problem

\n

If the same command gives opposite results through two entry points, the first thing to do is: freeze the command text and compare the entry points.

\n

Control variables before running experiments.

\n

Do not keep changing the project, guessing the cache, and trying new commands at the same time, or you will just confuse yourself.

\n

2. Check Whether the Repository Itself Is the Problem

\n

If manual execution succeeds on the same machine and the same repository, then the repository itself is probably not the main cause.

\n

That does not mean the code is definitely fine. It means:

\n

It should not be the first thing you suspect.

\n

3. Use zsh -c, zsh -lc, and zsh -ic to Slice the Environment

\n

Recently I heard someone say that once a problem becomes concrete, it is no longer scary. It is like the boss finally showing its health bar.

\n

Tool execution in Codex is different from manual terminal use needs to become a more concrete statement: the difference is whether the shell reaches the interactive initialization chain

\n\n

So the issue is not "whether there is zsh", but "what semantics zsh is started with".

\n

4. Validate the Smallest Failure Point

\n

Do not keep guessing while wrapped inside the whole system.

\n

Gradle wraps CMake, CMake wraps Ninja, and Ninja calls the compiler. That is too many layers, and the real signal gets buried.

\n

It wastes time, and it wastes tokens.

\n

Once I kept tracing, I found the failure path was actually using the NDK host clang, and then I checked its header search paths directly. The problem became much clearer.

\n

In the failing environment, the Darwin SDK system header search path was missing.

\n

I asked the AI, and it suggested trying to add SDKROOT.

\n

That turned "the build system may have many complicated causes" into "the current shell did not carry in the key environment"

\n

The Core Issue

\n

Looking back, the most important thing here was not how to fix one Android native project, but:

\n

In Codex, the interactive terminal and the tool subprocess are not the same shell environment.

\n

Once that premise is true, many later symptoms stop being strange:

\n\n

Commands are never executed outside context.

\n

A command's real execution conditions include at least:

\n\n

If you only look at the command text, it is easy to get stuck thinking: "I ran the exact same command."

\n

From a systems perspective, if those conditions differ, it is not the same execution at all.

\n

How I Will Debug This Kind of Environment Issue Next Time

\n

1. When Manual Works and Automation Fails, Do Not Rush to Change Code

\n

Suspect the process environment first, not the repository contents.

\n

Especially in IDEs, agents, terminal tools, and CI systems, never assume the environments are identical by default.

\n

2. Compare Shell Semantics Before Command Text

\n

The difference between zsh -c, zsh -lc, and zsh -ic is not a memorization question. It is a startup-chain difference.

\n

Once you know:

\n\n

a lot of "same command, different result" cases suddenly become concrete.

\n

3. Validate the Smallest Failure Point, Not the Outer System

\n

If there is a Gradle wrapper, script, or task orchestrator around it, push inward.

\n

Find the layer where it actually fails and inspect what it is missing.

\n

Many environment issues become much easier once you can reduce them to the smallest possible command.

\n", "url": "https://vw2x.vercel.app/en/blog/20260327_rethinking-zsh-in-codex", "title": "Rethinking zsh in Codex", "summary": "One software, one command, two outcomes. That made me start separating different zsh startup modes.", "date_modified": "2026-03-27T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/blog/260327_codex-zsh-interactive-shell", "content_html": "

为什么我会重新理解 zsh

\n

最近在 Codex 里排一个 Android native 构建问题.

\n

现象有点别扭: 同一台机器, 同一份仓库, 同一条 ./gradlew clean :app:assembleDebug, 在 Codex 桌面里的交互终端手动执行能成功, assistant 通过工具去执行却稳定失败.

\n

第一眼看上去像是普通的构建失败. 怀疑 Gradle, 怀疑 NDK, 怀疑 JDK, 怀疑缓存.

\n

但查看 daemon 进程的运行参数发现都不是.

\n

命令没变, 执行入口变, 结果变.

\n

这件事让我想起曾经一笔带过的环境配置问题: zsh -c、zsh -lc、zsh -ic 这些启动方式的差异是什么?

\n

以前对这些参数的理解比较松散, 觉得无非就是 shell 的几种启动形式.

\n

但这次排查到后面发现, 差异不是“语法细节”, 而是会直接决定你拿到的是不是同一套环境.

\n

一开始把它当成构建问题

\n

这次失败最终落在 native 构建链路里, 报错也很像工具链坏了:

\n\n

这类错误很容易让人想歪.

\n

因为它出现在构建阶段, 自然把注意力放在:

\n
    \n
  1. Gradle 有没有问题.
    2. \n
  2. NDK 版本是不是不对.
    3. \n
  3. JDK 是不是和项目不兼容.
    4. \n
  4. CMake/Ninja 缓存是不是脏了.
    5. \n
\n

与此同时发现一个更值得警觉的信号:

\n

用户手动终端能成功, 工具子进程却失败

\n

那优先级其实应该先切换一下.

\n

这时候比 "项目是不是坏了" 更值得问的是:

\n

这两个入口, 真的是同一种运行环境吗?

\n

这一步很关键.

\n

很多时候我们会下意识觉得, 都在同一个 App 里执行命令, 差别不该太大.

\n

但这次让我真正建立起来的直觉是:

\n

同一个产品里的不同执行入口, 完全可能对应不同的 shell 启动环境.

\n

zsh -c、zsh -lc、zsh -ic 差的不是语法, 是环境

\n

这次我没有一上来继续包在 Gradle 外面猜, 而是先拿 shell 启动方式做切片.

\n

结果非常直接:

\n\n

这三个结果一出来, 问题其实已经被压缩得很小了.

\n

它至少说明了三件事:

\n
    \n
  1. 问题不在命令文本本身.
    2. \n
  2. 问题不在仓库本身.
    3. \n
  3. 问题在 shell 初始化链条.
    4. \n
\n

如果只从排障角度理解, 这几个参数可以先粗暴地记成:

\n\n

这三个参数真正有价值的地方, 是它们背后的启动链路不同.

\n

\"截图\"

\n

翻了 zsh 手册, 启动顺序可以先记成:

\n\n

所以把它映射回这次遇到的三种启动方式, 大概就是:

\n\n

这也解释了为什么 zsh -lc 和 zsh -ic 虽然都不像纯粹的 zsh -c, 但它们拿到的环境仍然可能不同:

\n\n

这里最容易犯的错是:

\n

把 "也是 zsh" 误解成 "环境应该差不多" .

\n

其实不是.

\n

同样叫 zsh, 只要启动参数不同, 加载的初始化文件链就可能不同, 最后拿到的环境变量也可能不同.

\n

我是怎么把问题收敛到 shell 环境上的

\n

排障不是 "经验丰富地乱猜", 而是遇到难题先知道自己不能掌控全局, 先退一步, 控制变量, 二分法排查.

\n

1. 承认这不是一条命令的问题, 而是两个入口的问题

\n

如果同一条命令在两个入口结果相反, 那最应该先做的是: 冻结命令文本, 去比较入口差异.

\n

做实验时先控制变量.

\n

不能一边改项目, 一边猜缓存, 一边再换命令, 最后把自己绕晕.

\n

2. 判断是不是仓库代码本身的问题

\n

如果用户在同一台机器、同一份仓库里手动执行可以成功, 那仓库代码本身大概率不是主因.

\n

这里不是说代码一定没问题, 而是说:

\n

它不值得成为第一怀疑对象.

\n

3. 用 zsh -c、zsh -lc、zsh -ic 切环境

\n

前段时间听到别人说, 问题一旦具体起来, 就不再可怕, 相当于 boss 亮血条了.

\n

Codex 里的工具执行和手动终端不一样 需要切换成更加具体的语言: 差异在 shell 是否走到了交互初始化链条上

\n\n

所以, 问题不是 "有没有 zsh", 而是 "zsh 是按什么语义启动的".

\n

4. 验证最小失败点

\n

环境问题不能一直包在大系统外面猜.

\n

Gradle 套 CMake, CMake 套 Ninja, Ninja 再去调编译器, 中间层太多了, 就会把真正的信号埋掉.

\n

不仅浪费时间, 还浪费我的 token.

\n

继续往下追后, 看到失败链路里实际调用的是 NDK 的 host clang, 然后再去直接看它的头文件搜索路径, 问题就更清楚了.

\n

失败环境里看不到 Darwin SDK 的系统头搜索路径.

\n

问 AI, 说是补上 SDKROOT 试试.

\n

"构建系统可能有很多复杂原因" 的问题收敛为 "当前 shell 没把关键环境带进来"

\n

问题本质

\n

回头看, 这次最值得记住的东西并不是某个 Android native 项目该怎么修, 而是:

\n

在 Codex 里, 交互终端和工具子进程不是同一种 shell 环境.

\n

只要这个前提成立, 后面很多现象就都不奇怪了:

\n\n

说到底, 命令从来都不是脱离上下文运行的.

\n

一条命令真正的执行条件至少包括:

\n\n

只盯着命令文本, 很容易卡住: "我运行的明明是同一条命令."

\n

但从系统视角看, 如果这几个前提不同, 那它根本就不是同一次执行.

\n

以后怎么排这类环境问题

\n

1. 看到 "手工成功, 自动化失败", 不急改代码

\n

先怀疑进程环境, 不是仓库内容.

\n

尤其是在 IDE、Agent、终端工具、CI 这些多入口系统里, 默认不要假设环境一致.

\n

2. 先比较 shell 语义, 不只比较命令文本

\n

zsh -c、zsh -lc、zsh -ic 的差异, 本质不是参数背诵题, 而是启动链路差异.

\n

一旦你知道:

\n\n

很多“同命令不同结果”的问题就会突然具体起来.

\n

3. 验证最小失败点, 不要一直包在大系统外面猜

\n

如果外面套着 Gradle、脚本、任务编排器, 就尽量往里打.

\n

打到真正失败的那一层工具, 看它到底缺什么.

\n

很多环境问题一旦能落到最小命令, 判断速度会快很多.

\n

4. 看到标准头文件缺失, 优先怀疑 sysroot/SDK

\n

像 stdio.h、stdlib.h 这种系统标准头文件找不到时, 第一反应通常不该是 "业务代码写错了"

\n

更应该先看:

\n\n

最后

\n

以前我会把 zsh -c、zsh -lc、zsh -ic 这种区别当成 shell 使用细节.

\n

但这次在 Codex 里排完问题后, 我对它们的理解变了.

\n

它们不只是 "几种启动参数" , 而是几种不同的环境入口.

\n

而很多构建问题、自动化问题、Agent 跑命令的问题, 本质上都不是命令写错了, 而是你没有先分清:

\n

你到底是在同一个环境里执行, 还是只是在看起来相似的两个入口里执行.

\n", "url": "https://vw2x.vercel.app/blog/260327_codex-zsh-interactive-shell", "title": "在 Codex 里重新理解 zsh", "summary": "同一软件, 一条命令, 两种结果. 让我开始区分 zsh 的不同启动方式. ", "date_modified": "2026-03-27T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/en/blog/20260323_mobileagent-v3-testing", "content_html": "

Today I ran a side-by-side experiment on the same problem across two projects and spent 3 hours on it. The conclusion was clear:

\n

In the business environment of mobile security and gray-market app testing, chasing full automation coverage can take far more time than doing the clicks by hand.

\n

I spent enough time on this that I want to record how this should be designed from an engineering point of view when a process needs to run stably for a long time inside a private tool app.

\n

Full-AI Automation Attempts: Open-AutoGLM and MobileAgent-v3

\n

Once the goal shifts from can run to close to 100% stable, the difference becomes obvious:

\n
    \n
  1. Open-AutoGLM is a single loop: screenshot -> action -> execute.
    2. \n
  2. MobileAgent-v3 adds post-action reflection and failure branching, and repeated failures can trigger replanning.
    3. \n
\n

\"Screenshot\"

\n

Pretty impressive. It feels like it grew a brain.

\n

I turned one gray-market test flow into a workflow file similar to GitHub Workflow and even gave screenshots to the AI for context, hoping to lock it down once and trust it every time.

\n

But MobileAgent-v3 was very slow at post-action verification and failure branching. A single judgment took about 10 seconds, which meant the app could ask for root permission and the 10-second countdown would expire before the agent reacted. Then the flow had to roll back and start over. A setup that depends on server-side judgment is really too slow. One full round took 10 minutes. I was getting anxious next to it, and in the end I granted root, the device rebooted because of a device issue, and everything had to start again.

\n

That was awkward.

\n

Beyond that, gray-market environments usually share three traits:

\n
    \n
  1. They are private apps with a lot of startup mapping and permission pre-processing.
    2. \n
  2. UI disturbance is frequent: pop-ups, ads, network state changes, and even device reboots can break the chain.
    3. \n
  3. The regression chain is long, and one complete run can easily exceed 15 minutes.
    4. \n
\n

For the same chain, the critical click may only take a few seconds if a human does it.

\n

The more you push for end-to-end full automation, the more time you may waste in the least stable part.

\n

So the metric can be split out from automation coverage into:

\n
    \n
  1. Time per successful run
    2. \n
  2. Recovery cost after failure
    3. \n
\n

Back to Scripts and Humans

\n

For the Fake Location chain, I changed the flow to stable segments automated + script prompts x human actions.

\n
    \n
  1. The machine handles stable steps: root, install, server, health check.
    2. \n
  2. A human handles high-variance steps: critical taps, temporary pop-up handling, confirmation of file selection paths.
    3. \n
  3. After the human action, the script must immediately return to assertions. No black box is allowed to keep running.
    4. \n
\n

I also kept the GitHub Workflow-like approach, but turned the protocol into a verifiable contract instead of documentation:

\n
    \n
  1. Use JSON Schema for the request / candidate / trace / verification fields.
    2. \n
  2. Provide matching example JSON.
    3. \n
  3. Run the validator and workspace validation scripts on every change.
    4. \n
\n

\"Screenshot\"

\n

The Core Point

\n

The core of automation is not to replace humans. It is to script what is deterministic as much as possible, and to find determinism inside what is not.

\n

If something really is uncertain, do not force it. Separate the uncertainty and use verifiable mechanisms to keep the cost of each layer as low as possible.

\n

Oh, and I also fixed a BUG along the way.

\n

\"BUG\"

\n

I did not expect the PR to merge so quickly, and the homepage even got a small icon. That was a nice surprise.

\n", "url": "https://vw2x.vercel.app/en/blog/20260323_mobileagent-v3-testing", "title": "MobileAgent-v3 Testing", "summary": "If you want stable automation for gray-market app testing, abandon the fantasy of full automation first.", "date_modified": "2026-03-23T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/blog/260323_MobileAgentv3", "content_html": "

今天把同个问题在两个项目里做了对照实验, 花了 3h 时间, 得到一个结论:

\n

在移动安全黑灰产测试的业务环境, 追求 全自动覆盖率 会花费比人手点多得多的时间

\n

花了这么多时间, 我得记录一下, 当要在私有工具 App 上长期稳定执行流程时, 工程上该怎么设计.

\n

全 AI 自动化尝试: Open-AutoGLM 和 MobileAgent-v3 尝试

\n

但当目标从 能跑 变成 接近 100% 稳定, 差异会出现:

\n
    \n
  1. Open-AutoGLM 是单环路: 截图 -> 动作 -> 执行.
    2. \n
  2. MobileAgent-v3 多了动作后反射与失败分流机制, 连续失败可触发重新规划.
    3. \n
\n

\"截图\"

\n

挺厉害的, 感觉长脑子了.

\n

我将某个黑灰产测试的流程, 固定为类似 Github Workflow 的流程文件, 甚至截图给到 AI 辅助理解, 以期一次固定, 次次放心.

\n

但 MobileAgent-v3 的动作后验证和失败分流很慢, 一次判断居然需要 10s 左右, 以至于这个黑灰产 App 问我要 root 权限 10s 倒计时一过就过了, 然后流程需要回滚, 需要从头再来 (这种依赖服务端判断的方案真的是太慢了), 一轮下来, 跑通用了 10min, 我在旁边急急急, 最后给了 root 权限, 因为设备问题, 重启了, 一切又重来.

\n

尬住.

\n

除此之外, 对灰黑产环境进行复现, 往往有 3 个共性:

\n
    \n
  1. 私有 app, 启动映射和权限前置处理较多.
    2. \n
  2. UI 扰动频繁, 弹窗, 广告, 网络态变化, 甚至导致设备重启都会打断链路.
    3. \n
  3. 回归链路长, 一次完整执行可能超过 15 分钟.
    4. \n
\n

而同一条链路里, 关键点击如果交给人做, 可能只需要几秒.

\n

越追求端到端全自动, 越可能在最不稳定的段落浪费最多时间.

\n

所以指标可以从 自动化覆盖率 拆分为:

\n
    \n
  1. 单位成功耗时
    2. \n
  2. 失败后恢复成本
    3. \n
\n

回到脚本和人工

\n

在 Fake Location 链路里, 我把流程改成 稳定段自动化 + 脚本提示x人工动作.

\n
    \n
  1. 机器负责稳定步骤: root, install, server, healthcheck.
    2. \n
  2. 人负责高波动步骤: 关键点击, 临时弹窗处理, 文件选择路径确认.
    3. \n
  3. 人工动作后, 必须立刻回到脚本断言, 不允许黑盒继续跑.
    4. \n
\n

除此之外, 仍然使用类 Github Workflow 的方案, 把协议做成可校验契约, 而不是文档描述

\n
    \n
  1. 用 JSON Schema 写 request/candidate/trace/verification 字段.
    2. \n
  2. 配套 example JSON.
    3. \n
  3. 每次改动都跑 validator 与 workspace 校验脚本.
    4. \n
\n

\"截图\"

\n

本质

\n

自动化的核心不是替代人, 而是尽可能把确定性的东西脚本化, 不确定的东西寻找其确定性.

\n

实在不确定咱也别犟, 把不确定性分离, 用可验证机制把每层的成本压到最低.

\n

哦对了, 顺手修了个 BUG

\n

\"BUG\"

\n

没想到 pr 提上去没一会就合并了, 主页还多了个小图标, 蛮开心的.

\n", "url": "https://vw2x.vercel.app/blog/260323_MobileAgentv3", "title": "MobileAgent-v3 测试", "summary": "黑灰产 App 自动化测试想稳定, 先放弃全自动幻觉.", "date_modified": "2026-03-23T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/en/blog/20260319_nextjs-auth-bypass-cases", "content_html": "

Why I Wrote This

\n

Recently I was working on a Next.js app. While discussing one middleware implementation, I started thinking about a possible authorization bypass.

\n

AI mentioned CVE-2025-29927, which is a Next.js middleware authorization bypass. Many Next.js apps put access control in middleware, and if that layer can be skipped, the page, route handler, or API route behind it may be exposed directly.

\n

The core issue is that an internal control signal was influenced by external input, and because it was not tightly bound to context, the authorization check could be bypassed.

\n

The entry points for CVE-2023-48309, CVE-2022-24858, and CVE-2023-27490 are similar.

\n

With AI pushing more people to build their own sites and apps, the usual pattern is "make it work first", which makes these mistakes very easy to introduce. If you do not pay attention, they can become real loss events.

\n

Context

\n

1) CVE-2025-29927, Next.js middleware authorization bypass

\n\n

External input controls an internal flag -> possible bypass.

\n

2) CVE-2023-48309, NextAuth possible user mocking

\n\n

If it exists, it is treated as valid. That is a bit absurd.

\n

3) CVE-2022-24858, NextAuth open redirect

\n\n

The redirect is not bound-checked.

\n

4) CVE-2023-27490, missing OAuth checks (state/pkce/nonce)

\n\n

Notes

\n

For an attacker:

\n
    \n
  1. Which inputs does this authorization depend on
    2. \n
  2. Which of those inputs can I control
    3. \n
  3. Can I intervene in the middle, test the binding, and capture intermediate state
    4. \n
\n

For the code author:

\n
    \n
  1. Which inputs does this authorization depend on
    2. \n
  2. Can the client influence those inputs
    3. \n
  3. Does the failure path really fail closed
    4. \n
  4. Does the fix restore the invariant instead of only blocking a known payload
    5. \n
\n

If any layer treats untrusted input as a trusted control signal, the system will leak.

\n

Hardening

\n

In my Next.js project, I would make these changes:

\n\n

References

\n\n", "url": "https://vw2x.vercel.app/en/blog/20260319_nextjs-auth-bypass-cases", "title": "CVE-2025-29927 and CVE-2023-27490", "summary": "I do not try to control the whole system. I focus on the parts I can control and influence.", "date_modified": "2026-03-19T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/blog/260319_CVE-2025-29927", "content_html": "

为什么写这篇

\n

最近在写 Next.js 应用, 聊到某个中间件实现的时候, 想到可能存在越权问题

\n

AI 提到了 CVE-2025-29927 这个漏洞, 讲的是 Next.js middleware 授权绕过.\n很多 Next.js 应用会在 middLeware 做前置访问控制, 这层如果被跳过, 后面的 page.route handler.api 就可能直接暴露风险

\n

这个漏洞的本质是, 某个本该内部的控制信号, 被外部输入影响了, 且因为未与上下文强绑定, 导致越权绕过.

\n

CVE-2023-48309, CVE-2022-24858, CVE-2023-27490 这几个洞的切入点也差不多,

\n

因为 AI 的发展, 未来大家都会想手搓一些自己的网站或者应用, 一般就是能跑就行, 自然容易出现这些漏洞, 如果不怎么在意容易资损.

\n

上下文

\n

1) CVE-2025-29927 , Next.js middleware authorization bypass

\n\n

外部输入控制内部 flag -> 可能绕过

\n

2) CVE-2023-48309 , NextAuth possible user mocking

\n\n

存在即合理, 有点搞

\n

3) CVE-2022-24858 , NextAuth open redirect

\n\n

redirect 没有做绑定校验

\n

4) CVE-2023-27490 , OAuth checks missing(state/pkce/nonce)

\n\n

记录

\n

对于攻击者:

\n
    \n
  1. 这次授权依赖哪些输入
    2. \n
  2. 哪些输入是我能控制的
    3. \n
  3. 是否能在过程中操作, 测试其绑定关系, 获得中间态
    4. \n
\n

对于代码编写者:

\n
    \n
  1. 这次授权依赖哪些输入.
    2. \n
  2. 这个输入是否可能被客户端影响.
    3. \n
  3. 失败路径是否真正 fail-closed.
    4. \n
  4. 修复是否恢复了不变量, 而不是只挡住已知 payload.
    5. \n
\n

只要任何一层把 "不可信输入" 当成了"可信控制信号", 系统就会漏.

\n

优化

\n

在我的 Next.js 项目中, 进行如下更新

\n\n

参考

\n\n", "url": "https://vw2x.vercel.app/blog/260319_CVE-2025-29927", "title": "CVE-2025-29927 CVE-2023-27490", "summary": "不想着掌控全局, 只控制我能控制的, 影响更多我能影响的.", "date_modified": "2026-03-19T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/en/blog/20260314_algorithm-assistant-mcp-from-gui-to-api", "content_html": "

1. Introduction: What Kind of Reverse-Engineering Infrastructure Do We Need in the AI Era

\n

On the first day I touched Android security after graduating, I used a Frida script to successfully change a function return value. Watching the app behave according to my will kept me excited until 3 a.m.

\n

But as I did more reverse engineering, it started to feel different.\nEvery time I picked up a new app, I had to find the entry point again, write hooks, stitch parameters together, and inspect logs...\nWhat used to feel exciting turned into a chore: "Do I really have to write all those hooks again?"

\n

So I started "wrapping" things: Frida templates, Python scripts, Xposed modules.\nBut I soon found that requirements are always customized, and my wrappers usually over-engineered themselves. In the end I still had to go back and write the scripts by hand, and then copy a lot of helper functions over manually.\nThe copy-paste happened over and over, easily more than ten times, and it started to feel repetitive and dull.

\n

As my high school math teacher would say, that is not "beautiful".

\n

So what is "beautiful" reverse engineering in the AI era?

\n

My current view is simple: the less repetitive work I have to do, the more beautiful it is. The more it helps me be lazy, the better.

\n

With large models like Cursor, Claude, and Codex becoming common, AI-assisted static analysis has already become normal. A few days ago I saw frida-mcp, which made me realize that AI can also do dynamic analysis now.

\n

My own work also keeps running into small analysis tasks like card-code bypasses and encryption-chain inspection. The app I use most often is Jiang Ge's Algorithm Assistant Pro, which can handle pop-up dismissal, allow screenshots, enhance Reqable packet capture, monitor file read/write, hook common crypto algorithms, and let me choose which classes to hook. It is much more convenient than writing Xposed scripts.

\n

But after only a few runs, my "牛夫人" feeling came back.\nWhy do I still have to pick which app to hook every time, manually add methods, restart the process, check logs, and sometimes even drop a Frida script into /sdcard/ and open a file manager to load it? Why am I clicking all this again? Half an hour later I end up with a pile of logs that I still have to analyze myself.

\n

What if AI clicks for me?\nIf you try it, even Opus 4.6 has to think before every click. If it opens a few pages, it has to think ten times. Watching it operate is slower than clicking by hand, and when I remember that it also costs me tokens, I start feeling annoyed.

\n

That is not just unbeautiful. It is almost ugly.

\n

In fact, GUIs are designed for humans. For AI, text commands naturally match the input format of LLMs and can be chained into complex workflows. APIs and CLIs are the natural shape for agents.

\n

Yesterday I also saw CLI-Anything, which takes open-source software and exposes all of its functions through CLI interfaces so agents can use them better.

\n

That applies to open-source projects. Closed-source tools need a reverse-engineering step.

\n

So this series starts an efficiency exploration for my own work: AI-oriented reverse engineering of GUI tools.

\n

What I want to do is peel these human-facing GUI apps through reverse engineering and extract APIs that large models can call directly. Things I have already done should not need to be clicked through again and again.

\n

2. Methodology: Three Common Entry Points from GUI to API

\n

When you get an app that can only be used through UI clicks and want to turn it into a scriptable or AI-controllable interface, do not rush to think about button macros or UI automation testing. That is too human.

\n

You can hope the author provides an interface, or you can explore it yourself first. Usually there are three common entry points:

\n

1. Find the persistent storage point

\n

Every UI click eventually maps to some data change somewhere.\nIdea: monitor /data/data/<pkg>/shared_prefs, databases, and external storage under /sdcard/Android/data/<pkg>/files. Once you find a config file (XML/JSON/DB), try modifying it with a script to bypass the UI.

\n

2. Find the IPC interface

\n

If the config is not in normal files, or changing the files does not work, then there is probably in-memory caching or cross-process communication.\nIdea: decompile the APK and focus on provider, receiver, and service entries in AndroidManifest.xml, especially components with exported=true. A lot of tools communicate between the UI and backend services through these standard Android mechanisms.

\n

3. Find the CLI

\n

Some tools hide command-line interfaces to make debugging or power-user workflows easier.\nIdea: inspect binaries, install scripts, or search the decompiled code for keywords like Runtime.getRuntime().exec and su -c to uncover hidden shell commands.

\n

3. Case Study: Algorithm Assistant MCP

\n

The phased goals were:

\n
    \n
  1. Toggle the apps that Algorithm Assistant should affect inside LSPosed
    2. \n
  2. Toggle the apps inside the Algorithm Assistant UI
    3. \n
  3. Read, write, and apply configuration for a single app, including options such as hash hooks and custom method hooks
    4. \n
  4. Write and apply Frida scripts for a single app
    5. \n
  5. Extract, structure, and query logs
    6. \n
\n

Everything should be moved toward CLI so an agent can use it directly.

\n

1. Persistence point: confirm package-level config first, then trace AppSwitch

\n

In the experiment, LSPosed had these apps selected:

\n\n

Algorithm Assistant's own UI had these selected:

\n\n

I started with the usual directories:

\n\n

One thing became clear quickly: the target package's hook config really lives in the external directory\n/sdcard/Android/data/com.junge.algorithmAidePro/files/config/<targetPackage>.json

\n

But that is only config. The Algorithm Assistant UI's "application selection state (AppSwitch)" does not appear directly in the app's private directory. Under shared_prefs I saw several .sp files that looked like config, but searching for the package name did not hit anything.

\n

The easiest mistake here is to assume "no plain-text package name = no local persistence".\nThat is not true. Since the file layer did not show it, I moved to the code layer instead (the path of least resistance).

\n

2. IPC interface: the Provider exposed the key read/check surface

\n

After pulling base.apk, the point was not to read everything. The point was to find the config read/write path.

\n

Decompilation quickly surfaced a few key pieces:

\n
    \n
  1. ConfigReader.getInstanceByAlgorithmAidePro(String str)
    2. \n
  2. ConfigProvider
    3. \n
  3. android:authorities="algorithmAidePro"
    4. \n
  4. xposedsharedprefs=true
    5. \n
\n

The most important one was ConfigProvider. It exposed two query dimensions directly:

\n\n
# Query AppSwitch\nadb shell content query --uri content://algorithmAidePro/com.example.app --projection AppSwitch\n\n# Write AppSwitch\nadb shell content insert --uri content://algorithmAidePro/com.example.app --bind AppSwitch:s:true\n
\n

Use the Provider as the read/check surface first, then infer the real storage point from there.

\n

Main AppSwitch location: AppSwitch.json, not the Provider

\n

At that point, one odd thing became obvious:

\n\n

So it was not that file. Searching for AppSwitch led to the real location:

\n
/data/system/junge/AppSwitch.json\n
\n

Reading it directly gives a package-name-to-boolean map, for example:

\n
{\n  "com.example.app": true,\n  "com.lerist.fakelocation": true\n}\n
\n

On this device and this version, the Algorithm Assistant UI's app-selection source of truth already matched the constants in AlgorithmServer:

\n\n

3. Taking over LSPosed scope through CLI: LSPosed_mod

\n

LSPosed scope is another config set, and it does not live in the Algorithm Assistant directory.

\n

The real location is:

\n
/data/adb/lspd/config/modules_config.db\n/data/adb/lspd/config/modules_config.db-wal\n
\n

String hits across the main DB, WAL, and backup DB confirmed that this database stores LSPosed module enablement data.\nBut editing it directly with sqlite3 is not ideal, so I switched to the CLI exposed by LSPosed_mod.

\n

First confirm the environment:

\n
    \n
  1. The device has /data/adb/lspd/bin/cli, and the CLI needs root permission
    2. \n
  2. Enable CLI must be turned on in LSPosed Manager
    3. \n
\n
su -c /data/adb/lspd/bin/cli scope set -a com.junge.algorithmAidePro com.qiyi.video/0\n
\n

4. Continued Exploration: Log Source, Hook DSL, and the Dynamic-Analysis Loop

\n

1. Finding the log source: how it narrowed down to SQLite step by step

\n
/sdcard/Android/media/<targetPackage>/database/algorithmAidePro.db\n
\n

Round 1: start from the UI's "save all logs" action

\n

The most natural first idea was to automate the "save all logs" button on the log page.\nLater I confirmed two facts:

\n
    \n
  1. The UI button eventually reaches ThreadSaveLogList -> ConfigReader.createLogFile(null)
    2. \n
  2. The exported text file lands in:
    3. \n
\n
/sdcard/Android/data/com.junge.algorithmAidePro/files/Log/<yyyy-MM-dd_HH_mm_ss>.log\n
\n

In the first round, I followed already verified paths:

\n
    \n
  1. content://algorithmAidePro/...
    2. \n
  2. logs or config files already written to external storage
    3. \n
\n

First, content://algorithmAidePro/... could reliably read:

\n
    \n
  1. projection=config
    2. \n
  2. projection=AppSwitch
    3. \n
\n

But there was no export-log-related projection, and no stable insert/update/call write entry either.

\n

Second, the Frida log chain existed independently.

\n
/sdcard/Android/data/com.junge.algorithmAidePro/files/files/fridaLog.html\n
\n

That file can be pulled directly, but it only corresponds to Frida script logs, not native hook logs.\nAnd while fridaLog.html does exist, it is more of a UI/export surface and not necessarily the lowest runtime write surface.\nLater in the actual device run, com.example.app exposed a more direct file:

\n
/sdcard/Android/media/com.example.app/database/frida.log\n
\n

This file records Frida runtime logs directly, and it is a more direct smoke-test target than fridaLog.html.

\n

Round 2: start doubting whether UI text export is the best target

\n

At this point it was clear that "save all logs" is itself a human-facing export action. Its essence is:

\n\n

Trying to replace the button click felt like the wrong direction, and it could not avoid the UI trigger anyway.

\n

The better question was: where is the raw storage behind the data shown on the log page?\nThe idea shifted from "simulate UI export" to "find the log source directly".

\n

Round 3: keep tracing from private directories and system-side config

\n

Next I checked a few places that looked the most likely to hold logs:

\n
    \n
  1. /data/user/0/com.junge.algorithmAidePro/files
    2. \n
  2. /data/user/0/com.junge.algorithmAidePro/databases
    3. \n
  3. /data/system/junge/
    4. \n
\n

/data/system/junge/ had a lot of content, and it looked very much like the Algorithm Assistant system-side repository:

\n\n

At this point I already knew:

\n\n

Following that line naturally led to Android/media/<pkg>/database.

\n

Round 4: search globally by database name

\n

Since the UI page is probably backed by structured data, I should search for the database rather than keep staring at text files.

\n

The turning point was finding:

\n
/data/media/0/Android/media/com.example.app/database/algorithmAidePro.db\n
\n

Once that path appeared, several things clicked:

\n
    \n
  1. The path is per target package, which fits the idea of one separate log store per app
    2. \n
  2. The name is directly algorithmAidePro.db, which is clearly tied to the product
    3. \n
  3. It lives under the target app's media directory, not the UI export directory
    4. \n
\n

At that point there was no reason to keep guessing. I pulled it and opened it with SQLite.

\n

Round 5: verify whether this DB is actually the log source

\n

After pulling the DB, sqlite_master was very clean:

\n
table|LOG_DATA_V2|LOG_DATA_V2\ntable|android_metadata|android_metadata\ntable|sqlite_sequence|sqlite_sequence\n
\n

The schema also pointed directly to logging:

\n
CREATE TABLE IF NOT EXISTS "LOG_DATA_V2" (\n  "_id" INTEGER PRIMARY KEY AUTOINCREMENT,\n  "GROUP" INTEGER NOT NULL,\n  "TYPE" INTEGER NOT NULL,\n  "OBJ_NAME" TEXT,\n  "CLASS_NAME" TEXT,\n  "LOG_NAME" TEXT,\n  "TIME" INTEGER NOT NULL,\n  "IS_READ" INTEGER NOT NULL,\n  "LOG_DETAILS_RAW" BLOB,\n  "CALL_STACK" TEXT\n);\n
\n

At this point it was basically confirmed:

\n\n

Querying the latest rows also made sense:

\n\n

And the row count on this device was real:

\n
124\n
\n

The original idea was:

\n
    \n
  1. Avoid clicking the UI button for "save all logs"
    2. \n
  2. Make the app generate a .log
    3. \n
  3. adb pull it
    4. \n
\n

What I actually found was:

\n
    \n
  1. adb pull /sdcard/Android/media/<pkg>/database/algorithmAidePro.db
    2. \n
  2. Query it directly with sqlite3 or a GUI tool
    3. \n
\n

The latter is much better for future MCP work:

\n
    \n

  1. structured

    \n
    2. \n

  2. filterable

    \n
    3. \n

  3. sortable

    \n
    4. \n

  4. incrementally exportable

    \n
    5. \n

  5. directly convertible to TSV / CSV / JSON

    \n
    6. \n

  6. The UI text export path has been reverse-engineered, but it is not the best automation target

    \n
    7. \n

  7. content://algorithmAidePro/... is still a reliable read/check surface, not a log-export surface

    \n
    8. \n

  8. Frida logs still live separately in fridaLog.html

    \n
    9. \n

  9. Native hook logs already have a better non-UI main path: Android/media/<pkg>/database/algorithmAidePro.db

    \n
    10. \n
\n

The small closed loop I ended up with was not "automatically click save logs", but "export the structured hook-log database directly through CLI and query it with SQL".

\n

Example:

\n
adb pull /sdcard/Android/media/com.example.app/database/algorithmAidePro.db .\nsqlite3 algorithmAidePro.db 'select count(*) from LOG_DATA_V2;'\nsqlite3 -header -column algorithmAidePro.db "\nselect\n  _id,\n  \\"GROUP\\",\n  TYPE,\n  ifnull(OBJ_NAME,'') as obj_name,\n  ifnull(CLASS_NAME,'') as class_name,\n  ifnull(LOG_NAME,'') as log_name,\n  TIME,\n  length(LOG_DETAILS_RAW) as raw_len\nfrom LOG_DATA_V2\norder by TIME desc\nlimit 10;\n"\n
\n

Tip 1: Provider is an extremely strong verification surface

\n

If the target exposes a Provider, do not only rely on static analysis.\nBecause a Provider can answer directly:

\n\n

That is much faster than guessing file formats.

\n

Tip 2: Xposed modules deserve extra attention under /data/misc/.../prefs

\n

A lot of people keep staring at:

\n\n

But for modules with xposedsharedprefs, the config may not be in the app-private directory at all. It may live in a shared location that Xposed can read.

\n

2. MCP breakdown: separate the three layers of state first

\n

If I want to turn Algorithm Assistant into a general Java Hook MCP later, the actions need to be split into at least three layers:

\n
    \n
  1. Write the target package hook config\n
    2. \n
  2. Turn on the app in the Algorithm Assistant UI\n
    3. \n
  3. Sync LSPosed scope\n
    4. \n
\n

If those three layers are not separated, it is very easy to mix states up when building CLI and MCP later.

\n

What I mainly separated this time was:

\n\n

3. On-device verification: package-level JSON

\n

When all default switches are enabled, the package-level JSON on the device roughly looks like this:

\n
{\n  "ApplicationSwitch": true,\n  "ExceptionSwitch": true,\n  "SharedPreferencesPutSwitch": true,\n  "activitySwitch": true,\n  "assetsSwitch": true,\n  "cameraHookSwitch": true,\n  "checkRootSwitch": true,\n  "cipherSwitch": true,\n  "closeDialogSwitch": true,\n  "dialogKeyword": "注册码,机器码,激活码",\n  "dialogSwitch": true,\n  "digestSwitch": true,\n  "exitSwitch": true,\n  "fileDeleteSwitch": true,\n  "fileSwitch": true,\n  "fileWriteSwitch": true,\n  "getSharedPreferencesSwitch": true,\n  "hiddenVpnSwitch": true,\n  "hiddenWifiProxySwitch": true,\n  "hiddenXposedSwitch": true,\n  "justTrustMePlushSwitch": true,\n  "logSwitch": true,\n  "macSwitch": true,\n  "onClickSwitch": true,\n  "reqableSwitch": true,\n  "reqableSwitch_native": true,\n  "screenSwitch": true,\n  "shellSwitch": true,\n  "signSwitch": true,\n  "sqliteDeleteSwitch": true,\n  "sqliteExecSQLSwitch": true,\n  "sqliteInsertSwitch": true,\n  "sqliteOpenSwitch": true,\n  "sqliteQuerySwitch": true,\n  "sqliteUpdateSwitch": true,\n  "textViewSwitch": true,\n  "webCryptSwitch": true,\n  "webViewDebugSwitch": true,\n  "webViewLoadUrlSwitch": true\n}\n
\n

Verification 1: projection=config is not decided by config.xml

\n

It is easy to assume:

\n\n

But on-device verification showed that at least for projection=config, that is not the case.

\n

I ran two comparison experiments:

\n
    \n
  1. pkg.json.digestSwitch=true, config.xml.digestSwitch=false\n
    2. \n
  2. pkg.json.digestSwitch=false, config.xml.digestSwitch=false\n
    3. \n
\n

That is enough to show that:

\n
/sdcard/Android/data/com.junge.algorithmAidePro/files/config/<pkg>.json\n
\n

is the primary control source for projection=config, and it takes priority over:

\n
/data/misc/<uuid>/prefs/com.junge.algorithmAidePro/config.xml\n
\n

So when I want to change a target package config by field, I can edit the package-level JSON directly and do not need to touch config.xml.

\n

Verification 2: root does not mean unrestricted writes

\n

On this machine, the su context is:

\n
uid=0(root) gid=0(root) context=u:r:magisk:s0\n
\n

SELinux is still Enforcing. Also:

\n\n

That means "having root" does not mean "every write path works". Especially for paths under /data/misc/.../prefs, I need to respect the magisk su context instead of assuming it just works.

\n

Verification 3: recommended CLI order for plain file overwrite

\n

If the goal is "do not click the UI, just change it correctly from the command line", the most stable loop has been:

\n
    \n
  1. force-stop Algorithm Assistant
    2. \n
  2. overwrite the package-level JSON
    3. \n
  3. start Algorithm Assistant
    4. \n
  4. read back through the Provider for verification
    5. \n
\n

Command order:

\n
adb shell am force-stop com.junge.algorithmAidePro\nadb push com.example.app.json /data/local/tmp/com.example.app.json\nadb shell su -c 'cp /data/local/tmp/com.example.app.json /sdcard/Android/data/com.junge.algorithmAidePro/files/config/com.example.app.json'\nadb shell monkey -p com.junge.algorithmAidePro -c android.intent.category.LAUNCHER 1\nadb shell content query --uri content://algorithmAidePro/com.example.app --projection config\n
\n

4. Custom hook export: the native DSL is already visible

\n

I also dumped the "custom hook method" that I can quickly add by hand inside Algorithm Assistant.\nFor com.example.app, there are two files with the same content on the device:

\n\n
    \n
  1. config/<pkg>.json is the active config
    2. \n
  2. exportConfig/<pkg>.json is the exported snapshot
    3. \n
  3. The exported file is already the native config syntax accepted by Algorithm Assistant, so I do not need to guess the schema first
    4. \n
\n

The exported core for com.example.app looked roughly like this:

\n
{\n  "enableScript": "bezierzhixian.js",\n  "hookList": [\n    {\n      "argsValues": [],\n      "className": "com.example.app.DemoTarget",\n      "constructor": true,\n      "description": "来自快速添加的Hook",\n      "enable": true,\n      "intercept": false,\n      "methodName": "<init>",\n      "parameterSign": "",\n      "printLog": true,\n      "results": ""\n    },\n    {\n      "argsValues": [],\n      "className": "com.example.app.DemoTarget",\n      "constructor": false,\n      "description": "来自快速添加的Hook",\n      "enable": true,\n      "intercept": false,\n      "methodName": "someMethod",\n      "parameterSign": "",\n      "printLog": true,\n      "results": ""\n    }\n  ]\n}\n
\n

The key takeaway is that the native hook DSL is already there. I do not need to treat the UI as the source of truth.

\n

5. What This Means

\n

The point is not to turn every GUI into a CLI for the sake of it. The point is to find the points that already have structure:

\n
    \n
  1. storage
    2. \n
  2. IPC
    3. \n
  3. command line
    4. \n
\n

Once those are separated, the UI becomes a presentation layer instead of the only control surface.

\n

That is the path I want for future reverse-engineering work:\nnot more clicking, but less repeated clicking.

\n

6. Architecture Sketch

\n

The current chain can be summarized like this:

\n

\"Architecture\"

\n

7. If I Continue This Line

\n

The next step is not to keep staring at the UI. It is to turn these verified surfaces into a repeatable CLI and then into MCP actions:

\n
    \n
  1. package config write
    2. \n
  2. app enable state read/write
    3. \n
  3. LSPosed scope sync
    4. \n
  4. log query and export
    5. \n
\n

Once that exists, the agent can work with the tool instead of the GUI.

\n", "url": "https://vw2x.vercel.app/en/blog/20260314_algorithm-assistant-mcp-from-gui-to-api", "title": "Algorithm Assistant MCP: Thoughts on Moving from GUI to API", "summary": "Exploring how to gradually peel a human-facing reverse-engineering GUI tool into agent-facing APIs and CLIs.", "date_modified": "2026-03-14T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/blog/260314_algorithm-mcp", "content_html": "

一、引言: AI 时代我们需要什么样的逆向基建

\n

毕业接触 Android 安全的第一天, 用 Frida 脚本成功修改函数的返回值，看着 APP 按自己的意志运行，兴奋得半夜 3 点还没睡着觉.

\n

但随着逆向做得越来越多, 事情变味了. \n每次拿到一个新的 App, 又要重新找入口、写 Hook、拼参数、看日志 … \n曾经的 "小甜甜" 变成了 "牛夫人". 心里烦躁居多: "又特么要写遍 Hook?”

\n

于是开始 "封装", 写 Frida 模板、Python 脚本, XPosed 模块. \n但很快又发现: 需求总是定制化, 而自己的封装往往过度设计, 最后还是得乖乖回去手写脚本, 然后发现很多工具函数又得手动复制一遍. \n中间的复制粘贴得有十几次, 感觉全是重复性工作, 有些枯燥.

\n

用我高中数学老师的话来说, 这不 "美".

\n

那在 AI 时代, 什么是 "美" 的逆向工程？

\n

目前我觉得, 要做的重复性工作越少, 就越美. 越能让我偷懒, 就越美.

\n

随着大模型 (Cursor, Claude, Codex) 的普及, AI 辅助静态代码分析已经成为常态. 前几天看到 frida-mcp, 意识到 AI 现在也可以动态分析了.

\n

我当前工作也总会有点小外挂分析需求, 什么卡密校验绕过, 加密链路分析之类的活, 最常用的 APP 就是军哥的算法助手 Pro, 什么过弹窗, 允许截屏, 增强 Reqable 抓包, 文件读写监控, 常用的密码算法 hook 之类, 还能自己选择 hook 哪些类, 比写 XPosed 脚本方便多了.

\n

但果然没干几次我的 "牛夫人感应" 就又出现了. \n怎么每次都得选择 hook 哪个 App, 手动增加要 Hook 的方法, 重启进程, 查看日志, 有时候我还得给 frida 脚本放到 /sdcard/ 并打开文件管理器选择载入, 怎么又特么得点一遍? 弄了半小时, 得到了一堆还是需要我自己分析的日志.

\n

要不让 AI 点?\n试一下会发现, 就算是 Opus4.6, 每点击一下它也得想想下一步做什么, 点几个页面他得想 10 次, 看它操作比我自己手点还慢, 再一想这还要花我 Token, 就开始生闷气了.

\n

岂止是不美, 简直是有点丑陋.

\n

事实上, GUI 本身是为人类设计的, 但对 AI 来说, 文本命令天然匹配 LLM 的输入格式, 可自由串联成复杂工作流, API 和 CLI 才是面向 agent 的.

\n

昨天也看到了 CLI-Anything, 是基于开源代码, 将所有的开源软件功能暴露出 CLI 接口, 让 agent 可以更好的使用.

\n

这是针对开源项目的, 闭源就得有逆向的环节.

\n

因此, 本系列文章是给我自己工作的提效探索开个头: 面向 AI 的逆向 GUI 工具利用.

\n

我想做的, 就是把这些面向人类的 GUI 软件, 通过逆向分析剥离出可以直接被大模型调用的 API. 已经做过的事, 就别再反复手点了.

\n

二、方法论：从 GUI 到 API 的 3 个通用切入点

\n

当你拿到一个只能通过 UI 点击的 APP，想要把它变成脚本或 AI 可以自动控制的接口时，先不要去想“按键精灵”或 UI 自动化测试 (那太人类了)

\n

可以期待作者提供接口, 也可以先尝试自己探索探索, 通常有以下 3 个通用的切入点:

\n

1. 寻找持久化落盘点

\n

UI 的每次点击，最终必然对应着某处数据的修改\n思路: 监控 /data/data/<pkg>/shared_prefs、databases, 以及外部存储 /sdcard/Android/data/<pkg>/files. 只要找到配置文件 (XML/JSON/DB) , 可尝试用脚本修改文件, 就能绕过 UI.

\n

2. 寻找跨进程通信 (IPC) 接口

\n

如果配置不在常规文件里，或者修改文件后不生效，说明存在内存缓存或跨进程通信。\n思路: 反编译工具 APK, 重点排查 AndroidManifest.xml 中的 provider、receiver、service (特别是 exported=true 的组件) . 很多工具的 UI 和后台服务是通过这些 Android 标准机制通信的.

\n

3. 寻找命令行 (CLI)

\n

有些工具为了方便高级用户或自身调试，会暗藏命令行接口。\n思路: 检查工具的二进制文件、安装脚本, 或者在反编译代码中搜索 Runtime.getRuntime().exec、su -c 等关键字, 寻找隐藏的 shell 命令.

\n

三、实战解剖：算法助手 MCP

\n

几个阶段性目标:

\n
    \n
  1. 在 LSPosed 勾选算法助手生效的应用
    2. \n
  2. 在算法助手 UI 里勾选生效的应用
    3. \n
  3. 针对单个应用的配置读取, 写入, 生效 (包括常见的选项如哈希算法的 hook, 自定义方法的 hook 等)
    4. \n
  4. 针对单个应用的 frida 脚本写入和应用
    5. \n
  5. 日志的提取, 结构化和查询\n都尽量改造成 CLI, 让 agent 可以直接使用.
    6. \n
\n

1. 持久化落盘点：先确认包级配置, 再追 AppSwitch

\n

实验时，LSPosed 里勾选的是：

\n\n

开始找, 先看算法助手自己的常见目录：

\n\n

这里最容易犯的错误, 就是默认认为 "找不到明文包名 = 没有本地持久化" . \n实际不然, 既然文件层面找不到, 我们就转向代码层面 (寻找阻力最小路径)

\n

2. IPC 接口：Provider 暴露了关键读校验面

\n

把 base.apk 拉下来后，重点不是全量看代码，而是找配置读写路径。

\n

反编译后很快能抓到几个关键点：

\n
    \n
  1. ConfigReader.getInstanceByAlgorithmAidePro(String str)
    2. \n
  2. ConfigProvider
    3. \n
  3. android:authorities="algorithmAidePro"
    4. \n
  4. xposedsharedprefs=true
    5. \n
\n

其中最关键的是 ConfigProvider. 它直接暴露了两个查询维度:

\n\n
# 查询 AppSwitch\nadb shell content query --uri content://algorithmAidePro/com.example.app --projection AppSwitch\n\n# 写入 AppSwitch\nadb shell content insert --uri content://algorithmAidePro/com.example.app --bind AppSwitch:s:true\n
\n

先拿 Provider 当读校验面, 再反推真实落点

\n

AppSwitch 的主落点：AppSwitch.json 不是 Provider

\n

到这里出现了一个反常现象：

\n\n

说明不是这个文件, 使用 AppSwitch 关键词找到了实际落点

\n
/data/system/junge/AppSwitch.json\n
\n

直接读取内容会得到一份包名到布尔值的映射，例如：

\n
{\n  "com.example.app": true,\n  "com.lerist.fakelocation": true,\n}\n
\n

当前版本和这台设备上，算法助手 UI 的应用勾选状态主仓库已经和 AlgorithmServer 里的常量对上了：

\n\n

3. CLI 接管 LSPosed 作用域: LSPosed_mod

\n

LSPosed 的作用域是另一份配置, 不在算法助手目录里.

\n

真实位置在:

\n
/data/adb/lspd/config/modules_config.db\n/data/adb/lspd/config/modules_config.db-wal\n
\n

通过主库、WAL 和备份库的字符串命中, 可以确认这个 db 里存的是 LSPosed 的模块生效信息.\n但直接改 sqlite3 不太优雅, 所以后面直接转向 LSPosed_mod 提供的 CLI.

\n

先确认环境：

\n
    \n
  1. 设备存在 /data/adb/lspd/bin/cli, CLI 需要 root 权限
    2. \n
  2. 需要在 LSPosed Manager 里开启 Enable CLI
    3. \n
\n
su -c /data/adb/lspd/bin/cli scope set -a com.junge.algorithmAidePro com.qiyi.video/0\n
\n

四、继续探索：日志源, Hook DSL 与动态分析闭环

\n

1. 日志源定位：如何一步步收敛到 SQLite

\n
/sdcard/Android/media/<targetPackage>/database/algorithmAidePro.db\n
\n

第一轮：先从 UI 的 "保存所有日志" 反推

\n

一开始最自然的思路, 是围绕日志页面里的 "保存所有日志" 做自动化. \n这条路后来确认过两个事实:

\n
    \n
  1. UI 按钮最终会走到 ThreadSaveLogList -> ConfigReader.createLogFile(null)
    2. \n
  2. 导出的文本文件会落到:
    3. \n
\n
/sdcard/Android/data/com.junge.algorithmAidePro/files/Log/<yyyy-MM-dd_HH_mm_ss>.log\n
\n

第一轮里, 借用已有的经验, 先沿 "已验证路径" 查找:

\n
    \n
  1. 已经验证过的 content://algorithmAidePro/...
    2. \n
  2. 已经落到外置目录的日志或配置文件\n第一, content://algorithmAidePro/... 能稳定读到:
    3. \n
  3. projection=config
    4. \n
  4. projection=AppSwitch\n但没看到任何 "导出日志" 相关 projection, 也没看到稳定可用的 insert/update/call 写入口.
    5. \n
\n

第二, Frida 日志这条链路是独立成立的.

\n
/sdcard/Android/data/com.junge.algorithmAidePro/files/files/fridaLog.html\n
\n

这个能直接拉, 但它只对应 Frida 脚本日志, 不是原生 hook 日志. \n而且 fridaLog.html 的确存在, 但它偏向 UI/导出面, 不一定是最底层运行时写入面. 后面继续实机推进时, com.example.app 又看到了一个更直接的文件:

\n
/sdcard/Android/media/com.example.app/database/frida.log\n
\n

这个文件会直接记录 Frida 运行时日志, 做 smoke test 比 fridaLog.html 更直接.

\n

第二轮：开始怀疑 UI 文本导出不是最优目标

\n

到这里警觉了, "保存所有日志" 本身就是一个面向人看的导出动作. 它本质上是:

\n\n

更该问的是: "日志页面展示的数据, 最原始的存储到底在哪？" \n思路从 "模拟 UI 导出" 变成了 "直接找日志源" .

\n

第三轮：从私有目录和系统侧配置继续反查

\n

接下来先排了几处看起来最像“会放日志”的地方：

\n
    \n
  1. /data/user/0/com.junge.algorithmAidePro/files
    2. \n
  2. /data/user/0/com.junge.algorithmAidePro/databases
    3. \n
  3. /data/system/junge/
    4. \n
\n

/data/system/junge/ 里面确实东西很多，而且看起来很像“算法助手系统侧仓库”：

\n\n

但再往里看就会发现，这里主要是：

\n\n

以 com.example.app/config.json 为例，里面已经能直接看到：

\n\n

但这里后来踩了一个很典型的坑。

\n

一开始很容易顺着笔记继续默认：

\n
    \n
  1. files/config/<pkg>.json 是当前生效配置
    2. \n
  2. enableScript 在这份 JSON 里
    3. \n
  3. 那改外部脚本文件内容再重启，应该就会生效
    4. \n
\n

第一句是对的，后两句不完整。

\n

后面实机和反编译一起对账后，边界变成了：

\n\n

以 com.example.app 为例，当前能直接对上的就是：

\n\n

这时候已经能排掉几类常见误判了:

\n\n

按这个思路继续往下找, Android/media/<pkg>/database 这条线就变得很顺了. 想想也是, 对这类“一套宿主管多个目标”的形态, 配置统一放宿主侧, 日志按目标包落地, 本来就很合理.

\n

第四轮：开始按数据库名全局反查\n既然 UI 页面背后大概率是结构化数据，就应该反过来找数据库，而不是继续盯着文本文件。\n转折点不在代码, 而在设备全局搜索：

\n
/data/media/0/Android/media/com.example.app/database/algorithmAidePro.db\n
\n

这个路径一出现，很多事情就串起来了：

\n
    \n
  1. 路径按目标包分目录，符合“每个目标 App 单独存日志”的直觉
    2. \n
  2. 名字直接叫 algorithmAidePro.db，和产品本身高度相关
    3. \n
  3. 它不在 UI 导出目录，而在目标 App 的外置媒体目录\n这时候就不应该再猜了，直接拉下来开 SQLite。
    4. \n
\n

第五轮：验证这个库是不是日志源\n把库拉下来后，看 sqlite_master，结果非常干净：

\n
table|LOG_DATA_V2|LOG_DATA_V2\ntable|android_metadata|android_metadata\ntable|sqlite_sequence|sqlite_sequence\n
\n

表结构也直接指向日志用途：

\n
CREATE TABLE IF NOT EXISTS "LOG_DATA_V2" (\n  "_id" INTEGER PRIMARY KEY AUTOINCREMENT,\n  "GROUP" INTEGER NOT NULL,\n  "TYPE" INTEGER NOT NULL,\n  "OBJ_NAME" TEXT,\n  "CLASS_NAME" TEXT,\n  "LOG_NAME" TEXT,\n  "TIME" INTEGER NOT NULL,\n  "IS_READ" INTEGER NOT NULL,\n  "LOG_DETAILS_RAW" BLOB,\n  "CALL_STACK" TEXT\n);\n
\n

到这里基本已经坐实了：

\n\n

再继续查最近几条：

\n\n

而且当前设备上行数是实打实的：

\n
124\n
\n

做到这里, 结论就很清楚了.

\n

最初设想是：

\n
    \n
  1. 想办法不用 UI 点击“保存所有日志”
    2. \n
  2. 让 app 生成一个 .log
    3. \n
  3. 再 adb pull\n而现在找到的路径是：
    4. \n
  4. 直接 adb pull /sdcard/Android/media/<pkg>/database/algorithmAidePro.db
    5. \n
  5. 用 sqlite3 / GUI 工具直接查询
    6. \n
\n

后者明显更适合后续 MCP 化:

\n
    \n

  1. 结构化

    \n
    2. \n

  2. 可筛选

    \n
    3. \n

  3. 可排序

    \n
    4. \n

  4. 可增量导出

    \n
    5. \n

  5. 可直接转 TSV / CSV / JSON

    \n
    6. \n

  6. UI 文本导出链路已经逆出来了，但它不是最优自动化目标

    \n
    7. \n

  7. content://algorithmAidePro/... 仍然是可靠读校验面，不是日志导出面

    \n
    8. \n

  8. Frida 日志仍然独立落在 fridaLog.html

    \n
    9. \n

  9. 原生 hook 日志已经找到更好的非 UI 主路径：Android/media/<pkg>/database/algorithmAidePro.db

    \n
    10. \n
\n

这轮跑通的小闭环不是“自动触发 UI 保存日志”, 而是“直接通过 CLI 导出结构化 hook 日志数据库并用 SQL 查询”.

\n

示例：

\n
adb pull /sdcard/Android/media/com.example.app/database/algorithmAidePro.db .\nsqlite3 algorithmAidePro.db 'select count(*) from LOG_DATA_V2;'\nsqlite3 -header -column algorithmAidePro.db "\nselect\n  _id,\n  \\"GROUP\\",\n  TYPE,\n  ifnull(OBJ_NAME,'') as obj_name,\n  ifnull(CLASS_NAME,'') as class_name,\n  ifnull(LOG_NAME,'') as log_name,\n  TIME,\n  length(LOG_DETAILS_RAW) as raw_len\nfrom LOG_DATA_V2\norder by TIME desc\nlimit 10;\n"\n
\n

方法提示 1：Provider 是极强的验证面

\n

只要目标自己暴露了 Provider，就不要只做静态分析\n因为 Provider 能直接回答：

\n\n

方法提示 2：Xposed 模块要特别警惕 /data/misc/.../prefs

\n

很多人会一直盯着：

\n\n

2. MCP 化拆解：先把三层状态分开

\n

如果后面要把算法助手做成一个通用 Java Hook MCP，动作至少要拆成三层：

\n
    \n
  1. 写目标包 Hook 配置\n
    2. \n
  2. 打开算法助手 UI 勾选\n
    3. \n
  3. 同步 LSPosed 作用域\n
    4. \n
\n

这三层不拆开，后面做 CLI 和 MCP 很容易把状态混在一起。

\n

这次主要拆开的就是：

\n\n

3. 实机验证：包级 JSON

\n

当所有默认开关都打开时，实机里这份包级 JSON 大致会长这样：

\n
{\n  "ApplicationSwitch": true,\n  "ExceptionSwitch": true,\n  "SharedPreferencesPutSwitch": true,\n  "activitySwitch": true,\n  "assetsSwitch": true,\n  "cameraHookSwitch": true,\n  "checkRootSwitch": true,\n  "cipherSwitch": true,\n  "closeDialogSwitch": true,\n  "dialogKeyword": "注册码,机器码,激活码",\n  "dialogSwitch": true,\n  "digestSwitch": true,\n  "exitSwitch": true,\n  "fileDeleteSwitch": true,\n  "fileSwitch": true,\n  "fileWriteSwitch": true,\n  "getSharedPreferencesSwitch": true,\n  "hiddenVpnSwitch": true,\n  "hiddenWifiProxySwitch": true,\n  "hiddenXposedSwitch": true,\n  "justTrustMePlushSwitch": true,\n  "logSwitch": true,\n  "macSwitch": true,\n  "onClickSwitch": true,\n  "reqableSwitch": true,\n  "reqableSwitch_native": true,\n  "screenSwitch": true,\n  "shellSwitch": true,\n  "signSwitch": true,\n  "sqliteDeleteSwitch": true,\n  "sqliteExecSQLSwitch": true,\n  "sqliteInsertSwitch": true,\n  "sqliteOpenSwitch": true,\n  "sqliteQuerySwitch": true,\n  "sqliteUpdateSwitch": true,\n  "textViewSwitch": true,\n  "webCryptSwitch": true,\n  "webViewDebugSwitch": true,\n  "webViewLoadUrlSwitch": true\n}\n
\n

验证 1：projection=config 不是 config.xml 说了算

\n

一开始很容易觉得：

\n\n

做了两组对照实验：

\n
    \n
  1. pkg.json.digestSwitch=true，config.xml.digestSwitch=false\n
    2. \n
  2. pkg.json.digestSwitch=false，config.xml.digestSwitch=false\n
    3. \n
\n

这已经足够说明：

\n
/sdcard/Android/data/com.junge.algorithmAidePro/files/config/<pkg>.json\n
\n

才是 projection=config 的主控制源，优先级高于：

\n
/data/misc/<uuid>/prefs/com.junge.algorithmAidePro/config.xml\n
\n

所以按字段改目标包配置时，直接改包级 JSON 就行，不用碰 config.xml。

\n

验证 2：Root 也不等于无条件可写

\n

这台机器上 su 的上下文是：

\n
uid=0(root) gid=0(root) context=u:r:magisk:s0\n
\n

SELinux 仍然是 Enforcing。而且：

\n\n

验证 3：纯文件覆盖的推荐 CLI 顺序

\n

如果目标是“不要点 UI，只靠命令行改成功”，当前最稳定的闭环已经收敛成下面这 4 步：

\n
    \n
  1. force-stop 算法助手
    2. \n
  2. 覆盖包级 JSON
    3. \n
  3. 启动算法助手
    4. \n
  4. 用 Provider 回读校验
    5. \n
\n

命令顺序如下：

\n
adb shell am force-stop com.junge.algorithmAidePro\nadb push com.example.app.json /data/local/tmp/com.example.app.json\nadb shell su -c 'cp /data/local/tmp/com.example.app.json /sdcard/Android/data/com.junge.algorithmAidePro/files/config/com.example.app.json'\nadb shell monkey -p com.junge.algorithmAidePro -c android.intent.category.LAUNCHER 1\nadb shell content query --uri content://algorithmAidePro/com.example.app --projection config\n
\n

4. 自定义 Hook 导出：已经能看清原生 DSL 的轮廓

\n

这次顺手把“算法助手里手工快速添加的自定义 hook 方法”也导出看了一眼。\n以 com.example.app 为例，设备上能看到两份同内容文件：

\n\n
    \n
  1. config/<pkg>.json 是当前生效配置
    2. \n
  2. exportConfig/<pkg>.json 是导出快照
    3. \n
  3. 导出文件本身就是算法助手当前认可的原生配置语法，不需要先自己猜 schema
    4. \n
\n

com.example.app 当前导出的核心内容大致如下：

\n
{\n  "enableScript": "bezierzhixian.js",\n  "hookList": [\n    {\n      "argsValues": [],\n      "className": "com.example.app.DemoTarget",\n      "constructor": true,\n      "description": "来自快速添加的Hook",\n      "enable": true,\n      "intercept": false,\n      "methodName": "<init>",\n      "parameterSign": "",\n      "printLog": true,\n      "results": ""\n    },\n    {\n      "argsValues": [],\n      "className": "com.example.app.DemoTarget",\n      "constructor": false,\n      "description": "来自快速添加的Hook",\n      "enable": true,\n      "intercept": false,\n      "methodName": "a",\n      "parameterSign": "Landroid/content/Context;",\n      "printLog": true,\n      "results": ""\n    }\n  ]\n}\n
\n

结构 1：自定义 Hook 不只是一个方法名列表

\n

每条 hookList 至少包含：

\n\n

结构 2：参数签名不是 Java 写法, 而是描述符写法

\n

例如：

\n\n

这类写法更接近 JNI / Smali 描述符，不是 Java 源码签名。

\n

结构 3：构造函数是单独编码的

\n

这次导出里，构造函数同时具备两个特征：

\n\n

后面如果要抽 DSL，constructor 和 <init> 最好别让调用方重复写。

\n

结构 4：enableScript 说明脚本和 hookList 可以并存

\n

这份 JSON 不只是 hookList，还包含：

\n
"enableScript": "bezierzhixian.js"\n
\n

并且这次设备上也确实找到了对应脚本文件。

\n

也就是说，结构化 Hook 和额外脚本本来就能并存。

\n

5. Frida 自动化：上层应抽象成统一 Hook DSL

\n

后面不应该只盯着“把算法助手 JSON 原样搬来搬去”，而应该往更高一层抽象：

\n
    \n
  1. 上层统一描述“我要观察哪个类/哪个方法/是否拦截/是否替换参数/是否挂额外脚本”
    2. \n
  2. 中间层根据目标后端，分别编译成：\n
    3. \n
  3. 底层再负责把产物落到：\n
    4. \n
\n\n

这三种东西后面完全可以统一进一个更高阶的 Hook DSL.

\n

6. Frida 实机验证：这轮踩过的 5 个坑

\n

坑 1：不要把 enableScript 误当成脚本内容落点

\n

实测里先改了：

\n\n

然后重启算法助手去验证。\n这个动作本身不算错, 但它只能证明 "脚本名选择生效" , 不能证明 "运行时读到的是这份外部脚本内容".

\n

原因是：

\n\n

坑 2：不要默认 su -c 一定已经切到 root

\n

这台设备上一个很隐蔽的问题是：

\n\n

有时候实际上仍在 shell 身份跑。

\n

直到显式改成：

\n
adb shell 'su 0 sh -c "...'" \n
\n

才拿到 uid=0(root)，并成功覆盖 /data/system/junge/com.example.app/frida/bezierzhixian.js。

\n

否则很容易误以为“目录有缓存”或者“文件不可写”，实际只是 root 没真的切成功。

\n

坑 3：先验证“脚本确实被执行”, 再纠结 Hook 点

\n

后面直接改了真实执行脚本之后，com.example.app 对应目录下的：

\n
/sdcard/Android/media/com.example.app/database/frida.log\n
\n

已经能看到我们主动写入的：

\n
[smoke-probe] script loaded pid=...\n
\n\n

这之后如果 onCreate、onResume、showMessage 这类 hook 没看到，不应再回头怀疑“脚本没生效”，而应该优先怀疑：

\n\n

后面要解决的就不是“脚本存哪”, 而是“选什么 hook 点才一定会触发”。

\n

坑 4：这轮最终成立的最短路径

\n

对现有算法助手而言，当前更可靠的 Frida 改脚本闭环是：

\n
    \n
  1. force-stop com.junge.algorithmAidePro
    2. \n
  2. 直接改 /data/system/junge/<pkg>/frida/<script>.js
    3. \n
  3. 启动算法助手
    4. \n
  4. 等待几秒，给它完成注入准备时间
    5. \n
  5. 启动目标 App
    6. \n
  6. 先看 /sdcard/Android/media/<pkg>/database/frida.log
    7. \n
  7. 确认脚本已执行后，再迭代 hook 点
    8. \n
\n

这条链已经够短, 也适合后面继续做 CLI/MCP.

\n

坑 5：onResume 不是不能用, 前提是 Hook 点要选得更硬, 时序也要对

\n

前面一度会怀疑：

\n\n

单独盯某个 Activity 自己声明的方法，确实可能踩到两个问题：

\n
    \n
  1. 方法本身不是目标类直接声明
    2. \n
  2. 算法助手注入完成时，目标方法已经跑过去了
    3. \n
\n

这轮后面换了个更稳的 smoke hook：

\n\n

然后按下面时序跑：

\n
    \n
  1. 先启动算法助手
    2. \n
  2. 等几秒
    3. \n
  3. 再启动 com.example.app
    4. \n
\n

最后 frida.log 里就稳定拿到了：

\n\n

的 onResume 日志。

\n

现在在 algorithmaide-mcp 里，Frida 这条链已经额外做了一层受控适配：脚本写入时统一预置 __aaLog / __aaLogHit 结构化 logger，并强制要求脚本按契约打点。读取侧则按真机实际格式解包 frida.log 外层 {"type":"log","payload":"..."} envelope，再回收到统一查询视图里。

\n
    \n
  1. smoke hook 应优先选系统层、一定存在、且偏晚触发的方法
    2. \n
  2. 算法助手先启动并等待几秒，这个时序在实机上确实会影响是否能稳定 hook 上
    3. \n
\n

7. 目标再往前推一步：它已经在逼近 Java 层动态分析逆向

\n

上面这套东西如果再往前推一步, 已经是在做一个可重复迭代的动态分析闭环：

\n
    \n
  1. 先从人工经验或静态分析里拿到候选类、候选方法、疑似参数点
    2. \n
  2. 自动生成算法助手原生 hook、附加脚本或 Frida 脚本
    3. \n
  3. 跑一轮目标流程
    4. \n
  4. 把运行日志抽出来
    5. \n
  5. 统一格式化成结构化事件
    6. \n
  6. 再根据日志决定下一轮该 hook 什么、该拦截什么、该追加什么脚本
    7. \n
  7. 更新配置继续重跑
    8. \n
\n

这里核心在于“日志格式统一”。

\n

因为不管接的是：

\n\n

最后都不能停留在“原始文本打印”这一层。\n更合适的是把它们都收敛成统一事件结构，例如：

\n\n

8. 为什么它天然应该和 jadx-ai-mcp 协同

\n

如果只靠动态侧自己盲打，效率会很差。\n所以它和 jadx-ai-mcp 很适合协同：

\n
    \n
  1. jadx-ai-mcp 提供静态分析结果\n
    2. \n
  2. 动态 Hook MCP 根据这些静态线索生成一轮最小 hook/script 配置
    3. \n
  3. 运行后把日志结构化
    4. \n
  4. 再把结构化结果回给上层分析，继续收敛候选点
    5. \n
\n\n

五、工程化落地：构建 algorithmaide-mcp

\n

有了这些底层 API, 接下来就是把它们封装成大模型能直接调用的 MCP Tool. \nalgorithmaide-mcp 的架构被有意设计为分层结构

\n

\"架构图\"

\n

我们把这些底层动作, 例如包级 JSON 写入, AppSwitch 同步校验, LSPosed scope CLI 接管, 封装成了类似 apply_algorithm_aide_config 这样的高级工具.

\n

现在, 你只需要对 Cursor 说一句: "帮我用算法助手 Hook com.example.app, 开启网络抓包和加解密打印", AI 就会自动调用 MCP, 在真机上完成所有的配置、强杀应用、重启并抓取日志.

\n

当然, 写 SKILL.md 时候加上 "不确定的时候, 先用 jadx-ai-mcp 自己分析下" 会更好.

\n

项目开源地址：\nalgorithmaide-mcp

\n", "url": "https://vw2x.vercel.app/blog/260314_algorithm-mcp", "title": "算法助手 MCP: 从 GUI 到 API 的思考", "summary": "探索如何将面向人的逆向 GUI 工具逐步剥离成 agent 向的 API 与 CLI.", "date_modified": "2026-03-14T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/en/blog/20250125_beam-cross-device-copy-cli", "content_html": "

Background

\n

When I work on two computers and want to move copied text, configs, commands, or snippets to the other machine, the UI flow is always tedious, like using WeChat, DingTalk, or AirDrop.

\n

I also do not like installing clients. localsend still needs the same LAN, and I am used to my current input method setup, so I do not want to switch to something like WeChat Input Method.

\n

Web clipboards were much faster, but I still had to open the same URL, paste, save, and exit. And those sites usually transmit in plain text, so anyone who knows the URL can see the content.

\n

So I wrapped a simple command-line tool: two commands for cross-device copy and paste, with optional encrypted transfer.

\n
# On device A\n# Copy clipboard contents\nbm c\n# Or copy a specific string\n# bm c "hello world"\n\n# On device B\nbm p\n
\n

That is all. No pairing, no shared LAN, and no tedious UI flow. As long as the devices can reach the internet, it works.

\n

Key Features

\n

Low memory cost - only two commands to remember: bm c copies and bm p pastes. No complex configuration, no learning curve.

\n

Cross-platform - works directly in Mac, Linux, and Windows terminals; on mobile, just open the URL in a browser.

\n

Encrypted by default - all content is compressed and encrypted before upload, so the server only sees gibberish. Custom passwords and private deployment are supported.

\n

Ready to use - install with pip install beam-clipboard and start using it right away. First run will guide you through setting a personal key.

\n

Use Cases

\n

Sync between multiple computers
Copy a snippet while coding, switch to another machine, and paste immediately. Transferring a token or a config file becomes a second-level operation.

\n

Computer-to-phone transfer
Run bm c --plain "content" on your computer, then open your personal URL in a phone browser to see it. Type text in the phone web page, and bm p on the computer can fetch it.

\n

Temporary text relay
Faster than WeChat File Transfer and simpler than emailing yourself. Good for commands, code snippets, and temporary notes.

\n

Technical Highlights

\n\n

One-Line Summary

\n

Beam makes cross-device copy and paste as simple as local copy and paste.

\n

If you are also tired of all the friction involved in moving text between devices, give Beam a try.

\n

Support

\n

Beam is still mainly something I use myself, and the features are evolving from my own needs. If you think it is useful, feel free to give it a star on GitHub ⭐️

\n

Issues and PRs are also welcome if you have ideas or needs. More feedback and participation will make the tool better.

\n
\n

Install: pip install 'beam-clipboard[clipboard]'

\n

More usage: https://github.com/vwww-droid/Beam

\n", "url": "https://vw2x.vercel.app/en/blog/20250125_beam-cross-device-copy-cli", "title": "Beam: A Clean CLI for Cross-Device Copy and Paste", "summary": "Two commands for cross-device copy and paste, with optional encrypted transfer.", "date_modified": "2026-01-25T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } }, { "id": "https://vw2x.vercel.app/blog/20250125_beam-intro", "content_html": "

背景

\n

两台电脑开发, 想复制文本传个配置,命令或文本到另一台电脑上时, 都涉及比较繁琐的 UI 操作, 如微信/钉钉/AirDrop这种

\n

个人习惯也不喜欢装客户端, localsend 这种还需要同个局域网, 微信输入法这种我百度输入法各种配置习惯了也懒得换

\n

后面用网页粘贴板快了很多, 但还是要打开同一个网址, 输入保存退出, 但这些网站都是明文传输, 知道网址就能看见内容

\n

就封装了个简单命令行工具, 两个命令搞定跨设备复制粘贴, 而且可选解密传输

\n
# 在设备 A\n# 复制剪切板\nbm c\n# 或复制指定文字\n# bm c "hello world"\n\n# 在设备 B  \nbm p\n
\n

就这么简单. 不需要配对, 不需要同一局域网, 也没有繁琐的 UI 操作. 只要能联网就行.

\n

核心特性

\n

记忆成本低 - 只需记住两个命令: bm c 复制, bm p 粘贴. 没有复杂的配置, 没有学习成本.

\n

跨平台 - Mac, Linux, Windows 命令行直接用; 手机没命令行就用浏览器打开网址.

\n

默认加密 - 所有内容自动压缩加密后再上传, 服务器只能看到乱码. 支持自定义密码或私有部署.

\n

开箱即用 - pip install beam-clipboard 装完直接用, 首次使用会自动引导设置个人 key.

\n

使用场景

\n

多台电脑间同步
写代码时复制个 snippet, 切到另一台机器直接粘贴; 传个 token, 传个配置文件内容, 都是秒级操作.

\n

电脑手机互传
电脑上 bm c --plain "内容", 手机浏览器访问你的专属网址就能看到; 手机网页输入文本, 电脑 bm p 就能获取.

\n

临时文本中转
比微信文件助手更快, 比邮件发给自己更简洁. 适合传命令、代码片段、临时笔记等.

\n

技术亮点

\n\n

一句话总结

\n

Beam 让跨设备复制粘贴, 和本地复制粘贴一样简单.

\n

如果你也厌倦了在设备间传文本的各种繁琐操作, 试试 Beam 吧.

\n

求个支持

\n

Beam 目前主要是我个人在使用, 迭代的功能也都是根据自己的需求来做的. 如果你觉得这个工具还不错, 欢迎去 GitHub 给个 Star ⭐️

\n

也很欢迎你提 Issue 说说你的想法和需求, 或者提 PR 一起完善它. 有更多人的反馈和参与, 才能让工具变得更好用.

\n
\n

安装命令: pip install 'beam-clipboard[clipboard]'

\n

更多使用方式: https://github.com/vwww-droid/Beam

\n", "url": "https://vw2x.vercel.app/blog/20250125_beam-intro", "title": "Beam: 优雅的跨设备复制命令行方案", "summary": "两个命令搞定跨设备复制粘贴, 而且可选加密传输.", "date_modified": "2026-01-25T00:00:00.000Z", "author": { "name": "vw2x", "url": "https://vw2x.vercel.app" } } ] }