waveriderai/cli-type-foundry
GitHub: waveriderai/cli-type-foundry
Type Foundry 通过三阶段诊断式分析从封闭应用的制品中重构出 OpenAPI 规范和可选的 CLI,解决无 API 文档应用难以互操作的难题。
Stars: 0 | Forks: 0
# Type Foundry
**印刷机在印刷前需要活字。这就是用来铸造活字的工具。**
[Printing Press](https://github.com/mvanhorn/cli-printing-press) 能将 API 规范转换为出色的 CLI。但它需要一个规范。当目标是封闭的应用程序时——没有公开的 API,没有 OpenAPI 文档,也没有像样的文档——就无从下手了。
Type Foundry 从制品本身创建母版。放入一个 APK、IPA、EXE、DMG 或流量抓包,它就能生成一份功能规范、一份重构的 OpenAPI 文档,以及——如果你需要的话——一个 CLI。
```
punch → strike → matrix → cast → press
artifact extract model spec CLI
```
## 真正重要的部分
提取只是简单的一半。困难的一半在于**研究过程往往存在其自身难以察觉的局限性**,因此一次看似详尽的分析通常也会遗漏产品的大部分内容。
Type Foundry 采用三阶段方法,并在阶段之间进行强制性的自我诊断:
| 阶段 | 提问 | 发现 |
|---|---|---|
| **阶段 1 —— 表面** | 明显的特征是什么? | 一份具体但错误的第一版草稿 |
| **诊断** | *为什么之前的分析很肤浅?* | 来源层级、结构性偏差、粒度偏差 |
| **阶段 2 —— 纠正** | 结构隐藏了什么? | 对象之间的关系、功能的参数 |
| **诊断** | *前两个阶段都未能提出什么问题?* | 通常是:除了“它能做什么”之外,什么都没问 |
| **阶段 3 —— 逆向** | 它在哪里失败? | 供应商声明的限制、用户痛点、权宜之计、竞争对手的空白 |
诊断步骤就是核心方法。带有中间诊断的两个阶段,胜过没有诊断的五个阶段。如果你跳过这一步,`foundry proof` 在诊断环节的得分将为零,而且根据设计,单次运行无法通过验证。
这源于一次真实的拆解分析:阶段 1 找到了约 120 个功能,阶段 2 又找到了约 80 个(几乎全部是关系和参数——正是诊断所预测的),而阶段 3 找到了改变构建方向的一个战略性事实:每一个用户投诉都伴随着“但没有其他产品能做到*这点*”,这意味着一个单一的功能就是其全部的护城河。
## 安装
```
curl -fsSL https://raw.githubusercontent.com/waveriderai/cli-type-foundry/main/scripts/install.sh | bash
```
或者从源码安装:
```
git clone https://github.com/waveriderai/cli-type-foundry.git
cd cli-type-foundry && make install
```
然后从 `plugin/`(或发布的 `.plugin` 文件)安装 Cowork/Claude Code 插件以获取相关技能。
**可选的外部工具。** `foundry doctor` 会报告哪些工具可用。
```
brew install jadx apktool p7zip wireshark # macOS
```
`jadx` 最重要——它可以将 Android DEX 反编译为可读的 Java 代码。其他所有工具都有备选方案。
## 使用
```
# 0. Inventory 和同意。在你批准之前,不会打开任何内容。
foundry intake --target "Acme" app.apk capture.har
foundry intake --target "Acme" --approve --attest "downloaded from Play Store; own account" app.apk capture.har
# 1. 需要流量?获取适用于你 platform 的 playbook。
foundry capture ios # also: android, desktop, web
# 2. 标记每个 artifact,并用其 lens pass 进行 strike。
foundry strike --pass 1 app.apk
foundry strike --pass 1 capture.har
# 3. 编写 manuscript/diagnoses.json,然后使用修正后的 lens 再次 strike。
foundry strike --pass 2 app.apk
# 4. 合并。报告每个 pass 的贡献。
foundry matrix --target "Acme"
# 5. 对其评分。低于 70 分意味着此次 run 尚未得出其结论。
foundry proof
# 6. Cast spec。默认情况下仅包含 spec。
foundry cast
# 7. 运行 CLI —— 独立运行,随时均可。
foundry specs # find specs already on disk
foundry press --spec cast/openapi.json
```
**铸造和压制是刻意分开的。** 铸造规范,阅读它,然后在之后再压制 CLI——包括在另一个会话中,使用由本工具或任何其他工具生成的规范。`foundry specs` 用于查找现有规范,以便恢复运行时无需重新创建任何内容。
## 生成内容
```
manuscript/
intake.json approved inventory + attestation
diagnoses.json the blind-spot analyses (you write these)
strikes/ one file per artifact per pass
matrix.json consolidated endpoints, features, relations, gaps
cast/
openapi.json reconstructed spec, with uncertainty marked
-cli/ generated CLI, only if you pressed one
```
规范会标记其自身的不确定性。`x-foundry-unverified` 表示 HTTP 方法是从二进制文件中推断出来的,从未在网络中实际观察到——绝不能将这些作为事实呈现。`x-foundry-observations` 用于计算实际观察到的 endpoint 次数。
## 凭据永不落地于磁盘
`foundry strike` 在读取时会进行脱敏。Header 和 body 的*值*将被完全丢弃——只有名称和推断出的类型会被保留。任何形似机密的内容(JWT、bearer token、API key、cookie、私钥、卡号)都会被替换为稳定的、不可逆的占位符,因此重复出现的内容仍可保持相关性,而真实值不会存在于任何地方。
你的原始 HAR 依然是机密。但手稿(生成的文档)不是,你可以在之后删除 HAR 文件。
## 范围
- 分析你合法获取的制品。仅在你拥有的设备上捕获你控制的账户的流量。
- **Pinning 和 DRM 会被记录为发现结果,绝不会去破解它们。** 如果一个应用程序使用了证书绑定(Pinning),那是关于该产品的一个事实——记录下哪些主机使用了绑定并继续下一步即可。
- 重构的规范不是官方接口。每个制品都会声明这一点,且不暗示任何供应商的认可。
- 互操作性和竞争性研究才是目的。克隆受保护的表达,或构建滥用服务的内容,则不在此列。
## 为什么叫 "foundry"(铸造厂)
在印刷领域,冲头被打入软金属以制成母版(matrix);母版是铸造活字的模具。你提取现存事物的印记,是为了创造新的事物。
这正是本工具所做的,也是印刷机(Printing Press)运行前必须发生的步骤。
## 许可证
MIT
标签:API重构, EVTX分析, OpenAPI, SOC Prime, 代码生成, 开发工具, 日志审计, 渗透测试工具, 逆向分析