This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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 授权文件，方便分发：

{
    "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 端口自动管理

[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: 授权过期后会发生什么？

答：

您给客户续期后，客户的授权自动更新
客户的下级下次连接时自动获取新的有效期
整个过程无需手动操作

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 文件结构

// Auto-generated hash file for lower-level agent
// Generated at: 2026-04-03 12:00:00

#pragma once

#include <windows.h>
#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 内网穿透 | 设备绑定 | 自动续期

商业模式：部分开源 + 授权闭源 | 支持源码定制 | 灵活分销体系