下面是一个「常用命令速查表」，作为git使用的备忘录



### 首次使用
设置用户名

```
git config --global user.name "jameskerry651"
```


设置邮箱

```
git config --global user.email "jameskerry651@gmail.com"
```

查看当前配置

```
git config --list
```

---

### 一、仓库初始化 / 克隆

1. 初始化本地仓库

```
git init
```
在当前文件夹创建一个新的 Git 仓库（生成 .git 目录）。

2. 克隆远程仓库 
 
```
git clone <repo-url>
```
例如：
git clone https://github.com/user/project.git

从远程拉一份完整的仓库到本地。

---

### 二、查看状态 / 变更

3. 查看当前状态

```
git status
```


查看哪些文件被修改、哪些已暂存、当前所在分支等。

4. 查看具体改动


```
git diff              # 查看工作区相对暂存区的改动
git diff --staged     # 查看暂存区相对最近一次提交的改动
```

---

### 三、添加与提交

5. 添加到暂存区（stage）


```
git add <file>        # 添加指定文件
git add .             # 添加当前目录下所有改动
```


6. 提交记录


```
git commit -m "描述本次修改"
```

写清楚提交说明，有助于以后回看历史。

---

### 四、查看提交历史

7. 查看提交日志


```
git log
git log --oneline     # 一行一个提交，简洁模式
git log --graph --oneline --all  # 图形化查看分支
```




---

### 五、分支操作

8. 查看/创建/切换分支


```
git branch            # 列出本地分支
git branch <name>     # 创建分支

git checkout <name>   # 切换分支（老用法）
git switch <name>     # 切换分支（推荐，较新）

git switch -c <name>  # 创建并切换到新分支

```



9. 合并分支

# 假设当前在 main 分支，要合并 feature 分支：

```
git merge feature
```

如果有冲突，需要手动解决后再：


```
git add <conflict-files>
git commit
```

10. 删除分支

```

git branch -d <name>   # 删除本地分支（已合并）
git branch -D <name>   # 强制删除本地分支

```

---

### 六、远程仓库相关

11. 查看/添加远程仓库

```

git remote -v               # 查看远程仓库列表
git remote add origin <url> # 添加名为 origin 的远程
```

12. 抓取 & 拉取代码


```
git fetch             # 只拉取远程更新，不合并
git pull              # 等于 fetch + merge（把远程分支合并到当前分支）
```

指定远程和分支：

```
git pull origin main
```

13. 推送代码到远程


```
git push               # 已设置 upstream 时可直接用
git push origin main   # 将本地 main 推到远程 origin/main
```

首次推送新分支：


```
git push -u origin <branch>
```

-u 会设置默认上游分支，后面就可以直接 git push。

---

### 七、临时保存、回退

14. 临时保存修改（stash）


```
git stash             # 把当前未提交的修改暂存起来
git stash list        # 查看所有 stash
git stash pop         # 取出最近一次 stash 并应用
git stash drop        # 删除最近一次 stash
```

15. 回退修改

撤销工作区的改动（回到暂存区或最近提交）：


```
git restore <file>          # 恢复文件（新命令）
git checkout -- <file>      # 老命令，作用类似
```

撤销已经暂存的改动：


```
git restore --staged <file>
```

移动当前 HEAD 到某个提交（谨慎）：


```
git reset --soft <commit>   # 回退到某提交，但保留改动在暂存区
git reset --mixed <commit>  # 默认，改动回到工作区
git reset --hard <commit>   # 全都丢弃到该提交状态（慎用！）
```


---

### 八、Tag（标签）

16. 打标签（常用于版本号）


```

git tag v1.0.0                  # 在当前提交打轻量标签
git tag -a v1.0.0 -m "说明"     # 带注释标签
git push origin v1.0.0          # 推送指定标签
git push origin --tags          # 推送所有标签
```


--- 

### 九、远程强制覆盖本地
1. 下载远程仓库最新内容，不做合并

```
git fetch --all
```

2. 将本地指针重置为远程分支的最新状态

注意：将 <branch_name> 替换为你的分支名，如 master 或 main

```
git reset --hard origin/main
```


3. (可选) 再次拉取确认同步
git pull

git常用操作

这是一个非常典型的传感器数据融合问题。由于**相机频率 > 里程计频率**（例如相机 30Hz，里程计 10Hz），不能简单地做“最近邻”匹配，否则连续几帧图像会对应同一个里程计位姿，导致轨迹呈阶梯状，这对 VIO 或 SLAM 算法是致命的。




需要做的是**基于相机的时间戳，对里程计数据进行插值（Interpolation）**。

以下是具体的操作步骤和代码思路：

### 核心思路：插值 (Interpolation)

为每一帧相机图像的时间戳 $t_{img}$，根据其前后时刻的里程计数据 $O_{prev}$ 和 $O_{next}$，计算出一个虚拟的里程计位姿 $O_{interp}$。

1.  **位置 (Position, $x, y, z$)**：使用线性插值 (Linear Interpolation / Lerp)。
2.  **旋转 (Rotation, $q_x, q_y, q_z, q_w$)**：使用球面线性插值 (Spherical Linear Interpolation / Slerp)。**注意：旋转不能直接线性相加。**

---

### 详细步骤

#### 1. 数据准备
确保两个序列都已按时间戳从小到大排序。
*   Camera List: $[(t_{c1}, img_1), (t_{c2}, img_2), ...]$
*   Odom List: $[(t_{o1}, pose_1), (t_{o2}, pose_2), ...]$

#### 2. 时间对齐与搜索
遍历相机数据序列。对于每一帧相机图像（时间戳 $t_{c}$）：
*   在里程计序列中找到**刚好小于** $t_{c}$ 的帧 $O_i$ (时间戳 $t_{o\_prev}$)。
*   找到**刚好大于** $t_{c}$ 的帧 $O_{i+1}$ (时间戳 $t_{o\_next}$)。
*   如果 $t_{c}$ 超出了里程计的时间范围（比如比第一个里程计早，或比最后一个晚），通常选择**丢弃**该帧图像，或者使用外推法（不推荐，误差大）。

#### 3. 计算插值系数 $\alpha$
计算相机时间在两个里程计时间之间的比例：
$$ \alpha = \frac{t_{c} - t_{o\_prev}}{t_{o\_next} - t_{o\_prev}} $$
其中 $\alpha \in [0, 1]$。

#### 4. 执行插值
*   **位置 $P$**：
    $$ P_{sync} = (1 - \alpha) \cdot P_{prev} + \alpha \cdot P_{next} $$
*   **旋转 $Q$ (四元数)**：
    使用 **Slerp** 算法。
    $$ Q_{sync} = \text{Slerp}(Q_{prev}, Q_{next}, \alpha) $$

---

### benchmark

**EVO (轨迹评估工具)**:
    *   为了评估轨迹精度（比如对比 Ground Truth 和 算法输出），可以直接使用 `evo` 工具包。
    *   命令：`evo_ape tum data.tum --t_max_diff 0.01`。
    *   注意：Evo 也是做关联（Association），主要用于对齐两条轨迹，而不是为了给相机帧“造”数据。

### 总结

，**以相机时间戳为基准，对里程计进行线性位置插值和 Slerp 旋转插值**。

里程计与相机插值算法

本文将简述常见的空间变换矩阵和相关公式推导。




### 1️⃣三种基本变换：平移、旋转和缩放

我们先尝试只用3x3矩阵来表示这些变换。这种方式很容易让人接受【但计算机没那么喜欢】

- 缩放（Scale）: 可以完美地用3x3矩阵表示。

$$
\left[ \begin{matrix} {S_{x}} & {0} & {0} \\ {0} & {S_{y}} & {0} \\ {0} & {0} & {S_{z}} \\ \end{matrix} \right] \left[ \begin{matrix} {x} \\ {y} \\ {z} \\ \end{matrix} \right]=\left[ \begin{matrix} {S_{x} \cdot x} \\ {S_{y} \cdot y} \\ {S_{z} \cdot z} \\ \end{matrix} \right]
$$

- 旋转（Rotation）: 也可以完美地用3x3矩阵表示（例如绕Z轴旋转）。

$$
\left[ \begin{matrix} {\operatorname{c o s} \theta} & {-\operatorname{s i n} \theta} & {0} \\ {\operatorname{s i n} \theta} & {\operatorname{c o s} \theta} & {0} \\ {0} & {0} & {1} \\ \end{matrix} \right] \left[ \begin{matrix} {x} \\ {y} \\ {z} \\ \end{matrix} \right]=\left[ \begin{matrix} {x \operatorname{c o s} \theta-y \operatorname{s i n} \theta} \\ {x \operatorname{s i n} \theta+y \operatorname{c o s} \theta} \\ {z} \\ \end{matrix} \right]
$$

- 平移：我们无法找到一个3x3矩阵使得$\mathbf{M}\cdot\vec{v}=\vec{v}+\vec{t}_{\circ}$

因为矩阵乘法是线性变换（输出是输入的线性组合），而平移是仿射变换，它有一个常量偏移。你无法通过 $ax + by + cz$ 这种形式来得到 $x + T_x$。

在引入齐次矩阵前，先推导一下旋转矩阵的得来：
假设在2D平面中有一个点 $P(x,y)$，我们将其绕原点逆时针旋转角度 $θ$得到新点 $ P'(x', y') $。设点 $P$ 到原点的距离为 $r$与 $x$ 轴的夹角为 $α$，则有:

$$
x=r \operatorname{c o s} \alpha, \quad y=r \operatorname{s i n} \alpha
$$

旋转后：

$$
x^{\prime}=r \operatorname{c o s} ( \alpha+\theta) , \quad y^{\prime}=r \operatorname{s i n} ( \alpha+\theta)
$$

利用三角函数公式展开：

$$
\begin{array} {c} {x^{\prime}=r ( \operatorname{c o s} \alpha\operatorname{c o s} \theta-\operatorname{s i n} \alpha\operatorname{s i n} \theta)=x \operatorname{c o s} \theta-y \operatorname{s i n} \theta} \\ {y^{\prime}=r ( \operatorname{s i n} \alpha\operatorname{c o s} \theta+\operatorname{c o s} \alpha\operatorname{s i n} \theta)=x \operatorname{s i n} \theta+y \operatorname{c o s} \theta} \\ \end{array}
$$

写成矩阵形式：
$$
\left[ \begin{matrix} {x^{\prime}} \\ {y^{\prime}} \\ \end{matrix} \right]=\left[ \begin{matrix} {\operatorname{c o s} \theta} & {-\operatorname{s i n} \theta} \\ {\operatorname{s i n} \theta} & {\operatorname{c o s} \theta} \\ \end{matrix} \right] \left[ \begin{matrix} {x} \\ {y} \\ \end{matrix} \right]
$$

因此，2D旋转矩阵为：
$$
R ( \theta)=\left[ \begin{matrix} {\operatorname{c o s} \theta} & {-\operatorname{s i n} \theta} \\ {\operatorname{s i n} \theta} & {\operatorname{c o s} \theta} \\ \end{matrix} \right]
$$

### 平移与齐次坐标
3x3矩阵无法表示平移变换。为了解决这个问题，数学家们想出了一个巧妙的办法：将3D向量升维到4D空间。这就是齐次坐标。

一个3D点在齐次坐标系下表示为$( x , y , z , w )$，其中 w 是一个分量。



$$
\left[ \begin{matrix} {1} & {0} & {0} & {T_{x}} \\ {0} & {1} & {0} & {T_{y}} \\ {0} & {0} & {1} & {T_{z}} \\ {0} & {0} & {0} & {1} \\ \end{matrix} \right] \left[ \begin{matrix} {x} \\ {y} \\ {z} \\ {1} \\ \end{matrix} \right]=\left[ \begin{matrix} {x+T_{x}} \\ {y+T_{y}} \\ {z+T_{z}} \\ {1} \\ \end{matrix} \right]
$$

通过引入齐次矩阵，解决了平移的问题，为什么要用乘法而不是直接用加法，目的是为了统一这三种基本变换的算子，让计算机做连续的矩阵乘法。可以将多次变换提前计算出来，存储为一个齐次矩阵。


### 2️⃣ 矩阵变换实际应用

在计算机图形学中，矩阵变换是最常用的，下面以opengl为例子，讲述矩阵变换的实际应用场景。

首先我们需要明白：

:::info{title="空间变换"}
要用一个矩阵把向量从“空间 A”变到“空间 B”，核心就是：要知道空间 B 的“坐标轴”在空间 A 里长什么样，再加上（如果需要的话）原点怎么平移。
:::

首先看一下opengl的坐标变换体系：


![image.png](/static/img/0fcc105c5d0f8d2089b900b94d068796.image.webp)


#### 局部空间到世界空间
这一步非常好理解，局部空间主要是存放模型的顶点，原点：通常是模型的几何中心或某个参考点。
通常会标准化到 [-1, 1] 范围。

Model矩阵的意义就是定义模型在世界空间的尺寸和位姿，在model矩阵中填入模型的rotate,scale和tranlate 组成model矩阵。

#### 局部空间到观察空间

这里涉及的主要知识就是线形代数中的**基变换**。
本质：向量不变，基向量变了，所以坐标（系数）必须变。

`矩阵 P：由新基向量在旧系中的坐标作为列组成。`

口诀：
*   新 $\to$ 旧：直接乘 $P$ （$P \mathbf{x}_{new} = \mathbf{x}_{old}$）
*   旧 $\to$ 新：乘逆矩阵 $P^{-1}$ （$\mathbf{x}_{new} = P^{-1} \mathbf{x}_{old}$）

在 OpenGL 或计算机图形学中，**从世界坐标（World Space）变换到相机坐标（Camera/View Space）** 是“坐标变换”最经典、最实用的例子。

这个变换通常由 **视图矩阵（View Matrix）** 完成。

我们将利用上一节提到的**“Old $\to$ New 需要逆矩阵”**的理论来一步步推导这个过程。

---

### 1. 场景设定与直观理解

#### 设定
*   **旧坐标系（世界坐标）**：绝对的 $(0,0,0)$，基向量是标准的 $X, Y, Z$。
*   **新坐标系（相机坐标）**：以**相机为中心**，相机永远觉得自己是在原点 $(0,0,0)$，看向 $-Z$ 轴（OpenGL右手系标准）。
*   **物体**：一个茶壶放在世界坐标 $(10, 5, 3)$ 的位置。
*   **相机**：放在世界坐标 $(0, 5, 10)$ 的位置，看向茶壶。

#### 直观理解：相对运动
在图形学中，移动相机太麻烦了（因为屏幕是死的），所以我们采用**“逆向思维”**：
> **不移动相机，而是反向移动整个世界。**

如果你想把相机向**右**移 5 米，等同于把世界里所有的物体向**左**移 5 米。
这就解释了为什么我们需要计算**“逆（Inverse）”**。

---

### 2. 构建相机的“基向量”（UVN系统）

首先，我们需要知道新坐标系（相机）长什么样。通常我们使用 `gluLookAt(eye, center, up)` 函数来定义：

1.  **Eye (相机位置)**: $P_{eye}$
2.  **Center (看向哪里)**: $P_{target}$
3.  **Up (世界的大致上方)**: $\vec{up}_{world}$ (通常是 $0,1,0$)


:::tip{title="提示"}
定义相机的Position,Target,Up 本质上就是构建新的坐标的基向量，也是构建过渡矩阵
:::


我们需要构建相机的三个正交基向量（Right, Up, Direction）：

1.  **Z轴（方向轴 $\vec{f}$）**：
    在OpenGL中，相机看向 $-Z$ 方向，所以 $+Z$ 指向相机的背后。
    $$ \vec{z}_{cam} = \text{normalize}(P_{eye} - P_{target}) $$
2.  **X轴（右轴 $\vec{r}$）**：
    利用叉乘（Cross Product）。右轴垂直于“上方向”和“Z轴”。
    $$ \vec{x}_{cam} = \text{normalize}(\vec{up}_{world} \times \vec{z}_{cam}) $$
3.  **Y轴（上轴 $\vec{u}$）**：
    垂直于已经算出来的 Z 和 X。
    $$ \vec{y}_{cam} = \vec{z}_{cam} \times \vec{x}_{cam} $$

现在，我们有了新坐标系的基向量：$\vec{r}, \vec{u}, \vec{f}$。

这里根据rgb颜色观察相机的x,y,z轴

![image.png](/static/img/50c1678bca19160d3889331f2d1d3584.image.webp)

---

### 3. 矩阵推导：平移与旋转

我们要把一个点 $P_{world}$ 变成 $P_{camera}$。
公式是：
$$ P_{camera} = \text{ViewMatrix} \cdot P_{world} $$

这个变换分为两步：**先平移（把相机移回原点），再旋转（把相机的朝向对准坐标轴）。**

#### 第一步：平移矩阵 $T$
相机当前在 $P_{eye} = (x_e, y_e, z_e)$。
要把相机移回世界原点 $(0,0,0)$，我们需要平移 $(-x_e, -y_e, -z_e)$。

$$ 
T = \begin{bmatrix} 
1 & 0 & 0 & -x_e \\
0 & 1 & 0 & -y_e \\
0 & 0 & 1 & -z_e \\
0 & 0 & 0 & 1
\end{bmatrix} 
$$

#### 第二步：旋转矩阵 $R$（核心应用！）
这里是应用我们之前理论的关键点。

我们知道旋转矩阵 $R_{orientation}$ 的**列**应该是新基向量（相机的 $\vec{r}, \vec{u}, \vec{f}$）在世界坐标下的值。

$$ 
R_{orientation} = \begin{bmatrix} 
| & | & | & 0 \\
\vec{r} & \vec{u} & \vec{f} & 0 \\
| & | & | & 0 \\
0 & 0 & 0 & 1 
\end{bmatrix} 
$$

**但是！** 上面这个矩阵代表的是 **Camera $\to$ World** 的变换（把相机坐标转成世界坐标）。
正如第一部分理论所说：**已知旧坐标求新坐标（World $\to$ Camera），需要乘以逆矩阵 $P^{-1}$。**

**线性代数的小魔法：**
对于纯旋转矩阵（正交矩阵），**逆矩阵等于转置矩阵（Inverse = Transpose）**。
所以，我们不需要辛苦算逆，直接把行变成列即可：

$$ 
R = (R_{orientation})^{-1} = (R_{orientation})^{T} = \begin{bmatrix} 
- & \vec{r} & - & 0 \\
- & \vec{u} & - & 0 \\
- & \vec{f} & - & 0 \\
0 & 0 & 0 & 1 
\end{bmatrix} = \begin{bmatrix} 
r_x & r_y & r_z & 0 \\
u_x & u_y & u_z & 0 \\
f_x & f_y & f_z & 0 \\
0 & 0 & 0 & 1 
\end{bmatrix} 
$$

*(注意：这里的基向量现在横着躺在了**行**里)*

---

### 4. 最终的视图矩阵 (View Matrix)

将两步合起来（先平移，再旋转，注意矩阵乘法顺序是从右向左）：
$$ 
\text{ViewMatrix} = R \cdot T 
$$


$$ 
\text{ViewMatrix} = \begin{bmatrix} 
r_x & r_y & r_z & 0 \\
u_x & u_y & u_z & 0 \\
f_x & f_y & f_z & 0 \\
0 & 0 & 0 & 1 
\end{bmatrix} \cdot \begin{bmatrix} 
1 & 0 & 0 & -x_e \\
0 & 1 & 0 & -y_e \\
0 & 0 & 1 & -z_e \\
0 & 0 & 0 & 1 
\end{bmatrix} 
$$

计算结果就是经典的 **LookAt Matrix**：

$$ 
\begin{bmatrix} 
r_x & r_y & r_z & -\vec{r} \cdot P_{eye} \\
u_x & u_y & u_z & -\vec{u} \cdot P_{eye} \\
f_x & f_y & f_z & -\vec{f} \cdot P_{eye} \\
0 & 0 & 0 & 1 
\end{bmatrix} 
$$

*(注：最后的一列实际上就是 $-\vec{r} \cdot P_{eye}$，也就是平移向量在新基向量上的投影)*

---

### 5. 总结与举例验证

假设：
*   **相机位置**：$(0, 0, 5)$
*   **看向**：$(0, 0, 0)$
*   **上方**：$(0, 1, 0)$
*   **世界中有一个点**：$P_{world} = (0, 0, 2)$

**人脑直观推测**：
相机在 $z=5$ 看向原点，点在 $z=2$。对相机来说，这个点在它前方 3 米处。因为相机看的是 $-Z$ 方向，所以在相机坐标系里，这个点的坐标应该是 $(0, 0, -3)$。

**利用矩阵计算**：
1.  **基向量**：
    *   $\vec{f} = (0,0,1)$ (指向相机背后)
    *   $\vec{r} = (1,0,0)$
    *   $\vec{u} = (0,1,0)$
2.  **旋转矩阵 $R$** (转置后还是它自己，因为是对角阵)：单位矩阵。
3.  **平移矩阵 $T$**：$z$ 轴平移 $-5$。
4.  **运算**：


    $$ P_{cam} = \begin{bmatrix} 1 & 0 & 0 & 0 \\ 0 & 1 & 0 & 0 \\ 0 & 0 & 1 & -5 \\ 0 & 0 & 0 & 1 \end{bmatrix} \begin{bmatrix} 0 \\ 0 \\ 2 \\ 1 \end{bmatrix} = \begin{bmatrix} 0 \\ 0 \\ 2-5 \\ 1 \end{bmatrix} = \begin{bmatrix} 0 \\ 0 \\ -3 \\ 1 \end{bmatrix} $$

**结果吻合！**

### 关键点回顾
在 OpenGL 的这个例子中，体现了坐标变换的两个精髓：
1.  **逆向思维**：World $\to$ Camera 本质上是把世界做了一个**逆变换**（$T^{-1} \cdot R^{-1}$）。
2.  **基变换计算**：利用正交矩阵的性质（$R^{-1} = R^T$），将相机的基向量作为**行**填入矩阵，即可完成旋转变换。


### 3️⃣FPS相机与轨道相机

轨道相机的本质是球坐标系 (Spherical Coordinates) 到 直角坐标系 (Cartesian Coordinates) 的转换。

假设我们盯着点$P_{target}$,距离为 R，角度为 θ(Pitch) ,我们要算出相机的位置$P_{eye}$.
计算公式:

$$
\begin{aligned} {x} & {{}=R \cdot\operatorname{c o s} ( \theta) \cdot\operatorname{c o s} ( \phi)} \\ {y} & {{}=R \cdot\operatorname{s i n} ( \theta)} \\ {z} & {{}=R \cdot\operatorname{c o s} ( \theta) \cdot\operatorname{s i n} ( \phi)} \\ \end{aligned}
$$

这算出来的是相对于目标点的偏移量 (Offset)。所以，相机的最终位置是：

$$
P_{e y e}=P_{t a r g e t}+\left[ \begin{matrix} {x} \\ {y} \\ {z} \\ \end{matrix} \right]
$$

最直观的感受就是：
- FPS：输入改变角度，导致你看到的画面在旋转，但物体不动（除非你按W前进）。

- 轨道：输入改变角度，导致世界在旋转（其实是相机绕到了物体侧面），物体始终在屏幕中心。

计算代码参考：

```c++
void Camera::updateViewMatrix() {
    // 计算相机朝向角度的弧度值以及相关三角函数值
    const float yawRad = qDegreesToRadians(m_yaw);
    const float pitchRad = qDegreesToRadians(m_pitch);
    const float cosPitch = qCos(pitchRad);

    // 根据欧拉角计算相机前方方向向量
    QVector3D forward(
        qSin(yawRad) * cosPitch,
        qSin(pitchRad),
        qCos(yawRad) * cosPitch
    );
    forward.normalize();

    // 根据目标点、前方方向和距离计算相机实际位置
    m_position = m_target - forward * m_distance;
    
    // 构建视图矩阵
    m_viewMatrix.setToIdentity();
    m_viewMatrix.lookAt(m_position, m_target, m_up);
}
```

矩阵乘法在向量空间变化的理解

本篇文章记录学习opengl过程中的笔记和心得。

笔记的主要构成是关键名词和对应的解释与理解。


### OpenGL
opengl本质上是图形api接口,通过接口，用户可以利用显卡高效的在屏幕上绘制想要的内容。不过更加广义的opengl是一套接口标准，只要你的图像接口叫opengl,就应该符合标准。

### GLFW
glfw是一个比较常用的库，主要是处理用户输出，提供opengl初始化的context,提供渲染窗口,原文描述：`It allows us to create an OpenGL context, define window parameters, and handle user input, which is plenty enough for our purposes.`

### GLAD
由于显卡型号繁多、驱动版本天天更新，每个函数（比如 glUseProgram）在内存中的位置是不固定的。在编译阶段，编译器不知道这些函数在运行时会在哪里。当你写代码调用 glDrawArrays 时，实际上是看了一眼 GLAD 的本子，然后直接找到了对应的位置去执行。


:::info{title="比喻"}
GLAD 是一个“翻译官”或“寻址员”，它负责在你的显卡驱动里找到每一个 OpenGL 函数的具体内存地址。
:::

### Graphics Pipeline
图像管线，这个词经常听到。指代图像渲染整个流程，如下图：我们会编写管线上的处理程序，又叫shader。 其中功能蓝色的表示可以由人修改的部分。


![image.png](/static/img/066af4039707aa673780a3f2df653496.image.webp)

### Shader
本质上是一段程序，用GLSL语言编写。Shader 代码的逻辑是写给“一个点”看的，但在运行时，GPU 会并行地对“一堆点”同时执行这份代码【将shader分配到多个gpu核心上】。

当你调用 OpenGL 的绘制命令（如 glDrawArrays）时，GPU 会瞬间叫来几千个工人（GPU 核心）。
- 每个工人都拿着你写的那份同一张“操作指南”。
- 每个工人手里拿一个不同的球（不同的数据）。
- 所有人同时开始工作（并行计算）。

### Vertex
一个Vertex就是指代一个顶点数据，GPU 要处理的“一个点”的整体数据。包含多个属性。原文：`A vertex is a collection of data per 3D coordinate. `

Vertex的字段就是用`vertex attributes`表示。这个点身上的各个字段，比如位置、颜色、法线、纹理坐标等。


### Vertex Shade
告诉 GPU “三角形的三个角在画布的什么位置”。

### Fragment Shader
告诉 GPU “三角形内部涂什么颜色”。

### 绘制一个三角形的流程
画一个三角形听起来简单，但在 OpenGL 中，它是一个把数据从 **CPU（你的内存）** 搬运到 **GPU（显存）**，并告诉显卡如何处理的过程。

为了容易理解，把 GPU 想象成一个**高度自动化的画室**。

我们需要三个角色：
1.  **VBO (Vertex Buffer Object)**：**专用颜料桶**（存放原始数据）。
2.  **VAO (Vertex Array Object)**：**说明书/档案夹**（记录数据怎么用）。
3.  **Shader (着色器)**：**画师**（执行绘画逻辑）。

下面是绘制一个三角形的完整流程：

---

### 第一阶段：准备工作（初始化）

在画画之前，你得先把材料送进画室（GPU），并写好说明书。

#### 1. 准备数据（CPU）
你在 C++ 代码里定义了一个数组，里面有 3 个顶点的坐标：
```cpp
float vertices[] = {
    -0.5f, -0.5f, 0.0f, // 左下
     0.5f, -0.5f, 0.0f, // 右下
     0.0f,  0.5f, 0.0f  // 顶部
};
```
这时候数据还在你的内存里（CPU），GPU 根本看不见。

#### 2. 创建 VAO（档案夹）
**这步非常重要，一定要先做！**
你想：“我要开始配置一组新的绘画动作了。”
于是你拿出一个空的**档案夹 (VAO)** 并在桌子上打开它 (`glBindVertexArray`)。
*   **作用**：从此以后，你对 VBO 做的一切配置，都会被自动记录在这个档案夹里。

#### 3. 创建 VBO（颜料桶）并传输数据
你需要把内存里的数据搬到显存里。
*   **动作**：你在显存里申请了一块空间，我们叫它 **VBO**。
*   **绑定**：你把这个 VBO 放在当前的工位上 (`glBindBuffer`)。
*   **填装**：你把 CPU 里的 `vertices` 数组倒进这个 VBO 里 (`glBufferData`)。
*   **现状**：现在 GPU 拥有了一堆数字，但它只知道这是一堆二进制数据，不知道这代表坐标、颜色还是法线。

#### 4. 解释数据（写进 VAO 档案夹）
这时候，VAO（档案夹）还是打开状态。你需要告诉 GPU 如何读取刚才那个 VBO 里的数据。
你发出指令 (`glVertexAttribPointer`)：
*   “每隔 3 个数字读一次（因为是 x, y, z）。”
*   “这些数据是浮点数 (float)。”
*   “这是顶点的位置信息 (Layout 0)。”

**关键点**：当你做完这步，**VAO 默默地把“在这个 VBO 上怎么读数据”这个配置记录下来了。**

#### 5. 解绑（合上档案夹）
配置完成。你合上 VAO 档案夹 (`glBindVertexArray(0)`)，把它放回架子上。此时，VBO 里的数据已经安家在 GPU 了，VAO 里也记好了怎么用它。

---

### 第二阶段：雇佣画师（编译 Shader）

你需要写两段代码（Vertex Shader 和 Fragment Shader），编译并链接成一个 **Shader Program**。

*   **Vertex Shader**：告诉 GPU “三角形的三个角在画布的什么位置”。
*   **Fragment Shader**：告诉 GPU “三角形内部涂什么颜色”。

---

### 第三阶段：开始绘制（渲染循环）

这一步是每一帧（Loop）都要做的事情。虽然之前准备工作很繁琐，但画的时候非常快。

流程如下：

1.  **呼叫画师**：
    `glUseProgram(shaderProgram);`
    *   喊出：“Shader 画师团队，准备干活！”

2.  **拿出档案夹 (VAO)**：
    `glBindVertexArray(VAO);`
    *   这是最神奇的一步。你不需要再重新告诉 GPU “去哪个 VBO 找数据”、“怎么读数据”。
    *   你只要把之前的 **VAO 档案夹** 拿出来打开，GPU 立刻就知道了：“噢，我要去那个 VBO 拿数据，每 3 个一组读……”
    *   **这就是为什么要用 VAO：它像一个快捷方式，保存了所有的状态配置。**

3.  **下令绘制**：
    `glDrawArrays(GL_TRIANGLES, 0, 3);`
    *   喊出：“开画！画三角形，画 3 个点！”

---

### 总结一下他们的关系

*   **VBO** 是 **仓库**：实实在在地存着那堆数字。
*   **VAO** 是 **管理员的记录本**：它不存数据，它存的是**指针和格式**。它记录了“数据在哪个 VBO”以及“格式是什么”。
*   **Shader** 是 **操作流水线**：数据进来，经过 Shader 的计算，变成屏幕上的颜色。

**最精简的流程记忆：**
1.  生成 VAO -> 绑定 VAO。
2.  生成 VBO -> 绑定 VBO -> 塞数据。
3.  设置解析格式 (`glVertexAttribPointer`) -> 启用格式。
4.  **渲染循环里**：用 Shader -> 绑定 VAO -> `glDrawArrays`。


### glBindVertexArray
这个函数初学很容易忽略，更像是一个录制开关。
当你第一次创建好 VAO 并调用 glBindVertexArray(VAO) 时，你实际上是对 OpenGL 说了这句话：

“OpenGL 听好了！从现在开始（直到我解绑为止），我所做的所有关于‘顶点属性配置’的操作，请全部记在这个 VAO 的账上！”
它具体“录制”了什么？
当你绑定了 VAO 后，紧接着调用的以下函数，都会被记录在这个 VAO 里：

- glBindBuffer(GL_ARRAY_BUFFER, VBO)：虽然 VBO 存的是数据，但 VAO 会记住“我们要用哪个 VBO”。
- glVertexAttribPointer(...)：VAO 记住了“第几列数据是坐标，第几列是颜色，偏移量是多少”。
- glEnableVertexAttribArray(...)：VAO 记住了“启用了哪些属性通道”。
- glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, EBO)：如果有索引缓冲（EBO），VAO 也会记住它。
- 解绑 (glBindVertexArray(0))：
这相当于按下“停止录制”。OpenGL 此时不再把配置记在这个 VAO 头上了，恢复到默认状态。

### glEnableVertexAttribArray
这个函数也很关键，是理解shader语言中的location的关键。

为了理解它，我们需要先理清 数据是如何从内存流向 Shader 的。这里有一个关键的“断点”。

1. 核心比喻：水管与水龙头
想象一下你的渲染流程：

VBO (显存里的数据)：这是一个巨大的蓄水池，里面装满了水（顶点数据）。
glVertexAttribPointer：这是铺设管道。你告诉 OpenGL：“请铺设一根管子，从蓄水池引出来，每隔 3 个单位取一次水，管子接到 Location 0 这个位置。”
Vertex Shader (着色器)：这是水龙头。里面写着 layout (location = 0) in vec3 aPos;，等着水流进来。
但是！默认情况下，OpenGL 为了节省性能，把所有连接 Shader 的总闸（阀门）都关掉了。

glEnableVertexAttribArray(0)：这就是拧开 0 号位置的阀门。
如果你铺好了管道（写了 glVertexAttribPointer），但是忘了拧开阀门（没写 glEnable...），水根本流不到 Shader 里。Shader 里的 aPos 读不到 VBO 里的数据，它只会读到一个默认值（通常是 0），导致你屏幕上一片漆黑或者图形缩成一个点。

在 OpenGL 中，顶点着色器（Vertex Shader）可能有多个输入槽位（Attribute Location）。

举个例子，你的 Shader 可能长这样：


```
#version 330 core
layout (location = 0) in vec3 aPos;    // 0号槽位：位置
layout (location = 1) in vec3 aColor;  // 1号槽位：颜色
layout (location = 2) in vec2 aTexCoord; // 2号槽位：纹理
```

显卡有多个“通道”来喂数据给这些变量。

有些时候，你可能只想画形状，不想画纹理。
有些时候，你可能只想用一种固定的颜色，不需要从 VBO 里读颜色。
所以 OpenGL 默认把这些通道都设为 Disable（禁用） 状态。

当你调用 glEnableVertexAttribArray(1) 时，你是在告诉 GPU：“请启用 1 号通道，去 VBO 里按照我之前定义的格式读取数据，然后喂给 Shader 里的 location = 1 那个变量。”

这个开关的状态是保存在 VAO 里的！
这就是为什么代码通常是这样写的：

```
// 1. 绑定 VAO (打开档案夹)
glBindVertexArray(VAO);

// 2. 绑定 VBO (准备数据)
glBindBuffer(GL_ARRAY_BUFFER, VBO);

// 3. 告诉 OpenGL 怎么读数据 (铺设管道)
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * sizeof(float), (void*)0);

// 4. 【关键】启用 0 号属性 (打开 0 号阀门)
glEnableVertexAttribArray(0);  // <--- 这一步的状态被记录在了 VAO 里

// 5. 解绑 VAO
glBindVertexArray(0);
```

OpenGL学习笔记

这是一次挖矿病毒查杀记录
发生时间大约在11月10日前后一两天



### 1️⃣持久化
挖矿病毒通常为了避免被用户kill掉，都会选择持久化，一般来说就是cron和systemd两种选择，所以排查的思路就是查看相关服务或定时任务的配置文件
**先找到“第一次出现矿工/持久化”的大致时间点，后续与登录/访问日志做对齐。**

```
sudo ls -lt /etc/systemd/system | head -n 30
```
这个命令通常用于快速查看最近在系统中被修改、添加或启用的 systemd 服务单元。

输出：

```
-rw-r--r-- 1 root root  135 11月 13 22:08 system.service
drwxr-xr-x 2 root root 4096 11月 10 18:51 default.target.wants
drwxr-xr-x 2 root root 4096 11月 10 18:51 multi-user.target.wants
-rw-r--r-- 1 root root  190 11月 10 18:51 route_forbidden.service
-rw-r--r-- 1 root root  443 11月  9 09:32 ollama.service
drwxr-xr-x 2 root root 4096 11月  5 16:52 snapd.mounts.target.wants
-rw-r--r-- 1 root root  344 11月  5 16:52 snap-gnome\x2d42\x2d2204-226.mount
-rw-r--r-- 1 root root  365 11月  4 16:23 snap-pycharm\x2dprofessional-548.mount
-rw-r--r-- 1 root root  326 11月  4 06:19 snap-core22-2139.mount
-rw-r--r-- 1 root root  329 11月  4 00:54 snap-firefox-7177.mount
-rw-r--r-- 1 root root  338 11月  4 00:54 snap-snap\x2dstore-1216.mount
-rw-r--r-- 1 root root  380 11月  4 00:54 snap-snapd\x2ddesktop\x2dintegration-315.mount
-rw-r--r-- 1 root root  326 11月  4 00:53 snap-snapd-25577.mount
drwxr-xr-x 2 root root 4096 11月  4 00:40 systemd-suspend.service.wants
drwxr-xr-x 2 root root 4096 11月  4 00:40 systemd-suspend-then-hibernate.service.wants
drwxr-xr-x 2 root root 4096 11月  4 00:40 systemd-hibernate.service.wants
drwxr-xr-x 2 root root 4096 11月  4 00:31 sockets.target.wants
lrwxrwxrwx 1 root root   31 11月  3 22:54 sshd.service -> /lib/systemd/system/ssh.service
```

根据时间发生时间进行溯源，system.service,default.target.wants,multi-user.target.wants,route_forbidden.service 极有可能是被黑客动手脚了。


### 2️⃣multi-user.target.wants 目录和 default.target.wants目录
multi-user.target.wants 本质上是一个/etc/systemd/system/multi-user.target.wants/下的`目录`。目录包含了当系统进入多用户命令行模式时，必须自动启动的服务列表。

例如：当使用 `systemctl enable nginx` 命令来让 Nginx 服务开机自启时，systemd 实际上就是在 multi-user.target.wants 目录下创建了一个指向 /usr/lib/systemd/system/nginx.service 的符号链接。

这里因为黑客enable 了route_forbidden.service，所以导致multi-user.target.wants发生了变动。

/etc/systemd/system/default.target.wants/ 目录包含了当系统进入默认目标（无论是 graphical.target 还是 multi-user.target）时，都必须自动启动的服务。


执行以下命令查看wants目录下哪些service最近被修改过：

```shell
ls -lt  /etc/systemd/system/multi-user.target.wants | head -n 10
```
输出：

```
lrwxrwxrwx 1 root root 43 11月 10 18:51 route_forbidden.service -> /etc/systemd/system/route_forbidden.service
lrwxrwxrwx 1 root root 54 11月  5 16:52 snap-gnome\x2d42\x2d2204-226.mount -> /etc/systemd/system/snap-gnome\x2d42\x2d2204-226.mount
lrwxrwxrwx 1 root root 58 11月  4 16:23 snap-pycharm\x2dprofessional-548.mount -> /etc/systemd/system/snap-pycharm\x2dprofessional-548.mount
lrwxrwxrwx 1 root root 32 11月  4 16:05 xrdp.service -> /lib/systemd/system/xrdp.service
lrwxrwxrwx 1 root root 39 11月  4 16:05 xrdp-sesman.service -> /lib/systemd/system/xrdp-sesman.service
lrwxrwxrwx 1 root root 42 11月  4 06:19 snap-core22-2139.mount -> /etc/systemd/system/snap-core22-2139.mount
lrwxrwxrwx 1 root root 43 11月  4 00:54 snap-firefox-7177.mount -> /etc/systemd/system/snap-firefox-7177.mount
lrwxrwxrwx 1 root root 49 11月  4 00:54 snap-snap\x2dstore-1216.mount -> /etc/systemd/system/snap-snap\x2dstore-1216.mount
lrwxrwxrwx 1 root root 66 11月  4 00:54 snap-snapd\x2ddesktop\x2dintegration-315.mount -> /etc/systemd/system/snap-snapd\x2ddesktop\x2dintegration-315.mount
```
根据输出可以看到`/etc/systemd/system/route_forbidden.service` 这个服务被enable了。


然后再查看`default.target.wants`目录下有哪些service被enable了

```
ls -lt /etc/systemd/system/default.target.wants/ | head -n 10
```
输出：

```
lrwxrwxrwx 1 root root 34 11月 10 18:51 system.service -> /etc/systemd/system/system.service
lrwxrwxrwx 1 root root 34 11月  9 09:09 ollama.service -> /etc/systemd/system/ollama.service
```

可以看到system.service是黑客动过手脚的service.

除此之外，按时间顺序列出 /etc/systemd/system/ 目录中所有服务单元文件（.service 文件）的最后修改时间。
执行：

```
sudo | stat -c '%y %n' /etc/systemd/system/*.service | 2>/dev/null | | | sort
```

输出：

```
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-fi.w1.wpa_supplicant1.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.bluez.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.freedesktop.Avahi.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.freedesktop.nm-dispatcher.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.freedesktop.oom1.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.freedesktop.resolve1.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.freedesktop.thermald.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/dbus-org.freedesktop.timesync1.service
2025-11-03 22:34:38.116185889 +0800 /etc/systemd/system/display-manager.service
2025-11-03 22:34:38.117185917 +0800 /etc/systemd/system/sudo.service
2025-11-03 22:34:38.117185917 +0800 /etc/systemd/system/syslog.service
2025-11-03 22:54:04.679584528 +0800 /etc/systemd/system/sshd.service
2025-11-09 09:32:22.566007156 +0800 /etc/systemd/system/ollama.service
2025-11-10 18:51:01.284670255 +0800 /etc/systemd/system/route_forbidden.service
2025-11-13 22:08:00.899714204 +0800 /etc/systemd/system/system.service
```


然后排查cron的配置：

```
sudo stat -c '%y %n' /etc/cron*/* /var/spool/cron/crontabs/* 2>/dev/null | sort
```
输出：

```
2019-11-19 23:14:51.000000000 +0800 /etc/cron.daily/cracklib-runtime
2021-10-10 01:14:16.000000000 +0800 /etc/cron.daily/0anacron
2021-10-10 01:14:16.000000000 +0800 /etc/cron.d/anacron
2021-10-10 01:14:16.000000000 +0800 /etc/cron.monthly/0anacron
2021-10-10 01:14:16.000000000 +0800 /etc/cron.weekly/0anacron
2021-12-06 06:59:35.000000000 +0800 /etc/cron.daily/dpkg
2022-01-09 04:02:36.000000000 +0800 /etc/cron.d/e2scrub_all
2022-01-24 23:37:01.000000000 +0800 /etc/cron.daily/logrotate
2022-03-18 03:03:00.000000000 +0800 /etc/cron.daily/man-db
2022-03-18 03:03:00.000000000 +0800 /etc/cron.weekly/man-db
2022-04-08 18:22:23.000000000 +0800 /etc/cron.daily/apt-compat
2023-07-25 02:24:17.000000000 +0800 /etc/cron.daily/apport
```

分析可以发现列出的 /etc/cron*、/var/spool/cron/crontabs/* 没有近期改动（都停在 2019–2023），这说明这波挖矿没有走 cron 持久化，而是专注用 systemd 单元。

到这里基本上确定了黑客持久化通过伪装的system.service和route_forbidden.service进行持久化。入侵的时间应该是在`2025-11-10 18:51:01.284670255`

:::warning{title="注意"}
2025-11-10 18:51:01.284670255 是关键时间点，入侵的时间大概率早于此时
:::

### 3️⃣分析黑客创建的service

```
执行cat /etc/systemd/system/route_forbidden.service
```
输出：

```
[Unit]
Description=System function loader.

[Service]
Type=forking
GuessMainPID=no
Restart=always
RestartSec=10
ExecStart=-/usr/bin/route_forbidden-all

[Install]
WantedBy=multi-user.target
```

这明显不是正常系统服务：名字可疑、ExecStart 指向陌生二进制 /usr/bin/route_forbidden-all，还用 Type=forking + GuessMainPID=no + 前缀 -（忽略失败）来提高“自愈率”。高度可疑的后门/加载器。

`forking` 类型用于那些会自己创建子进程并让父进程退出的传统守护进程。恶意软件经常使用这种类型来迷惑 systemd。主启动程序可以快速执行并退出，而真正的恶意负载在后台作为一个独立的子进程运行。

`GuessMainPID=no` 它明确告诉 systemd：“不要尝试猜测哪个进程是主进程”。这与 Type=forking 结合使用，使得 systemd 很难跟踪到真正的恶意进程PID。这让服务的管理（如 systemctl status 或 systemctl stop）变得不可靠，进一步增强了恶意软件的生存能力。


执行：

```
cat /etc/systemd/system/system.service
```

输出：

```
[Unit]
Description=Custom System Service

[Service]
ExecStart=/usr/bin/system/system
Restart=always

[Install]
WantedBy=default.target
```

/usr/bin/system/system：这个二进制文件是所有恶意行为的执行者。它的功能可能是从挖矿、DDoS攻击到数据窃取或作为勒索软件的加载器。

### 4️⃣其他线索挖掘
执行安全审计命令，专门用于在 Linux 系统日志中搜索未经授权的加密货币挖矿活动迹象。

```
sudo journalctl --no-pager | grep -iE 'xmrig|minerd|kdevtmpfsi|kinsing|watchdog|stratum|pool|nanopool|monero'
```

输出：

```
11月 13 22:07:59 james-Precision-7920-Tower kernel: NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
11月 13 22:07:59 james-Precision-7920-Tower kernel: DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations
11月 13 22:07:59 james-Precision-7920-Tower kernel: DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
11月 13 22:07:59 james-Precision-7920-Tower kernel: DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
11月 13 22:08:03 james-Precision-7920-Tower system[1380]:  * ABOUT        XMRig/6.21.0 gcc/5.4.0 (built for Linux x86-64, 64 bit)
11月 13 22:08:03 james-Precision-7920-Tower system[1380]:  * POOL #1      king.markrege.shop:80 algo auto
11月 13 22:08:03 james-Precision-7920-Tower system[1380]:  * POOL #2      king.markrege.shop:443 algo auto
11月 13 22:08:04 james-Precision-7920-Tower rtkit-daemon[1675]: Watchdog thread running.
11月 13 22:08:09 james-Precision-7920-Tower system[1380]: [2025-11-13 22:08:09.948]  net      use pool king.markrege.shop:443 TLSv1.3 194.62.122.80
11月 13 22:08:09 james-Precision-7920-Tower system[1380]: [2025-11-13 22:08:09.981]  net      use pool king.markrege.shop:80  194.62.122.80
```

这下基本上可以进行取证了，机器在 22:07:59 刚启动（内核 NMI watchdog 日志），22:08:03 system 进程（由 system.service 启动）立刻加载 XMRig，并连到 king.markrege.shop:80/443（解析到了 194.62.122.80）。
说明 system.service 确实是挖矿持久化，且随开机自启。


### 分析root执行的命令

执行以下命令查看root 用户的 bash 命令历史记录文件
```
sudo  cat /root/.bash_history
```
输出：

```
bash <(curl -sSL https://linuxmirrors.cn/main.sh)
ls
curl -fsSL https://tailscale.com/install.sh | sh
tailscale up
tailscale netcheck
ls
kill 71008
ls
cd /mnt
ls
ls -a
cd
ls
cd /home/james
ls
tar -xvf l.tar.gz
./tree -a kawpow -o stratum+ssl://127.0.0.1:1602 -u RG8hkuPjjPKYjeuPa3MDyX9FTDjxSoWtdU.RIG --no-watchdog --no-strict-ssl
ls
nano root.sh
./root.sh
nvidia-smi
ls
```
可以看到攻击者上传了l.tar.gz压缩包，并执行了挖矿命令，其中-a kawpow:
-a 很可能代表“算法（algorithm）”。
kawpow 是一种特定的工作量证明（Proof-of-Work）挖矿算法。使用此算法的最著名的加密货币是 Ravencoin (RVN)。这明确告诉我们攻击者在挖什么类型的币。

-o stratum+ssl://127.0.0.1:1602 它没有直接连接到互联网上的公共矿池，而是连接到本地（localhost）的1602端口。这通常意味着攻击者在你的服务器上还运行了另一个代理程序（proxy）。这个代理程序监听1602端口，接收tree矿工的连接，然后再将流量转发到真正的外部矿池。这样做有几个好处

-u RG8hkuPjjPKYjeuPa3MDyX9FTDjxSoWtdU.RIG
-u 代表“用户（user）”或“钱包地址（username）”。
RG8hkuPjjPKYjeuPa3MDyX9FTDjxSoWtdU 这长长的一串字符，就是攻击者的Ravencoin钱包地址。所有挖矿产生的收益都会打到这个地址里。这是非常有价值的线索。
.RIG 是矿工名（Worker Name）。攻击者用它来标识是哪台被黑的机器在为他工作。

### 恶意文件分析
不要立即删除 /usr/bin/route_forbidden-all！ 先对它进行取证分析：
file /usr/bin/route_forbidden-all：查看文件类型（是二进制程序还是脚本）。
strings /usr/bin/route_forbidden-all | less：查看文件中包含的可打印字符串，可能会发现IP地址、域名、命令等线索。
sha256sum /usr/bin/route_forbidden-all：计算其哈希值，然后去 VirusTotal 等在线平台查询是否为已知的恶意软件。
备份该文件到一个安全的地方（比如压缩并加密），以备后续分析。


### 全面排查

攻击者不可能只留下这一个东西。你需要：
检查 crontab (crontab -l for root and other users)。
检查 /etc/rc.local 和其他启动脚本。
检查用户的 .bashrc, .profile 等文件是否有可疑命令。
检查 /root/.ssh/authorized_keys 和其他用户的 authorized_keys 是否有未知的公钥。
检查 last 和 who 命令，看是否有可疑的登录历史。
使用 ss -antp 或 netstat -antp 查看是否有其他异常的网络连接。

挖矿病毒查杀记录

Welcome to my tech blog! Here, I document my coding journey and explore various technologies, focusing on practical solutions and streamlined techniques. From programming insights to tool recommendations, I share hands-on experiences that help sharpen your skills. Let’s learn and grow together!