Cris.Q

摆弄一下 Stack Canary Checker

Thu, 03 Sep 2026 00:00:00 GMT

import { Aside } from 'astro-pure/user'

之前学习了一些关于程序栈和栈溢出/栈保护的知识，了解到 GCC 会默认给函数插入 Canary Checker 进行栈溢出防护。考查 Checker 的性质：

它是编译器自动插入的，源代码中不会显式调用。
它只在发生栈溢出时会被调用
反编译器（以 HexRay Decompiler 为例）只会检查函数签名是否与数据库匹配

于是，一个自然的想法就是：反编译器为了尽可能“还原”人手编写的 C 代码，应该不会事无巨细地显示所有“噪声”函数，而 AI 一般为了效率也倾向于忽略之。因此，如果我们覆写一个自定义的 Canary Checker，是否就能实现某种混淆，瞒天过海呢？

前置知识

Stack Canary

由于在栈帧内部栈向下增长，如果栈数据太大，可能会覆盖前一栈帧的内容。为了避免因此造成数据损失或程序异常，C Compiler 一般都会在函数末尾插入 Stack Canary Checker，如果不通过则直接崩溃退出程序。

一个典型的栈金丝雀工作原理是：从神奇的 fs:28h 地址[^1]取一个 8 字节随机数[^2]（A），存入栈底（B），等函数返回时进行比对（A=B?），若不同则进入__stack_chk_fail函数，由它进行后续处理。一个典型的反编译结果形如：

// decompiled by Ghidra
undefined8 dbg.main(void)
{
    int64_t iVar1; // 栈上局部变量，存储 canary
    undefined8 uVar2; // 返回值
    int64_t in_FS_OFFSET;

    iVar1 = *(int64_t *)(in_FS_OFFSET + 0x28); // 取随机数

	// do something

    uVar2 = 0; // 设定返回值为 0
    if (iVar1 != *(int64_t *)(in_FS_OFFSET + 0x28)) { // 检查 canary 是否被覆盖
        uVar2 = __stack_chk_fail(); // 调用 __stack_chk_fail() 函数
    }
    return uVar2; // 返回
}

因此，我们首先可以想到：覆写 __stack_chk_fail，让它在报错退出之前“额外做一些工作”。

强符号与弱符号

__stack_chk_fail是一个弱符号，这是让覆写成为可能的关键。

强符号有如下特点[^3]：

由明确定义的变量或函数产生。
同一个程序中不能有多个强符号定义同名符号，否则链接器报错（重定义错误）。
定义全局变量或函数。
确保唯一性，避免冲突。
提供明确的符号定义，链接器优先选择强符号。

而弱符号则：

通过特殊方式声明（如 __attribute__((weak))），表示它是备选符号。
如果有强符号与弱符号同名，链接器选择强符号；如果只有弱符号存在，链接器选择弱符号。
多个弱符号同名时，链接器只选择其中一个。
提供默认实现，允许用户通过强符号覆盖。
支持动态链接中的符号解析。
提供灵活性，支持符号覆盖机制。（malloc/free 都是弱符号，因此tcmalloc才能实现自己的malloc、free函数进行覆盖）

换言之，glibc中提供的__stack_chk_fail是一个备选方案，我们可以用自己声明的强符号覆盖它。

GCC 何时插入 Canary Checker

详细信息见GCC文档，比较复杂。

综合各种编译参数，为了让stack_chk_fail的自由度更高，我选用了-fstack-protector-explicit，这样每个显式声明__attribute__((stack_protect))的函数都会被保护。

获取和修改 FS 段的 canary 原件

GCC 提供了 __seg_fs 符号让我们访问 CPU 的 FS 段，但为了清晰，我还是选择了内联汇编。定义如下两个 helper 函数：

static inline uint64_t get_canary() {
    uint64_t canary;
    __asm__ __volatile__("movq %%fs:0x28, %0" : "=r"(canary));
    return canary;
}

static inline uint64_t set_canary(uint64_t canary) {
    __asm__ __volatile__("movq %0, %%fs:0x28" : : "r"(canary));
    return canary;
}

开始实验

最小可用 demo

我们写一个最简的示例：

#include <stdio.h>
#include <unistd.h>
int main() {
    char stack[1];
    scanf("%s", stack);
    printf("%s", stack);
    return 0;
}

void __stack_chk_fail(void) {
    static const char msg[] = "Hello, World!\n";
    write(2, msg, sizeof(msg) - 1);
}

> ./main
12
Hello, World!
12

可以发现：

__stack_chk_fail被执行了
栈溢出后printf正常执行了（因为我们只是覆盖了canary）

使用gdb跟栈：

此时，__stack_chk_fail就是一个可以做正常函数操作的函数了。那么，是否可以让__stack_chk_fail隐式调用自己，实现尾递归？

一个简单的想法是，__stack_chk_fail本身就是一个函数，它的末尾能不能也被插入 Canary Checker 呢？综合上面知识，我们给__stack_chk_fail加入 attribute 就行了。

更复杂的控制流

有了set_canary这一利器，我们可以自由控制何时发生溢出。

简单的循环逻辑

int iter = 0;

__attribute__((stack_protect)) int main() {
    char stack[1];

    scanf("$s", stack);
    return 0;
}

__attribute__((stack_protect)) void __stack_chk_fail(void) {
    printf("iter: %d\n", iter);
    iter++;
    if (iter < 5) {
        set_canary(get_canary() + 1);
    }
}

> ./main
AAAAAAAA
iter: 0
iter: 1
iter: 2
iter: 3
iter: 4

迭代

我们用全局变量保存计算状态，就可以实现迭代逻辑。如下为一个可用的斐波那契数列计算程序：

#include <stdint.h>
#include <stdio.h>
#include <unistd.h>

// 迭代轮数
int iter = 0;

// 最终结果
int result = 0;

// 迭代中间变量
int prev = 0;
int now = 1;

// 原始输入保存
char buffer[32];

// helper 函数
static inline uint64_t get_canary() {
    uint64_t canary;
    __asm__ __volatile__("movq %%fs:0x28, %0" : "=r"(canary));
    return canary;
}

static inline uint64_t set_canary(uint64_t canary) {
    __asm__ __volatile__("movq %0, %%fs:0x28" : : "r"(canary));
    return canary;
}

// main 函数
__attribute__((stack_protect)) int main() {
    char stack[1];
    printf("您要计算第几个斐波那契数列 > ");
    scanf("%s", buffer);

    // 输入要计算的斐波那契数项
    sscanf(buffer, "%d", &iter);

    // 构造可溢出输入
    buffer[1] = buffer[1] == '\0' ? buffer[0] : buffer[1];
    buffer[2] = '\0';

    // 溢出！
    sscanf(buffer, "%s", stack);
    return 0;
}

// 栈溢出处理函数
__attribute__((stack_protect)) void __stack_chk_fail(void) {
    switch (iter) {
    case 1: {
        result = prev;
        break;
    }
    case 2: {
        result = now;
        break;
    }
    default: {
        if (iter > 0) {
            prev = prev + now;
            now = now + prev;
            break;
        }
    }
    }
    iter -= 2;
    if (iter > 0) {
        // 说明迭代还未结束，继续迭代
        set_canary(get_canary() + 1);
    } else {
        printf("结果: %d\n", result);
    }
}

> ./main
您要计算第几个斐波那契数列 > 34
结果: 3524578

递归

由递归转迭代的知识，我们可以知道，用以下方式模拟递归从理论上是可行的：

__stack_chk_fail(state: in) -> __stack_chk_fail(inner_call) -> __stack_chk_fail(state: out)

经过实现，如下：

#include <stdint.h>
#include <stdio.h>

int data[1024];
int level = 0;
int result = 0;

enum State { incall, handle } hdl = incall;

static inline void bump_canary(void) {
    uint64_t c;
    __asm__ __volatile__("movq %%fs:0x28, %0\n\tincq %0\n\tmovq %0, %%fs:0x28"
                         : "=&r"(c));
}

__attribute__((stack_protect)) int main(void) {
    setvbuf(stdout, NULL, _IONBF, 0);
    scanf("%d", data);
    char stack[1];
    scanf("%s", stack); // 溢出
    return 0;
}

__attribute__((stack_protect)) void __stack_chk_fail(void) {
    if (level < 0) {
        printf("1 + ... + %d = %d\n", data[0], result);
        return;
    }
    if (hdl == incall) {
        if (data[level] == 1)
            hdl = handle;
        else {
            data[level + 1] = data[level] - 1;
            level++;
        }
    } else {
        result += data[level--];
    }
    bump_canary(); // 炸掉fs canary
}

> ./main
5
pwn!
1 + ... + 5 = 15

反汇编行为

以如下代码为例：

#include <stdio.h>
#include <unistd.h>
int main() {
    char stack[1];
    scanf("%s", stack);
    printf("%s", stack);
    return 0;
}

void __stack_chk_fail(void) {
    static const char msg[] = "Hello, World!\n";
    write(2, msg, sizeof(msg) - 1);
}

可以看出，IDA 的反汇编视图将我们的 stack checker 视为正常库函数，不予显示。但函数列表识别出我们的 __stack_chk_fail 不是标准实现，所以没有紫红色背景高亮标注。这是该方案的一个缺陷。可以考虑放入大量函数进行隐藏。

[^1]: 关于 FS 和 GS 段，可以参考Linux内核文档或这篇博客。 [^2]: 根据这篇博客的记录，32 位系统中取地址的内存区是 gs:14h，取出的是 4 字节数。 [^3]: 强符号和弱符号的特点取自这篇博客

数据结构期末复习笔记

Fri, 26 Jun 2026 00:00:00 GMT

import { Aside } from 'astro-pure/user'

前言

这篇笔记是我根据自己比较薄弱的内容，加上做往年卷子时遇到的一些易错点整理出来的复习资料。涵盖时间复杂度、线性表、栈与队列、串、递归、树与二叉树、图、查找和内排序等核心考点，不一定适合所有人，读者请批判性使用。

数据结构概述

基础知识

时间复杂度分析（大O）

分析方法

对于顺序执行（顺序结构或无循环的选择结构）的代码，其复杂度为$O(1)$。
对于循环次数与输入规模$n$无关的单层循环，其复杂度也为$O(1)$。
对于循环次数与输入规模$n$有关的单层循环，其复杂度取决于步长，方法为：写出第k次迭代时循环变量index的通项公式，然后解不等式index <= n，解出的k就是时间复杂度。
对于多层循环，若互不依赖，时间复杂度为$O("总") = O("外" times "内")$，例如内层$O(n)$，外层$O(log n)$，总时间复杂度$O=O(n log n)$；若相互依赖，则退回到内层每轮操作数求和。
对于分治类（即平均划分子问题的递归类），使用主定理求解：
- $$T("当前规模")\ ="每次递归分裂的子问题个数" times T("子问题规模") + T("其余时间")$$
- 令分裂子问题个数为$a$，$"当前规模"/"子问题规模" = b$，$T("其余时间")=f(n)$，比较$n^(log_b a) = c$与$f(n)$的大小：$$T(n) = cases(f(n) " " f(n) > c, c " " f(n) < c, c log n " " f(n) = c)$$
- 上步中的“比较”是增长快慢的比较（即比较$O(f(n))$和$O(c)$），不是绝对的数值比较。
对于非分治类递归算法（递归树不平衡，无法找到恒定的$b$），则直接使用递归树求解：

若树不平衡，但每层总成本$S$恒定，直接取最深递归树深度$H$，$T(n) = S times H$
若树不平衡，每层总成本$S$递减，可认为$H->infinity$，无穷级数求和。
若树不平衡，递归划分非常复杂，考虑求有限项，归纳得解。

分析示例

def func(n):
    count = 0
    for i in range(n):
        j = n
        while j > 0:
            count += 1
            j = j // 2
    return count

循环次数与$n$有关，外层循环$n$次，步长不变，内层步长倍增，$O(n * log n) = O(n log n)$

def func(arr, left, right):
    if left == right:
        return arr[left]
    mid = (left + right) // 2
    # 递归调用：2个子问题，每个规模 n/2
    left_max = find_max(arr, left, mid)      # T(n/2)
    right_max = find_max(arr, mid + 1, right) # T(n/2)

    # 合并：只做一次比较，耗时 O(1)（这里就是 f(n)）
    return max(left_max, right_max)

递归类，平衡，$a=2, b=2, f(n) = 1$，算出$c = n^(log_2 2) = n > 1 -> n$，故$O = O(n)$

def func(arr, left, right):
    if left >= right:
        return 0
    # 不等比划分：1/3 和 2/3
    mid1 = left + (right - left) // 3
    mid2 = right - (right - left) // 3

    # 递归调用：两个子问题规模不同
    res1 = uneven_divide(arr, left, mid1)
    res2 = uneven_divide(arr, mid2, right)

    # 假设合并时要遍历整个数组：O(n)
    total = 0
    for i in range(left, right + 1):
        total += arr[i]
    return res1 + res2 + total

递归类，不平衡，每层总规模为$n$，总成本为$n$，最高层高为$H = log_3 n -> log n$，$O(n log n)$

常见算法

排序

| 算法 | 最好 | 平均 | 最坏 | | ---- | ---------- | ---------- | ---------- | | 冒泡排序 | O(n) | O(n²) | O(n²) | | 选择排序 | O(n²) | O(n²) | O(n²) | | 插入排序 | O(n) | O(n²) | O(n²) | | 归并排序 | O(n log n) | O(n log n) | O(n log n) | | 快速排序 | O(n log n) | O(n log n) | O(n²) | | 堆排序 | O(n log n) | O(n log n) | O(n log n) | | 计数排序 | O(n + k) | same | same | | 桶排序 | O(n + k) | same | same | | 基数排序 | O(d(n+r)) | same | same |

查找

| 算法 | 最好 | 平均 | 最坏 | | -------------- | ------ | -------- | -------- | | 二分查找（折半查找） | O(1) | O(log n) | O(log n) | | DFS/BFS的邻接表形式 | O(V+E) | same | same | | DFS/BFS的邻接矩阵形式 | O(V^2) | same | same | | KMP | O(n+m) | same | same |

图论算法

| 算法 | 时间复杂度 | | ------------- | -------------- | | BFS / DFS | O(V + E) | | Dijkstra（堆优化） | O((V+E) log V) | | Floyd | O(V³) | | Kruskal | O(E log E) | | Prim（堆） | O(E log V) |

一些数据结构的CRUD

哈希表的随机访问是O(1)
二叉搜索树的平均时间复杂度是O(log n)，最坏情况退化成数组，O(n)
链表、数组、栈的性质不言自明，不多赘述

例题

（2）数据元素是数据的基本单位，可以由多个数据项构成（例如，一个结构体数据元素可以包含多个field，各为一个数据项）

（3）数据项是有独立含义的最小数据单位，也称为字段或域

（4）数据类型是一类性质相同的值与其上一组操作的总和，是某种编程语言已实现的数据类型。（与抽象数据类型是不同的概念）

（5）可用已实现的数据类型表示数据项，令其组成数据元素，并将数据元素以逻辑结构组织为自定义的数据类型。

（2）链式存储结构是一种将数据元素分布到离散的内存结点存储的结构，通常使用指针串联索引多块分立的内存区域。

（3）如下：

索引存储结构（在建立元素信息表时一并建立索引表），如 K-V类索引存储
散列存储结构，通过Hash函数建立Key到地址的映射，并在对应的地址中存储Value。

线性表

基础知识

线性表的三个特点为：

有穷性：线性表中元素总数有限
一致性：所有元素性质相同（实现角度：所有元素数据类型相同）
序列性：所有元素的相对位置是线性的，每个元素仅有一个前驱/后继，允许出现不同位置的相同元素。

衡量链表种类有以下几个维度：

头结点/尾结点：头结点/尾结点不存储数据，目的是让链表无须判空，简化处理逻辑。
单向/双向：单向链表每个元素只有next指针，可以指向后继元素，只能单向遍历，双向链表每个元素同时有prev和next两个指针，可以双向遍历
循环：将非循环链表的尾元素的next指向头元素即可。

常见算法

链表的CRUD，其中插入有头插法和尾插法两种

例题

（2）双向链表是一种每个元素同时有next和prev指针的非循环链表。

（3）对于插入，通常可以进行头插或尾插，也可以通过指针循环赋值索引到固定位置，再进行插入；对于删除，可以通过指针赋值+内存释放的方式删除指定结点，对于单链表，即让prev->next = current->next，对于双向链表，还要让next->prev = current->prev。

栈和队列

基础知识

栈：FILO，先进后出，常用于深度优先搜索和递归的模拟（递归本质使用了编程语言的运行时栈）。栈可以使用数组+顶指针模拟。
单调栈：新元素准备入栈时从栈顶不断弹出不满足条件的元素，结束后将新元素入栈。（例如维护递增单调栈时弹出所有大于新元素的元素）
队列：FIFO，先进先出，常用于广度优先搜索，队列可以使用数组+首尾指针模拟
循环队列：通过让index > 数组长度n 的元素回绕到初始位置（例如做对n的取模），重复利用出队后在队头区域留下的空间，提高存储效率。

常见算法

调度场算法

中缀表达式转后缀表达式的经典算法，维护操作数和操作符（可视为单调栈）两个栈，对表达式串从前往后扫描，遇操作数直接放入操作数栈，遇操作符先暂存入操作符栈，当遇到同级或更高级操作符入栈（或右括号）再弹栈。

int evaluate(string s) {
	for (int i = 0; i < s.size(); i++) {
		char c = s[i];

		// 1. 数字：直接入栈（假设是单个数字）
		if (isdigit(c)) {
			num.push(c - '0');
		}

		// 2. 左括号：直接入栈
		else if (c == '(') {
			op.push(c);
		}

		// 3. 右括号：一直计算到左括号
		else if (c == ')') {
			while (!op.empty() && op.top() != '(') {
				calc();
			}
			op.pop(); // 弹出 '('
		}

		// 4. 运算符
		else if (c == '+' || c == '-' || c == '*' || c == '/') {
			while (!op.empty() && priority(op.top()) >= priority(c)) {
				calc();
			}
			op.push(c);
		}
	}

	// 5. 收尾计算
	while (!op.empty()) {
		calc();
	}

	return num.top();
}

深度优先搜索的栈版本

该算法会在查找一节中提及，这里只做示范：

void DFS(int start) {
    stack<int> st;
    st.push(start);

    while (!st.empty()) {
        int u = st.top();
        st.pop();

        if (vis[u]) continue;
        vis[u] = true;

        // 访问结点
        cout << u << " ";

        // 将邻接点压栈（逆序/任意顺序都可以）
        for (int v : G[u]) {
            if (!vis[v]) {
                st.push(v);
            }
        }
    }
}

广度优先搜索的队列版本

同上，放一个我写的层序遍历建树算法做示例：

Node *build_tree(int nums[], int n) {
  if (n == 0) return NULL;

  Node *queue[MAX_NODES];
  int front = 0, rear = 0;

  Node *root = new_node(nums[0]);
  queue[rear++] = root;

  int idx = 1;
  while (idx < n && front < rear) {
    Node *cur = queue[front++];

    // 左子结点
    if (idx < n) {
      if (nums[idx] != NaN) {
        cur->l_child = new_node(nums[idx]);
        queue[rear++] = cur->l_child;
      }
      idx++;
    }

    // 右子结点
    if (idx < n) {
      if (nums[idx] != NaN) {
        cur->r_child = new_node(nums[idx]);
        queue[rear++] = cur->r_child;
      }
      idx++;
    }
  }
  return root;
}

例题

（2）判断非法出栈序列可以通过对给定的入栈序列进行模拟，若出栈序列要求弹出非栈顶元素，或某元素不遵循先进先出原则，则该序列非法。

（2）rear指向队列的最后一个元素，即队尾；front指向队列的第一个元素，即队首

（3）队空：rear=front；队满：(front+n-1-rear)%n=0

（4）可以

串

基础知识

串可存储为顺序串和链串

常见算法

BF & KMP

Bruteforce算法，纯暴力，将查找串的每个字符和模式串的每个字符比较，一旦有不匹配字符则重新比较。

KMP通过next[]数组“复用了已有匹配成果”，next[]数组中每一项表示“当不匹配时要跳到何处继续匹配”，将“后缀BA与当前位置匹配”变成“前缀BA与当前位置匹配”，避免主串指针回溯。

def build_pi(p):
    pi = [0] * len(p)
    j = 0

    for i in range(1, len(p)):
        while j > 0 and p[i] != p[j]:
            j = pi[j - 1]

        if p[i] == p[j]:
            j += 1
            pi[i] = j

    return pi

def kmp(s, p):
    pi = build_pi(p)
    j = 0

    for i in range(len(s)):
        while j > 0 and s[i] != p[j]:
            j = pi[j - 1]

        if s[i] == p[j]:
            j += 1

        if j == len(p):
            return i - j + 1  # 匹配起点

    return -1

例题

（2）目标串是待匹配的串。

（3）模式串是作为匹配物的串，匹配成功即在目标串中找到一个模式串的相等串。

（4）next[]数组存储了模式串的[0, i]子串中匹配的真前后缀最长长度，用于在失配时移动模式串，复用已匹配部分，避免主串指针回退

递归

基础知识

直接调用自身称为直接递归，调用外部函数，外部函数调用自身称为间接递归。
递归思路是将大问题化为小问题解决
一次递归就是一次函数调用栈，会在操作系统提供的运行时栈上开辟一个新的栈帧，因此递归太深可能会爆栈。
递归到非递归的转换分为直接转换和间接转换，直接转换使用迭代（循环）代替递归，间接转换需要通过栈模拟递归结构。

常见算法

深搜和广搜都是递归算法，二分查找，归并排序等也是经典的递归算法，图、树的遍历也都可以使用递归进行。

例题

（2）一种情况下下标不能超过数组长度（位置不能越界），如果递归指针表示区间（例如[left, right]）则不能出现无意义的组合（例如left > right），根据实际问题不同，算法中还可能出现其他人为指定的终止条件。

（3）根据第n个元素选/不选的两种情况分类，并分别递归求出符合题目要求的n-1元素状态S(n-1)，最终得到符合要求的n元素状态S(n)，同时要通过回溯确保找到所有可能的组合。

树和二叉树

基础知识

树的相关概念

一个结点的度指的是该结点的子树的个数，可视为从该结点指出的箭头个数。
树的度是其所有结点度的最大值。度为m的树称为m次树。
叶子结点没有子树
二叉树和二次树的区别：
1. 二次树必须有度为2的结点，二叉树不需要（二叉树甚至可以退化成一个链表）
2. 二叉树严格区分左右子树，二次树无此要求。
满（Full）二叉树：每一层结点数达到最大，结点数为$2^h-1$
完全（Complete）二叉树：仅允许缺口为右下角$h=1$的小块区域，其他部分必须填满。
树的遍历分为：先根遍历、后根遍历，层序遍历（环形队列），对于二叉树，还有中序遍历。
所有树均可以通过孩子-兄弟表示法转化为二叉树，反之亦然。

树的相关公式

$"结点数" = "所有结点度之和" + 1$
$"高" h "的树最多结点数为" (m^h - 1)/(m-1)$
$"结点数为" n "的" m "次树" h >= log_m (n (m-1) + 1)$

几种二叉树

线索二叉树

通过二叉树遍历建立prev/next索引，将二叉树转化为链表，后续使用无须再遍历，避免重复递归消耗。

哈夫曼树

$n$个带权叶子结点构成的所有二叉树中，带权路径长度最小的二叉树称为哈夫曼树。若令叶子结点到根结点的路径长度$l_n$，权重$w_n$，则定义$"WPL" = sum w_n l_n$，表示带权路径长度。

哈夫曼树的构造见常见算法。

并查集

“并”即将两个二叉树合并，“查”即找两个元素的根，看是否相同。可通过parent[]数组进行路径压缩。

二叉搜索树

二叉搜索树（Binary Search Tree, BST）满足以下性质：

对于任意结点，如果其左子树非空，则左子树所有结点的值均小于该结点的值；
对于任意结点，如果其右子树非空，则右子树所有结点的值均大于该结点的值；
任意结点的左右子树也都分别是二叉搜索树（递归定义）。

二叉搜索树的插入：从根开始，比较与当前结点的大小关系，决定往左/右子树插入，当“当前结点”为空时代表找到插入点，进行插入。

二叉搜索树的删除则复杂一些，当删除叶子结点，执行一次搜索并删除，删除仅一个子结点的结点时用子结点替代自己。删除有两个子结点的结点时，用左子树最大值或右子树最小值替换。（即左子树最右元素或右子树最左元素）。一般采用前一种做法。

平衡二叉树（AVL）

定义一个结点左右子树高度差为平衡系数，即 $"平衡系数" k = "右子树高度" - "左子树高度"$。

平衡二叉树要求：一棵平衡二叉树及其所有子树（也为平衡二叉树）有$abs(k) <= 1$。

插入元素，删除元素均与二叉搜索树一致，先执行一次搜索，再分情况操作。

除此之外，平衡二叉树有一个“恢复平衡”的操作。通过左旋 & 右旋进行平衡恢复。

例如，对于LL型，根结点进行一次右旋：

对于LR型，将根的左子树左旋可以转为LL型，再重复上述方法即可处理：

对于RL型和RR型，处理方法类似，不做赘述。

B- 树 & B+ 树

B树的B不是二叉的意思，而是平衡的意思。B树是一种所有结点平衡因子均为0的多路平衡搜索树。

一棵$m$阶B树要么是空树，要么满足以下条件：

除根结点外，每个非叶子结点至多有$m$个孩子结点(该结点本身存储了$m-1$个关键字，关键字之间的空隙为孩子结点的范围)，至少有$\lceil m/2 \rceil$个孩子结点。
每个结点至多有$m$个孩子结点（包括叶子结点和根结点）。
根结点至少有两个孩子结点。
子结点存储的数据区间为插空存储，即从小到大形如：[[子1],p1,[子2],p2,...,p_n,[子n+1]]
所有外部结点处于同一层

B-树的CRUD

B树的查找与二叉搜索树一致，落入外部结点时为查找失败。

B树的插入与二叉搜索树基本一致，先找到插入点（叶子结点层的某个结点），如果其关键字个数为$m-1$，没有空位置，进行分裂：将第中位数个关键字上提为父结点（没有父结点则新建，有则在父结点关键字中新增一条）。如图所示：

B树的删除有两种特殊情况，一个是删除后不满足Min需求，可以考虑从兄弟结点借：

另一种是从兄弟结点借后兄弟结点不满足需求，即不能借，此时合并两兄弟结点（可看作将父结点某个关键字下提）：

B+树

B+树放弃了存关键字，只存索引，所有值存在叶子结点，同时叶子结点层通过链表串联：

B+树的插入和删除都仅在叶结点上进行，方法与B-树类似。

堆

堆是一种特殊的二叉树，其左右子树中所有元素均小于/大于堆顶元素（即二叉树根），其左右子树也是堆（递归定义），分为最大堆（大根堆）和最小堆（小根堆）。一般实践中使用数组存储。堆有上滤和下滤两种操作。

堆的上滤和下滤

以最大堆为例：

上滤一个元素时，将其插入到数组末尾，不断比较其和父元素（第n/2个元素），其比父元素大时则交换位置。
下滤一个元素时，不断找其左右子元素中的较大值，如果当前值小于该较大值，则交换其与对应子元素位置。

常见算法

哈夫曼算法

哈夫曼算法用于构造一棵哈夫曼树，算法步骤如下：

初始化：由给定的 $n$ 个权值构造 $n$ 棵只有一个根结点的二叉树，得到一个二叉树集合 $F$。
选取与合并：从二叉树集合 $F$ 中选取根结点权值最小的两棵二叉树分别作为左右子树构造一棵新的二叉树，这棵新二叉树的根结点的权值为其左、右子树根结点的权值和。
删除与加入：从 $F$ 中删除作为左、右子树的两棵二叉树，并将新建立的二叉树加入到 $F$ 中。
重复 2、3 步，当集合中只剩下一棵二叉树时，这棵二叉树就是哈夫曼树。注意，由于上述算法确保了内部节点同时有左右两个子节点，所以构造出的哈夫曼树节点个数为$2n-1$，没有度数为1的分支节点。

其余算法也并不复杂，都在上述内容中陈述过。

例题

（2）二叉搜索树的插入和删除需要先进行搜索，定位插入/删除位点。对于左右都非空的结点的删除，一般把其左子树最大值与自身交换，并删除自身。

（3）AVL树的删除和插入基本步骤同上，插入后根据LL、LR、RL、RR四种情况通过左旋右旋进行平衡。（对于LL和RR，对根结点进行右旋/左旋，LR和RL分别对第一层左/右结点进行左旋/右旋，转化为LL/RR进行处理）

（2）使用循环队列

（2）B-树的构造使用逐个插入元素的方法，同结点的关键字插入按从小到大插入，当关键字数量打到限额，提取第中位数个关键字上提（提升至父结点，如果没有父结点则新建父结点，树高+1）再继续插入。

（3）B+树是一种改进版的B树，与B-树的差别为：B+树内部结点只存子结点索引，不存关键字，所有数据存于叶结点，叶结点层通过链表索引。

（2）对于给定字符集的哈夫曼编码，先统计字符出现频率赋权，再根据加权路径长最短原则生成哈夫曼树，最后按左子树为0，右子树为1的规则给叶子结点分配哈夫曼编码。

（3）先统计每个字符出现频率，然后根据$(sum "字符出现次数" times "哈夫曼编码长度")/("总字符量" times "固定编码长度")$计算。

（例如，A=00, B=01, C=10，则定长编码为2位，Huffman则会更短）

（2）堆的性质与堆的类型有关，最大堆（大根堆）满足：对于任意结点，其所有子结点小于自身，所有子结点都是最大堆；最小堆（小根堆）则反之。

（3）构建堆一般可以通过不断上滤/下滤进行。以最大堆为例，将新元素插入到数组末尾，执行一轮上滤，重复该操作直到构建完毕。

图

基础知识

有向图/无向图：结点之间存在“指向”关系的图为有向图，表现为结点用箭头连接。无向图则只表明了连接关系，不表明指向关系。表现为邻接矩阵，无向图始终有matrix[a][b]=matrix[b][a]。
入度/出度：指向当前元素的箭头数为其入度，指出箭头数为其出度。无向图中没有严格的入度/出度定义，可以认为入度=出度=度=当前结点连接结点数。
连通/非连通：往一个结点灌水，能流到的所有结点相互连通，组成一个最大连通分量，其子集为连通分量。最大连通分量覆盖所有结点的图为连通图。
最小生成树：遍历所有结点，不允许成环，总路径长度最小。

常见算法

四个重量级。

Kruskal

思路：所有边从小到大排，每次选最小边，如果两端元素不在同一个并查集中，则加入候选边集，以此类推，直到选出（n-1)条边。

Prim

思路：存储每个结点到当前最小生成树的距离，每次遍历，找到树距离最小点，加入树，并更新其邻接树外结点到树的距离，直到所有结点在树中。

Dijkstra

思路：设置起点到自身距离为0，其余点为∞。每次从未访问的点中选择当前距离起点最小的点u，将其加入已确定集合（已得到最短路径），然后用u去更新它的邻接点到起点距离，直到所有点都被确定或不可再更新。

Floyd

思路：设置dist[i][j]表示i -> j的最短距离，并枚举中间点k，当dist[i][k] + dist[k][j] < dist[i][j]，更新，直到所有点处理完毕。

拓扑排序

要求：必须要是无环有向图，即有明确依赖结构，无循环依赖。

算法：每次找入度为0的点，选择它，并将邻接元素入度-1，重复直到排序完毕。

AOE网

一个源点一个汇点，中间发散，用于求关键路径。例如：

最长权重的路径就是关键路径。图中为$W=3+1+2=6$。

例题

（2）邻接矩阵会表现为上三角矩阵，因为序列下标的递增保证了永远是下标小的元素指向下标大的元素。

（2）需要找最短路径时建议用广搜，需要枚举所有路径建议用深搜，空间限制较严时建议用深搜。

查找

基础知识

平均查找长度（ASL）：分为成功状况下的平均查找长度和不成功状况下的平均查找长度。理解为“比较次数的期望”。
- 成功时$"ASL"=sum(P_i C_i)$，其中$P_i$表示节点$i$被查找的概率，$C_i$表示查找节点 $i$需进行的比较次数。
- 失败时则看需要走多少步才能判错，对于顺序查找，$"ASL"=n$，其他查找方式可分别分析。
顺序查找：for i in range(0,n): compare
折半查找：二分法，可用红蓝染色法理解，也可用二叉树表示查找过程，该类树称为判定树。
分块查找：在索引整体无序，分块后块间有序的情况下，可以分块查找。例如，对于[3,2,1,6,5,4,9,8,7]，分为三块，按块内最大值建立索引[3,6,9]，按照“先块间，再块内”缩小查找范围。分块查找性能介于二分和顺序查找之间。
基于树的查找已经在前文讲过了，其他查找算法比较基础，略去。

例题

（2）进行分块查找首先确定分块标准和索引标准，并建立块和索引表，接着根据待查找数据在索引表内选块（顺序、二分等均可），在块内进行查找（块内无序，只能顺序查找）。

（3）分块查找效率等于块内和块间的$"ASL"$加和。

内排序

基础知识

基于比较的排序算法：插入、选择、交换、归并。
不基于比较的排序算法：基数排序。
引入序列$（R_1,...R_n）$，排序过程也可以用决策树表示。
使用基于比较的排序方法，最佳平均时间复杂度为$O(n log n)$。
排序前后相同关键字的元素相对位置发生改变的排序算法不稳定，反之稳定。

常见算法

插入排序

插入排序分直接插入、二分插入和希尔排序。

直接插入十分简明，略去；二分插入中“查找待排序元素在有序区的位置”使用二分查找操作，其余操作与直接插入相同。

希尔排序采用的思路是：等距分组（d=n/2）分别插入排序，依次将d折半，直到d=1（最后一趟执行了直接插入排序）。通过前面不断分组排序，让最后一趟插入排序需要移动的元素数量较少，不会有太大压力。

交换排序

常见的交换排序算法有冒泡排序、快速排序两种。冒泡十分简明，略去。

快速排序分二路和三路，思路相近，不断进行哨兵划分，将待排序区域分为[<=pivot],[>pivot]两块（或者三块），递归排序。

选择排序

分为简单选择排序和堆排序。简单选择排序的思路是从未排序区选出最小元素，插入有序区尾。堆排序将数组的未排序区视为堆，维护最小堆并不断将堆顶元素放到已排序区，直到堆空。

归并排序

将一个表拆分成多块，分别递归排序，最后采用“每个表作为一个队列，取队首元素比较较小值”的方式合并为一个新表。根据拆分数n记为“n路归并”。

基数排序

按位分桶（分最低位优先和最高位优先，最低位优先为：先排个位，再排十位......），低位优先时按桶顺序收集元素，再分桶。例如：

{123, 125(1号), 125(2号), 134, 137} -> {123, 134, 125(1号), 125(2号), 137} -> {123, 125(1号), 125(2号), 134, 137}

高位优先则递归分桶，不收集，而且我承认这块我真没搞明白，但是没关系，高位优先排序非常不常用，应该不会考的。

各算法特性

时空复杂度

| 排序方法 | 平均情况 | 最坏情况 | 最好情况 | 空间复杂度 | 稳定性 | | :----- | :------------- | :------------- | :------------- | :------------ | :-- | | 直接插入排序 | $O(n^2)$ | $O(n^2)$ | $O(n)$ | $O(1)$ | 稳定 | | 折半插入排序 | $O(n^2)$ | $O(n^2)$ | $O(n log_2 n)$ | $O(1)$ | 稳定 | | 希尔排序 | $O(n^(1.3))$ | — | — | $O(1)$ | 不稳定 | | 冒泡排序 | $O(n^2)$ | $O(n^2)$ | $O(n)$ | $O(1)$ | 稳定 | | 快速排序 | $O(n log_2 n)$ | $O(n^2)$ | $O(n log_2 n)$ | $O( log_2 n)$ | 不稳定 | | 简单选择排序 | $O(n^2)$ | $O(n^2)$ | $O(n^2)$ | $O(1)$ | 不稳定 | | 堆排序 | $O(n log_2 n)$ | $O(n log_2 n)$ | $O(n log_2 n)$ | $O(1)$ | 不稳定 | | 二路归并排序 | $O(n log_2 n)$ | $O(n log_2 n)$ | $O(n log_2 n)$ | $O(n)$ | 稳定 | | 基数排序 | $O(d(n+r))$ | $O(d(n+r))$ | $O(d(n+r))$ | $O(r)$ | 稳定 |

稳定性

希尔排序，快速排序，各种选择排序不稳定，其他稳定。

例题

（2）没有必要

（3）可以通过单侧递归快排，堆等方法高效查找。

（2）二路快排的平均时间复杂度为$O(n log n)$，最坏情况退化为$O(n^2)$（类似冒泡排序，每一轮的哨兵划分都正好分到最大元素），空间复杂度为$O(log n)$。

（2）希尔排序（时$O(n^{1.3})$，空$O(1)$）、快速排序（时$O(n log n)$，空$O(log n)$）、堆排序（时$O(n log n)$，空$O(1)$）、简单选择排序（时$O(n^2)$，空$O(1)$）不稳定，其他稳定。

（3）冒泡排序，选择排序，快速排序，堆排序

（2）时间复杂度为$O(n log n)$，空间复杂度为$O(n)$。

（3）稳定，内排序，基于归并。

大学物理（上）复习笔记整理

Sat, 13 Jun 2026 00:00:00 GMT

import { Aside } from 'astro-pure/user'

前言

这篇笔记是我根据自己比较薄弱的内容，加上做了三套往年卷子的错题和搞不懂的点整理出来的资料，不一定适合所有人，也可能存在错漏之处，读者请批判性使用（

质点运动学

本章没有太多需要强调的点，只梳理一下自然坐标系。

自然坐标系

任意时刻，建立自然坐标系时，加速度可分解为切向加速度和法向加速度，即有： $$ cases(a_n = (v^2)/R, a_tau = (d |arrow(v)|)/(d t) ) $$ 切向加速度改变物体运动速率，法向加速度改变物体运动方向。

刚体定轴转动

角量表示的运动学

对于运动学的线量表示，有： $$ cases(v = (dif x)/(dif t), a = (d v)/(d t), ) $$ 若物体绕定轴作半径为 $R$ 的圆周运动，引入角速度 $omega$ 和角加速度 $alpha$ 后可将上式拓展为运动学的角量表示： $$ cases( omega = (d theta)/(d t), alpha = (d omega)/(d t), a = alpha R, v = omega R ) $$ 该部分的运动学题目比较常规，略去。

角量视角下的力、功、能、动量

力矩，转动惯量

在刚体视角下，力的作用点对力的作用效果有影响，引入力矩$M$刻画这种影响，同样，与代表平动惯性的质量$m$相对，有转动惯量$I$。

取参考点到力作用点的有向连线 $arrow(r)$ 为位置矢量，有：$M = arrow(F) times arrow(r)$，只考虑大小时也可以说$M = F d$，即力矩大小等于力乘力臂。

对于$I$，有$I = integral R^2 d m$（这里$R$就是到转轴的垂直距离，类似力臂），由此可整理以下表格：

| 物体 | 转轴 | 转动惯量 | | --- | ----- | ------------ | | 圆环 | 过圆心垂线 | $m R^2$ | | 圆盘 | 过圆心垂线 | $1/2 m R^2$ | | 细杆 | 中点 | $1/12 m R^2$ | | 细杆 | 端点 | $1/3 m R^2$ | | 空心球 | 过球心的轴 | $2/3 m R^2$ | | 实心球 | 过球心的轴 | $2/5 m R^2$ |

其中，个人体感上，细杆绕端点旋转非常常用，建议重点记忆。

平行轴定理与正交轴定理

注意参考点是质心

注意，这里三个坐标轴不要求轴与物体交点为物体质心，也就是说你可以组合平行轴定理+正交轴定理算出物体绕任意点的转动惯量。

角量视角下的力学、能量、动量

同线量描述的力学和能量、动量一样，我们可以用角量描述这些关系。且只考虑定轴转动时，两种视角下对应公式形式高度一致： $$ F = m a -> M = I alpha
E_k = 1/2 m v^2 -> E_k = 1/2 I omega^2
P = m v -> L = I omega $$ 此处出现的$L$表示角动量。与动量守恒相似，当无合外力矩时，有角动量守恒：$L_0 = L_1 + l_2 + ... -> I_0 omega_0 = I_1 omega_1 + ... = "常量"$。

同样的，不考虑滑轮转动惯量时有简化结论任意时刻绳上两点拉力相等。

然而，上述两个观点在刚体力学（具体而言为刚体定轴转动）中不成立。处理绕端点旋转的棍一律使用$1/3 I omega^2$，而处理含非轻质滑轮的转动问题时以与滑轮接触点为界设两侧拉力为$T_1, T_2$后列方程求解。

简谐运动，机械波

描述简谐振动的物理量

$$ x = underbrace(A, "振幅") cos underbrace((underbrace(omega, "角频率") t + phi), Phi ", 相位") $$

其中：

复摆：$omega = sqrt(m g l/I)$
单摆：$omega = sqrt(g/l)$
弹簧振子：$omega = sqrt(k/m)$

旋转矢量法

将简谐运动视为一个圆周运动在某个坐标轴上的投影，该部分略去。

横波和纵波

这块我高中就没搞明白，惭愧（

为了便于~~我这种猪脑子~~记忆，振动方向与波传播方向垂直，像是关上阀门"横行霸道"拦截波，所以是横波，反之"纵容"波传播，是纵波。

常见的波（绳波，部分机械波，电磁波...）都是横波，声波是纵波。液体和气体不能传播机械横波（电磁波不属于机械横波，不需要介质就能传递）。

简谐运动的证明

当证明某个运动为简谐运动，核心就是证明回复力（这是个合力，不一定只是弹簧拉力）与偏离某个点（平衡位置）的位移成正比。

此时有规律：$a("加速度") = - omega^2 x$，可以快速算出简谐运动角频率，进而算出周期。

对于弹簧振子模型，认为弹性势能最大点动能为0没有问题，因为此时弹性势能看的是弹簧弹性形变。但上题中是机械波，在介质中传播，弹性势能是看振动质点挤压旁边质点的幅度。因此，机械波中弹性势能与动能同步变化。

热学

理想气体的基本知识

理想气体的压强为：$p = 1/3 n m_0 dash(v)^2$，其中$n = N/V$，表示平均分子密度。

因此可以改写理想气体状态方程：$p = nu R / V T = m/M R / V T = N/N_A R/V T = n k T$，称$k$为玻尔兹曼常量。 $$ cases(p = n k T, p = 2/3 n dash(epsilon_k)) -> dash(epsilon_k) = 3/2 k T $$ 此处$dash(epsilon_k)$表示的是分子平均平动动能。

理想气体的平均碰撞频率 $dash(z) prop dash(v) n, n = N/V$

平均自由程 $dash(lambda) prop 1/n, n = N/V, p V = N k T -> dash(lambda) prop T/P$，与平均速度和体积无关。

理想气体状态量符号辨析

$N$ 表示分子总数
$n = N/V$ 表示分子数密度
$m$ 表示单个分子质量
$M$ 表示分子摩尔质量
因此有$p V = nu R T, p = n k T = N/V k T = N/V R/(N_A) T$，其中$N/N_A = nu$，符号就能对上了。

理想气体的各类分布

速率分布函数

$$ f(v) = lim_(Delta v -> 0) (Delta N)/(N Delta v) = 1/N (d N)/(d v) $$ 表示温度为$T$的平衡状态下速度在$v$附近单位速率区间的分子数占总数的比率。

速率位于$v_1 ~ v_2$区间内的分子占总数比：$integral_(v_1)^(v_2) f(v) d v$

对于一个速率分布函数，其最大值点对应的就是最概然速率。

麦克斯韦气体速率分布定律

$$ f(v) = 4 pi (m/(2pi k T))^(3/2 e^(-(m v^2)/(2 k T))v^2) $$ 这个式子不用记，但是由该式推出的三种统计速率需要掌握：

最概然速率$v_p = sqrt((2 k T)/m)$，原理是$(d f(v))/(d v) = 0 -> v = sqrt((2 k T)/m)$
平均速率：$sqrt((8 k T)/(pi m))$，原理是：$v = (integral_(0)^(v_0) v d N)/N$
方均根速率：$sqrt(dash(v^2))=sqrt((3 k T)/m) = sqrt((3 R T)/M)$，由广义积分得出

三种速率的关系有：$v_p < dash(v) < dash(v^2)$

四个过程

下表展示了四个常见热学过程的性质。

| 过程 | 过程方程 | $Delta U$ | A | Q | | --- | -------------------------------------------- | -------------------- | ---------------------- | -------------------- | | 等容 | $p T^-1 = C$ | $nu C_(V,m) Delta T$ | $0$ | $nu C_(V,m) Delta T$ | | 等压 | $v T^-1 = C$ | $nu C_(V,m) Delta T$ | $nu R Delta T$ | $nu C_(p,m) Delta T$ | | 等温 | $p V = C$ | $0$ | $nu R T ln(V_2/V_1)$ | $nu R T ln(V_2/V_1)$ | | 绝热 | $p V^gamma = C, gamma = (C_(p,m))/(C_(V,m))$ | $nu C_(V,m) Delta T$ | $- nu C_(V,n) Delta T$ | $0$ |

可见只要有温度变化的过程，内能变化均为$nu C_(V,m) Delta T$，其中，等压变化还额外吸热用于对外做功，所以$nu C_(p,m) Delta T = Delta U + A$，又有规律$C_(p,m) = C_(V,m) + R$，故有上式。

每一个自由度均分$1/2 k T$的平均动能，总动能等于所有自由度均分动能的和。

对于每摩尔物质，你也可以说每个自由度均分$1/2 R T$平均动能，注意$R = k N_A$。

此外，有$(C_(p,m))/(C_(V,m)) = (i+2)/(i), thick thick C_(V,m) = i/2 R$。

自由度

确定气体分子能量需要引入自由度的概念。分子自由度$i=t+r+s$，其中三个量分别是平动、转动、振动自由度。下面讨论的为有效自由度（$=t + r + 2s$），例如，只考虑平动转动振动时几何自由度为6，但有效自由度为7。热力学公式全部使用有效自由度。

热循环，热机

任意一个在p-V图中回到原点的过程组合称为一个循环。循环一周内能不变。

顺时针方向称为热循环（逆时针方向为制冷循环），每循环一周系统吸热并对外做功，曲线所围面积为系统对外做净功。设吸热$Q_A$，放热$|Q_2|$，则热循环效率为：$eta = A/Q_1 = 1 - (|Q_2|)/Q_1$。

如果为制冷机，则我们希望它做功少，吸热多，故制冷系数$omega = (|Q_1)/A$，注意制冷系数是可以大于 1 的。

卡诺热机

工质只和两个恒温热源交换热量。等温+绝热。

卡诺热机的$eta = 1- T_2/T_1$，如果为制冷机则$omega = T_2/(T_1 - T_2)$（其中，$T_1 > T_2$，为高温热源温度）。

多个卡诺热机如果共享某条等温线，则该热源温度相同。

电学

各种电荷的概念辨析

电位移的高斯定理框选的是自由电荷。
感应电荷是自由电荷的重新排布，属于自由电荷。
电介质极化出现的是束缚电荷。

常见物体的场强分布

球壳

对于空心球壳：

壳内：$E = 0$
壳外：$E = (k Q)/r^2$

对于实心球，使用$r/R = E_0/E, E = (k Q)/(R^2)$即可。

无限长圆筒

当没有厚度，退化为细线，外部任意点有：$E=(2 k lambda)/r$

当有厚度，筒内$E=0$，筒外同上。

当有厚度且实心，筒外同上，筒内按$r/R = (E R)/(2 k lambda)$求解。

无限大带电平板

此时有$E = sigma/(2 epsilon_0)$，电场强度与$r$无关

细线的等效

可将细线等效为圆弧求解：

对于无限长细线，可等效为半圆。

电场中的导体与电介质

对于这种模型，导体内电场强度为0的条件除了列高斯定理外，还可以通过带电平板激发场强公式列方程予以利用。

球壳激发的电势$(k Q)/R$是"面外"电势，这个"外"不理解为几何意义的封闭图形外部，可以理解成只要所处区域不与图形重叠，就是外部。同时，上述公式不要求电荷均匀分布，因为$R$是相等的，积分时直接把所有$d Q$重合到一点即可。

电容

$$ Q = U C $$ 其中，$Q$为平行板电容器一个极板带的电荷量。

电场能的计算

静电系统的总能量是$W = 1/2 sum_i q_i phi_i$，对于两个等势体，系统存储的电场能是$1/2 (Q_1 V_1 + Q_2 V_2)$。

注意，平行板电容器存储的电能是"两极板中间部分的能量"，所以才退化成只考虑相对的两个内表面带电荷，并相减。此外，平行板电容器只有内表面带电，外表面不带电，可以认为是两个电荷均匀分布，等大异号的导体板靠近发生感应起电时的情形。

如果你大物实验也没听

Mon, 25 May 2026 00:00:00 GMT

import { Aside } from 'astro-pure/user'

简单而言，不确定度就是一个均衡考量了仪器误差和实验随机误差的，用于衡量测得量偏差度的量。其计算方法按照直接测量和间接测量的不同，也会分为两种。总体而言，大学物理实验报告中要求呈现的结果按如下格式写出（假定带测量为$x$）： $$ (1). space.third dash(x) = ...
(2). space.third S_x = ...;\ S_dash(x) =...
(3). space.third cases(x = dash(x) +- u "(即不确定度)", u_r = "某一个百分量") $$

标准偏差

用于描述“单次测量偏离均值的情况”，计算公式如下：

$$ S_x = sqrt((sum_(i=1)^n (x_i - A_0)^2)/(n)) $$ 然而，$A_0$作为假设中绝对精确的准确值，现实世界中只能趋近无法精确得出的。因此一般用平均值$dash(x) = (sum x_i)/(n)$来代替$A_0$，并为了避免样本天然向均值趋近（也就是说你用计算出的均值来计算同一组数据的另一个“平均量”，得到的误差肯定会比真实小），所以降低一个自由度，将$n$变为$n-1$，上式变化为： $$ S_x = sqrt((sum_(i=1)^n (x_i - dash(x))^2)/(n-1)) $$ 可以发现上式根号中分子即为方差。

算术平均值的标准差

标准差表述的是“单次测量距离测量均值的偏离程度”，算术平均值的标准差反映的则是“算数平均值距离真实值的偏差程度”。有公式如下：

$S_dash(x) = (S_x)/sqrt(n)$，将$S_x$展开可以得到最终公式，但笔者觉得出于理解便利考虑，分步计算两个标准偏差是思维负担更小的做法。

仪器误差

仪器误差表征的是仪器存在的未知的系统误差的估计量。因此其无法保证消除，采用一个约定的值将其纳入考量。

一般而言，仪器误差按如下表格取值：

| 仪器 | 仪器误差 | | ------ | ----------------------------- | | 米尺 | 最小刻度的一半 | | 螺旋测微器 | 最小刻度的一半 | | 游标卡尺 | 精度（尺上标明） | | 数字显示仪器 | 显示的最小单位 | | 电学仪表 | 量程乘以级别（$X_m times S percent$） |

不确定度的计算

不确定度$u = sqrt(u_A^2 + u_B^2)$，其中，$u_B$表示B类不确定度，可直接用$sum r_i$（对应仪器的仪器误差）代替。$u_A$表示A类不确定度，与随机误差有关。

针对待算量的测量方法，不确定度的计算方法有细微差异，下面将阐述两种计算方法。

直接测出的量

对于直接测出的量（例如通过天平测量质量$m$），有$u_A = t / sqrt(n) S_x$，由统计规律发现，在测量次数$n in (6,10)$时，$t/sqrt(n) -> 1$，故在平常实验表述中，可直接取：$u_A = S_x$。

结合B类不确定度算法，可得：

$$ u = sqrt((S_x)^2 + sum (Delta "仪")^2)
u_r = u/dash(x) times 100 percent $$

间接测出的量

对于间接测出的量（例如使用位移时间法测速度，此时$v = f(s,t)$），则有： $$ u_v = sqrt(((diff f)/(diff s) u_s)^2 + ((diff f)/(diff t) u_t)^2) $$ 对于常见函数有误差传递公式，但笔者觉得现推也来得及，记太多反而是负担。

值得注意的是，公式中使用的精确量无不确定度，因此间接测量不确定度时只需要考虑$f("所有本次实验测出的量")$，而不需要把每一个值纳入考量。

至此，~~又臭又长的~~绪论PPT中不确定度部分笔记整理完毕，祝临时抱佛脚顺利。

一些关于武大的话

Tue, 12 May 2026 00:00:00 GMT

import { Masonry } from 'astro-masonry'

因为害怕冲突，我是一个很畏惧公共表达的人。总担心因为表达自己惹上麻烦，失去朋友。在之前几次关于武大的舆论中，学生媒体《珞珈山上》的社论《风暴中心的武大人，该如何自持？》给了我将心中郁结抒发出来的勇气，"愿珞珈常青，弦歌不辍"的呼唤也由衷地震撼到了我。而这次，虽然我不太认同其对澎湃新闻那些诛心之论的谴责，但既然ta们发了声，我也便又有了勇气写一些东西。

争议焦点的文案，错在了哪?

我对这个文案的观感其实是经历过起伏的：一开始看到有点别扭，后来想着想着觉得好像没什么大问题，但在自己看了一些相关的评论，和AI进行了一些讨论后，又逐渐明白了为何说它确实存在问题。

针对文案本身，如果这是一条个人的社媒评论或者朋友间的私人表达，我觉得完全合理。作为一个"二次元爱好者"，每次看动漫时弹幕都能看见各种刷"老婆老婆"的，而玩乙游叫老公也是极正常的现象。我喜爱的动漫类博主泛式、竹鱼夫妻就在直播中有当着对方管纸片人喊老婆/老公的切片。在二次元、追星等亚文化圈层中，喊喊"老公""老婆"本就是极其正常的、共识性的表达喜爱的语言。用所谓"严肃的家庭文化"去消解难免让人觉得实在保守得不行。穿个婚纱追演唱会和开痛车、买手办真的有什么本质区别吗？难道因为明星不像纸片人"那么虚拟，那么毫无可能"，就担心妻子会因为泛泛花痴喊几句老公就去跟明星发生关系吗？这其中的滑坡实在是不言自明的。

但如果这样的表达上升到面向大众的公共宣传，确实就会冒犯到偏保守和严肃的主流家庭伦理观，会让一部分人觉得构成了对"神圣的婚姻"的"亵渎"。虽然我本人不这么认为，但我完全可以理解觉得被冒犯的那一部分朋友。即使表达者对主流的婚姻叙事不满意，想融入自己的表达，也应理解风气的改变是渐进的而非瞬进的，冒进的、与社会脱节太远的公共表达只会招致反感，传播研究者和工作者更应该保持克制。

另外，作为商业宣传，冒犯用户显然是不明智的。哪怕是为了多覆盖一点消费群体，也许这样的个人表达稍稍让位于市场策略，会是"接商单""做任务"的更好姿态。即使是出于迎合女性主义者受众的考虑，这样的文案也在遣词造句上仍有值得推敲之处。

当然，我对文案本身确实没什么恶感。"跟我爸约会基本不打扮"完全可以理解成老夫老妻之间的信任和默契，"恨不得穿婚纱"也是一个对偶像有热情的活泼形象。我尽力在这一 part 保持客观，也欢迎讨论。

数年未有之怪现状：对人的征伐。

这是一个我本来没有意识到的问题。但反而是最让我愤怒的。

前两天，在一个鸿蒙开发相关的群里看到了一些群友转发的聊天记录，点进去的第一条消息竟然是一个女生的个人主页截图，随后便是一些令人不忍卒读的诟谇谣诼："看见长相的那一刻释然了"、"符合小仙女刻板印象"、"傅首尔面相"种种。思索整理后才明白，原来就是涉事广告组中的一人（以 A 指代）。当日下午，在另一个技术群看到了对此人更加彻底的揭底——扒出母校，扒出论文，甚至扒出了贴吧的表白帖。不出所料，又是新一轮的狂欢。

直到这时，我才忽然意识到一个问题：这些年这么多次所谓"广告翻车"事件中，有哪一次是像这次这样，舆论从品牌和文案本身集体转向，转向对一个具体的人的恶意，对ta的相貌羞辱，对ta身份的起底，乃至对ta母校的羞辱吗？。

得益于 AI ，我能做一个比较全面的调查：

| 年份 | 品牌 | 争议焦点 | 舆论转向个人情况 | |------|------|----------|----------------| | 2019 | 杜蕾斯×喜茶 | 跨界文案"今夜一滴都不许剩"物化女性，低俗色情营销 | 否，舆论聚焦品牌 | | 2021 | 李诞·Ubras内衣 | "让女性轻松躺赢职场"矮化女性，男性代言女性内衣 | 否，聚焦李诞本人及品牌，但李诞作为公众人物，批评仍在其职业身份范畴内 | | 2021 | 江南布衣童装 | 儿童服装图案出现暴力、血腥、性暗示元素 | 否，聚焦品牌与产品 | | 2022 | 奥迪 | 《人生小满》广告文案抄袭"北大满哥"，被指查重率高达99% | 否，聚焦品牌与创意代理方 | | 2023 | Keep | "这么可爱的奖牌，确定不要？反正都是男朋友给跑"矮化女性 | 否，聚焦品牌 | | 2024 | 京东 | "辱男又辱女"营销失误，章泽天佩戴徽章引发舆论反噬 | 否，聚焦品牌与代言人家属 | | 2024 | 珀莱雅 | 三八妇女节营销刻意放大性别对立，被指"为流量制造矛盾" | 否，聚焦品牌 | | 2024 | 某洗护品牌 | "妈妈，您先用"文案被指暗示家务是妈妈的专属 | 否，聚焦品牌 | | 2025 | 桃李面包 | "饱尝生活毒打"月饼广告，被指"爹味说教" | 否，聚焦品牌 | | 2025 | 百果园 | "不迎合消费者""教育消费者"回应被指"爹味说教" | 否，聚焦品牌创始人及品牌本身 | | 2025 | 迪卡侬 | 将海洋比喻为"处女地"，被投诉用词不当 | 否，聚焦品牌 | | 2025 | 斯沃琪 | "眯眯眼"亚裔模特广告被指种族歧视辱华 | 否，聚焦品牌及模特表现 | | 2025 | 南孚电池 | "好喜欢和领导一起出差"高铁广告玩职场梗翻车 | 否，聚焦品牌 | | 2026 | OPPO母亲节 | "我妈有两个老公"扭曲亲情，冒犯婚姻伦理 | 是，出现"人肉开盒"、相貌羞辱、身份起底、母校羞辱 |

在OPPO这次广告翻车之前最近的事件应该就是罗技那条"一降价，你还不像狗一样跑过来"的营销事件了，但谁能说清那条广告的策划人姓甚名谁，毕业于何时何处呢？亲爱的好事网友们是懒得挖，还是挖到了发现没有流量可吃，就没有继续传播声张呢？

我们现在能知道 A 的名字，这本身就是不可思议而让人愤怒的——从扒名字开始，一切的狂欢，一切的污名，都是脱离事件本身的失当惩罚，是非正义在以正义的幌子无限延伸，是把这一切当乐子传来传去的网民们平庸而麻木的恶毒。我们本应该意识到这个名字是不应该出现在大众视野的，我们本应该意识到有些话题是远远超出这个议题本身的讨论场域的。但没有，武大两个字盖过了一切，我们想都不想就开始对这个话题表态，但是朋友们，读者们，读到这里认同或不认同我的各位。这本来不该是一个议题啊，这个议题的发起就是非正义的啊！

真的，我感到出离的愤怒，然后是一身冷汗。

武大的回应，和《珞珈山上》对回应的回应

在自图书馆时间后接踵而至的许多真假参半的指责与碰瓷中，提了武大真是就跟买了流量一样好用。当然，我既然不认同诛心之论，也就不能自己开始对批评武大的人诉诸动机，所以这些揣测就此打住。来说一说这几次对垒。

说到武大的回应。我个人是站在冷处理一侧的。此时的武大正是多事之秋，处在一种类似"塔西佗陷阱"的恶性循环中，任何回应都有可能称为攻击与风暴新的立足点，被歪曲炮制成新的枪弹和火药，让舆论自然沉降，不给恶意的声音递刀子，这是我秉持的观点。既然舆论是因为武大的帽子有流量吃而起，难道就会因为你的切割就真的切割了吗？显然不会。因为舆论就是冲着武大来的。

在之前写南京大学的那篇文章中我引用了我在空间中发表的一小段文字，我现在再次在这里引用。因为自始至终，只要恶意涌动的方向没有变化，这句话就还能再被我引用一万次。

我不想说什么诸如"不分青红皂白选择一竿子打死的人都是上不起985的红眼loser"这种无谓的诛心之论，只是祝愿各位在被裹挟着的舆论彰显出的所谓"民意的铁拳"砸到自己身上的时候，也能有诋毁别人学校时那样的镇定与愉悦。

风暴中心的所有人

这些天听到最多的一句话就是"怎么又是武大"。是啊，怎么又是武大呢？

事实上，我会说"又是武大"是一个自指预言。

从图书馆事件开始，武大一头撞在了高度极化的性别议题上，承受了汹涌澎湃的舆论拷问，自那之后，社会开始以其他学校从未经历过的眼光审视武大的一举一动，拿着放大镜让一所大学承受了数倍于之前的审视。过往的旧事被一件件起底，新出的事件，有的是确有其事被放大或歪曲（用来标定I LOVE WHU的红点被说是致敬日本国旗），有的是根本没事被编造成虚假叙事（"武大支持吸毒事件"中朱征夫被造谣是武大法学院教授，因儿子吸毒而推动吸毒记录封存）。世界上一天发生的事情千千万，报道清华团队为国做的贡献不如报道清华留学生多、是美西方势力培养基地，这是一点都不令人奇怪的。好事不出门，恶事传千里。自古以来人们对正面叙事的不信任和对负面评价的相信倾向让武大"坐上了舆论的审讯椅，就难以下来"，这也是一点都不令人奇怪的（当然，令人叹息）。

那么，下面我不得不诉诸动机说一点我自己的真实想法了：

"武大"自带的流量标签让武大相关的事件更容易从舆论场中脱颖而出（甚至不惜在其中混杂别有用心的谣言，比如基于PS技术的武大校徽天皇皇冠论），推动"又是武大"的刻板印象，让人们为了找乐子，享受成为"又是武大"的推手被瞩目的感觉而主动积极地去寻觅武大的黑料，把关系甚小甚至毫无关系的脏水往武大身上泼，一次次为"又是武大"添砖加瓦。事实上，不仅武大经历过这样的负面循环，川大也经历过类似的事件，浙大被翻旧账之后也几乎成了"共和国强奸犯的摇篮"。好吧，好吧，中国人自己学会用黄祸论的那一套东西搞自己人了。

如果没有《珞珈山上》的社评，我真的不敢在互联网上发言。我怕因为我的ip，就被人说"武大的狗又来护着自己的主子了"，在一个"Br0"，"母人"，"小仙女"，"下头男"种种帽子立等可取，"屁股决定脑袋"论和"抛开事实不谈，先告诉我你的立场"的时代，武大两个字分量真是出奇地重，重到想说点什么的时候，嘴就打不开了。

那，我又能再说些什么呢。就此住笔吧。

后记

文章写完的时候下课铃正好敲响，自习教室的人们从沉思中抬起头，收拾收拾东西，准备去梅园食堂吃饭。夕阳洒在教室的课桌上，半开的窗边窗帘轻轻飘着，远处有青草的香气。晚上还有世界史考试呢，先复习吧。

愿珞珈常青，弦歌不辍。

WHUCTF 2026 校赛后记

Sat, 02 May 2026 00:00:00 GMT

import { Masonry } from 'astro-masonry'

为什么我没有放上WHUCTF2026的WP呢？

在我昨天晚上把自己的博客文章从头到尾读了一遍之前，我甚至觉得这个话题完全没有单独写一篇博客的意义。毕竟不想写就是不想写，是一种感觉，哪里能说道出那么多的大概念呢？

最主要的原因当然是因为我也是可悲的梭狗。有两道题我看都没看，直接喂给GPT写，我再把GPT写的WP放上来——这不觉得贱得慌吗？写WP是记录自己的思路，希望给后人启发，我别说思路了，思都没思，把这么一篇自己一个字都没有过目的“文字的排列组合”以自己的名义发布在自己的博客上，既让人觉得膈应和恶心，也未免有不尊重自己的个人品牌，砸自己招牌，毁自己声誉之嫌。

至于其他勉强能算得上“自己解出”的题，也无非是让GPT一层层推进代码逆向，命令它读逻辑，重命名符号，写模拟脚本，写解密脚本——是的，即使是我厚颜无耻说“并非梭出”的题，也不过是把AI自己思考要干啥变成了我思考AI下一步要干啥（并下命令），把手弄脏的始终不是我，每一道题我都做得“脚不沾地”。

人与自己的造物疏离了，疏远的沟壑中间是冰冷冷的智能，题目于我变成黑盒，我于题目变成看客。但没关系，我有Token可烧，让AI去做脏活累活吧，不是因为你要增质提效，是因为你知道你根本就不会这些东西。那些看起来繁琐的跟栈，读汇编，写脚本，跑模拟，看起来能被AI替代掉的活，你其实一点都不会，你之所以还道貌岸然地坐在选手席上只是因为你知道你给Opus 4.6充了足够的钱，它能继续稳定地给你这种无所不能的幻觉。

拿到题，哦，是VM（虚拟机保护），好吧，告诉AI说这是一个VM挑战，帮我找到Dispatcher，分析字节码类型和handler table，写simulation.py。看起来你什么都知道，但上面每一步你都只是重复了Wiki上说的那些高屋建瓴泛泛而谈的东西。你觉得你什么都知道了，思路如此清晰，但你其实根本不知道什么是Dispatcher，如何把Handler Table从密密麻麻的汇编里拎出来。OK，那你只能把自己全部的身家性命压在这个概率机器上了。一旦选择开始梭，要么成功，要么从零开始。

“梭”这个东西从一开始就是一场赌博，绝无可能让一个人“先让AI做”，等AI出麻烦了再“人类介入干预”。别做梦了，你跟AI共享了一丝一毫上下文吗？AI做了一半的题对你来说就是完全陌生的东西，等你自己跟着AI的思路把题看一遍，比赛是否还在继续暂且不论，耗时跟你自己从头做一遍也没啥区别了，白白浪费Token，增加复杂度。

那让AI每一步都写文档，不就可以共享上下文了吗？首先，AI既然已经卡在半路了，就说明它之前的某个步骤错了，哪个步骤呢？你要不要一步一步排查呢？其次，看过WP的都知道，看别人写的东西和自己亲自写一遍，差异是天差地别的，就像把高数课本通读一遍不如自己动手做题，把汇编教材翻烂不如跟着gdb自己单步调试一个程序，你看完了AI的解题思路，再打开IDA看题，依然“圣质如初”，不知道从何下手。因此，“赌”恐怕是每个梭狗都不得不选择的信仰之跃。

没有AI做不来题的人类，做着为了防AI出得诘屈聱牙的怪题，真可谓是一对苦命鸳鸯。

另外，还有两个点值得提一提。

第一个是我在提交给主办方的WP开头写的一段话，我想放在这里很合适：

注：本场比赛由于时间原因（比赛时限内尽可能追求多的解出 + 比较紧张的WP提交时间无法确保赛后复现），会有一些题是AI解出，AI写WP。这类题目我们会标记为“[梭]”，评审组可选择跳过不看，但此类题目的开头末尾一般会有解题者想说的话，也有一些对于规则和技术的感慨。

AI解出并不一定等同于选手能力不足，也许更是竞赛属性导致的对分数的天生追求，和对“别人都在梭，三血只是不同的人在浪费codex的token做着一样事情”的不忿而催生的某种必然。我无意用这些话语为我们的放弃思考“脱罪”，只是想将事实与我们的思考呈现在各位眼前——有人的地方就有江湖，hack for fun从来只有置身事外的人能心安理得地喊。

愿竞赛回归本质，祝CTF一切都好，大家一切都好。

另一个是我在一位朋友的邀请下玩了玩BombLab，在两天时间里对这个简单到不能再简单的逆向题进行了分析，没有使用IDA，没有看任何反编译结果，gdb下断，跟栈，用rizin辅助了一下看汇编（还是那个原则，没有使用rz-ghidra反编译），手动编写反编译代码（我不会用python，所以代码全部用c++写出）。整整两天，不紧不慢，没有什么分数和时间在催着我，我得以完全沉浸在逆向的快乐中，学到了去年半年都没有学到的调试和汇编的知识，看花指令，分析控制流，乃至人肉反汇编，似乎突然就得心应手了。

第一次，我对以赛促学的口号产生了一点怀疑。但可能并不是口号错了，也不是我们错了，只是口号和我们错配了吧。

比赛结果是总榜第二，前面由于几道RE梭得太厉害了，VM放题后几分钟就有解出，“抢血”实在是不那么现实，没办法，第二就第二吧~

队友们真的都很给力，Web手忙得觉都没睡好，凌晨惊醒想到了新的攻击思路；Crypto手要同时身兼密码和Misc两个方向，人和AI都忙得脚不沾地；Pwn手独自坚守在AI无能为力的阵地，手搓脚本和友队另一个巨神结结实实较量了一场；至于我，虽然一血拖了后腿，但好再最后还是AK了Re方向，没太丢人。最重要的一点是，大家都很团结，打完校赛后会互相安慰，互相鼓励。

感谢大家，各位都辛苦了，能遇见各位真是太幸运了。

那么最后，暂时地，再见了，所有的CTF。

<Masonry breakpointCols={{ default: 2, 640: 1 }} class="flex gap-4 px-4"

DevEco Studio 移植笔记

Fri, 30 Jan 2026 00:00:00 GMT

前几个月买了个华为的平板，一直想趁机搞搞鸿蒙开发，但苦于 DevEco 不支持 Linux，遂开始考虑是否可能进行移植。

准备工作

获取 DevEco Studio 的 Windows版

我们这里从华为官方下载Windows版本的安装包（本文撰写时可下载的版本是DevEco Studio 6.0.2 Release），通过wine安装即可。安装配置全部保持默认，则DevEco的程序本体应该在~/.wine/drive_c/Program Files/Huawei/DevEco Studio下，我们进入该目录。

获取 IDEA

由于目前的 DevEco Studio 是基于IDEA修改制作而成的，所以我们需要一份IDEA的Linux版作为参考，我下载的版本是2025.3.2。

进行解压和整理后我们的目录格式如下：

.  
├── DevEco Studio  
│   ├── bin  
│   ├── ......
│   └── tools  
└── idea-IU-253.30387.90  
	├── bin  
	├── ......
	└── plugins

移植环境

移植JBR

JBR ( Jetbrains Runtime ) 是由 JetBrains 制作的 JDK 改版，我们下载 IDEA 时就已经包含在内。直接复制替换DevEco Studio中的jbr目录即可。

当然，IDEA 和 DevEco 使用的 JBR 版本不一定相同，如果你希望 JBR 版本完全匹配，可以通过wine打印一下DevEco的jbr版本，再到Github上进行下载。

移植Node

华为的构建工具要么是用nodejs写的要么使用python写的，查看tools/node，发现NodeJS版本是v18.20.1 LTS，于是在官网下载该版本，解压，替换原目录。（这里为了和Windows版本的目录结构保持一致，我将node/bin子目录下的文件全部软链接到了node目录）

此时tools目录下应该有node文件夹。

替换libs

进入lib目录，复制 IDEA 样本中的native, pty4j, jna三个目录并替换DevEco中的目录

替换OpenHarmony SDK

这里用下载好的OpenHarmony SDK替换sdk/default/openharmony即可。（至于如何下载，可以直接使用DevEco提供的下载工具，你可以先跳过本步，做完其他步骤，之后应该能在Linux上打开它并下载SDK了）

逆向官方启动器

由于华子大概率是直接搬的官方启动器，这里我直接用 ida 逆了 bin/idea。最有用的函数应该是xplat_launcheer::main_lib。~~在GPT的帮助下得出的~~ 结论如下：

启动器使用~~世界上最好的语言~~ Rust 编写
启动器加载时会向当前目录的上层递归读取product-info.json文件，最大深度为5
启动器会加载properties文件，具体加载的是

因此，我们通过编写product-info.json和devecostudio.vmoption，即可完成最后的移植工作。

编写相关配置文件

这部分就不多赘述，给出可以抄作业的VMOption & product-info & idea properties:

// product-info.json
{  
"name": "DevEco Studio",  
"version": "6.0.2.640",  
"versionSuffix": "",  
"buildNumber": "243.24978.46.36.602640",  
"productCode": "DS",  
"envVarBaseName": "DEVECOSTUDIO",  
"dataDirectoryName": "DevEcoStudio6.0",  
"svgIconPath": "bin/devecostudio.svg",  
"productVendor": "Huawei",  
"launch": [  
{  
"os": "Linux",  
"arch": "amd64",  
"launcherPath": "bin/devecostudio",  
"javaExecutablePath": "jbr/bin/java",  
"vmOptionsFilePath": "bin/devecostudio64-lin.vmoptions",  
"startupWmClass": "deveco-studio",  
"bootClassPathJarNames": [  
"platform-loader.jar",  
"util-8.jar",  
"util.jar",  
"util_rt.jar",  
"opentelemetry.jar",  
"app.jar",  
"stats.jar",  
"jps-model.jar",  
"external-system-rt.jar",  
"rd.jar",  
"bouncy-castle.jar",  
"protobuf.jar",  
"forms_rt.jar",  
"lib.jar",  
"externalProcess-rt.jar",  
"groovy.jar",  
"annotations.jar",  
"hwlib.jar",  
"idea_rt.jar",  
"kotlinx-coroutines-slf4j-1.8.0-intellij.jar",  
"nio-fs.jar",  
"trove.jar"  
],  
"additionalJvmArguments": [  
"-Djava.system.class.loader=com.intellij.util.lang.PathClassLoader",  
"-Didea.vendor.name=Huawei",  
"-Didea.paths.selector=DevEcoStudio6.0",  
"-Djna.boot.library.path=$IDE_HOME/lib/jna/amd64",  
"-Dpty4j.preferred.native.folder=$IDE_HOME/lib/pty4j",  
"-Djna.nosys=true",  
"-Djna.noclasspath=true",  
"-Dintellij.platform.runtime.repository.path=$IDE_HOME/modules/module-descriptors.jar",  
"-Didea.platform.prefix=DevEcoStudio",  
"-Dsplash=true",  
"-Daether.connector.resumeDownloads=false",  
"-Dcompose.swing.render.on.graphics=true",  
"--add-opens=java.base/java.io=ALL-UNNAMED",  
"--add-opens=java.base/java.lang=ALL-UNNAMED",  
"--add-opens=java.base/java.lang.ref=ALL-UNNAMED",  
"--add-opens=java.base/java.lang.reflect=ALL-UNNAMED",  
"--add-opens=java.base/java.net=ALL-UNNAMED",  
"--add-opens=java.base/java.nio=ALL-UNNAMED",  
"--add-opens=java.base/java.nio.charset=ALL-UNNAMED",  
"--add-opens=java.base/java.text=ALL-UNNAMED",  
"--add-opens=java.base/java.time=ALL-UNNAMED",  
"--add-opens=java.base/java.util=ALL-UNNAMED",  
"--add-opens=java.base/java.util.concurrent=ALL-UNNAMED",  
"--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED",  
"--add-opens=java.base/java.util.concurrent.locks=ALL-UNNAMED",  
"--add-opens=java.base/jdk.internal.vm=ALL-UNNAMED",  
"--add-opens=java.base/sun.net.dns=ALL-UNNAMED",  
"--add-opens=java.base/sun.nio.ch=ALL-UNNAMED",  
"--add-opens=java.base/sun.nio.fs=ALL-UNNAMED",  
"--add-opens=java.base/sun.security.ssl=ALL-UNNAMED",  
"--add-opens=java.base/sun.security.util=ALL-UNNAMED",  
"--add-opens=java.desktop/com.sun.java.swing=ALL-UNNAMED",  
"--add-opens=java.desktop/com.sun.java.swing.plaf.gtk=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.dnd.peer=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.event=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.font=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.image=ALL-UNNAMED",  
"--add-opens=java.desktop/java.awt.peer=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.plaf.basic=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.text=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.text.html=ALL-UNNAMED",  
"--add-opens=java.desktop/javax.swing.text.html.parser=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt.X11=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt.datatransfer=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.awt.image=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.font=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.java2d=ALL-UNNAMED",  
"--add-opens=java.desktop/sun.swing=ALL-UNNAMED",  
"--add-opens=java.management/sun.management=ALL-UNNAMED",  
"--add-opens=jdk.attach/sun.tools.attach=ALL-UNNAMED",  
"--add-opens=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED",  
"--add-opens=jdk.internal.jvmstat/sun.jvmstat.monitor=ALL-UNNAMED",  
"--add-opens=jdk.jdi/com.sun.tools.jdi=ALL-UNNAMED"  
],  
"mainClass": "com.intellij.idea.Main"  
}  
],  
"bundledPlugins": [],  
"modules": [],  
"fileExtensions": [],  
"layout": []  
}

# devecostudio64-lin.vmoptions
-Xms256m  
-Xmx2048m  
-XX:ReservedCodeCacheSize=512m  
-XX:CICompilerCount=2  
-XX:+HeapDumpOnOutOfMemoryError  
-XX:-OmitStackTraceInFastThrow  
-XX:+IgnoreUnrecognizedVMOptions  
-XX:+UnlockDiagnosticVMOptions  
-XX:TieredOldPercentage=100000  
-ea  
-Dfile.encoding=UTF-8  
-Dsun.java2d.metal=true  
-Dawt.lock.fair=true  
-Dsun.io.useCanonCaches=false  
-Djdk.nio.maxCachedBufferSize=2097152  
-Djava.util.zip.use.nio.for.zip.file.access=true  
-Djava.nio.file.spi.DefaultFileSystemProvider=com.intellij.platform.core.nio.fs.MultiRoutingFileSystemProvider  
-Djdk.attach.allowAttachSelf=true  
-Dsun.tools.attach.tmp.only=true  
-Djdk.http.auth.tunneling.disabledSchemes=""  
-Djdk.module.illegalAccess.silent=true  
-Djbr.catch.SIGABRT=true  
-Dkotlinx.coroutines.debug=off  
-Djava.security.manager=com.intellij.platform.core.nio.fs.CoreBootstrapSecurityManager

# idea.properties

# ---------------------------------------------------------------------  
# DevEco Studio - Linux
# Based on IntelliJ Platform 243.x  
# ---------------------------------------------------------------------  
  
# Use ${idea.home.path} macro to specify location relative to IDE installation home.  
# Use ${xxx} where xxx is any Java property (including defined in previous lines of this file)  
# to refer to its value.  
  
# ---------------------------------------------------------------------  
# Paths (use defaults unless you really need to override)  
# ---------------------------------------------------------------------  
# idea.config.path=${user.home}/.DevEcoStudio/config  
# idea.system.path=${user.home}/.DevEcoStudio/system  
# idea.plugins.path=${idea.config.path}/plugins  
# idea.log.path=${idea.system.path}/log  
  
# ---------------------------------------------------------------------  
# File size limits  
# ---------------------------------------------------------------------  
idea.max.intellisense.filesize=2500  
idea.max.content.load.filesize=20000  
  
# ---------------------------------------------------------------------  
# Console & process behavior  
# ---------------------------------------------------------------------  
idea.cycle.buffer.size=4096  
idea.no.launcher=false  
idea.dynamic.classpath=false  
  
# ---------------------------------------------------------------------  
# UI / Window manager behavior  
# ---------------------------------------------------------------------  
idea.popup.weight=heavy  
  
# ---------------------------------------------------------------------  
# Graphics & rendering (Linux-safe)  
# ---------------------------------------------------------------------  
sun.java2d.d3d=false  
sun.java2d.pmoffscreen=false  
swing.bufferPerWindow=true  
sun.java2d.uiScale.enabled=false  
javax.swing.rebaseCssSizeMap=true  
  
# ---------------------------------------------------------------------  
# Accessibility & stability (JBR)  
# ---------------------------------------------------------------------  
javax.swing.JTree.excludeAccessibleChildrenFromClosedNodes=true  
sun.awt.mac.a11y.tableAccessibleRowCountThreshold=1000  
sun.lwawt.macosx.LWCToolkit.invokeAndWait.disposeOnEDTFree=true  
  
# ---------------------------------------------------------------------  
# Smooth scrolling (disabled by default, stable choice)  
# ---------------------------------------------------------------------  
# idea.true.smooth.scrolling=true  
  
# ---------------------------------------------------------------------  
# DevEco specific: plugin compatibility baseline  
# IMPORTANT: keeps DevEco plugins from behaving like pure IDEA plugins  
# ---------------------------------------------------------------------  
idea.plugins.compatible.build=IC-243.24978.46  
  
# ---------------------------------------------------------------------  
# HarmonyOS / DevEco toolchain (keep even if commented)  
# ---------------------------------------------------------------------  
# ide.harmonyos.sdk.location=/path/hosdk/  
# ide.ohpm.location=/path/ohpm  
# ide.hvigor.location=/path/hvigor  
# ide.node.location=/path/node  
# ide.emulator.location=/path/emulator  
  
# ---------------------------------------------------------------------  
# ArkTS / Node related limits (optional)  
# ---------------------------------------------------------------------  
# arkts.server.max.intellisense.filesize=10240  
# arkts.server.max.old.space.size=8192  
  
# ---------------------------------------------------------------------  
# Error handling  
# ---------------------------------------------------------------------  
idea.fatal.error.notification=disabled

这里值得注意的一个 fun fact 是：如果你使用sun.java2d.uiScale=true开启 IDEA 推荐的 Scale by OS，华为奇怪的插件加载机制会搞砸一切！所以这里设置为false，我们就完成了全部的移植工作。

处理签名问题

此时的DevEco看起来已经可以正常开发了，但在签名时会遇到奇怪的问题：

2026-02-05 22:20:54,000 [ 490226]   WARN - #com.huawei.deveco.projectmgmt.hos.s  
ignature.sign.utils.AutoGenerateKeyCSRUtil - No available JDK is found.  
2026-02-05 22:21:00,716 [ 496942]   WARN - #com.huawei.deveco.projectmgmt.hos.s  
ignature.sign.utils.AutoGenerateKeyCSRUtil - No available JDK is found.

我们使用 Recaf 逆向该组件。（如果有做Java逆向的朋友，真心推荐Recaf，目前用过的最好用的Java反编译/字节码修改工具，绝对的神器级别）。组件位置是plugins/harmony/lib/hos-project-mgmt-6.0.2.640.jar，相关代码是：

String toolPath = homePath + TOOL_PATH;              // /jbr/bin
if (SystemInfo.isMac || SystemInfo.isLinux) {
    toolPath = homePath + MAC_TOOL_PATH;             // /jbr/Contents/Home/bin
}

也就是说 Linux 被直接和 Mac 划到一起去了，组件找寻 jbr/Contents/Home/bin/keytool，二实际路径是jbr/bin/keytool。

因此我们“伪装路径”，具体方法不做赘述。

移植“模拟器”

由于鸿蒙的模拟器不开源，我们显然无法强行兼容之，所以这里采用 Oniro Emulator。按照其要求安装配置即可。

效果

一份莫名其妙的C语言速查表

Fri, 16 Jan 2026 00:00:00 GMT

import { Aside } from 'astro-pure/user'

输入读取

读取整行字符串（包括空格）

char line[200];
fgets(line, sizeof(line), stdin);

连续读多行直到 EOF

char s[200];
while (fgets(s, sizeof(s), stdin)) { 
	// 处理每一行 
}

处理单行多元素输入

用 strtok 分割：

char s[200]; 
fgets(s, sizeof(s), stdin); char *p = strtok(s, ",");
while (p != NULL) {
	int x = atoi(p); 
	// 用 x 
	p = strtok(NULL, ","); // 从原位置继续往后切
}

用空格分开时将 strtok 的分隔符设置成空格即可。

对于存入数组的情况：

char line[200];
int arr[50], cnt = 0;
fgets(line, sizeof(line), stdin);
char *p = strtok(line, " ");
while (p != NULL) {
	arr[cnt++] = atoi(p);
	p = strtok(NULL, " ");
}

连续读取未知数量数字直到换行

int x;
while (scanf("%d", &x) == 1) { 
	// 用 x 
	if (getchar() == '\n') 
		break; 
		// 换行就停 
}

读取带空格的单词，直到遇到换行

示例输入：
apple banana orange

char s[100]; 
while (scanf("%s", s) == 1) { 
	// 处理 s 
	if (getchar() == '\n') 
		break; 
}

字符串 → 数组 → 排序

char line[200];
int arr[100], cnt = 0;

// 读取整行
if (fgets(line, sizeof(line), stdin) == NULL) return 0;

// strtok 分割（空格分隔）
char *p = strtok(line, " \n"); // 顺便把 '\n' 也当分隔符
while (p != NULL) {
    arr[cnt++] = atoi(p);
    p = strtok(NULL, " \n");
}

// 排序
qsort(arr, cnt, sizeof(int), cmp);

字符串处理

记得要引入 string.h 才能使用下列方法

长度/比较

#include <string.h>
size_t len = strlen(s); 
int r = strcmp(a, b); // <0, =0, >0

子串检索

char* p = strchr(s, 'x');   // 第一次出现 'x' 的位置
char* q = strstr(s, "abc"); // 第一次出现子串 "abc"的位置

分割字符串

#include <string.h> 
char line[200]; 
fgets(line, sizeof(line), stdin); 
for(char* p = strtok(line, " ,\n"); p; p = strtok(NULL, " ,\n"))
{ 
	// p 是每个 token
}

这里 for 循环中的 p 等价于 p!=NULL，后面传入 NULL 表示从上一次 strtok 停下的位置继续往后切。

类型处理

记得要引入 ctype.h 才能使用下列方法

isdigit：是否是数字字符 '0'..'9'
isalnum：是否是字母或数字（混合判断）
isspace：是否是空白字符（空格、换行、Tab 等）
islower / isupper：是否是小写 / 大写字母
tolower / toupper：大小写转换

这几个因为用法太显而易见了就不给示例了。

妙妙工具

Qsort

记得引入 stdlib.h。基本用法形如：

qsort(base, n, size, cmp);

base：数组首地址（比如 arr）
n：元素个数
size：每个元素的字节数（通常 sizeof(arr[0])）
cmp：比较函数指针（你自己写，决定升序/降序/按什么字段排）

使用示例：

给 int 数组升序排序

#include <stdio.h>
#include <stdlib.h>
int cmp_int_asc(const void *a, const void *b) {
	int x = *(const int*)a;
	int y = *(const int*)b;
	return (x > y) - (x < y); // 避免 x-y 溢出 
}

int main() {
	int arr[] = {10, 3, 25, -7, 8};
	int n = sizeof(arr) / sizeof(arr[0]);
	qsort(arr, n, sizeof(arr[0]), cmp_int_asc);
	
	for (int i = 0; i < n; i++)
		printf("%d ", arr[i]);
	return 0;
}

cmp 返回值的规则比较函数 cmp(a,b) 必须满足：

返回 < 0：表示 a 应该排在 b 前面
返回 0：表示相等
返回 > 0：表示 a 应该排在 b 后面

排结构体

假设要按 score 升序排，score 相同按 id 升序：

typedef struct {
	int id;
	int score;
} Node;

int cmp_node(const void *a, const void *b) {
	const Node *x = (const Node*)a;
	const Node *y = (const Node*)b;
	if (x->score != y->score)
		return (x->score > y->score) - (x->score < y->score);
	return (x->id > y->id) - (x->id < y->id);
}

int main() {
	qsort(nodes, n, sizeof(nodes[0]), cmp_node);
}

Printf 格串

补零（或者补别的什么）

printf("%05d\n", 42);   // 00042
printf("%02d:%02d\n", 3, 7); // 03:07

精度（保留位数）

浮点：控制小数位数（四舍五入）

printf("%.2f\n", 3.14159); // 3.14 
printf("%.0f\n", 3.9);     // 4

字符串：最大输出长度

printf("%.3s\n", "abcdef"); // abc

动态宽度/精度

宽度由参数给：

int w = 8; 
printf("^%0*d^\n", w, 123); // "^00000123^"

内存操作

`malloc`：申请一块未初始化的内存

特点：申请到的内容是垃圾值，要手动初始化。

int n = 10;
int *a = (int*)malloc(n * sizeof(int)); // 申请10个int  
if (a == NULL) {     
	// 内存不足
}

`calloc`：申请 + 自动清零

int n = 10;
int *a = (int*)calloc(n, sizeof(int)); // 10个int，全部为0

（这俩都是用完要 free() 的，你最好别忘了）

Memset

int a[100]; memset(a, 0, sizeof(a));

Memcpy

int a[5] = {1,2,3,4,5};
int b[5];
memcpy(b, a, sizeof(a));

文化常识（确信）

ASCII 相关

计数排序必需品：

大写字母范围是 65 ~ 90
小写字母范围是 97 ~ 122
'0' = 48
'9' = 57

标准 ASCII 可打印字符是：

32 ~ 126（共 95 个）
其中 32 是空格 ' '

位运算

| & | 按位与操作，按二进制位进行"与"运算 | (A & B) 将得到 12 即为 0000 1100 | | ---- | ------------------- | -------------------------------- | | \| | 按位或运算符，按二进制位进行"或"运算 | (A \| B) 将得到 61 即为 0011 1101 | | ^ | 异或运算符，按二进制位进行"异或"运算 | (A ^ B) 将得到 49 即为 0011 0001 | | ~ | 取反运算符，按二进制位进行"取反"运算 | (~A) 将得到 -61 即为 1100 0011 | | << | 二进制左移运算符 | A << 2 将得到 240 即为 1111 0000 | | >> | 二进制右移运算符 | A >> 2 将得到 15 即为 0000 1111 |

Break & continue

Break 跳出整个循环体，continue 步出单次循环

数组指针 & 指针数组

指针数组

int *p[3];

含义：p 是一个长度为 3 的数组，p[i] 是 int*

char *s[3] = {"aa", "bb", "cc"};
printf("%s\n", s[1]); // bb

数组指针

int (*p)[3];

int a[2][3] = {{1,2,3},{4,5,6}};
int (*p)[3] = a;      // 指向第0行
printf("%d\n", p[1][2]); // 6

二维数组

int a[2][3] = {
    {1, 2, 3},
    {4, 5, 6}
};
// a 是一个2个元素的数组，每个元素是一个3个元素的数组
// 也就是：int[3] t[2]; 本质上 [3] 和 int 配对

行指针 & 列指针

行指针

行指针 = 指向“一整行”的指针
也就是：指向 int[列数] 这种数组的指针。

如果有 4 列：

int (*row)[4];

row 指向第 0 行
row + 1 指向第 1 行（因为它知道“一行有 4 个 int”）
row[i][j] 可以直接当二维数组用

列指针（其实就是普通的元素指针）

int *p = &a[0][0];

此时 p + n 指向的元素是：

第几行：row = n / C
第几列：col = n % C

结构体

结构体的声明（反正我直接用 typedef 了）

typedef struct {
	int x;
	int y;
} Point; // 相当于将一个匿名结构体绑定给 Point 了

Point p = {0, 0};

允许函数以结构体为返回值，此时发生拷贝。

判断傻逼类型注释的技巧

从右向左螺旋读，遇到括号时被“挡住”。 例如对于这个愚蠢至极的数组指针定义：

int (*p)[3];

这次括号把 *p 绑定在一起了：

从 p 开始读：

(*p)：说明 p 是指针（因为要先解引用）
(*p)[3]：解引用后得到的东西是数组（长度 3）

所以它是数组指针：p 是指针，指向“3 个 int 的数组”

让我们告别2025

Mon, 29 Dec 2025 00:00:00 GMT

很难相信我度过了一个怎样的2025，上半年和下半年割裂得像是两年压缩进了一年——六月前还满脑子学习，喜欢在周末带着作业听着喜欢的播客泡在咖啡馆里，九月后却又背着电脑疲于奔命在劳累与焦虑中。不过客观来说，我的2025过得还是挺充实的。

讲真，我真的觉得我的高三挺美好的，说这句话并不意味着孩子被优绩主义PUA傻了，我怀念的是那些从夹缝中挤出的 do something fun 的时间和那些有一搭没一搭地日常玩笑着的友人。

我在2024年终总结里写过这样一段话：

Spotify的免费版14天会掉登录，在手机上还好说（进行一些科学处理），手表上可着实有点难受了，于是每两周不得不抽出一天来回家重新登录Spotify（这方面内容先按下不表），不过激活之后Spotify的体验堪称优秀，我喜欢的播客和音乐直接受藏到音乐库就可以随时收听了。Spotify Wear最近的一次更新还加入了搜索功能，这下好了，抛掉手机吧少年（笑）。

真的满足了吗？完全没有，我想念我的小宇宙，想念我的订阅列表和第一时间同步的更新，也想念评论区的互动。那么怎么办呢？既然没有一个Wear专属的小宇宙，就自己做一个吧！抱着这样的想法，从寒假开始动工，到三月最后一次commit，一个播客App逐渐成型。

取Casmos这个名字的原因也很简单——对应播客的Cast融合对应小宇宙英文名的Cosmos。开发Cosmos的这段时间真是我那几个月最快乐的时候，每当一个新的API接口点亮一个亲手搭建的组件或界面，那种喜悦和成就感都是无以复加的，我想起了几年前熬夜写星火的投稿器和AppimageToDeb工具的时候，熬大夜而满心欢喜，又或是前年筹备班会展示情景剧时通了一个星期宵的热情，人最幸福的不就是干自己喜欢的事吗。现在想来，其实有点项目当时的我。

当然，播客之外，高三的备考生活总还是紧张劳累的，不过我的成绩倒没有那么令人紧张，所以我的心态整体还是不错的。每个周末把卷子夹成一摞，带到书店去，伴着一杯咖啡和几集播客不紧不慢的写完，全身心沉浸在推理和死思索中，其实还蛮惬意的哦。

回忆起来，陪伴着我度过高三的是两件事，一个是每天晚自习放学后偷偷溜到乒乓球台跟朋友们打球，另一个是每周六早上都可以早起去校门口搞杯瑞幸，收获一天的幸福感。两件小小的事，现在想来也算是我的精神寄托了吧。

说实话，我很爱我的老师们，他们都是很好的老师，教导有方，也不会说散布很保守很古老的“万般皆下品”之类的价值观，而是很尊重我们的喜好和兴趣。我记得我的生物老师默许我两年不写生物作业，我还经常跑到她办公室要零食；语文老师也喜欢跟我分享各种有趣的文章，并愿意接受我拿各种社论，诗歌和小说当作周末作业交上去（真的可以的）；物理老师有点唯读书论，但日常生活中也很体贴人，经常跟我们道歉（把我们没做对题的问题很真诚地怪罪到自己身上）；数学老师是个有数学情怀的人，我印象很深的他的一句话是“这个不考，但我觉得如果这种思维都不学的话你们的数学算是白学了”，经常分享一些数学史的小趣闻，也会鼓励同学们深入研究某个问题后整理成论文投稿。每当想起他们，我就会惧怕自己考不好，辜负了他们的宽容和用心，越这样想越焦虑，越焦虑越控制不住往坏处假设。焦虑是最好的咖啡因。

而我的高考，大概就是被这样的焦虑毁掉的吧。

第一天进考场时下着大雨，我不想找借口说大雨毁了我的大学梦之类的，但就是没发挥好，看到作文的一刻脑子是晕的——不再是多元思辨，而是一篇没有明显概念冲突点的歌功颂德。就像让一个惯用戏剧冲突塑造主线的编剧写一篇合家欢，他自然不自觉地开始歪曲起了题意，试图从中提炼出那么一些对立的观点进行思辨。结局是悲惨的，他的语文只考进了很低的110档位，远低于他的预期。

中午我没有睡着，也没心思复习数学，带着满眸的死灰踏进数学考场，却出乎意料考得还不错，最后几分钟在漫无目的地瞎看中看出了解析几何的隐藏条件，顺利拿分，最终考了138。唯一的小遗憾可能就是最后一题第三问看到时间不多而慌乱，导致没仔细做。不过比起我的平均水平，这次的数学无疑考得扬眉吐气的。

随后的物理英语化学像是走马灯一样闪过，我完全不记得自己考了什么，考得如何，但分数是一样的低，物理我记不得多少分了，但应该也就60或70左右吧，化学也只有80多，最令我痛心的是生物，考了我有史以来最差的分数：连90都没有，卡在了89。

也许是预感到了什么，我考生物前一天的晚上哭着跟我的生物老师说我对不起她，她安慰我让我早点睡，我更睡不着了，一直哭。现在想来，也许那是一个自我指涉的预言。

高考那几天一直在下雨，我记得

不过，过去的总归是过去了，（毫无意外地）没有考上自己心中的南京大学，，最后还是选择了家门口的武汉大学，却发现这的校园真的很美，也不失为一个意外的收获。至少在这件事上，算是上天最好的安排了。

如果你看过我的南京游记，你应该记得我对这座城市的热爱。现在回忆起来，其实南京和杭州都是美好的回忆，去灵隐寺的那天大雨倾盆，灰黄的寺墙在雨中褪色，虽无钟声，却让人心静。

然而在灵隐寺求的高分似乎没那么灵验😭。算了，自己没救谁也救不了，就不大书哀怨了。

旅行生活结束后很是清闲了一阵子，突然想减肥就去办了健身房的月卡，每天晚上去撸会铁，跑跑步，感觉也没啥效果hh，倒是力气似乎是大了一些的。暑假还尝试着自己做了葡萄柠檬茶，效果非常之堪忧（悲叹）。每天晚上实在不知道干啥了就会去散步，从家门口出发，选一个方向一直走啊走啊走，有一次走了六七公里后越来越偏，快走到郊区了😂。

心想着这样闲不行啊，这样子闲肯定绝对显然是不行的啊，就去找了个助教的活干着。每天帮忙改改作业，收收本子管管午休，和一帮本来根本叫不上名字的学生逐渐熟络起来，也习惯了每天早起，在地铁上掐准麦当劳开业的时间点一份早餐外卖，坐在位子上美美享用。同事们人很好，如果有人的活特别多或者当天出了特殊情况，大家都会主动帮忙。记得有一次忙里偷闲晚上跟一个同事出去捞了一顿巨贵无比的烤肉（于是自那以后我就成了烤肉的忠实拥趸，每个月都要吃一两次hh）。

七月下旬时，一切尘埃落定：信息安全。也好，那就开始新的一段旅程吧，我开始捡起尘封的CTF工具，不过不再是小学时候喜爱的Web安全（妈的你那个时候的水平怎么好意思说喜爱的，太不要脸了），受Happy Hacking的影响，这次选了逆向工程方向，然后就体会到了什么叫坐牢，真的是极致的坐牢。汇编语言？不会哦；可执行文件格式？不会哦；加密算法？不会哦；不会哦不会哦全都不会哦！那就学呗，CSAPP启动（事实上四分之一都没读完，笑死我了）。

而九月份后，成为大学生的cris老师精神状态，可真是颇为美丽呢（大雾），每天在图书馆敲代码敲到晚上满脸疲惫地吊着一张死人脸晃荡着回宿舍，中途去711买点夜宵续命——这就是我每天的日常。

保研的焦虑，竞赛的焦虑，人生选择的焦虑，因为什么都想要反而什么都得不到，甚至让自己的学业受到了影响。之前我不理解为什么大学生上完课还得下去再听一遍，现在我理解了。每天心思都是乱的，不是在思考各种杂七杂八的任务就是在纠结于一些无关紧要的事情，再加上一周几次课和不定时交的作业，很难说“落实”二字到底有没有分量。我时常感觉喘不过气来，便只能扫车，启动，去把校园逛上个一整圈。从信息学部沿着自强大道一路向上，拐出梅园，来到行政楼的青顶下，穿过老斋舍拔起的翘角飞檐，又在樱园北路拐个弯儿扑向湖滨的水汽氤氲。我向来对武大的“最美校园”之称是心服口服的，校园的景色足矣治愈我，给与我继续生活的动力。

十月份时趁着国庆假期又去了趟南京，十一月则是在校运会时溜走，跑长沙玩了两天，偷偷旅行还是很刺激的哈哈！到了十二月的岁末寒冬，则是每天往返教学楼都冻得够呛，而且似乎有点醒不过来了，翘了好几节早八😭，我忏悔。

期末考试临近，也是忙里偷闲中敲下了这段文字。不想再做什么升华或渲染，我很喜欢我的2025，虽然有痛苦，有繁忙，有（非常大的）不尽如人意和遗憾，但总归只要向前走就有收获，因为可能性是生命本身的礼物。这是我回首一年的感受，也希望你能有同样的感触。

最后，祝愿看到这里的大家平安喜乐。

BITs2CTF-2025 RE方向题解

Sat, 22 Nov 2025 00:00:00 GMT

帮着同学打了一下北理的第一届新生赛，题目都十分有趣，收获满满。有一道是LLVM pass是容器题，就没打。

（当然，邪恶的代打行为被主办方正义制裁了，不过也是罪有应得啦）

大战WebAssembly

给了一个 WebAssembly 的 check.wasm，外加一个 JavaScript 脚本逐字符验证 flag：

  if (check(i, flag[i].charCodeAt(), enc[i]) != 1)

逆向WebAssembly模块可知有check，f和g三个函数，总结下来一次check大概执行以下逻辑：

  flag[i] = enc[i] XOR ((2*i + 1) XOR 8)

写出解密脚本即可：

  const enc = [
  75, 66, 89, 124, 51, 64, 81, 65, 98, 76, 46, 46, 32, 76, 113, 39, 71,
  24, 12, 112,
  120, 19, 80, 0, 79, 8, 98, 10, 68, 80, 86, 4, 124, 126, 43, 58, 112,
  114, 60, 24,
  61, 104, 59, 108, 101, 100, 102, 51, 54, 92, 5, 92, 62, 91, 81, 87, 65,
  79, 77,
  78, 65, 29, 67, 40, 189, 229, 233, 208, 233, 178, 176, 216, 206, 175,
  168, 242,
  236,
  ];
  
  let flag = [];
  
  for (let i = 0; i < enc.length; i++) {
  const v = enc[i] ^ ((2 * i + 1) ^ 8);
  flag.push(String.fromCharCode(v));
  }
  
  console.log("FLAG =>", flag.join(""));

什么？你问我怎么逆 WebAssembly 文件？IDA 9.2 直接打开就行啊，有 Loader 的。

答案：BITs2CTF{W311_d0n3!_Y0u'v3_5ucc355fu11y_d3f3473d_7h3_84084010n6_4nd_h15_W45m}

真假奶龙

使用 Lua Decompiler 反编译Bytecode得：

  -- filename: @./main.lua
  -- version: lua54
  -- line: [0, 0] id: 0
  local function r0_0(r0_1)
  -- line: [1, 20] id: 1
  if type(r0_1) ~= "string" then
  return "请输入文本"
  end
  r0_1 = string.reverse(r0_1)
  local r1_1 = {}
  for r5_1 = 1, #r0_1, 1 do
  local r6_1 = string.byte(r0_1, r5_1)
  if r6_1 >= 48 and r6_1 <= 57 then
  table.insert(r1_1, (r6_1 + -48 + 2) % 9 + 48)
  elseif r5_1 ~= 1 then
  table.insert(r1_1, r6_1 + r1_1[r5_1 + -1])
  else
  table.insert(r1_1, r6_1)
  end
  end
  return r1_1
  end
  local r1_0 = {
  125,
  158,
  51,
  84,
  54,
  171,
  51,
  146,
  56,
  134,
  50,
  51,
  51,
  54,
  132,
  227,
  54,
  149,
  53,
  167,
  54,
  149,
  270,
  51,
  51,
  54,
  53,
  167,
  262,
  379,
  50,
  171,
  266,
  48,
  54,
  158,
  48,
  143,
  51,
  164,
  50,
  54,
  51,
  139,
  234,
  50,
  48,
  143,
  243,
  53,
  171,
  50,
  164,
  276,
  371,
  53,
  171,
  210,
  327,
  50,
  139,
  234,
  267,
  53,
  163,
  50,
  150,
  245,
  51,
  51,
  53,
  140,
  263,
  333,
  417,
  484,
  52,
  167,
  251,
  324,
  390
  }
  print("==========================")
  print(" | 奶龙与小七之真假奶龙 | ")
  print("==========================")
  print("你：我是奶龙！")
  print("假奶龙：我才是奶龙！")
  print("你：我会喷火，你会吗？")
  print("假奶龙：我也会！")
  print("小七：你们别争了，真正的奶龙会念出只有我能听懂的神奇咒语！")
  print("请输入你的咒语：")
  local r3_0 = r0_0(io.read())
  for r8_0 in pairs(r3_0) do
  local r9_0 = r3_0[r8_0]
  local r10_0 = r1_0[r8_0]
  if r9_0 ~= r10_0 then
  print("小七没有听懂你的咒语，你没有证明自己是真的奶龙！")
  os.exit(1)
  end
  end
  -- close: r4_0
  print("恭喜你说出了正确的咒语，你是真的奶龙！")
  os.exit(1)

加密逻辑是典型的替换密码：

整体反转输入
从左到右扫描反转后的字符串：
- 如果是数字：用 (d+2) mod 9 的方式映射到另一个数字
- 如果是非数字 & 是第一个字符：直接用 ASCII 值
- 如果是非数字 & 不是第一个字符：把当前 ASCII 和前一个输出值相加

写出解密脚本：

  r1_0 = [
  125,158,51,84,54,171,51,146,56,134,50,51,51,54,132,227,
  54,149,53,167,54,149,270,51,51,54,53,167,262,379,50,171,
  266,48,54,158,48,143,51,164,50,54,51,139,234,50,48,143,
  243,53,171,50,164,276,371,53,171,210,327,50,139,234,267,
  53,163,50,150,245,51,51,53,140,263,333,417,484,52,167,
  251,324,390
  ]
  
  # 逆向数字分支：(c - 48 + 2) % 9 + 48
  digit_map = {}
  for d in range(48, 58): # '0'..'9'
  enc = (d - 48 + 2) % 9 + 48
  digit_map.setdefault(enc, []).append(d)
  
  def reverse_enc(out):
  """
  反推得到反转后的字符串（byte 数组）
  """
  s_rev = [None] * len(out)
  
  # i = 0，对应 Lua 的 i = 1
  s_rev[0] = out[0] # 必须是非数字，直接就是 ASCII！
  
  for i in range(1, len(out)):
  val = out[i]
  
  # 分支 1：尝试非数字分支：val = c + out[i-1]
  c = val - out[i-1]
  if 32 <= c <= 126 and not (48 <= c <= 57): # 可显示 & 非数字
  s_rev[i] = c
  continue
  
  # 分支 2：尝试数字分支
  if val in digit_map:
  # 如果能对应到某些数字，那就是数字字符
  # 多个可能时一般只有一个可打印
  for d in digit_map[val]:
  s_rev[i] = d
  break
  continue
  
  raise ValueError("无法反推第 {} 项".format(i))
  
  return s_rev
  
  s_rev = reverse_enc(r1_0)
  
  # 把 byte 数组拼成字符串，并反转回来
  s = ''.join(chr(c) for c in s_rev[::-1])
  print("解出的咒语：")
  print(s)

答案：BITs2CTF{W311_d0n3!_Y0u'v3_pr0v3d_70_X140q1_7h47_y0u_r3411y_4r3_4_N4110N6_1u4!1!}

ChaCha20

简单到令人困惑的Python逆向，pycdc跑一遍就出来了

源代码：

  # Source Generated with Decompyle++
  # File: chacha20.pyc (Python 3.10)
  
  from cryptography.hazmat.primitives.ciphers import Cipher, algorithms
  from cryptography.hazmat.backends import default_backend
  from Crypto.Util.number import long_to_bytes, bytes_to_long
  from secret import flag
  import time
  import random
  import os
  
  def chacha20_encrypt(plaintext = None, key = None, nonce = None):
  cipher = Cipher(algorithms.ChaCha20(key, nonce), None,
  default_backend(), **('mode', 'backend'))
  encryptor = cipher.encryptor()
  ciphertext = encryptor.update(plaintext)
  return ciphertext
  
  if __name__ == '__main__':
  k1 = bytes_to_long(os.urandom(32))
  n1 = bytes_to_long(os.urandom(16))
  print(f'''k1={k1}''')
  print(f'''n1={n1}''')
  random.seed(int(time.time()) % 100)
  k2 = random.getrandbits(128)
  n2 = random.getrandbits(64)
  key = long_to_bytes(k1 ^ k2)
  nonce = long_to_bytes(n1 ^ n2)
  encrypted_data = chacha20_encrypt(flag, key, nonce)
  print(f'''加密后: {encrypted_data.hex()}''')
  return None

解密脚本：

  from cryptography.hazmat.primitives.ciphers import Cipher, algorithms
  from cryptography.hazmat.backends import default_backend
  from Crypto.Util.number import long_to_bytes
  import random
  
  # ================== 已知数据（从 result.txt 里抄过来的） ==================
  k1 =
  89156737880809474145449532029493055444849328922741582677584755390029529653680
  n1 = 20979402206073728478533457085044507592
  ct_hex =
  "a8c123f27ed9d34a6040a98f0b9d5e22930ca34bd3195e27a1e73725aba2f3eff888"
  
  ciphertext = bytes.fromhex(ct_hex)
  
  def chacha20_xor(data, key, nonce):
  """和原脚本一样，用 ChaCha20 做加解密（同一个操作）"""
  cipher = Cipher(algorithms.ChaCha20(key, nonce), None, default_backend())
  encryptor = cipher.encryptor()
  return encryptor.update(data)
  
  for seed in range(100):
  random.seed(seed)
  k2 = random.getrandbits(128)
  n2 = random.getrandbits(64)
  
  key = long_to_bytes(k1 ^ k2)
  nonce = long_to_bytes(n1 ^ n2)
  
  # 理论上 key 应该 32 字节，nonce 应该 16 字节，这里简单做个保护
  if len(key) != 32 or len(nonce) != 16:
  continue
  
  try:
  pt = chacha20_xor(ciphertext, key, nonce)
  except Exception as e:
  # 不符合要求长度等情况直接跳过
  continue
  
  # 简单筛一下：只要能 decode，且包含 CTF 常见格式就输出
  try:
  s = pt.decode("utf-8")
  except UnicodeDecodeError:
  continue
  
  if "CTF{" in s or "BITs2CTF{" in s:
  print(f"[+] seed = {seed}")
  print(f"[+] plaintext = {s}")
  break

答案：BITs2CTF{pyc_reverse_is_important}

EasyMaze

一眼的迷宫题。

查看代码发现没有做任何混淆，逻辑清晰易懂，代码可读性高，夸赞一下。

在 Maze::Maze 找到迷宫数据，排除反调试后的假数据，发现Maze类中除了前后左右外还有上下两个方向移动的函数，于是猜测应该是把三维迷宫逐层展开成一个二维迷宫（所以看起来是6*36的奇怪比例）。

相关代码截取发给AI后写出了美观的求解页面（非必须，个人喜好）

答案：BITs2CTF{QHGIIVVWRKECAEWNVUTQPHEEEGQ}

Gore

Go语言逆向。

这里是伪随机，但是Go版本未知，随机数生成逻辑可能和文档记录的不同。

查看 main_keyexpand 和 main_crypt 发现加密逻辑是环状XOR，但ran[]序列不方便完全静态复现。于是动调之：

  pwndbg> info args
  box = 0xc0001abea0
  data = 0xc0001abed0
  ran = 0xc0001abeb8
  length = 56
  
  pwndbg> x/gx (0xc0001abeb8)
  0xc0001abeb8: 0x000000c0001bc1c0
  
  pwndbg> x/56gx (0xc0001bc1c0)
  0xc0001bc1c0: 0x0000000000000017 0x0000000000000068
  0xc0001bc1d0: 0x0000000000000084 0x0000000000000017
  0xc0001bc1e0: 0x0000000000000008 0x000000000000008f
  0xc0001bc1f0: 0x00000000000000a6 0x00000000000000f2
  0xc0001bc200: 0x00000000000000ea 0x000000000000002f
  0xc0001bc210: 0x0000000000000053 0x00000000000000b1
  0xc0001bc220: 0x00000000000000d3 0x00000000000000b6
  0xc0001bc230: 0x00000000000000e2 0x000000000000005b
  0xc0001bc240: 0x000000000000005c 0x000000000000009c
  0xc0001bc250: 0x0000000000000058 0x0000000000000064
  0xc0001bc260: 0x00000000000000f8 0x00000000000000a8
  0xc0001bc270: 0x0000000000000022 0x00000000000000e2
  0xc0001bc280: 0x0000000000000094 0x0000000000000005
  0xc0001bc290: 0x0000000000000057 0x0000000000000069
  0xc0001bc2a0: 0x0000000000000048 0x00000000000000fe
  0xc0001bc2b0: 0x0000000000000020 0x0000000000000032
  0xc0001bc2c0: 0x0000000000000078 0x00000000000000c1
  0xc0001bc2d0: 0x0000000000000022 0x0000000000000053
  0xc0001bc2e0: 0x00000000000000c9 0x0000000000000030
  0xc0001bc2f0: 0x0000000000000047 0x00000000000000ac
  0xc0001bc300: 0x000000000000001b 0x000000000000008f
  0xc0001bc310: 0x000000000000003d 0x000000000000009f
  0xc0001bc320: 0x0000000000000072 0x00000000000000df
  0xc0001bc330: 0x00000000000000cd 0x0000000000000034
  0xc0001bc340: 0x00000000000000ae 0x00000000000000fe
  0xc0001bc350: 0x0000000000000032 0x00000000000000f9
  0xc0001bc360: 0x00000000000000fc 0x000000000000005a
  0xc0001bc370: 0x000000000000004e 0x0000000000000036

写出解密脚本：

  target = [
  0xBE, 0x67, 0xF3, 0x76, 0xE1, 0x5C, 0xA0, 0x79,
  0x1F, 0x42, 0xA7, 0x02, 0xE6, 0x99, 0x8D, 0xE3,
  0xCE, 0x10, 0x30, 0x36, 0xF6, 0x1C, 0x1B, 0xA1,
  0x4D, 0x25, 0x45, 0x43, 0xEE, 0x35, 0xFC, 0xB1,
  0x87, 0xB3, 0xBB, 0x5D, 0x26, 0x1E, 0xE7, 0x08,
  0x50, 0xFC, 0x4E, 0xA4, 0x7E, 0x45, 0xE6, 0xFC,
  0xC9, 0x18, 0x38, 0x10, 0xA6, 0x4B, 0x7F, 0xD5,
  ]
  
  ran = [
  0x17, 0x68, 0x84, 0x17, 0x08, 0x8f, 0xa6, 0xf2,
  0xea, 0x2f, 0x53, 0xb1, 0xd3, 0xb6, 0xe2, 0x5b,
  0x5c, 0x9c, 0x58, 0x64, 0xf8, 0xa8, 0x22, 0xe2,
  0x94, 0x05, 0x57, 0x69, 0x48, 0xfe, 0x20, 0x32,
  0x78, 0xc1, 0x22, 0x53, 0xc9, 0x30, 0x47, 0xac,
  0x1b, 0x8f, 0x3d, 0x9f, 0x72, 0xdf, 0xcd, 0x34,
  0xae, 0xfe, 0x32, 0xf9, 0xfc, 0x5a, 0x4e, 0x36,
  ]
  
  def keyexpand(k):
  length = len(k)
  box = list(range(256))
  i = 0
  j = 0
  while i < 256:
  v = box[i]
  j_idx = (k[i % length] + v + j) % 256
  box[i] = box[j_idx] ^ v
  box[j_idx] ^= box[i]
  box[i] ^= box[j_idx]
  i += 1
  j = j_idx
  return box
  
  def crypt(box0, data, ran):
  length = len(data)
  box = box0[:] # copy
  i = 0
  j = 0
  t = 0
  while t < length:
  v7 = i - (((i + 1) & ~0xff))
  idx_i = v7 + 1
  
  v10 = box[idx_i]
  j_idx = (v10 + j) % 256
  
  box[idx_i] = box[j_idx] ^ v10
  box[j_idx] ^= box[idx_i]
  box[idx_i] ^= box[j_idx]
  
  v16 = box[idx_i]
  v17 = v7 + j_idx + 1
  
  idx_ran = v17 % length
  idx_s = ran[idx_ran] ^ ((box[j_idx] + v16) % 256)
  
  data[t] ^= box[idx_s]
  
  t += 1
  i = idx_i
  j = j_idx
  return data
  
  def invert_ring_xor(q):
  L = len(q)
  xor_0_to_Lm2 = 0
  for i in range(L-1):
  xor_0_to_Lm2 ^= q[i]
  p0 = q[L-1] ^ xor_0_to_Lm2 ^ q[0]
  p = [0]*L
  p[0] = p0
  acc = 0
  for k in range(1, L):
  acc ^= q[k-1]
  p[k] = acc ^ p0
  return p
  
  def main():
  key_str = "BITs2CTF{}"
  k = [ord(c) for c in key_str]
  box0 = keyexpand(k)
  
  data = target.copy()
  q = crypt(box0, data, ran.copy())
  
  p = invert_ring_xor(q)
  
  mid_bytes = []
  for idx in range(28):
  lo = chr(p[2*idx])
  hi = chr(p[2*idx+1])
  mid_bytes.append(int(hi+lo, 16))
  
  middle = bytes(mid_bytes).decode()
  flag = "BITs2CTF{" + middle + "}"
  print(flag)
  
  if __name__ == "__main__":
  main()

答案：BITs2CTF{G0r3_15_h@Aa4%&rD_7O_5oLv3?!}

Math

fun1到fun4都是纯数学运算，可以化简成Z3求解器友好的形式。

  from z3 import *
  
  # 6 个 32-bit 无符号变量
  A, b, c, d, e, f = BitVecs('A b c d e f', 32)
  
  s = Solver()
  
  # 范围约束：100000 < x < 1000000
  lo = BitVecVal(100000, 32)
  hi = BitVecVal(1000000, 32)
  for v in (A, b, c, d, e, f):
  s.add(UGT(v, lo)) # v > 100000
  s.add(ULT(v, hi)) # v < 1000000
  
  # 1) (A + b) % 951081 == 597141
  mod = BitVecVal(951081, 32)
  s.add(URem(A + b, mod) == BitVecVal(597141, 32))
  
  # 2) A - b + 2c == 1644082
  s.add(A - b + (c << 1) == BitVecVal(1644082, 32))
  
  # 3) 4f XOR d == 1161537
  s.add(((f << 2) ^ d) == BitVecVal(1161537, 32))
  
  # 4) 5(d - e) == 343890
  s.add((BitVecVal(5, 32) * (d - e)) == BitVecVal(343890, 32))
  
  # 5) A + f == 1136538
  s.add(A + f == BitVecVal(1136538, 32))
  
  # 6) 2d + e == 1952901
  s.add((d << 1) + e == BitVecVal(1952901, 32))
  
  print(s.check())
  m = s.model()
  
  A_val = m[A].as_long()
  b_val = m[b].as_long()
  c_val = m[c].as_long()
  d_val = m[d].as_long()
  e_val = m[e].as_long()
  f_val = m[f].as_long()
  
  print("A =", A_val)
  print("b =", b_val)
  print("c =", c_val)
  print("d =", d_val)
  print("e =", e_val)
  print("f =", f_val)
  
  flag =
  f"BITs2CTF{{{A_val:x}{b_val:x}{c_val:x}{d_val:x}{e_val:x}{f_val:x}}}"
  print("Flag:", flag)

答案：BITs2CTF{a5b51d446ddffa7a486593bbb6fc49}

这题本来想用Angr做符号执行，玩一把花活儿，结果Angr似乎跑进死循环了，可能还是学艺不精不太会用，sad😢😢。

Rustre

Rust是一种很严谨的语言，所以当你尝试反编译rustre::main的时候你就会看到编译器摁造出来的依托垃圾。

各种边界检查丑的不要不要的，无法看出实际情况。于是让AI对代码进行简化（也就是说：写出一个等效Rust项目，这一步巨难无比，我花了一个下午才折腾出等效的可用代码）：

  ❯ cat src/main.rs
  use std::io::{self};
  
  // 对应 IDA 中的 rustre::square
  // 在 Debug 编译下，Rust 会自动插入溢出检查 (is_mul_ok)
  fn square(n: u32) -> u32 {
  n * n
  }
  
  // 对应 IDA 中的 keychange
  fn keychange(key: &mut [u8]) {
  // 还原去重逻辑
  // 遍历 1..4，比较 key[i] 和 key[i-1]
  for i in 1..4 {
  if key[i] == key[i - 1] {
  key[i] = 50; // ASCII '2'
  }
  }
  
  // 还原 XOR 链逻辑
  // 遍历 0..3
  for i in 0..3 {
  key[i] ^= key[i + 1];
  }
  }
  
  // 对应 IDA 中的 enc
  // 这里包含了一个关键的逻辑陷阱，导致只加密了前 12 字节
  fn enc(data: &mut [u8], key: &[u8]) {
  let len = data.len();
  // 陷阱还原：原作者可能想写 len / 4，但写成了 len / 8 (也就是 >> 3)
  // 导致 limit = 28 / 8 = 3
  let limit = len >> 3;
  
  for i in 0..limit {
  // 每次处理 4 字节
  for j in 0..4 {
  let data_idx = i * 4 + j;
  // 密钥轮转逻辑: (Block + Offset) % 4
  let key_idx = (i + j) % 4;
  
  data[data_idx] ^= key[key_idx];
  }
  }
  }
  
  fn main() {
  // 1. 读取输入
  // 对应 std::io::stdio::Stdin::read_line
  let mut input_str = String::new();
  io::stdin()
  .read_line(&mut input_str)
  .expect("Failed to read line");
  
  // 对应 core::str::trim
  let input = input_str.trim();
  
  // 对应 "Wrong length!" 检查
  if input.len() != 28 {
  println!("Wrong length!");
  return;
  }
  
  let mut data = input.as_bytes().to_vec();
  
  // 2. 准备密钥
  let mut key_str = String::from("reee");
  // SAFETY: "reee" is valid utf8, unsafe implies direct byte
  manipulation in some contexts,
  // but standard into_bytes is safe. kept simple here.
  let mut key = key_str.into_bytes();
  
  keychange(&mut key);
  
  // 3. 执行加密 (含 Trap)
  enc(&mut data, &key);
  
  // 4. 位重组 (Shuffle)
  // 对应那一长串的 index 操作。
  // 使用 chunks(7) 会导致编译器对定长循环进行展开 (Loop Unrolling)
  let mut shuffled_data = vec![0u8; 28];
  
  for (chunk_idx, chunk) in data.chunks(7).enumerate() {
  let base_idx = chunk_idx * 7;
  
  // 模拟 7x7 位变换
  for (s_byte_idx, &byte) in chunk.iter().enumerate() {
  // 假设只处理 ASCII 的低 7 位
  for b in 0..7 {
  // 取出第 b 位
  if (byte >> b) & 1 == 1 {
  // 还原公式: dst = (6 - b - s) % 7
  // 使用 rem_euclid 确保负数取模结果为正，符合数学定义
  let d_byte_idx = (6 - (b as i32) - (s_byte_idx as i32)).rem_euclid(7)
  as usize;
  
  shuffled_data[base_idx + d_byte_idx] |= 1 << b;
  }
  }
  }
  }
  
  // 5. 字节映射与比较
  // 对应 IDA 中的 rustre::main::{{closure}}
  // 以及最终的 cmp 逻辑
  let target = [
  139, 161, 68, 233, 197, 35, 129, 79, 171, 76, 167, 6, 37, 135, 207,
  236, 143, 169, 41, 205,
  8, 197, 109, 109, 205, 228, 140, 128,
  ];
  
  // Map: ((x ^ 25) >> 3) | ((x ^ 25) << 5)
  // 这在 Rust 中就是 rotate_right(3)
  let final_data: Vec<u8> = shuffled_data
  .iter()
  .map(|&x| {
  let val = x ^ (square(5) as u8);
  val.rotate_right(3)
  })
  .collect();
  
  // 6. 结果判定
  if final_data == target {
  println!("You are right!");
  } else {
  println!("You are wrong!");
  }
  }

那还说什么，直接vibe it~

  #!/usr/bin/env python3
  # -*- coding: utf-8 -*-
  
  # 题目中 main 里给的 target 数组
  TARGET = [
  139, 161, 68, 233, 197, 35, 129, 79,
  171, 76, 167, 6, 37, 135, 207, 236,
  143, 169, 41, 205, 8, 197, 109, 109,
  205, 228, 140, 128,
  ]
  
  def keychange_from_reee():
  """
  还原 Rust 里的 keychange("reee")
  初始: "reee" -> [114, 101, 101, 101]
  """
  key = [ord(c) for c in "reee"]
  
  # 去重逻辑
  for i in range(1, 4):
  if key[i] == key[i - 1]:
  key[i] = 50 # '2'
  
  # XOR 链
  for i in range(3):
  key[i] ^= key[i + 1]
  
  return key # [23, 87, 87, 101]
  
  
  def inverse_map(target):
  """
  逆向这一段：
  val = x ^ 25
  out = val.rotate_right(3)
  
  对应逆过程：
  val = rotate_left(x, 3)
  src = val ^ 25
  """
  res = []
  for x in target:
  # 8-bit rotate_left(3)
  val = ((x << 3) & 0xFF) | (x >> 5)
  res.append(val ^ 25)
  return res # 得到 shuffled_data
  
  
  def inverse_shuffle(shuffled):
  """
  逆向 7x7 位重组：
  
  正向：
  for each chunk of 7 bytes:
  for s in 0..6:
  for b in 0..6:
  if src[s] 第 b 位为 1:
  d = (6 - b - s) mod 7
  dst[d] 的第 b 位 |= 1
  
  逆向：
  已知 dst[d] 第 b 位为 1，则：
  s = (6 - b - d) mod 7
  src[s] 的第 b 位 |= 1
  """
  n = len(shuffled)
  out = [0] * n
  assert n % 7 == 0
  
  num_chunks = n // 7
  for chunk_idx in range(num_chunks):
  base = chunk_idx * 7
  for d in range(7):
  byte = shuffled[base + d]
  for b in range(7): # 只处理低 7 位
  if (byte >> b) & 1:
  s = (6 - b - d) % 7
  out[base + s] |= (1 << b)
  return out # 即 enc 之后的 data
  
  
  def inverse_enc(data_after_enc, key):
  """
  逆向 enc：
  
  正向：
  limit = len >> 3 = 3 (因为 len=28)
  i=0..2, j=0..3:
  idx = i*4 + j
  data[idx] ^= key[(i+j) % 4]
  
  XOR 自反，所以逆向做同样的 XOR 即可还原。
  """
  data = list(data_after_enc)
  for i in range(3):
  for j in range(4):
  idx = i * 4 + j
  kidx = (i + j) % 4
  data[idx] ^= key[kidx]
  return data
  
  
  def main():
  # 1. 逆最后一步 map，得到 shuffled_data
  shuffled = inverse_map(TARGET)
  
  # 2. 逆 7x7 位重组，得到 enc 之后但 shuffle 之前的 data
  data_after_enc = inverse_shuffle(shuffled)
  
  # 3. 还原 key
  key = keychange_from_reee()
  
  # 4. 逆 enc，得到原始输入（flag 字节）
  plain_bytes = inverse_enc(data_after_enc, key)
  
  # 5. 转成字符串
  flag = ''.join(chr(b) for b in plain_bytes)
  print("Recovered flag:", flag)
  
  
  if __name__ == "__main__":
  main()

答案：BITs2CTF{D1fficuLt_Ru57R3~~}

这个题目还是很有难度的，1kpts名副其实。传统的长代码审计也很克制 AI 。我使用Gemini3分步处理，非常完美的解决了这道题目，令人感叹长上下文就是爽啊~

另外值得提一嘴的就是AI的使用。这些日子大量使用AI辅助做题，发现了一个小技巧：我们把AI的解题步骤分为提供信息和思路推进，则思路推进一定要分步处理，信息提供一定要一步给完

如何理解这句话呢？例如有fun1()、fun2()两个函数，经过了3个不同的加密步骤得到密文。

则，你的第一条prompt应该是：fun1()的完整代码+fun2()的完整代码+调度器（让AI知道是3轮加密），2️而不应该是：第一条prompt给fun1()的代码，AI提示你给出fun2()的，你再给。

一次给足信息的效果几乎总是远远强于分步给出信息的会话，fun fact to share.

感想

最近很不顺心，打N1打的有点破防，结果看到这篇博客，震惊地发现：设计这道卡住我一周的难题的，位列N1官网的师傅，竟然才大二（或大三）。一瞬间被差距打击地体无完肤了，迫切地想做题做题做题。

这种心态健康吗？也不见得多健康，熬夜，眼睛痛，头晕，上课打不起精神，作业欠一堆，还有那些自己处于体验生活目的加入的学生社团和组织的任务......算了，你没有义务成为天才，还是过好自己的生活吧。

You only live once.

流量时代正在断送媒体的良知：锐评新京报报道南京大学帝王蟹事件

Tue, 04 Nov 2025 00:00:00 GMT

以下内容转自我的好友AritxOnly-音唯，作为 WHU 的学子，互联网上的口诛笔伐这些日子真是受够了。我对南大很有感情，便就借着他的这篇文章抒发下自己的悲愤吧。

“媒体面前，事实似乎不再重要了。”

这几个月我越来越不信任新闻，因为事实往往不是它们让你看到的那样。

昨天去九食堂，和女朋友盘算着叫几个人一起尝尝没尝过的帝王蟹，今天就被骂上热搜了。

从数码圈乱象起手

我关注的圈子，是无良媒体扎堆的数码圈。

“比一元硬币还薄”的断章取义、“小字营销”的带节奏、“年轻人的最后一台车”的情绪包装——这些我都看在眼里。但我没有发声。

我不是小米的“死忠粉”，只是一个喜欢产品、能分辨是非的普通人。用着华为手表、拿着OPPO手机、背着苹果电脑，也装着米家生态。可当我看到那么多人被带偏，被煽动去骂、去信时，我才真正意识到：媒体对公众的影响力有多么恐怖。

锐评本次事件

南大学生十人八人，分享一只帝王蟹又何罪之有呢？

你们说我们不务学习，尽显奢靡之风——而我告诉你午夜的生命科学楼、计算机楼、电子楼等院楼灯火通明，不止研究生和博士生，还有本科生和教职老师。他们用尽心力，只为了给国家给社会创造更多的价值。

你们说我们没有积蓄，尽花父母钱财——而我告诉你南京的大学生家教的数量已经超出你们的想象。我的同学们，不是通过家教兼职赚钱，就是通过实习积攒工作经历，亦或是投资理财理财。我们的有能力拼一桌人均150的帝王蟹。

你们会拿南大前校训“嚼得菜根，做得大事”上纲上线，而我告诉你，奢俭由人，南大学子绝不会因为享用过一餐帝王蟹，就真认为自己是“帝王”了。

一点冷静的分析

情绪发泄之外，不妨跳出这件事情本身，来看看媒体是如何误导群众，而群众又是如何制造出庞大的互联网声量的。

媒体首先给事件贴上标签，用情绪代替事实，用“高校奢靡”“学生浪费”这样的话术触发公众的愤怒。随后，社交平台的算法捕捉到这种情绪，放大矛盾，推送给更多还没了解真相的用户。于是，一场舆论的狂欢开始了。谁还在乎真相？只要骂，就能被看见。

在这样的环境里， 一个人的认知，决定了他能看到的东西 。

那些骂南大“奢靡”的人，或许只是看到了自己生活的投射——他们身边确实充斥着攀比、虚荣和浮躁，于是理所当然地认为所有学校都一样。当他们看到一所大学的食堂敢卖帝王蟹，他们不会想到是尝试改革、是多样化供餐，而会本能地嘲讽：“这不就是洗脚城吗？”

他们眼里的“奢靡之风”，正是他们熟悉的世界；他们嘲笑的“校园堕落”，也许只是南大走在前面的尝试。他们酸的，不是帝王蟹的价格，而是自己学校里没有这样的改变。

就好像真正的“花粉”也会批驳华为旗舰机系统更新不及时、价格虚高等等不足，而手上拿着低端机的网友却对这些真金白银支持华为的人们口诛笔伐。网络上从来不缺精神股东，网络只是他们的情绪宣泄口。

这就是流量时代最可悲的地方：人们不再追问“事实是什么”，而是急着寻找能让自己情绪有出口的东西。媒体知道这一点，于是不断制造“可以骂”的新闻。群众在骂声中获得快感，而真相被埋在最不值钱的地方。

是啊， 真相已随那一串串的字符流，消失在了大数据的海洋里 。

最后发一段我在 QQ 空间写下的评论吧：

最近互联网上似乎形成了一种新的猎巫范式：大家似乎已经发现了一种通过找各种清奇的角度，片面陈述甚至伪造事实来诋毁高校的固定套路——当然，很有效，很爽，很能恶心人。从“入学小心被留学生强奸”的浙江大学，“努力培养和NGO勾结的汉奸”的武汉大学，到“奢靡之风成性”的南京大学，下一个是谁呢？我不想说什么诸如“不分青红皂白选择一竿子打死的人都是上不起985的红眼loser”这种无谓的诛心之论，只是祝愿各位在被裹挟着的舆论彰显出的所谓“民意的铁拳”砸到自己身上的时候，也能有诋毁别人学校时那样的镇定与愉悦。

WHUCTF-2025 RE方向全题解

Sun, 26 Oct 2025 00:00:00 GMT

WHUCTF-2025 RE方向全题解

签到

打开发现是弗吉尼亚密码，直接解密即可。

WHUCTF{welcome_to_reverse-kep}.exe

ezbase

发现密文 d2h1Y3RmezZac2U2NF8xc192ZXJ5XzNac3ktZWtlfQ==

猜测base64，发现表都没换

坏了，想简单了，换表了，难度还是太高了（

aBCDEFGHIJKLMNOPQRSTUVWXYZAbcdefghijklmnoqprstuvwxyz0123456789+/

得：

whuctf{6@se64_1s_very_3@sy-eke}.exe

太空逃亡

主函数是一个巨简单的验证函数，关键的加密逻辑在sub_4015F8。检验得其把用户输入当作一串方向键 W/A/S/D（分别对应上、左、下、右），在一个 16×16 的网格（线性数组 byte_4A3020）上沿直线滑动：每次沿某方向一直前进直到遇到一个非 0的格（障碍/节点）；不能越界、不能连续输入相同方向，目标是最终抵达数组中值为 '!'（33）的格子。

迷宫地图 (0=路径, !=终点, 其他=障碍):
. . . . # . . . . . . . # # # #
. . . # # . . . # # . . . . . .
. . . . . . . . # # . # # . . .
. . . # . # # . # # . # # . . .
. . . # . # # . # # . # . . . .
. . # # . # # . . . . # . . . .
. . . . . # # . . . . # . . . .
# . . . . . . . . . . . . . . .
. . . . . . . . . . . . # . . .
. . . . . . # # # . . . # . . .
. . . . . . . # # # . . . . # #
. . . # . # . # . # . . . . # .
. . . . . . . . . . . . . . # #
# # # # . # . # . # . . . . # .
. # . # . # . # . # . . . . # .
. # . # . # . # . # ! . . . # #

值得注意的是！这是一个冰面迷宫，左右移会直接移到可移动区域的边缘。

写出解密脚本即可：

import hashlib
from collections import deque


def parse_maze_data():
    """解析IDA风格的迷宫数据"""
    # 解析重复计数语法
    def parse_dup(part):
        part = part.strip()
        if 'dup(' in part:
            count_str, value_str = part.split('dup(')
            count_str = count_str.strip()
            value_str = value_str.strip(')')

            # 处理十六进制计数 (如0Eh, 1Bh等)
            if count_str.endswith('h'):
                count = int(count_str[:-1], 16)
            else:
                count = int(count_str)

            # 处理十六进制值
            if value_str.endswith('h'):
                value = int(value_str[:-1], 16)
            else:
                value = int(value_str)

            return [value] * count
        else:
            # 处理普通值
            if part.endswith('h'):
                return [int(part[:-1], 16)]
            else:
                return [int(part)]

    # 原始数据
    raw_data = [
        "4 dup(0), 23h, 7 dup(0), 4 dup(23h), 3 dup(0), 2 dup(23h)",
        "3 dup(0), 2 dup(4Fh), 0Eh dup(0), 2 dup(4Fh), 0, 2 dup(50h)",
        "6 dup(0), 4Ch, 0, 2 dup(4Fh), 0, 2 dup(4Fh), 0, 2 dup(50h)",
        "6 dup(0), 4Ch, 0, 2 dup(4Fh), 0, 2 dup(4Fh), 0, 50h",
        "6 dup(0), 2 dup(4Ch), 0, 2 dup(4Fh), 4 dup(0), 50h",
        "9 dup(0), 2 dup(4Fh), 4 dup(0), 50h, 4 dup(0), 23h",
        "1Bh dup(0), 23h, 9 dup(0), 3 dup(4Dh), 3 dup(0), 23h",
        "0Ah dup(0), 3 dup(4Dh), 4 dup(0), 2 dup(45h), 3 dup(0)",
        "30h, 0, 4Dh, 0, 4Dh, 0, 4Dh, 4 dup(0), 45h, 0Fh dup(0)",
        "2 dup(45h), 3 dup(54h), 49h, 0, 4Dh, 0, 4Dh, 0, 4Dh",
        "4 dup(0), 45h, 2 dup(0), 54h, 0, 49h, 0, 4Dh, 0, 4Dh",
        "0, 4Dh, 4 dup(0), 45h, 2 dup(0), 54h, 0, 49h, 0, 4Dh",
        "0, 4Dh, 0, 4Dh, 21h, 3 dup(0), 2 dup(45h)"
    ]

    maze = []
    for line in raw_data:
        parts = line.split(',')
        for part in parts:
            part = part.strip()
            if part:
                maze.extend(parse_dup(part))

    return maze


def solve_maze(maze, start, end):
    """使用BFS算法求解迷宫最短路径"""
    rows, cols = 16, 16
    directions = [(0, 1, 'D'), (1, 0, 'S'), (0, -1, 'A'), (-1, 0, 'W')]

    # 将一维数组转换为二维网格
    grid = [[maze[i * cols + j] for j in range(cols)] for i in range(rows)]

    # BFS初始化
    queue = deque([(start, [])])
    visited = set([start])

    while queue:
        (x, y), path = queue.popleft()

        # 到达终点
        if (x, y) == end:
            return path

        # 探索四个方向
        for dx, dy, direction in directions:
            nx, ny = x + dx, y + dy

            # 检查边界和可通行性
            if 0 <= nx < rows and 0 <= ny < cols:
                if (nx, ny) not in visited and (grid[nx][ny] == 0 or grid[nx][ny] == 0x21):
                    visited.add((nx, ny))
                    queue.append(((nx, ny), path + [direction]))

    return None  # 无解


def visualize_maze(maze):
    """可视化迷宫"""
    rows, cols = 16, 16
    grid = [[maze[i * cols + j] for j in range(cols)] for i in range(rows)]

    print("迷宫地图 (0=路径, !=终点, 其他=障碍):")
    for i in range(rows):
        for j in range(cols):
            if grid[i][j] == 0:
                print('.', end=' ')
            elif grid[i][j] == 0x21:
                print('!', end=' ')
            else:
                print('#', end=' ')
        print()


def main():
    # 解析迷宫数据
    print("正在解析迷宫数据...")
    maze = parse_maze_data()

    # 检查迷宫大小
    print(f"迷宫大小: {len(maze)} 字节")

    # 可视化迷宫
    visualize_maze(maze)

    # 设置起点和终点
    start = (0, 0)
    end = (15, 15)  # 终点在右下角

    print(f"\n起点: {start}")
    print(f"终点: {end}")

    # 求解迷宫
    print("\n正在求解迷宫...")
    path = solve_maze(maze, start, end)

    if path:
        path_str = ''.join(path)
        print(f"找到路径! 长度: {len(path)}")
        print(f"WASD序列: {path_str}")

        # 计算MD5
        md5_hash = hashlib.md5(path_str.encode()).hexdigest()
        print(f"MD5哈希: {md5_hash}")

        # 构造flag
        flag = f"WHUCTF{{{md5_hash}}}"
        print(f"\nFLAG: {flag}")
    else:
        print("未找到路径!")


if __name__ == "__main__":
    main()

Try to find me

打开IDA一片茫然，啥都找不到。于是Shift + F12查字符串发现了：

strcpy((char *)(v0 + 40), "Software\\flag");
strcpy((char *)(v0 + 84), "flag");

找到了程序逻辑的尾巴：这里会把解密后的目标字符串写入注册表的HKEY_CURRENT_USER\Software\flag，然后残忍地删掉。不行，不能让它删掉（悲）于是我们patch掉这两个RegDeleteKey的调用，再次运行程序。注：本题的加密是曾经书记出的困难题，所以别想着静调了~

What can you find

这题可以当作一道misc去做：

> binwalk -e ./what_can_you_find.3dsx

得一张png，打开有：

这其实是非预期，下面介绍一种比较简洁的预期解法。

首先，我们了解到3DSX是ELF的变体，因此有映射区段并反编译的可能。通过查找Github已有的开源库我们发现了这个项目，这里作者其实已经对IDA 7以上的版本做了适配，我进行了少量修改使它符合IDA 9的标准，但不修改也没大问题，可以直接用。放入~/.idapro/loaders即可：

现在，我们就可以像处理一个正常的ELF可执行文件那样去处理它了。先查找字符串可以发现如上的逆天言论，跳转找到主函数：

这里是一个输入密码并显示图片的简单程序，因此我们要从中提取出图片文件。此处像上面非预期一样binwalk即可。

好多文件

好多文件！！！

但是没关系，观察Plugins发现，83和84单独分离出了自己的dll，猜测83和84是节目效果。

打开后发现是盘子（小）小故事，笑死了。

打开exe文件，太乱了，拖一下列表发现主要函数：

// Hidden C++ exception states: #wind=2
HBRUSH __fastcall WndProc(HWND hWnd, UINT msg, HDC wParam, LPARAM lParam)
{

    ...something_else...

      if ( (unsigned __int16)wParam == 2 )
      {
        GetWindowTextW(hEdit, buf, 32);
        score = j__wtoi(buf);
        if ( (unsigned int)score <= 0x64 )
        {
          std::wstring::wstring(&dllName);
          if ( score > 60 )
          {
            if ( score > 82 )
            {
              if ( score == 83 )
              {
                std::wstring::operator=(&dllName, L"Plugin_83.dll");
              }
              else if ( score == 84 )
              {
                std::wstring::operator=(&dllName, L"Plugin_84.dll");
              }
              else
              {
                std::wstring::operator=(&dllName, L"Plugin_85_100.dll");
              }
            }
            else
            {
              std::wstring::operator=(&dllName, L"Plugin_61_82.dll");
            }
          }
          else
          {
            std::wstring::operator=(&dllName, L"Plugin_0_60.dll");
          }
          v8 = std::wstring::c_str(&dllName);
          hMod = LoadLibraryW(v8);
          if ( hMod )
          {
            RunPlugin = (void (__fastcall *)(HWND__ *, int))GetProcAddress(hMod, "RunPlugin");
            if ( RunPlugin )
            {
              RunPlugin_1 = (std::wstring *)RunPlugin;
              RunPlugin(hWnd, score);
            }
            else
            {
              MessageBoxW(hWnd, &lpText_, &lpCaption_, 0x10u);
            }
            FreeLibrary(hMod);
            std::wstring::~wstring(&dllName);
          }
          else
          {
            RunPlugin_1 = std::operator+<wchar_t>(&result, &Left, &dllName);
            _Left = RunPlugin_1;
            std::operator+<wchar_t>(&v19, RunPlugin_1, Right);
            std::wstring::~wstring(&result);
  ...something_else...
  return 0;
}

我们发现了调用dll的关键函数：RunPlugin

分别打开几个Plugin的该函数，发现不同的惊喜：

直接猜XOR，最后结果肯定是whuctf{

不用说了，基础的换表base64，Cyberchef直接梭。

你这是典型的RC4逻辑，RC4思维，RC4素质。

分别解密后拼出完整flag：

whuctf{I_w1ll_give_y0u_an_extr@_po1nt}

hajimi_player

使用FindCrypt发现了一些AES相关的东西：

询问AI有：

函数 1：sub_140012E50

作用：实现 AES-128 的密钥扩展 (Key Expansion)。

概要说明：

输入：16 字节主密钥（a1）。

输出：176 字节扩展密钥（a2），即 11 轮 × 16 字节的轮密钥。

内部逻辑：

拷贝前 16 字节为初始轮密钥。

每 16 字节为一轮，执行：

RotWord（循环左移 1 字节）；

SubWord（用 Rijndael S-box 替换每个字节）；

首字节 XOR 上 Rcon（轮常数），并更新 Rcon；

按 AES 规则生成新的 16 字节轮密钥。

使用的表：RijnDael_AES_LONG_14001DBE0（AES S-box）。

👉 简单说：它把一个 16 字节的 AES 密钥展开成所有轮用的 176 字节密钥数据。

函数 2：sub_140013D70

作用：执行 AES 的 SubBytes 步骤（S-box 替换）。

概要说明：

输入：指向 16 字节数据块的指针（a1）。

对每个字节执行：byte = SBOX[byte]；

直接在原缓冲区中替换（就地操作），返回 16。

同样使用表 RijnDael_AES_LONG_14001DBE0（Rijndael S-box）。

👉 简单说：它把 16 字节“状态矩阵”中的每个字节都通过 AES S-box 映射，属于 AES 加密的一个核心变换步骤。

查找引用，发现了函数sub_140012CA0：

分析得出这是单块AES的加密实现，用GPT的话说就是：

这是单块 AES-128 加密的驱动函数——把 16 字节明文用 16 字节密钥加密成 16 字节密文（相当于 ECB 的单块操作）。流程就是标准 AES：初始轮密钥异或 → 9 个主轮（SubBytes→ShiftRows→MixColumns→AddRoundKey）→ 最后一轮（SubBytes→ShiftRows→AddRoundKey，不含 MixColumns）。

顺着该函数的线索，观察行移位和列混淆和轮密钥加的相关函数：

sub_140013A30：ShiftRows
sub_140013390：MixColumns
sub_140012C00：AddRoundKey（state XOR round key）

发现全是标准实现。（想到了书记骂盘子的“都多少年了还看不出来AES”）

全部更名后，想起了被PolyEncrypt支配的恐惧。

根据该函数的引用，跳转到了sub_140011990，这是一个登录对话框，输入用户名和密码。

然而，我们发现了奇怪的函数！

根据函数签名，它长得很像加密函数，但又不是我们之前分析的AES_EncryptBlock。导航进去并尝试分析之。发现是一个类TEA实现。这里Trunk和跳转比较多就不贴出完整流程了，给一个重命名表，可自行检验：

sub_140013E00 = TEA_EncryptBlock128_ECB
sub_140013EA0 = TEA_Encrypt64
sub_140011447 = TEA_Trunk_Wrapper

至此登录部分分析完毕，给出用户名和密码的解密脚本（解密需要的静态数据就不贴出了，很容易找到）。

WHUCTF2025_新生赛/RE/hajimi_player via 🐍
❯ cat dec.py
# Requires: pip install pycryptodome
from Crypto.Cipher import AES
import struct

# Constants from .rdata
C1 = bytes.fromhex(
    "F2 C1 8F 6E 89 18 46 70 DE E6 76 95 E7 BC 17 CB".replace(" ", ""))
C2 = bytes.fromhex(
    "4D D5 DF FB 1A CA 76 E6 1E 22 5F 3E 57 58 F3 EB".replace(" ", ""))

# TEA key words (little-endian 32-bit words as in the binary)
k0 = 0x00000001
k1 = 0x00000002
k2 = 0x00000003
k3 = 0x00000004
KEY_WORDS = (k0, k1, k2, k3)

# TEA parameters observed in the binary
DELTA = 0x0D33B470  # custom delta from disassembly
ROUNDS = 32


def le_bytes_to_u32_pair(b8):
    """Little-endian: first 4 bytes -> v0 (low dword), next 4 -> v1"""
    v0 = struct.unpack("<I", b8[0:4])[0]
    v1 = struct.unpack("<I", b8[4:8])[0]
    return v0, v1


def u32_pair_to_le_bytes(v0, v1):
    return struct.pack("<I", v0) + struct.pack("<I", v1)


def tea_decrypt_block64(v0, v1, k):
    """Decrypt single 64-bit block that was encrypted with the variant seen in binary."""
    k0, k1, k2, k3 = k
    mask32 = 0xFFFFFFFF
    # initial sum = delta * rounds mod 2^32
    sum_ = (DELTA * ROUNDS) & mask32
    # run rounds in reverse
    for _ in range(ROUNDS):
        # reverse of:
        # v5 += (k3 + (v4>>5)) ^ (sum + v4) ^ (k2 + (v4<<4));
        # v4 += (k1 + (v5>>5)) ^ (sum + v5) ^ (k0 + (v5<<4));
        v1 = (v1 - (((k3 + ((v0 >> 5) & mask32)) ^ ((sum_ + v0) & mask32)
              ^ ((k2 + ((v0 << 4) & mask32)) & mask32)) & mask32)) & mask32
        v0 = (v0 - (((k1 + ((v1 >> 5) & mask32)) ^ ((sum_ + v1) & mask32)
              ^ ((k0 + ((v1 << 4) & mask32)) & mask32)) & mask32)) & mask32
        sum_ = (sum_ - DELTA) & mask32
    return v0, v1


def tea_decrypt_128_ecb(cipher16, k):
    """Decrypt 16-byte block that was encrypted as two TEA-64 encryptions (ECB on two halves)."""
    assert len(cipher16) == 16
    out = bytearray(16)
    for i in range(2):
        blk = cipher16[i*8:(i+1)*8]
        v0, v1 = le_bytes_to_u32_pair(blk)
        pv0, pv1 = tea_decrypt_block64(v0, v1, k)
        out[i*8:(i+1)*8] = u32_pair_to_le_bytes(pv0, pv1)
    return bytes(out)


def aes128_decrypt_block(cipher16, key16):
    assert len(cipher16) == 16 and len(key16) == 16
    cipher = AES.new(key16, AES.MODE_ECB)
    return cipher.decrypt(cipher16)


# Step 1: decrypt username block (TEA variant)
plain_user_block = tea_decrypt_128_ecb(C1, KEY_WORDS)
print("Username block (hex):", plain_user_block.hex())

# remove trailing zero padding to get ASCII username (zero-padded)
username = plain_user_block.rstrip(b"\x00").decode('latin1', errors='replace')
print("Username:", repr(username))

# Step 2: decrypt password block using AES-128 with username-block as key
# The code uses the username block (16 bytes) as AES key directly.
plain_pass_block = aes128_decrypt_block(C2, plain_user_block)
print("Password block (hex):", plain_pass_block.hex())
password = plain_pass_block.rstrip(b"\x00").decode('latin1', errors='replace')
print("Password:", repr(password))

WHUCTF2025_新生赛/RE/hajimi_player via 🐍
❯ python dec.py
Username block (hex): 68616a696d696e616d656c75646f6f6f
Username: 'hajiminameludooo'
Password block (hex): 6d616e626f2331623265266562686a34
Password: 'manbo#1b2e&ebhj4'

获得用户名和密码。

接下来根据窗口逻辑，顺着指针dwNewLong_捋到函数sub_140012480，发现是一个文件解密器的实现。GPT大人如是说：

快速结论（一句话） sub_140012480 是 Hajimi Player 的窗口过程：用户点击 “select your hajimi file” 会把路径放到全局 FileName；点击 “play” 会读取 GetWindowLongPtr(hWnd, GWLP_USERDATA)（也就是登录时存的 Destination —— username+password 拼接字符串），把它作为“密钥/密钥材料”传给 sub_14001110E（初始化/派生解密上下文），然后调用 sub_140011451 把读到的文件数据用该上下文进行解密/处理，最后把解密后数据指向全局 ::Block/::Size 以供播放。也就是说 Player 在播放前会对选中文件进行解密，解密密钥由窗口的 user-data（登录时的 username+password）来派生/生成。

啊伟大的GPT大人！

解密文件部分主要涉及的是sub_14001110E和sub_140011451，分析得知：

...能得知什么，就一破RC4罢了。

解密之：

# RC4 decrypt for Hajimi Player files
key = (b"hajiminameludooo" + b"manbo#1b2e&ebhj4")  # username + password

def rc4_ksa(key: bytes):
    S = list(range(256))
    j = 0
    for i in range(256):
        j = (j + S[i] + key[i % len(key)]) & 0xFF
        S[i], S[j] = S[j], S[i]
    return S, 0, 0  # S, i, j

def rc4_prga(S, i, j):
    i = (i + 1) & 0xFF
    j = (j + S[i]) & 0xFF
    S[i], S[j] = S[j], S[i]
    K = S[(S[i] + S[j]) & 0xFF]
    return K, S, i, j

def rc4_crypt(data: bytes, key: bytes) -> bytes:
    S, i, j = rc4_ksa(key)
    out = bytearray(len(data))
    for n, b in enumerate(data):
        k, S, i, j = rc4_prga(S, i, j)
        out[n] = b ^ k
    return bytes(out)

inp = "video.hajimi"   # 改成你的文件名
outp = "output.bin"

with open(inp, "rb") as f:
    enc = f.read()

dec = rc4_crypt(enc, key)

with open(outp, "wb") as f:
    f.write(dec)

# 粗略看看是否像明文
head = dec[:64]
print("Decrypted head (hex):", head.hex())
try:
    print("ASCII head:", head.decode("latin1"))
except:
    pass

通过file命令查阅生成的基密文件后发现是个MP4，遂直接mpv播放之。

WHUCTF{h@jimin@meLud0_axiga@xiii}

byd气笑了。

Baby_HeavenGate

众所周知，Heaven's Gate是一种在32位程序环境下执行64位代码的混淆技术。于是，当我们看到这个JUMPOUT时，我们就知道要切到反汇编界面进行查看了。这里出现了牢门经典的call $+5、retf等汇编指令。

进门发现一个简单的异或：继续往下分析，又发现了经典牢门：分析可得，这里会把用户输入送入sub_402000函数中。当然，如果你实现没有执行某一步骤，你看到的可能不是正经的sub_402000，而是一些奇怪的东西。其实这里出题人已经通过区段名给了我们提示：这里是Heaven's Gate跳转到的64位代码处。我们通过IDA的Edit-> Segments -> Edit Segment将x64区段改为64位：核心的异或解密逻辑就搞定了。

因此，写出解密脚本如下：

# 加密数据
encrypted = [
    0x09, 0x2e, 0x27, 0x36, 0x39, 0x01, 0x65, 0x35, 0x71, 0x05,
    0x28, 0x20, 0x1d, 0x28, 0x23, 0x32, 0x34, 0x1d, 0x24, 0x61,
    0x27, 0x73, 0x05, 0x34, 0x36, 0x26, 0x12
]

# "Heaven's Gate" 密钥 (13个字符)
key = b"Heaven's Gate"

# 第一步：逆向第二步XOR（使用"Heaven's Gate"作为轮转密钥）


def get_key_char(index):
    return key[index % len(key)]

# 第二步：逆向XOR_Encrypt


def decrypt_xor_encrypt(encrypted_byte):
    for original in range(256):
        if encrypted_byte == (original + 39 - 2 * (original & 0x27)) & 0xFF:
            return original
    return None


# 完整解密
decrypted_step1 = [encrypted[i] ^ get_key_char(i) for i in range(27)]
decrypted_step2 = [decrypt_xor_encrypt(b) for b in decrypted_step1]

flag = ''.join(chr(b) for b in decrypted_step2)
print("解密结果:", flag)

解密结果: flag{Heavens_Gate_mastered}

天才侦探

打开发现奇怪的setjmp函数：

带着对它的疑惑，先看看别处的逻辑🤔

很轻松地，我们可以看出XOR和XXTEA_Encrypt加密的线索。

然而，XXTEA_Encrypt中部出现了疑似花指令的诡异跳转。切到汇编：经典的跳转到+1位置，在中间藏一个恶心人的幽灵call。NOP掉即可。

__int64 __fastcall XXTEA_Encrypt(char *Buf1, int n10, char *Can_y0u_catch_me)
{
    ...something...
  if ( n10 <= 1 )
  {
    if ( n10 < -1 )
    {
      v20 = -n10;
      v10 = 52 / -n10 + 6;
      v14 = 1131796 * v10;
      v19 = *(_DWORD *)Buf1;
      do
      {
        v8 = (v14 >> 2) & 3;
        for ( i = v20 - 1; i; --i )
        {
          v16 = *(_DWORD *)&Buf1[4 * (i - 1)];
          v5 = &Buf1[4 * i];
          *(_DWORD *)v5 -= ((v19 ^ v14) + (v16 ^ *(_DWORD *)&Can_y0u_catch_me[4 * (v8 ^ i & 3)]))
                         ^ (((4 * v19) ^ (v16 >> 5)) + ((v19 >> 3) ^ (16 * v16)));
          v19 = *(_DWORD *)v5;
        }
        v17 = *(_DWORD *)&Buf1[4 * v20 - 4];
        *(_DWORD *)Buf1 -= (((4 * v19) ^ (v17 >> 5)) + ((v19 >> 3) ^ (16 * v17)))
                         ^ ((v19 ^ v14) + (v17 ^ *(_DWORD *)&Can_y0u_catch_me[4 * v8]));
        v19 = *(_DWORD *)Buf1;
        v14 -= 1131796;
        --v10;
      }
      while ( v10 );
    }
  }
  else
  {
    v9 = 52 / n10 + 6;
    v13 = 0;
    v15 = *(_DWORD *)&Buf1[4 * n10 - 4];
    do
    {
      v13 += 0x114514;
      v7 = (v13 >> 2) & 3;
      for ( j = 0; j < n10 - 1; ++j )
      {
        v18 = *(_DWORD *)&Buf1[4 * j + 4];
        v3 = &Buf1[4 * j];
        *(_DWORD *)v3 += ((v18 ^ v13) + (v15 ^ *(_DWORD *)&Can_y0u_catch_me[4 * (v7 ^ j & 3)]))
                       ^ (((4 * v18) ^ (v15 >> 5)) + ((v18 >> 3) ^ (16 * v15)));
        v15 = *(_DWORD *)v3;
      }
      v4 = &Buf1[4 * n10 - 4];
      *(_DWORD *)v4 += ((*(_DWORD *)Buf1 ^ v13) + (v15 ^ *(_DWORD *)&Can_y0u_catch_me[4 * (v7 ^ j & 3)]))
                     ^ (((4 * *(_DWORD *)Buf1) ^ (v15 >> 5)) + ((*(_DWORD *)Buf1 >> 3) ^ (16 * v15)));
      v15 = *(_DWORD *)v4;
      --v9;
    }
    while ( v9 );
  }
  return 0xFFFFFFFF / 0;                        // 这里会触发除0异常，抛出浮点数异常然后触发longjmp
}

然而，在XXTEA加密的末尾，我们发现了奇怪的除0行为！

这里非常不对劲，除0会引发报错。猜测这里的报错是有意为之，我们找到错误处理函数Function：

一个永真跳转，先执行sub_4015F0，再执行longjmp_w。到这里我们明白了上面的setjmp究竟起何作用：一开始Buf是0，执行XXTEA加密，然后XXTEA加密末尾通过除零触发Function，修改Buf为1并跳到setjmp处，使程序进入XOR_Encrypt的分支。

于是，问题就在于：sub_4015F0()做了什么。

分析各种跳转发现，这里又是一个异或。

于是理清了所有加密步骤，写出解密脚本：

import struct

# 密文数据 (从 Cipher)
cipher_bytes = bytes([
    0x8A, 0xFF, 0x4B, 0x28, 0xF8, 0x79, 0x53, 0xA8,
    0xFA, 0xE0, 0x9B, 0x21, 0x9D, 0xAB, 0x79, 0x01,
    0xCD, 0xD7, 0x49, 0xA5, 0x7A, 0x05, 0x0B, 0x94,
    0xF5, 0xD8, 0xBA, 0xD9, 0x4B, 0x26, 0x3E, 0x0C,
    0x8F, 0x91, 0x70, 0x41, 0x05, 0xE9, 0x40, 0xD7
])

# sub_4015F0 中使用的 cipher 数组 (从 unk_49F020 提取，按 DWORD 存储)
unk_49F020 = [
    0x0000003E, 0x00000034, 0x000000BE, 0x000000D6,
    0x00000000, 0x0000008F, 0x000000C8, 0x00000006,
    0x00000008, 0x000000E2, 0x000000F9, 0x00000005,
    0x000000FD, 0x000000E0, 0x0000003A, 0x000000D0,
    0x0000000A, 0x000000C2, 0x000000D7, 0x000000D4,
    0x0000000C, 0x0000001E, 0x00000047, 0x0000004D,
    0x0000009D, 0x00000020, 0x000000F9, 0x00000095,
    0x0000009F, 0x0000000F, 0x000000E8, 0x00000075,
    0x000000CA, 0x000000F6, 0x00000096, 0x00000096,
    0x0000007B, 0x00000028, 0x0000001B, 0x000000D1
]

# XXTEA 密钥
xxtea_key = b"Can_y0u_catch_me"

# XOR 密钥
xor_key = b"Siesta"


def xxtea_decrypt(v, k):
    """XXTEA 解密算法"""
    def MX(sum, y, z, p, e, k):
        return ((z >> 5 ^ y << 2) + (y >> 3 ^ z << 4)) ^ ((sum ^ y) + (k[p & 3 ^ e] ^ z))

    n = len(v)
    rounds = 6 + 52 // n
    sum = (rounds * 0x114514) & 0xFFFFFFFF
    y = v[0]

    while rounds > 0:
        e = (sum >> 2) & 3
        for p in range(n - 1, 0, -1):
            z = v[p - 1]
            v[p] = (v[p] - MX(sum, y, z, p, e, k)) & 0xFFFFFFFF
            y = v[p]
        z = v[n - 1]
        v[0] = (v[0] - MX(sum, y, z, 0, e, k)) & 0xFFFFFFFF
        y = v[0]
        sum = (sum - 0x114514) & 0xFFFFFFFF
        rounds -= 1

    return v


def decrypt():
    # 步骤1: 逆 XOR_Encrypt (与 "Siesta" 异或)
    data = bytearray(cipher_bytes)
    for i in range(40):
        data[i] ^= xor_key[i % len(xor_key)]

    print("Step 1 - 逆 XOR_Encrypt:")
    print(' '.join(f'{b:02x}' for b in data))

    # 步骤2: 逆 sub_4015F0 ((data ^ cipher[i]) - 1)
    for i in range(40):
        # 原加密: Input[i] = (Input[i] + 1) ^ cipher[i]
        # 逆运算: Input[i] = (data[i] ^ cipher[i]) - 1
        data[i] = ((data[i] ^ (unk_49F020[i] & 0xFF)) - 1) & 0xFF

    print("\nStep 2 - 逆 sub_4015F0:")
    print(' '.join(f'{b:02x}' for b in data))

    # 步骤3: XXTEA 解密
    # 将字节数组转换为 32 位整数数组（小端序）
    v = list(struct.unpack('<10I', bytes(data)))

    # 将密钥转换为 32 位整数数组
    k = list(struct.unpack('<4I', xxtea_key[:16]))

    # 执行 XXTEA 解密
    decrypted = xxtea_decrypt(v, k)

    # 转换回字节
    result = struct.pack('<10I', *decrypted)

    print("\nStep 3 - XXTEA 解密:")
    print(' '.join(f'{b:02x}' for b in result))

    # 尝试解析为字符串
    try:
        flag = result.decode('ascii', errors='ignore')
        print(f"\n解密结果: {flag}")
        return flag
    except:
        print("\n解密结果 (hex):", result.hex())
        return result


if __name__ == "__main__":
    print("=" * 60)
    print("开始解密...")
    print("=" * 60)
    print()

    result = decrypt()

解密结果: WHUCTF{U_ar3_as_pr0f3ssional_as_siesta!}

感想

本次迎新赛拿到了个总榜第二。当然还是感谢学长们不杀之恩。

第一天下午去了Deepin的WHLUG，没写题，第二天运动会+百团大战+游园会，算是玩爽了，也没怎么写题，我忏悔喵。

最后，逆向工程这个方向，从迎新赛打到moe，从NewStar打到ILoveCTF，甚至在强网杯还干出来一题。再回头看看迎新赛，虽不能说轻舟已过万重山，至少也翻过了一两重吧。

中气爱讲座记录

Fri, 17 Oct 2025 00:00:00 GMT

气象科普最前线

结缘科普与科普的历程

中气爱连续存在了 14~15 年（刚上初中时就创立了）。

关心天气：一路南下，今年的秋好像跟往年不太一样。整个天永远是阴沉的，雨很大。（？为何呢）

来自广东潮汕，自小学二年级就开始关注气象。潮汕作为沿海地区，每年夏天有各种台风侵袭。"珍珠"侵袭当晚，台风裹挟的雨像针一样非常吓人------大自然并不温和。

学生时代痴迷台风，不止喜欢表面，还会关注机理------台风为何发生？台风如何行动？台风为何可以预测？......

结缘台风论坛，中气爱的"发源地"。创作了大量优质的气象科普内容。开始阅读大气科学的大学教材。午休时捧着《天气学原理与方法》。==看不懂也要看。（这一点想起了小学时热爱黑客文化的我）==

正值 2011 年微博出现，"中气爱"开始正式更新，早期的"140 字"科普训练------至今共创作微博 42760 则。（这一点和当今的短视频"感觉"是一脉相承的）

2015 开办微信公众号，几天一次的"天气沙盘推演"（意图塑造战场般紧张刺激的氛围）==造就了中气爱的独特文风==，至今已创作文章 1992 篇。

2022 年正式开始视频创作，从图文到视频的"惊险一跃"。

2022 年并非规划出来，从 2020 就开始思考尝试------第一个视频只有 3 分钟，收获了 3000 的播放量。紧接着创作第二条，只有 700~800 人看。突然有一天（2022 台风活跃）播放量上去了。==（厚积薄发）==

在探索中形成合适的风格，而非尝试事先规划。

从而造就了如今的中气爱------全网 1500 万粉丝，团队运营了内容账号矩阵（中气爱、中气爱怎么说、科普航、中气爱科技新知...）

科普心得

中气爱的内生动力：对天气现象的天然、强烈、持久的兴趣。（科普也存在"外部性"^1）虽然兴趣方向不同，但会有"让更多人知道"的共同乐趣。
因热爱而探索，自发创作，业务训练，技术研发...... 从线上到线下，实地追击台风。（从纯粹的热爱转变到主动的实践）
干一行爱一行（当你想持之以恒的创作，没有受众的支持很难坚持）

科普语言的选择

学术语言，业务语言，网络语言------三者有联系，更有区别。

台风"格美"打转，如何解读？

学术：多专业名词，侧重客观描述，复杂且难以理解业务：详细描述，中心不明确，注意力容易跑偏。

探索网络语言------观众最希望听什么？ ==不感兴趣"为什么"，但关心"怎么样, 有何影响"^2。例如："对此不少朋友感到困惑，甚至害怕。有人说格美要掉头去日本韩国了，不会再登陆我国了；还有人说格美要绕开台湾，直接一手登陆福建了。这两种说法都不正确，由于 xxx 山脉存在，扰乱台风环流，xxx，这是正常的。"。

做科普时尽量避免急切地讲"为什么"，要先抛出一个不那么"科普"的问题，让受众驻足停留个几秒钟，再不经意穿插科普知识点。（用故事的糖衣包裹枯燥无味的科学知识）

在坚持"科"的同时，尽可能"普"

三个例子 "热带扰动"：专业性，晦涩性，学术性，专注"机理"。替换成"台风胚胎"后，让观众理解：热带扰动是台风的前身，是其前置条件，专注"联系"。（而且是与受众感兴趣的元素有联系）

"台风外围下沉气流"：受众关心"台风来之前为何如此热？"，于是替换成"空调外机"：台风中心在制冷，能量往外抛就是"空调外机"------诙谐，但尽可能捕捉气象背后的科学原理。

"各种东西"：不列举长串名词，而是以诙谐的用法概称之，一方面直观强调严重性，一方面可以引起对"各种东西"好奇的观众对气象知识的兴趣。

（重要的不是比喻这一手法，而是往什么方向比喻）

在长期科普中形成科普直觉

对大众关注的热点，痛点问题的捕捉能力和阐释能力。迅速确定选题，分析呈现模式（故事片的手法，呈现大量实况）。同时要关注发布时间：高温稍稍降低，此时人们关切是否还会高温，于是及时推出，回应关切。

科普和科研紧密融合

科普成果成为了科研论文的素材。科研向公众号向公众提供专业前沿科普内容。

AI 出现后，其完全不依赖任何物理公式，而是一个纯涌现的过程的特性很值得分析。趁此社会热点，抓住时机科普（甚至训练了自己的 AI 气象预测模型坤舆并对其原理进行科普）。==当把这方面内容讲给他人听，反而更有利于科研灵感的产生，加深对科研内容的理解==。科普与科研并不矛盾。

成就感是科普的常见驱动力

"有时候学霸的讲解比老师更靠谱"------将知识给别人讲懂，是一种成就感。

随着科普，另一个很重要的意义涌现------以郑州 7.20 暴雨为例，团队微博小编及时关注，发了很多微博。但后来发生的事情远超预料。

当天的郑州雨量直接破了纪录。团队意识到这样的降雨量肯定伴有意外事件发生，于是积极提醒，一天发了五十条微博提醒大家关注和警惕。事件结束后，观众纷纷发来感谢------让更多的人了解科学，是一种责任感。

单对单地讲气象不一定会让人感兴趣，但正如大数定律所说：跟大量受众传播时，一定会有不少人会从科普中意识到自己对气象的热爱，从而对社会产生益处。

气候变暖面前，我们能做什么

低碳环保肯定正确，但每天提只会让人枯燥。中气爱的角度是：气候变化是一个事实，让所有人意识到气候变暖离我们并不远。

每天绑架别人说"你不能开车，要公共交通，你不能开空调......"并不现实，但一方面可以通过长久地科普让人们潜意识中加深对气候变化的印象，一方面介绍大气科学前沿的研究者，让人们知道这些知识非常重要，从而帮助公众建立对于大气科学的兴趣，培养接力者。

中气爱的口号之一：让大气科学广为人知。

提问时间

如何平衡科普、科研与生活的关系

其实这是一个很难的问题，大家都会觉得时间不够用。要更多地利用碎片时间。整块的时间拿来做正事（连续的时间才能做更好的科研），零碎的时间用于科普（科研前画个半小时关注一下气候变化过程，创作微博之类）。注重劳逸结合，好好生活。

如何在专业课学经济时还能保持对气象的高水平认知

中气爱不做预测，只是把气象台的预测用一种通俗易懂的方式说出来。

对于气象知识的积累是从初中开始持之以恒的，每天花个半小时，积少成多，能维持对气象的认知。归根结底还是如何协调安排自己的时间。明确主业，利用零碎时间维持大气方向知识量。

遇到负面反馈的观众，如何看待和应对

相信绝大多数观众发心是善意的，"如果...... 的话，会更好"。欣然接受，视为一种鞭策。

使用 Typst 渲染数学公式

Wed, 15 Oct 2025 00:00:00 GMT

原理

尝试使用 astro-typst 渲染数学公式。

笑死，完全用不了，样式也是乱的，目录也是乱的，渲染也是乱的。

于是使用 rehype-typst，并大量定制主题样式，有了现在这个勉强可以接受的渲染方案。这样今后我 Obsidian 上的数学笔记就能同步过来了。

参考了博主 huawen 的方案，在此致谢。

如果只需要渲染 Typst Math，装个rehype-typst后直接写就行了。但我遇到了三个问题：

明暗页面总有一个会吃掉Typst的文字
内联公式总是会自己换行。
TOC识别元素时会将渲染出的svg里的标题元素渲染成目录项

经过和 AI 的~~对骂~~探讨，得出了修改方法

解决方案与修改内容

1. 创建自定义Rehype插件：`rehype-filter-svg-headings.ts`

问题：TOC会识别Typst生成的SVG内部的h5:div元素作为标题

解决方案：

创建了src/plugins/rehype-filter-svg-headings.ts插件
检测并过滤SVG内部的命名空间标题元素（h5:div）
在构建时自动移除这些内部标题，防止它们出现在目录中

关键代码：

// 检测SVG内部的标题元素
const isHeading =
  node.tagName &&
  (/^h[1-6]$/.test(node.tagName) || // 标准HTML标题
    node.tagName.includes('h5:') || // 命名空间标题如 h5:div
    classNameStr.includes('tsel')) // Typst选择元素

2. 优化CSS样式：`src/assets/styles/app.css`

问题1：内联公式总是换行显示

解决方案：

为段落内的Typst SVG添加内联显示样式
优化垂直对齐和大小缩放

/* 行内公式样式 */
p .typst-doc,
p svg.typst-doc {
  display: inline !important;
  vertical-align: -0.3em !important;
  margin: 0 0.1em !important;
  max-height: 1.4em !important;
  transform: scale(1.15) !important;
  transform-origin: 0 0.5em !important;
}

问题2：块级公式大小异常

解决方案：

确保块级公式不受行内样式影响
保持块级公式的原始大小

/* 块级公式 - 不受样式影响 */
.typst-doc {
  display: block;
  max-width: 100%;
  height: auto;
}

问题3：主题切换时Typst公式显示异常

解决方案：

添加JavaScript控制的深色模式支持
使用CSS滤镜实现颜色反转

/* JavaScript控制的深色模式 */
html.dark svg.typst-doc {
  filter: invert(100%) sepia(0%) saturate(367%) hue-rotate(19deg) brightness(105%) contrast(101%) !important;
}

/* 浅色模式重置滤镜 */
html:not(.dark) svg.typst-doc {
  filter: none !important;
}

3. 配置Astro插件

在astro.config.ts中配置了自定义插件：

// 添加自定义rehype插件
rehypePlugins: [
  // ... 其他插件
  rehypeFilterSvgHeadings
]

最终效果

经过这些修改，现在Typst数学公式能够：

✅ 行内公式正确显示在行内，不换行
✅ 块级公式保持原始大小和块级显示
✅ TOC只显示真正的文章标题，不包含数学公式字符
✅ 在深色/浅色主题切换时正确显示
✅ 支持复杂的数学表达式和矩阵

大部分代码使用 Cline + DeepSeek V3.2 完成，感谢Vibe Coding救我等不会前端的小白于水火。

简单公式示例

这是一个行内公式示例: $f(x) = x^2$ 看起来不错的。

而这里就可以接下一行了

这里是再下一行

$$ because sum_(i=1)^(16)f(i) = 5 \ therefore cases(x^2 + 2x + 1 = 6, x - 5 =7) $$

行间公式也能正常显示

矩阵与向量

$$ mat(1+lambda,1,1, 0; 1,1+lambda,1,3; 1,1,1+lambda,lambda) -> mat(1,1+lambda,1,3; 0,-lambda,lambda,lambda-3; 0,0,-lambda(lambda+3),(lambda+3)(1-lambda); delim: "(") $$

渲染一段完整的数学笔记

证明：

(1).

$$ "要证：" forall epsilon > 0, exists delta > 0, forall 0 < |x - 1| < delta , |2x -2|<epsilon \ "取：" delta = epsilon/4 , "则 " 0< |x-1| < epsilon/4 -> |2x - 2| = 2 |x-1| < epsilon/2 < epsilon \ thick \ therefore lim_(x->1) (2x-1)=1 $$

(2).

$$ "要证：" forall epsilon > 0, exists delta > 0, forall 0 < |x-1| < delta, |(x+1) - 2 | < epsilon \ thick \ therefore "取 " delta = epsilon/2 , "则：" |(x^2-1)/(x-1) -2| = |x+1-2| = |x-1|< delta = epsilon/2 < epsilon \ thick \ therefore lim_(x->1) (x^2-1)/(x-1) = 2 $$

(3).

$$ "要证：" forall epsilon > 0, exists delta > 0, forall 0<|x-2|<delta, |x^2 - 4| < epsilon \ therefore "取" delta_1 = 1, "则 " |x+2| |x-2| < 5 |x-2| <epsilon -> delta_2 < 1/5 \ therefore delta = min{1, epsilon/5} \ thick \ "此时 " |x^2 - 4| < 5 < epsilon "或" |x^2-4| < 5* epsilon/5 < epsilon \ thick \ therefore lim_(x->2) x^2 = 4 $$

记一杯花茶的逆向工程

Mon, 25 Aug 2025 00:00:00 GMT

（本文是新手 re 同学的学习笔记，所以可能比较啰唆，见谅~）

审题

审题可知，flower 代表花指令，tea 代表加密算法是 TEA 或者某种 TEA 的衍生算法。

分析加密算法

首先导航到 Strings 发现一个很明显的 base 64 编码数据 bTRwbGUxc3hubg==，解密后发现 ~~主席是男娘~~ 得到了 m4ple1sxnn，猜想应该是密钥。

再使用 FindCrypt 插件查看是否有明显的常见加密算法迹象：

没有看到有用信息，重新根据 Strings 中保留的字符串，定位到跳转点。整理后代码如下（其中包含对我的一些疑问点的注释，感谢 GPT 5 的解答）：

__int64 sub_140001A79()
{
  _QWORD v1[2]; // 实际扮演的是 结构体 而不是单纯数组。
                // v1[0] 保存了地址值（这里是 &unk_1400C82E0）。
                // v1[1] 保存了长度值（15）。
                // sub_1400AB3F0 接收到的第二个参数本质上就是“指向一块数据的指针 + 这块数据的长度”。
  _BYTE input[32]; // [rsp+30h] [rbp-70h] BYREF
  _BYTE key[32]; // [rsp+50h] [rbp-50h] BYREF
  _BYTE cipher[30]; // [rsp+70h] [rbp-30h] BYREF
  char v5; // [rsp+8Eh] [rbp-12h] BYREF
  char v6; // [rsp+8Fh] [rbp-11h] BYREF
  char *v7; // [rsp+90h] [rbp-10h]
  char *v8; // [rsp+98h] [rbp-8h]
  sub_14000DC40();
  v8 = &v5;
  v1[0] = &unk_1400C82E0;
  v1[1] = 15;
  sub_1400AB3F0(cipher, v1, &v5);
  sub_1400A1160(&v5);
  v7 = &v6;
  base64_decode(key, "bTRwbGUxc3hubg==", &v6); // 这里明显是base64处理函数，外部做解码即可。
  sub_1400A10A0(&v6);
  printf(&unk_1400C6BC0, "plz input your flag: "); // 这里应该是单纯打印字符串的函数
  // 但是读取输入为何要顺带读一个"全局变量？"
  // 绝大多数 C 程序在调用 `printf` 的时候，编译器最终会把它翻译成 `fprintf(stdout, "msg")`。
  // `stdout` 在 Windows CRT 里就是一个全局变量，编译时常常会被放在 `.data` 里，反编译看上去就是 `&unk_1400C6BC0`。
  get_input(input);// 显然，获取输入
  trim_input(&unk_1400C6860, input); // 这里读取一个全局变量并对input做处理
  // 可能的处理方式：1. 标准化字符串，删除空格和特殊字符之类。 2. 对字符串和读入的全局变量做变换，使之以某种方式"混合"或者"发生作用关系"。这里我们就认为是普通的处理输入。
  if ( (unsigned __int8)xxtea_encrypt(input, cipher, key) )// 同时出现密文，密钥和输入，显然是加密比较函数了
    printf(&unk_1400C6BC0, "Right!let_us_have_a_cup_of_tea!!!\n");
  else
    printf(&unk_1400C6BC0, "oh_no_no_no!!!\n");
  sub_1400AFEB0(input);
  sub_1400AFEB0(key);
  sub_1400AB510(cipher);
  // 对那几个栈上对象做收尾工作：释放可能的堆内存、把长度归零等。
  return 0;
  // 标准返回函数
}

于是我们清理 sub_1400018CA (在上述清理过的代码中为 xxtea_encrypt )代码：

__int64 __fastcall xxtea_encrypt(__int64 input, __int64 cipher, __int64 key)
{
  size_t n16; // rbx
  const void *v4; // rax
  size_t Size; // rsi
  const void *v6; // rbx
  void *v7; // rax
  __int64 v8; // rbx
  __int64 v9; // rax
  _BYTE v11[32]; // [rsp+20h] [rbp-70h] BYREF
  _QWORD v12[2]; // [rsp+40h] [rbp-50h] BYREF
  _BYTE v13[43]; // [rsp+50h] [rbp-40h] BYREF
  char v14; // [rsp+7Bh] [rbp-15h] BYREF
  int v15; // [rsp+7Ch] [rbp-14h] BYREF
  char *v16; // [rsp+80h] [rbp-10h]
  unsigned __int64 v17; // [rsp+88h] [rbp-8h]
  sub_140001450(v13, key);

  // 下面是处理 key 的函数
  v12[0] = 0;
  v12[1] = 0;
  if ( (unsigned __int64)sub_14002F0A0(v13) > 0x10 )
    n16 = 16;
  else
    n16 = sub_14002F0A0(v13);
  v4 = (const void *)sub_1400AD570(v13);
  memcpy(v12, v4, n16);
  // 将10位的小暖男（确信）密钥扩展成16位，空缺处补0
  // eg: maple1sxnn -> maple1sxnn000000

  v17 = (unsigned __int64)(sub_14002F0A0(input) + 3) >> 2; // XXTEA 所需的"按4字节对齐后的词数"

  v16 = &v14;
  v15 = 0;
  sub_1400AB490(v11, v17, &v15, &v14);
  sub_1400A1160(&v14);
  Size = sub_14002F0A0(input);
  v6 = (const void *)sub_14002EEB0(input);
  v7 = (void *)sub_1400AB3C0(v11);
  memcpy(v7, v6, Size);
  // 准备工作，实现一些拷贝，缓冲之类的操作

  v8 = sub_14002D4C0(v11);          // 当前数据长度（字节数）
  v9 = sub_1400AB3C0(v11);          // 数据指针
  xxtea_encrypt(v9, v8, v12);       // XXTEA 加密的核心函数
  // 这里把 buf[0..len-1] 按小端 32-bit 词视图、长度 n = (len+3)>>2，用 key（四个 32-bit 子键）做循环加密。
  LODWORD(v8) = sub_1400BF530(v11, cipher);
  sub_1400AB510(v11);
  sub_1400AFEB0(v13);
  return (unsigned int)v8;
}

可知：

使用 m4ple1sxnn 作为密钥材料（16 字节，因此填 0）
对用户输入的flag进行加密（通过sub_1400016DC函数）
将加密结果与预存的数据进行比较

花指令处理

于是定位到 sub_1400016DC 函数，发现是一个跳转。显然这里 JUMPOUT 出的地址才是真正的实现函数。但是由于它没有被 IDA 识别为函数，我们只能强行看汇编了。

void __fastcall encrypt_impl(__int64 a1, unsigned __int64 a2)
{
  if ( a2 > 1 && 0x34 / (unsigned int)a2 != -6 )
    JUMPOUT(0x140001744LL);
}

(AI 注释： 你不一定要把 JUMPOUT 目标当“新函数”看。 JUMPOUT 往往只是跳到一个代码块（可能在同一函数里，或落在别的函数的中间/尾块），反编译器因此不把它认作函数入口。先把它当作“落点基本块”去读即可；若你确认那儿才是一个独立入口，再手动建函数。 )

; 噪音 / 误解码（建议当作 db）
; xor     eax, [rcx+4514F845h]
; adc     [rax], eax
; xor eax, [rcx+4514F845h] 带巨大的位移，对未定义的 RCX 取内存；adc [rax], eax 会对 EAX 指向的地址写内存，若 EAX 未设定几乎必崩——它们既不保存现场也不建立栈框，和后续“规整的逻辑”断层。
; loc_14000174B  ← 以这里作为代码起点更合理
mov     eax, [rbp+var_8]      ; eax = sum !!!注意，这里是读取sum的地方!！初始的Sum就是我们需要的Delta
shr     eax, 2
and     eax, 3                ; eax = (sum >> 2) & 3  → e ∈ {0,1,2,3}
mov     [rbp+var_18], eax     ; e
mov     [rbp+var_C], 0        ; i = 0
jmp     loc_140001806         ; 进入主循环

如果我们将上面两条花指令 NOP 掉，其实可以看见部分 XXTEA 的实现（Delta 累加部分被更多花指令隐藏掉了）：

void __fastcall encrypt_impl(_DWORD *a1, unsigned __int64 a2, __int64 a3)
{
  unsigned int *v3; // rax
  unsigned int *v4; // rax
  unsigned int v6; // [rsp+4h] [rbp-1Ch]
  unsigned int v7; // [rsp+10h] [rbp-10h]
  unsigned int i; // [rsp+14h] [rbp-Ch]
  unsigned int v9; // [rsp+1Ch] [rbp-4h]
  if ( a2 > 1 )
  {
    v9 = a1[(unsigned int)(a2 - 1)];
    v7 = 0x34 / (unsigned int)a2 + 6;
    while ( v7-- )
    {
      for ( i = 0; i < (int)a2 - 1; ++i )
      {
        v6 = a1[i + 1];
        v3 = &a1[i];
        *v3 += (v6 + (v9 ^ *(_DWORD *)(4LL * (i & 3) + a3))) ^ (((4 * v6) ^ (v9 >> 5)) + ((v6 >> 3) ^ (16 * v9)));
        v9 = *v3;
      }
      v4 = &a1[(unsigned int)(a2 - 1)];
      *v4 += (*a1 + (v9 ^ *(_DWORD *)(4LL * (i & 3) + a3))) ^ (((4 * *a1) ^ (v9 >> 5)) + ((*a1 >> 3) ^ (16 * v9)));
      v9 = *v4;
    }
  }
}

进入主循环（太长了不贴），可以发现是一个标准的"判断是主循环还是尾循环，并执行符合 XXTEA 规则的轮加密"的函数。自此我们确定了该函数是 XXTEA 加密。（这一步需要有密码学基础，至少得熟悉常见的对称加密的代码实现，可以选择问AI）下一步就是找 Delta 了。

然而，上面 FindCrypt 的结果已经指出：TEA 类算法中经典的 Delta 值（0x9E3779B9）并没有出现在我们的程序中（表现为检测不出 TEA 类算法），于是我们猜测该程序有自定义的 Delta 值。结合上述内容可知 Delta 被花指令隐藏，该部分处理比较困难，于是考虑通过动态调试获取之（由于笔者使用 Linux 环境，这里使用 winedbg + gdb，选用x64dbg 等亦可）：

动态调试

首先，我们需要解决一个问题：去哪找？

根据上述内容，注意到：

mov     eax, [rbp+var_8]      ; eax = sum !!!注意，这里是读取sum的地方!！初始的Sum就是我们需要的Delta

这里就是我们需要的函数，它的地址在 IDA 中可以发现是 0x14000174b，于是启动 gdb 并下断：

pwndbg>  winedbg --gdb another_flower_tea.exe
(Some Output)
pwndbg>  b *0x14000174b # 下断点
pwndbg>  c # continue，表示执行程序到断点
# 等待程序停在断点处，中间可能需要按照源程序要求执行输入操作，随便输入些东西即可
pwndbg>  set $sum_addr = $rbp - 8 # 源程序显示采用的是负偏移，所以我们先提前算出负偏移的 offset
pwndbg> x/wx $sum_addr
0x21fd68:	0x00114514

好了！我们拿到了初始的 Delta——0x00114514，一个非常符合网安学长精神状态的数。于是根据标准的 XXTEA 加密过程，可以开始写解密脚本了。

写出解密脚本如下（可以求助 AI 或翻阅 Github 现成实现并修改 Delta 值）：

#include <stdint.h>
#include <stdio.h>
#include <string.h>
#define DELTA 0x00114514
void xxtea_decrypt(uint32_t *v, uint32_t len, uint32_t *k) {
  uint32_t n = len - 1;
  uint32_t z = v[n], y = v[0], sum = 0, e;
  uint32_t p, q;
  q = 6 + 52 / (n + 1);
  sum = q * DELTA; // 初始sum值
  while (sum != 0) {
    e = (sum >> 2) & 3;
    for (p = n; p > 0; p--) {
      z = v[p - 1];
      y = v[p] -= (((z >> 5) ^ (y << 2)) + ((y >> 3) ^ (z << 4))) ^
                  ((sum ^ y) + (k[(p & 3) ^ e] ^ z));
    }
    z = v[n];
    y = v[0] -= (((z >> 5) ^ (y << 2)) + ((y >> 3) ^ (z << 4))) ^
                ((sum ^ y) + (k[(p & 3) ^ e] ^ z));
    sum -= DELTA;
  }
}
// 将密钥扩展为4个uint32_t，不足部分填0
void key_setup(const char *key_str, uint32_t *key) {
  memset(key, 0, 16); // 先清零
  memcpy(key, key_str, strlen(key_str) < 16 ? strlen(key_str) : 16);
}
int main() {
  // 加密数据（60字节，15个uint32_t）
  uint8_t enc_data[] = {
      0x92, 0x37, 0x53, 0x0B, 0x48, 0x37, 0x0A, 0x7D, 0x08, 0xF6, 0x91, 0x5F,
      0xA2, 0x4B, 0x3C, 0xAD, 0x06, 0xFB, 0x6C, 0x8B, 0xF3, 0x51, 0x74, 0x6D,
      0xF3, 0x8F, 0x6F, 0x58, 0x20, 0x75, 0xFE, 0x81, 0xE0, 0x46, 0x0A, 0x88,
      0x0E, 0x80, 0x04, 0xBD, 0xBE, 0xCB, 0x4B, 0x74, 0xC4, 0x58, 0x12, 0x30,
      0x91, 0x29, 0x4D, 0x12, 0x1E, 0xCE, 0x38, 0x01, 0xD5, 0xF3, 0x0D, 0x23};
  uint32_t data[15];
  memcpy(data, enc_data, sizeof(data));
  // 密钥
  const char *key_str = "m4ple1sxnn";
  uint32_t key[4];
  key_setup(key_str, key);
  // 解密
  xxtea_decrypt(data, 15, key);
  // 以字符串形式输出（可读明文）
  printf("\n解密结果 (string):\n");
  char *str = (char *)data;
  for (int i = 0; i < 60; i++) {
    if (str[i] >= 32 && str[i] <= 126) {
      putchar(str[i]);
    } else if (str[i] == 0) {
      putchar('\\');
      putchar('0');
    } else {
      printf("\\x%02X", (unsigned char)str[i]);
    }
  }
  putchar('\n');
  return 0;
}

江南漫溯 | 南京篇

Thu, 26 Jun 2025 14:26:00 GMT

import { Aside } from 'astro-pure/user' import { Masonry } from 'astro-masonry' import { Image } from "astro:assets" import BilibiliVideoCard from "../../../components/Bilibili/BilibiliVideoCard.astro"

在我的音乐人圈子里有位好友，在南京大学念书，因而我很早便对南京心生向往，想去亲自看看秦淮风物，但却懒癌发作，迟迟不愿计划出发，恰巧一天下午准备看看南京博物院是否还有预约位，抱着试试看的心态随手约了20号上午的票，竟然成功了。于是蛰伏已久的旅行热情突然被唤起，匆匆整顿行装，17号便迫不及待地出发，扑向江南的怀抱。

🚶‍♂️ Day 1 | 匆匆出行，却也有路上风景

说是Day1其实没那么严谨，上午去优衣库买了两件换洗的衣服，下午就赶慌赶忙前往火车站。人生中第一次独自离家如此之远，兴奋是难免的。然而，上了火车后才体会到极致的无聊，索性便听着播客，靠在桌板上一觉睡到到站。

旅途虽然奔波，多少留下了些光影的痕迹。我曾在很小的时候去过一次南京，留下的最深印象就是那里的地铁有地上段，果然，在窗外从深黑变为淡紫时，世界便在我眼前徐徐晕开。天幕似乎在流动，与如缕的云搅拌在一起，渐变成温暖的粉色。伴着逐渐褪成剪影的房屋和草木，明暗交织，颇令人心醉。

我特别喜欢蓝调时刻的南京，所有地方都透着娴静又唯美的气质。图二还颇有点动漫中电车窗外日落的感觉了，甚至可以想象窗外人们结束一天的忙碌谈笑漫步的场景，他们会去哪儿呢？也许是一家藏在深巷间的精酿酒馆，也许是公园里能看见萤火虫的长椅，也许就是自己安安稳稳，遮风避雨的家。烟火气漫卷开，涂抹了我对这座古老城市印象的底色。

安顿完行李，准备随便出门转转，没想到，一转就给转迷路了🤣，眼看着林立的高楼大厦逐渐变成陌生的小街小巷和各类狭小逼仄的门面，初来乍到的小年轻还是有点畏手畏脚，转着转着索性放开了，到哪儿不是逛吃逛吃，找了家看着顺眼的小店整了点甜品（你永远可以相信南京的甜品铺子！是真的多，又多又好！！），芒果酱是现做的，冰沙软乎乎，看起来像木鱼花，吃起来感觉很轻盈，还蛮好吃~ <Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

⛰️ Day 2 | 登高，会禅，看老蒋

李记清真馆为什么是神

带着前几天在B站上狂刷南京旅行指南的自信，次日清晨直奔李记清真馆，准备试试他家芳名远传的牛肉锅贴。我认为他家牛肉锅贴最神奇的是外皮，松脆酥软，却不易碎，入口仿佛肉松般细腻，带着甜味的肉汁涌入口中，回味悠长。

哦对了，记得避雷旁边的望吉利，他家的所有饮料真的都好难喝😡。

爬山，见佛，瞰南京

吃饱喝足，立马准备赶往牛首山！

当然，行程不出意外地出意外了。网约车司机在离景点还有一公里多的荒郊野岭把我直接放下车了，我居然也稀里糊涂答应了（可能觉得是不是走几步就能找到景区了，也没看定位，麻了，大家千万不要学我），于是体验了一把原生态山水后和农民婶婶打听到了最近的公路的方位，又叫了另一辆网约车才算到目的地（人生地不熟的，要用走估计得走好久......）

好在，总算还是到了。在门口买了杯星巴克，喝完就开始爬山。好家伙，给我爬了个半死，网上明明说有电梯，结果要抵达电梯先要爬个将近四千步，还都是爬升上坡，顶着六月份的大太阳，可谓折磨。嘛，安慰安慰自己，这是佛祖给孩子的考验，嗯，一定是。

山脚是一处小湖，有很多鱼，颇有种“皆若空游无所依”的飘逸感，山顶则是佛顶宫和佛顶塔，按照攻略，先走进了佛顶宫。混着檀香的空调冷风吹来，解散暑气，确乎颇有种飘飘欲仙的感觉。穹顶很震撼，是那种说不出门道，照片也展示不出来的震撼。佛祖巨像卧在莲台中央，缓缓旋转，推荐各位亲自去看一看（如果爬得了山的话）。下到地宫的千佛殿，拍几张佛造像，虽然说偶像崇拜不是佛学本意吧，但当成纯粹的文化艺术作品来欣赏，未尝不是一场视觉盛宴。

<Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

逛完了佛顶宫，也就顺带去佛顶塔拍了几张。佛顶塔也好难爬，泪目了，尤其是到了第六层还是七层之后只能爬阁楼，楼梯更加陡峭逼仄，实在是太难为人了，下行时，不得不猫着身子斜着脚走路，委委屈屈。好在登高望远，迎着山顶吹来的风，拍下了南京城的天际线，还是很壮丽的。

没能看到老蒋是我最大的遗憾

中午回酒店稍事休息（其实是懒癌发作躺床上玩手机玩到快三点）后前往总统府找老蒋（www），一进门就是一个近代史相关资料展，也算是大概了解了一下民国发生了什么大事www。给我留下的比较好印象的一点是这个展览没有一味聚焦在宏大叙事上，没有只介绍谁和谁打了，谁把谁暗杀了，谁即了谁的位，而是专门留了很大一块区域介绍民国的文化交融（如天主教嬷嬷给渔民传教）和生活风貌（如职工体操大会的老照片、健康宝宝评选、女子运动会等），感觉对民国的认识一下子立体起来了。虽然仍然是浮光掠影，但至少也摆脱了“才子佳人上海滩”或者“人民水深火热”、“黑暗统治”之类片面的刻板印象，看到了有生气有血肉的人的生活。总体上是一个很值得推荐的展，像我这种对民国历史几乎一窍不通的人也能有所收获。

顺着人流行进时，还发现一个侧院有太平天国主题的展，也顺带看了看。嚯呀，洪老师的龙椅看着好~~土豪般的俗气~~ 符合人设😅。

然而，最大的遗憾是子超楼由于装修而暂停开放，心心念念想看的老蒋办公室也没看成。

<Masonry breakpointCols={{ default: 2, 640: 1 }} class="flex gap-4 px-4"

最后放一张孙先生的名言结束总统府一章吧。

夜闯夫子庙，仗“证”走金陵

众所周知，当谈起夫子庙的时候，无论是不是南京人，一定会往死里骂。但没办法，想看秦淮夜景，大概率也只能去夫子庙。于是，抱着不在夫子庙买哪怕一块钱的小吃的坚定意志，“奄奄黄昏后，寂寂人定初”，我来到了这里. 然而，直到前往江南贡院前，我对这一片的印象都是：糟糕，十分糟糕。且不说各式光怪陆离的宰人店面和穿着形制混乱粗糙劣质的所谓杂糅汉服摆拍的游人，单是核心卖点“秦淮”，也被五颜六色的灯带蹂躏得媚俗不堪，完全无法带入“烟笼寒水月笼沙”的静谧诗意中，只看到因追逐客流量和成交量而粉碎着洒落一地的金陵幻梦。所以，即使为了看秦淮夜景，我的评价仍然是别去夫子庙，它会毁了你心中的江南。

当然，旁边的江南贡院（中国科举博物馆）还是要夸一夸的！

首先是因为它的全，几乎将清楚了科举制度的发源演进，科举的流程步骤，科举的试题内容及验身、答卷、审卷、改卷全流程的各种复杂防作弊措施。甚至还列了很多份真实的科举答卷（有一说一，排比句这种东西古人也很爱用，看来应试作文小技巧是古今通用的，但流俗也是真的流俗~）。

其次，高考生免票。好那不用多说了，我会成为忠实的自来水并把它夸上天的。

<Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

🏛️ Day 3 | 孝陵观景，中山怀人，门东圆梦

克里斯摸黑闯孝陵

由于明孝陵早晨六点半前免票的政策，五点就摸黑起来准备闯孝陵了！

网传“南京最美六百米”的神道其实就我而言并没有什么感觉，只觉得走了就是走了，可能雨天去会更漂亮吧。

走到尽头就是方城明楼，由于明孝陵至今未被掘，能看的也只有地上建筑，到此便可返程了。临走时去了一趟长生鹿苑，令人很难受的是，长生鹿苑八点半才正式营业，也就是说我得等个一小时左右才能去摸鹿，此刻正是蚊子疯狂肆虐的时节，我的腿上已经显出一些红色的抓痕了，于是一狠心和我的小鹿们挥手告别，赶紧遛掉。

<Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} sortByHeight={true} class="flex gap-4 px-4"

快看我拍的小白鹿！好可爱！！门口的水塘里还有鸭子（还是鹅🪿？）反正也很可爱就是了~

奋登山谒陵瞻国父

从明孝陵到钟山景区观光车站点，很是走了一段，中途看见了一个有趣的标牌：

在中山陵狠狠爬了好多级台阶😭，我跟同学说我能一分钟内爬上去，结果上是上去了，心率飙到160了。谒陵结束出来时我又贪玩想滑台阶旁的斜坡，结果因为正好下着小雨，脚底打滑摔倒在地，万幸屁股比后脑勺先着地，目前幸存😊.

当你不知道午饭吃什么的时候怎么办？那就无脑南京大牌档吧！至少不难吃~ <Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

下午实在不知道干嘛了，想去先锋书店又不想动，想去红山动物园又不想动，想去鸡鸣寺又不想动，于是就继续躺酒店里躺了一下午。（胡适之啊胡适之你怎能如此堕落！！！）

老门东？颜值巅峰！

快傍晚时，按照原定行程，来到老门东，看看南京除了秦淮风月之外的另一种夜景。

烟雨浸透的南京才是最美的南京。人群熙熙攘攘，却没有夫子庙那般摩肩接踵惹人厌烦。正是日落月升之时，天幕一片澄澈的靛蓝，如刚漂洗过，与徽派的青瓦白墙相映成趣。间或穿插着点点红灯笼，为潇潇洒洒的青蓝色调注入一抹明艳的撞色。青石板路沟壑间流淌着潺潺的雨水，薄雾模糊了霓虹灯闪烁的光。颇有些“金吾不禁夜，玉漏莫相催”的气派。

<Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

至于吃嘛，老门东基本上也就是和夫子庙坐一桌的，但门东水铺还不错哦，值得打卡。

我早就说过，你永远可以相信南京的甜品铺子吧，嘿嘿

---Cris.Q

Day 4 | 晃晃悠悠南博，心心念念南大

终于，到了20号，可以去我此行的真正目的地——南京博物院了。

我跟你们讲，南博的票真的很难约的！（虽然我一下就约上了，但是看网上似乎不好约欸~）

当然，还有集印章环节，真的得做足功课（小红书上有很多攻略，但我不用小红书hhh所以只能硬着头皮瞎转悠）。

<Masonry breakpointCols={{ default: 2, 640: 1 }} class="flex gap-4 px-4" sortByHeight={true}

在深陷民国馆泥潭前，好好欣赏了一遍艺术馆，老师们的作品真的都好棒。

<Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

而把宝贵的一个半小时浪费在民国馆后，只能特种兵行程了，匆匆看完了历史馆和特展馆，拍了一些很有意思的文物。（唐宋真的是一座艺术高峰，太多文物都漂亮而有个性了，相比起来明清感觉太四平八稳了一些，没唐朝那么“飘”）

<Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

明知分差悬殊，仍是梦中情校

前文也提到过了，由于我朋友在南大上学，我对南大还是很心生向往的。于是，通过一些比较特殊的手段，我走进了南大的校门。

鼓楼校区并不大，但是建筑错综复杂，很容易迷路，再加上当时离我赶车前去杭州只有不到两个小时，我便只能一边慌张一遍匆匆浏览南大的风貌。

<Masonry breakpointCols={{ default: 3, 1024: 2, 640: 1 }} class="flex gap-4 px-4"

虽然已经尽力赶时间了，但是千算万算，忘记了南京那时正值晚高峰，堵车啊朋友们！！！！

于是，改签失败，被迫选了绕远路的换乘方案，好在最后还是平安抵达了杭州西。

总结我这几天的南京之行，确实过于走马观花了。行程安排也不合理。即使如此，我仍然感到充实和满足，学到了很多象牙塔里无法接触的处事法则。

不过，如果有机会，我还会再回来，作为一个精神南京人，我还会选择一个风和日丽的日子，再次扑进这座六朝古都宽容、坚实而温柔的怀抱。

至于杭州嘛，这篇游记实在给我写得累死了，等有时间再写杭州篇吧。

感谢看到这里哦👋

我的2024

Sun, 26 Jan 2025 00:00:00 GMT

有点难以置信的是，整个2024，我几乎没有发布一篇博文......说实话有点难过，有点悲哀，但这也是没办法的嘛，毕竟高三了。今年其实没什么好说的，大部分时间在无穷无尽的作业，满溢出来的压抑氛围和一杯一杯灌下去的咖啡中度过，剩下的少量时间用来忙点自己的兴趣。前者在博客里发再多牢骚都是扯淡，还是写写后者吧。

买了一块智能表！

首先，今年令我最高兴的事情大概就是我有了一块智能表：

这块手表是OPPO Watch 4 Pro，我大概在11月购入，给了我剩下两个月极大的幸福感（因为我终于可以又网易云音乐和Spotify听歌听播客了！泪目。

在没有这块表前，我用一个老旧的mp3播放器听歌，由于我住校，每周回家都得先下好自己收藏的播客，然后带到学校去听。然而大部分播客又恰好不是周末更新，每次只能听旧的，可实在是太难受了......举一个最直观的例子，有了这块表后，我终于可以准点听到每周三晚上更新的《半拿铁》了，两位主播的声音想起来那一刻感觉疲惫感都一扫而空了。Spotify的免费版14天会掉登录，在手机上还好说（进行一些科学处理），手表上可着实有点难受了，于是每两周不得不抽出一天来回家重新登录Spotify（这方面内容先按下不表），不过激活之后Spotify的体验堪称优秀，我喜欢的播客和音乐直接受藏到音乐库就可以随时收听了。Spotify Wear最近的一次更新还加入了搜索功能，这下好了，抛掉手机吧少年（笑）。

另一个老大难的问题——记住每天作业有什么，有了手表上滴答清单的帮助，变成了每天下晚自习后对着手表想念咒一样自言自语”xxx写到xxx，xxx写完第xxx面“（其实是语音输入），彻底解放大脑嘿嘿~

OPPO Watch还有欧路词典App，可以方便的查词，在英语课上别人都在查字典时瞬间把问题抢答的感觉，啧啧从来没有如此强大过~ 然而，必须强调的一点是，我是设置了校园模式的，每天7:30到5:15都不能使用第三方App（白名单内除外，我的白名单只有滴答清单和欧路词典）。所以不要说我是坏孩子哦，我可是乖乖的~

18岁了 🍰！

成年啦！！！好感慨。

成年前的最后一个周末回家时，父母给了我个”惊喜“——提前给我准备了”生日宴会“，然而我当天正好甲流，全都泡汤了~

不过生日当天倒是在学校好好high了一把。中午的时候跑到校门口的蛋糕店买了整整十个蛋糕（ -200 ￥），提着到我膝盖那么大的袋子，走得那叫一个志得意满。收到了班主任的祝福（还请我吃了肯德基），给我开心坏了哈哈。朋友们也送了不少礼物，甚至有个哥们把自己斥巨资积攒的原神周边打包了一大盒送我（本人称之为“年轻时犯下的错误”），这下我这个不玩原神的反而被迫成了班上原神浓度最高的了🤣。另一个朋友同样斥巨资请我喝了杯星巴克，那叫一个感动，嘴角抑制不住地流下了泪水。

18之后好多事可以干了，我记得我准点等到生日当天的00:00，打开我的表测了一次心电图（该功能仅年满十八周岁用户可用），看着窦性心律那个一跳一跳的图，心里还挺美。

我将建立健！康！的生活习惯（也许

12月初我立下雄心壮志要更改以前混乱不堪的作息习惯，从“12:30~6:30”改为“11：30~5:30”

成功了吗？？没有。晚上始终睡不着，闭着眼睛感觉有困意，但不多。翻来覆去总感觉膈应，眼皮子闭上了又觉得想要睁开，那叫一个难受。躺到最后都躺出完美主义了，非要找到一个两手两脚都不觉得膈应的姿势才能罢休，一折腾下来又12:30了。早上即使早起也...不如不起，纯粹糟践自己。

再一个就是早饭，本来我是不吃早饭的，但是又觉得还是随便吃点什么有助于不犯困，于是就买了点方便粥，结果第二天便利店就不卖方便粥了，抗拒之下只好拿起方便面（我讨厌方便面纯粹是因为它的调味吃起来泛酸而且不容易消退，搞得人很难受），果然还是不能接受呢~

到底要不要“调整作息”，不知道，再看吧。

OneThing好文明

高三居然有元旦晚会，这是咱没想到的——既然要办，没办法，技术支持是肯定跑不了咱的。

同学们发来歌曲要“降人声”，出于算力考虑，没有胆敢上自己这台只有集成显卡的小笔记本，去OneThingAI家租了台4090的服务器捣鼓了三小时多（ -7.64 ￥），用的是MSST WebUI。提取人声后便是漫长的处理（这部分自然是操持上咱最爱的Reaper），不过这次倒是尝试了用LSP Studio出的Plugin Suite来做混音，效果极佳，太爱开源插件了！

后来又来了各种奇奇怪怪的要求，什么把三首歌混一起，这首的副歌结束时直接无缝接下一首歌的副歌之类（......也都给实现了！

当然，事后请几顿饭几杯星巴克是少不了的~

import Audio from '../../../components/Audio.astro'

碰了Flutter和Jetpack，放弃了

有了表自然想着开发点手表上的应用。不得不吐槽OPPO官方的开发文档几乎就跟没有一样。一开始技术选型是Kotlin + Jetpack Compose，粗略地写了写后发现Compose这设计是真的优雅，直到我放了个LazyColumn上去，才发现这种设计方法带来的重组让LazyColumn默认状态下在手表上“一滑就卡”。上网搜了不少解决方案都没法解决，遂弃之。当然，并没有说Compose不好，只是我实在没有时间研究怎么让它跑在非WearOS设备上（我相信Wear Compose肯定已经优化得很好了，奈何用不了~）。

所以，目光投向了Flutter + Rust这个我关注已久的方案上。不得不承认，Rinf是一个救人于水火的库，好用，推荐！唯一令人诟病的是Flutter这糟糕的语法，和Compose比起来确实太古朴了，颇有一种“声明式，但是不优雅”之感。由于时间不太够，也就没深究下去。2025等高考完可能会再捡起来玩玩。

今年最讨厌的词

就是挂在班主任嘴边的“按部就班”

我甚至写了个段子，把班主任常说的词总结成了一句话，文段如下：

这篇很规范很典型的文章告诉我们一定要按部就班的颗粒归仓。

如果有碰巧和我同班的朋友看到这句话估计就...嘛，会心一笑了~

好了，就写这么多吧。枯燥的一年也没什么可总结的，希望明年会更好。

祝大家新春快乐呀~

琴师

Sun, 25 Aug 2024 00:00:00 GMT

一

初唐是个繁荣而动荡的矛盾时代，更别提最近还传着武后称帝的流言。

但龚羽没有感知到外界的纷扰，他只是每日坐在桌前画着图，在后院的桐木林中挑挑拣拣，间或做些刨锯活计谋生。在远离都城的小山上，苍翠掩映中，落着几幢古朴的宅子。那是龚家时代驻守的祖宅。

陇西龚氏，世代琴师出身，秦汉时期也曾显赫一时。凡其所制之琴，纹如润玉，弦比月辉，浑然天成。达官显贵为了求得龚氏瑶琴一把，无不竞相争抢，相传还闹出过人命官司，一度从郡守告到廷尉，惹得大人攥着卷宗左右为难。至于那晚照下拔起的未央宫中，花梨木架端御琴上醒目的龚字刻印，也无疑堪比一张不容质疑的金字招牌。家道中落后，父辈世代惦记着重振家业，做过许多尝试。然而，好琴须得良木，浑腔方出金鸣。苦于没有上好的桐木，数代人奔走四方，辛苦搜寻，从剑南和黔中带回了许多树种，回到陇西栽下，日夜呵护，仅留其品色俱佳者。如今他的祖宅后院中，就葱郁着他的不知多少代先祖汗水浇灌的成果。

陇西临近西域，自太宗朝始，往来的胡商把大量形制新颖的乐器带入中原。龚羽经常和这帮人打交道，因得以聆听品玩这些还未在唐朝流传开的异域之声。他知道，龚家数十代人坚守的梦想不能只通过一遍遍重复前人走过的老路实现，从他的父辈开始，两代人靠着人脉，寻了许多胡琴和琵琶，将其巧思融入古琴的设计中。稿纸像雪片般堆满半间房，龚羽知道，不需要再画了。他把成稿与父亲的棺椁葬在一处，孤身守着老宅。桐木饱汲风露，但少一天就是少一天，龚家等了四百年了，这事容不得性急。他想象着成琴在手里摩梭时的触感。他知道不能固守在陇西，他的目光看向太极宫所在的方向。

那座城在汉朝叫长安，随后的王权更替中改了不少次名，如今又叫回了长安。一如龚家忍辱负重的蛰伏，也该再度扬名了。

龚羽，由宫及羽，五音俱全；桐木，自汉至唐，经年始成。

二

初阳匆匆穿过泛黄的琴谱，又顺着干硬的床板爬上后窗，掠过交错的树叶与层叠的枝条，将一缕缕辉光送至古铜色的树干上，为其鎏上一层内敛的暗金。龚羽比对一遍纪年簿上所载，第四百个春秋已然度过，他准备着手砍它了。

三更即起，昏昏灯下，颤颤笔端，早已烂熟于心的的琴稿转眼浮现，又附每个部件的精密结构与共鸣腔体的形态草案，甚至随绘了纹样与装饰的示例，一鸟一凤，一草一木皆循章法。他把琴体画得很大，上刻一个张扬的龚字，四周云纹绕带，双凰振羽，字形若龙行虎步，筋骨毕现。虽在纸上，但纸又怎承得下？他需得把这琴从笔墨中解救出来。于是斫、磨、涤、烤、染、拭，精益而求精；挑、抹、拨、合、点、闷，凡音必中律。春去秋来，龚羽本就银灰夹杂的头发已然全白，那五六捆桐木版也从与门奇高降至堪堪及腰，奇形怪状的半成品反而越堆越高。看着被自己挥霍的，旁逸而斜出的条条框框，他双手背后，笑得像一个天真的艺术家。又伏下身继续做琴，斧凿纷飞间，他下意识抬手擦汗，只触到自己干硬的布满皱纹的额头，大概是汗水已被吹散了。

铮然一声轻响，风月齐动，山林呼应，金铁交鸣。琴成。

向县里申请下过所文书后，他带上全部的家当，择好日子前去长安。临行前，他又去了一趟后院。被伐倒的树冠上年轮已看不分明，只剩短短一截桩，其侧刻着长短不一的十六条线。他摸着那些刻线，浅浅笑着，然后摇了摇头，从斑驳的回忆中抽身出来，像握笔一样握着刻刀，同他的十六代祖辈一般，斜斜刻下。

十七条线。

三

数月的脚程，他终于站到了紧闭的长安城门下。

好不容易等到开远门前凝滞着的长队开始挪动，后面的胡商不耐烦地搡他一下：“磨磨蹭蹭，怕不是越度的！”。一阵浓烈而刺鼻的汗味惹他惊得不知所措，亦使他感到颇有些恍惚。他下意识把背着的琴换到胸前护住。琴还完好，他松了一口气。

京城自是与他世代隐居的小村别若云泥，林立的各坊险些使他迷路——绕居德、群贤，穿西市，走怀远、丰乐。朱雀大街突然扑进他逼仄的视野。此刻街上正人流如织，一片鼎沸的嚣嚣，他眺望远方，却连正对面的荐福寺都看不见。他不由地怯了。自幼不是与青灯做伴，就是枕琴谱而眠的他，所能耐的极闹便是夏虫的鼓噪，又怎见过这般烈火烹油的盛景。

整齐的鼓声开始响起，盖住了一切杂音——午时已到，市鼓三百下，贵公子们也该出门了。他需得加紧赶往东市——沿路走，沿路打听，他早就知道东市是上层人物出入的豪富场所。至于自己，休说绫罗锦缎，就连穿上一套体面的圆领袍靴都是奢望。注视着贴在自己身上的灰白麻布短打，他把琴抱得更紧了。

安仁、长兴两坊，他几乎是全速跑过去的。待他在东市前停住脚步，市门早已大开，扑面而来的便是商贩叫卖的声浪。他犹豫地后退一步，但琴却没有后退，于是他便又很快迈了回去。低着头，从商铺和摊贩的缝隙中小心翼翼地经过，找到一片还算空旷的地界。微微颔首，他把包着琴的裹布解开。

那只粗砺的手攀上弦，他拍了拍他的友人，像在为他饯行。而后，他将手虚虚勾起，搭在弦上。

铮！

时光突然湍急了起来，人们都不约而同回过头，被这未尝听过的音色震住。说是瑶琴之音，却能奏得干净利落，一拨一按间当断即断，清脆若黄鹂啼露；说是胡琴之音，却又音色雅正，婉转流泻，轻轻一扫便余音不绝。人们激动起来，狂热地拥向他，叫嚷着不同的话语，他几乎要耳鸣。

他费力推开人群，与另一只拨开人群的手相遇。那是一位穿着青衣的带玉公子。

龚羽有些不知所措，想要开口询问是否有意购琴，却又觉得不能失礼，只能嗫嚅着整理他那身毫无必要整理的短褂：“这位公子，可有购琴之意？”。

那人直勾勾盯着琴，眼神中闪烁着难以压抑的兴奋。他的手紧紧攥着袖子，在沉默中思考着什么。不久后，他似突然想到了什么，松开了紧攥的手，转过身对着簇拥的人群，朗声说道：“某陈子昂，蜀中人士，善音律，久苦无良桐以奏，成美琴之名，今幸得逢佳琴于斯，莫非天意？诸君，何不明日偕往宣阳里，子昂愿与诸位共赏妙音，听琴品茗岂不快哉？”

温和大方的笑容出现在他脸上，如果龚羽没有察觉到他抿紧的嘴唇。

“琴师，休说此琴何值，子昂愿倾某所有，但求成全。”

他似乎在对他说话，但却没有看着他。周围喧起震天的喝彩声，但却也没有人看着他。

他的头被震得发昏，只站在远处，痴痴地笑着。

四

宣阳坊就在东市旁边，几步路便可赶去。

隆隆的鼓声再次伴着山间的半朵夕阳响起，他户籍不在长安，坊正自然不会放他进坊，在长安又无亲眷朋友，只能奔着寺院去了。他想起朱雀大街旁的荐福寺，心下决定到寺中投宿一晚。街鼓八百下，足够他慢慢走过去。

各坊的门在他身后重重关上，行人以肉眼可见的速度迅速减少。天色黑得很快，暗青的夜空逐渐在一片橙红中晕开，金色的晚霞漂浮在云间，打着旋向天边的远山绵延，一点点暗淡下去。

禅房内的灯火算不上明亮。他注视着跳动的火苗，一言不发。

夜半的风涛中，他曾想起自己的父亲，父亲的父亲。他想起自己幼时在桐木下与父亲玩笑，抚摸着树冠上的刻痕，嫌弃它们刻得太乱，父亲的面容却突然严肃起来，毫不犹豫对他一顿训斥。那是他第一次意识到这些老树在父亲眼里的地位。他又想起父亲弹琴时无意中跟他讲到过的伯牙绝弦的故事。

“岂不愚乎？市之即好呀，何必摔呢？”

“倘少一子期，又何有伯牙之名乎？没了子期的伯牙，没了子期的琴，卑如尘土而已。 ”

但求成全啊......

那一袭青衣又浮现在他眼前，他的嘴角情不自禁挂起了笑。他似乎看到老屋后一圈圈的年轮流淌下来，流过山川河流，流进钟鼎府上、朱门堂中。龚氏的名声享誉四方，龚家的子弟再一次穿上绫罗绸缎，环翠佩锦，出入在庙堂之高。夜风打着寺院内的芭蕉，他似乎听到琴声从四面八方涌来，铮然齐响......

和衣而卧，一夜未眠。

五

第一声报晓鼓还是如期响起来了。

南北向的每条大街上，鼓楼迅速响应起来，鼓声由内而外依次传开。城内的一百几十所寺庙逐个撞响晨钟，交相辉映。这座沉睡的古都在绵长的钟声里迎来了第一缕阳光。寺门，坊门，市门齐齐打开。定格的长安城里，时间再次流动了起来。

龚羽揉了揉红肿的眼，他睡不着，他太盼望着亲眼见证自己的琴被弹响了。

从荐福寺所在的开化坊走到陈子昂所在的宣阳坊，也就一两柱香的功夫，但他却唯恐误时，寺门未开便守在门口，还遭了守夜的沙弥几句呵斥。

待他气喘吁吁来到宣阳坊时，酒席已经摆开了，各色人等穿梭于杯盏之间，觥筹交错，谈笑风生。陈子昂穿着水色的圆领袍，衣裾在风中摆动，他昂着头，站在正中央的圆台上，自信而捎带狂狷地笑着。龚羽被他感染，也不由地挂起了浅浅的笑。很快各式华贵的轿子款款而来，“武攸宜！”人群之中掀起不小的骚动。宫羽从没听过那个名字。

“诸君！今日云集宣阳里，是子昂之幸。特设好酒菜相宴，诸位莫言且尽杯盏！”言之激动处，他将酒狠狠泼在了地上，仰天而笑。

琴被抬上来了。龚羽屏住了呼吸。

“某，陈子昂，字伯玉。梓州射洪人士......”陈子昂的声音忽然变得严肃起来。不知为何，龚羽觉得气氛有些不对了起来。

“某有文百轴，以为才情卓然，针砭时弊。”他举起一卷写满小字的卷轴，展示给前排的众人看，又回身捧出数卷文稿，分发给前排的人们，陈子昂的手不住颤抖着，紧紧抿起了嘴。“琴呢？妙音又在何处？”后排有好事者嚷起来，旋即被同伴推搡着制止。然而，陈子昂转过了头。他胜券在握的表情突然绷紧了起来。

“琴？某驰走京毂，如碌碌尘土，竟无人知我！何也？若无此琴，子昂之心，恐历一世而终不得成全啊！”陈子昂的语气竟带上些许愤怒的尖音，面色激动得发红，令围观者颇有些悚然起来，龚羽想到了自家曾经显赫的名声，觉得心酸起来。但他还是耐心听了下去。“文章经世，声名通达，此子昂毕生之理想！大道如青天，余何独不能出？盛世此朗朗，余何独寂尘土！”琴上覆盖的绢布忽然被掀了起来。

烈日照在了陈子昂的面庞上，他的眼睛隐没在阴影中。

喧哗逐渐平息了下来，人们屏住呼吸。路过的风也跟着屏住呼吸，按住了柳条的摆动，枝头的夏虫也察觉到了气氛的凝重，当即也屏了息，四下陷入了一片寂静。人们都等待着陈子昂接下来的话。龚羽想走上前去，他已经觉察到事情的不妙，但人群拥成一团，似乎每个人都在阻挠着他。他张开嘴，想喊些什么，却只听到自己沉重的喘息声。

陈子昂举起了琴，轻轻抚了抚它光洁的琴身，又把手搭上了弦，作出试音的动作。他的眼睛自始至终没有看向琴师。也许他根本没察觉到他的到来。他突然开口了。

“琴，难道比文章，更能济世救民吗？”

“此乐，不过贱工之役，岂宜留心？ ”

他举起琴，直勾勾盯着它，却毫不犹豫。他手臂上肌肉鼓起，青筋暴现。

他把琴重重砸在了地上。

轰的一声，所有弦被同时砸响，龚羽听到琴声嘶力竭的哀鸣。

流泻而下的云纹被从中间劈断，裂痕似一道劫雷，斩下琴上凤凰的头颅，撕开龙虎的爪牙，继续蔓延，直至贯穿琴上的龚字刻印。烟尘飞扬起来，旋在四分五裂的琴周围，只呜呜的啸着。

他眼前倏地一黑，坊间林立的楼宇缓慢倒塌，而那圈从老树上流淌下的年轮也在他脚下骤然绷断。他失去了立足点，双腿发软跌坐在地上。他的眼睛睁得滚圆，把眼角扯得生疼。但他没有办法流泪。

他的耳边，回荡起了那句但求成全。

补

本文成于 2024 年 5~6 月左右，当时是在阅读题上看见马伯庸《长安的荔枝》选段，突然来的灵感。遍在一节晚自习草草挥笔。感谢我的语文老师刘老师愿意耐着性子看完，真诚分享感受，也感谢我的另一位恩师姚老师一针见血的指点，每每直指要害，条分缕析，让我拍案叫绝。

成文后本来是准备见诸报端的，想投《青年文摘》又怯懦犹疑，最终在对被拒稿的恐惧中按下了取消键；后又辗转投了诸如《沙地》之类的几家纯文学杂志，也渺无音信。大抵是学艺不精，或是缘法未到吧。索性也就整理整理，直接发在博客上，供读者一笑，也不失为一桩美事。

25 年 6 月，高考失利，整理博客时删掉了除年终总结之外的所有文章，本文也于那次大清洗中罹难，同年八月意欲前往苏州游展，忽然想起这篇拙作，也就再次动笔，稍事打磨，尽量尊重原文，瑕疵之处若无伤大雅，也一并也予以保留。才疏学浅，不敢称什么作品，也就是权当留个纪念，当作我青葱岁月的一段刻印，便知足也。

也许我们还缺一个年终总结

Sun, 21 Jan 2024 00:00:00 GMT

转眼间又是一年匆匆过去，今天是一月 21 日，元旦已经远去。也许如果不逼着自己写点什么，我的 2023 就会如一阵烟雾消散在我的回忆里吧。于是，2022 的年终总结似乎还余温犹存，2023 的年终总结就已经不得不动笔了。

今年的时间主要还是在学校里度过。四月份的时候帮着我们班开展了一次“广受好评”的班会，甚至在全校多次“公演”。还记得我为此几乎熬了一周的通宵，每天都怀着忐忑而兴奋的心情期待着第二天的排练和新的 mindstorm。虽然很累，但却因为是自己喜欢的事情而倍感充实。

说起来，在学校的日子里倒是经常往语文办公室跑，却不是为了学习，而是去帮忙剪视频——班主任的教学比赛视频，同学的校园安全宣传视频，艺术节的班级节目混音小 set......来来回回反而成了办公室的常客，跟许多老师都混熟了。时不时还能找班主任要点小零食走（2333....

今年的写作兴致也还算高，在作文本上留下了不少有意思的随笔，晚自习还偷偷摸鱼写了篇文言小品。

我曾经在 About 页面里说过，我是一个开发者，也是一个音乐制作人，我想今年的我更多偏向后一重身份。今年的 Gitlab 活跃度几乎没有，一方面是因为学业突然变得紧张，一方面在于认识了不少音乐人朋友，和他们的交流与合作让我的重心逐渐偏向了这块。

大概是今年四五月份吧，我认识了 AritxOnly 同学（现在是一位南京大学的学生），他当时是一名高三学生，也是一位 Bass Music 爱好者。他带我探索了 Sound Design 的广阔世界，教会了我很多，也与我合作了几首作品。感谢他的陪伴，让我受益良多。虽然我仍不能算作一个成熟的制作人，水平也十分拙劣，但至少我感觉到自己的思绪有了一个倾诉的途径，有了一个表达的窗口。

本来我们有一首合作单曲，准备在元旦那天准时发行，但是因为一些原因，可能会在一月下旬发布，年终总结里没写完的话，就交给音乐去诉说吧。

在Linux上做任务管理，这件事得好好掰扯

Fri, 14 Jul 2023 00:00:00 GMT

记得是两三年前吧，我曾经在酷安写过一篇文章，介绍我如何在Linux和Android间同步我的待办事项。

那篇文章写得很烂，同步的方法一样很烂，一切都得借助Todoist这个第三方服务，难免会受服务器环境和第三方应用稳定性的牵制。然而，在手握一台VPS的现在，我找到了一个更有趣的方案―― Vikunja 。

于是，我想从头梳理梳理这几年我是如何在Linux任务管理这个需求上挣扎跳跃，最后踏上Vikunja的贼船的。

简陋朴素 ―― Todo.txt

放一段Todo.txt官方仓库的介绍吧：

A complete primer on the whys and hows of todo.txt.

The first and most important rule of todo.txt:

A single line in your todo.txt text file represents a single task.

简而言之，Todo.txt是一个以纯文本的方式运作的待办规则，这样的好处是你几乎可以在任何平台找到支持Todo.txt的客户端，坏处是由于这种看起来比较简陋的处理模式，这些客户端往往都不尽如人意......

比如，如果我们打开万能的应用商店Github搜索一下支持Todo.txt的Android应用：

嚯，这一个比一个看着不靠谱。不过正如在酷安那篇文章里写过的，我体验过一段时间TooDoot，然而，对于那款应用，我的感想是————还是去用Todoist吧。

老老实实 ―― Todoist

在国内互联网上，Todoist的讨论度还是比较高的。想当年它曾经也是被国内一众"生产力工具狂热爱好者"奉为至宝的产品～

唯一有一点别扭是什么呢——它在我编写酷安上那篇文章的时候还没有发布Linux版本（即使现在发布了，也是基于Electron技术的产物，毕竟自己曾经也是个 "Native Apps" 的狂热追求者），不过好在，开源社区给出了一个足够有吸引力的解决方案—— Planify 。

同样地，放一段官方仓库里的介绍：

Planify is here...

Neat visual style.

Drag and Order: Sort your tasks wherever you want.

Progress indicator for each project.

Be more productive and organize your tasks by 'Sections'.

Visualize your events and plan your day better.

Reminder system, you can create one or more reminders, you decide.

Better integration with the dark theme.

然而，前面已经提到过我的选择，最终是Todoist服务器访问速度的缓慢和对它的移动端UI风格的别扭感让我放弃了它。

顺带一提 ―― Microsoft Todo

自从我用Linux之后，就没怎么用过Microsoft Todo了，因为Linux上根本没有能用的客户端（那些单纯套网页的大可不必算作客户端），然而，最近我在Github上发现了一款支持MS Todo同步的GTK应用—— Reminders ，没怎么用过，就不多介绍了。

勉强能用 ―― CalDAV + Tasks

从我初三到高一，一直用的都是这个方案，足够看出来，对于"凑合用"这一指标，CalDAV是合格甚至优秀的。

我一开始使用的是Yandex家的CalDAV服务器，效果出奇得不错，在移动端可以使用Tasks进行同步，Tasks的功能强大，界面现代（然而并不支持Material You），开源自由，堪称是Android下绝对理想的Todo管理软件，那么现在压力给到了桌面端——

桌面端什么都没有。

不论是KDE或者Gnome家自带的日历应用（K系甚至没有自带日历，我选择了Kalendar），还是第三方的所谓日历管理应用，对CalDAV的支持都堪称灾难，唯一令我觉得比较顺手的操作方式，反而是在Yandex Calendar的网页端添加Todo。然而，Yandex Calendar毕竟不是专门的Todo list应用，Todo管理页面被深深埋在二级页面，操作起来也颇觉不顺，而且，毕竟是外国服务器，访问速度还是有些令人难受的。

诶嘿，恰逢我买了一台VPS，于是自己搭建了一个CalDAV Server。这下访问速度上来了，但是却没有Web UI可以创建和编辑Todos了。

望着空空荡荡的任务列表，我沉思着：难道速度和WebUI真的不可兼得？

死心塌地 ―― Vikunja

初夏的雨后，我独自站在街角的十字路口。夜晚的寂静包围着我，仿佛一层无形的孤独笼罩在身上。寂寥的感觉如潮水般涌上心头，我感到自己孤独的存在像是一个被遗忘的角落。

突然，我的目光被一个昏黄的路灯牢牢吸引住。灯火温柔地闪烁，将周围的光影扑朔迷离地渲染成诗意的画面。那盏路灯在黑夜中独自发光，仿佛是寄托着所有寂静雨夜的心声。

我就这样静静地站在那里，与路灯一同呼吸着雨夜的寂静。在这个瞬间，我的孤独和寂寞在那盏默默发光的路灯的怀抱中找到了安慰。我感受到了一种被包容和理解的温暖，仿佛寂静和洁净在这一刻相互拥抱。雨夜带来的孤独，不再是伤痛，而是一种与自己对话的契机。

——Generated By ChatGPT

试赏析以上文字在一篇技术分享类博客中起到的作用（6分）

据说，当我第一眼看见Vikunja时，我就知道，我的服务器又要被吃掉一块内存了。

极简的界面，强大的功能（这甚至是一个多人协作的Todo Manager），内置的CalDAV Server（不需要自己搭CalDAV服务器啦！）。谁见了能不爱呢？

安装

我选择使用Docker-compose安装Vikunja，它的文档详细得令人垂泪——怎么能够这么友好？

如果你对此感到怀疑，不妨亲自看看这份覆盖市面上几乎所有主流Reverse Proxy的Docker-compose示例配置列表。

我走的是Traefik v2,所以找到对应的Example,稍作修改，服务便跑起来了。

值得注意的是，不用于我们熟悉的某些服务，会要求你在首次访问时设置管理员账户和密码，或是在log中输出初始密码，Vikunja是没有管理员账户的，部署之后你需要做的，就是访问，创建新账户，然后愉快（并感激）地享受它为你提供的一切便利。

多端同步

再来讲讲Vikunja的多端同步吧，移动端的应用我选择的还是在CalDAV那一节已经提到过的Tasks。

在Vikunja网页端右上角点选用户头像，在弹出的菜单里选择"设置"，进入后选择"CalDAV"，然后选择"创建令牌"，将CalDAV地址，账户和令牌填入Tasks,就可以愉快地将你的Todos同步到移动端了。在目前测试中，创建列表、修改/删除Todo、标记完成等等都是完全没问题的。

所以，我到底该用什么好呢？

我们让ChatGPT来回答这个问题吧。

根据用户在文章中的描述，可以给出以下用户适合使用各个应用的建议：

Todo.txt：适用于追求简单、轻量级且跨平台的用户。适合在不同设备间同步待办事项，不过需要注意，客户端的可用性和功能可能会受限。

Todoist：适用于那些希望在多个平台上都能使用一款稳定、成熟的任务管理应用的用户。Todoist 提供了跨平台的支持，并且有广泛的用户群体和开发支持。

Microsoft Todo：适用于 Windows 和 Microsoft 生态系统用户。但是需要注意，Linux 平台上的客户端支持有限，可能无法满足在 Linux 上使用任务管理的需求。

CalDAV + Tasks：适用于追求自主搭建服务器、有技术能力并且愿意妥协一些 UX 的用户。这种方案可以在多个平台上同步任务，但需要一定的技术设置和对服务器的管理。

Vikunja：适用于寻求全方位任务管理解决方案的用户，尤其是那些追求跨平台同步、拥有多人协作功能、并且希望有现代界面和简便部署的用户。

总之，不同的用户可以根据自己的需求和优先级来选择适合自己的任务管理应用。建议用户在选择之前试用一下，并考虑到自己的平台偏好、同步需求、用户界面喜好以及对技术设置的兴趣程度等因素。

这似乎是国内第一篇 Conduit 部署教程

Sun, 12 Mar 2023 00:00:00 GMT

注：烦死了，似乎是第三篇或者第四篇，反正不是第一篇······

在很久～很久～以前，有一个开放的 IM 协议，他的名字叫做 Matrix。

相传，他披着黑色的中括号，腰杆儿挺得笔直，但是，从来没有人见过他真实的样子，因为他只使用化身为人们带来福音——那最著名的化身是 Synapse，生活在 Python 镇，但他厚重的铠甲常常令前来学艺或拜访的服务器望而生畏；比较灵巧些的化身是 Dendrite，他是 Go 城邦的贵公子，虽然装备不如老大 Synapse 那么齐全，但一样功夫了得，尤其是迅捷的身法，传闻只需要几百 Mb 的内存便可大展拳脚。他们二位长期为人们所称道，可谓家喻户晓哇！

然而，客官，咱们说的是另一位隐世的公子。Rust 派的嫡传弟子，Conduit。

简介

在 Synapse、Dendrite、Ruma 等等一大堆 Homeserver 中最后还是选择了 Conduit 尝鲜，一是因为它比较轻量级，不至于让我的服务器叫苦连天；二是因为它很新，我喜欢新东西（即使它们功能不一定齐全）；三嘛，因为它的开发者和社区热情且平等，没有架子，开发非常活跃。

另外，熟悉我的朋友都知道，我是个 Rust 爱好者，用 Rust 开发的 Conduit 本身就是个有吸引力的选择。而它的官网宣传语也让人十分动心：Conduit is a simple, fast and reliable chat server powered by Matrix.

那还说什么呢，快让我也 Powered By Matrix 吧。

安装&部署

由于我是使用 Traefik 做反向代理的，所以下面的安装适用于 Traefik 用户。

先是 Docker-compose 一把梭：

version: '3'

services:
    homeserver:
        image: matrixconduit/matrix-conduit:latest
        restart: unless-stopped
        volumes:
            - db:/var/lib/matrix-conduit/
        networks:
            - traefik
        environment:
            CONDUIT_SERVER_NAME: chat.crisq.top # 你实例将要绑定到的域名
            CONDUIT_DATABASE_PATH: /var/lib/matrix-conduit/
            CONDUIT_DATABASE_BACKEND: rocksdb # 类似 Sqlite 的轻量 K-V 数据库
            CONDUIT_PORT: 6167 #嘛～默认就好了
            CONDUIT_MAX_REQUEST_SIZE: 20_000_000
            CONDUIT_ALLOW_REGISTRATION: 'false' # 第一次运行的时候设置为 true，如果是自用，创建完自己的账户就可以设置成 false 了。请尽快创建账户，以防被他人捷足先登：Conduit 默认第一个被创建的用户为管理员。
            CONDUIT_ALLOW_FEDERATION: 'true'
            CONDUIT_TRUSTED_SERVERS: '["matrix.org"]'
            #CONDUIT_MAX_CONCURRENT_REQUESTS: 100
            CONDUIT_ADDRESS: 0.0.0.0 # 确保能被 traefik 发现。

    well-known: # 我们简单的部署一个 nginx，为其他服务器提供 well_known 文件，你问我为啥还要配置第二个反向代理？我也烦啊淦······
        networks:
            - traefik # 我的 traefik 和 docker 容器们都跑在这个网络中
        image: nginx:latest
        restart: unless-stopped
        volumes:
            - ./nginx/matrix.conf:/etc/nginx/conf.d/matrix.conf

volumes:
    db:

networks:
    traefik:
        external: true

可是，看起来并没有什么和 Traefik 相关的配置项，因为我们使用了另外一个文件：docker-compose.override.yml

version: '3'

services:
    homeserver:
        labels:
            - "traefik.enable=true"
            - "traefik.docker.network=traefik"

            - "traefik.http.routers.to-conduit.rule=Host(`your.domain`) && PathPrefix(`/_matrix`)" # 我们将让 Conduit 处理所有指向"_matrix"的流量，而剩余部分则交给 nginx。
            - "traefik.http.routers.to-conduit.tls=true"
            - "traefik.http.routers.to-conduit.tls.options=chat@file" # 你需要在 Traefik 的动态配置中启用这一 Option，或者删掉这行配置，下面对 well_known 的配置同理
            - "traefik.http.routers.to-conduit.tls.certresolver=mytlschallenge" # 同样改成你在配置中启用
            - "traefik.http.routers.to-conduit.middlewares=cors-headers@docker"

            - "traefik.http.middlewares.cors-headers.headers.accessControlAllowOriginList=*"
            - "traefik.http.middlewares.cors-headers.headers.accessControlAllowHeaders=Origin, X-Requested-With, Content-Type, Accept, Authorization"
            - "traefik.http.middlewares.cors-headers.headers.accessControlAllowMethods=GET, POST, PUT, DELETE, OPTIONS"

    well-known:
        labels:
            - "traefik.enable=true"
            - "traefik.docker.network=traefik"

            - "traefik.http.routers.to-matrix-wellknown.rule=Host(`your.domain`)"
            - "traefik.http.routers.to-matrix-wellknown.tls=true"
            - "traefik.http.routers.to-matrix-wellknown.tls.options=chat@file"
            - "traefik.http.routers.to-matrix-wellknown.tls.certresolver=mytlschallenge"
            - "traefik.http.routers.to-matrix-wellknown.middlewares=cors-headers@docker"

            - "traefik.http.middlewares.cors-headers.headers.accessControlAllowOriginList=*"
            - "traefik.http.middlewares.cors-headers.headers.accessControlAllowHeaders=Origin, X-Requested-With, Content-Type, Accept, Authorization"
            - "traefik.http.middlewares.cors-headers.headers.accessControlAllowMethods=GET, POST, PUT, DELETE, OPTIONS"

愉快地docker-compose up -d，就能跑起来一个 Matrix Homeserver 了。你可以使用Federation Tester检测你的 Federation 功能是否成功配置。

配置&使用

我倒没有怎么特别配置过 Conduit，感觉已经比较顺手了。但是文档介绍了一些额外的配置，例如 TURN 和 Appservice(Bridge)，有兴趣的可以配置着玩。

至于使用，第一次创建用户时会生成一个会话密钥，请妥善保管。在其他平台登录该账号时使用此密钥验证，或与其他设备比较验证即可。需要注意的是，Conduit 目前不支持历史消息的获取，也不支持 Sliding Sync 功能，所以 ElementX 是无法使用的，其它客户端的 Space 功能也并不支持。（但基本的私聊，群组等功能是完整的）。

客户端方面，比较推荐的是Cinny，优雅极简的 Web Client，Android 上则推荐Element和FluffyChat，Gnome 上推荐 Fractal (Devel 版的，目前正式版不支持登录 Conduit)，但 KDE 上不推荐 NeoChat。cli 端没用过，可以都尝试以下，选择你最喜欢的。俺现在就是 FluffyChat + Cinny 了。不过，值得注意的是，Fractal 在我的设备上似乎存在无法获取消息的问题，不清楚是否是普遍性问题。

哦，对了，我的账户是Cris.Q，欢迎来找我玩耍哦。你也可以去我的GoToSocial账户逛逛。

年末随笔

Sun, 25 Dec 2022 00:00:00 GMT

今年于我而言是很难忘的一年，写个流水账追忆一下。

上半年我度过了我的初三。那是一段很累但很快乐的时光。初三的晚自习有三个多小时，我们就偷偷下位互相讨论题目，大部分时候会争得面红耳赤，然后带着怨气比做题速度。那时班上还喜欢提前写作业，各科作业都有。我个人更偏好写数学，曾经和当时的同桌比拼，一晚上写了十多面平面几何。你愿意说卷那就是卷吧，不过大概只是喜欢做题时的思考，品出了一些乐趣而已。

我最享受的一段时间，就是每次吃完午饭后，我独自漫步在校园，看着走廊上慵懒靠着的同学们，午后的暖阳给他们的发梢和眼角镀一层金边，也染白了教学楼不再笔直的轮廓线。我的初中校园不大，在我们班门口的走廊往外看便能看到校门口。傍晚十分，我就会靠在走廊的栏杆上，看着短短一段路上形形色色的人们，当然，有时也会被“青春”的气息狠狠刺痛，暗骂一句烧死那对狗男女。

中考那几天阴雨连绵，为了方便往返考场，我在考场附近的酒店暂住。那时我独住在一间房，特别喜欢戴上耳机，静静看着窗外的灯火和江面。每当看到江面上闪烁的光影和路边车流构成的灯河，就莫名对生活又产生了憧憬。大概是烟火气又飘进了心中吧，现在想来，那几天真是充满了诗意。

后来的那个暑假，是陪着一位“特殊的友人”走过的。我们一起去了北京，在故宫和天坛留下一段足迹，也涌入前门大街和太古里的人海。那也算是我第一次脱离父母，独自远行。在连续几个月网课的当下，这着实是一段弥足珍贵的回忆。

九月如期而至，高中生活莽莽撞撞地到来。在措手不及中又迎来网课的变故，期中考的取消，分科的纠结。下半年的日子一下子不好过了起来。索性，在线下教学的那些日子里，花园似的校园，同学间的互动和友谊，还有每天在办公室门口“踩点”的经历，或多或少总算还是给予了我些慰藉。

不过，高中伊始，一切似乎都还充满不确定性。我似乎正陷入自我怀疑的摇摆中，不敢贸然踏出一步。哦，还有。十二月天寒地冻，我顺带还被新冠蹂躏了一波，真的很难受，希望别再得了。

在彷徨，焦虑和虚无感中，我提起笔，四处寻找欢乐，充实和幸福感。

送别2022,希望新年更好。

一个人和一台服务器

Sat, 03 Dec 2022 00:00:00 GMT

最近看到了一个叫 Memos 的开源自托管笔记工具，非常惊喜，奈何这东西需要服务器部署。那没办法了，一咬牙一闭眼，斥巨资购买了一台阿里云香港的 VPS。

但毕竟服务器资源闲置也是闲置，我自然是顺手又给它叠了几个同样有趣的项目。

"万恶之源" Memos

不多说了，服务器就是为它买的。

这是我特别喜欢的笔记软件 Flomo 的界面：

我认为 Memos 可以作为 Flomo 的开源替代去用，就像 AppFlowy 或 Affine 对于 Notion 的替代一样（就这俩目前的功能而言，替代 Notion 都不太现实，而碰巧我很不喜欢 Notion 哈哈）。

搭建非常轻松，没有什么踩坑的点，我是直接按照官方的 docker-compose 文件搭的，这款应用的网页端可用度非常高，所以我目前桌面端就是将其作为应用安装在桌面使用的（感谢 Gnome 家美妙的浏览器 Epiphany），至于移动端，我推荐的选择是第三方的MoeMemos，拥有对于 Android 和 IOS 的完整支持，唯一稍显不足的是似乎不支持折叠 Memo，对图片的上传也有些问题。但是这并不重要～

不想学 Nginx 的懒人福音 Nginx Proxy Manager

我记得这东西有段时间在网上很火的啊，搜反向代理排名前几的都是推荐 NPM 的，不知道为啥现在好像看不太见了。

部署也非常简单，但是资源消耗有点大······

没办法，用它部署反向代理实在是太方便了，点几下就把从反代到 Let's Encrypt 申请证书都解决了，没法不用啊。

来都来了 x1 FreshRSS

我个人其实并不算是一个在线 RSS 阅读器的重度用户，我更喜欢在一个叫做 ReadYou 的移动端阅读器中读，而该阅读器是本地存储 Feeds 列表的。然而，每当我更换桌面端的 RSS 阅读器，或是有一些同步订阅源的需求，我就需要一遍一遍导入和导出 OPML，这实在太麻烦，于是所幸就自己搭建了一个 FreshRSS 实例。

FreshRSS 总体来说还是比较轻量化的，不过我选择的配套数据库是 PortgreSQL，并不算一个太轻量的数据库。

搭建方面我参考了ChrAlpha 的文章，写得非常详细了，安装完之后记得要在用户设置->管理->认证中勾选允许 API 访问，然后返回账户->用户账户填写一个 API 密码，才能让你的 RSS 阅读器通过该密码登入你的服务。

使用方面挺中规中矩，没有值得大书特书的亮点，但是并不难用。界面虽不惊艳，却也算简约现代。

不错的应用。

来都来了 x2 Wallabag

我以前还在用 Firefox 的时候，也算是一个 Pocket 的中度用户了，看到什么好的文章就会存到 Pocket 里。但既然有了开源的解决方案，肯定是要支持的。

不过 wallabag 的搭建就比较难受了，我选择的依旧是 docker-compose，但是其配置文件经过了我几次修改，现给出一个应该能用的版本：

version: '3'
services:
  wallabag:
    image: wallabag/wallabag
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
      - SYMFONY__ENV__DATABASE_HOST=db
      - SYMFONY__ENV__DATABASE_PORT=3306
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=wallabag
      - SYMFONY__ENV__DATABASE_PASSWORD=wallapass
      - SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
      - SYMFONY__ENV__MAILER_HOST=127.0.0.1
      - SYMFONY__ENV__MAILER_USER=~
      - SYMFONY__ENV__MAILER_PASSWORD=~
      - SYMFONY__ENV__FROM_EMAIL=你的邮箱地址   # 修改成你自己的邮箱
      - SYMFONY__ENV__DOMAIN_NAME=https://doma.in/  # 修改成稍后要反向代理的域名
      - SYMFONY__ENV__SERVER_NAME="My Wallabag"
    ports:
      - 7007:80   # 7007 可以修改成其他的自己想用的端口
    volumes:
      - ./images:/var/www/wallabag/web/assets/images  # 将图片映射挂载到本地
    healthcheck:
      test: ["CMD", "wget" ,"--no-verbose", "--tries=1", "--spider", "http://localhost"]
      interval: 1m
      timeout: 3s
    depends_on:
      - db
      - redis
  db:
    image: mariadb
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
    volumes:
      - ./data:/var/lib/mysql  # 将数据映射挂载到本地
    healthcheck:
      test: ["CMD", "mysqladmin" ,"ping", "-h", "localhost"]
      interval: 20s
      timeout: 3s
  redis:
    image: redis:alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 20s

演示图就不放了，我应该不太会去用它的网页版，桌面端可以使用Read It Later，至于移动端，可选项就不少了，我选择的是FeedMe。

来都来了 x3 GoToSocial

不知道各位小伙伴听过 Mastodon 没有，最近它又因为马斯克老师而火了一把。

我最早应该是 21 年上半年开始用 Mastodon，当时在几个中文实例间辗转。后来在小森林定居。但近期因为一些原因，小森林的访问变得有些困难，于是所幸自己搭了一个实例。

但是，在面对 Mastodon 这种笨重的庞然大物时，我那 2C1G 的服务器开始止不住地颤抖起来，难道就没有更轻量级，但又能和 Mastodon 几乎完美兼容的应用吗？

GoToSocial就这样来到了我面前。

这是一个使用 Go 编写的，兼容 Mastodon API 的服务端应用，可以与各种支持 Fediverse 的应用互通。这意味着，你可以使用大部分现成的 Mastodon 客户端登录并使用 GoToSocial，且大部分功能正常使用。而 GoToSocial 对服务器的内存花销是——50～100Mb。

绝了！

GoToSocial 的部署出奇简单。通过 docker-compose，仅需要几行命令便可部署一个可用的实例。但有一个点我目前没太弄明白，就是用户的删除，我至今还无法删除我创建的测试账号，只能当小号用。

另外需要注意的一点是，使用 GoToSocial 关注的用户，只向你展示你关注他之后他发布的内容，且他的关注与粉丝也都只会显示你。这样做可能也是为了安全性考虑吧。

那么，多关注些人，耐心等个几天，你的时间线会再次热闹起来的。

对了，我的 Mastodon 账号是 @crisq@g.crisq.top，欢迎来找我玩！

收工

以上便是我目前在服务器上搭建的所有服务，迫于服务器资源限制，有些我很眼馋的项目却没有机会搭，不得不说是件憾事。

要不...V 我 50 让我再买台服务器？

关于笔记应用的一些想法

Mon, 25 Jul 2022 00:00:00 GMT

又强迫自己用了一阵子Notion和FlowUs，实在没用下去。

我心目中对笔记的定义还是临时性的记录（从这点来说更像备忘，而事实上笔记的一大作用就是备忘），从本子上随便撕张纸就开始写的那种。那我为什么还要在撕纸写字的时候思考我应该把笔记放到哪个文件夹的哪个子页面，从长长的块列表里选出一个符合我想法的块，一点一点加双链呢？等找到符合我心意的帅气精致的块的时候PPT都换页了啊喂🥲。

我心目中对理想笔记软件的定义大概跟创作Flomo的少楠老师一样，一定要快，打开就写（我甚至嫌Android的软键盘Gboard拖慢了录入效率，频频打断思考），随处可写，有着最纯粹的"书写"的体验（在格式和书写流畅度的兼顾上，Markdown虽然也并不尽如人意，但是比富文本和html还是要优秀的多了），非侵入性，不用因为太操心排版打断思考（但是却不是Simplenote那样一点版式都没有）。我既不需要看板图表，也不需要双链和知识图谱，它们都是服务于知识管理的工具（但是你似乎又找不到一个不加这些功能的新一代笔记软件，Unix哲学在现在算是被忘得一干二净了）。

Obsidian、Notion、Logseq、AppFlowy、Roam这些见鬼的产品都不是我需要的笔记软件，不因为追求时髦或莫名其妙的精致感去强迫自己用它们，是在这个有些生产力焦虑的时代，对自己的一种放过。

说说友链

Sat, 18 Jun 2022 00:00:00 GMT

仅代表个人观点

细琢磨一下，加友链跟扩列似乎已经变成了一回事。

从目的来说，都是扩展关系网，可能还带一点点展示和炫耀的心思；而从形式来说，则更为相似，看看许多博客下充斥的"大佬加个友链"，怎能让人不联想到QQ空间的扩列潮呢？毕竟，"扩个列"和"加个友链"，从表意到句式都如此一致。这两个平行的群体，竟在一瞬间以莫名的方式重合。

我必须先提出我的观点：对于现在的独立博客而言（尤其是学生们运营的博客），友链的意义已不再偏重于推广网站，而是"交流与展示"。比如一些博主会选择以"friends"而不是"links"来命名友链页面。另外，"开往"这类友链接力平台能起到的外链引入和搜索权重提升的作用是微乎其微的，但他们却一直存在且愈加壮大，这难道不说明了我们对友链的定义和需求在逐渐转变向交流和展示吗？不过，如果我们这个观点成立，那现在的友链环境似乎变得可怕起来。

博主们的友链展示区延伸着望不到尽头的长长列表，评论区充斥着加友链的呼声，甚至还出现了自动加友链的脚本和友链接力的平台。友链已然与"友"脱钩。尤其是自动加友链，明确只追求数量不追求质量的方针，不管一个人的技术表达或思想观念你是否认可，甚至你根本没有访问过他的博客，但只要他的提交格式合格，你的脚本还是忠实的让他成了你的朋友。

在本就小众的博客圈，我们开始试图寻找尽可能"大众"，或者叫"大群体"的身份认同：我和如此多的大佬都建立了关系网，因此我融入了一个大的博主圈子，认领了博主的身份，就像把全身浸泡到水里。而再如何大的圈子又怎么比得上社区呢？于是"十年之约""虫洞"这类平台开始兴起。人们涌入一个个大的社区，与一群素不相识的朋友连结成友链的大网。

链是链起来了，其他的就不好说了。

我并不是一个极端分子，也不鼓吹博客的去社交化或孤岛化。我们在友链中发现他人，找到自己喜爱的博主；也在友链中发现自己，了解自己的兴趣和品味。友链串起分散的互联网个人博客世界。但一味的去不停得"加"友链，去追求友链的数量，是不是让我们陷入了一种盲目？我们又该用什么态度面对自己巨大的"朋友"圈呢？

我们来思考几个问题。

你的友链网中，你有几位朋友的IM好友？你和其中几位朋友保持着比较活跃的交流？从你对一位博主喊出"大佬加个友链"至今，你是否第二次访问过这个博主的博客？

你看，友链其实并未连接你我。

它是一串数据，一个URL，一段无意义的介绍，一个可有可无的头像。它不是友情，也不是交流。你看不到也无心去看看友链的另一头，而你也无法通过你的友链列表认识自己了。

当我们的联系止于友链，友链也便不再是友链。

这篇文章定稿后，我对我自己的友链列表做了反复审视和修改。

令我欣慰的是，我大概还算是一个有朋友的人。

记一次"Password Incorrect"错误的修复

Wed, 09 Feb 2022 00:00:00 GMT

本文应该适用于ArchLinux，其它发行版不保证成功。

愉快的例行Syyu，虽然中间用Ctrl+C打断了几次但也还算顺利。把电脑晾在一边，起身去给自己倒了杯开水，伴着氤氲荡开的水汽，坐回原位熟练的输入密码并敲下Enter。

"Paasword Incorrect"

噔噔噔咚

发生甚么事了

我们再来审视一下上面这段话。 "...中间用Ctrl+C打断了几次..."，对，问题就出在这儿。在上述情况下打断输入密码的进程，也算输入错误。而且没有任何提示告诉你这一点。于是你就被锁住了🤐。

几次使用Ctrl+C打断pacman进程后无论怎么输密码都会提示密码不正确的情况，说起来我也多次遇到过了，以前真的就以为是类似语言设置崩掉之类的玄学问题🥲，这次处理后才突然明白过来。

那既然不是玄学问题，当然也是有通法来解的啦！

终于进入正题，来讲讲解决办法

首先，你得事先设置了root用户和密码。（对于没设置的我才疏学浅也不知道咋办，有知道的烦请评论区指出）

其次，按Ctrl+Alt+F3（或者别的什么等效的快捷键）进到tty界面，以root身份登录。

然后，输入faillock --reset --user <username>（username就是你被锁住的用户名），请注意，这条命令是在root权限下执行的（废话你上一步都用的root登录当然是要有root权限的啊）

踩坑记录：一开始不知道是faillock的问题，以为是存储密码的文件被破坏了，所以试了passwd <username>，这条命令是无效的！因为你不是密码输错了，是被"请五分钟后重试"了啊🤣

这条命令执行完后如果没啥报错就Ctrl+Alt+F1回你刚才的登录窗口，继续愉快的使用。

哦，对了，别忘了把刚才倒的水喝完。