当前位置： 首页 > news >正文

SP‘24 SSRFuzz论文学习

news 2025/9/15 6:31:57

论文地址：https://www.jianjunchen.com/p/ssrfuzz.sp24.pdf

零、前言

因为是学习/复现的第一篇big four的paper，所以印象非常深刻。再加上复现学习确实做了很多工作，所以记录一下~

一、复现

复现环境搭建

踩坑力）这是修好了的版本：

git clone https://github.com/SSRFuzz/SSRFuzz.git
cd SSRFuzz
git submodule update --init --progressdocker network create ssrf-net
docker pull dockerproxy.net/rocm/dev-ubuntu-22.04:latest
docker tag dockerproxy.net/rocm/dev-ubuntu-22.04:latest rocm/dev-ubuntu-22.04:latest
docker rmi dockerproxy.net/rocm/dev-ubuntu-22.04:latest
docker run -d --name SSRFuzz-u22 --network ssrf-net -v "$(pwd)":/SSRFuzz --gpus all rocm/dev-ubuntu-22.04 sleep infinity
docker exec -it SSRFuzz-u22 /bin/bashdocker run --name ssrf_db --network ssrf-net -e MYSQL_ROOT_PASSWORD=123456 -d -p 3306:3306 mysql:8.0cd SSRFuzz
apt update && apt install python3-pip python3-venv -y && apt update && apt install software-properties-common -y
add-apt-repository ppa:ondrej/php # 按ENTER
apt update && apt install php7.4 php7.4-cli php7.4-fpm php7.4-mysql php7.4-curl php7.4-mbstring php7.4-xml php7.4-zip php7.4-dev php7.4-pgsql -y curl -sS https://getcomposer.org/installer -o composer-setup.php
php7.4 composer-setup.php --install-dir=/usr/local/bin --filename=composer
rm composer-setup.phpcd TaintInfer ; composer install
cd ../Fuzzer; pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simplecd ../zmark;
phpize
./configure
make -j$(nproc)apt update && apt-get install -y mysql-client
mysql -h ssrf_db -u root -pCREATE DATABASE IF NOT EXISTS ssrf_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE ssrf_db;CREATE TABLE `ssrf_info` (`id` int unsigned NOT NULL AUTO_INCREMENT,`param` varchar(255) DEFAULT NULL,`Av1` varchar(255) DEFAULT NULL,`Av2` varchar(255) DEFAULT NULL,`Bv1` varchar(255) DEFAULT NULL,`Bv2` varchar(255) DEFAULT NULL,`requests` mediumtext,`vulntype` varchar(255) DEFAULT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;CREATE TABLE `ssrf_vuln` (`id` int unsigned NOT NULL AUTO_INCREMENT,`vulnparam` varchar(255) DEFAULT NULL,`vulntype` varchar(255) DEFAULT NULL,PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;CREATE TABLE `check_info` (`id` int unsigned NOT NULL AUTO_INCREMENT,`param` varchar(255) DEFAULT NULL,`vulnable` varchar(255) DEFAULT '0',`stack` mediumtext,`body` mediumtext,`url` mediumtext,PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4;ALTER USER 'root'@'%' IDENTIFIED WITH 'mysql_native_password' BY '123456';
FLUSH PRIVILEGES;
exit;# soshite, modify the TaintInfer/src/Config.php to use the right path 
# and modify Fuzzer/fuzzer.php to correct the database settings
# open 4 terminal# docker exec -it SSRFuzz-u22 /bin/bash
# 1.
cd /SSRFuzz/Fuzzer && python3 fuzzer.py
# 2.
cd /SSRFuzz/Fuzzer && python3 detector.py
# 3.
cd /SSRFuzz/TaintInfer/verify && ./run.sh
# 4.
curl "http://localhost:8000/params.php?url=1&nnn=2"

效果

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

root@45dcfdddbffe:/SSRFuzz/TaintInfer/verify# ./run.sh
curl "http://localhost:8000/params.php?url=1&nnn=2"
curl "http://localhost:8000/params.php?url=http://www.baidu.com&nnn=2"

可以发现我们的url参数被成功截获！

url=1是非法，url=www.baidu.com是正常

四个terminal：

fuzzer.py:
在这里插入图片描述

detector.py:
在这里插入图片描述

./run.sh:
在这里插入图片描述

curl:
在这里插入图片描述

taint识别到url参数最终触发了sink，所以对url进行fuzz，替换为能够被detector检测的"url"，中间加了绕filter的字符

如果是需要多参数共同决定最终的sink点的参数？（比如 $a.$b） <= To Be Check

params.php改了下：

$result = file_get_contents($url.$nnn);

发现检测不出来了

paper实现的好像就只能是单param的

        if 'query' in self.request and self.request['query']:self.fuzz_query() // 里面用的fuzz_one_valueif 'data' in self.request and self.request['data']:self.fuzz_body()

算个未来的挑战吧

二、一些思考

Q1

Taint那儿是动态的，为什么？（如何区分动态/静态分析方法 是需要执行来关联，还是直接源代码分析）

动态的话，怎么保证深度的？跟fuzz ing一样，有些路径执行不到怎么处理？

ANSWER：Executing the code or not； 它是在一个 被插桩的、正在运行的 Web应用环境中进行的。区别于psalm；
用智能爬虫crawlgo来保证深度；
对执行不到的路径无法处理，动态分析的通病

Q2

如何实际来测真实的PHP project?

ANSWER：理论上，再加一个crawlergo的爬虫联动就能触发，但是实际实现起来，多个docker交互细节的坑很多。

Q3

有什么启发？

ANSWER：留到后面写。

三、Deeper dive

1. zmark

特别好用的一个PHP Hook的工具。
用法：

php -d "extension_dir=/src/zmark/modules/" -d "extension=zmark.so" -d "zmark.enable=1" -d "zmark.rename_functions=var_dump:_var_dump" test.php
最好把zmark.so复制到php插件目录php -d "extension=zmark.so" -d "zmark.enable=1" -d "zmark.rename_functions=var_dump:_var_dump" test_zmark.php

some ideas by Gemini:

好的，我们来深入探讨一下。您这个问题提得非常好，并且对SSRFuzz的分析完全正确。它的核心思想——**利用动态污点分析进行攻击面“预筛选”，从而为Fuzzing节约大量资源**——是极具启发性的。`zmark` 的本质是提供了一个在PHP运行时对数据流进行**标记**和**拦截**的能力。我们可以将 `SSRFuzz` 的模式进行抽象和泛化，然后应用到几乎所有与用户输入相关的漏洞类型上。### 核心模式：污染源 -> 传播 -> 危险函数 (Source -> Propagation -> Sink)这个模式是动态污点分析的灵魂，`zmark` 的功能完美地映射了它：1. **定义污染源 (Source)**：通常是所有外部输入，如 `$_GET`, `$_POST`, `$_COOKIE`, `$_SERVER` 等。我们用 `zmark()` 来给这些输入数据“染色”。
2. **追踪污点传播 (Propagation)**：当“被染色”的数据在程序中被复制、拼接、处理时，我们希望“染料”也能跟着传递下去。这是最复杂的一步，`zmark` 的**操作码挂钩**（如拦截字符串拼接 `ZMARK_CONCAT`）在这里能发挥巨大作用。
3. **识别危险函数 (Sink)**：这是“染料”最终产生危害的地方，比如执行系统命令、查询数据库、输出到页面等。我们用 `zrename_function` 来拦截这些函数。
4. **在Sink处检查**：当一个危险函数被调用时，我们检查它的关键参数是否“带色”（`zcheck()`）。如果带色，就证明从污染源到危险函数存在一条完整的数据流路径。
5. **触发动作**：确认路径后，我们就可以做一系列事情：记录日志、中断执行、或者像 `SSRFuzz` 一样，**将这个（端点、参数）组合存入数据库，作为高价值的Fuzzing目标**。---### 基于此模式的更多启发和应用### 灵感一：发现其他类型的“高价值Fuzzing目标”我们可以完全复刻 `SSRFuzz` 的思路，只是更换不同的“危险函数”即可。| 目标漏洞类型 | 危险函数 (Sinks) | “预筛选”出的Fuzzing目标 |
| --- | --- | --- |
| **SQL 注入** | `mysqli_query`, `PDO::query`, `PDO::prepare`, `PDOStatement::execute` 等所有数据库执行函数。 | 所有其输入会直接或间接拼接到SQL语句中的HTTP参数。 |
| **命令注入/代码执行** | `system`, `exec`, `shell_exec`, `passthru`, `popen`, `proc_open`, `eval`, `assert`。 | 所有其输入会成为待执行命令或代码一部分的HTTP参数。 |
| **文件包含/路径遍历** | `include`, `require`, `include_once`, `require_once`, `fopen`, `file_get_contents`, `readfile`。 | 所有其输入会影响最终读取或包含的文件路径的HTTP参数。 |
| **反序列化** | `unserialize`。 | 所有会作为 `unserialize` 函数输入的HTTP参数。 |**工具思路**：我们可以开发一个“**通用漏洞Fuzzing目标发现器**”。它内置了对上述所有危险函数的Hook。在对一个大型Web应用进行全量请求扫描后（比如用爬虫跑一遍所有功能），这个工具就能输出一个数据库，里面包含了针对不同漏洞类型的高价值目标列表。然后，我们可以将这个列表喂给 `sqlmap`, `commix`, 或者自定义的Fuzzer，进行精准、高效的漏洞挖掘。### 灵感二：自动化安全审计与漏洞预警（IAST）相比于筛选Fuzzing目标，我们可以更进一步，尝试直接发现漏洞或进行实时拦截，构建一个轻量级的交互式应用安全测试（IAST）引擎。- **XSS 漏洞检测**：- **Source**: `$_GET`, `$_POST` 等。- **Sink**: `echo`, `print` 等输出函数。这里 **opcode hook `ZMARK_ECHO`** 会比函数Hook更强大。- **Sanitizers (净化函数)**: `htmlspecialchars`, `htmlentities`, `strip_tags` 等。- **逻辑**:1. 用 `zmark()` 标记所有输入为“Tainted_HTML”。2. Hook所有的净化函数。当一个被标记的字符串经过净化函数处理后，用 `zclear()` **清除它的标记**，因为它现在是安全的了。3. 在 `echo` 的Hook点，如果检查到参数**依然带有标记** (`zcheck()`)，这说明有一条从输入到输出的路径，且**没有经过任何已知的净化函数**。- **启发**: 这就是一个基础的XSS检测引擎。它可以直接在测试环境中，当QA或爬虫在测试功能时，自动发现潜在的XSS漏洞并输出精准的漏洞报告（包含URL、参数、输出点）。
- **二次漏洞（Second-Order Vulnerability）挖掘**：- **场景**: 一个参数先被存入数据库，之后在另一个完全不同的请求中被取出并使用，最终触发漏洞。- **逻辑**:1. **Hook数据库写入函数**（如 `mysqli_query` 中含有 `INSERT` 或 `UPDATE` 的语句）。如果发现写入的数据是“被污染”的，则除了数据本身，我们还需要**在`zmark`的辅助数据库中记录下这个数据的唯一标识**（比如 `PRIMARY KEY`）。2. **Hook数据库读取函数**（如 `mysqli_fetch_assoc`）。如果读取出的数据所对应的唯一标识在我们辅助数据库中，就重新用 `zmark()` 将这个从数据库里读出来的数据**再次标记为“已污染”**。3. 后续流程和普通漏洞检测一样。- **启发**: 这使得 `zmark` 能够跨请求、跨存储地追踪污点，极大地增强了发现隐藏较深的二次漏洞的能力。### 灵感三：代码与业务逻辑理解`zmark` 不仅仅能用于找漏洞，它强大的Hook能力还能帮我们快速理解一个陌生的、庞大的代码库。- **关键业务链路梳理**：- 想知道用户完成一次“下单”操作，到底调用了哪些函数、修改了哪些数据库的表？- **做法**: Hook所有你关心的函数（数据库、缓存、关键业务类方法），在Hook的函数里打印出调用栈 (`debug_print_backtrace()`)。然后手动触发一次下单操作，你就能得到一条完整的、清晰的执行链路日志。
- **敏感数据（PII）泄露审计**：- **目标**: 确保用户的手机号、邮箱、身份证号等敏感信息不会被不当地记录到日志或泄露到前端。- **做法**:1. Hook数据库查询函数。当查询结果的字段名是 `email`, `phone`, `id_card` 等敏感词时，用 `zmark()` 标记返回的相应数据。2. Hook日志记录函数 (`error_log`) 和输出函数 (`echo`)。3. 在日志和输出的Sink点，检查参数是否带有敏感标记。如果带了，就立即告警。总之，`zmark` 提供了一个“上帝视角”，让我们能在程序运行时动态地、低成本地观测和干预其内部的数据流。基于这个能力，想象力是唯一的限制。

2. 漏洞检测模式

本质上就是

  1. Hook
  2. Taint propagate
  3. Sink
  4. Callback
    的过程，后面看多了觉得还好，但第一次看还是很震撼的，甚至在怀疑自己没有这种工程量的代码能力 😦

3. Novelty的思考

那么，为什么这篇paper能发Oakland呢🤔

Some ideas by Gemini:

您这个反思非常深刻，完全切中了问题的要害！“**用强大的并发工程能力，能否暴力破解这个问题？**”这是一个非常实际且值得探讨的角度。您的直觉是对的——在某些场景下，一个用Go写的高效并发扫描器，表现可能会非常好。然而，`SSRFuzz` 这类研究之所以被认为是顶会级别的创新，是因为它解决了几个“高并发盲目Fuzzing”模式在面对**大型、真实、复杂**应用时，难以克服的根本性障碍。我们可以从以下几个层面来分析：### 1. 攻击面的量级：远超想象的“组合爆炸”您的论点“对每个parameter都fuzzing”可能低估了现代Web应用中参数的真实数量。- **参数总量巨大**：一个中等规模的应用（比如带有几十个插件的WordPress或Magento），其暴露出的API端点可能有成千上万个，每个端点平均有2-5个参数。总参数量可以轻松达到**数万甚至数十万**。
- **参数结构复杂**：很多参数不是简单的 `id=123`，而是嵌套的JSON、XML或序列化数组。例如 `data={"user":{"profile_image_url":"FUZZ_HERE"}}`。一个盲目的Fuzzer如何知道应该在哪一层、哪个字段插入payload？如果对整个JSON体进行变异，效率会极其低下。
- **组合污染**：有时SSRF的触发需要多个参数的配合，比如 `?host=example.com&port=80`。盲目Fuzzing很难有效处理这种跨参数的依赖关系。我们假设一个大型应用有10,000个参数（这是一个保守的估计），每个参数我们只用100个基础payload去试探。这就需要 **1,000,000** 次请求。这仅仅是开始，还没考虑嵌套和组合问题。`SSRFuzz` 的DTA阶段，可能只需要几千次正常的请求，就能将这10,000个参数的目标范围缩小到其中的50个，效率提升是数量级的。### 2. Fuzzing的真实瓶颈：并非客户端，而是服务器端您用Go写并发的思路是优化**客户端（Fuzzer）的效率，但Fuzzing的瓶颈往往在服务器端（目标应用）**。- **服务器处理能力有限**：一个Web应用处理单个请求可能需要几十到几百毫秒（因为它要走完数据库查询、业务逻辑、模板渲染等一系列流程）。服务器的QPS（每秒查询率）是有限的。您用Go可以一秒钟发出10,000个请求，但服务器可能一秒钟只能处理200个，多余的请求都会被拒绝或排队，导致测试时间急剧拉长。
- **破坏性测试**：高并发的、带有攻击性的请求很容易触发服务器的WAF（Web应用防火墙）、资源限制，甚至直接把应用进程打死（Denial of Service），导致后续的Fuzzing无法进行。`SSRFuzz` 的DTA阶段，发送的是**基本正常的请求**，对服务器负载小，不易被发现和拦截。它是在“悄无声息”地绘制地图，然后再对极少数目标进行“外科手术式”的打击。### 3. “神谕问题”（The Oracle Problem）：如何有效确认成果？这是盲目Fuzzing最核心的难题之一。对于SSRF，你怎么知道你的Payload成功了？最可靠的方法是**带外交互（Out-of-Band Interaction, OOBI）**，即Payload是 `http://UNIQUE_ID.your-dns-server.com`。然后你等待自己的DNS服务器收到查询。- **关联难题**：当你发送了数百万个带有不同`UNIQUE_ID`的请求后，你需要一个健壮的系统来管理和关联这些回调。
- **信号的保真度**：`SSRFuzz`的DTA提供的信号保真度极高。它能**确定性地**告诉你：“参数`foo`的值，在第123行代码处，被传入了`curl_exec`函数”。而OOBI的信号则相对模糊：“服务器集群中的某台机器，在某个不确定的时间，查询了我的DNS记录”。这个DNS查询甚至可能是由其他服务（如日志分析、安全监控）触发的。### 结论：“硬弄一个创新点”？回到您最核心的那个问题，我认为答案是“**否**”。它不是“硬弄”，而是**从根本上改变了问题的解法**。- **盲目并发Fuzzing**：是一种**工程思维**的极致。它相信只要我的工具够快、机器够多、时间够长，就能用算力覆盖所有可能性。
- **DTA指导的Fuzzing**：是一种**科学/算法思维**的体现。它首先通过廉价的分析去**理解（Understand）系统的内部行为，然后基于这份理解去指导（Guide）后续昂贵的探索。它追求的是信息效率**，而不仅仅是**计算效率**。所以，总结来说，您是对的——对于一个API很少、参数结构简单的应用，Go并发小子弹跑全量确实可能够快，甚至更快。但`SSRFuzz`这类研究的价值在于，它提供了一个能够**优雅地扩展（scale up）到大型、复杂、未知应用的、具有方法论意义的框架**。在学术界，提出一个更具扩展性和根本性的**方法论**，其价值远高于对某个特定问题提出一个工程上的加速方案。这正是它能够成为顶会论文的核心原因。

我的分析：

  1. stage-1的找sink：私以为novelty不算很强
  2. SSRFuzz框架的思路设计，hook + taint 传播：novelty + efficiency✔️ （实际感觉工程比较简单是因为有zmark这个神器:) ）
  3. Real world Impact：这部分不好说，因为web application的漏洞太多了）16个CVEs似乎也不算很出色？

anyway，这只是技术层面的”拙劣“分析，还得看写作思路，叙事逻辑等。
但对我来说，这篇paper是个很好的introduction ：)

四、Deepest dive

既然zmark这么好用，既然LLM这么好用，那就来实操吧~

1. stage-1: 利用LLM parse PHP Manual找sink

大致思路就是：

  • 下载php manual文档
  • 对文档每个函数传给LLM（这里用的Gemini api）
  • 写好prompt，让LLM生成对应的SSRF探针似的demo代码
  • 运行，并利用callback 来验证

自己写了一下代码：https://github.com/N0zoM1z0/SSRFuzz/tree/main/stage-1
但第四步没有实际做）但这个stage主要是学学思路。
可扩展的思路还有：
对于协议让LLM读RFC，对于audit让LLM读Q&A等

2. 写一个SSRF之外的

这里写了个简单的SQLFuzz，
https://github.com/N0zoM1z0/SSRFuzz/tree/main/SQLFuzz

仿照SSRFuzz的模式写的，熟悉了整个流程

  • hook
  • taint propagate
  • callback verification

贴一下当时记录的文档：

模仿 SSRFuzz来

这里的sink“触发”检测需要动下脑筋，不能像ssrf那样很自然的用callback server来listen

发现SSRFuzz把zmark opcode和一些filter的hook都写好了）

现在基本实现了污点传播+检测，下面就是写个简单的fuzzer来联动了。

  1. 实现一个基本的fuzzer，detector ✔️
  2. 初始的taint点要存数据库，sink找到后需要回溯定位最开始传入的那个参数点 (还是先按SSRFuzz这种一次只处理一个参数点的开始做起) ✔️
  3. 语义分析，ast… # 可以做
  4. 二次验证，传入特定字符串进行检测，减少误报 canary injection # 没啥必要，sql查询字段很结构化，特定化
  5. 自动化的差分测试（正常请求和payload请求）# 没必要 这个就是sqlmap…
  6. hook sanitizer，当污点通过净化函数后，去标签 or 降等级 # 这个可以做下
  7. call stack analysis debug_backtrace存入数据库 # 可以做

[TODO]后续的一些想法：

  1. 语义分析，ast… # 可以做：
    （1）这里的话，感觉sqli没啥好创新的点，毕竟业界有sqlmap这种全面完备的tools了）用ast分析的话可以用来指导fuzzer.py的payload选取（引号闭合选择…），但有sqlmap其实这种做法意义不大）；（2）后面可以试着集成llm来分析query
  2. 感觉做sqli的这种分析不是很有新意）就当practice+熟悉工具+重温php了
  3. 后面跟crawlergo联动的时候，大致这种：标记为TODO，没什么创新，工程上的事情了
    1. 爬虫产生大量原始的http请求
    2. 框架拦截请求，对请求参数逐个遍历，单参数加上tag进行fuzzing
    3. 将crafted http request forward给server
    4. listen callback，fuzzing

总的来看，确实还是做不出什么很有创新性的成果，由于1day速成，也没有进行工程落地来跑实际的漏洞，就当自己的探索学习吧。
至少后面涉及到PHP的web application fuzzing的时候，我能有自信能够把工程代码写出来）

五、SSRFuzz可改进点

学习论文需要批判思考，要能够发现局限性

关于SSRFuzz，我目前发现的几个limitations：

  1. 只能单个parameter进行fuzzing，对于一些需要组合参数才能触发的逻辑是达不到的。
  2. 不支持POST（传post的时候数据库连接会有问题）
    这个后面没再分析了，不知道是环境的问题还是工具的bug）
    在这里插入图片描述

六、未来的方向

后面又看了很多web application fuzzing相关的，
印象比较深的有：

  1. atropos那篇用NYX-Snapshots来解决需要stateful fuzzing的问题；这篇paper还有一个很不错的点：跟AFL++的lto模式类似，atropos hook了compare，regex等函数，来提取出键值对，从而提升了fuzzing的覆盖率。（多好的一个idea，但已经被做力）悲）
  2. FuzzCache：这篇也很优秀。将php fuzzing时候的网络请求，I/O，数据库请求等都缓存下来，从根本上（程序执行的角度）极大提升了fuzzing速率。（优秀，这换我是真想不到，思路还是没打开）

所以感觉，纯做web application fuzzing，似乎不是很好找novelty了🤔
现在学术研究的切入点有：
a. 换更难的场景。比如fdu那篇关于Java微服务的跨application的静态分析
b. 做比较新/没有研究透的漏洞的广泛测量。

再者，就应该是些还没被想到，但具有颠覆性novelty的ideas了罢）


文章转载自：

http://oJRB3RIr.bqppr.cn
http://dgapqasM.bqppr.cn
http://JPobaEXe.bqppr.cn
http://E7U9ryGO.bqppr.cn
http://oDKxbeTZ.bqppr.cn
http://4RhadmfU.bqppr.cn
http://hDiu5vIk.bqppr.cn
http://pmfIA2kC.bqppr.cn
http://0uQP6oOI.bqppr.cn
http://fEqpc6Lp.bqppr.cn
http://xo4HAp8B.bqppr.cn
http://XxfZQcs4.bqppr.cn
http://0FuHzU00.bqppr.cn
http://QZsUmqaV.bqppr.cn
http://W8MARI7C.bqppr.cn
http://DVJCaqYK.bqppr.cn
http://FEt86iKI.bqppr.cn
http://DHVgYhxp.bqppr.cn
http://rwfF49ee.bqppr.cn
http://N3vpFaJi.bqppr.cn
http://b0PkUFYE.bqppr.cn
http://NhoDXjaQ.bqppr.cn
http://0SScMNeH.bqppr.cn
http://qOqpnI41.bqppr.cn
http://icgou46A.bqppr.cn
http://UnJX3nQs.bqppr.cn
http://NAqnQ7bw.bqppr.cn
http://wHDnXFJ4.bqppr.cn
http://pkdggijX.bqppr.cn
http://HybICOjI.bqppr.cn
http://www.dtcms.com/a/383169.html

相关文章：

  • 【算法】day2 双指针+滑动窗口
  • 拆解 AI 大模型 “思考” 逻辑：从数据训练到推理输出的完整链路
  • Axios在鸿蒙应用开发中的使用
  • Go高性能双端队列Deque实战指南
  • StringBuilder 深度解析：数据结构与扩容机制的底层细节
  • Altium Designer（AD24）自学资源介绍
  • cs144 lab0学习总结
  • Playwright MCP浏览器自动化指南
  • 经典俄罗斯方块游戏 | 安卓三模式畅玩，暂时无广告！
  • JVM调优常用命令
  • 文心快码Comate - 百度推出的AI编码助手
  • 做一个RBAC权限
  • Debian13下使用 Vim + Vimspector + ST-LINK v2.1 调试 STM32F103 指南
  • 临床研究三千问——临床研究体系的4个核心（9)
  • 高光谱成像在回收塑料、纺织、建筑废料的应用
  • LeetCode 2348.全0子数组的数目
  • OCSP CDN HTTPS OTA
  • 1.2.3、从“本事务读”和“阻塞别的事务”角度看 Mysql 的事务和锁
  • MySQL C API 的 mysql_init 函数深度解析
  • 第10课：实时通信与事件处理
  • 33.网络基础概念（三）
  • Spark专题-第一部分：Spark 核心概述（1）-Spark 是什么？
  • 使用buildroot创建自己的linux镜像
  • MapReduce核心知识点总结：分布式计算的基石
  • 当大模型走向“赛场”：一场跨越教育、医疗与星辰的AI创新马拉松
  • 2025年IEEE TCE SCI2区，不确定环境下多无人机协同任务的时空优化动态路径规划，深度解析+性能实测
  • Python 上下文管理器：优雅解决资源管理难题
  • 主流反爬虫、反作弊防护与风控对抗手段
  • C语言柔性数组详解与应用
  • 【C++】22. 封装哈希表实现unordered_set和unordered_map