AI for Mission-critical Security (AIMS) Lab

Recent Research Interests

LLM for Security

We explore how large language models can enhance security analysis and automate traditionally labor-intensive security tasks. Our research focuses on vulnerability discovery, program understanding, security reasoning, and automated security testing by combining LLMs with program analysis and domain-specific security knowledge.

Featured Project
SAGE: Signal-Amplified Guided Embeddings for Vulnerability Detection
🧠 LLM for Security × Vulnerability Detection
LLM for Security

SAGE: Recovering the Vulnerability Signals Hidden Inside LLMs

What if an LLM actually “sees” the vulnerability, but the signal is simply too faint to affect its final decision? We identify a fundamental bottleneck in LLM-based vulnerability detection called Signal Submersion: vulnerability-related features are activated inside the model, yet become numerically overwhelmed by dominant functional semantics as information flows through deeper layers. To recover these hidden signals, we develop SAGE, which probes intermediate representations and uses task-conditional Sparse Autoencoders to isolate and amplify vulnerability-relevant features while keeping the LLM backbone frozen. The result: up to 12.7× higher internal signal-to-noise ratio, 318% MCC gains on unseen distributions, and a 7B model outperforming 34B baselines. Sometimes, better vulnerability detection does not require a bigger model—it requires helping the model hear the signal it already has.

12.7× Higher Internal SNR
+318% MCC Gain on Unseen Distributions
7B > 34B Smaller Model Beats Larger Baselines
SAGE 漏洞:“我明明在这儿!” 模型:“啊?没听见。”

一段几百行的代码里, 可能只有那么一两处细微差别真正决定了 “安全”还是“有漏洞”。 问题是,正常代码实在太多了—— 函数功能、变量关系、控制逻辑全在疯狂刷存在感, 真正关键的漏洞信号反而像在人群里小声喊了一句: “这里有 Bug!” 然后……被淹没了。🙂

我们发现,这并不一定意味着 LLM “完全没学会漏洞”。 很多时候,漏洞相关特征其实已经在模型内部出现, 只是到了深层之后, 被大量正常功能语义压得越来越弱—— 我们把这个现象叫做 Signal Submersion

所以 SAGE 干的事情不是继续无脑 “把模型做大”, 而是深入模型内部, 把这些快要沉底的漏洞信号 捞出来、分离出来,再放大。 最终内部信噪比最高提升 12.7×, unseen distribution 上 MCC 最高提升 318%, 一个 7B 模型甚至可以超过 34B baseline, 并在 13 种编程语言上展现跨语言能力。

🔍 一句话总结: The vulnerability signal was not missing—it was submerged.
与其一味让模型 “长更大的脑子”, 不如先帮它把真正重要的那句话 听清楚。
LLM for Security Vulnerability Detection Sparse Autoencoder Mechanistic Interpretability Software Security
Featured Project
The Imitation Game
🎭 LLM for Security × Cybercrime Disruption
LLM for Security

The Imitation Game: What If the “Victim” Is Actually an AI?

Chat-based scams survive on one simple assumption: the person on the other side is a real potential victim. What if that assumption could no longer be trusted? We introduce LURE, an LLM-powered adversarial engagement system that turns language models from passive scam detectors into active participants inside cybercrime ecosystems. LURE discovers illicit chat communities, identifies suspected service providers, and uses human-like LLM agents to engage them in realistic multi-round conversations while extracting operational intelligence such as pricing, payment methods, QR codes, and migration tactics. In a real-world study spanning 98 Telegram groups and channels, LURE engaged 53 active actors, with 56.6% of interactions progressing naturally without the LLM being exposed as a bot. But the bigger idea goes beyond intelligence collection: if cybercriminals cannot reliably tell real victims from artificial ones, deception itself becomes more expensive, less efficient, and ultimately harder to sustain.

98 Telegram Groups & Channels
53 Active Cybercrime Actors Engaged
56.6% Natural Multi-Round Engagements
🎭 骗子:“这次终于钓到人了。” AI:“你确定?”

裸聊诈骗这件事, 本质上特别依赖一样东西: 真人。 骗子先找目标、聊感情、建立信任, 再一步步把人引到裸聊、付费甚至敲诈。 整套生意能运转, 是因为骗子默认了一件事—— “屏幕另一头,一定是个真的、可能会上钩的人。”

那我们就换个玩法。 如果屏幕另一头根本不是受害者呢? 我们让 LLM 假装成一个普通用户, 会聊天、会接话、会讨价还价, 甚至还能陪骗子一轮一轮聊下去。 表面上看: 骗子在钓“受害者”。 实际上: AI 正在钓骗子。🙂

我们把这个系统叫做 LURE。 它在真实的 Telegram 黑灰产生态中, 分析了 98 个群组和频道, 与 53 个活跃服务提供者展开交互。 其中有 56.6% 的对话自然推进, 对方把我们的 AI 当成了正常用户, 甚至主动暴露了价格、支付方式、二维码、 引流 App 等运营细节。

但这个工作的重点其实还不是 “骗过了多少骗子”。 更有意思的问题是: 如果骗子以后每遇到一个“受害者”, 都要先怀疑一句—— “这到底是真人,还是 AI?” 那么他们的时间会被浪费, 转化率会下降, 运营成本会升高, 而真正的受害者, 就会越来越难成为他们赖以生存的“土壤”。

🎭 一句话总结: More Fake Victims → Less Room for Real Criminals.
骗子靠真人受害者生存。 当“假受害者”足够多, 真的坏人也会越来越难活。
LLM for Security Cybercrime LLM Agents Social Engineering Scam Disruption Human-Centered Security

LLM & Agent Security

We study the security, privacy, and trustworthiness of large language models and LLM-powered applications (e.g., agents). Our research investigates jailbreak attacks, prompt injection, adversarial manipulation, data leakage, agent security, and practical defenses for real-world LLM systems.

Featured Project
Flashboom
💥 LLM Security × Software Security
LLM Security

Flashboom: Make the Auditor Look the Wrong Way

What if the vulnerability is still sitting right there in the code, but the LLM auditor is simply looking somewhere else? Flashboom exposes a new attack surface in LLM-based code auditing: the model’s own attention mechanism. Instead of hiding or obfuscating the real vulnerability, an attacker inserts carefully selected attention-grabbing code that naturally attracts the auditor’s focus. The real bug remains untouched, but the model becomes distracted and may fail to report it. To automate this attack, we build Crazy-Ivan, which searches a codebase for high-attention functions, refines them into self-contained snippets, inserts them into vulnerable code, and verifies whether the auditor’s attention has shifted away from the true vulnerability. Flashboom achieves up to 96.3% blinding success, transfers across different LLMs, and remains highly similar to the original program. The bug is not removed—the auditor is simply made to look in the wrong direction.

96.3% Blinding Success on CodeLlama
>87% Cross-Model Blinding Transfer
≥0.92 Mean Semantic Similarity
💥 “声东击西”:漏洞没藏起来,只是让模型看错了地方。

想骗过一个代码审计模型, 第一反应可能是: 把真正的漏洞藏得更深一点? 改变量名、套几层函数、做点代码混淆…… 结果我们试了一圈发现: 现在的 LLM 没那么好骗。

那就换个思路。 与其想办法把漏洞 “藏起来”, 不如想办法让审计模型 “看别处”。

想象一下: 真正的漏洞就在代码里安安静静地待着。 这时候我们往旁边放一段特别 “吸睛”的代码—— 模型一看: “诶?这个地方好像很值得研究。” 然后注意力就被吸过去了。

于是就出现了一个很有意思的场景: 漏洞没改,漏洞没删,甚至漏洞还在原来的位置。 但 LLM 审计器就是 没看见。🙂

我们把这种攻击叫做 Flashboom, 中文其实特别形象: “声东击西”。 为了不靠人工一个个找“烟雾弹”, 我们还做了 Crazy-Ivan: 自动从代码库中寻找最容易吸引 LLM 注意力的函数, 自动补全依赖、插入目标代码, 再检查它是不是真的把模型的目光 从真正漏洞上“拽走了”。

最终 Flashboom 在 CodeLlama 上 最高实现了 96.3% 的 blinding success rate, 并且这种“障眼法”还能 跨模型迁移。 更麻烦的是, 攻击后的代码和原代码依然非常相似, 平均 semantic similarity 可以达到 0.92+, 人也未必一眼就能发现哪里不对。

🎩 一句话总结: Hide the bug? No. Distract the auditor.
真正危险的地方在于: Bug 一直都在那里, 只是模型的眼睛被“骗开了”。
LLM Security Software Security Code Auditing Attention Manipulation Adversarial Attack Vulnerability Detection
Featured Project
Identity Confusion in MCP
🧩 LLM Security × MCP Security
LLM Security

Identity Confusion in MCP: Authorizing the Server Is Not the Same as Authorizing the Caller

MCP servers are increasingly becoming the execution layer of LLM-based agents, bridging model decisions with real system actions. But what happens when a server remembers that it was authorized, yet cannot tell who is actually making the next call? We identify a previously underexplored vulnerability in MCP-based AI systems, which we call caller identity confusion. The core problem is simple but dangerous: authorization is often bound to the server, not to the real invoking caller. As a result, a one-time legitimate authorization may silently unlock later tool executions triggered by different, potentially malicious callers. To systematically study this problem, we design MCPAuthChecker, an invocation-level analysis framework that detects whether execution authority is truly bound to the caller. In a large-scale study of 6,137 real-world MCP servers, we find that 2,846 (46.4%) exhibit insecure authorization behavior, and 52% of developer-tool servers are insecure. These flaws can directly enable remote command execution, unauthorized UI control, and privileged API abuse.

6,137 MCP Servers Analyzed
46.4% Insecure Authorization Behavior
52% Developer-Tool Servers Insecure
MCP “授权过一次” ≠ “以后谁来都能用”。

MCP 很像大模型时代的“工具中间层”: 上面是 AI Agent,下面连着数据库、文件系统、浏览器、外部 API。 问题就出在这里—— 很多 MCP server 记住了“自己被授权过”, 却没认真区分:这次真正发起调用的人,到底是谁。

于是,一个很危险但又很自然的事情就发生了: 一个合法用户先正常完成一次授权, 服务器把这个“已授权状态”记下来; 之后,另一个调用者——甚至是恶意 agent—— 再来请求工具调用时, server 可能直接沿用之前的授权, 继续执行。

换句话说,问题不在于 “有没有授权逻辑”, 而在于: 这次执行的权限, 到底是不是绑定在当前这个 caller 身上。

为了系统回答这个问题, 我们设计了 MCPAuthChecker, 从 tool invocation 粒度分析: 工具调用到底从哪里真正落到执行、 路径上有没有 caller-bound authorization、 以及已有授权状态会不会被后续调用“继承”。

最后我们分析了 6,137 个真实世界 MCP servers, 发现有 2,846 个(46.4%) 存在不安全授权行为; 而在最常见的 developer-tool servers 里, 这个比例高达 52%。 这些问题不是“代码不够优雅”那么简单, 而是可能直接导致: 远程命令执行、未授权界面控制、以及高权限 API 滥用。

🔐 一句话总结: Authorize the caller, not just the server.
真正危险的不是“授权过一次”, 而是 一次授权之后,server 开始替任何后来者干活。
LLM Security MCP Security AI Agents Authorization Security Program Analysis Web Security

Mobile Security

We investigate security and privacy issues in mobile applications and ecosystems through large-scale program analysis, security measurement, and automated testing. Our research focuses on vulnerability discovery, privacy risks, and emerging threats introduced by AI-enabled and cross-device mobile applications.

Featured Project
Easy As Child's Play
🔞 Mobile Security × Child Safety
Mobile Security

Easy As Child’s Play: Are “18+” Apps Really 18+?

An “18+” label looks like a locked door—but how hard is it really for a child to get through? We studied 693K+ Android apps, identified 31,750 adult-oriented apps, and built GUARD, a static–dynamic analysis framework that uncovers how age-verification mechanisms actually work. Surprisingly, only 3.67% implement age verification, and many rely on little more than an “Are you over 18?” button. Even stronger-looking mechanisms can often be sidestepped through fake identities, OAuth trust-chain abuse, regional downgrades, and other low-effort tricks. In short, age-restricted does not necessarily mean age-protected.

693K+ Android Apps Analyzed
31,750 Adult-Oriented Apps
3.67% Implement Age Verification
18+ “刚满18岁”?点一下就算。

App 上赫然写着 “18+”, 门口又是锁、又是盾牌, 看起来多少有点“未成年人止步”的意思。 但现实可能是—— 不管你到底几岁, 先点一句“我已满18岁”再说。 某种意义上, 互联网上每天都有无数用户 “刚满18岁”。🙂

我们一口气分析了 69 万+ Android App, 从中找出 31,750 个成人向 App, 结果发现真正部署年龄验证的只有 3.67%。 更有意思的是, “有验证”也不代表“拦得住” : 改个生日、 借张成人身份证、 从 OAuth 绕一下、 换个地区/VPN, 甚至动一动验证数据, 都可能让这道看似严肃的 “18+ 大门”秒变儿童栅栏。

🔐 一句话总结: “Age-Restricted” ≠ “Age-Protected”.
真正的问题不是 App 有没有问你 “满 18 岁了吗”,而是—— 它到底认不认真听你的答案。
Mobile Security Android Age Verification Program Analysis Child Safety

IoT & Embodied AI Security

We investigate security and privacy risks across IoT devices, communication protocols, cyber-physical systems, and emerging embodied AI platforms. Our research focuses on vulnerability discovery, cross-layer attacks, AI-driven control pipelines, and unsafe physical behaviors in robots and embodied agents.

Featured Project
TORCHLIGHT
🔦 IoT Security × Tor Traffic Analysis
IoT & Embodied AI Security

TORCHLIGHT: Following the Footprints Leaving the Tor Tunnel

Cloudless IoT devices are directly exposed to the Internet, making them attractive targets for real-world attacks. But attackers do not always attack in the open— many prefer to hide behind Tor. This raises a powerful idea: even if Tor protects the attacker’s identity, the malicious traffic must still emerge from a Tor exit node before reaching a real IoT device. We build TORCHLIGHT, a system that detects both known and unknown threats against cloudless IoT devices by analyzing Tor exit traffic. It combines (1) Tor-exit traffic collection, (2) strategic VPS deployment for cost-effective observation, and (3) an LLM-based IoT traffic analyzer for attack identification. Over 12 months, TORCHLIGHT analyzed 26 TB of traffic, uncovered 45 vulnerabilities, including 29 zero-day exploits with 25 assigned CVE-IDs, and recorded 90,047 attack attempts. These vulnerabilities affect approximately 12.71 million devices across 148 countries, exposing them to serious risks such as information disclosure, authentication bypass, and arbitrary command execution. In short, Tor may hide who the attacker is, but the exit traffic can still reveal what the attacker is doing.

26 TB Tor Exit Traffic Analyzed
45 Vulnerabilities Revealed
29 Zero-Day Exploits
12.71M Vulnerable Devices Affected
TOR 人藏在 Tor 里,但脚印还是会从 tunnel 里走出来。

Tor 最厉害的地方,就是 “帮攻击者把人藏起来”。 但问题是, 不管攻击者藏得多好, 真正要去打一个现实世界里的 IoT 设备, 流量最终还是得从 Tor exit node 出来,落到目标设备上。

所以这个工作的核心 insight 其实很直观: 既然很难知道 tunnel 里是谁, 那就盯住“从 tunnel 里出来了什么”。

我们设计了 TORCHLIGHT, 从 Tor exit traffic 里去发现 正在被真实攻击的 cloudless IoT devices。 整个系统一边在 VPS 上低成本收集外部流量, 一边根据 Tor 的选路机制优化部署, 再结合基于 LLM 的流量分析, 自动识别哪些请求是真的 IoT 流量、 哪些是正在进行中的攻击。

最后我们连续监测了 12 个月, 分析了 26 TB 流量, 发现了 45 个漏洞, 其中包括 29 个 zero-day, 已获得 25 个 CVE。 这些问题影响大约 1271 万台设备, 分布在 148 个国家, 带来的风险包括 信息泄露、认证绕过、任意命令执行 , 还记录到了 90,047 次 真实攻击尝试。

更重要的是,这项工作第一次清楚说明了: 攻击者确实会主动利用 Tor 隐藏身份, 去攻击没有云端保护、直接暴露在公网中的 IoT 设备。

🔦 一句话总结: Tor hides the attacker, but the exit traffic can still expose the attack.
与其试图看穿 tunnel 里的匿名者, 不如直接盯住 离开 tunnel 的脚印。
IoT Security Tor Traffic Analysis Vulnerability Discovery Zero-Day LLM for Security
Featured Project
When Good Becomes Evil
🦇 BLE Security × Privacy
IoT & Wireless Security

When Good Becomes Evil: When a Security Feature Becomes a Tracking Side Channel

Bluetooth allowlists are supposed to improve security: a BLE device remembers which peers it trusts and ignores everyone else. But that seemingly helpful behavior creates an unexpected privacy leak— the way a device responds can reveal who it trusts. We uncover a new allowlist-based side channel and introduce BAT (Bluetooth Address Tracking), which exploits behavioral differences between allowlisted and unknown devices to track BLE devices even when their MAC addresses are randomized. BAT supports both passive tracking, by observing BLE responses over time, and active tracking, by replaying previously observed randomized addresses and probing whether a device recognizes them. We validate BAT on 43 BLE peripherals, 11 centrals, and 4 development boards, finding that none of the tested allowlist-enabled devices are immune. To close the side channel, we design SABLE (Securing Address for BLE), which combines synchronized unpredictable address randomization with replay-resistant address generation. A security mechanism should not only decide who gets in— it should also avoid revealing who is already trusted.

43 BLE Peripheral Devices Tested
11 BLE Centrals Tested
0 Tested Allowlist Devices Immune to BAT
~1% SABLE Central Power Overhead
🦇 BAT 本来是“白名单”,怎么反而把自己人暴露了?

BLE 的 allowlist 本来是个挺好的安全功能: “只跟认识的人说话,陌生人一律不理。” 听起来很安全,对吧?

但问题恰恰出在这个 “理不理你”上。

攻击者站在旁边观察: 一个熟悉的设备过来—— “Hi again!” ✅ 一个陌生设备过来—— 沉默。 ❌ 于是攻击者突然发现: 我虽然不知道你是谁, 但我可以从你的反应,看出你认识谁。

更麻烦的是, BLE 原本还会不断随机化 MAC 地址, 就是为了防止别人长期追踪。 但只要设备对 “认识的人”和“陌生人” 表现得不一样, 攻击者就可以把不同时间出现的随机地址 一点一点串起来: 地址一直在换,但还是同一个设备。🙂

我们把这个攻击叫做 BAT — Bluetooth Address Tracking。 名字也故意玩了个小巧思: 🦇 BAT 就像蝙蝠一样, 不需要“看见”你,也能靠外界反馈找到你。 BAT 既可以 被动监听, 也可以主动把之前听到的地址 replay 回去试探设备: “这个地址你还认识吗?” 如果设备回应了—— 抓到了。

我们在 43 个 BLE peripheral devices11 个 centrals4 块 development boards 上进行了验证, 结果是: 没有一个测试的 allowlist-enabled 设备能够免疫 BAT。

🦦 防御怎么办? 我们设计了 SABLE — Securing Address for BLE.

如果说 BAT 🦇 是偷偷循着“信任关系”寻找猎物, 那么 SABLE 🦦 就负责把这些踪迹擦掉: 让通信双方 同步但不可预测地更换随机地址, 同时加入 freshness, 防止攻击者把以前看到的地址拿回来 replay。

一句话: 安全机制不仅要挡住陌生人, 还不能顺手告诉陌生人——“我的朋友是谁”。
Bluetooth Security BLE Privacy Side Channel Device Tracking Replay Attack IoT Security

Program Analysis

We develop static, dynamic, and hybrid program-analysis techniques for vulnerability discovery, behavioral understanding, and large-scale security measurement. We also explore combining program analysis with machine learning and LLMs to improve the automation, scalability, and semantic understanding of security analysis.

Featured Project
Collapse Like a House of Cards
🏢 BAS Security × Fuzzing
IoT & CPS Security

Collapse Like a House of Cards: One Weird Packet Can Shake the Whole Building

Building Automation Systems (BAS) quietly control critical building functions such as HVAC, lighting, fire safety, and access control. They are the hidden operating system of modern smart buildings. But what happens when the packets flowing through this infrastructure are malformed, unexpected, or deliberately crafted? We present BASE (Building Automation System Evaluator), the first fuzzing framework designed specifically for BAS networks. Unlike traditional fuzzers, BASE must deal with complex protocol structures and sequencing, closed-source BAS clients with hard-to-measure coverage, and servers whose internal state is largely unobservable. BASE addresses these challenges by automatically learning protocol structures and message dependencies, dynamically instrumenting BAS clients for coverage feedback, and using timestamp-aware throughput control to fuzz BAS servers efficiently. We evaluated BASE on 11 BAS servers (4 BACnet devices and 7 KNX devices) and 6 BAS clients, uncovering 13 new vulnerabilities. Over a 24-hour fuzzing campaign, BASE discovered 17,616 unique edges at an average speed of 138.91 executions per second. In contrast, BooFuzz sent millions of mutated messages yet found no vulnerabilities. More importantly, the discovered bugs are not merely software crashes: they can translate into delayed fire detection, loss of climate control, and security breaches in real buildings.

13 New BAS Vulnerabilities Found
11 + 6 BAS Servers and Clients Evaluated
17,616 Unique Edges in 24 Hours
138.91 Executions per Second
BASE 楼看着好好的,可能一条怪报文就开始“塌房”。

楼宇自动化系统(BAS)平时非常低调: 控空调、管照明、接火警、连门禁, 平常没人注意它, 但它其实就是一栋智能楼宇背后的 “隐形操作系统”。

问题在于, 这些系统不是只管“软件逻辑”, 它们还直接连着现实世界里的设备和控制链路。 所以一旦出了问题, 后果就不是简单的 “程序崩了”, 而可能变成: 火警延迟、温控失灵、门禁和摄像头受影响。

这个工作的核心 insight 很直观: 在 BAS 这种高度互联、层层依赖的系统里, 一条异常报文,可能就像抽掉牌屋底下的一张牌。 不是某一个点单独坏掉, 而是整套自动化逻辑开始连锁失稳。🙂

为了系统性地找出这类问题, 我们设计了 BASE, 一个专门面向 BAS 的 fuzzing framework。 难点并不小: BAS 协议像 BACnet、KNX 报文结构复杂, 有字段依赖、有消息顺序; 客户端很多还是 closed-source, coverage 很难看; server 内部状态也几乎不可见, 吞吐还会受设备扫描周期影响。

BASE 的思路是把这些障碍一一拆开: 自动学习协议结构和顺序关系, 动态插桩客户端看 coverage, 再根据时间戳去估计设备输入扫描间隔, 让 fuzzing 不只是“乱发包”, 而是更聪明、更贴近真实通信地去打。

最后我们在 11 个 BAS servers6 个 BAS clients 上进行了评估, 一共发现 13 个新漏洞。 在 24 小时测试中, BASE 找到 17,616 条 unique edges, 平均速度达到 138.91 exec/s。 相比之下, BooFuzz 即使发了 285 万+ 条变异消息, 也没有发现漏洞。

更重要的是, 这些漏洞不是“论文里看起来挺危险”, 而是真能落到现实影响上: 火警检测延迟、气候控制失效、 以及楼宇安防风险。

🏢 一句话总结: In a building automation system, one malformed packet can trigger cascading real-world failures.
真正危险的不是“某个程序崩了”, 而是 一条奇怪报文,可能让整栋楼的自动化链条一起失衡。
Building Automation Security CPS Security IoT Security Fuzzing BACnet KNX

Human-Centered Security

We study security and privacy from a human-centered perspective, focusing on user behavior, security perceptions, privacy decision-making, and usable security. We also investigate human interactions with emerging AI systems and design security mechanisms that are effective, understandable, and usable.

Featured Project
Learning Less While Asking More
🧠 Human-Centered Security × LLM Learning
Human-Centered Security

Learning Less While Asking More: When Faster Answers Lead to Shallower Understanding

LLM assistants make learning feel remarkably easy: ask a question, get a clear answer, ask another one, and quickly arrive at a fix. But does a smoother learning experience actually mean deeper understanding? We conducted a controlled within-subject study with 70 programmers, comparing LLM-assisted vulnerability learning with traditional web search across five dimensions: Recognition, Cause, Behavior, Danger, and Fix. We uncover a striking gap between perceived support and actual learning. Participants consistently rated the LLM as more helpful, clearer, and more responsive, yet achieved significantly weaker learning gains in the reasoning-intensive dimensions of Cause, Behavior, and Danger. Behavioral analysis helps explain why: LLM users shifted topics more frequently, moved toward fixes earlier, and spent less time engaging with explanatory content. Motivated by these findings, we design VulnScaffold, a scaffolded LLM learning interface that guides better questions, structures explanations around why → how → risk → fix, and encourages learners to test and reflect on their own understanding. The lesson is simple: better learning tools should optimize for deeper thinking, not merely faster answers.

70 Programmers in Controlled Study
3 / 5 Reasoning Dimensions with Lower LLM Gains
97s LLM Reading Time per Query
9 / 14 Preferred VulnScaffold for Learning Support
🧠 问得更多,为什么反而学得更少?

现在学一个漏洞有多方便? 代码一贴,问一句: “这个漏洞怎么修?” LLM 马上给你答案。 再问一句, 再来一个答案。 整个过程丝滑得像开了倍速。🙂

但我们想问一个有点扎心的问题: 你是真的学会了, 还是只是更快拿到了答案?

我们找了 70 名有编程经验、但没有正式软件安全训练的参与者, 让同一个人分别用 LLMWeb Search 学习软件漏洞。 不只看最后 “会不会修”, 而是把理解拆成五层: Where、Why、How、Risk、Fix。

结果很有意思。 LLM 在 “找到漏洞”“告诉你怎么修” 这类任务上并没有明显落后。 但一旦问到真正需要推理的: 为什么会产生?
运行时到底发生了什么?
最后为什么危险?
学习效果反而更弱。

更有反差的是—— 用户自己完全不觉得体验差。 相反,他们觉得 LLM: 更 helpful、更加 clear、也更加 responsive。 也就是说: “感觉学得很好” 和 “真的学得很好” 可能是两回事。

我们进一步看了大家到底是怎么学的, 发现 LLM 特别容易把人带进一种节奏: 问得快 → 跳得快 → 很快开始找 Fix → 拿到答案 → 收工。 而真正有效的学习, 往往需要在 Cause、Behavior、Danger 上多停一会儿, 把这些东西真正串起来。

所以我们又设计了 VulnScaffold: 不让 LLM 只是一个 “答案打印机”, 而是通过 Guide Better Questions → Structure the Reasoning → Test & Reflect 把学习过程重新组织起来。 在初步实验中, VulnScaffold 相比普通 LLM 在 CauseBehavior 上都表现出了更好的学习增益。

🎓 一句话总结: Feels easier ≠ Learns deeper.
LLM 最大的风险可能不是 “不给你答案”, 而是—— 太快给你答案, 让你误以为自己已经懂了。
所以真正好的 AI 学习工具, 不应该只让答案来得更快, 而应该让人 想得更深。
Human-Centered Security LLM Security Education Vulnerability Learning HCI Usable Security