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, 代码生成, 开发工具, 日志审计, 渗透测试工具, 逆向分析