From b48e28d5f42a6fc08a0b9c1a5c2ea9149c355b96 Mon Sep 17 00:00:00 2001 From: yuanyuanxiang Date: Fri, 1 May 2026 20:14:03 +0000 Subject: [PATCH] =?UTF-8?q?=E6=B7=BB=E5=8A=A0=20Home?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Home.md | 1008 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1008 insertions(+) create mode 100644 Home.md diff --git a/Home.md b/Home.md new file mode 100644 index 0000000..8d7d9ae --- /dev/null +++ b/Home.md @@ -0,0 +1,1008 @@ +# SimpleRemoter 多层授权架构指南 + +## 一、痛点与解决方案 + +### 传统远程控制系统的困境 + +如果您想构建一个大规模的远程管理系统，传统方案面临以下挑战： + +``` +传统架构示意图： + +┌─────────────────────────────────────────────────────────────┐ +│ 您（总控制中心） │ +│ 需要一台高配服务器 │ +└──────────────────────────┬──────────────────────────────────┘ + │ + ┌──────────────────┼──────────────────┐ + │ │ │ + ▼ ▼ ▼ +┌───────────────┐ ┌───────────────┐ ┌───────────────┐ +│ 服务器 A │ │ 服务器 B │ │ 服务器 C │ +│ (需要公网IP) │ │ (需要公网IP) │ │ (需要公网IP) │ +│ 月租 ¥xxx │ │ 月租 ¥xxx │ │ 月租 ¥xxx │ +└───────┬───────┘ └───────┬───────┘ └───────┬───────┘ + │ │ │ + 受管设备群 受管设备群 受管设备群 +``` + +**传统方案的问题：** + +| 问题 | 说明 | +|------|------| +| 成本高 | 每个节点都需要独立的公网IP服务器，月租费用累积 | +| 运维复杂 | 多台服务器需要分别维护、更新、监控 | +| 协调困难 | 需要自己开发总控系统来管理多个子节点 | +| 扩展受限 | 每增加一个下级代理商，就需要增加服务器投入 | +| 授权混乱 | 无法有效控制下级的分销行为和有效期 | +| 安全薄弱 | 授权容易被复制、伪造、篡改 | + +--- + +### SimpleRemoter 的创新方案 + +我们的多层授权架构 + FRP 自动代理，让您的客户**只需要一台有公网IP的服务器**即可构建完整的远程管理系统： + +``` +SimpleRemoter 多层架构示意图： + +┌─────────────────────────────────────────────────────────────┐ +│ 超级管理员（项目开发者） │ +│ 唯一存在 │ +│ 持有 ECDSA 私钥，签发顶级授权 │ +│ 可选：提供 FRP 代理服务 │ +└──────────────────────────┬──────────────────────────────────┘ + │ V2 授权 (ECDSA 签名) + │ + 可选 FRP 配置 + │ + 指定可生成的下级层数 + ┌──────────────────┼──────────────────┐ + │ │ │ + ▼ ▼ ▼ +┌───────────────┐ ┌───────────────┐ ┌───────────────┐ +│ 客户 A │ │ 客户 B │ │ 客户 C │ +│ (第一层) │ │ (第一层) │ │ (第一层) │ +│ 可生成2层下级 │ │ 可生成1层下级 │ │ 叶子节点 │ +│ │ │ │ │ (不可生成下级) │ +└───────┬───────┘ └───────┬───────┘ └───────┬───────┘ + │ │ │ + │ 可继续发展下级 │ 只能发展1层 │ 只能管理设备 + ▼ ▼ │ +┌───────────────┐ ┌───────────────┐ │ +│ 客户 A 的下级 │ │ 客户 B 的下级 │ │ +│ (第二层) │ │ (第二层) │ │ +│ 可生成1层下级 │ │ 叶子节点 │ │ +└───────┬───────┘ └───────────────┘ │ + │ │ + ▼ │ +┌───────────────┐ │ +│ 第三层... │ │ +└───────────────┘ │ + │ │ + └─────────────┬───────────────────────┘ + │ + ▼ + ┌───────────────┐ + │ 任何节点都可以 │ + │ 生成受管程序 │ + │ 部署到待管设备 │ + └───────────────┘ +``` + +--- + +## 二、架构详解 + +### 2.1 节点类型 + +| 节点类型 | 说明 | 能力 | +|---------|------|------| +| **超级管理员** | 项目开发者，全局唯一 | 签发V2授权，控制整个授权链，指定客户的下级层数 | +| **控制端节点** | 从上级获得授权的客户 | 生成受管程序，管理受管设备 | +| **可分销节点** | 被授权可生成下级的控制端 | 除控制端能力外，还可给下级签发V1授权 | +| **叶子节点** | 不能生成下级的控制端 | 只能生成受管程序，管理受管设备 | + +### 2.2 授权类型对比 + +| 授权类型 | 使用场景 | 验证方式 | 说明 | +|---------|---------|---------|------| +| **V2 (ECDSA)** | 超管 → 第一层 | 网络验证 + 数字签名（支持离线） | 最高安全级别 | +| **V1 (HMAC)** | 上级 → 下级 | 网络验证 + 消息认证码 | 适用于分销场景 | +| **Authorization** | 控制有效期 | 离线验证（ECDSA 签名） | 全链共享，自动续期 | + +### 2.3 层级控制机制 + +超管在给第一层客户授权时，可以指定该客户能生成多少层下级： + +``` +授权参数示例： + +客户 A 的授权： + • 有效期：2026-03-17 ~ 2027-03-17 + • 连接数：256 + • 可生成下级层数：2 ← 可以发展2层下级 + +客户 B 的授权： + • 有效期：2026-03-17 ~ 2027-03-17 + • 连接数：100 + • 可生成下级层数：0 ← 叶子节点，不能发展下级 +``` + +**层级传递规则：** + +``` +超管授权客户A（可生成2层） + │ + ├──▶ 客户A给下级A1授权（最多可生成1层） + │ │ + │ └──▶ A1给下级A1a授权（最多可生成0层 = 叶子节点） + │ + └──▶ 客户A给下级A2授权（可设为0层 = 叶子节点） + +规则：下级的"可生成层数" ≤ 上级的"可生成层数" - 1 +``` + +### 2.4 工作流程图解 + +``` +步骤 1: 超管给客户授权 +━━━━━━━━━━━━━━━━━━━━ + + ┌─────────────┐ ┌─────────────┐ + │ 超管 │ ──── V2 授权 ────▶ │ 客户 │ + │ (开发者) │ │ (第一层) │ + └─────────────┘ └─────────────┘ + │ │ + │ 生成: │ 收到: + │ • Passcode (密码) │ • Passcode + │ • PwdHmac (v2:签名) │ • PwdHmac + │ • 可生成下级层数 │ • Authorization + │ • FRP配置（可选） │ • FRP配置（可选） + + +步骤 2: 客户给下级授权（如果有分销权限） +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + ┌─────────────┐ ┌─────────────┐ + │ 客户 │ ──── V1 授权 ────▶ │ 下级 │ + │ (有分销权) │ │ │ + └─────────────┘ └─────────────┘ + │ │ + │ 生成: │ 收到: + │ • Passcode (密码) │ • Passcode + │ • PwdHmac (数字) │ • PwdHmac + │ • 可生成层数（≤自己-1） │ • 完整 Authorization + + +步骤 3: 任意节点生成受管程序 +━━━━━━━━━━━━━━━━━━━━━━━━━━ + + ┌─────────────┐ + │ 任意控制端 │ ──── 生成受管程序 ────▶ 部署到待管设备 + │ (包括叶子) │ + └─────────────┘ + + 受管程序连接到该控制端，实现远程监管 + + +步骤 4: 续期自动传递 +━━━━━━━━━━━━━━━━━━━ + + 超管续期第一层客户 + │ + ▼ + 客户获得新 Authorization + │ + ▼ + 客户的下级连接时自动获取新 Authorization + │ + ▼ + 全网自动续期完成！ +``` + +--- + +## 三、FRP 自动代理 - 零服务器方案 + +### 3.1 什么是 FRP？ + +FRP (Fast Reverse Proxy) 是一种内网穿透工具。通过 FRP，即使您的客户没有公网 IP，也能被受管设备访问。 + +**传统方案 vs FRP 方案：** + +``` +传统方案（需要公网IP）： +━━━━━━━━━━━━━━━━━━━━━━ + + 受管设备 ────▶ 客户服务器（公网IP） ◀──── 远程管理 + 需要租用服务器 + + +FRP 方案（无需公网IP）： +━━━━━━━━━━━━━━━━━━━━━ + + ┌────────────────┐ + 受管设备 ────▶ │ 超管的FRP服务器 │ ◀──── 远程管理 + │ (一台即可) │ + └───────┬────────┘ + │ + ┌───────┴────────┐ + │ FRP 隧道 │ + └───────┬────────┘ + │ + ┌───────▼────────┐ + │ 客户的电脑 │ + │ (无需公网IP！) │ + └────────────────┘ +``` + +### 3.2 FRP 自动配置流程 + +整个过程完全自动化，您的客户无需任何网络知识： + +``` +1. 超管配置 FRP 服务器 + ┌────────────────────────────────────────┐ + │ 扩展(X) → 下级FRP代理设置... │ + │ │ + │ [✓] 启用为下级提供 FRP 代理 │ + │ │ + │ 服务器地址: [frp.your-domain.com] │ + │ 服务器端口: [7000] │ + │ 认证Token: [********************] │ + │ 端口范围: [20000] ~ [29999] │ + └────────────────────────────────────────┘ + +2. 生成授权时勾选 FRP + ┌────────────────────────────────────────┐ + │ 工具(T) → 生成口令... │ + │ │ + │ [✓] 提供 FRP 代理 远程端口: [20001] │ + │ │ + │ FRPS: frp.your-domain.com:7000 │ + └────────────────────────────────────────┘ + +3. 客户导入授权 + ┌────────────────────────────────────────┐ + │ 客户端自动: │ + │ • 解析 FRP 配置 │ + │ • 启动 FRPC 连接 │ + │ • 建立反向隧道 │ + │ │ + │ [FRP-Auto] 启动成功! │ + │ [FRP-Auto] 远程端口: 20001 │ + └────────────────────────────────────────┘ + +4. 受管设备连接 + ┌────────────────────────────────────────┐ + │ 连接地址: frp.your-domain.com:20001 │ + │ │ + │ 隧道路径: │ + │ 受管设备 → FRP服务器 → 客户控制端 │ + └────────────────────────────────────────┘ +``` + +### 3.3 FRP Token 隐藏机制 + +**传统 FRP 的安全问题：** 客户知道 Token 后可以自己创建隧道，绕过授权控制。 + +**SimpleRemoter 的解决方案：** + +``` +超管配置: + Token = "MySecretToken123" + +生成授权时: + privilegeKey = MD5(Token + Timestamp) + 或 + privilegeKey = "ENC:" + XOR_Base64(Token) + +客户收到: + 只有 privilegeKey，不知道原始 Token + +自定义FRPS验证: + 验证 MD5(Token + Timestamp) == privilegeKey ✓ +``` + +**两种认证模式：** + +| 模式 | 实现方式 | 客户是否知道Token | 适用场景 | +|------|---------|------------------|---------| +| 自定义 FRP | `privilegeKey = MD5(token + timestamp)` | 否 | 需要隐藏Token | +| 官方 FRP | `privilegeKey = "ENC:" + 编码后的token` | 解码后可知 | 使用官方FRPS | + +--- + +## 四、核心安全机制 + +### 4.1 ECDSA 数字签名 + +**为什么选择 ECDSA 而不是 RSA？** + +| 对比项 | RSA-2048 | ECDSA P-256 | +|-------|----------|-------------| +| 密钥长度 | 2048 bits | 256 bits | +| 签名长度 | 256 bytes | 64 bytes | +| 安全强度 | 112 bits | 128 bits | +| 签名速度 | 慢 | 快 | +| 验证速度 | 快 | 较快 | + +**ECDSA 优势：** +- 密钥更短，存储和传输更方便 +- 同等安全强度下性能更好 +- 是现代加密标准（TLS 1.3、比特币等都使用 ECDSA） + +### 4.2 双重验证机制 + +下级验证时需要通过两道关卡： + +``` +验证流程（顺序重要）： + +┌─────────────────────────────────────────────────────────────┐ +│ 第一关：V1 HMAC 网络验证（先执行） │ +│ │ +│ • 连接上级服务器 │ +│ • 验证 HMAC = f(Password, 上级pwdHash, DeviceID) │ +│ • 作用：设备绑定 + 获取新 Authorization │ +└─────────────────────────────────────────────────────────────┘ + │ + ▼ 通过后 +┌─────────────────────────────────────────────────────────────┐ +│ 第二关：ECDSA 离线验证（后执行） │ +│ │ +│ • 验证 Authorization 的 ECDSA 签名 │ +│ • 检查有效期范围 │ +│ • 作用：确保授权来自超管且未过期 │ +└─────────────────────────────────────────────────────────────┘ + │ + ▼ 两关都通过 + 验证成功！ +``` + +**为什么这个顺序很重要？** + +先 HMAC 后 ECDSA 的设计支持**自动续期**： +- 即使旧 Authorization 已过期，只要签名有效，仍可连接上级 +- 上级返回新的 Authorization +- 再验证新 Authorization 的签名和有效期 +- 实现无缝续期，无需人工干预 + +### 4.3 设备绑定机制 + +每个授权都绑定特定设备，无法复制到其他机器： + +``` +授权生成时： + + derivedKey = KDF( + password = "日期范围 + 上级pwdHash + 连接数", + salt = DeviceID + ) + +验证时： + + 上级使用相同算法计算 expectedKey + 比较 derivedKey == expectedKey + + DeviceID 不同 → expectedKey 不同 → 验证失败 +``` + +### 4.4 第一层隔离机制 (snHashPrefix) + +防止不同第一层客户之间的 Authorization 混用： + +``` +客户 A 的 Authorization: + snHashPrefix = SHA256(A的DeviceID).substr(0, 8) = "a1b2c3d4" + 签名内容 = "有效期|连接数|a1b2c3d4" + +客户 B 的 Authorization: + snHashPrefix = SHA256(B的DeviceID).substr(0, 8) = "e5f6g7h8" + 签名内容 = "有效期|连接数|e5f6g7h8" + +如果 A 试图使用 B 的 Authorization： + A 返回给下级前检查: 自己的snHashPrefix == Authorization中的snHashPrefix + "a1b2c3d4" != "e5f6g7h8" → 拒绝返回 +``` + +### 4.5 配置混淆存储 + +Authorization 包含敏感信息（有效期、服务器地址等），需要混淆： + +``` +明文: + 20260317|20270317|0256|a1b2c3d4|192.168.1.100:6544|v2:xxx... + +存储流程: + 明文 → XOR混淆(固定密钥) → Base64编码 → 写入配置文件 + +存储后: + YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY3ODkw... + +读取流程: + 配置文件 → Base64解码 → XOR还原 → 明文 +``` + +**防护效果：** +- 直接查看配置文件看不到明文 +- 标准 Base64 解码只能得到乱码 +- 需要知道 XOR 密钥才能还原 + +### 4.6 攻击场景防护总览 + +| 攻击场景 | 防护机制 | 结果 | +|---------|---------|------| +| 伪造/延长授权有效期 | ECDSA 签名保护 | ❌ 签名验证失败 | +| 复制授权到其他设备 | DeviceID 绑定 derivedKey | ❌ 设备绑定验证失败 | +| 客户A使用客户B的Authorization | snHashPrefix 隔离检查 | ❌ 前缀不匹配被拒绝 | +| 下级绕过上级直接连超管 | pwdHash 不同导致 derivedKey 不匹配 | ❌ HMAC 验证失败 | +| 叶子节点生成下级控制端 | 层数限制检查 | ❌ 超出授权层数 | +| 伪造 FRP 连接 | privilegeKey 验证 | ❌ FRPS 拒绝连接 | +| 篡改 hmacServer 地址 | HMAC 在错误服务器上验证 | ❌ 密码不匹配 | +| 窃取配置文件 | XOR + Base64 混淆 | ❌ 无法直接读取明文 | +| 重放旧的 Authorization | 有效期检查 | ❌ 过期被拒绝 | + +--- + +## 五、运营管理优势 + +### 5.1 一键续期，全网生效 + +``` +传统方案的续期： +━━━━━━━━━━━━━━━ + + 超管 ──手动更新──▶ 客户A + ──手动更新──▶ 客户B + ──手动更新──▶ 客户C + ... + + 客户A ──手动更新──▶ A的下级1 + ──手动更新──▶ A的下级2 + ... + + 工作量: O(N) 人工操作 + + +SimpleRemoter 的续期： +━━━━━━━━━━━━━━━━━━ + + 超管 ──更新──▶ 客户A、B、C...（V2验证时自动获取新Authorization） + │ + ▼ 自动传递 + 所有下级验证时自动获取新Authorization + + 工作量: 超管只需更新第一层，全网自动生效 +``` + +### 5.2 授权文件支持 + +支持导出/导入 `.lic` 授权文件，方便分发： + +```json +{ + "magic": "YAMA", + "version": 1, + "createTime": "2026-04-01 22:30:00", + "license": { + "sn": "XXXX-XXXX-XXXX-XXXX", + "password": "20260401-20270401-0100-xxxx-xxxx-xxxx-xxxx", + "pwdHmac": "v2:...", + "authorization": "...", + "frpConfig": "frp.example.com:7000-20000-20371231-..." + }, + "checksum": "sha256:..." +} +``` + +**优势：** +- 一个文件包含所有授权信息 +- 包含 FRP 配置，导入即用 +- SHA256 校验防篡改 +- 比发送多个字符串更方便 + +### 5.3 FRP 端口自动管理 + +```ini +[frp_ports] +; 自动记录端口分配 +20001 = XXXX-XXXX-XXXX-0001 +20002 = XXXX-XXXX-XXXX-0002 +20003 = XXXX-XXXX-XXXX-0003 +... +``` + +**功能：** +- 自动分配下一个可用端口 +- 记录端口与序列号的对应关系 +- 支持配置端口范围 +- 避免端口冲突 + +### 5.4 离线验证能力 + +V2 授权支持离线验证（无需连接超管服务器）： + +``` +场景：超管服务器临时不可用 + +传统方案： + 客户无法验证 → 无法启动 → 业务中断 + +SimpleRemoter： + 1. 首次验证时已保存 Authorization + 2. Authorization 包含 ECDSA 签名 + 3. 公钥内嵌在程序中 + 4. 离线验证签名 + 检查有效期 → 可以启动 + + 业务不中断！ +``` + +--- + +## 六、成本优势分析 + +### 6.1 服务器成本对比 + +假设您有 10 个第一层客户，每个客户有 5 个下级： + +| 方案 | 服务器数量 | 月成本估算 | +|------|-----------|-----------| +| 传统方案（每节点独立服务器） | 60+ 台 | ¥30,000+/月 | +| 传统方案（共享但需公网IP） | 10+ 台 | ¥5,000+/月 | +| SimpleRemoter + FRP | 1~2 台 | ¥200~1,000/月 | + +**节省 90%~99% 的服务器成本！** + +### 6.2 运维成本对比 + +| 运维项目 | 传统方案 | SimpleRemoter | +|---------|---------|---------------| +| 授权续期 | 逐个手动更新 | 一键全网生效 | +| 授权分发 | 发送多个字符串 | 发送一个lic文件 | +| 网络配置 | 每个客户都要配置 | FRP 自动配置 | +| 安全更新 | 各节点分别更新 | 中心化更新 | + +### 6.3 客户准入门槛 + +| 要求 | 传统方案 | SimpleRemoter | +|------|---------|---------------| +| 需要公网IP | 是 | 否（使用FRP） | +| 需要服务器 | 是 | 否（使用FRP） | +| 需要网络知识 | 是 | 否（自动配置） | +| 需要运维能力 | 是 | 否 | + +**降低客户准入门槛，扩大潜在客户群！** + +--- + +## 七、快速上手 + +### 7.1 超管操作流程 + +``` +步骤 1: 生成密钥对（仅首次） +━━━━━━━━━━━━━━━━━━━━━━━━━━ + + 工具(T) → 生成口令 → 选择 V2 → 点击"生成密钥对" + + 保存好私钥文件！丢失将无法签发新授权 + + +步骤 2: 配置 FRP 服务器（可选但推荐） +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + 扩展(X) → 下级FRP代理设置 + + 填写您的 FRP 服务器信息 + + +步骤 3: 为客户生成授权 +━━━━━━━━━━━━━━━━━━━━━ + + 工具(T) → 生成口令 + + • 选择 V2 版本（主要方式，支持离线验证） + • 输入客户的设备序列号 + • 设置有效期和连接数 + • 设置可生成的下级层数（0=叶子节点） + • 勾选"提供 FRP 代理"（如需） + • 点击"生成" → "保存授权" + + +步骤 4: 发送授权信息给客户 +━━━━━━━━━━━━━━━━━━━━━━━━ + + 方式 A: 发送生成的密码和 HMAC + 方式 B: 导出 .lic 授权文件发送（推荐） +``` + +### 7.2 客户操作流程 + +``` +步骤 1: 导入授权 +━━━━━━━━━━━━━━━ + + 方式 A: 在设置中输入密码和 HMAC + 方式 B: 导入收到的 .lic 授权文件（推荐） + + +步骤 2: 验证授权 +━━━━━━━━━━━━━━━ + + 程序自动连接超管服务器验证（或离线验证） + 验证成功后： + • 显示有效期和连接数 + • 显示可生成的下级层数 + • 如有 FRP 配置，自动启动 FRP 客户端 + + +步骤 3: 生成受管程序 +━━━━━━━━━━━━━━━━━━ + + 生成 → 生成受管程序 + + 将生成的程序部署到待管设备运行 + + +步骤 4: 给下级授权（如果有分销权限） +━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ + + 工具(T) → 生成口令 + + • 选择 V1 版本 + • 输入下级的设备序列号 + • 设置有效期（不能超过自己的有效期） + • 设置可生成层数（不能超过自己的层数-1） + • 点击"生成" → "保存授权" +``` + +--- + +## 八、常见问题 + +### Q1: 我需要多少台服务器？ + +**答：** 作为超管，您只需要： +- 1 台服务器运行您的控制端 +- 1 台服务器运行 FRP（可以是同一台） + +您的客户可以选择： +- 自己租服务器（传统方案） +- 使用您提供的 FRP 代理（零服务器成本） + +### Q2: 叶子节点和可分销节点有什么区别？ + +**答：** +- **叶子节点**：可生成下级层数=0，只能生成受管程序管理设备，不能发展下级控制端 +- **可分销节点**：可生成下级层数>0，除了管理设备外，还可以给下级签发授权 + +### Q3: 授权过期后会发生什么？ + +**答：** +1. 您给客户续期后，客户的授权自动更新 +2. 客户的下级下次连接时自动获取新的有效期 +3. 整个过程无需手动操作 + +### Q4: 如果客户不续费怎么办？ + +**答：** 授权过期后： +- 客户的控制端停止工作 +- 客户的所有下级也无法使用 +- FRP 隧道自动断开 +- 受管设备无法连接 + +### Q5: V2 和 V1 授权有什么区别？ + +**答：** +- **V2 (ECDSA)**：超管专用，使用数字签名，安全级别最高，支持离线验证 +- **V1 (HMAC)**：客户给下级使用，使用消息认证码，需要网络验证 + +### Q6: FRP 会影响传输速度吗？ + +**答：** FRP 是高性能的反向代理，延迟增加通常在 10-50ms 以内，对远程管理体验影响很小。如果客户有条件，也可以自己部署服务器获得更低延迟。 + +### Q7: 什么是"受管程序"？ + +**答：** 受管程序是部署在待管设备上的客户端程序。运行后会连接到对应的控制端，实现远程监管功能（如远程桌面、文件管理、进程管理等）。 + +### Q8: 超管服务器挂了，客户能用吗？ + +**答：** 可以。V2 授权支持离线验证： +- 客户首次验证时已保存 Authorization +- Authorization 包含 ECDSA 签名 +- 只要在有效期内，可以离线验证启动 +- 只有续期时才需要连接超管服务器 + +### Q9: 客户能破解授权吗？ + +**答：** 极难。需要同时： +- 获取超管的 ECDSA 私钥（几乎不可能） +- 伪造设备 ID（硬件绑定） +- 知道上级的 pwdHash（每层不同） + +任何一项都有密码学保护。 + +--- + +## 九、架构优势总结 + +### 9.1 与传统远控方案对比 + +| 特性 | 传统方案 | SimpleRemoter 多层架构 | +|------|---------|----------------------| +| 服务器需求 | 每个节点都需要 | 最少只需 1 台 | +| 月运营成本 | 高（服务器费用累积） | 低（共享基础设施） | +| 授权管理 | 手动管理每个节点 | 自动化，集中管控 | +| 层级控制 | 无法限制 | 超管可精确控制每个客户的分销层数 | +| 续期操作 | 需要逐个更新 | 一处续期，全网生效 | +| 层级扩展 | 需要自己开发 | 原生支持可控层级 | +| 安全性 | 需要自己实现 | 多重安全机制内置 | +| 部署难度 | 高（需要网络知识） | 低（FRP 自动配置） | +| 离线能力 | 无 | V2 支持离线验证 | +| 客户门槛 | 高（需公网IP、服务器） | 低（FRP 代理即可） | + +### 9.2 核心优势一览 + +| 优势类别 | 具体优势 | +|---------|---------| +| **安全性** | ECDSA数字签名、双重验证、设备绑定、第一层隔离、配置混淆 | +| **成本** | 服务器共享、FRP内网穿透、运维自动化 | +| **管理** | 一键续期、授权文件、端口自动分配、层级可控 | +| **可用性** | 离线验证、自动续期、FRP自动配置 | +| **扩展性** | 无限层级、灵活分销、按需授权 | + +--- + +## 十、术语表 + +| 术语 | 说明 | +|------|------| +| 超级管理员（超管） | 项目开发者，全局唯一，持有签名私钥 | +| 控制端 | 运行管理软件的节点，可管理受管设备 | +| 受管程序 | 部署在待管设备上的客户端程序 | +| 待管设备/受管设备 | 安装了受管程序的终端设备 | +| 第一层 | 直接从超管获得授权的客户 | +| 叶子节点 | 不能生成下级控制端的节点（可生成层数=0） | +| V2 授权 | 使用 ECDSA 数字签名的授权方式 | +| V1 授权 | 使用 HMAC 消息认证码的授权方式 | +| Authorization | 有效期凭证，受 ECDSA 签名保护，全链共享 | +| snHashPrefix | 第一层设备ID的哈希前缀，用于隔离不同第一层 | +| derivedKey | 派生密钥，绑定设备ID，防止授权复制 | +| FRP | 内网穿透工具，让无公网IP的设备可被访问 | +| privilegeKey | FRP 认证密钥，隐藏原始 Token | +| .lic 文件 | 授权文件，包含所有授权信息和 FRP 配置 | + +--- + +## 十一、开源授权模式（面向开发者客户） + +### 11.1 独特的商业模式 + +SimpleRemoter 采用 **部分开源 + 授权激活** 的创新商业模式： + +``` +┌─────────────────────────────────────────────────────────────┐ +│ 开源部分 (MIT 协议) │ +│ │ +│ • 核心功能模块：远程桌面、文件管理、进程管理等 │ +│ • 通信协议、UI 界面、插件系统 │ +│ • 客户可以审计代码安全性 │ +│ • 客户可以自由修改、定制、二次开发 │ +└─────────────────────────────────────────────────────────────┘ + + +┌─────────────────────────────────────────────────────────────┐ +│ 闭源部分 (授权模块) │ +│ │ +│ • 授权验证模块（多处分布，抗破解设计） │ +│ • 哈希校验、HMAC 验证、有效期检查等 │ +│ • 以编译好的库/目标文件形式提供 │ +│ • 防止授权机制被绕过或破解 │ +└─────────────────────────────────────────────────────────────┘ +``` + +**为什么授权模块不开源？** + +| 原因 | 说明 | +|------|------| +| **防止破解** | 授权验证逻辑公开后容易被绕过 | +| **保护商业利益** | 确保授权机制的有效性 | +| **多点校验** | 授权验证分布在多个模块，增加破解难度 | +| **抗逆向设计** | 关键逻辑不暴露源码，提高安全性 | + +### 11.2 开发者客户的工作流程 + +针对有编程能力的第一层客户，可以获取源码进行定制化开发： + +``` +步骤 1: 获取源码 +━━━━━━━━━━━━━━━ + + 从 GitHub 克隆 SimpleRemoter 仓库 + https://github.com/yuanyuanxiang/SimpleRemoter + + +步骤 2: 获取授权 +━━━━━━━━━━━━━━━ + + 联系超管购买授权，超管通过 "工具 → 生成主控" 功能生成： + • 定制化的 EXE 程序（可直接使用） + • generated_hash.h 头文件（用于源码编译） + + +步骤 3: 替换头文件 +━━━━━━━━━━━━━━━━ + + 将 generated_hash.h 替换到源码指定位置 + 该文件包含： + • g_MasterID - 您的主控程序唯一标识 + • g_UpperHash - 上级（超管）的哈希标识 + • Validation - 有效期、层级深度等验证信息 + + +步骤 4: 自由定制 +━━━━━━━━━━━━━━━ + + 在源码基础上进行定制化开发： + • 修改界面外观 + • 添加新功能 + • 集成第三方服务 + • 调整业务逻辑 + + +步骤 5: 编译发布 +━━━━━━━━━━━━━━━ + + 编译后的程序具有完整功能 + 可以发展自己的下级客户 +``` + +### 11.3 generated_hash.h 文件结构 + +```cpp +// Auto-generated hash file for lower-level agent +// Generated at: 2026-04-03 12:00:00 + +#pragma once + +#include +#include "common/hash.h" + +// 主控程序唯一标识 +// 密码的哈希值 + 验证信息 +char g_MasterID[_MAX_PATH] = { + 0x61, 0x62, 0x63, 0x64, ... // 64字节密码哈希 + // + 32字节校验码 + // + 4字节校验码 + // + Validation 结构体（有效期、MaxDepth等） +}; + +// 上级（超管）的哈希标识 +char g_UpperHash[_MAX_PATH] = { + // MASTER_HASH_STR 标记 + // + 上级的64字节哈希 +}; +``` + +### 11.4 这种模式的优势 + +| 优势 | 说明 | +|------|------| +| **代码透明** | 核心功能源码公开，客户可审计确保无后门 | +| **自由定制** | 开源部分可根据需求自由修改和扩展 | +| **技术学习** | 客户可以学习项目的技术实现，提升自身能力 | +| **授权安全** | 授权模块闭源+多点校验，难以破解 | +| **版本独立** | 客户可以维护自己的分支版本，不依赖上游更新 | +| **社区贡献** | 开源部分促进社区贡献，推动项目发展 | + +### 11.5 授权与源码的关系 + +``` +源码结构： +━━━━━━━━ + + SimpleRemoter/ + ├── server/ ← 开源：控制端主程序 + ├── client/ ← 开源：受控端程序 + ├── common/ ← 开源：公共模块 + ├── linux/ ← 开源：Linux 客户端 + └── SimplePlugins/ ← 部分闭源：授权验证模块（预编译库） + + +没有 generated_hash.h： +━━━━━━━━━━━━━━━━━━━━━ + + 源码可以编译 → 程序可以运行 → 但功能受限 + + • 无法通过授权验证 + • 无法连接上级 + • 无法生成下级 + • 仅供学习研究 + + +有 generated_hash.h： +━━━━━━━━━━━━━━━━━━━━ + + 源码编译后 → 程序完整可用 → 可商业运营 + + • 授权验证通过（多点校验） + • 可以连接上级续期 + • 可以生成下级控制端（根据 MaxDepth） + • 可以管理受管设备 +``` + +### 11.6 超管生成授权的流程 + +超管通过 `工具 → 生成主控` 功能为客户生成授权： + +``` +┌────────────────────────────────────────────────────────────┐ +│ 生成主控程序 │ +├────────────────────────────────────────────────────────────┤ +│ │ +│ 1. 输入当前主控的密码（验证超管身份） │ +│ │ +│ 2. 输入可生成的最大层数 (MaxDepth) │ +│ • 0 = 叶子节点，不能生成下级 │ +│ • N = 可以生成 N 层下级 │ +│ │ +│ 3. 输入新主控程序的密码 │ +│ │ +│ 4. 输入使用天数（有效期） │ +│ │ +│ 5. 选择保存位置 │ +│ │ +│ 生成结果： │ +│ • YAMA.exe - 可直接使用的控制端程序 │ +│ • generated_hash.h - 源码编译所需的哈希文件 │ +│ │ +└────────────────────────────────────────────────────────────┘ +``` + +### 11.7 安全性保障 + +| 安全措施 | 说明 | +|---------|------| +| **哈希绑定** | generated_hash.h 包含密码哈希，无法伪造 | +| **HMAC 验证** | 包含上级签名的 HMAC，验证授权来源 | +| **有效期内嵌** | Validation 结构体包含过期时间 | +| **层级限制** | MaxDepth 控制可生成的下级层数 | +| **上级标识** | g_UpperHash 标识上级身份，防止篡改 | + +--- + +## 十二、适用场景 + +### 12.1 推荐使用场景 + +| 场景 | 说明 | +|------|------| +| **IT 运维外包** | 为多个客户提供远程技术支持 | +| **连锁企业管理** | 总部管理各分店的设备 | +| **教育机构** | 机房管理、远程教学 | +| **软件分销** | 代理商发展下级渠道 | +| **技术培训** | 远程实操指导 | + +### 12.2 客户类型与推荐方案 + +| 客户类型 | 技术能力 | 推荐方案 | +|---------|---------|---------| +| **普通用户** | 无编程基础 | 直接使用生成的 EXE + FRP 代理 | +| **技术用户** | 有编程基础 | 获取源码 + generated_hash.h 自行编译 | +| **开发商** | 专业开发团队 | 基于源码深度定制，发展自己的产品线 | + +--- + +## 十三、联系方式 + +如需购买授权或咨询详情，请联系： + +- **QQ**: 962914132 +- **Telegram**: @doge_grandfather + +--- + +**SimpleRemoter 多层授权架构** — 让您的远程管理业务更简单、更安全、更经济。 + +*技术架构：ECDSA + HMAC 双重验证 | FRP 内网穿透 | 设备绑定 | 自动续期* + +*商业模式：部分开源 + 授权闭源 | 支持源码定制 | 灵活分销体系*