我们必须承认，乌克兰战争是一个非常复杂的国际事件，它牵动着全球舆论，很多国家和个人对此都有立场和情感。然而，将政治因素引入技术领域，特别是开源这种基于全球协作的项目中，难免会导致更多的分歧和对立。封禁俄罗斯开发者不仅可能影响开源项目的质量和进展，还可能破坏开源社区的包容性，甚至削弱这一技术领域长期以来形成的多边合作机制。

从现实出发，制裁和封禁措施本身或许能够带来短期的压力，但从长远来看，技术的进步和创新依赖于跨国界的协作与共享。开源世界的成功正是因为它超越了政治、种族和国界，为全世界的开发者提供了一个平等的舞台。将某个国家的开发者排除在外，不仅是在打击个体的贡献，更是对全球技术生态的破坏。

因此，我认为Linus的这一决定虽然在当前的国际形势下可以理解，但从维护全球开源生态的长远利益来看，恐怕并不是最佳的选择。技术合作需要保持相对的独立性，不能被政治因素过多干扰，否则最终可能伤害的是整个行业的健康发展。希望开源社区能够冷静思考，找到一种既能够表达立场又不损害合作精神的解决方案。

通过Follow认证十分简单，首先在Follow上获得需要认证的暗号

此处我选择最简单的修改插件模版的方式，我使用的是atom模版，所以修改atom.xml

随便找个地方把暗号插入即可

完成后再次部署，查看网站的RSS订阅是否已经存在这个暗号了

完成后按下Follow里的认证，无内鬼，暗号正确，就通过了

• 安装 hexo-generator-feed 插件

1

npm install hexo-generator-feed

第二步

• 在 Hexo 博客配置文件 _config.yml 中配置上述插件的 hub 项为 Google PubSubHubbub Hub

1
2

feed:
  hub: https://pubsubhubbub.appspot.com

第三步

• 在部署 Hexo 静态博客的相关站点设置 Webhook, 此处以 GitHub 为例, 在站点仓库新建一个 Webhook

• Payload URL 的填写格式为

1
2
3
4

https://pubsubhubbub.appspot.com/publish?hub.mode=publish&hub.url=站点RSS链接

# 以本站为例
https://pubsubhubbub.appspot.com/publish?hub.mode=publish&hub.url=https://sekibetu.com/atom.xml

• Content type 选择 application/x-www-form-urlencoded

• 在 GitHub 中还可以设置各种触发 Webhook 的方式，因为 Hexo 博客是静态网页，我们可以选择 Page builds , 这样每次站点更新后就会触发 Webhook

第四步

• 做完上一步之后就大功告成了, 可以在 Inoreader 等支持 PubSubHubbub 协议的 RSS 订阅软件中查看自己的站点是不是已经实时推送了

• 经过测试，本文在站点更新后也是实时推送了

第一步

• 参照以下文章安装 Magisk

• https://sekibetu.com/magisk01.html

第二步

• 参照以下文章的第二步，在 Magisk 中刷入对应 Zygisk 版本的 LSPosed 框架

• https://sekibetu.com/tiktok01.html

第三步

• 下载 MagiskTrustUserCerts 并在 Magisk 中刷入

• 重启手机

第四步

• 安装 JustTrustMe 模块(用来绕过 SSL Pinning)，并在 LSPosed 中启用，模块作用域指定为 FGO

第五步

• 下载安装 Fiddler Classic 或 mitmproxy

• 启动 Fiddler Classic 或 mitmproxy 并进行一些基础设置，以下是 Fiddler Classic 的基础设置， mitmproxy 并不需要特别设置即可使用，我是通过 python 的 pip install mitmproxy 安装的，所以直接在命令行输入 mitmweb 启动

• 通过 ipconfig 程序找到你的本地局域网 IPv4 地址

• 将其填入手机 WLAN 中的代理设置并保存，端口号为 Fiddler Classic 或 mitmproxy 的代理端口，默认为 8888 和 8080

• 使用手机浏览器访问上述 IP 与端口并点击 FiddlerRoot certificate 下载 Fiddler Classic 的证书

• 或访问 mitm.it 下载 mitmproxy 的证书

• 从系统设置中安装下载好的证书，以小米的 MIUI 系统为例，在 设置 — 密码与安全 — 系统安全 — 加密与凭证 — 安装证书 — CA证书

• 安装完证书重启手机，第三步中的证书提权模块 MagiskTrustUserCerts 会在重启的过程中将安装完的用户证书复制到 root 证书目录以提权

第六步

• 登录 FGO 使 Fiddler Classic 或 mitmproxy 抓到用户的数据

• 国服一般会在 line3-s2-bili-fate.bilibiligame.net/rongame_beta/rgfate/60_1001/ac.php 这样的路径抓到一个大小较大的包，保存抓到的数据的 Response Body

• 将数据导入 Chaldea 就可以愉快地规划素材刷取了

• OpenSSH

  • 优点：开源，跨平台，各大系统默认集成，不需要安装
  • 缺点：使用过程全靠手打命令行参数，SFTP 的使用繁琐
  • 个人推荐度：⭐

• PuTTY + WinSCP

  • 优点：开源
  • 缺点：界面丑，使用时 WinSCP 不能同步当前 PuTTY 所在目录
  • 个人推荐度：⭐⭐

• Termius

  • 优点：跨平台，有手机端
  • 缺点：商业闭源，SFTP 功能需付费
  • 个人推荐度：⭐⭐

• Visual Studio Code

  • 优点：跨平台，易于编辑代码
  • 缺点：终端界面过小，浏览服务器目录的方式逆天，需要频繁重新输入 passphrase
  • 个人推荐度：⭐

• Xshell

  • 优点：功能齐全，支持 SFTP
  • 缺点：商业闭源
  • 个人推荐度：⭐⭐⭐

• WindTerm

  • 优点：跨平台，功能齐全，支持 SFTP，内存使用较少，使用流畅
  • 缺点：逐渐开源
  • 个人推荐度：⭐⭐⭐⭐

• Electerm

  • 优点：开源，跨平台，功能齐全，支持 SFTP，可查看服务器运行信息
  • 缺点：内存使用较多，界面 UI 较为卡顿，不能使用本地编辑器打开文件，长时间使用会断开连接
  • 个人推荐度：⭐⭐⭐

• Tabby

  • 优点：开源，跨平台，功能齐全，支持 SFTP，使用还算流畅
  • 缺点：内存使用较多，SFTP 目录同步需要 配置
  • 个人推荐度：⭐⭐⭐⭐

个人总结：

• 使用 SSH 协议连接服务器是一个较为敏感的操作，应避免使用闭源软件，但 WindTerm 的使用体验极佳，是个特例，如果在未来完全开源，我将会优先选择它

• Tabby 与 Electerm 因占用大量内存而成为了难兄难弟，如果在服务器上安装一个 btop ，则 Tabby 优于 Electerm ，我目前也正在使用 Tabby

• PuTTY 与 WinSCP 的组合是我的 Plan B

• OpenSSH 很纯真，很朴素

• 参照以下文章安装 Magisk
• https://sekibetu.com/magisk01.html

第二步

• 在 Magisk 设置中启用 Zygisk (关于什么是 Zygisk 请看 这篇文章 和 这个公告 )

• 下载对应 Zygisk 的 LSPosed 版本并在 Magisk 中刷入，然后重启手机

第三步

• 安装 TikTok

第四步

• 安装可以修改手机 SIM 卡信息的相关模块( 应用变量、应用伪装、Thanox 等)，本文以 源计划 模块做演示

• 在 LSPosed 中激活上述模块并指定模块作用域为 TikTok

第五步

• 在 源计划 模块 APP 中搜索 TikTok 并进入详细设置界面

• 修改 SIM信息 中的 SIM厂商 、 SIM国际 和 SIM名称 (不同模块有不同的叫法)，将 SIM 卡伪装成非大陆 SIM 卡即可

第六步

• 修改手机的地区，以 MIUI 系统为例，进入 设置 —— 更多设置 —— 地区 ，设置成中国以外的国家或者地区

• 修改手机的时区，进入 设置 —— 更多设置 —— 日期和时间 ，关闭 自动设置时区 ，进入 选择时区 选择一个非大陆的时区即可，推荐选择马来西亚、台湾、香港等和大陆同一个时区的国家或者地区，这样不会影响手机的时间

第七步

• 保证你的网络环境能够访问 TikTok 官网

• 打开 TikTok 开始看视频吧，账号登录、点赞、收藏、关注、评论都可正常使用

Magisk 官方教程指路：https://topjohnwu.github.io/Magisk/install.html

本文仅为官方教程中最通用的一种方法的个人实践过程(Ramdisk、vbmeta 验证和三星手机的问题还请自行查阅上述官方教程)

食材准备：

• 手机一部，本文以 红米 K30Pro (MIUI 13 Android 12) 做演示

• 电脑一台，本文以 Windows 11 系统 做演示

• USB 线一根

厨具准备：

• Android SDK Platform-Tools

• Google USB

• Magisk

烹饪步骤：

• 通过小米官方的 解锁工具 解锁手机的 BootLoader (不同的厂商有不同的解锁方式，也有一些厂商不支持解锁 BootLoader)

• 把下载好的 Android SDK Platform-Tools 压缩包解压到一个文件夹中

• 【可选步骤】将上述文件夹的路径加入到系统环境变量以使 adb 、fastboot等程序能够在任意位置调用(如果不进行此处步骤，则下述步骤中的 cmd 和 powershell 7 请在上述 Android SDK Platform-Tools 解压后的文件夹目录中运行，并替换 adb 和 fastboot 指令为 .\adb.exe 和 .\fastboot.exe 执行)

• 通过手机品牌官网下载或者以抓包的方式获取手机的系统安装包并解压获得 boot.img 文件

• 在手机上安装 Magisk

• 将上述步骤获取到的 boot.img 文件传输到手机中，并用 Magisk 对其进行修补

• 将修补后的 magisk_patched-25000_XXXXX.img 文件传输回电脑

• 将手机通过 USB 连上电脑并启用手机的 USB 调试模式，然后设置为文件传输模式(各品牌手机不同，小米手机可以通过 我的设备 —— 全部参数 —— 多次点击 MIUI版本 开启开发者模式，在 更多设置 —— 开发者选项 中启用 USB调试 选项)

• 【可选步骤，适用于 USB 连接有问题的人】下载 Google USB 驱动压缩包并解压到一个文件夹后安装

• 在电脑上打开 cmd 或者 powershell 7 ，输入 adb devices 回车执行查看是否能检测到手机，如果没有检测到则返回上一步安装 Google USB 驱动

• 继续输入 adb reboot bootloader 回车执行使手机进入 fastboot 模式(也可以在手机关机状态下，同时按住 电源 和 音量+ 键几秒后进入)

• 继续输入 fastboot flash boot 路径\magisk_patched-25000_XXXXX.img 回车执行刷入通过 Magisk 修补后的上述文件

• 继续输入 fastboot reboot 或者长按电源键关机后重启手机，至此，Magisk 的安装就完成了

关于系统升级

• 看了以上的安装过程可以得知的一点是，Magisk 是通过修改 boot.img 生效的，所以在升级系统的时候，只要让升级包里的 boot.img 被 Magisk 修补一遍，再升级系统，就可以让 Magisk 在升级系统后不失效

以以下路由配置为例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60

{
  "dns": {
    "servers": ["8.8.8.8", "localhost"]
  },
  "outbounds": [
    {
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "users": [
              {
                "id": "xxx-x-x-x-xx-x-x-x-x"
              }
            ],
            "address": "1.2.3.4",
            "port": 10086
          }
        ]
      },
      "streamSettings": {
        "network": "tcp"
      },
      "tag": "proxy"
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ],
  "inbounds": [
    {
      "domainOverride": ["http", "tls"],
      "port": 1086,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true,
        "ip": "127.0.0.1"
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["8.8.8.8"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

内置 DNS 用 8.8.8.8 做首选服务器，localhost 作备用，路由中首先来一条规则让 8.8.8.8 的流量一定走 proxy，匹配了 geosite:cn 中的域名的请求走 direct，如果没匹配任何规则，则走主 outbound，也即 outbounds 中的第一个，也即 proxy。

同样设置系统代理至 V2Ray 的 SOCKS inbound 127.0.0.1:1086，再来考虑浏览器做请求的过程，经过上面几个例子，可以看到很多步骤其实是一样的，所以后续例子中会简化一些：

S4

1. 假设浏览器请求 https://www.bilibili.com
2. 浏览器发 SOCKS 请求到 V2Ray
3. 请求来到 V2Ray 的 inbound，再到路由过程
4. 很明显 www.bilibili.com 这个域名包括在 geosite:cn 中，走 direct
5. Freedom outbound (direct) 对 www.bilibili.com 发起 TCP 连接
6. Freedom outbound 解析域名，因为这次没有用 UseIP，用的是系统 DNS
7. 直接发 DNS 请求到 114.114.114.114
8. 得到结果后可以跟 Bilibili 服务器建立连接，准备代理浏览器发过来的 HTTPS 流量

S5

1. 再假设浏览器请求 https://www.google.com
2. 浏览器发 SOCKS 请求到 V2Ray
3. 请求来到 V2Ray 的 inbound，再到路由过程
4. www.google.com 不在 gesoite:cn，也没匹配任何规则，本来应该直接走主 outbound: proxy，但因为我们用了 IPIfNonMatch 策略，V2Ray 会去尝试使用内置的 DNS 把 www.google.com 的 IP 解析出来
5. V2Ray 使用内置 DNS 向 8.8.8.8 发起针对 www.google.com 的 DNS 请求，这个请求的流量将会是 UDP 流量
6. 内置 DNS 发出的 DNS 请求会按路由规则走，因为 8.8.8.8 匹配了路由中的第一条规则，这个 DNS 请求的流量会走 proxy
7. proxy 向远端代理服务器发起 TCP 代理连接（因为 “network”: “tcp”）
8. 建立起 TCP 连接后，proxy 向远端代理服务器发出 udp:8.8.8.8:53 这样的代理请求
9. 远端服务器表示接受这个代理请求后，proxy 用建立好的 TCP 连接向远端服务器发送承载了 DNS 请求的 UDP 流量（所以 V2Ray/VMess 目前是 UDP over TCP）
10. 远端代理服务器接收到这些承载 DNS 请求的 UDP 流量后，发送给最终目标 udp:8.8.8.8:53
11. 8.8.8.8 返回给远端代理服务器 DNS 结果后，远端代理服务器原路返回至本地 V2Ray 的内置 DNS，至此，从步骤 5 ~ 11，整个 DNS 解析过程完成。
12. 接上面步骤 4，V2Ray 得到 www.google.com 的 IP，再进行一次规则匹配，很明显路由规则中没有相关的 IP 规则，所以还是没匹配到任何规则，最终还是走了主 outbound: proxy
13. proxy 向远端代理服务器发起 TCP 代理连接（因为 “network”: “tcp”）
14. 连接建立后，因为 proxy 中所用的 VMess 协议可以像 SOCKS 那样把域名交给代理服务器处理，所以本地的 V2Ray 不需要自己解析 www.google.com，把域名放进 VMess 协议的参数中一并交给代理服务器来处理
15. 远端的 V2Ray 代理服务器收到这个代理请求后，它可能自己做域名解析，也可能继续交给下一级代理处理，只要后续代理都支持类 SOCKS 的域名处理方式，这个 DNS 请求就可以一推再推，推给最后一个代理服务器来处理，这个超出本文范围不作讨论，反正这个域名不需要我们本地去解析
16. 远端代理服务器最后会发出针对 www.google.com 的 DNS 请求（至于究竟是如何发，发到哪个 DNS 服务器，我们不一定能知道，也不关心这个）
17. 远端代理服务器得到 DNS 结果后，可以真正地向 Google 的服务器建立 TCP 连接 18. 远端的 V2Ray 做好准备后告诉本地 V2Ray 连接建立好了，可以传数据了
18. 本地 V2Ray 就告诉浏览器连接好了，可以传数据了，浏览器就可以把 HTTPS 流量顺着这个代理链发送至 Google 的服务器

在上面 S5 中，步骤 5 ~ 11 做了次 DNS 请求，采用代理转发 DNS 请求流量的方式，而在步骤 14 中，又说可以不解析域名，交给远端服务器来解析，这两者其实并不冲突。一般来说，前者的处理方式就是实实在在的 UDP 流量代理而已，后者一般叫作远程 DNS 解析。用了 IPIfNonMatch ，对域名做一次 DNS 解析要经过 5 ~ 11 这么多步骤，看起来效率很慢，但如果代理服务器不慢的话，这个过程一般是很快的，最重要的是 V2Ray 内置 DNS 对 DNS 结果有一个缓存，所以并不需要每次都去做 DNS 请求。不管怎么说，毕竟还是做了额外的事情，而且有可能涉及到一个 UDP over TCP 的代理请求，的确会相对地慢点。

DNS 处理流程

若当前要查询的域名：

• 命中了 hosts 中的「域名 - IP」、「域名 - IP 数组」映射，则将该 IP 或 IP 数组作为 DNS 解析结果返回。
• 命中了 hosts 中的「域名 - 域名」映射，则该映射的值（另一个域名）将作为当前要查询的新域名，进入 DNS 处理流程，直到解析出 IP 后返回，或返回空解析。
• 没有命中 hosts，但命中了某（几）个 DNS 服务器中的 domains 域名列表，则按照命中的规则的优先级，依次使用该规则对应的 DNS 服务器进行查询。若命中的 DNS 服务器查询失败，或 expectIPs 不匹配，则使用下一个命中的 DNS 服务器进行查询；否则返回解析得到的 IP。若所有命中的 DNS 服务器均查询失败，此时 DNS 组件：
  • 默认会进行 「DNS 回退（fallback）查询」：使用「上一轮失败查询中未被使用的、且 skipFallback 为默认值 false 的 DNS 服务器」依次查询。若查询失败，或 expectIPs 不匹配，返回空解析；否则返回解析得到的 IP。
  • 若 disableFallback 设置为 true，则不会进行「DNS 回退（fallback）查询」。
• 既没有命中 hosts，又没有命中 DNS 服务器中的 domains 域名列表，则：
  • 默认使用「skipFallback 为默认值 false 的 DNS 服务器」依次查询。若第一个被选中的 DNS 服务器查询失败，或 expectIPs 不匹配，则使用下一个被选中的 DNS 服务器进行查询；否则返回解析得到的 IP。若所有被选中的 DNS 服务器均查询失败，返回空解析。
  • 若「skipFallback 为默认值 false 的 DNS 服务器」数量为 0 或 disableFallback 设置为 true，则使用 DNS 配置中的第一个 DNS 服务器进行查询。查询失败或不匹配 expectIPs 列表，返回空解析；否则返回解析得到的 IP。

Reference

漫谈各种黑科技式 DNS 技术在代理环境中的应用(作者@TachyonDevel)

DNS 域名解析 | V2Fly.org

1

Hash算法(Hash算法(密码)+盐)

1、使用慢 Hash 算法可以拖延破解时间【重要】

2、使用和 Hash 函数输出的字符串等长的盐值，比如 SHA256 算法的输出是 256bits(32 bytes)，那么盐值也至少应该是 32 个随机字节【重要】

3、使用随机盐还是固定盐，取决于程序是否被泄露，

一般认为，数据库是第一个被泄露的，那么随机盐是直接被拿走了，而嵌入于程序中的固定盐是安全的；

但是，能入侵到数据库的黑客一般程序也顺手可以拿走了，所以固定盐反而降低了后续彩虹表的建立时间，

所以使用随机盐虽然免不了随机盐、密码和算法一起被泄露，但能增加彩虹表攻击的成本(每一个盐都需要建立一个彩虹表，能增加一丢丢破解时间)

我认为默认使用随机盐是好事，但是有些特殊情况下使用固定盐反而能取胜

git 是 snapshot 式保存手段(每一次 commit 都是完整的 snapshot)，但又偏向于增量式保存，举例：
现有以下两个文件已成为第一次 commit
A.txt
B.txt
那么 git 会将其分为若干个 git 对象，并将这些对象进行切割后压缩保存(delta)，
当我修改了 A.txt，再次 commit 时，
git 不会存储改动后的整个 A.txt，
而是存储一个指向 B.txt 的指针加上 A.txt 改动的部分，这些就是新增的 git 对象，git 接着将其按一定规则切割后压缩保存(delta)
总的来说，git 对象偏向于内容，而 delta 偏向于二进制分段压缩包，

每次 commit 的 delta 部分就像是彩虹六号 Y5S4 赛季这次更新的时候，游戏本体就 70G 左右，补丁却需要下载 60G，
因为彩虹六号把材质文件都封装进了 delta 文件，这类文件特别大，根目录下最大的单个材质包文件可达 28G，即使是改动了其中的一张图片，也需要整个重新下载,而 git 的包切得很小，可重复利用的 delta 文件多，每次 commit 就能省下不少空间

Total A (delta B), reused C (delta D) 中的 A、B、C、D 意思分别为

A、本次打包总计有 A 个 git 对象

[每个文件的每一次改动都会创造出一个新的内容级别的对象]，

B、从第一次 commit 以来的二进制分段压缩包级别的增量改动包 B 个

[与内容级别的对象不同点是将内容级别的对象按一定规则切割成分段压缩包]

C、有 C 个可重复使用的 git 对象

D、有 D 个二进制分段压缩包级别的增量改动包可重复使用而不需要重新打包

git config --global user.name "xxx" # 配置用户名
git config --global user.email "xxx@xxx.com" # 配置邮箱
git config --global color.ui true # git 命令自动着色
git config --global color.status auto
git config --global color.diff auto
git config --global color.branch auto
git config --global color.interactive auto

git config --global http.https://github.com.proxy socks5://127.0.0.1:2080 # 设置代理

git config --global --unset http.proxy # 取消代理
git clone XXX.git # clone 远程仓库
git status # 查看当前改动
git add A # 提交 A 文件至 index
git add . # 提交所有文件更改
git commit -m 'xxx' # 提交
git commit --amend -m 'xxx' # 合并上一次提交（用于反复修改）
git commit -am 'xxx' # 将 add 和 commit 合为一步
git rm xxx # 删除 index 中的文件
git rm -r * # 递归删除
git log -n # 显示 n 行提交日志
git log --stat # 显示提交日志及相关变动文件
git show dfb02e6e4f2f7b573337763e5c0013802e392818 # 显示某个提交的详细内容
git show dfb02 # 同上，可只用 commit ID 的前几位
git show HEAD # 显示 HEAD 提交日志
git show HEAD^ # 显示 HEAD 的父（上一个版本）的提交日志 ^^为上两个版本 ^5 为上 5 个版本

git show main@{yesterday} # 显示 main 分支昨天的状态

git tag # 显示已存在的 tag
git tag -a v2.0 -m 'xxx' # 增加 v2.0 的 tag
git show v2.0 # 显示 v2.0 的日志及详细内容
git log v2.0 # 显示 v2.0 的日志
git diff # 显示所有未添加至 index 的变更
git diff --cached # 显示所有已添加 index 但还未 commit 的变更
git diff HEAD^ # 比较与上一个版本的差异
git diff HEAD -- ./lib # 比较与 HEAD 版本 lib 目录的差异
git diff origin/main main # 比较远程分支 main 上有本地分支 main 上没有的
git diff origin/main main --stat # 只显示差异的文件，不显示具体内容
git remote add origin XXX.git # 增加远程定义（用于 push/pull/fetch）
​git branch # 显示本地分支
​git branch --contains 50089 # 显示包含提交 50089 的分支
​git branch -a # 显示所有分支
​git branch -r # 显示所有原创分支
​git branch --merged # 显示所有已合并到当前分支的分支
​git branch --no-merged # 显示所有未合并到当前分支的分支
​git branch -m main main_copy # 本地分支改名
​git checkout -b main_copy # 从当前分支创建新分支 main_copy 并切换
​git checkout -b main main_copy # 上面的完整版
​git checkout branch # 切换已存在的 branch 分支
​git checkout --track branch # 切换远程分支 branch 并创建本地跟踪分支
​git checkout v2.0 # 切换版本 v2.0
​git checkout -b dev origin/dev # 从远程分支 dev 创建新本地分支 dev 并切换
​git checkout -- README # 检出 head 版本的 README 文件（可用于修改错误回退）
​git merge origin/main # 合并远程 main 分支至当前分支
​git cherry-pick ff44785404a8e # 合并提交 ff44785404a8e 的修改
​git push origin dev:main # 将本地的 dev 分支 push 到远程的 main 分支

git push origin --delete branch # 删除远程仓库的 branch 分支

git push origin :branch # 同上
​git push --tags # 把所有 tag 推送到远程仓库
​git fetch # 获取所有远程分支（不更新本地分支，另需 merge）
​git fetch --prune # 获取所有原创分支并清除服务器上已删掉的分支

git --set-upstream-to=origin/main main # 将 main 分支的远程分支设为 origin/main

git pull --rebase origin main # rebase 式 pull 远程 origin 代码到本地 main 分支(需要与上一步结合确定 pull 哪个分支)

git pull origin main # 获取远程 origin 的分支并 merge 到本地 main 分支
​git mv README README2 # 重命名文件 README 为 README2
​git reset --hard HEAD # 将当前版本重置为 HEAD（通常用于 merge 失败回退）
​git rebase main patch # 换底，将 patch 分支的基准换成 main 分支
​git branch -d branch # 删除本地分支 branch（本分支修改已合并到其他分支）
​git branch -D branch # 强制删除本地分支 branch
​git ls-files # 列出 git index 包含的文件
​git show-branch # 图示当前分支历史
​git show-branch --all # 图示所有分支历史
​git whatchanged # 显示提交历史对应的文件修改
​git revert dfb02e6e4f2f7b573337763e5c0013802e392818 # 撤销提交 dfb02e6e4f2f7b573337763e5c0013802e392818
​git ls-tree HEAD # 内部命令：显示某个 git 对象
​git rev-parse v2.0 # 内部命令：显示某个 ref 对于的 SHA1 HASH
​git reflog # 显示所有提交，包括孤立节点

git log --pretty=format:'%h %s' --graph # 图示提交日志
git stash # 暂存当前修改，将所有文件置为 HEAD 状态
git stash list # 查看所有暂存
git stash show -p stash@{0} # 参考第一次暂存
git stash apply stash@{0} # 应用第一次暂存
git grep "delete from" # 文件中搜索文本“delete from”
git gc # 清理不必要的文件并优化本地存储库

git rm -r -f --cached . # 删除缓存区而不删除本地文件(可以配合.gitignore 使用)

Docker

基础命令

服务相关命令

• systemctl start docker
• systemctl stop docker
• systemctl restart docker
• systemctl status docker
• systemctl enable docker 为 docker 服务设置开机自启

镜像相关命令

• docker images 查看本地镜像
• docker search 镜像名称 搜索镜像
• docker pull 镜像名称:版本号 从 docker 仓库拉取某版本的镜像到本地
• docker build 创建 dockerfile 镜像

容器相关命令

• docker ps -a 查看所有本地容器

• 举例：docker run -it --name=cl centos:7 /bin/bash 创建一个名为 cl 的 centos7 的容器并以 bash 这个 shell 进入交互式界面

  • exit 可以退出容器但会使带-t 参数的交互式容器停止，所以要避免-t 参数的使用，但是可以使用^p^q 来退出而不结束容器

• docker run -id --name=cl centos:7 创建一个名为 cl 的 centos7 的容器在后台运行(守护式容器)

• docker attach 容器名

  • docker exec 容器名 用此命令进入容器，退出后容器不会停止

• docker start 容器名 重新启动已存在的容器

• docker stop 容器名 关闭容器

• 删除所有容器的示例命令(慎用)：docker rm ‘docker ps -aq’

• docker inspect 容器名 查看容器信息

数据卷(挂载)

docker run … -v 宿主机目录 : 容器内目录 -v 宿主机目录 : 容器内目录

• 目录必须是绝对路径
• 如果目录不存在会自动创建
• 可以挂载多个数据卷

数据卷容器

• 使用方法

  • name=A -v /volume
  • –volumes-from A
  • –volumes-from A
  • 即使删除了 A，其余的数据卷也挂在于宿主机，不受影响

• 作用

  • 容器数据持久化(数据隔离)
  • 客户端和容器数据交换
  • 容器间数据交换

应用部署

MySQL 示例

• docker run -id \ 守护进程
  -p 3307:3306 \ 映射端口为 3307 与宿主机通信
  –name=mysql \ 镜像名
  -v $PWD/conf:/etc/mysql/conf.d \ 挂载配置目录
  -v $PWD/logs:/logs \ 挂载日志目录
  -v $PWD/data:/var/lib/mysql \ 挂载数据目录
  -e MYSQL_ROOT_PASSWORD=123456 \ 密码环境
  mysql:5.6 镜像和版本

Tomcat 示例

• docker run -id --name=tomcat
  -p 8080:8080
  -v $PWD:/usr/local/tomcat/webapps
  tomcat

Nginx 示例

• docker run -id --name=nginx
  -p 80:80
  -v $PWD/conf/nginx.conf:/etc/nginx/nginx.conf
  -v $PWD/logs:/var/log/nginx
  -v $PWD/html:/usr/share/nginx/html
  nginx

Redis 示例

• docker run -id --name=redis -p 6379:6379 redis
• ./redis-cli.exe -h 主机 IP -p 端口

Dockerfile

结构

• Docker 镜像是由特殊的文件系统叠加而成，底层直接沿用宿主机的 bootfs
• 第二层为 root 文件系统 rootfs，称为 base image
• 可以再往上叠加其他镜像文件

制作镜像

• 容器转镜像

  • docker commit 容器 id 镜像名称 : 版本号
  • docker save -o 压缩文件名称 镜像名称 : 版本号
  • docker load -i 压缩文件名称

• dockerfile

服务编排 Compose

微服务需要部署多个实例，人工进行过于复杂

使用流程

• 安装 docker-compose
• 编写 docker-compose.yml
• docker-compose up -d 启动即可

私有仓库

搭建流程

• docker pull registry
• docker run -id --name=registry -p 宿主端口:容器端口 registry
• 访问服务器 IP:端口号/v2/_catlog，查看是否有输出{“repositories”:[]}
• 修改/etc/docker/daemon.json
• 添加{“insecure-registries”:[“服务器 IP:端口号”]}
• 重启 docker 服务 systemctl restart docker && docker start registry

上传流程

• docker tag 镜像名:版本 服务器 IP:端口号/镜像名:版本
• docker push 服务器 IP:端口号/镜像名:版本

拉取流程

• docker pull 服务器 IP:端口号/镜像名:版本

删除策略

定时删除

• 定时删除，CPU 占用大

惰性删除

• 过期数据二次访问后才删除，内存占用大

定期删除

• 随机抽查删除，hz 值决定了 CPU 和内存哪个占用大

淘汰策略

• 内存不足时按策略删除

  • maxmemory ?mb 最大可用内存，默认为 0 不限制，一般设置物理机的 50%以上

  • maxmemory-samples count 每次随机删除的数据个数

  • maxmemory-policy policy 删除策略

    • volatile 易失数据

      • volatile-lru 按最后一次使用时间
      • volatile-lfu 按最近使用次数
      • volatile-ttl 按即将过期的数据
      • volatile-random 随机

    • allkeys 全库数据

      • allkeys-lru 按最后一次使用时间
      • allkeys-lfu 按最近使用次数
      • allkeys-random 随机

    • no-enviction 放弃数据驱逐

主从复制

建立连接的流程

• 设置 master 地址和端口并保存
• 建立 socket 连接
• 发送 ping 命令(定时器任务)
• 身份验证
• 发送 slave 端口信息

数据同步

• 全量复制

  • 发送指令 psync2
  • 执行 bgsave
  • 第一个 slave 连接时创建命令缓冲区
  • 生成 RDB 文件通过 socket 发给 slave
  • 接收 RDB，清空数据，执行恢复过程

• 部分复制

  • 发送命令告知 RDB 已经恢复完成
  • 发送复制缓冲区信息
  • 接收信息，执行 bgrewriteaof，恢复数据

• 心跳机制

  • master 心跳

    • 内部指令 PING
    • 周期 repl-ping-slave-period 默认 10 秒
    • INFO replication 获取 slave 最后一次连接时间间隔，lag 项维持在 0 或 1 视为正常

  • slave 心跳

    • 内部指令 REPLCONF ACK {offset}
    • 周期 1 秒
    • 汇报 slave 自己的复制偏移量，获取最新的数据变更指令
    • 判断 master 是否在线

• 注意事项

  • master 数据同步应避开流量高峰期
  • 复制缓冲区太小会导致数据溢出，出现数据丢失并自动进行二次全量复制，死循环 repl=backlog-size ?mb 建议留下 30%~50%的内存用于执行 bgsave 命令和创建复制缓冲区
  • 避免 slave 同步过程服务器响应阻塞或者数据不同步，建议关闭此期间的对外服务 slave-serve-stale-data yes | no
  • 数据同步阶段，master 主动发送命令给 slave，可以理解为是一个客户端
  • 多个 slave 同时对 master 请求同步，RDB 只会有一份，但是带宽压力变大，可以适量错峰但是 RDB 会有多份
  • slave 过多可以采用树状结构，但是数据一致性差

哨兵模式

检测 master 是否宕机，master 宕机后选举 slave 为 master

建立过程配置

• sentinel monitor master_name master_host master_port sentinel_number 设置监听的主服务器信息，sentinel_number 表示参与投票的哨兵数量
• sentinel down-after-milliseconds master_name million_seconds 设置宕机时长，控制是否进行主从切换
• sentinel failover-timeout master_name million_seconds 设置故障切换操作的最大超时时长
• sentinel parallel-syncs master_name sync_slave_number 设置主从切换后，同时进行数据同步的 slave 数量，越大网络资源要求越高，越小同步时间越长

监控阶段

• 检查各个哨兵是否在线
• 先向 master 发 info 查询其信息和名下 slave
• 再向 slave 发 info 查询 slave 具体信息

故障转移阶段

• 单个哨兵监测到 master 无响应（主观下线） SRI_S_DOWN

• 半数哨兵监测到 master 无响应（客观下线） SRI_O_DOWN

• 哨兵选举

• 选举 master 优先级

  • 不在线的

  • 响应慢的

  • 与原来 master 断开连接时间长的

  • 优先原则

    • 优先级
    • offset 偏移量大
    • runid

Cluster 集群

数据存储结构

• 保存流程

  • CRC(key)%16384 计算结果为某台服务器中的槽位地址，该槽位不止存储一个 key，而是大量 key

• 查询流程

  • 各个数据库相互通信，保存各个库中槽位的编号数据
  • 一次查询命中直接返回
  • 一次未命中，告知具体的位置

配置

• cluster-enabled yes|no 是否启用 cluster，加入 cluster 节点
• cluster-config-file filename cluster 配置文件名，该文件会自动生成，尽量手动命名否则会共用
• cluster-node-timeout milliseconds 节点服务响应超时时间
• cluster-migration-barrier min_slave_number master 连接的 slave 最小数量

企业级解决方案

缓存预热

• 现象：启动服务器后立刻宕机
• 解决思路：系统启动前，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

缓存雪崩

• 现象：短时间范围内，大量 key 集中过期导致一系列宕机

• 解决思路

  • 更多的页面静态化处理
  • 构建多级缓存架构
    Nginx 缓存+redis 缓存+ehcache 缓存
  • 检测 Mysql 严重耗时业务进行优化
    对数据库的瓶颈排查：例如超时查询、耗时较高事务等
  • 预警机制
  • 限流、降级

• 具体解决方案

  • 切换为 LFU 淘汰策略
  • 调整过期的时间，使其错峰
  • 超热数据暂时使用永久 key
  • 定期维护（自动+人工）
    对即将过期数据做访问量分析，确认是否延时，配合访问量统计，做热点数据的延时
  • 加锁：慎用！

缓存击穿

• 现象：Redis 中某个高热点 key 过期，该 key 访问量巨大

• 解决方案

  • 增加热点 key 的时间
  • 设置热点 key 为永久
  • 高峰期来临前自动刷新有效期
  • 二级缓存，设置不同的过期时间错峰
  • 分布式锁

缓存穿透

• 现象：黑客大量访问不存在的数据，跳过 redis 直接攻击数据库

• 解决方案

  • 1、对查询结果为 null 的数据进行缓存（长期使用，定期清理），设定短时限，例如 30-60 秒，最高 5 分钟
  • 2、白名单策略
    提前预热各种分类数据 id 对应的 bitmaps，id 作为 bitmaps 的 offset，相当于设置了数据白名单。当加载正常数据时放行，加载异常数据时直接拦截（效率偏低）
    使用布隆过滤器（有关布隆过滤器的命中问题对当前状况可以忽略）
  • 3、实时监控 redis 命中率，提前预防，使用黑名单进行防控
  • 4、key 加密
    问题出现后，临时启动防灾业务 key，对 key 进行业务层传输加密服务，设定校验程序，过来的 key 校验
    ​ 例如每天随机分配 60 个加密串，挑选 2 到 3 个，混淆到页面数据 id 中，发现访问 key 不满足规则，驳回数据访问

Redis: Remote Dictionary Server

三个特点:

• Redis 支持数据持久化. 可以将内存中的数据保持在磁盘中, 重启后可再次使用
• Redis 支持 key-val, list, set, zset, hash 等数据结构存储
• Redis 支持数据备份, master-slave 模式数据备份

零碎基础知识

1. 单进程 (*) 单进程处理客户端的请求, 对读写事件响应是通过 epoll 函数而包装来操作. Redis 实际处理速度完全依靠主进程执行效率
2. 默认 16 个数据库, 类似数组下标从 0 开始, 初始默认使用 0 号库
3. select 切换数据库
4. dbsize 查看当前数据库的 key 的数量
5. flushdb 清空当前数据库
6. flushall 删全部库
7. 统一密码管理, 16 个库同一个密码
8. Redis 索引是从 0 开始
9. 默认端口 6379

Redis 数据类型

五大数据类型

1. String (字符串)
2. Hash (哈希, 类似 Java HashMap)
3. List (列表)
4. Set (集合)
5. Zset (Sorted Set: 有序集合)

String (字符串)

1. 一个 key 对应一个 value
2. 二进制安全. 可以包含任何数据, 包括图片或者序列化对象
3. value 最多可以是 512M

Hash

1. string 类型的 field 和 value 的映射表

List (列表)

1. 底层是一个链表
2. 按照插入顺序排序, 可以在头部或者尾部插入数据

Set

1. string 类型的无序集合, 是通过 HashTable 实现的

Zset (Sorted Set)

1. string 类型的集合
2. 与 Set 不同的是: 每个元素都会关联一个 double 类型的分数
3. Redis 通过分数来为集合中的成员进行从小到大排序
4. zset 成员唯一, 但是分数 (score) 可以重复!

Redis 键 (key)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

key *

# 判断某个 key 是否存在
exists key

# 将 key 移动到另一个库
move key db

# 给 key 设置过期时间
expire key

# 查看还有多长时间 key 过期, -1 表示永不过期, -2 表示已经过期
ttl key

# 移除key的过期时间，即设置回永不过期
persist key

# 查看 key 是什么类型
type key

get k1

# 有对应的键值, 覆盖 value
set k1 v1

# 删除 key
del key

Redis 字符串 (String)

单值单 value

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

set / get / del / append / strlen
incr / decr / incrby / decrby

# 获取指定区间范围的值
getrange key 0 -1

# 范围内设置值 (结果 key 对应的 value 以 'xxx'开头)
setrange key 0 xxx

# 设置过期时间
setex

# set if not exist
setnx

# 设置 / 获取 多个键值对
mset / mget / msetnx

Redis 列表 (List)

单值多 value

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

lpush / rpush / lrange

lpop / rpop

# 按照索引下标获得元素 (从上到下)
lindex

llen

# 删除 n 个 val
lrem key n val

# 截取指定范围的值然后再赋值给 key
ltrim key index1 index 2

# 源列表 -> 目标列表
rpoplpush list1 list2

lset key index value

linsert key before/after val1 val2

性能总结

1. 是一个字符串链表, left, right 都可以插入添加
2. 如果键不存在, 创建新的链表
3. 如果键已存在, 新增内容
4. 如果值完全移除, 对应的键也就消失了
5. 链表操作头尾效率很高, 中间元素效率不高

Redis 集合 (Set)

单值多 value

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

sadd / smembers / sismembers

# 获取集合里元素个数
scard

# 删除集合中元素
srem key value

srandmember key 某个整数

# 随机 pop 元素
spop key

# 将 key1 里的某个值赋值给 key2
smove set01 set02 5

# 差集 / 交集 / 并集
sdiff / sinter / sunion

Redis 哈希 (Hash)

KV 模式不变, 但 V 是一个键值对

1
2
3
4
5
6
7
8
9
10
11
12

hset / hget / hmset / hmget / hgetall / hdel

hlen

# 在 key 里面的某个值的 key
hexists key

hkeys / hvals

hincrby / hincrbyfloat

hsetnx

Redis 有序集合 (Zset)

1
2
3
4
5
6
7
8
9
10
11
12

zadd / zrange (withscores)

# 开始 score1 结束 score2
zrangebyscore key score1 score2
withscore
'(' 不包含
limit 开始下标步, 多少步

# 删除元素
zrem key 某 score 下对应的 value

zcard / zcount key <score_range> / zrank key values

Reference

1. https://zhenye-na.github.io/2019/08/29/redis-cheatsheet.html#redis-%E4%BA%8B%E5%8A%A1

2. https://github.com/LeCoupa/awesome-cheatsheets/blob/master/databases/redis.sh

• 未提交读(Read uncommitted)：能读取到别的事务未提交的数据

• 已提交读(Read committed)：只能读取到别的事务已经提交的数据

• 可重复读(Repeatable)：在读取数据后直接加锁，其他事务无法修改和删除这些数据，但是防不住 insert 的新数据

• 可串行化(Serializable)：读取用读取锁，写入用写入锁，这两个锁互斥，这样能保证数据绝对安全，但是性能低下

• 脏读(Dirty Read)：可以读取到未提交的数据

• 不可重复读(NonRepeatable Read)：在读取完数据后数据又修改并 commit 了，导致第二次读取的数据与第一次数据不一致(重点在修改数据)

• 幻读(Phantom Read)：两次读取期间有新数据加入或者旧数据删除，导致不一致(重点在增删数据)

第一步

首先，我们安装完 python 并且配置好环境变量后，去下载 pyinstxtractor.py 这个工具，他能把 PyInstaller 打包的 exe 文件里包含的依赖库和已编译好的.pyd 或者.pyc 字节码文件给“解压”出来，这其中，.pyd 文件的反编译特别复杂（因为.pyd 其实是已经编译成.c 后封装成类似.dll 的东西了，根本看不出 Python 的源码了），技术力不足的我这部分无能为力，本次讲的是.pyc 的反编译。

1

python pyinstxtractor.py Test.exe

运行工具“解压”完成后，

我们看到目录中生成了一个文件夹：

图中的 Test.exe_extracted 文件夹便是 Test.exe 文件被“解压”后的结果，然后我们找到类型为.pyc 的字节码文件（或者如下图所示的类型为文件的文件）

然后把他们改为后缀名为.pyc 的字节码文件（因为上述工具解压过程无法识别这些二进制的文件所以没有自动改后缀）

【这里剧透下：其实是因为这些字节码文件标头的幻数被人删除了】

第二步

接着，我们开始对上述“解压”出来的已编译的.pyc 字节码文件进行反编译

首先，pip 安装 uncompyle6：https://pypi.org/project/uncompyle6/

1

pip install uncompyle6

然后试着直接使用一次：

1

uncompyle6 Test.pyc

然后我们发现，提示的是“导入错误：Test.pyc 中有无法识别的幻数 227”

这个 227 其实是十六进制的数字，我们用 WinHex 打开 Test.pyc 查看一下：

我们发现，并没有什么特征，我们继续把同目录的 struct 文件打开看一下：

我们发现，这里也有一个“E3”，而十六进制的 E3 恰好就是 227，诶，我们发现，幻数 227 是错误的，说明，在这个 E3 前面，本来应该有一个正确的幻数，在编译成.pyc 字节码文件的过程中，可能被人篡改或者删除了，而我这个情况是被人删除了，那我们手动插入这个数字进去试试：

然后我们再试一次反编译：

提示成功，源码也显示了出来，查看不方便的话可以这样写：

1

uncompyle6 Test.pyc > Test.py

这样根目录就会出现反编译完成的.py 源码文件了

后记

新版本的 pyinstxtractor.py 已经增加了自动补全 python 版本幻数的功能了：

https://github.com/extremecoders-re/pyinstxtractor

批量反编译

笔者又在 github 上找到了一个批量反编译.pyc 字节码文件的脚本：

https://github.com/jazlopez/py-recursive-uncompyle6

这个脚本会自动搜索自身所在的目录及其子目录下的所有.pyc 字节码文件，然后通过安装好的 uncompyle6 进行反编译，不足之处是，反编译后只会把反编译完的.py 源码文件扔在原文件旁，而不是另建文件夹储存。

不过，我们可以修改这个脚本中的 uncompyle_to 参数来指定输出文件夹

1

uncompyle_to = os.path.join(parent, i["dirname"], i["name"])

因为笔者没有这个需求，所以这个代码逻辑的修改就留给读者你了，改完记得去给原项目 PR 哦

​ 以下是全过程记录：

第一步

​ 首先，安装抓包软件 Fiddler Classic，然后准备好一个 fat32 格式的 U 盘，并在里面新建一个文件夹

然后插到光猫上，浏览器输入 192.168.1.1 进入天翼网关

输入光猫背后贴的用户账号密码，就是 useradmin 那个

然后进入存储管理，我们发现，U 盘被识别出来了

这时我们启动 fidder，然后选择下图所示的事前断点

然后手动去点击文件夹目录，你会发现，点不动，点不动就对了

这时去寻找到 cgi-bin/luci/admin/storage/openFolder 这条 URL

然后我们把其中的 U 盘路径改成斜杠，就是进入光猫根目录的意思

最后点击 Run to Completion，执行完毕

再把断点给关了

你会发现，我们已经进入到了光猫的根目录（如果没进去，刷新下页面，应该是登录信息过期了，整个过程再做一遍，手速要快点）

接着我们把这个路径下的文件复制出来到你的 U 盘里

这时候就可以把 U 盘拔了插电脑上了

第二步

​ 拿到设置文件后，我们发现，表面是 xml 格式，但是实际是加密过的二进制文件，这里引用下 52 破解一个大佬的解码猜测过程

https://www.52pojie.cn/thread-1005978-1-1.html

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

function UnZipCofing(Fname: string): string;
var
  ds: TDecompressionStream;
  ms, fs, tmpfs: TMemoryStream;
  ss: TStringStream;
  bufferSize, blockSize, nextOff: LongWord;
begin
  fs := TMemoryStream.Create;
  tmpfs := TMemoryStream.Create;
  ms := TMemoryStream.Create;
  ss := TStringStream.Create('');
  if not FileExists(Fname) then
  begin
    ShowMessage('文件不存在！');
    exit;
  end;
  try
    fs.LoadFromFile(Fname);
    nextOff := 60;
    while nextOff > 0 do
    begin
      fs.Seek(nextOff, soFromBeginning);
  //读取缓冲区大小
      fs.Read(bufferSize, SizeOf(bufferSize));
      bufferSize := Swap32(bufferSize);
  //读取压缩块大小
      fs.Read(blockSize, SizeOf(blockSize));
      blockSize := Swap32(blockSize);
  //读取下一块位置
      fs.Read(nextOff, SizeOf(nextOff));
      nextOff := Swap32(nextOff);
      //复制压缩数据块到临时数据流
      tmpfs.Clear;
      tmpfs.CopyFrom(fs, blockSize);
      tmpfs.Position := 0;
      //解压数据块
      ds := TDecompressionStream.Create(tmpfs);
      ms.SetSize(bufferSize);
      ZeroMemory(ms.Memory, bufferSize);
      ms.Position := 0;
      ds.Read(ms.Memory^, bufferSize);
      //将解压后的数据流复制到字符串数据流
      ss.CopyFrom(ms, 0);
      ds.Free;
    end;{end while}
    //输出合并后的字符串流。
    Result := ss.DataString;
  finally
    //垃圾回收
    fs.Free;
    tmpfs.Free;
    ms.Free;
    ss.Free;
  end;
end;

鉴于 delphi 太冷门了，没有学习价值，所以可以选择直接下载现成的工具 RouterPassView（软件有壳，杀软会误报）

https://www.nirsoft.net/utils/router_password_recovery.html

解密出来之后我们搜索到如下的字段

光猫管理员的账号密码也就出来了

登录之后我们发现，wow，界面都变了，直接迅速找到网络设置，业务类型是上网的那个连接，我们在超管的情况下只能看到拨号上网的账号，密码可以用到网上营业厅的宽带密码服务去重置或者修改，按道理装完宽带给的回执也会记录你的账号密码

然后路由改成桥接，其他默认配置建议小白不要碰

这里的 QoS 模块也可以顺手设置一下（注意，此处的 QoS 是用来控制你上网流量、电话和 IPTV 流量的优先级的）

然后，我们到路由器上，直接把以前的自动获取 IP 模式换成拨号上网模式（路由器设置地址和界面大家都不一样，发挥主观能动性，找到类似的设置即可，我这边路由器是浏览器输入 192.168.0.1 进入，别的路由器可以找说明书有说如何进入）

然后我们拿国人开发的小工具

https://github.com/HMBSbige/NatTypeTester/releases

测下 NAT 类型

我们发现，是 NAT1 的 FullCone

到这一步，就结束了

enjoy it！

https://docs.microsoft.com/en-us/windows/iot-core/develop-your-app/loopback

以下是实施这个方法的全过程：

情景一（单个设置）：

首先打开注册表，Win+R 键，输入 regedit 回车

找到以下路径：

1

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Mappings

其中，左边的注册表项即为应用的 SID 值

右边的 DisplayName 对应的值即为应用的名称，比如这里就是 Windows 商店

接着，使用管理员权限打开 CMD 或者 Powershell

输入

1

CheckNetIsolation.exe loopbackexempt -a -p=SID

其中的 SID 填上之前我们找到的

1

S-1-15-2-1609473798-1231923017-684268153-4268514328-882773646-2760585773-1760938157

回车之后即可解除 UWP 应用的网络隔离

情景二（批量设置）：

使用管理员权限运行 CMD，输入以下的命令，回车即可

1

FOR /F "tokens=11 delims=\" %p IN ('REG QUERY "HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Mappings"') DO CheckNetIsolation.exe LoopbackExempt -a -p=%p

或者使用 PowerShell 指令也行：

1

Get-ChildItem -Path Registry::"HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Mappings\" -name | ForEach-Object {CheckNetIsolation.exe LoopbackExempt -a -p="$_"}

题外话

​ UWP 应用作为微软主推的一种体系，近年来虽然有很多人响应并开发了很多优质的应用，但是，到现在还是半死不活的，和 Chrome 浏览器的 PWA 应用凑成了一对难兄难弟，呜呼哀哉。