[原创]踩楼有奖|看雪·2026 KCTF 征题中

发表于: 4天前 131

[原创]踩楼有奖|看雪·2026 KCTF 征题中

Editor

4天前

131

看雪·2026 KCTF 【防守方】规则发布（8月5日截止征题）

看雪CTF（简称KCTF）是圈内知名度最高的技术竞技之一，从原CrackMe攻防大赛中发展而来，采取线上PK的方式，规则设置严格周全，题目涵盖Windows、Android、iOS、Pwn、智能设备、Web等众多领域。

KCTF采取动态积分模式，使每道题的分数随着赛事的发展而变化，比赛结束的分数才能决定最终比赛结果。

看雪CTF比赛分为两个阶段：
第一阶段是防守篇，防守方根据比赛要求制作题目，根据题目在比赛中的得分评选优胜者。
第二阶段为攻击篇，攻击第一阶段的题目，攻击成功题目后获得相应的攻击得分。累计攻击方在每道题上的攻击得分以获得攻击方总得分，并评选优胜者。

既给了防守方足够的施展空间，也避免过度浪费攻击方的时间。从攻防两个角度看，都是个难得的竞技和学习机会。

KCTF比赛历史悠久、影响广泛。自2007年以来，看雪已经举办十多个比赛，与包括金山、腾讯安全、腾讯TSRC、360、阿里、京东、WiFi万能钥匙、安恒、深信服、众安科技等在内的各大公司共同合作举办赛事。比赛吸引了国内一大批安全人士的广泛关注，历年来CTF中人才辈出，汇聚了来自国内众多安全人才，高手对决，精彩异常，成为安全圈的一次比赛盛宴，突出了看雪论坛复合型人才多的优势，成为企业挑选人才的重要途径，在社会安全事业发展中产生了巨大的影响力。

2026年规则更新通知

为适应 AI 技术在安全研究、CTF 出题与解题中的应用发展，2026 年 KCTF 规则拟作如下更新：

一、新增 AI Security / LLM Security 题型

征题范围新增 AI 安全 / 大模型安全方向，包括但不限于 Prompt Injection、Jailbreak、RAG 安全、Agent 工具调用安全、模型与数据安全、AI 供应链安全、LLM 应用漏洞利用等相关题目。

AI Security / LLM Security 题目须保证可复现、可审计、可稳定判定，不得依赖不可控外部 AI 服务作为核心判题逻辑，相关题目须经组委会专项审核后方可参赛。

二、允许攻防双方使用 AI 工具

防守方和攻击方均可使用 AI 工具辅助出题、审计、分析、解题、脚本编写和 writeup 整理。

AI 工具仅作为辅助工具，使用方对 AI 生成或辅助生成的内容承担全部责任。使用 AI 不降低题目的原创性、安全性、稳定性、可复现性和可审计性要求，也不改变攻击方积分计算方式。

三、新增 AI 使用披露要求

防守方如使用 AI 工具辅助出题，应在提交材料中说明 AI 使用情况，包括 AI 参与环节、是否进行人工审核、是否包含 AI 生成代码或第三方内容等。组委会可根据审核需要要求补充说明。

四、明确 AI 使用边界

允许使用 AI Agent 或自动化脚本辅助分析，但不得对比赛平台、靶机或判题系统进行高频、无节制、破坏性或超出题目范围的自动化请求。

不得利用 AI 工具实施攻击比赛平台、破坏比赛环境、绕过平台权限、批量爆破、泄露 flag、共享答案、攻击非题目目标等违规行为。

五、优化部分规则表述

统一题型和平台名称表述，将 Windows、Android、Linux、IoT 等名称规范化；修正部分章节编号、年份表述和重复编号问题；扩展“多解/非预期解”的定义，使其适用于 CrackMe、Reverse、PWN、WEB、Crypto 及 AI Security / LLM Security 等题型。

2026年5月
KCTF竞赛组委会

一、活动时间

防守方出题：2026年4月2日～ 2026年08月05日（防守方题目准备阶段）
攻击方比赛：2026年08月10日～ 2025年09月10日（截止时间根据攻击方比赛情况而定）

二、活动地点

KCTF 官方网站：https://ctf.kanxue.com/

三、主办方及支持单位

主办方：
图片描述

四、防守方比赛赛制

本届 KCTF 团队赛为线上赛，由论坛会员自由组成攻、防两方团队，每个团队人数不超过 5 人。由防守方出题，攻击方夺旗。

1、防守方提交题目

参加防守的团队，每个团队需要提供一个防守题目到提交区：KCTF2026提交区(隐藏版块）。

评委审核通过后方可作为防守方参赛，审核结果在攻击赛开始前一天公布。

2、赛期

规则：顺序发题、弹性赛期。

防守题的赛期根据被破解情况决定，最少 1 天，最多 4 天。

一律中午 12 点发题。发题当天记作第 0 天。

若第 i 天上午 6 点该题被破解次数大于等于 $5^{3 - i}$ ，则在第 i 天中午 12 点结束该题，发下一题。

解释

发题后的第 1 天 6 点，若破解次数少于 25 人，则继续比赛；
发题后的第 2 天 6 点，若破解次数少于 5 人，则继续比赛；
发题后的第 3 天 6 点，若破解次数少于 1 人，则继续比赛；
以上任意一天继续比赛的条件不满足，就中午 12 点换下一题；
6 点至 12 点之间的破解，依然有效；发题后的第 4 天中午 12 点，此题一定结束。

3、积分规则

防守题积分分为难度值积分、火力值积分和精致度积分三种。在所有奖项评选中，若积分相同，则以提交题目时间来排序，最早提交题目的胜出。

攻击方积分是根据其破解战绩而计算得到的。

注：攻击者不能攻击自己提交的题目。

3.1 难度系数评估

基本原则

根据每道防守题的实际被破解时间、次数和多解，评价每道题的相对难度系数。
赛期内被发现多解的扣分，在此题赛期内直接生效。

计算方法

每道题的原始难度系数：原始难度系数 $= - lo g (k \cdot \sum \frac{1}{B _{i}} / T)$ 其中，k 是此题被破解的次数，Bi 是此题的被破解时间，i 从 1 到 k，T 是此题赛期（天数）。
将每道题的原始难度系数线性归一化到 [0,1]，即得到每道题的原始归一难度系数（此系数将用于攻击方计分）。
多解难度系数 = 原始难度系数 * $(M^{n})$ ,其中，M 为多解计算系数（87%），n 为在此题赛期内被发现的多解攻击方团队数量，n 大于 5 时，视同为 5。
将每道题的多解难度系数线性归一化到 [0,1]，即得到每道题的难度系数。（在比赛中，尚未被破解的题（含尚未开始比赛的题），暂计其难度系数为 1）。

解释

多解或非预期解，是指在某个问题或任务中，存在两个或更多个不同的flag，这些flag都能够满足问题或任务的要求；

被破解次数越少、被破解时间越长、被发现多解的个数越少、挺过赛期越久的防守题，其难度系数越大。
若被 1 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87%；
若被 2 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% = 原始难度系数 * 0.7569；
若被 3 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% * 87% = 原始难度系数 * 0.658503；
若被 4 个攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% * 87% * 87% = 原始难度系数 * 0.57289761；
若被 5 个及以上攻击方发现多解，则此题多解难度系数 = 原始难度系数 * 87% * 87% * 87% * 87% * 87% = 原始难度系数 * 0.4984209207。
难度系数是相对值，会随着比赛进行而变化。最简单的题难度系数为 0，最难的题为 1。比赛结束时将得到每道题的最终难度系数。

3.2 火力值积分

基本原则

火力值计分规则鼓励：既具有较高难度又适合于有限赛期的题。难度较高且在赛期之内能够被破解的题，将获得较高火力值积分。

计算方法

对每道题，分别计算每个破解者的攻击火力系数，得分在 [1,0) 之间：

攻击火力系数 = 此题一血时间 / 此攻击方破解此题的时间
对每道题，累计每个破解者的攻击火力系数之和，得到此题累计攻击火力系数。无人破解的题，累计攻击火力系数为 0。
根据每道题（除签到题以外）的归一化难度系数，计算所有破解者在此题上的火力值：

火力值 = 此题难度系数 * 累计攻击火力系数 * 100
根据每道题的火力值从高到低排序，评选本届比赛“火力焦点奖”。

解释

完全无人破解的题目，火力值为 0；
除签到题以外，最简单的题，其难度系数为 0，其火力值也为 0；
难度较高且有多人破解的题，会得高分。

3.3 难度值积分

基本原则

难度值计分规则鼓励：破解难度最高的题。它们代表着本届比赛的防守最高水平。

计算方法

出题难度值：

出题难度值 = (出题基本分 50 分 + 难度系数 * 难度加权分 150 分) * (1 + 一血加分系数)
若无人破解此题，则一血加分系数为 10%；若有人破解成功，则一血加分系数为 0。
根据每道题的难度值从高到低排序，评选本届比赛“最佳坦克奖”。

解释

最简单的题的出题难度值是：出题基本分；
最难的题是：出题基本分 + 难度加权分；
一血的定义是指：题目第一次被破解；若无人拿下此题一血，则此题获得额外 10% 加分。

3.4 精致度积分

基本原则

精致度计分规则鼓励：难度高且代码短的防守题。精致度反映了一道题的难度密度。
题目是以 CPU 指令构成的，或者用自定义语言编写且自带解释器的，可以参评。
用其它解释型语言编写的，不参评。
WEB 题不参与精致奖评定。
AI Security / LLM Security 题目是否参与精致奖评定，由组委会根据题目形态、题目包规模、核心逻辑和评审情况另行判定。

计算方法

防守题原始长度指标：

防守题原始长度指标 = log(在比赛中供攻击方下载的题目包的文件长度)
以 Byte 为单位。长度不足 1024B 的，计作 1024B。
将每道题的原始长度指标线性归一化到 [0,1]，即得到每道题的长度指标。
精致度积分 = 出题基本分 50 分 + (难度系数 * (1 - 长度指标)) * 450
根据每道题的精致度积分从高到低排序，评选本届比赛“精致奖”。

解释

具有一定难度且代码较短的题目，会得到较高精致度积分；
攻击方下载的题目包可以是压缩的，压缩格式为 ZIP 或 RAR，由参赛者提供；
题目下载包必须包含题目正常运行所需所有文件；
比赛规则已经指定了多款 OS 作为运行平台。若题目需要其它软件支持，必须将其带入到题目包中。例如：题目需要一个特殊的 lib，则需要带上这个 lib。

3.5 攻击方积分

基本原则

攻击方计分规则鼓励：破解高难度题目最多最快的团队。他们代表着本届比赛的攻击最高水平。

计算方法

攻击方在某一道题上的得分：

攻击方得分 = (出题基本分 50 分 + 此题原始归一难度系数 * 难度加权分 150 分) * (此题一血时间 / 此攻击方破解此题的时间 + 1) / 2 * (1 + 一血加分系数)
攻击方总积分 = 攻击方在其破解的每道题上的得分之和。

解释

若攻击方是此题的一血破解者，将获得此题出题难度值的 10% 的额外加分。
其他破解者无一血加分，且得分依破解时间递减，理论上最少将获得此题出题难度值的一半。
如果未破解此题成功，则在此题上不得分。
攻击者在某题上的得分，不因此题出现多解而受影响。
攻击方是否使用 AI 工具辅助分析、解题、脚本编写或 writeup 整理，不影响积分计算，仍以提交正确 flag、注册码、序列号或其他有效解题结果的时间为准。

五、征题说明

1、征题范围

CrackMe/Reverse（Windows、Android、Linux、IoT 等）、PWN、WEB、Crypto、AI Security / LLM Security 等相关题目。
注：自 2023 年起，不接受 Misc 类题型。

AI Security / LLM Security 题目包括但不限于 Prompt Injection、Jailbreak、RAG 安全、Agent 工具调用安全、模型与数据安全、AI 供应链安全、LLM 应用漏洞利用等方向。该类题目须保证可复现、可审计、可稳定判定，不得依赖不可控外部 AI 服务作为核心判题逻辑，相关题目须经组委会专项审核后方可参赛。

2、征题数量

将从征集的题目里抽选出一定数量较为优秀的题目来参与 KCTF 赛，其他符合规则的题目将录入平台数据库备用。

3、征题期限

2026年4月2日～ 2026年08月05日

4、征题要求

1）原创性要求

所有题目必须是原创并且没有公开过。

使用 AI 辅助生成的题目，仍须满足原创且未公开要求。不得直接提交公开题、历史题、他人题目、训练语料中高度相似的题目，或未经授权的第三方代码、素材和数据。

AI 生成或辅助生成的内容一旦提交参赛，视同防守方自行设计和编写，由防守方承担全部责任。

2）防守方提交内容

防守方应打包提交以下内容：

团队名称；
团长 QQ；
参赛题目；
题目答案（攻击脚本）；
详细的题目设计说明；
破解思路；
其他需要说明的问题；
AI 使用说明。

提交资料不完整的不予通过。

3） AI 使用说明

若防守方使用 AI 工具辅助出题、写代码、生成题面、生成 writeup、编写 exp、检查非预期或进行其他相关工作，应在提交材料中补充 AI 使用说明。

AI 使用说明建议包括：

是否使用 AI 工具；
使用的 AI 工具或模型名称，可概括填写；
AI 参与的环节，例如题目构思、代码生成、混淆、writeup、exp、测试、非预期检查等；
是否对 AI 生成内容进行了人工审核；
是否包含第三方代码、开源代码或 AI 生成代码；
是否完成安全性、原创性、可复现性和非预期解检查。

组委会可根据审核需要，要求防守方补充提供 AI 参与环节、代码来源、人工审核记录、测试记录或其他必要说明。

未如实披露并造成题目泄露、非原创、不可复现、安全风险或比赛公平性问题的，组委会有权取消题目资格或调整成绩。

4）提交入口

题目提交到看雪 CTF 提交区：KCTF2026提交区（隐藏版块）

5、题目规则

Android、Linux、IoT 逆向题的设计规则，请参考 Windows 逆向题规则。

5.1 关于 Windows 平台 CrackMe 设计规则

Windows 平台题目规则有两个方案，参赛者可以任选一种方案来出题参赛。

如果选手采用方案二参赛，必须在提交题目时明确参赛模式，否则默认以方案一模式参赛。

提交格式

├─Readme.md------------|题目描述文档
├─Writeup.md-----------|writeup
├─attachments----------|题目文件
├─src------------------|源文件
└─files----------------|writeup包含的图片等文件

5.1.1 Windows 方案一

5.1.1.1 关于注册码

1）CrackMe 应有且仅有唯一注册码，除给定的注册码外。如果 CrackMe 被发现多解，则根据积分规则扣分。CrackMe 的注册码字符集限定为 ['!','~']，即 ASCII 码范围是 [33,126]，共 94 个可选字符。不允许将注册码绑定硬件 ID。

2）CrackMe 界面

参赛 CrackMe 界面必须有且仅有注册码输入项，例如类似的界面，界面仅供参考，可以是控制台。

┌────────────────────────────────────┐
│        ┌──────────────┐            │
│ Serial └──────────────┘            │
│             KCTF 2026              │
└────────────────────────────────────┘

3）CrackMe 输入

CrackMe 在没有被附加调试的情况下运行时，第一次运行时输入正确注册码，必须显示成功提示信息。若是重启验证的，在重启后必须显示。
在 CrackMe 没有被改动且没有被其他程序干扰的情况下，只要输入了注册码，显示了成功信息，则认为该注册码是正确的，否则设计不合理。

4）CrackMe 输出显示

注册成功，要出现成功提示信息。
CrackMe 里不允许出现虚假的注册成功提示信息。

5.1.1.2 算法规则

1）不鼓励穷举

在当前技术条件下，序列号从理论上讲，是可逆或可求出来的。
如果破解者必须通过穷举才能得到注册码，设计文档里一定要描述清楚，并且将穷举代码和程序发给评委验证。评委验证时，在当前主流硬件配置条件下，如果穷举时间超过 30 分钟则不通过。
如果在当前主流硬件配置条件下，CrackMe 的启动时间超过 10 秒也不通过，需要返回修改。

2）其他限制条件

参赛 CrackMe 必须可以在 Windows 11/64、Windows 11/32、Windows 10/64、Windows 10/32 其中一种系统正确运行。推荐优先支持 Windows 11/64 或 Windows 10/64。原则上不再将 Windows 7 和 Windows XP 作为默认支持平台。
参赛 CrackMe 不可使用第三方保护工具来保护 CrackMe，例如第三方壳和 VM。
参赛 CrackMe 不可使用 VM 来保护，包括第三方 VM 和自己写的 VM。（注：若要用自己实现 VM 参赛，请按 Windows 方案二规则提交题目。）
参赛 CrackMe 执行后，不能干扰破解者正常使用电脑。比如关闭显示器、禁用键盘鼠标、关机、暴力占用内存或 CPU 资源使电脑死机、破坏电脑文件等类似操作不允许，但允许采用技术手段关闭调试器，防止破解者破解。
参赛 CrackMe 设计的总体原则是绿色安全，不可含木马或 rootkit，没有任何危险或恶意程序，不能对系统进行破坏，可以正常结束，结束后不能给系统留下垃圾。比如临时文件要删除，驱动要卸载干净，不可使系统重启。
参赛 CrackMe 如果有任何危险或者恶意行为，ban ID。如果有杀软或者 360 等安全软件报 CrackMe 有异常行为，评委有权要求参赛选手解释。
参赛 CrackMe 不可以联机到网络，或使用服务器注册，CrackMe 必须可以在单机运行。
所提交的参赛 CrackMe 运行文件包括 .exe、.dll、.sys 等，在不打包压缩时总大小不超过 1M。
如果评审有怀疑，例如怀疑加壳伪装，可以要求队伍提供 CrackMe 的源码。
如果评审认为 CrackMe 使用了不合理的设计，或违反比赛精神，便会判定 CrackMe 无效，取消奖品和名次，并把参赛者提交的技术文件在论坛公开，让会员公开讨论。

5.1.2 Windows 方案二

5.1.2.1 关于用户和序列号

1）防守方发布的 CrackMe 应允许输入用户名和序列号，并提示用户名和序列号是否匹配正确。界面仅供参考，可以是控制台。

┌────────────────────────────────────┐
│        ┌──────────────┐            │
│ name   └──────────────┘            │
│        ┌──────────────┐            │
│ Serial └──────────────┘            │
│           KCTF 2026                │
└────────────────────────────────────┘

2）用户名和序列号要求

防守方在发布 CrackMe 时，应向大众公开一组用户名和序列号，即 “Name/Serial”。
其中公开的这个用户名 “Name”，必须是该 CrackMe 文件的 hash 值。
hash 算法指定为 SHA256，用户名为 hash 结果的前 64bit 的 16 进制大写文字。例如：参赛 CrackMe.exe 文件的 hash 结果是50be38745d82d93f3a974701e86c1cafcbc2ec83d1f1913d216079022ba7317f
则用户名 “Name” 应为：50BE38745D82D93F
如果 CrackMe 不止一个文件，计算 hash 时应包含 CrackMe 的所有文件，第三方共享库除外。参考 hash 计算工具：f9cK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6W2L8h3^5I4y4K6S2Q4x3X3g2Y4K9i4c8Z5N6h3u0Q4x3X3g2A6L8#2)9J5c8X3!0F1L8r3W2F1k6g2)9J5k6s2c8G2L8$3I4K6i4K6u0r3M7$3S2S2x3U0f1$3i4K6g2X3j5$3S2W2j5$3E0K6N6h3#2Q4x3X3g2Z5N6r3#2D9

B）判胜条件

若攻击方找出特定用户名 “KCTF”（不含引号）的序列号，经 KCTF 系统自动确认，将认定攻击方获胜。
若攻击方找出特定用户名 “KCTF”（不含引号）的第二个序列号，经 KCTF 官方确认，将认定攻击方获胜，且此题多解。

C）规则限制

干净环境中，当前主流硬件配置环境下，20 秒内出提示且不能虚假提示。(2026年更新）
KeyGen 算法不能基于“未在 CrackMe 中公开的秘密信息”。如果需要穷举，则穷举时间在目前主流机型中必须小于 30 分钟。
不能依赖网络，不能依赖硬件。
禁止使用第三方保护工具，禁止恶意破坏机器。
参赛 CrackMe 允许用自己未公布的壳或 VM 或其他手工处理的方法来保护程序（VM 或壳的嵌套最多 2 层），但必须将保护该 CrackMe 所使用的壳或 VM 或其他手工处理的方法与 CrackMe 一同提交，评委审核通过后方可参赛。
所提交的壳或 VM 程序和源码，或其他手工处理的方法，将在赛后向广大会员公开。凡违反该比赛规则的 CrackMe 将作废，设计该 CrackMe 的会员将取消本届比赛的参赛资格。
关于 VM 定义：所有掩盖原始程序、以解释方式执行的保护方式都可统称 VM。比如 Java VM 也算 VM，其它模拟器也算 VM。赛题中，壳内壳外的所有 VM 加起来，不要超过 2 层。
所提交的参赛 CrackMe 运行文件包括 .exe、.dll、.sys 等，在不打包压缩时总大小不超过 10M。
同一用户名不应有多个序列号，否则根据积分规则扣分。
禁止在 CrackMe 中为特定用户名 “KCTF” 设立独立验证路径，以绕开 hash 用户名的验证路径。
序列号字符集限定为 ['!','~']，即 ASCII 码范围是 [33,126]，共 94 个可选字符。
不限制使用套娃。可以使用任何数据和代码变换。
不限制线索隐藏方式。可以将线索以任何形式置于 CrackMe 的任何位置。

5.2 关于 Android/iOS 平台 CrackMe 设计规则

参考 5.1 Windows 平台规则（方案一和方案二），确保 CrackMe 能在常见移动端稳定运行。

5.3 关于 PWN 的设计规则

CTF 中的 PWN 是一个关于二进制漏洞挖掘与利用的方向。通过对二进制程序进行逆向分析，挖掘程序中存在的漏洞并进行漏洞利用，最终获取目标主机的 shell 或读取 flag。

5.3.1 题目规则

1）规则

设计一个存在漏洞的程序。
漏洞包括但不限于堆栈溢出、UAF、DOUBLE FREE、OFF BY ONE、格式化字符串、逻辑错误等漏洞。
提供稳定的漏洞利用 EXP，攻击者根据漏洞攻击成功后能获得 flag，flag 格式为：flag{***}
题目提供二进制附件，或以 Docker 形式提交，并提供详细的部署方法。

2）其他限制条件

尽量不要出带有爆破、猜测的题目，避免比赛选手使用爆破工具给服务器带来较大压力。
控制解题流程，避免非预期。

带* 有文件上传或者代码执行的题目，要控制好权限，避免环境被破坏。

PWN 文件允许用自己未公布的壳或 VM 或其他手工处理的方法来保护程序（VM 或壳的嵌套最多 2 层），但必须将保护该 PWN 文件所使用的壳或 VM 或其他手工处理的方法与 PWN 附件一同提交，评委审核通过后方可参赛。
所提交的壳或 VM 程序和源码，或其他手工处理的方法，将在赛后向广大会员公开。凡违反该比赛规则的 PWN 题将作废，设计该 PWN 题的会员将取消本届比赛的参赛资格。
关于 VM 定义：所有掩盖原始程序、以解释方式执行的保护方式都可统称 VM。比如 Java VM 也算 VM，其它模拟器也算 VM。赛题中，壳内壳外的所有 VM 加起来，不要超过 2 层。
PWN 主文件尺寸不超过 10M。

5.3.2 提交格式

├─Readme.md--------------|题目描述文档
├─Writeup.md-------------|writeup
├─exp--------------------|解题关键脚本
├─attachments------------|题目文件
├─deploy-----------------|online型题目部署脚本
│  └─docker_for_pwn-------|pwn题示例
│     │  Dockerfile
│     │  xctf.xinetd
│     │
│     └─bin
│             pwn
│             flag
│
└─files------------------|writeup包含的图片等文件

Dockerfile：基于官方 Docker 镜像生成后需要部署的内容，并且暴露对应端口使用。
attachments：提供给选手分析使用的相关文件。

5.3.3 公开给选手文件

防守方应公开题目运行和分析所需的必要文件，包括题目可运行 Docker 环境，或完整 Dockerfile、启动脚本、attachments 及相关配置文件。
公开文件应尽量与线上比赛环境保持一致，使攻击方能够在本机或本地 Docker 环境中复现题目环境，完成运行、调试和 EXP 验证。
如题目依赖特定系统版本、架构、运行库、环境变量、端口或启动参数，应在 Readme.md 中明确说明。
若线上环境与公开文件存在差异，防守方应明确标注；因环境差异导致题目无法复现或影响解题的，组委会有权要求补充材料、调整题目或判定题目无效。

5.4 关于智能硬件 PWN 设计规则

题目设计规则：

设计一个可以运行于模拟器如 qemu 中基于 uboot 的 arm32 位程序。
该程序能够通过 uboot 引导并稳定执行。
该程序可设计为存在漏洞程序、CrackMe 程序等。
参赛者可以解题成功后获得：flag{*********}
设计者需提供可以运行设计程序的 qemu 版本信息，以及让 uboot 成功运行起来的必要信息，如模拟的目标板、内存等。
设计者还需要提供已经设计好的 uboot 二进制文件、比赛程序、解题思路及答案。

5.5 关于 WEB 题目设计规则

1）规则

设计一个存在 WEB 漏洞的 WEB 程序。
漏洞包括但不限于注入、命令执行、文件上传等漏洞。
攻击者根据漏洞攻击成功后能获得 flag，flag 格式为：flag{***}
题目以 Docker 形式提交，并提供详细的部署方法。
WEB 题不参与精致奖评定。

提交格式

│  Readme.md-------------|题目描述文档
│  Writeup.md------------|writeup
├─attachments------------|题目文件
├─deploy-----------------|online型题目部署脚本
│  │
│  └─docker_for_web-------|web题示例
│      │  Dockerfile
│      │  run.sh
│      │
│      └─bin
│  index.php
└─files------------------|writeup包含的图片等文件

2）其他限制条件

尽量不要出带有爆破、猜测的题目，避免比赛选手使用爆破工具给服务器带来较大压力。
控制解题流程，避免非预期。
带有文件上传或者代码执行的题目，要控制好权限，避免环境被破坏。

5.6 关于 Crypto 题目设计规则

密码学方向的考题在 CTF 中被归为 Crypto 类型，主要目标是找出隐藏在密码学算法中的 flag。
题目应提供完整题面、必要附件、解题思路、答案和验证方式。
Crypto 题目应避免仅依赖大规模爆破或不可复现随机性。若题目涉及随机数、密钥生成、参数生成或交互式服务，应确保题目环境稳定、结果可验证、解题路径明确。

5.7 关于 AI Security / LLM Security 题目设计规则

AI Security / LLM Security 题目，是指以人工智能系统、大语言模型应用、智能 Agent、RAG、模型接口、提示词工程或 AI 应用安全缺陷为主要攻击对象或核心解题要素的题目。

该类题目应遵循 CTF 基本判定方式：攻击方通过利用题目中设计的 AI 安全问题，最终获得明确的 flag 或其他可验证结果。

flag{***}

题目不得仅以“说服模型”“让模型输出某类内容”“完成某种对话效果”等主观结果作为唯一判定标准，必须能够通过明确结果进行判定。

AI Security / LLM Security 题目须保证可复现、可审计、可稳定判定。原则上不得依赖不可控的外部在线 AI 服务、商业模型接口或会随时间变化的远程模型能力作为核心判题逻辑。确需使用的，须提前向组委会说明，并经审核通过。

5.7.1 题目方向

AI Security / LLM Security 题目包括但不限于以下方向。各方向均应围绕明确的 CTF 判定目标设计，攻击方通过完成对应攻击路径，最终获得 flag{***} 或其他可验证结果。

1）Prompt Injection / Jailbreak

包括但不限于：

绕过系统提示词限制；
诱导模型泄露隐藏信息；
间接提示词注入；
多轮对话上下文污染；
利用提示词边界错误获取 flag。

2）RAG / 知识库安全

包括但不限于：

隐藏文档泄露；
越权查询；
检索污染；
向量数据库信息泄露；
知识库权限隔离失败。

3）Agent / Tool Calling 安全

包括但不限于：

工具调用越权；
文件读取；
SSRF；
命令执行；
Agent 权限过大；
多工具调用链攻击。

4）AI 应用与传统漏洞结合

包括但不限于：

LLM 应用中的 WEB 漏洞；
AI 助手插件漏洞；
RAG 系统中的权限绕过；
Agent 调用链中的文件读取、命令执行、SSRF 等；
AI 应用与 PWN、WEB、Crypto 等传统方向结合的组合题。

这类题目可根据核心考点归入 AI Security / LLM Security 或传统 WEB/PWN/Crypto 题型。若核心解题点主要围绕 AI 应用安全，则建议归入 AI Security / LLM Security。

5.7.2 题目规则

设计一个以 AI 系统、大模型应用、智能 Agent、RAG 系统、模型接口或 AI 应用安全缺陷为核心攻击对象的题目。

攻击者根据题目目标成功完成攻击后，应能获得明确的 flag 或其他可验证结果。

题目应提供完整题面、部署方式、运行环境、验证方式、解题思路和答案。

题目建议以 Docker 或其他可复现形式提交。若使用本地模型、模拟模型服务、向量数据库、知识库或工具调用环境，应一并提供完整部署方法和依赖说明。

5.7.3 可复现与判题要求

AI Security / LLM Security 题目必须保证结果稳定、环境可复现。

防守方应提供完整部署环境、必要数据、配置文件、判题逻辑和测试样例，确保题目在赛期内可以稳定运行和验证。

若题目涉及模型输出，应尽量通过固定环境、固定参数、固定提示词、固定上下文、固定随机种子或 mock 服务等方式降低不确定性。

题目不得仅依赖模型随机输出或主观判断作为判题依据。

5.7.4 外部服务与安全限制

AI Security / LLM Security 题目原则上不得依赖不可控的外部在线 AI 服务作为核心判题逻辑。

确需使用外部模型或在线服务的，须提前向组委会说明，并经审核通过。

题目应在隔离环境中运行，不得要求攻击真实第三方 AI 服务、绕过真实平台安全策略、窃取真实用户数据或生成现实恶意内容。

题目中使用的文档、知识库、训练数据、日志、对话记录等内容不得包含真实个人隐私、真实账号凭证、真实商业秘密或未经授权的数据。

题目应控制请求频率、上下文长度和资源消耗，避免攻击方通过高频调用、爆破或自动化 Agent 对平台造成过大压力。

5.7.5 提交格式

├─Readme.md--------------|题目描述文档
├─Writeup.md-------------|writeup
├─exp--------------------|解题关键脚本或说明
│
├─attachments------------|提供给选手分析使用的题目文件
├─deploy-----------------|题目部署脚本
│  └─docker_for_ai--------|AI题示例
│     │  Dockerfile
│     │  run.sh
│     │
│     ├─app--------------|题目服务代码
│     ├─data-------------|知识库、测试数据或题目数据
│     └─config-----------|固定参数、提示词、策略配置等
│
└─files------------------|writeup包含的图片等文件

如题目使用本地模型、mock 模型服务或固定输出服务，应在 Readme.md 中说明运行方式，并提供必要文件和测试方法。

5.7.6 奖项和积分说明

AI Security / LLM Security 题目参与攻击方积分、难度值积分和火力值积分。

AI Security / LLM Security 题目是否参与精致奖评定，由组委会根据题目形态、文件规模、核心逻辑和评审情况另行判定。

六、AI 工具使用规则

6.1 AI 使用总原则

本届比赛允许防守方和攻击方使用 AI 工具辅助出题、审计、分析、解题、脚本编写和 writeup 整理。

AI 工具仅作为辅助工具，使用方对 AI 生成或辅助生成的内容承担全部责任。

使用 AI 不降低题目的原创性、安全性、稳定性、可复现性和可审计性要求，也不改变攻击方积分计算方式。

6.2 防守方使用 AI 的要求

防守方可以使用 AI 工具辅助以下工作：

题目创意设计；
代码生成或代码优化；
混淆逻辑设计；
题面文案编写；
Readme 编写；
Writeup 编写；
EXP 或攻击脚本编写；
非预期解检查；
安全性检查；
部署脚本编写。

但 AI 只能作为辅助工具。防守方对最终提交题目的原创性、安全性、稳定性、可解性、可审计性和合规性承担全部责任。

使用 AI 生成或辅助生成的代码，视同防守方自行编写代码，必须满足源码审计、恶意行为排查、环境复现和赛后公开要求。

组委会有权要求防守方补充说明相关代码来源、生成方式和人工审核情况。

6.3 攻击方使用 AI 的要求

攻击方可以使用 AI 工具辅助解题，包括但不限于：

逆向分析；
代码审计；
漏洞分析；
EXP 编写；
脚本编写；
Crypto 分析；
WEB 漏洞分析；
PWN 思路辅助；
题目理解；
Writeup 整理；
自动化分析辅助。

攻击方是否使用 AI，不影响攻击方积分计算。

攻击方成绩仍以提交正确 flag、注册码、序列号或其他有效解题结果的时间为准。

6.4 AI Agent 和自动化工具限制

允许使用 AI Agent 或自动化脚本辅助分析，但不得对比赛平台、靶机或判题系统进行高频、无节制、破坏性或超出题目范围的自动化请求。

组委会可根据流量、日志、请求频率和实际影响判定是否违规。

使用 AI 工具不得突破原有比赛边界。凡通过 AI 实施或辅助实施攻击比赛平台、破坏靶机环境、批量爆破、越权访问、泄露 flag、共享答案、攻击非题目目标等行为，均按违规处理。

6.5 AI 使用披露和审计

防守方使用 AI 辅助出题的，应在提交材料中说明 AI 使用情况，包括 AI 参与环节、是否进行人工审核、是否包含 AI 生成代码或第三方内容等。

不强制防守方公开完整 prompt 或完整 AI 对话记录，但组委会在审核需要时，可以要求防守方补充说明。

攻击方通过 AI 工具获得的分析结果、脚本、payload 或答案，由攻击方自行负责。若 AI 输出内容涉及违规攻击、答案泄露、他人 writeup、非授权资料或其他违规来源，攻击方不得以“AI 生成”为由免责。

6.6 AI 相关禁止行为

参赛队伍不得利用 AI 工具获取、整理、传播或使用非公开题目、flag、writeup、源码、评审资料、其他队伍解题材料等信息。

无论相关信息是否由 AI 工具生成、总结或提供，一经确认均按违规处理。

禁止利用 AI 工具实施以下行为：

攻击比赛平台；
破坏比赛环境；
绕过平台权限；
批量爆破；
攻击非题目目标；
泄露他人信息；
共享答案；
获取或传播非公开 flag、writeup、源码、评审资料；
使用泄露渠道获得答案；
其他违反比赛公平性和安全边界的行为。

6.7 AI 相关泄露责任

因使用 AI 工具导致题目、flag、源码、攻击脚本、账号凭证、评审资料或其他比赛敏感信息泄露的，由使用方自行承担责任。

造成比赛公平性影响的，组委会有权取消参赛资格、取消题目资格、调整成绩或作出其他处理。

6.8 组委会解释权

AI 工具、AI Agent、AI Security / LLM Security 题型及相关技术发展较快。对于规则未覆盖的新情况，组委会有权根据比赛公平性、安全性、可复现性和比赛精神作出解释和处理。

六、评委团队

评委成员：kanxue、gjden、Editor

七、奖项&奖品

本次比赛设置3类奖项：

最能抗的：最佳坦克奖
实际吸收伤害最多的：火力焦点奖
题目短小并且最能抗的：精致奖

7.1 防守方奖项

防守方奖项设3类：最佳坦克奖、火力焦点奖、精致奖（*奖品价值：最佳坦克奖>火力焦点奖>精致奖）
同一战队获奖类型，不可重复。若已获得靠前类别奖项，则不参与后续的评定。

解释：

若获得最佳坦克奖，则不参与火力焦点奖、精致奖评定
若获得火力焦点奖，则不参与精致奖评定
同时，该类别奖项将按名次顺延给下一战队。

最佳坦克奖：

大疆【张雪同款】DJI Osmo 360 运动相机 b35K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6N6r3g2E0i4K6u0W2K9X3c8Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6l9J5z5e0b7$3x3o6V1#2x3U0c8Q4x3X3g2Z5N6r3#2D9
图片描述

火力焦点奖：

布鲁克斯（BROOKS）Ghost幽灵Max3男子缓震支撑跑鞋 631K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6N6r3g2E0i4K6u0W2K9X3c8Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6l9J5y4o6f1%4y4K6l9^5y4o6u0Q4x3X3g2Z5N6r3#2D9
图片描述

精致奖：

索尼（SONY）Float Run 非入耳开放式运动耳机 9c5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6N6r3g2E0i4K6u0W2K9X3c8Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6l9H3y4o6b7^5y4o6R3$3y4K6u0Q4x3X3g2Z5N6r3#2D9
图片描述

7.2 攻击方奖项

根据攻击方获得的 “3.5 攻击方积分”进行排名，取前一、二、三名，分别对应一等奖、二等奖、三等奖。

一等奖：攻击方第1名

大疆【张雪同款】DJI Osmo 360 运动相机 a4fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6N6r3g2E0i4K6u0W2K9X3c8Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6l9J5z5e0b7$3x3o6V1#2x3U0c8Q4x3X3g2Z5N6r3#2D9
图片描述

二等奖：攻击方第2名

布鲁克斯（BROOKS）Ghost幽灵Max3男子缓震支撑跑鞋 240K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6N6r3g2E0i4K6u0W2K9X3c8Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6l9J5y4o6f1%4y4K6l9^5y4o6u0Q4x3X3g2Z5N6r3#2D9
图片描述

三等奖：攻击方第3名

索尼（SONY）Float Run 非入耳开放式运动耳机 b87K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6A6N6r3g2E0i4K6u0W2K9X3c8Q4x3X3g2U0L8$3#2Q4x3V1j5I4x3o6l9H3y4o6b7^5y4o6R3$3y4K6u0Q4x3X3g2Z5N6r3#2D9
图片描述

7.3 幸运奖

防守方（未得奖战队）+攻击方（4-10名）

奖品：看雪·2026 定制周边T恤（每个战队1件）

KCTF 2026 组委会

2026/05/07

踩楼有奖！！！！

奖品：第十届安全开发者峰会（2026 SDC）早鸟票1张

参与方式：下方留言你对2026 KCTF的建议、看法、想法等，若所踩楼层与系统内置的中奖楼层匹配上，立即显示中奖。

注意事项：

每个ID只能获得一次奖励，踩楼帖只能回复一帖。

严禁用马甲参与活动，一经发现视为放弃参

传播安全知识、拓宽行业人脉——看雪讲师团队等你加入！

最后于 4小时前被kanxue编辑，原因：

收藏・0

免费・0

支持

幸运楼层： ??????????

最新回复 (0)
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

Editor

2622

发帖

5453

回帖

145

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

[原创]踩楼有奖|看雪·2026 KCTF 征题中

看雪·2026 KCTF 【防守方】规则发布（8月5日截止征题）

2026年规则更新通知

一、活动时间

二、活动地点

三、主办方及支持单位

四、防守方比赛赛制

1、防守方提交题目

2、赛期

解释

3、积分规则

3.1 难度系数评估

基本原则

计算方法

解释

3.2 火力值积分

基本原则

计算方法

解释

3.3 难度值积分

基本原则

计算方法

解释

3.4 精致度积分

基本原则

计算方法

解释

3.5 攻击方积分

基本原则

计算方法

解释

五、征题说明

1、征题范围

2、征题数量

3、征题期限

4、征题要求

1） 原创性要求

2）防守方提交内容

3） AI 使用说明

4）提交入口

5、题目规则

5.1 关于 Windows 平台 CrackMe 设计规则

提交格式

5.1.1 Windows 方案一

5.1.1.1 关于注册码

5.1.1.2 算法规则

1）不鼓励穷举

2）其他限制条件

5.1.2 Windows 方案二

5.1.2.1 关于用户和序列号

B）判胜条件

C）规则限制

5.2 关于 Android/iOS 平台 CrackMe 设计规则

5.3 关于 PWN 的设计规则

5.3.1 题目规则

1）规则

2）其他限制条件

5.3.2 提交格式

5.3.3 公开给选手文件

5.4 关于智能硬件 PWN 设计规则

5.5 关于 WEB 题目设计规则

1）规则

提交格式

2）其他限制条件

5.6 关于 Crypto 题目设计规则

5.7 关于 AI Security / LLM Security 题目设计规则

5.7.1 题目方向

1）Prompt Injection / Jailbreak

2）RAG / 知识库安全

3）Agent / Tool Calling 安全

4）AI 应用与传统漏洞结合

5.7.2 题目规则

5.7.3 可复现与判题要求

5.7.4 外部服务与安全限制

5.7.5 提交格式

5.7.6 奖项和积分说明

六、AI 工具使用规则

6.1 AI 使用总原则

6.2 防守方使用 AI 的要求

6.3 攻击方使用 AI 的要求

1）原创性要求