信息收集-APP应用&产权渠道&服务资产&通讯抓包&静态提取&动态调试&测试范围

本文最后更新于30 天前，其中的信息可能已经过时，如有错误请发送邮件到184874483@qq.com

信息收集-APP应用-公开信息-知识产权&开发者定位

一、认知基础重构

一、模块概念解释

本模块重塑对数字世界中“公开标识”与“责任主体”之间关联的认知。信息收集中，面对的不是抽象代码或服务，而是特定组织或个人开发运营的数字资产。核心问题：如何理解并建立从一串字符（如域名、证书序列号）到法律或商业实体（如公司、开发者）之间的逻辑桥梁。 需摒弃将公开信息视为孤立数据点的观念，将其视为指向责任主体的线索集合。

二、技术原理说明

底层逻辑基于数字世界的标识注册与认证体系。当组织或个人部署面向公众的应用服务时，需通过技术和管理手段确立其合法性与可访问性。例如：

域名系统（DNS）：将易于记忆的名称（如example.com）与IP地址绑定，其注册信息（WHOIS）最初设计用于联系责任方。
安全套接层/传输层安全（SSL/TLS）证书：将域名与组织身份信息（如证书中的Subject字段）通过证书颁发机构（CA）的验证绑定，确保证书持有者为对应域名的控制者。
代码签名（Code Signing）：为确保软件来源可信且未被篡改，开发者使用代码签名证书对APP签名，证书中包含开发者身份信息。
这些机制在设计之初即包含身份验证与公开可查原则，为信息溯源提供技术基础。

三、在系统中的位置

本模块为信息收集流程的认知起点，位于所有具体操作之前。它为后续“问题与目标明确”、“关键结构拆解”等模块提供理论基础和思维框架。缺乏此认知，后续操作可能沦为盲目搜索，无法有效解读所获信息含义，也无法将碎片化标识关联成完整主体画像。这是从“看见数据”到“理解信息”的思维转换。

四、可执行命令或查询方式

概念验证：查看网站证书信息
- 目标：https://www.hackthissite.org
- 操作：使用浏览器访问该站点，点击地址栏“锁”图标 → “连接是安全的” → “证书有效”。
- 观察：在证书详情中，查找“颁发给”或“使用者”字段，可见与运营实体相关的信息（可能显示为域名或组织名）。演示数字证书如何将域名与声明的身份关联。

五、工具对比表

工具/资源	适用场景	优点	局限
浏览器开发者工具 (F12)	快速检查当前站点证书、HTTP头、源代码注释等	无需安装，即开即用，直观查看实时数据	信息零散，难以批量或历史查询
在线SSL证书查询工具 (如crt.sh)	深入分析特定域名的SSL证书链，查看完整证书详情	提供证书序列号、签名算法、颁发者等完整字段	依赖第三方服务，可能存在查询频率限制
WHOIS 命令行/在线查询	查询域名注册人、注册商、联系方式等原始注册信息	直接获取域名所有权核心注册数据	隐私保护可能隐藏大部分个人信息，仅显示代理信息

六、标准操作步骤

选择目标：以公开测试网站 http://testphp.vulnweb.com 为例。
访问目标并定位：在浏览器中打开该网站。
查找公开标识：点击地址栏左侧“锁”图标，查看站点证书信息。注意：HTTP站点可能无证书或证书无效，此现象本身即为信息。再右键点击页面空白处，选择“查看页面源代码”。
建立关联意识：在源代码中搜索“Copyright”、“author”、“powered by”等关键词。可能发现类似  的注释。
初步认知映射：将找到的“Acunetix”标识与当前访问网站 testphp.vulnweb.com 关联，初步形成“该网站可能由Acunetix创建或用于测试其产品”的认知。

七、如何验证结果真实性

验证逻辑：单一标识指向性可能较弱（如“Powered by”可能声明框架而非责任主体），需多个不同来源的标识相互印证。
输出判断依据：若在页面源代码中发现“Acunetix”注释，同时在HTTP响应头中发现“X-Powered-By: Acunetix”字段，则两个独立来源标识共同指向“Acunetix”，其作为潜在责任主体的可能性显著提高。判断依据是标识的一致性和多源性。

八、常见错误与排查方式

错误：将托管服务商误认为责任主体。例如，网站页面底部的“托管于XX云”标识，仅代表基础设施提供商，而非应用开发者。
- 排查：建立“开发层”与“基础设施层”区分意识。与代码、版权、功能直接相关的标识（如作者meta标签、代码签名）更可能指向开发者；服务器信息、IP归属等则指向托管方。
错误：忽略过期或被隐私保护的标识信息。
- 排查：认识到信息是动态的。域名WHOIS被隐私保护本身即为信息点，表明主体有隐藏意图。过期证书信息可能指向不再使用的主体，但仍具参考价值。

九、合规边界说明

网络安全视角：本模块建立对公开信息的正确理解，是网络防御、资产盘点和合规审计的基础工作。
风险：误读信息可能导致错误归因，将无关方认定为责任主体。
局限：并非所有公开标识都能100%指向真实世界责任主体，主体可能使用虚假信息注册。
缓解措施：始终基于多源信息交叉验证，不依赖单一标识做出最终判断。
决策指南：何时必须使用？ 当需对未知APP或网站进行初步风险评估或背景调查时，需首先建立此关联认知。何时替代？ 无需替代，这是所有后续工作的思想基础。

十、本模块阶段性小结

本模块完成了认知重构，明确了公开标识作为线索的价值及其原理。接下来，我们将基于此认知，明确具体溯源任务，将抽象意图转化为可执行的情报收集问题。

图：公开标识与责任主体关联概念图

二、问题与目标明确

一、模块概念解释

基于上一模块“公开标识指向责任主体”的认知，本模块将其转化为清晰、可执行的情报收集问题。核心是明确“到底要找什么？”，即从宽泛的“信息收集”中精确定义溯源APP责任主体的目标、范围和成功标准，避免在信息海洋中迷失。

二、技术原理说明

目标明确化的底层逻辑基于“溯源树”模型。任何APP均可视为一棵倒置树：

树干：APP本身（名称、包名、图标）。
树枝：公开标识，如官方网站域名、开发者账号名称、代码签名证书序列号、客服邮箱域名、版权声明中的公司名、社交媒体账号等。
树根：最终的法律或商业责任主体。
本模块将“找到树根”的大目标分解为“沿每根树枝向下挖掘”的子任务。分解基于信息间的逻辑关联性：域名（树枝）需由实体（树根）注册；代码签名证书（树枝）需由实体（树根）申请。技术设计的耦合性决定了任务分解的可行性。

三、在系统中的位置

本模块承上启下，承接“认知基础重构”建立的思维模式，并将其具体化、任务化。同时，为后续“关键结构拆解”和“方法模型建立”提供明确靶向——接下来拆解的正是这些“树枝”的结构，要建立的方法正是挖掘这些“树枝”并关联到“树根”的路径。

四、可执行命令或查询方式

定义目标应用：选取测试应用 OWASP Juice Shop。
- 目标：明确核心任务为“找出开发和维护OWASP Juice Shop的责任主体”。
拆解初步线索：
- 从应用本身：应用名称“OWASP Juice Shop”，图标，启动画面。
- 从应用来源：开源项目代码仓库地址 https://github.com/juice-shop/juice-shop。

五、工具对比表

工具/资源	适用场景	优点	局限
任务看板 (如 Trello, Notion)	组织和跟踪多个溯源任务，记录线索和发现	可视化任务进度，便于团队协作和信息整理	本身不产生信息，仅是管理工具
思维导图软件 (如 XMind)	头脑风暴阶段，可视化“溯源树”和线索关联	直观展示线索层级和分支，帮助理清思路	信息需手动输入和更新
简单的文本文件/电子表格	个人小规模信息收集，记录目标和已发现线索	轻量级，上手快，无需复杂配置	难以处理大量复杂关联信息，不适合团队协作

六、标准操作步骤

确定初始目标：明确要溯源的APP对象。例如：“了解 OWASP Juice Shop 的开发者背景。”
列出所有可触及的公开标识：打开APP（或访问其官网），记录可见标识：应用名称（OWASP Juice Shop）、官网URL（https://owasp.org/www-project-juice-shop/）、版权信息（若存在）、代码仓库（GitHub）等。
将每个标识转化为子问题：
- 标识：官网域名 owasp.org → 子问题：谁注册了 owasp.org？
- 标识：代码托管于 GitHub → 子问题：juice-shop 组织或用户背景？
- 标识：应用名称含 OWASP → 子问题：OWASP 是什么组织？
定义成功标准：成功并非找到名字，而是构建包含以下信息的实体档案：主体名称、主体类型（公司/非营利/个人）、主体官方描述、主体主要业务/使命、主体联系方式（如官网、公开邮箱）。

七、如何验证结果真实性

验证逻辑：任务明确体现在子问题间是否存在逻辑闭环。若所有子问题得到解答，且答案共同指向逻辑一致的主体，则初始任务完成。
输出判断依据：例如，解答“owasp.org注册者”为“OWASP Foundation, Inc.”；解答“GitHub组织背景”为“The OWASP Foundation”；解答“OWASP是什么”为“开源应用安全基金会”。三个独立子问题答案均指向“OWASP Foundation”，形成强关联，证明溯源任务成功。

八、常见错误与排查方式

错误：目标定义过于宽泛，如“收集这个APP的所有信息”，导致后续操作无重点，收集大量无关数据。
- 排查：用“5W1H”方法细化：Who（谁开发的？）、What（还开发了什么？）、Where（他们在哪里？）、When（何时开始？）、Why（目的？）。
错误：成功标准不明确，导致收集到部分信息即认为任务完成，未能形成完整主体画像。
- 排查：执行操作前，先写下预期输出格式和必含字段，如[主体名称, 主体官网, 主体简介]。

九、合规边界说明

网络安全视角：明确的目标有助于聚焦必要信息，避免过度收集和侵犯个人隐私。
风险：将合法、公开的标识溯源任务与恶意人肉搜索混淆，可能引发法律和道德风险。
局限：某些主体可能刻意隐藏关联性，使得定义出的子问题无法解答。
缓解措施：严格遵守目标范围，仅收集与责任主体直接相关的公开信息，不涉及个人隐私。若线索指向个人开发者，应更加审慎，仅收集其用于开发工作的公开身份信息。
决策指南：何时必须使用？ 在开始任何信息收集工作之前，必须首先完成目标明确化。何时替代？ 无法替代，目标是行动的指南针。

十、本模块阶段性小结

本模块将抽象的信息收集意图转化为由具体子问题构成、并有明确成功标准的情报收集任务，明确了“要找什么”。接下来，我们将深入分析这些公开标识的构建方式，为提取有价值信息打下基础。

图：溯源树模型 – 从APP到责任主体的线索分解

三、关键结构拆解

一、模块概念解释

本模块对“问题与目标明确”阶段识别出的公开标识（如域名、证书、代码签名）进行内部结构分析，解决“线索本身如何构成”的问题。通过拆解，理解标识各组成部分携带的信息及如何利用。例如，域名不仅是一个字符串，其顶级域、二级域、子域蕴含不同含义和关联。

二、技术原理说明

每个公开标识遵循特定语法规则和命名规范，由相应技术标准或注册机构定义。

域名结构（DNS）：遵循点分层级结构，从右至左依次为根域、顶级域（TLD，如.org）、二级域（owasp）、子域（www或juice-shop）。层级结构反映管理权和所有权归属。拥有owasp.org的实体可自由创建其下任意子域。
数字证书结构（X.509）：遵循ASN.1标准定义的复杂结构。关键字段包括：Subject（证书持有者身份）、Issuer（证书颁发者）、Validity（有效期）、Subject Alternative Names（SAN，证书保护的所有域名）。这些字段共同定义证书的用途和归属。
代码签名结构：嵌入可执行文件中的数字签名块，包含证书信息、时间戳、文件哈希值。验证签名即确认文件自签名后未被修改，且签名证书由可信CA颁发。
理解这些结构，如同拿到地图图例，可精准从标识的特定字段中提取有价值情报。

三、在系统中的位置

本模块是连接“目标明确”和“方法建立”的桥梁。明确了要找的“树枝”（标识）后，本模块剖析这些“树枝”的内部纹理（结构）。理解纹理才知道从何下手（提取哪个字段），以及纹理如何指引走向下一个关联点。为后续“方法模型建立”中“如何关联”提供技术基础。

四、可执行命令或查询方式

目标：对 https://bwapp.hakhub.net 的证书进行结构拆解。
命令（使用 OpenSSL 命令行）：
bash openssl s_client -connect bwapp.hakhub.net:443 -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout
（注：命令中使用了-showcerts显示完整证书链，并修正了原始目标拼写。）
输出解读：命令显示证书明文结构。重点关注：
- Subject: CN = bwapp.hakhub.net：证书直接持有者，此处为域名。
- Issuer: C = US, O = Let's Encrypt, CN = R3：证书由Let’s Encrypt颁发，为免费CA。
- X509v3 Subject Alternative Name: DNS:bwapp.hakhub.net：确认该证书仅用于此域名。

五、工具对比表

工具/资源	适用场景	优点	局限
OpenSSL 命令行	深入、自动化地获取和分析证书完整结构	功能强大，可脚本化，获取最底层证书详情	命令行操作，学习曲线较陡峭
浏览器开发者工具（安全/证书面板）	快速、图形化查看当前站点证书摘要信息	无需额外工具，信息展示友好直观	展示信息有限，无法导出或批量处理
在线 ASN.1 解析器	分析原始DER编码的证书或CRL（证书吊销列表）时	解析最底层二进制结构，用于高级分析	专业性过强，常规溯源任务中较少使用

六、标准操作步骤

选择线索：从上一模块子问题中选取一个，如 bwapp.hakhub.net 的域名。
获取其证书：使用浏览器访问 https://bwapp.hakhub.net，通过“锁”图标查看证书，或使用 OpenSSL 命令获取。
拆解 Subject 字段：查看证书的 Subject 字段，通常包含 CN（Common Name，通用名称）。若是OV（组织验证）或EV（扩展验证）证书，此处会包含组织的详细名称和地址。本例为DV（域名验证）证书，仅显示域名。
拆解 SAN 字段：查看 Subject Alternative Name 扩展字段，列出该证书可合法使用的所有域名，可揭示是否还有其他域名共用此证书。
拆解 Issuer 字段：查看 Issuer 字段，了解证书由哪家CA颁发，有时能提供线索，如某些公司习惯使用特定CA证书。
记录关键信息：记录 Subject CN, SANs, Issuer O, Validity 等信息。

七、如何验证结果真实性

验证逻辑：结构拆解的正确性可通过对比多个工具输出或与公开证书透明度（CT）日志交叉验证。
输出判断依据：例如，使用 OpenSSL 解析出的证书序列号，可在公开CT日志搜索引擎（如crt.sh）中查询。若查到完全相同记录，则证明拆解的证书信息真实准确。

八、常见错误与排查方式

错误：混淆证书中的 Subject 和 Issuer，将颁发者信息误认为持有者信息。
- 排查：牢记 Subject 是“谁”，Issuer 是“谁发给他的”，类比身份证和发证机关。
错误：只看了 CN 字段，忽略 SAN 字段，漏掉该证书保护的其他域名。
- 排查：查看证书时，务必检查扩展区域（Extensions），特别是 Subject Alternative Name，它是现代浏览器验证域名的标准字段。

九、合规边界说明

网络安全视角：解析公开证书结构，是进行资产发现、盘点自有证书、发现过期或错误配置证书的合法且必要手段。
风险：无直接风险，证书本身设计为公开可查。
局限：DV（域名验证）证书提供的责任主体信息极少，仅证明域名控制权，无法直接关联法律实体。
缓解措施：意识到证书类型局限性，当遇到DV证书时，需结合其他线索（如WHOIS、网页内容）定位主体。
决策指南：何时必须使用？ 目标使用HTTPS时，分析其证书结构是溯源责任主体的第一步。何时替代？ 目标仅为HTTP时，此方法失效，需转向WHOIS、HTTP头分析等方法。

十、本模块阶段性小结

本模块完成了对核心公开标识（以证书为例）的内部结构拆解，掌握了从结构化数据中提取精确信息片段的方法。接下来，我们将把这些片段组合成可复用的关联方法论，构建从点到面的关系网络。

图：X.509数字证书核心结构图

四、方法模型建立

一、模块概念解释

本模块构建一套基于逻辑关联的系统性方法框架，将上一模块从各公开标识拆解出的信息片段有机组合，最终指向统一责任主体。解决“如何从点到面构建关联网络”的问题，即建立标识与标识、标识与主体之间的多维关系模型。

二、技术原理说明

方法模型的核心是“关联图”理论。每个标识（域名、证书、邮箱、版权名）视为图中的一个节点，标识间的技术或逻辑关系视为连接节点的边。例如：

所有权关系：WHOIS记录中的注册人邮箱，连接“域名”节点和“邮箱地址”节点。
绑定关系：证书的Subject字段，连接“证书”节点和“域名/组织名”节点。
引用关系：页面源代码中的“Powered by”注释，连接“网站”节点和“技术框架/公司”节点。
共同出现关系：同一联系邮箱出现在两个不同域名的WHOIS记录中，则这两个域名节点通过该邮箱节点间接相连。
本模块的任务是主动发现并构建这些连接，形成扩展的关联网络，最终网络的核心节点即目标责任主体。

三、在系统中的位置

本模块是方法论的核心，位于“关键结构拆解”之后，“操作路径形成”之前。它提炼出通用思维框架，指导思考和行动。如果说“关键结构拆解”是学会辨认和处理原材料，那么“方法模型建立”就是掌握将这些原材料组合成成品的蓝图和工艺流程。

四、可执行命令或查询方式

目标：基于 testphp.vulnweb.com 和 bwapp.hakhub.net 两个目标，建立关联模型。
模型应用：
1. 节点A：域名 testphp.vulnweb.com。
2. 关联动作：查询其WHOIS信息（假设数据可见），得注册邮箱 contact@acunetix.com（示例邮箱，非真实）。
3. 节点B：邮箱 contact@acunetix.com。
4. 关联动作：搜索该邮箱，发现它与另一域名 www.acunetix.com 的WHOIS记录关联。
5. 构建关系：建立 testphp.vulnweb.com → contact@acunetix.com → www.acunetix.com 的关联路径。

五、工具对比表

工具/资源	适用场景	优点	局限
思维导图（如 XMind）	手动构建和可视化关联网络，适合分析和推理	灵活，直观展示线索间复杂关系，便于理清思路	手动操作，效率较低，不适合处理海量数据
关系图谱数据库（如 Neo4j）	处理大规模、结构化关联数据，进行自动化分析和挖掘	强大，可进行复杂查询，发现隐藏的多层关系	学习成本高，需数据导入和查询语言（Cypher）知识
电子表格（如 Excel）	记录和管理关联关系，进行简单排序和筛选	上手容易，适合管理中等规模关系列表	可视化能力弱，难以直观展现复杂网络

六、标准操作步骤

建立初始节点：以目标APP名称或官网域名作为关联网络第一个节点。
拓展第一层关联：对初始节点执行操作，提取关联信息。例如，对域名节点进行WHOIS查询和证书解析，将获得的注册人、注册邮箱、证书颁发者等作为新节点加入网络。
建立连接边：在初始节点和新节点之间画线，注明关系类型，如“WHOIS记录指向”、“证书Subject指向”。
以新节点为起点，迭代拓展：对新节点（如邮箱地址、组织名）进行反向搜索。例如，搜索该邮箱还出现在哪些域名的WHOIS记录中？该组织名还与哪些证书关联？
持续迭代直至收敛：重复步骤2-4。当每次迭代产生的新节点越来越少，且新节点指向共同核心实体（如同一个组织名或官网）时，关联网络逐渐收敛，核心责任主体浮现。

七、如何验证结果真实性

验证逻辑：模型有效性体现在其“预测”和“解释”能力。若模型构建的关联网络真实，则新增节点应能与其他已知信息相互印证，形成逻辑闭环。
输出判断依据：假设根据模型预测“某联系邮箱”背后应为“某家公司”。随后在该公司官网上找到此邮箱，或在LinkedIn上看到该公司员工职位信息与目标APP相关。这种外部印证即为验证模型真实性的有力证据。

八、常见错误与排查方式

错误：将“间接关联”当作“直接证据”。例如，A和B使用同一托管商，不代表A和B由同一主体开发。
- 排查：在模型中区分关系强度。WHOIS中相同注册邮箱是强关联；相同IP段或托管商是弱关联。始终优先追踪强关联线索。
错误：模型无限扩展，陷入信息海洋。例如，从邮箱追到注册人，再从注册人追到他名下的其他100个域名，偏离初始目标。
- 排查：时刻牢记初始目标。迭代时问：“这个新节点是否有助于更清晰定位最初APP的责任主体？”若否，则停止深入该分支。

九、合规边界说明

网络安全视角：此方法模型是威胁情报分析和供应链安全评估的标准实践。
风险：关联过程可能无意触及与目标无关的第三方个人或组织的信息。
局限：关联模型是概率性的，非100%确定。隐私保护、虚假注册信息等技术手段会切断或模糊关联路径。
缓解措施：严格限定在公开数据范围内进行关联。一旦发现关联路径指向与初始目标无关的个人信息，应立即停止并忽略该分支。
决策指南：何时必须使用？ 面对多个线索，需理清逻辑关系、构建统一主体画像时，必须采用此模型。何时替代？ 若目标信息直接明确（如官网“关于我们”页面），则无需复杂建模，可直接获取信息。

十、本模块阶段性小结

本模块构建了基于关联图理论的方法模型，将零散信息点编织成指向责任主体的关系网络，掌握了从“点”到“面”的思维框架。接下来，我们将这套模型转化为可按图索骥的具体操作流程。

图：关联图模型示例

五、操作路径形成

一、模块概念解释

本模块将“方法模型”转化为清晰、可重复、标准化的操作流程，解决“第一步做什么，第二步做什么，直到任务完成”的执行问题。这是一份面向实战的“工作手册”，确保执行者能系统完成从APP到责任主体的信息溯源，避免遗漏关键步骤。

二、技术原理说明

操作路径基于“工作流”设计原则。将溯源过程分解为一系列相互关联的阶段，每个阶段包含若干原子操作。阶段和操作按数据依赖关系和逻辑顺序排列，形成流水线。前一个操作的输出是后一个操作的输入。例如：

阶段一（静态采集） → 输出（应用名称、图标、官网链接）→ 输入给阶段二。
阶段二（域名溯源） → 输出（WHOIS信息、证书信息）→ 输入给阶段三。
阶段三（主体信息整合） → 输出（最终主体档案）。
这种流水线设计保证过程的系统性、高效性和可审计性。

三、在系统中的位置

本模块是方法论的具体实现层，位于“方法模型建立”之后，是信息收集流程的执行蓝图。它指导如何将头脑中的关联模型通过具体工具和命令落地到实际操作，是连接“知道怎么做”和“真正动手做”的桥梁。

四、可执行命令或查询方式

目标：以 http://testphp.vulnweb.com 为起点，形成操作路径。
路径示例 – 域名信息查询：
1. 命令:
  bash whois testphp.vulnweb.com
  目的: 获取域名注册信息。
2. 命令:
  bash openssl s_client -connect testphp.vulnweb.com:443 -showcerts 2>/dev/null | openssl x509 -text -noout | grep -E "Subject:|Issuer:|DNS:"
  目的: 尝试获取HTTPS证书信息（尽管可能失败，但需执行）。
路径示例 – 网站信息采集：
- 操作:
  bash curl -I http://testphp.vulnweb.com
- 目的: 获取HTTP响应头，查看 Server, X-Powered-By 等字段。

五、工具对比表

工具/资源	适用场景	优点	局限
Shell 脚本（Bash）	将一系列命令行操作自动化，实现一键式信息收集	高效，可重复，易于分享和标准化	需编写和调试脚本，有一定门槛
Python 脚本（使用 requests, whois 等库）	需要更复杂逻辑处理、数据解析和报告生成的场景	功能强大，灵活性高，可处理结构化数据	需编程知识，开发周期比Shell脚本长
Burp Suite（Repeater/Intruder）	手动分析Web应用时，作为辅助工具发送构造的HTTP请求	集成了众多Web测试功能，便于操作和重放请求	主要用于手动测试，不适合批量自动化

六、标准操作步骤

阶段一：静态信息采集（从APP本身）

获取应用标识：记录APP名称、包名（对Android，可从APK文件获取）、版本号。例如，OWASP Juice Shop包名可能为 com.example.juiceshop。
提取官方链接：从应用官方页面、设置或关于界面，提取其官方网站、隐私政策链接、客服邮箱等。记录为 [官网URL]。
记录版权信息：截屏或记录APP启动页、关于页面中的所有版权声明 © [年份] [公司名]。

阶段二：域名及网络资产溯源（针对官网）

域名 WHOIS 查询：对 [官网URL] 的根域名执行 whois 查询。记录注册人、注册组织、注册邮箱、注册商等信息。
域名证书查询：对 [官网URL] 执行证书获取命令，解析 Subject、Issuer、SAN 字段。记录所有关联域名。
DNS 记录查询：使用 dig 或 nslookup 查询 A、MX、TXT 记录。例如，MX 记录可能指向主体使用的邮件服务器提供商。

阶段三：应用内标识溯源（针对APP本身）

代码签名证书提取（如有可能）：若目标是APK或IPA文件，使用相应工具（如 keytool 或 jarsigner）提取其代码签名证书信息。记录证书中的 Issuer 和 Subject 字段。
资源文件分析：解压APP（如APK文件），在资源文件（如 AndroidManifest.xml, strings.xml）中搜索开发者邮箱、公司名、第三方服务API Key等，这些可能作为新的关联节点。

阶段四：信息整合与主体识别

交叉验证：将阶段二和阶段三收集到的所有组织名、邮箱、域名进行关联匹配。例如，WHOIS邮箱是否与代码签名证书中的组织名有逻辑关联？
形成主体档案：基于交叉验证后指向最集中的实体，撰写包含主体名称、类型、官网、简介、关联资产（域名列表）的最终报告。

七、如何验证结果真实性

验证逻辑：流程每一步应产生可观测、可记录的输出。最终结果的真实性取决于每一步操作的正确执行和多源信息的相互印证。
输出判断依据：最终“主体档案”中的主体名称不应仅来自一个孤立来源。例如，若主体名称既出现在官网“关于我们”页面，又出现在域名WHOIS注册信息中，还出现在应用版权声明里，则该主体名称真实性非常高。

八、常见错误与排查方式

错误：跳步。例如，未完成阶段二（域名溯源）直接进入阶段三（APP资源分析），可能导致对发现的线索（如第三方API域名）缺乏上下文理解。
- 排查：严格遵守流程顺序。若发现必须先做某步，应退回相应阶段。可制作Checklist，每完成一步打勾。
错误：命令使用错误导致信息遗漏。例如，whois 查询时未指定正确顶级域WHOIS服务器，导致返回信息不完整。
- 排查：执行关键命令前，先通过 man whois 或 --help 查看帮助，确认参数正确。对不确定的输出，可先用测试站点验证命令有效性。

九、合规边界说明

网络安全视角：标准化的操作流程是进行合规的内部资产审计、供应商风险评估的标准作业程序（SOP）。
风险：自动化脚本可能对目标服务器造成不必要的请求负载，甚至被误判为攻击。
局限：流程有效性依赖于公开信息的可用性和真实性。当目标主体采取严格信息隐藏措施时，流程可能无法得出确定结论。
缓解措施：在流程中，对所有命令执行设置合理延时（如 sleep）。确保查询频率在正常范围内，遵守 robots.txt 的精神。
决策指南：何时必须使用？ 当需对APP进行系统性背景调查，且要求结果可复现、可审计时，必须遵循标准操作路径。何时替代？ 对于临时、快速调研，可简化流程，只执行核心步骤。

十、本模块阶段性小结

本模块将抽象的方法模型转化为可执行、可重复的标准操作路径，提供了清晰的“作战地图”。接下来，我们将学习如何识别并规避执行过程中的法律和安全红线，确保所有操作在合规框架内进行。

图：APP责任主体溯源标准操作路径流程图

六、风险与边界控制

一、模块概念解释

本模块在执行信息收集操作过程中，识别并主动管理潜在的法律、道德和技术风险，解决“如何在合法合规前提下安全完成任务”的问题。这为之前的工作加上一道“安全阀”，确保所有操作处于网络安全工作的合理范畴内，不越界。

二、技术原理说明

风险与边界控制基于“最小权限”和“目的正当”原则。

最小权限原则：信息收集中，只获取完成任务所必需的信息，不进行漫无目的的“探索”或“扫描”。例如，通过公开API查询WHOIS信息，而非尝试对域名服务器进行暴力破解。
目的正当原则：操作目的是资产盘点、安全评估或供应链分析，而非攻击、破坏或人肉搜索。技术本身中性，使用意图和场景决定合规性。
技术限制：公开信息查询服务通常有频率限制（Rate Limit），并受其服务条款（ToS）约束。突破这些限制可能构成违约或非法访问。

三、在系统中的位置

本模块是整个流程的“护航者”，位于“操作路径形成”之后，并与所有前期模块并行存在。它不是流程终点，而是一个贯穿始终的约束框架。在执行任何一条命令、使用任何一个工具时，都需在本模块指导下进行。它为后续的“能力整合与输出”提供必须遵守的基线。

四、可执行命令或查询方式

风险识别示例：进行WHOIS查询时，应优先使用公开、官方的WHOIS服务器，而非某些提供“增强信息”的第三方聚合网站，因后者可能通过非正规渠道获取数据。
- 合规命令:
  bash whois example.com
  （使用系统默认WHOIS客户端，通常指向IANA指定服务器）
- 高风险替代: 使用未经授权、声称能“破解”隐私保护信息的API接口。

五、工具对比表

工具/资源	适用场景	优点	局限	风险控制考量
官方 WHOIS 客户端	标准域名注册信息查询	数据源权威，直接连接注册局或注册商WHOIS服务器	输出格式不统一，有时支持隐私保护	低风险：符合服务条款
公开的证书透明度日志（如 crt.sh）	查询某个域名所有已颁发的证书历史	数据公开透明，可发现隐藏资产	数据量大，需筛选	低风险：数据本身公开，查询行为符合服务条款
商业威胁情报平台	需要深度关联、历史数据、恶意家族分析等高级情报	数据丰富，关联性强，提供风险评分	成本高	中风险：使用前需签订合同，确保数据用途合规，不用于非授权目的

六、标准操作步骤

明确授权与目的：执行操作前，再次确认本次信息收集目的正当（如内部审计、授权渗透测试、公开研究），并确保拥有授权。
审视操作对象：确认目标是否在允许测试范围内。例如，只针对有合法授权的测试站点（如 juice-shop.herokuapp.com）或明确声明可用于学习的站点（如 bwapp.hakhub.net）。
选择合规工具和方法：优先使用官方、公开的API或客户端进行查询。避免使用任何声称可绕过限制、隐藏身份或获取非公开信息的工具。
控制操作频率和强度：执行批量或脚本化查询时，在命令间加入适当延时（如 sleep 2），模拟人工操作，避免对目标服务器或查询服务造成压力。
审查收集到的信息：对收集数据进行审查，若无意获取可能涉及个人隐私的信息（如个人电话、住址），应立即脱敏处理或删除，不作为最终报告内容。
安全存储和处置数据：将收集信息存储在受控环境中，任务完成后按数据安全策略归档或销毁。

七、如何验证结果真实性

验证逻辑：风险控制的有效性体现在操作过程平滑、无警告，且未收到查询服务提供商的任何违规通知。
输出判断依据：若执行命令后收到WHOIS服务器的 420 Enhance Your Calm 或类似限流错误，说明操作强度越界。反之，所有命令成功返回预期结果，且无警告或封禁，则证明操作处于安全边界内。

八、常见错误与排查方式

错误：认为“公开信息”就是“可以随意使用”的信息，忽略查询服务的服务条款（ToS）和网站的 robots.txt。
- 排查：养成使用新服务前阅读其服务条款或“关于”页面的习惯。对网站，可通过 curl 查看其 robots.txt（如 curl http://testphp.vulnweb.com/robots.txt）。
错误：在撰写报告时，将个人邮箱、电话等敏感信息原样输出，导致隐私泄露。
- 排查：最终输出前，进行一轮人工或自动脱敏审查。将 user@example.com 替换为 [邮箱地址]，将 +1-555-123-4567 替换为 [电话号码]。

九、合规边界说明

网络安全视角：严格的风险与边界控制，是区分专业网络安全人员与恶意攻击者的核心标志，是职业操守的体现。
风险：主要风险包括违反服务条款（可能导致IP被封）、侵犯隐私（可能引发法律纠纷）、误伤第三方系统。
局限：即使严格遵守边界，也可能因目标系统误判而被错误视为恶意。
缓解措施：始终使用官方、标准方法。发起自动化请求前，尝试先联系目标所有者（若可能）。保留所有操作详细日志，以备审计和澄清。
决策指南：何时必须使用？ 在任何一次信息收集任务中，风险控制必须在操作开始前、进行中和结束后贯穿始终。何时替代？ 无法替代，风险控制是所有行动的基石。

十、本模块阶段性小结

本模块为所有操作建立了清晰的法律和道德边界，并提供了具体管理方法，确保获取情报的同时始终为负责任的网络安全专业人员。接下来，我们将收集到的信息整合成最终成果，完成从原始信息到高价值情报的转化。

七、能力整合与输出

一、模块概念解释

本模块为信息收集流程的最终环节，核心任务是将前期收集、验证、关联后的信息系统性整合、提炼和结构化呈现，形成面向特定受众的最终成果，解决“如何让收集到的信息发挥最大价值”的问题。输出的是基于信息的分析、判断和结论。

二、技术原理说明

最终输出的形式取决于受众和目的，底层逻辑是“信息-知识-情报”的转化模型。

信息：原始数据，如“域名A的WHOIS邮箱是xxx@example.com，证书B的Subject是…” （阶段二、三产物）。
知识：经过组织和关联的信息，如“邮箱xxx@example.com同时关联到域名A、B、C，且这些域名都指向一个名为‘ExampleOrg’的非营利组织” （阶段四、五产物）。
情报：结合上下文和目的，对知识的分析和判断，如“因此，有中等置信度判断，APP X的开发者是ExampleOrg国际组织，其主要关注领域Y，关联数字资产包括A、B、C。这对评估APP X的供应链风险有直接帮助” （本模块产物）。
本模块完成从“知识”到“情报”的跃迁，为决策提供直接支持。

三、在系统中的位置

本模块是整个流程的终点和成果交付点。它接收来自“操作路径形成”模块的已验证信息和“风险与边界控制”模块的合规约束，整合成最终报告、图表或数据文件。一份优秀的输出也能作为未来类似任务的输入（如建立主体知识库），形成能力闭环。

四、可执行命令或查询方式

本模块强调输出，而非查询。“命令”体现为生成报告的工具或脚本。

示例：使用命令行工具生成报告摘要
bash # 假设已将关键信息存入 info.txt 文件 echo "===== 责任主体情报摘要 =====" > report.txt echo "目标APP: OWASP Juice Shop" >> report.txt echo "主体名称: OWASP Foundation" >> report.txt echo "主体官网: https://owasp.org" >> report.txt echo "关联域名: owasp.org, juice-shop.github.io" >> report.txt echo "置信度评估: 高 (多源信息交叉验证)" >> report.txt cat report.txt

五、工具对比表

工具/资源	适用场景	优点	局限
Markdown 编辑器	撰写结构清晰、可读性强的技术报告，可转换为PDF或HTML	语法简单，格式整洁，支持代码块、表格，非常适合技术文档	不适合生成复杂图表
电子表格（如 Excel）	输出结构化的资产列表、关联关系矩阵等数据	数据便于排序、筛选和二次处理	不适合撰写长篇分析性文字
思维导图软件（如 XMind）	向非技术受众直观展示主体、资产、标识之间的复杂关联网络	可视化效果极佳，易于理解关系	信息承载量有限，不适合输出大量细节
专业报告生成工具（如 LaTeX）	需要格式极其规范、严谨的正式报告	排版精美，对复杂公式和引用支持好	学习曲线陡峭

六、标准操作步骤

确定报告受众和格式：明确报告给谁看（技术团队、管理层、法务），据此选择报告格式（如Markdown技术报告、PPT摘要）。
整合核心信息：回顾阶段四、五产出，提炼核心责任主体信息：主体名称、主体类型、主体官网、主体简介。
梳理关联资产列表：整理与主体强关联的数字资产，如官方网站、相关域名、代码仓库、社交媒体账号、主要应用列表，可按关联强度排序。
撰写分析过程与置信度：简要说明如何得出上述结论（如“通过WHOIS信息交叉验证”、“证书信息指向”），并对结论确定性给出置信度评估（高/中/低），说明原因。
组织并呈现信息：按照从“核心结论”到“详细证据”的逻辑结构，将信息填充到选定报告格式，使用标题、列表、表格使内容层次分明。
脱敏与合规审查：最终检查报告中是否包含任何不必要的个人信息或敏感数据，如有则脱敏处理。
输出与归档：将最终报告保存为选定格式，按安全策略归档。

七、如何验证结果真实性

验证逻辑：最终输出的真实性体现在所有结论都能在引用的证据链中找到支持，且证据链完整、可追溯。
输出判断依据：读者阅读报告时，看到结论（如“开发者是OWASP Foundation”），能沿着报告提供的证据（如“详见2.1节WHOIS记录”）找到原始数据，且这些原始数据足以支撑结论。这种结论与证据之间的清晰、可追溯的对应关系是报告真实性的最终体现。

八、常见错误与排查方式

错误：只输出结论，不提供证据和分析过程，使报告沦为“黑盒”，无法验证可信度。
- 排查：撰写时，养成“每个结论必须有引用”的习惯，可使用脚注或内部链接将结论和原始数据关联。
错误：输出内容冗长，信息堆砌，未突出核心结论，让读者难以抓住重点。
- 排查：遵循“金字塔原理”，结论先行。报告开头是“核心摘要”，然后才是“详细支撑材料”，摘要中只含最重要的3-5条信息。

九、合规边界说明

网络安全视角：一份专业、严谨、合规的报告是整个信息收集工作的价值体现，也是网络安全人员专业能力的证明。
风险：报告若包含未经脱敏的敏感信息，或在传播中落入不当人员手中，可能造成信息泄露。
局限：报告结论仅基于当时可获取的公开信息，具有时效性，主体信息可能随时间变化。
缓解措施：对报告进行密级标识，严格控制分发范围。在报告中明确信息截止日期和局限性。始终将风险控制模块要求落实到最终输出中。
决策指南：何时必须使用？ 信息收集任务完成，需向相关方交付成果时，必须进行此整合与输出。何时替代？ 若信息收集仅用于个人理解或短期记忆，可简化输出，但仍应形成笔记便于日后回溯。

十、本模块阶段性小结

本模块完成了从原始信息到高价值情报的最终转化，形成结构清晰、证据确凿、合规安全的责任主体分析报告。至此，完成了从“认知重构”到“整合输出”的完整信息收集工程闭环。这套方法论和流程可系统应用于任何需要进行APP知识产权与开发者背景调研的场景。

图：信息-知识-情报转化模型

参考与进一步阅读

Kali Linux Tools Documentation: whois：本文中 whois 命令参数与安装方式的主要参考依据。
Debian Manpages: whois(1)：whois 命令的详细手册页，提供了全面的选项说明和用法示例。
InterNetX Help: OpenSSL Commands：提供了 openssl s_client -showcerts 等命令的详细解释。
University of Warwick: OpenSSL：提供了 openssl 命令的实用示例，包括如何查看证书链和解读输出。
crt.sh | Certificate Transparency Log Search：文中提及的用于验证证书信息真实性的公开CT日志搜索引擎。
OWASP Foundation Official Website：文中示例“OWASP Juice Shop”的归属机构，其官网提供了大量关于应用安全项目的权威信息。
G5 Cyber Security Blog: Check Certificate Transparency Logs：介绍了如何使用crt.sh进行证书监控和验证，为“验证结果真实性”部分提供依据。
RFC 3912 – WHOIS Protocol Specification：WHOIS协议的技术规范，定义了协议的基本运作方式。 (核心行为自2004年以来未发生重大变化)
建议读者访问官方最新文档以确认当前环境兼容性。

信息收集-APP应用-资产信息-抓包&静态提取&动态调试

模块一、移动应用资产信息认知框架

学习目标

掌握移动应用资产信息的定义、范畴与技术定位。
能够分析资产信息各构成元素（代码、数据、网络、配置）之间的关联。
理解本模块作为信息收集的起点，如何为后续抓包、静态提取、动态调试提供统一的分析视角。
从全局视角区分资产信息的静态存储与动态传输形态。

重点与难点

核心知识点在于理解移动应用资产信息并非孤立的数据点，而是由客户端代码、本地存储数据、运行时内存数据及网络通信数据构成的整体。难点在于打破仅关注单一类型资产（如仅看网络流量或仅看代码）的线性思维，建立多维度资产关联分析意识，为后续系统性提取信息奠定认知基础。

一、模块概念解释

本模块旨在重构对移动应用资产信息的认知方式。传统分析中，应用代码、本地数据库、网络请求常被视为独立模块，本模块则建立一个统一的分析框架。

在此框架下，“资产信息”被定义为：移动应用在运行和交互过程中，所有可被提取并用于理解应用功能、逻辑、配置及潜在风险的数字线索。这包括：应用代码逻辑、嵌入代码的硬编码凭证、本地存储的配置文件与缓存数据、运行时的内存对象，以及应用与服务器交互的网络协议、接口地址和数据载荷。该框架解决的问题是，如何从零散的技术点中抽象出一个完整的、可操作的资产信息视图。

移动应用资产信息多维关联图

二、技术原理说明

该认知框架的底层逻辑基于系统论和信息论。移动应用作为一个信息系统，其资产信息在静态（存储）和动态（传输、处理）状态下存在。信息必须依附于载体。代码（DEX/ Mach-O文件）是逻辑的载体，本地文件系统（SQLite数据库/ SharedPreferences）是持久化数据的载体，网络流量（TCP/HTTP/WebSocket数据包）是通信数据的载体，内存（堆/栈）是运行时瞬时数据的载体。

该框架的设计核心，是将上述载体按照“生命周期”和“存在形态”两个维度进行划分。生命周期指信息从产生、存储、传输到消亡的过程；存在形态指信息是静态持久化（如硬盘上的配置文件）还是动态瞬时（如内存中的解密后密钥）。该框架用于解决信息收集的“完整性”和“关联性”问题。若不建立此框架，分析师可能只关注了网络流量，而遗漏应用本地存储的开发者后台地址，导致攻击面清单不完整。此框架的权衡在于其抽象性和复杂性——它提供了一个全面但需要投入更多认知资源进行关联思考的视角。

资产信息二维分类模型图

三、在系统中的位置

本模块是信息收集流程的“概念基础层”，位于所有具体操作技术之前，为后续模块提供统一的分析语言和思维模型。

与前序模块的关系：将前置知识中“理解移动应用资产信息的定义”这一概念系统化、结构化。
与后续模块的关系：本模块建立的“网络-代码-数据”三维视角，将指导后续模块对具体资产构成的分析，并为抓包（解决网络维度）、静态提取（解决代码与数据维度）、动态调试（解决运行时维度）三种方法提供明确的问题定位。

四、可执行命令或查询方式

此模块不涉及直接的信息提取，而是进行信息分类与关联练习。可在合法演练环境中执行以下命令，初步实践信息关联。

# 1. 查询应用包名（作为资产信息的唯一标识）
adb shell pm list packages | grep <应用关键词>

# 2. 查看应用安装路径（了解代码资产的物理存储位置）
adb shell pm path <应用包名>

# 3. 列出应用私有目录下的文件（初步了解本地数据资产）
# 【技术边界】run-as命令仅适用于应用自身或可调试应用，且从Android 4.4开始限制增强。若目标应用不可调试，此命令会失败。
adb shell run-as <应用包名> ls -la /data/data/<应用包名>/

# 4. 使用nslookup查询应用可能通信的域名（以OWASP Juice Shop为例）
nslookup juice-shop.herokuapp.com

五、工具对比表

工具/视角	适用场景	优点	局限性
网络视角	分析应用与后端的所有通信行为	直接捕获交互数据，协议、接口、参数清晰	无法看到本地存储和代码逻辑，加密流量需解密
代码视角	分析应用内部逻辑、算法、硬编码信息	可发现隐藏逻辑、后端API地址、硬编码凭证	受混淆、加固技术影响大，无法获取运行时动态值
数据视角	分析应用在本地存储的配置、缓存、数据库	可发现不应持久化存储的敏感信息	需要文件系统访问权限，数据可能加密或编码
运行时视角	分析应用运行时的内存对象、函数调用	可验证静态分析结果，捕获动态生成的数据	操作复杂，对反调试机制敏感，可能改变应用行为

六、标准操作步骤

准备分析环境：启动已安装目标应用（如OWASP Juice Shop）的Android模拟器或真机，确认Android Debug Bridge (adb)连接正常。
识别应用标识：使用adb shell pm list packages命令，通过应用名称关键词过滤，获取目标应用的唯一包名。
定位本地资产存储路径：使用adb shell pm path <包名>获取APK安装路径。使用adb shell run-as <包名> ls -la尝试浏览应用私有目录，初步观察是否存在databases、shared_prefs、files等子目录。
模拟网络交互：在模拟器中打开目标应用，执行一次登录或查询操作。
关联网络标识：使用nslookup或dig命令，对应用中出现的域名进行解析，获取其IP地址。
构建初步资产地图：将上述步骤中获取的包名、本地目录结构、域名/IP记录下来，形成该应用资产信息的第一张关联地图。

标准操作步骤流程图

七、验证结果真实性

本模块验证的重点在于认知关联的准确性。

验证逻辑：通过交叉索引不同来源的信息，确认它们描述的是同一个应用的不同资产维度。
判断依据：例如，通过pm path得到的APK路径，其文件应可通过adb pull命令拉取到本地，并能通过Android Asset Packaging Tool (aapt)查看包名，该包名应与pm list packages输出的包名一致。这验证了“代码资产”与“应用标识”的关联性。又如，通过应用界面操作后，若能使用adb shell run-as查看shared_prefs目录，应能找到与操作相关的新生成或更新的XML配置文件，这验证了“操作行为”与“本地数据资产变化”的关联性。

资产信息关联验证逻辑图

八、常见错误与排查

错误：将应用图标名称误认为包名。
- 排查：应用图标名称可被本地化或自定义，不具有唯一性。必须使用adb shell pm list packages查看系统注册的包名，这是应用的唯一标识。
错误：认为资产信息仅存在于APK文件中。
- 排查：通过run-as命令查看应用私有目录，确认应用在安装后生成的动态数据的存在。这有助于建立“静态代码”与“动态生成数据”是两个不同资产来源的认知。

九、合规边界说明

应用范围：此认知框架本身不涉及攻击行为，但其应用必须在授权范围内。
风险提示：若将此类分析方法应用于未经授权的应用，可能涉及逆向工程和隐私数据访问，违反相关法律法规。
技术局限：该框架基于公开技术原理构建，对于采用高度定制化私有协议或强混淆技术的应用，某些维度（如代码视角）可能难以深入。
缓解措施：确保被分析的应用属于自身或已获得明确的书面授权。在内部培训或自测时，严格限定在OWASP Juice Shop、DVWA等公开的、明确用于安全训练的靶机应用上。
决策指南：
- 适用场景：在启动任何移动应用安全评估项目前，应建立这种全局认知，以避免遗漏关键信息。
- 替代方案：对于简单的功能测试，可能无需此复杂框架，但对于深度安全评估，该框架是形成完整攻击面清单的前提。

合规边界决策树

十、模块总结

本模块完成了对移动应用资产信息的认知重构，将其从孤立的技术点整合为“代码-数据-网络-运行时”的多维度关联视图。该框架解决了信息收集的完整性问题，为后续模块提供了统一的分析语言。在此基础上，后续模块将逐一深入剖析资产信息的具体构成，并为每种维度制定对应的提取方法。

十一、关键术语

包名
: Android系统中应用的唯一标识符。
私有目录
: /data/data/<包名>/，Android系统为每个应用分配的专属存储空间。
静态资产
: 指应用安装包（APK/IPA）中包含的代码、资源和配置文件。
动态资产
: 指应用运行时在内存中生成、或运行过程中产生并存储于本地的数据。
攻击面
: 应用中所有可能被利用的入口点和信息泄露点的总和。
信息关联
: 将不同来源的孤立信息片段，通过逻辑分析连接起来，形成有意义的上下文。

十二、思考与练习

配置分析：在Android模拟器中安装OWASP Juice Shop，浏览应用功能后，使用adb shell进入其私有目录，找出所有.xml和.db文件。根据文件名猜测这些文件可能存储了哪类资产信息？
结果判断：假设在一次分析中，从APK代码里发现一个硬编码IP地址192.168.1.100，同时从抓包数据中看到应用正在向域名api.example.com发送请求。这两种信息是否矛盾？可能存在哪几种关联情况？
权衡决策：在一次授权测试中，如果只能从“网络视角”和“本地数据视角”中选择一个作为优先分析方向，你的决策依据是什么？请结合应用类型（如金融类 vs 游戏类）说明理由。

参考与进一步阅读

Android Debug Bridge (adb) 文档：Android Developers官方文档。本文中adb命令的权威参考。
Android 存储权限和行为变更：Android Developers官方指南。解释了run-as命令的访问限制。
OWASP Mobile Top 10：OWASP官方项目页面。提供了移动应用十大安全风险的权威定义。
NIST SP 800-163 – 应用程序源代码安全审查：NIST官方出版物。为静态源代码审计提供了方法论指导。
MITRE ATT&CK for Mobile：MITRE官方知识库。提供了针对移动平台的攻击技术框架。