第四届移动超级应用安全研讨会（ACM Workshop of Security and Safety of AI-empowered Mobile Super Apps, SaTS’26） 将与CCS 2026同期在荷兰海牙举办。该Workshop旨在探讨 AI 赋能移动超级应用与小程序生态中的系统性安全与隐私挑战，旨在汇聚学术界与产业界研究人员，共同探讨该领域的新兴威胁、分析方法、防御机制与未来发展方向。投稿截止日期为2026年7月15日（AoE），欢迎全球研究人员和从业者踊跃投稿！

关于SaTS 26

在过去的十年间，移动超级应用从单一应用形态逐步演进为由平台、开发者与用户共同构成的复杂三方生态系统。随着微信、支付宝、TikTok、LINE、Zalo、Grab 等超级应用的快速普及，超级应用沉淀并掌握了海量用户数据与服务入口，小程序服务商也能够提供诸如“一键登录”等更高效便捷的用户体验。与此同时，华为、小米、OPPO 等厂商推动的快应用等新型系统应用开发范式，也进一步强化了移动服务轻量化、平台化与无安装化集成的发展趋势。这些基于移动端JavaScript执行环境的超级应用平台，通过对用户数据、云服务、与开发者程序包的管理，逐渐演化为一种具有操作系统属性的平台型基础设施。近年来，智能体 AI 框架与 AI 赋能应用开发的兴起，在进一步重塑超级应用生态的同时，也引入了更加复杂、动态且跨主体的安全与隐私挑战。

为了应对这类新型威胁，SaTS Workshop 旨在汇聚来自学术界、产业界和政府机构的工作与经验，搭建跨领域交流平台，分享最新研究成果与技术进展，共同探讨 AI 赋能移动超级应用、小程序生态和安全分析交叉领域中的新兴威胁、防御机制与未来研究方向。在2023年至2025年间，SaTS成功举办了三届Workshop，持续凝聚学术界与产业界共识，并推动相关研究议题的形成与发展。今年，第四届 SaTS Workshop 期待进一步吸引业界与学术界的投稿，围绕高质量数据集构建、工具与基础设施建设、新型安全分析范式探索，以及前沿安全问题识别与治理等方向，推动更加深入的研究交流与社区协作。

征稿主题

第四届移动超级应用安全Workshop将与CCS 2026大会一并在荷兰举行。本届workshop重点关注超级应用安全与人工智能自动化技术交叉方向的投稿，尤其欢迎围绕大语言模型与智能体 AI及其在移动超级应用与小程序生态中的应用、安全影响与治理挑战展开的投稿。我们诚邀能够推进超级应用生态理解、推动其安全评估、风险发现与防护能力提升的技术性和实证性研究。征稿主题包括但不限于：

• AI 赋能移动（超级）应用及第三方小程序的安全分析

• 移动（超级）应用中智能体框架与助手的安全分析

• 基于智能体或大语言模型的移动（超级）应用安全分析技术

• 面向用户的移动（超级）应用安全与隐私研究

• 恶意软件、漏洞、虚假信息与违规行为检测，隐私政策与安全合规分析

• 移动（超级）应用中的攻击、防御与缓解机制

• 与移动（超级）应用中的智能体和小程序相关的其他安全议题

投稿指南

投稿论文须为英文撰写，且必须是未发表、未同时投递至其他出版渠道的原创工作。所有投稿应以 PDF 格式提交，并采用双栏 ACM 格式，具体请参考 ACM Proceedings Template 中的 sigconf 样式。我们接受三类投稿：

• 常规论文，不超过 7 页

• 短文或进行中工作的论文，不超过 4 页

• 攻击、防御或工具演示论文，不超过 2 页。

页数限制不包括参考文献和明确标注的附录，附录最长可为 2 页。作者不得修改 ACM 模板中的字体或页边距。审稿流程采用双盲评审，所有论文均须以 Adobe Portable Document Format（PDF）提交，并通过 HotCRP 在线投稿系统完成提交，投稿链接将在五月下旬于主页https://superappsec.github.io/ 更新。

研讨会主页：https://superappsec.github.io/

联系邮箱：yuqing.yang@cispa.de

重要日期

论文提交截止时间：2026 年 7 月 15 日（AoE，UTC-12）录用通知时间：2026 年 9 月 1 日终稿提交截止时间：2026 年 9 月 15 日（AoE，UTC-12）

组织委员会

指导委员会Zhiqiang Lin (Distinguished Professor of Engineering, The Ohio State University, IEEE Fellow)Ben Stock (Faculty, CISPA Helmholtz Center for Information Security)Yan Shoshitaishvili (Associate Professor, Arizona State University)Luyi Xing (Associate Professor, University of Illinois Urbana-Champaign)

程序委员会主席Yuqing Yang（Assistant Professor, Macao University of Science and Technology）Yue Xiao（Assistant Professor, William & Mary）

程序委员会

Yue Zhang（Professor, Shandong University）

Balazs Engedy (Staff Software Engineer, Google)

Hao Wu (Assistant Professor, Nanjing University)

Hongkai Chen (Arizona State University)

Soheil Khodayari (Researcher, CrowdStrike)

Shubham Agarwal (Researcher, Max Planck Institute for Security and Privacy)

Xinfeng Li (Research Fellow, Nanyang Technological University)

Yanjie Zhao (Researcher, Huazhong University of Science and Technology)

Yue Xiao（Assistant Professor, William & Mary）

Yuhao Wu（Researcher, Palo Alto Networks）

Yuqing Yang（Assistant Professor, Macao University of Science and Technology）

Zifeng Kang（Assistant Professor, Beijing University of Posts and Telecommunications）

期待您的投稿，我们海牙见！

跳转微信打开

’‘三人言市有虎，王信之乎？’王曰：‘寡人信之矣。’

庞葱与太子质于邯郸，谓魏王曰：‘今一人言市有虎，王信之乎？’王曰：‘否。’‘二人言市有虎，王信之乎？’王曰：‘寡人疑之矣。’‘三人言市有虎，王信之乎？’王曰：‘寡人信之矣。’庞葱曰：‘夫市之无虎明矣，然而三人言而成虎。今邯郸去大梁也远于市，而议臣者过于三人，愿王察之。’王曰：‘寡人自为知。’于是辞行，而谗言先至。后太子罢质，果不得见。

在今年的SACMAT会议上，有一篇Bluesky Paper（这个bluesky模式很有意思，大家可以去看看，大概就是“高瞻远瞩”的模式）讨论了在当前多agent模式下，人类要去验证AI的工作，这个问题怎么以一种更为严格的形式来定义和分析，这就是今天我们要给大家介绍的论文 The Treacherous Envoy Problem: Trust, Collusion, and Accountability in Multi-Agent Workflows

这篇论文定义了一个叫做Treacherous Envoy Problem（TEP）的问题形式，问题的名字援引圣经Proverbs 13:17 A wicked messenger falls into trouble, but a trustworthy envoy brings healing（奸恶的使者必陷在祸患里； 忠信的使臣乃医人的良药），那怎么理解TEP在AI时代的定义？

我们先回忆下前段时间的一个新闻，2026年初，携程因为滥用市场垄断地位被调查，收到顶格罚单65亿元，这倒不奇怪，因为很早以前大家就听说过“大数据杀熟”这个概念了。不过到了AI时代，这些巨头们最害怕的可能不是罚款，是AI代替人去查价格买东西。在本文中，作者正是用这个买买买的实例引出了问题：假设现在你想让AI帮忙找一个价格在500块以下，还可以入住前免费退款的酒店，你有没有想过这里面可能会涉及到什么安全或者信任的危机吗？

在携程时代（当然没有携程之前，外地人被宰得更狠），我们去订酒店的时候并不知道携程是否真的给了我们最好的价格，而在AI时代，当我们指挥现在的AI agents去帮我们搜索网页选择最低价产品时，也一样要怀疑这些人工智能助手是否真的给了人类足够诚实的答案（虽然人类肯定比ta们更加摸鱼和不老实）。最近的所有关于AI和人共处的文章，大家无一例外强调的就是人要学会验证（validation and verification），但是，要是你面对的是一群AI助手合伙起来（骗你）呢？

本文的核心就在于此：在一个multi-agent的工作流中，信息的流转变得相当复杂且不透明，我们要想去验证到底任务是否真正按照人类的意思去执行，就要把这个工作流给抽象成可以分析的模型，然后更为准确地定义其中的子问题，最后才能回答那个最大的问题——人工智能助手是否可信可靠。在本文中，提到最频繁的那个概念——envoy——实际上可以认为就是一个处理任务的agent，这个agent如果是不可信的（treacherous，又学到新单词了），我们就很容易被蒙骗，那如果处理任务的是多个agent，它们还会合谋起来欺骗人，那我们人类估计是被骗了还很难发现：

因此，要对这样一系列很复杂的信息交互流程进行验证，本文作者首先给出了关于TEP流程非常细节的定义图（如下图），这里面涉及到大量的概念和定义，可能初读起来非常的晦涩，但是如果不这样去定义，可能就很难勾勒出来在现在这样一个multi-agent工作流背景下的清晰的安全模型，因此感兴趣的读者可以去仔细了解一下原文的细节（第三章）：

论文的第四章讨论了另一个问题：为什么检测这些不可信的agent（或者说，检测agents的行为中是否存在不可信的成分）那么困难？作者用了一些信息论的方法，来展示了其中存在的根本性困难：不管你工程上如何优化，信息的传递本质上可能就是很难保证100%的可靠。

回到validation and verification上来，基于前面的模型，本文提出了这么一个“不可能三角”（三难困境），这里面其实很像现实中的人类社会，在社会活动中的监管、审计和契约合作都是典型的多方参与的事务，而里面如果只考虑其中的某个单方面事务，是很难发现并真正解决问题的，只有每个层面上的不同角色都合作起来，可能才有希望改善（而非完全解决）现有的问题。这既是人类社会遇到的问题，也是未来人工智能时代可能面临的第一个社会学问题？

本文的作者之一是我们G.O.S.S.I.P的老朋友林志强教授，他最近和大家一样，在AI对计算机特别是安全领域产生巨大冲击的浪潮中始终在思考，这篇文章的核心目标，也是希望能够提出一个和byzantine general problem、millionare problem那样的问题，促使大家去思考，在人工智能成为水电这样的基础设施之时，也有一个更为黄金的标准来衡量它的可信度。

论文：https://zhiqlin.github.io/file/SACMAT26.pdf

跳转微信打开

重温两千年密码学发展史，了解密码科学与技术专业，成为一名破译者！

提问：在电影银幕上，你最喜欢什么元素？

每个人的答案应该都不一样，但是有一个元素肯定会吸引大家的眼球，那就是密码学：讲述计算机巨擘阿兰·图灵的电影《模仿游戏》（其实下图这个香港版本的海报的译名——解码游戏——可能更为贴切），核心正是图灵在二战期间破解德军的Enigma密码机这一著名的事件。如果你对这个故事的具体细节感兴趣，除了去观赏这部电影，也可以访问一个网站 https://thecodebreakers.org/ 看看你是否能在这个超级芯片加持的时代能如图灵一般破解德军的战争密件。

在战争年代，密码学总是和生死存亡密切相关，剧情也扣人心弦，像国产电影《风声》在豆瓣上依然保有8.5的高分，好评如潮，影评中甚至有热心观众去分析周迅需要用多少针脚去编码相关的秘密信息。

而另一部更为古早的电影《风语者》（2002年吴宇森执导），以二战中的太平洋战争为背景题材，讲述了美军为了对抗日本的密码破译，招募了几百名印第安纳瓦霍族人，将他们训练成了专门的译电员，称为“风语者”（Windtalker）。实际上，第二次世界大战中，密码学的分析和破译几乎是产生了许多决定性的作用：德军的Enigma密码被图灵破译，历史学家认为这直接让二战至少提前两年结束，挽救了超过1400万人的生命。而在太平洋战场上，美军因为破译了日本的密码，不仅直接借助情报击落了日本联合舰队司令山本五十六的座机，还成功在中途岛战役中一举扭转了珍珠港事件导致的劣势。

关于这些故事背后的故事，如果你感兴趣，那么就决不应该错过一本非常值得阅读的书籍——《The Code Breakers》，特别其中关于中途岛战役的部分，描述得非常精彩，作者David Kahn描述了美军截获了日本的密电，无法确定其中的一个符号“AF”的含义，于是用了巧妙的方法引诱日军执行了密文重用，最后确认这个AF是中途岛（Midway）的代号，从而实施了相关伏击，可以说是彻底改变了太平洋战争的走势。

实际上《The Code Breakers》并不是只简单记录了二战期间的密码学故事，它可以说是第一本讲述几千年来密码学发展史的书籍，在豆瓣上还有一个网友“君子不器”记录了去美国和作者David Kahn共进晚餐的有趣故事：这位网友之所以会去联系David Kahn，完全是无心读到了下面这本《破译者》，这是上个世纪在国内翻译并出版的《The Code Breakers》的中译本，大概是因为这个群众出版社是公安部下属的？上了年纪的读者肯定知道它家出的另一套经典——《福尔摩斯探案集》。而David Kahn其实并不知道这本书在中国国内被翻译了，不过在他收到了“君子不器”的联系邮件之后，表示希望搞到这套中译本（以及他的另一本书《希特勒的间谍》），并愿意请网友在曼哈顿吃牛排作为答谢！！！这种翩翩风度让我们想到了另一个虽然拿了诺奖但是充满了小家子气的南美老头马尔克斯，不知道老马知道了这个故事会不会觉得羞愧（估计不会，老马已经掉钱眼里面了）。

https://book.douban.com/subject/4928343/

David Kahn其实并不是一个密码学专家，而是一名情报人员，他十一岁的时候恰巧遇到一本很精彩的密码学普及读物，从此对数字背后的隐秘产生了巨大的兴趣。多年后，《纽约时报》在某日头版头条报道了一起情报案件。此时卡恩的情报学知识已经很丰富了，他撰文投给报社，介绍案件背后的情报史背景。此文见报后，有几家出版社找到他，希望他编写一本关于加密和解密的历史著作。卡恩于是开始了他的笔耕生涯，经过“八年抗战”，终于完成号称密码学史上的“圣经”的《破译者》。虽然老先生已于2024年2月1日驾鹤仙去，享年93岁，但是他的这本书籍作为密码学领域的不朽之作，在人类文明的长卷中应该拥有一席之地。

大概是因为《The Code Breakers》太有名了，前面提到的网站 https://thecodebreakers.org/ 应该是向它致敬，上面有很多很多相关的挑战和资料。大家可以去访问一下，就会发现密码学绝不是什么枯燥的数学理论，更像是引人入胜的解密游戏~

实际上，芝加哥大学很早开始就通过一个叫做CryptoClub Project的项目（NSF资助的哦）发布了一系列面向中小学生的密码学学习材料（https://cryptoclubproject.uchicago.edu/curriculum 这里有详细信息），其中一本叫做The Cryptoclub的图书已经被国内引入并翻译成中文了。

如果大家感兴趣，完全可以去它的官网 https://www.cryptoclub.org/ 直接 玩游戏 学习原汁原味的内容：

好了，介绍了这么多，现在你发现自己对密码学产生了浓厚的兴趣，但不知道是否投身这个领域，那应该怎么办呢？请往下看：

教育部公布2025年度普通高等学校本科专业备案和审批结果，华东师范大学密码学院获批设立密码科学与技术本科专业，将于2026年开始招生。

欢迎大家投身密码学行业，你也可能成为一名非常厉害的codebreaker哦！

跳转微信打开

《DARPA拖拉机简史》==《DARPA try everything来解决内存漏洞简史》

有一本叫做《乌克兰拖拉机简史》的书，在俄乌战争之前估计听说过的读者不多，而之后估计也都是一些喜欢政治军事的网友去“误读”然后弃坑，其实它是一部黑色幽默文学作品，喜欢文学的读者可以去自行搜索和阅读~

今天我们介绍的内容其实和文学以及乌克兰没什么关联，纯属蹭一下这本书的热冷度。那今天的推荐是来自NDSS 2026的keynote speak环节，由Dan Wallach（应该是之前在Rice University，现在去了DARPA？）给大家做的报告Solving the Memory Safety Problem, Once and for All

这个报告之所以和《乌克兰拖拉机简史》有那么亿分之一的关联，是因为DARPA在2024年启动了一个“拖拉机”项目——即“TRanslating All C TO Rust”（缩写为TRACTOR）的项目。不知道还有没有读者记得公众号的一篇很古老的推荐（额，其实也就是5年前，不过那时候还属于前AI时代，一转眼恍如隔世，）《G.O.S.S.I.P 学术论文推荐 2021-12-13 Translating C to safer Rust》，在那一期的推荐中，我们介绍了一个叫做c2rust的工具。

而DARPA和Dan Wallach教授肯定是看了我们的公众号（很有可能，Dan Wallach教授此前的研究论文也cite了我们的工作 不要脸），于是在2025年6月启动了TRACTOR项目，意在推动研究人员去开发把现有的C代码翻译成Rust代码的自动化工具。

可能你要问，为什么是Rust？因为DARPA此前进行了各种尝试，下面这一张幻灯片（响起了夏奇羊的try everything）里面列出来了之前的各种安全加固技术路线，当然每个路线估计DARPA也投入了不少钱，那也不差再拿出来一笔钱资助下一个新idea（嗯，Rust）：

和之前DARPA的项目类似，TRACTOR也是让不同的team来互相竞争（嗯，我们在国内管这个叫做“养蛊赛马”），而不同的队伍可以使用不同的技术路线，有的用机器学习主导，有的队伍则是走传统的程序分析路线。参赛的六支队伍有的来自大学（华盛顿大学、耶鲁大学、威斯康星大学），有的来自企业（Intel、Galois、Aarno Labs）：

这个项目进展到现在，可能大家最关心的问题（也是现在网络上论战最多的点，大家对AI的态度也可以分为“降临派”、“拯救派”和“幸存派”）就是到底人类还有没有必要去研究代码翻译这个事情。很多人都觉得，现在反正把代码直接扔给AI让它改就完了，Anthropic都已经开始营销大模型直接写编译器、写浏览器和写操作系统了，区区一个C翻译成Rust代码的任务有什么值得研究的？

实际上今年2月，TRACTOR项目出了个中期报告，大家可以去GitHub上看看这个报告的PDF，里面关于各家队伍的技术细节和实际的测试（测试是请了MIT Lincoln Lab作为第三方测试机构，https://www.ll.mit.edu/r-d/projects/translating-all-c-rust-tractor-benchmarks 还准备了专门的benchmark）

https://github.com/DARPA-TRACTOR-Program/Reports/blob/main/First_TRACTOR_Evaluation_Report.pdf

从下面这个正确性评估来看（注意这里评估用的是GPT 5.0，而且没有什么特别的环境，就是给两次prompt机会，第一次是要求它翻译，第二次是把报错信息反馈给它让它改），其实那个最naive的C2Rust的效果反而很有竞争力，这就有点尴尬了。。。

评估报告里面有很多关于各家技术出错的细节（比如谁容易在翻译阶段出错，谁在运行阶段出错更多），感兴趣的读者可以去看看。我们只简单介绍下翻译后的Rust代码和原始C代码的性能对比，从下面的表格可以看出，基本上翻译后的这个性能开销都在可接受的范围（最多也就不到30%）。

不过（某些技术路线）翻译后的Rust代码有一个问题：内存占用开销会大大增加，例如LLM翻译的代码，最极端的情况下会比原C代码使用的内存增加137.64倍……

那么，究竟C代码翻译成Rust代码更好，还是说在LLM时代，人们又一次找到了银弹——直接用AI去检测代码漏洞（嗯，不需要夏奇羊来唱try everything了）~~~

Slides：https://www.ndss-symposium.org/wp-content/uploads/NDSS-2026-Keynote-DWallach.pdf
TRACTOR项目主页：https://www.darpa.mil/research/programs/translating-all-c-to-rust

跳转微信打开

80后只是老了，不是亖了

几天前，在HackerNews上出现了一个热帖，大家讨论的是一个叫做 Windows 9x Subsystem for Linux（wsl9x）的项目，这是一个什么样的项目呢？请看下图：

乍一看，平平无奇，但是就像字画鉴赏一样，只有行家才能一眼看到细微的妙处。仔细看，发现可不简单：在老玩家们熟悉得不能再熟悉的Windows 95系统里面，突然出现了Linux console，而且还是6.19版本的内核？？？这是怎么做到的？？？

年轻的读者可能嘴一撇，会说“这不就是WSL吗，我们又不是没用过”，嗯，4月26日刚刚过去，CIH病毒运行的那个动不动就蓝屏的环境，微软自己的NT内核都没有弄好，还给你搞一个子系统么~

而如作者（Hailey）所说，这个看起来很像WSL的wsl9x，它是可以货真价实的运行在古老的486电脑上，无需什么硬件虚拟化支持（1994年有什么硬件虚拟化？只有《肖申克的救赎》），这个工作完全是计算机编程的佳作：首先，作者fork了一个Linux内核（https://github.com/haileys/linux/tree/win9x-um-6.19 也就是一个叫做 win9x-um-6.19的分支），这个内核里面对posix API的调用都被改写成了对Windows 9x kernel API的调用，而且直接运行在了ring 0权限级别（Win9x那个年代真的是好宽松啊，难怪CIH可以瞎搞），当然，作者还做了很多的改动，在 https://github.com/haileys/linux/tree/win9x-um-6.19/arch/um/os-Win95 这边有一些和OS实现相关的具体改动的代码。

有了一个能运行在Win9x上的Linux内核，接下来需要的是什么呢？一个病毒VxD驱动！这个技术在早年的病毒和反病毒大乱斗时代可是非常流行的，而这个看起来已经退出历史舞台的技术，在今天这个wsl9x项目中焕发了新生：正是通过自己开发的一个VxD驱动，可以加载前面魔改的Linux内核（vmlinux.elf，需要用到 https://github.com/richfelker/musl-cross-make 来交叉编译），而编译Windows这边的代码呢？你还在用VC 6.0吗？作者又展示了一个上古神器——Watcom C/C++编译器（当然，这里用的是它后来开源的版本Open Watcom V2）

最后，整个wsl9x的最后一块拼图是一个叫做 wsl.com 的16位DOS应用，恐怕今天对这个扩展名还有所了解的都是老登了，这个程序用ASM汇编代码开发，可以让运行的魔改Linux内核的TTY子系统以MS-DOS窗口的形式展示出来，酷！注意哦，这个TTY并不是去用Windows 9x提供的键盘输入，作为运行在ring 0的代码，它可以直接去监听IRQ（中断请求）然后获取硬件的键盘输入，是不是一个很好的防止恶意软件攻击的方法？你甚至可以认为这就是一个Win9x时代的TEE嘛！

作者还非常骄傲的在项目描述里面留了一句话：

Proudly written without AI.

而作为知识无敌的AI一代，评论看起来就很滑稽：

我们80后只是老了，不是亖了，还轮不到 “http://wsl.com” 这种言论来指指点点~

另外，很多人都提到了当年很有极客精神的另一个项目——coLinux，虽然今天已经停止开发了，第一次接触到这个项目的时候那种震撼还是记忆犹新的。

顺便也安利其他的一些京口北固亭怀古项目：

https://netpcforum.org/t/2025年了-我开发了一套-rpl-win98-无盘-为了年少时的无盘梦想/119154

项目：https://codeberg.org/hails/wsl9x

阅读原文

跳转微信打开

买卖star，AI有责！

那些年我们学过的语文课文中，有很多在记忆中闪闪发光的文字，比如曾经在初中课本中出现的《这不是一颗流星》，今天读起来依然比许多文字更有温情和力量：

有时候一颗真星（心）胜过几百万颗star，我们今天介绍的这篇ICSE 2026论文 Six Million (Suspected) Fake Stars on GitHub: AGrowing Spiral of Popularity Contests, Spam, and Malware 应该推荐到315晚会上，给大家曝光一下GitHub上那些花钱买star的乱象：

论文上来就放出了一张触目惊心的图片：

这是一个看起来关于“以太坊杀手”——Solan区块链的相关repo，你以为它是一个好项目——因为它有111个star？实际上，本文的作者通过他们开发的一套叫做 StarScout 的工具分析发现，这其中至少有109个star是来自非真实用户的！而这个repo其实是一个恶意的repo，一旦使用了就会被盗走资产……

从这个例子出发，我们今天介绍的论文揭开了GitHub上和star相关的乱象：作者分析了20TB的GitHub元数据，涵盖了从2019年到2024年67亿个事件和3.26亿星数，并识别出了600万被怀疑刷的虚假星数，涉及了超过30万个账户。听上去是不是很吓人？更加令人瘆得慌是下面这个趋势：从2024年开始，“付费刷星”这种情况开始疯涨，2024年7月的时候，GitHub上16.66%的项目（50及以上星数）都涉嫌在刷数据！

简单说一下本文作者开发的 StarScout 工具，它主要是分析了那些去标记star的GitHub账号的特征：首先观察这些账号是不是只点了star然后就没干别的事情了，其次是分析是不是有一批账号经常一起给某个项目点star，通过这两个基本的原则，再加上一些数据分析的技巧（这里就略过不表了），就能识别出来所谓的“fake stars”了。

借助 StarScout 工具的分析能力，作者深入调研了fake star这个生态，其中很有意思的一个发现是这样的：

嗯，历史经验告诉我们，大热的研究方向都是充斥着泥沙的~ 另外，本文还关注了GitHub官方的态度，作者也表扬了官方：他们发现到2025年1月，有90.42%的涉嫌刷星数的项目已经被官方移除，这是因为这些项目大部分涉及到了malware、钓鱼等安全问题，当然作者的这个工具也许只能发现部分有问题的项目，官方可能还有更多的一些背景数据能够帮助发现这种的刷数据的行为？总之这个产业链看起来一时半会是不会消亡的，因为现在这个行业还挺兴旺的，在另一篇报道（https://awesomeagents.ai/news/github-fake-stars-investigation/ 不是学术论文），记者调查了这个“造星”市场，发现服务不同，当然也对应了不同的价位：

更为有意思的是，记者调查了一些流行的AI项目，发现这里面的openai-fm居然有66%的star是刷出来的，不过这个调查并没有说是哪个openai-fm，而我们在GitHub上去查了下，官方的openai-fm（https://github.com/openai/openai-fm 只有2.8K star）好像是唯一符合的，所以到底是之前有一个李鬼项目，还是openai-fm本身的有水分的star被删除了，不得而知~

实际上，刷排名这种人类最喜欢的行为并不是第一次被研究论文分析了，清华大学段海新老师研究团队在ACSAC 2020年的论文Understanding Promotion-as-a-Service on GitHub对国内的一些这种“服务群”进行了调研，而2014年的IMC 论文Paying for Likes?: Understanding Facebook Like Fraud Using Honeypots更早就对脸书上的所谓“like fraud”进行了分析。

写到这里，编辑部突然想起以前听说过的一件事情：据说现在很多中小学里面有一些学生很social，同学们都有ta的微信，然后ta就会像李彦宏一样搞竞价排名让那些需要得到关注的同学付点钱，ta就发个朋友圈去at一下这些付钱的同学，让所有人都关注到这些“小金主”们。当时那篇文章还说到“注意力经济已经渗透到了少年中”，于是我们注意到这篇论文的开头引用了这么一段话，引人深思：

联想到科研里面的各种乱象（比如什么动不动就数论文篇数，呃注意我们并不是说CSRanking），还有之前我们介绍过的关于刷CVE的研究【G.O.S.S.I.P 阅读推荐 2025-09-15 CVE：学术界的"水论文神器"还是真正的安全指标？】，再看看今天的这个研究工作，大家有没有思考过，这种以定量排名来评估的方式，何尝不是一种劣质的优绩主义思想？你看看人家Fabrice Bellard在他的主页 https://www.bellard.org/ （破旧的页面，没有任何前端水平）上有说过他拿了多少star吗？

最后，还记得前段时间“小龙虾热”的时候，有这么一个新闻：

而关于fake star的新闻报道里面有这么一句话：

A GitHub star costs $0.06 at the low end. A seed round unlocks $1 million to $10 million. The math is obvious, and thousands of repositories are exploiting it.

现在想想，你还在为AI降临欢呼吗？

论文：https://arxiv.org/pdf/2412.13459

跳转微信打开

SSH 守株待兔~

小学语文老师教过我们一个成语——守株待兔，小时候可能觉得这个成语的主人公太傻了，怎么可以就在那里等下一只兔子呢？到了互联网时代，这个行为可能不但不愚蠢，反而还有些价值：比如今天我们要介绍的这项研究工作以及对应的IMC 2025研究论文 Attacks Come to Those Who Wait: Long-Term Observations in an SSH Honeynet 就用了三年多的时间“守株待兔”，深入分析了SSH网络攻击在最近几年的演化趋势。

SSH蜜罐并不是什么新的技术，已经发展了几十年了，对于攻击行为的分析，更像是一种新闻报道：要么有深度有么有广度。本文正是这么一项有耐心的研究：作者从2021年12月开始部署蜜罐，然后持续观察了差不多3年，直到2024年8月才结束实验，这其中总共只关机了48小时，其余的时间一直保持着蜜罐的可用性。经过这么长的时间，他们总共收集到了超过6亿个session，其中和安全攻击相关的session有5.46亿，涉及到85万个不同的IP，这样看起来确实是非常有深度和广度。

大家可能会好奇，作者是怎么部署蜜罐的呢？这里他们是和 Global Cyber Alliance (GCA) 组织合作，用了开源的Cowrie Honeypot suite并进行了自定义，感兴趣的读者也可以去试用一下这个套件。

作者观察了攻击者的行为，发现攻击行为也不全是一致的，有一些攻击只会扫描端口和服务，有些攻击则是尝试爆破然后登录，但是什么也不做，还有一些攻击在登录了之后就开始执行特定的命令。作者统计了所有执行命令的攻击，看哪些对蜜罐系统的状态产生了影响，下图是整个实验期间的统计：

作者还从2025年IEEE S&P论文Hey, Your Secrets Leaked! Detecting and Characterizing Secret Leakage in the Wild（是东南大学、奇安信技术研究院星图实验室与清华大学联合完成的哦）中学到了一个基于regex匹配的技术，用来对攻击中执行的脚本命令进行了分类，在论文的附录里面有一个很大的表，大家可以去看看。

论文还把攻击中涉及到的文件（攻击者上传到蜜罐并使用的文件）进行了归类（下图），作者根据文件的hash去查VirusTotal这种数据库，但是能识别出来具体身份的bot不多，所以继而又进行了行为分析，把这些文件和botnet、挖矿、DDoS攻击关联起来：

在这篇论文中，作者重点讨论的是一个叫做mdrfckr的bot（据说和一个叫做Outlaw Hacking Group的组织相关），因为它是本文调查过程中观测到的最大规模的攻击相关的bot，而且它的行为非常有意思，论文的第9章详细介绍了mdrfckr的攻击行为。mdrfckr在攻击实施后就开始植入自己的公钥，然后用rsync去下载恶意文件。这些看起来都很常规，但是mdrfckr存在很有意思的“黑吃黑”行为：它会去检测机器上是否有另一些恶意软件，比如有一个叫WorkMiner的挖矿木马，如果存在就会移除这个挖矿木马设置的/tmp/auth.sh和/tmp/secure.sh（但是并不阻止挖矿行为），使得攻击者能够解除限制去远程控制这台SSH主机。作者对mdrfckr背后的IP进行了交叉分析，发现和其他一些挖矿、DDoS团伙使用的IP有交集，这说明这背后很可能是同一伙人。而且很有意思的是，作者还发现尽管mdrfckr每天都产生了超过10万的攻击会话（背后是6千个不同的IP），但是有一些阶段它会突然降低攻击流量，不知道是为了减少关注还是把攻击的机器拿去做其他事情了？

本文的研究发现了一个很有意思的现象：灰黑产组织真的是在与时俱进的，就拿SSH口令爆破这种1988年Morris Worm就干过的事情来说，攻击者会根据最近的一些安全事件不断调整尝试策略。比如在整个观察中，作者发现了一个很神奇的口令——“3245gs5662d34”，正常人谁会用这个口令？而且作者还发现，在使用这个口令尝试登录后（当然是被骗登录），攻击行为似乎并没有什么后续了，实际上这个攻击开始于2022年的12月8日UTC时间18:00，后续一共有2400万个session尝试使用这个口令，而且关联到了12.5万个IP地址，这也是在整个观察过程中仅次于mdrfckr的第二大攻击行为。经过一番调查，作者发现这个口令似乎和 Polycom CX600 IP telephone 这个产品有关，而且特别有意思的是，作者还发现，这个攻击和一起商业行为紧密联结：2022年惠普（Hewlett Packard）对 Polycom CX600 IP telephone 的生产商完成了收购，而就在收购之后这个攻击就出现了，这不禁让人浮想联翩啊，可惜这背后的故事没有再往下深挖了（期待有后续）。另外要说的是，这个口令似乎是被人挖出来然后卖给了很多不同的黑产集团？因为mdrfckr也在同一时期使用了这个口令！

在整个观察过程中，恰好遇上了俄乌战争的爆发，作者也发现在网络空间中，安全战场的硝烟味一样浓厚：在2024年初，作者观察到一个很奇怪的攻击模式——攻击者从4个IP连接到了作者部署的180多个蜜罐系统，然后用这些蜜罐去启动了差不多20万个curl请求会话，访问俄乌两国的电商、贸易、数字货币和游戏网站，企图实施攻击，这种攻击模式把蜜罐当成了proxy，这也让作者惊出了一身冷汗：本来以为做了无害化处理，没想到蜜罐依然被攻击者利用了。。。

总之，不管AI在安全研究工作取得了多大的成就，许多深入的分析依旧需要时间去检验，不过说不定在老老实实搞科研这个维度上，AI才是真正吊打人类的？我们期待未来有更多AI辅助的“长期主义”安全研究工作出现。

论文：https://dl.acm.org/doi/10.1145/3730567.3764475

跳转微信打开

三篇论文，打崩英伟达！

在古早的动画片《圣斗士星矢》中，有一个非常非常厉害的招式“雅典娜之惊叹（Athena Exclamation）”，看过动画片的老同学们应该都知道这个招式的威力。今年的IEEE S&P上，安全研究人员在面对AI的威胁时，总算想到了还手：来自多伦多大学、北卡教堂山分校、普渡大学、佐治亚理工、Clemson大学、Rochester大学等机构的研究人员贡献的三篇论文形成三位一体之势，爆出了针对英伟达GPU（或者把锅甩给三星？）的Athena Exclamation，誓要将老黄的战争武器撕成碎片！

关于这三篇论文的背景，看题目就可以追溯到两条主线：一条是经典的内存破坏漏洞及利用，另一条则是最近几年非常火热的Rowhammer攻击。关于这些背景知识，大家可以去看看我们的历史推送。反正你只需要知道基本的策略：利用Rowhammer让GPU上的显存产生错误，然后一步一步 把大象塞进冰箱 完成复杂的内存攻击和提权攻击即可。我们不妨先从GPUBreach: Privilege Escalation Attacks on GPUs using Rowhammer这篇论文讲起，因为它号称在三篇论文中能够实现最宽泛的攻击（见下表，能在IOMMU开启的情况下完成从GPU到CPU的攻击链并实现提权）：

关于这个攻击，首先可以参考GPUBreach这篇论文的研究组在USENIX Security 2025上的前序论文GPUHammer（也被认为是第一篇系统性研究GPU显存的Rowhammer问题的论文），因为所有的Rowhammer攻击都需要去想办法精确控制内存翻转的位置（否则没有什么攻击的意义了）。这里面通常用到的技巧包括对内存布局的研究（比如通过分析驱动程序来理解物理内存的使用）、耗尽（其他）物理内存以缩小攻击范围等等。

当然，我们之所以在今天推荐这几篇文章，其中一个原因是GPUBreach这个研究承诺在4月17日（也就是今天）公开论文和代码（在GPUBreach网站上说“The reproduction package and scripts will be available soon on GitHub: https://github.com/sith-lab/gpubreach after April 17”），不过截止到我们发稿的时候，还没有看到内容，请大家以朝阳区群众雪亮的眼睛监督作者及时公开材料！！！目前在GPUBreach网站上只有一个视频，大家可以先观看一下：

GPUBreach研究中包含了两个方面的亮点：第一个是他们针对页表项（Page Table Entry，PTE）进行Rowhammer攻击的精确控制，虽然论文没放出来，但是网站上有一些基本的介绍：

第二个亮点是作者宣称实现了一条完整的从GPU到CPU再到内核提权的攻击链，甚至在开启了IOMMU的情况下（IOMMU会限制GPU和CPU的内存共享）也能实现攻击，这其中必然用到了一些trick，让我们期待论文的公开！

尽管GPUBreach还没开放，另外两篇研究工作GDDRHammer:Greatly Disturbing DRAM Rows — Cross-Component Rowhammer Attacks from Modern GPUs 和 GeForge: Hammering GDDR Memory to Forge GPU Page Tables for Fun and Profit 目前已经可以公开访问，我们也继续看看这两篇论文的细节

https://gddr.fail/files/gddrhammer.pdf
https://gddr.fail/files/GeForge.pdf

我们首先关注三篇论文的共同之处：它们都是利用Rowhammer攻击去针对GPU的page-table，主要的不同在于对GPU实施攻击（执行GPU侧的任意内存读写）之后，继续攻击CPU这一侧使用的方法的差异（又变成了exp利用大赛，AI这时候是不是有话说）。GDDRHammer研究的主要亮点之一就是号称比以前的工作（对，就是GPUHammer）能够多产生差不多64倍的内存翻转效果，当然在今天之前，它也号称是全球第一个GPU-to-CPU Rowhammer exploit~ 关于内存翻转攻击这个部分我们就不详细介绍了，大家可以去看看论文，今天重点介绍一下所谓的“Hijacking CPU Memory Via the GPU”攻击。

实际上这种从一个外来domain去攻击kernel内存的想法在TEE时代就经常看到，由于内核需要和TEE通信，常见的做法是内核这边开辟一块共享内存，然后把内存的地址丢给TEE让它去写，如果攻击者能把这个地址劫持了，让TEE去修改本来不应该修改的内存（注意，在TEE那边对内存进行处理是不受内核权限访问控制的），就可以实现攻击。而GPU-to-CPU攻击的想法也差不多，先把GPU这边的页表给改掉（用Rowhammer），让特定的高权限GPU显存页面可以被普通的GPU进程（“进程”这个词不太准确）代码访问，然后攻击者就直接去访问自己的PTE页面了。更重要的是，显存的PTE表项里面有一个“APERTURE”参数，代表了这个页面指向的是GPU还是CPU的内存（显然是在没有IOMMU的保护下，CPU和GPU之间实现了统一内存访问了），那么攻击者改掉这个参数，再改掉PTE里面的物理地址，就可以很方便地实施针对内核的任意内存读写了（太简单了是不是~）

和GDDRHammer研究相比，GeForge这个研究的思路几乎是一样的（幸好两篇论文一起投稿了），最后的攻击除了对显存中的一些敏感信息（比如模型数据）的提取，也有一个针对内核的任意内存读写攻击，所以两篇论文放在一起读，审稿人显然是节省了很多工作量（不过也并没有多加两个鸡腿，都是义务劳动）。大家可以自己去找找两篇论文中的一些差异，细节里面有很多有趣的内容。

最后我们想说一下，这三篇论文都有一个比较大的问题，那就是针对GPU的Rowhammer攻击到底是不是一种稳定的攻击方式？首先所有论文都集中针对了特定型号的老黄家显卡——NVIDIA RTX A6000（注意，这不是RTX 6000！）以及它们使用的GDDR6显存。GDDRHammer的作者说他们测试了搭载了GDDR6x的ADA RTX 6000（注意，下表是作者的typo，实际上并没有什么ADA RTX A6000，这里要给论文扣一分），发现并没有办法产生Rowhammer攻击。

而GeForge的作者测试了其他的一些显卡（RTX 3080、RTX 4060、RTX 4060 Ti、RTX 5050，其中除了3080用的是GDDR6X显存，其他都用了GDDR6显存），结果发现除了RTX A6000之外，只有RTX 3060会受Rowhammer攻击的影响，其余的显存根本产生不了比特翻转。

这就让我们产生了一点点疑问：在PC DIY时代，对硬件的评测大家都知道是很难做到公平的，因为你测试的那块样品和玩家们手上的设备可能存在亿点点差异，更不要说测试的机器（电源、散热）可能也会严重影响各种运行，Chiphell论坛上那些中年富哥天天吵来吵去不是没有道理的。此外，今年是2026年，但RTX A6000（和RTX 3060）是2021年发布的产品，也许从发布到测试这段时间，显卡经历了很多（比如矿潮到矿难）也不一定？

GPUBreach https://gpubreach.ca/
GDDRHammer & GeForge https://gddr.fail/
GPUHammer（USENIX Security 2025的前驱工作） https://gpuhammer.com/

跳转微信打开

大家在使用ChatGPT、Qwen、Llama这些经过安全对齐的大模型时，一定遇到过这样的情况：问个“如何用菜刀切西瓜”被拒绝了，或者稍微换个说法就把不该说的话全说出来了。这两种现象在学术界被称为over-refusal（过度拒绝） 和 jailbreak（越狱） ，是当前安全对齐领域最核心的两个痛点。

更让人头疼的是，这两个问题不是独立的——它们之间存在一个看似无法打破的trade-off：让模型更保守，越狱减少了，但动不动就拒绝正常问题；让模型更开放，过度拒绝改善了，但坏人又钻空子了。现有的“向量操控”（vector steering）方法——通过调整模型内部表示来改变行为——本质上都是在调整“回答向量”的幅度（magnitude），这就好比拧水龙头：拧小了漏不了水，但也出不了水；拧大了水来了，但脏东西也进来了。这个trade-off，似乎是无解的。

来自浙江大学的研究团队发现，这个trade-off并非无解。他们的论文LLM-VA: Resolving the Jailbreak-Overrefusal Trade-off via Vector Alignment已被ACL 2026 Main Conference录用。

问题的根因：两个判断向量正交

研究团队在模型内部提取了两个方向：回答向量（反映模型是否倾向于回答）和良性向量（反映模型对输入是否安全的判断）。他们发现，在几乎所有被测试的大模型中，这两个向量在各层之间的夹角都接近90°——近乎正交。

这一现象揭示了一个深刻的问题：大模型把“要不要回答”和“输入是否安全”当作两个完全独立的过程在处理。 于是，模型有时候“判断出输入是安全的，但就是不回答”（over-refusal），有时候“明明感知到了有毒输入，却还是回答了”（jailbreak）。两个决策互不知情，自然就会各自出错。

现有方法只调整的幅度，没有把“是否回答”和“是否安全”关联起来，所以无论怎么调，都逃不开这个trade-off。

解法：让“回答意愿”因果地依赖“安全判断”

LLM-VA的核心思想非常直接：把对齐到的方向上，让模型“要不要回答”的决策在因果上依赖“输入安不安全”的判断。具体分三步走：

第一步：用SVM识别各层的控制向量。 在每一层分别训练两个线性SVM，分别找到区分“良性/有毒”和“回答/拒绝”的最大间隔超平面，其法向量即为和。选择SVM的原因是它提供可解释的线性决策边界，间隔最大化保证了向量的鲁棒性。

第二步：筛选与安全决策最相关的层。 不是每一层都对最终的安全行为有同等贡献。LLM-VA用一个综合得分来选层：

其中衡量该层向量与最终残差流的对齐程度（影响力），衡量该层SVM的分类准确率。乘积形式确保选出的层既有影响力又足够准确，缺一不可。实验也验证了一个直觉：靠后的层对安全决策更重要，靠前的层则更多承载通用能力——修改前者伤害小，修改后者要小心。

第三步：闭式权重更新完成对齐。 不需要梯度下降，不需要微调，不需要改模型架构，直接用伪逆给出最小扰动的权重更新：

其中是归一化因子，确保良性输入在方向产生正投影、有毒输入产生负投影。由于修改某一层权重会影响后续层的有效向量方向，方法会迭代地重新提取向量并更新权重，大多数模型在20–30次迭代内收敛。

实验：12个模型，全面超越基线

研究团队在12个主流开源指令微调模型（涵盖Llama、Gemma、Mistral、Phi、Qwen五个系列，规模3B–14B）上进行了实验，覆盖jailbreak和over-refusal两类数据集，并与VectorSteer、AlphaSteer、SCANS等基线方法对比。

• 综合效果（F1）：LLM-VA平均F1达0.77，比最优基线AlphaSteer**相对提升11.45%**，同时将越狱成功率（ASR）和过度拒绝率（ORR）分别降低了18.50%和22.00%。

• 通用能力保留：在语法、自然语言推理、情感分析、数学（GSM8K）等6个benchmark上，LLM-VA平均保留了**95.92%**的原始能力，优于所有基线方法。相比之下，SCANS由于激进的幅度调整，通用能力平均损失达40.98%。

一个特别值得关注的现象是LLM-VA的自适应性：对于越狱风险高的模型（如Mistral-v0.3-7B，初始ASR高达81%），它会优先压制越狱；对于本来就过于保守的模型（如Llama-3.1-8B，初始ORR高达53%），它则优先缓解过度拒绝。这种自适应行为完全来自向量对齐的内在机制，无需为每个模型手动调超参数。

小结

LLM-VA提供了一个清晰的诊断：安全对齐的两难困境，根源不在于对模型的控制力度不够，而在于控制的方向错了。把“是否回答”和“是否安全”这两个本应深度耦合的决策对齐起来，才是正路。方法无需微调，无需改架构，只需要少量标注数据训练SVM，便可为不同家族、不同规模的模型一键提升安全性能。

论文：https://arxiv.org/abs/2601.19487

代码与权重：https://hotbento.github.io/LLM-VA-Web/

跳转微信打开

安全人员的末日到了吗？

今天大家都被 交通大学130周年校庆 Anthropic的Claude Mythos模型刷榜了吧？对于2000后安全研究人员来说打击可能蛮大的，但是我们80后（包括部分90后）根本不在乎，因为我们是刘欢老师熏陶下成长起来的一代人！

嗯，人生其实没有什么再来的机会了，都是给AI做bootloader，不过我们今天想讨论的是一篇2011年的文章Exploit Programming，在这篇文章中，作者讨论了一个叫做weird machine的概念，并把它和计算机安全联系在一起。如果你读了这篇文章，你就不会对Claude Mythos在安全上有如此突出的表现感到惊奇：

（可能大家也注意到了这篇文章还纪念了其中的一位作者Len Sassaman，他是一位英年早逝的黑客，在2011年受抑郁症困扰而离世，而许多人甚至认为他就是中本聪）

从事安全研究的人群往往有个不太好的自恋情结，就是认为开发exploit是一种更加高级的技巧，毕竟它是像高德纳在图灵奖获奖感言里面提到的“在针尖上跳舞”一样的编程。而在Exploit Programming这篇文章中，作者认为，完全无需神话exploit开发，只需要理解漏洞利用的实质。作者首先从Aleph One经典的 “Smashing the Stack for Fun and Profit 开始回顾，继而提到了return oriented programming：作者把这种行为叫做“borrowed code”，听上去很形象对不对（只借不还~）

而正是从这种向系统“借”代码来执行的思路开始，我们正式进入到了weird machine的范畴：对于正常的程序来说，代码执行是CPU的“取指-译码-执行”循环，而ROP其实无非也就是另一种CPU而已，只不过是用了一些已有的code snippet来做虚拟的指令，这个就是很经典的虚拟机解释器对不对~

更加深入一点，我们还能想起来Stephen Dolan的论文：

https://drwho.virtadpt.net/files/mov.pdf

实际上还有人实现了一个只有MOV指令的CPU（很应该申请个发明专利）：

https://justanotherelectronicsblog.com/?p=771

好了，到目前为止，我们知道，除了正常的CPU指令，也可以用很多其他的方式来充当所谓的weird instruction，然后再把这些weird instruction拼接起来就可以实现很复杂的功能了！毕竟只要是图灵完备的计算系统都是等价的对不对~

历史进展到了2009年，在计算机研究的重镇Dartmouth，我们今天推荐的文章的第一作者Sergey Bratus在一次演讲中正式提到了weird machine的概念，并且认为hacker和码农一样都是代码的小商品生产者，并没有什么区别（当然也是这些小手工业者共同催生了代码资本主义也就是AI coding）

https://www.cs.dartmouth.edu/~sergey/hc/rss-hacker-research.pdf

到了2011年，zynamics的创始人Thomas Dullien（a.k.a Halvar Flake）做了一个非常烂懒的slides，讲了exploitation开发里面的各种思考：

当时Thomas Dullien还列了这么个例子，说静态分析没法很好找到bug，你知道问题在哪吗？（快使用Claude，呵呵哈希）

基于上面这个例子，在Exploit Programming文章中，作者认为：

The “weird machine,” then, is simply a concise description of the transition-based computational structures in this exploded space

这里面隐藏了一个很有意思的讨论：weird machine背后影射的是程序的状态转移的巨大空间，足够exploit去实施各种行为，我们也许并不应该惊讶于AI能够很好地写出exploit，而是应该去思考另一个问题：完全探索复杂的状态转移是否可行？如果不行，那么我们真的觉得AI就能找到所有漏洞吗？（当然，只要能把现在的安全研究人员斩杀了就行，而且历史是这样教育我们的：“小生产者在自由竞争中必然要发生两级分化。因为商品是按照它的价值量田生产商品的社会必要劳动时间来进行交换的，在这个价值规律的作用下，大多数小生产者由于生产规模较小，技术落后，生产商品的劳动时间往往超过社会必要动劳时间，因而在竞争中就逐步陷于贫困破产，失去生产资料,变为无产者;而少数生产规模较大、生产条件较好、技术比较先进的生产者，生产商品的劳动时间少于社会必要劳动时间，因而在竞争中就居于有利地位，逐渐排挤、吞并其它小生产者，占有越来越多的生产资料，成为资本家。”）

既然提到了weird machine，那就不得不提到一代神作Baba is You了（居然有在线版了 https://kbhgames.com/game/baba-is-you ！！！）：

原文：https://langsec.org/papers/Bratus.pdf
资料汇集：https://www.cs.dartmouth.edu/~sergey/wm/

阅读原文

跳转微信打开

以下文章来源于：BlockSec

BlockSec聚焦智能合约全生命周期安全，提供安全区块链基础设施。核心成员毕业于海内外知名高校，兼具学术界前沿研究背景和头部安全公司产业化经验，先后获得头部美元基金和区块链知名基金的数轮投资。

BlockSec 与浙江大学联合完成的研究论文 《Thought is All You Need: Smar

阅读原文

跳转微信打开

QCP 2.0，为SJTU 130周岁献礼~

三月的最后一期公众号文章推送，我们给大家介绍来自SJTU（对，就是那个马上要130周岁生日的上海西南某高校）的一款黑科技工具（想多了，不是AI）。大家还记得去年的文章【2025 Let’s GoSSIP 软件安全暑期学校预告第三弹——Qide】中介绍的Qualified C Programming（QCP）吗？

在暑期学校期间发布的QCP是一个萌新版本（1.0），大半年之后，当所有人都在讨论AI什么时候斩杀程序员的时候，QCP团队给大家带来了全新升级版的QCP 2.0，同时也带来了全新的qua.codes网站：

网站上除了能够导航到原来的在线IDE ( https://ide.qua.codes )，还提供了全新的tutorials，以及github的开源代码下载链接！

而在这个AI降临派每天都在积极发帖的年代，QCP也迎合一下他们的需求，引入了AI协作能力！

最后预告一下：QCP团队计划在近期发布 QCP 2.0 的 Lean 版本套件，Lean 用户敬请期待！

阅读原文

跳转微信打开

来，LLM也能缓存投毒

前几年web安全研究方向有一个很有趣的议题是针对CDN的缓存投毒攻击，核心攻击思路在于利用了CDN在服务不同用户的相似请求时可能会缓存并重用相关资源，从而造成（机密）信息泄露等危害。这几年随着LLM的飞速发展，攻击者很自然地就能把类似的攻击思路迁移过来，于是就有了我们今天要推荐的这篇NDSS 2026会议论文 When Cache Poisoning Meets LLM Systems: Semantic Cache Poisoning and Its Countermeasures 的相关研究内容：

首先了解下基本原理：万恶的厂商为了降本增效，肯定要想方设法减少算力的开销，因此如果遇到不同的用户提出了相似的问题（例如下图这样的），是不是可以把答案（突然想到这几天大家吵得很凶的“词元”这个翻译）缓存起来，节省相关的算力消耗呢？（当然，人家说不定还继续问你要“词元”的费用）

在这个方面，比较出名的是GPTCache这个方案，它实现了一种叫做 semantic caching 的设计，也被 AWS、阿里和 Azure 用在了实际的生产环境。在厂商眼中，semantic caching 的技术栈是下图这样的：

但是在那些研究web安全的玩家眼中肯定会放出来不一样的光芒：前几年讨论得火热的CDN投毒攻击，这不马上又有了新的用武之地？

不过对LLM投毒最困难的是怎么去“污染”LLM的回答，比如前面提到的例子，攻击者得想办法让LLM给出一个错误的答案（例如“NDSS 2026在鹤岗召开”），然后还要让错误的答案对应相关的问题，里面有很多的挑战。首先是攻击者要去构造一个 malicious query 来诱导LLM回答，然后这个 malicious query 还得和普通的问题足够相似，这样会被 semantic caching 机制选中，才能起到污染的效果；其次是怎么保证 malicious query 能够产生特定的污染效果。

要让 malicious query 和普通的问题类似，作者说这里只需要很简单的把普通的问题作为一个 malicious query 的前缀就好了：

而要让LLM回答出错，就要使用特定的 prompt engineering 去引导它，这方面估计我们的读者更有经验？各种大模型越狱比赛肯定能培养出很多“污染小能手”吧~

总之最后攻击成功的效果就是把一些恶意的答案注入到 LLM 服务的缓存里面：

比较有意思的是，文本生图（Text-to-Image Generation）也可以用这个方法注入（你能看出来下图中的注入内容了吗）：

作者去调查了相关的服务（AWS、阿里和Azure的产品），同时也自己部署了GPTCache来测试，发现攻击的成功率蛮高的：

不过这个也提醒了厂商，以后可以搞一个VIP服务，如果不充钱，就给你用可能会被污染的缓存结果，只要充了足够的会费，给用户一个专享绝无污染的超级大会员？

论文：https://dev.ndss-symposium.org/wp-content/uploads/2026-f200-paper.pdf
slides：https://www.ndss-symposium.org/wp-content/uploads/F0200-zhang-slides.pdf

跳转微信打开

很难想象哪个通信协议从上一个千年走到现在，版本从1.0走到了6.0，还充满了各种安全问题~

很难想象哪个通信协议从上一个千年走到现在，版本从1.0走到了6.0，还充满了各种安全问题。而蓝牙通信协议就是这么一个典型的“缝缝补补又三年”的案例：从1998年到现在，不停的迭代不停的修补，但是始终还是存在这样那样的安全问题。在NDSS 2026会议上，一篇名为BLERP: BLE Re-Pairing Attacks and Defenses的研究论文就首次针对蓝牙（聚焦于BLE也就是低功耗蓝牙）的重配对（re-pairing）流程设计了相关的攻击（相当搞笑的一点在于，这个re-pair不但没有repair安全问题，反而引入了安全问题）：

论文提出的安全攻击——BLERP attacks——是一系列针对蓝牙重配对的攻击，更具体一点，是四种特定的攻击，其中两种是身份模仿（impersonation）攻击，另外两种是中间人（MitM）攻击，下图展示了这四种攻击的大概流程：

再具体到实现层面，我们需要了解一点蓝牙的知识：平时大家使用的蓝牙设备可以分为Central和Peripheral两种类别，Central是那些主动去扫描其他蓝牙设备并发起连接的设备，而Peripheral则是被动接收连接请求的设备。在具体的通信开始前，为了保证安全，蓝牙协议要求设备之间先协商一个long-term Pairing Key（PK），然后再为不同的session去生成特定的fresh Session Key（SK），使用的密码算法和协议需要首先按照下图的流程去协商好，然后用ECDH进行密钥交换，最后的加密用的是AES-CCM模式。

现在问题来了，如果两个蓝牙设备已经配对成功，然后又需要重新配对，这时候应该怎么办呢？蓝牙规范里面对于这时候应该怎么处理，按照下面这个决策树（if-then-else）进行。可是这里面挂一漏万，被本文的作者逮到了好多漏洞——作者发现了6类漏洞，其中4类是全新的，2类是已有BLE漏洞在重配对这个场景下的扩展。

关于前面提到的4类全新的漏洞，其实理解起来也没那么复杂，核心就在于在重配对的时候，蓝牙规范并没有讲清楚这时候Central和Peripheral两方应该对重配对的请求进行怎么样的严格检查（特别是怎么和上一次的配对的安全级别进行对比），这就导致了攻击者可以在重配对的过程中把安全级别协商到比较弱的级别（感觉针对蓝牙通信进行安全降级攻击是标准套路了），然后发起攻击。反而是那两类已有漏洞的扩展可能还更加“高级”一点，第一类是在重配对的时候从整个流程的中间（而不是第一步）开始执行，第二类是重新协商一个entropy很低的PK，破坏相关机密性。

在实际攻击中，本文提出的所有攻击（两种身份模仿攻击和两种中间人攻击）都要综合利用上面的多类漏洞一起来实施，在论文的第四章中有详述，比如要冒充Central设备，一方面要利用重配对协议可以跳过开头的authentication步骤、从中间开始执行的漏洞，一方面也利用了Central和Peripheral设备双方可以接受更低安全级别的协商请求的漏洞。

当然，在实际的攻击中，除了在理论上操作，还需要底层硬件配套支持，因为需要进行一些身份仿冒攻击（比如模仿被攻击设备的蓝牙MAC地址），因此攻击需要特定的硬件（如下图所示的Nordic nRF52840-DK开发板），以及相关的蓝牙协议栈实现代码（比如NimBLE），作者开发了一个完整的叫做BLERP的toolkit，方便大家重现相关攻击。

作者在实验中测试了一大堆的设备，包括各种智能手机和平板、智能电视、蓝牙鼠标键盘、智能手表等等，测试结果（下表）表明BLERP attacks几乎影响了所有测试的设备：

读完这篇论文，顺便介绍一下作者在WOOT 2025的一篇相关的研究论文Bluetooth Security Testing with BlueToolkit: a Large-Scale Automotive Case Study，在这篇论文中，作者介绍了他们开发的BlueToolkit测试工具，对于蓝牙安全分析很有帮助。

https://www.usenix.org/system/files/woot25-zubkov.pdf

最后，让我们看看某些大厂对这个攻击的反应：

论文：https://www.ndss-symposium.org/wp-content/uploads/2026-f121-paper.pdf
代码：https://github.com/sacca97/blerp

跳转微信打开

2026年秋季，北京航空航天大学Web安全题组计划招收 1–2名博士研究生。主要研究方向聚焦Web安全与系统安全，尤其关注真实互联网环境中的攻防技术，包括浏览器指纹、浏览器安全、以及卫星互联网安全等问题。

研究方向

课题组主要研究 Web安全与系统安全，关注真实互联网环境中的安全问题与攻防技术，而不仅仅是论文中的理论模型。研究方向主要围绕浏览器技术、系统安全以及新型网络环境中的安全问题展开。

目前课题组重点关注以下几个研究方向：

1. 浏览器指纹追踪与反制

浏览器指纹技术已经广泛应用于互联网风控系统，同时也带来了隐私追踪问题。该方向主要研究浏览器指纹识别与设备关联技术，以及针对指纹追踪的对抗与隐私保护机制。相关研究包括浏览器指纹特征分析、设备识别技术、反追踪机制以及浏览器指纹生态的大规模测量与分析。

2. 浏览器与系统安全

浏览器是现代互联网最复杂的软件系统之一，也是安全研究的重要对象。该方向主要研究浏览器攻击面分析、漏洞挖掘、浏览器沙箱与隔离机制，以及浏览器与操作系统之间的安全问题，探索从浏览器内核到操作系统层面的系统安全问题。

3. 卫星互联网安全

随着低轨卫星网络的发展，新的网络架构也带来了新的安全挑战。该方向主要关注卫星互联网架构中的协议安全、系统安全以及相关攻防问题。

4. AI for Security

课题组也探索将 AI 技术应用于安全研究，例如自动化安全分析、漏洞发现以及安全检测等方向。

总体而言，课题组的研究风格更偏向学术研究与工业实践结合。希望关注真实互联网环境中的安全问题，并通过深入系统底层的技术研究，探索具有实际价值的安全技术和系统原型。

研究风格

课题组更倾向于 学术研究与工业实践结合的研究方式。关注的问题包括：

• 真实互联网环境中的安全问题

• 系统底层机制研究

• 可落地的安全技术和原型系统

希望博士阶段不仅能够产出论文，也能积累系统安全与工程实践能力。

实验室氛围

实验室强调灵活的科研方式：

• 不打卡

• 工作时间灵活

• 更关注研究进展而不是形式

只要研究持续推进，工作方式可以自由安排。

希望你具备

欢迎对安全研究有兴趣的同学联系。希望你：

• 对安全方向有热情

• 具备一定代码能力和工程能力

• 对系统方向或AI方向有兴趣

基本要求：会使用 C语言（学校入学考试需要）

优先背景：

• 计算机科学

• 网络空间安全

• 或相关相关专业硕士

招生信息

• 入学时间：2026年秋季

• 招生人数：1–2名博士

• 截止日期：2026年4月6日

联系方式

邮箱：buaasniper@gmail.com

微信：buaasniper_work

联系时建议附上：简历+项目或研究经历

如果你对浏览器安全、风控技术、隐私保护或系统安全研究感兴趣，欢迎联系交流！期待一起探索真实互联网中的安全问题！

跳转微信打开

3月份的《30天内挖掘100+内核漏洞：Windows驱动安全大危机？》文章刚出，2月份的NDSS论文就马上来碰瓷？

前几天（2026年3月2日）有个公众号发了个新闻，标题党得很，叫做《30天内挖掘100+内核漏洞：Windows驱动安全大危机？》，具体说的是什么呢？说的是有一个叫做Hexaplex AI的安全公司（这种命名风格最近非常多啊，挂着AI的名头），说他们构建了一个自主平台，从互联网各个角落抓取具有合法签名的Windows驱动程序，然后用AI去识别内存损坏漏洞，号称是对每个驱动的分析成本只有3美元，而结果是从158个不同的驱动程序二进制文件中发现了521处潜在漏洞，然后手动确认并向包括联想、富士通、IBM、英特尔、AMD、Silicom、英伟达和戴尔在内的供应商报告了15处漏洞。（不过只从富士通那边拿到了一个漏洞编号CVE-2025-65001）。

初读这篇文章，很多人肯定又是那个经典的先“哇塞”然后“x的，安全分析师又要完蛋了”的反应，不过我们如果把目光聚焦到几天之前召开的NDSS 2026会议上，那么在读完下面我们要介绍的这篇论文Unveiling BYOVD Threats: Malware’s Use and Abuse of Kernel Drivers之后，不知道你会作何感想？是不是让人想到了一种可能的商业模式：让AI快速学习最新的学术论文的研究成果，然后在这个基础上编提出来一套更为“AI而宏大”的理论和结果，接下来就走入到融资的道路上？算了，不能胡乱揣测，毕竟人家亚历山大王（Alexandr Wang）就是这种天才套路嘛，我们还是专注于介绍今天的内容吧！

前面其实已经把研究背景介绍得很清楚了：本文讨论的 Bring Your Own Vulnerable Driver (BYOVD) attacks 就是一种找到现有的合法驱动程序，在里面找到漏洞，然后拿这个有漏洞的驱动来当特洛伊木马（虽然这匹木马并不是自己想干坏事）的攻击方法。关于怎么实施具体的安全攻击，这里我们只能引用那段经典的废话——“这种事情我见的多了，我只想说懂得都懂，不懂的我也不多说了，说了你也不明白，不如不说，细细品吧，你也别来问我怎么回事，这里面利益牵扯太大了，说了对你我都没有好处，你就当不知道就行了，其余的我只能说这里水很深，牵扯到很多东西，详细情况你们很难找到的，网上大部分都删干净了，所以我说懂得都懂，不懂也没办法。” （或者你随便在网上搜索一下，例如 https://forum.butian.net/share/2832 这种文章也很多，哪有被删光的说法？）

打住打住，这部分大家还是去网上找教程或者看看论文的第二章去了解个大概吧，本文并不是教你搞黑产的，作者想要介绍的是对整个安全生态的调研：为了研究malware使用存在漏洞的驱动程序实施攻击的情况，作者首先开发了一套分析系统（如下图所示，是一个基于虚拟化的沙盒分析系统）来进行分析：

这套分析系统基于波兰安全研究人员开发的DRAKVUF Sandbox框架开发，DRAKVUF的好处是你甚至都不需要往guest OS里面写什么插桩代码，它直接就给你提供了Virtual Machine Introspection（VMI）功能，于是分析人员可以很轻松地记录driver loading and unloading routine执行、关键的内存管理API调用、IOCTL请求、kernel callback routine执行等关键事件，并把这些信息存储为特定的execution trace，供后续分析使用。

https://github.com/CERT-Polska/drakvuf-sandbox

为了区分什么是正常的驱动行为，什么是被攻击者利用然后干坏事的行为，作者列出了8条经验规则（论文的第IV.C章，这里不全部详述了），主要就是观察可疑的内存分配和关联的一些内核API的调用。而且，作者在论文的第IV.D章里面还介绍了一些可配置的execution trace记录方法，允许大家选择性地监控不同的行为。

作者还在论文的第五章介绍了关于怎么去寻找有问题的驱动，并且如何构建相关的数据集给后面的实验使用的过程，这里面提到了两个资源，第一个是一个由安全分析人员提交的，已经包含了1805个（且数量不断在增长）被人工确认有漏洞的驱动的集合，第二个则是微软自己维护的Microsoft Vulnerable Driver Blocklist：

[1] Living off the land drivers https://www.loldrivers.io/
[2] Microsoft recommended driver block rules https://learn.
microsoft.com/en-us/windows/security/application-security/application-control/app-control-for-business/design/microsoft-recommended-driver-block-rules

除了这些已知有漏洞的驱动，作者还对Windows全体驱动进行了筛选，只要符合下表的标准（存在可疑的导入表，即abusable imports），都选进来作为candidate进行分析：

作者总共收集了8779个可执行文件样本，涉及到加载773个（可能）有问题的驱动，然后进行了大规模的分析实验，实验里面很自然地分为了两部分：对已知恶意程序的分析和对未知恶意攻击的分析。针对已知恶意程序的分析看起来不是那么乐观：针对2995个样本的分析（已经确认它们和162个有漏洞的驱动相关联）表明，仅有10%左右的样本（304个）的动态执行看起来是有问题的（suspicious），而差不多一半的样本（1524个）就没真正执行任何的驱动加载行为，作者分析了半天，指出这就是传统的病毒分析里面的大问题——恶意行为如何触发，不过我们也感谢作者在这里没有提任何AI或者小龙虾，本来以为作者要靠万能的AI来让病毒分析变得更简单呢~

对于其中56.25%的产生了相关驱动加载行为的样本，作者表示，尽管没监控到什么可疑的行为（因为作者的sandbox只能监控一些事件，而不是进行指令级别的trace），但是经过查阅了相关文献，以及对部分驱动行为进行了人工分析，发现它们可能就变成了CTF pwn题目了——调用代码利用驱动漏洞直接去进行内存操作。作者表示，日后会开发指令级别的记录工具（召唤QEMU？）来增强分析。

但是你也别嘲笑人家作者的方法不够小龙虾，即使只是基于下表的特征筛选，作者针对潜在可能有问题的驱动进行分析，就发现了很多可疑的样本。

作者实打实地列出来了存在问题的驱动（如下表），并且在case studies章节里面具体讨论了这些驱动里面包含的高危操作，不过作者也没有很浮夸，只是说他们把这些驱动发给了微软和相关的厂商，然后只收到了一个CVE编号（CVE-2024-26506，针对probmon.sys）。

顺便提一嘴，大家有没有想过哪些驱动程序是容易被利用的漏洞大户？一开始你以为是硬件厂商，但是仔细想想还有什么更恶心的驱动？对，就是那些游戏厂商的反作弊检查代码，在2022年就有这么个例子：

安全公司趋势科技的研究人员报告，《原神》的反作弊驱动 mhyprot2.sys 被勒索软件利用杀死杀毒软件的进程和服务。mhyprot2.sys 作为设备驱动是与《原神》游戏分开安装的，卸载《原神》并不会卸载 mhyprot2.sys，早在 2020 年 9 月米哈游发布 《原神》时游戏社区就开始讨论具有间谍软件能力的 mhyprot2.sys。它很快被发现存在漏洞允许被利用杀死进程。开发者神楽坂早苗/kagurazakasanae 和 Kento Oki 分别发布了 PoC 演示了杀死进程的能力。Kento Oki 向米哈游报告了漏洞，但该公司没有承认也没有修复。勒索软件利用的 mhyprot2.sys 是 2020 年 8 月构建的，其签名至今仍然有效没有撤销。

上面的例子当然不是孤例，论文中列举了CAPCOM这个游戏巨头开发的capcom.sys反作弊驱动作为又一个反面教材（不过这个是2017年的旧闻了），说capcom.sys里面甚至学习eBPF搞了一个允许用户态发送代码过来给它执行的接口……实际上，就连V社都已经不能忍了：从2024年开始，Valve就强制要求游戏开发商在游戏介绍页面必须披露是否使用了内核级反作弊技术。

总之，驱动程序里面的问题确实很多，但是究竟是去关注那些基于AI智能体的安全分析营销文章，还是来学习这种传统的安全分析思路，这留给我们的读者自己去思考了（写这段话的目的其实是SEO，最近发现好像公众号文章里面不带AI和小龙虾，阅读量就一路下滑……此处重复OpenClaw一万遍）

论文：https://www.ndss-symposium.org/wp-content/uploads/2026-s1491-paper.pdf
Open Science：https://doi.org/10.5281/zenodo.15864111

跳转微信打开

谁在查看你的加密数据流量？

早在2016年，G.O.S.S.I.P曾经发表过一篇研究论文An Empirical Study of Insecure Communication in Android Apps，讨论了Andriod APP使用私有加密方案这一问题。人生如白驹过隙，一转眼10年过去了，想必大家都认为移动互联网总该是 HTTPS/TLS 满天飞了吧，而去年IEEE S&P的一篇研究论文报告的结果却让人大跌眼镜。在这篇名为WireWatch: Measuring the security of proprietary network encryption in the global Android ecosystem的论文中，来自普林斯顿大学和多伦多大学的研究人员指出，很多大厂开发的Android APP竟然还在使用私有加密流量，有些甚至还能被解密？！

当然，本文的研究结果一部分来自于作者的方法论——以往很多安全研究通常只分析 Google Play，因为它有现成的数据源，获取 APK 非常容易。但是由于在中国无法使用 Google Play，所以这些研究不能代表所有的情况。这一次，作者把小米应用商城中的 App 也纳入了分析目标，一下子就增加了很多的多样性~ 作者同时选取了 Google Play 和小米商城下载量排名前 1000 的 App 进行分析，然后设计了一个叫做 WireWatch 的工具，用于对安卓App的网络流量安全性进行大规模分析。分析过程主要关注两个事情：1、App交互过程中是否存在明文数据流量；2、App中是否使用非标准的、私有密码协议。

上图是WireWatch的工作流程，针对非标准密码协议的判断过程，该工具首先对数据流量进行采集，并将结构化字段剥离出来（例如base64和JSON格式），然后使用 NIST 随机性测试来判断数据是否像加密后的密文。最终判断，如果数据流量同时满足：1）不是 TLS / HTTPS；2）payload 含有疑似加密数据；3）加密过程位于应用层，则被认为是使用了非标准密码协议。

不过这篇论文虽然发表在了IEEE S&P上，在对于加密流量的分析上，技术含量略显不足，就是用了流量聚类和手工逆向分析的方法，而且在针对流量的加密方法进行逆向分析这部分，文章写得语焉不详，还不如我们在10年前的工作（不要忘记了现代人都用AI辅助的，怎么水平还这么落后）。

那就看看结果吧：作者的工具成功分析了 1699/2000 个 App（分析成功率为 85%）。从实验结果来看，国内 Android App 的安全性要远低于 Google Play 中的 App。65.4% 的 App 甚至还在明文传输数据，49.1% 的 App 都没有应用 TLS。还有 47.6% 的 App 更愿意使用自研非标准的密码协议（这里作者也承认，分析结果可能不够完整）。为了展示 WireWatch 工具识别非标准密码协议的准确性，作者还选取 92 个 App 进行人工分析，WireWatch 工具跟人工分析结果对比仅有 3 个 False Positive 和 1 个 False Negative。

WireWatch 使用无监督学习的聚类算法，对所有被认为是非标准密码协议的数据流进行聚类分析，最终得到 177 个非标准协议家族，其中 83 个家族协议被多个 App 所使用，剩下的协议有且仅有 1 个 App 在使用。其中，很多大厂生产的 App（我们知名的阿里、腾讯、快手、爱奇艺等等公司都被作者“点名”），大都会使用相同的（祖传的）非标准密码协议。

本文的灵魂拷问当然是这些不公开的非标准密码协议真的安全吗？作者继续重拳出击，仔细地对 18 个协议进行逆向分析（隶属9个协议家族）。结果发现这 9 个协议家族里面，有 8 个都存在严重安全问题，加密的数据都可以被攻击者解密（下表）。这背后的原因居然是密钥要么硬编码在代码中，要么是用一个固定种子作为输入，使用确定性算法来生成的。即使有协议使用了 RSA 算法保护对称密钥，但是他们居然用的是 Textbook RSA。除此之外，部分协议还存在很多其他问题，导致隐私数据的泄漏。

最让人感到不安的，可能还是这些出现如此低级错误的 App，居然都来自大公司之手，并且有着非常高的下载量，文章里面有相关的细节，什么蚂蚁mPaaS SDK、数美SDK还有腾讯的WUP（针对它家的攻击可以出一个密码题目让AI来试试看）都被重点圈出来了。（好在微信被作者划分到了安全的行列，所以小编可以继续安心地在公众号分享文章）

看到上面的表格，再关注一下下面的事实：

《中华人民共和国密码法》于2019年10月26日通过，并自2020年1月1日起施行，旨在规范密码应用和管理，保障网络与信息安全，维护国家安全和社会公共利益。

论文：https://jeffreyknockel.com/publications/oakland2025wirewatch.pdf

跳转微信打开

Wi-Fi client isolation，一个美丽的谎言

最近我们的公众号更新比较不积极，因为各种事情很忙，不过我们还是坚持古法写作，不用AI，因为大家可能都听说了Ars Technica网站的一个专门报道AI相关新闻的记者用AI写作，发了一篇子虚乌有的文章然后被打脸最后离职的新闻（这个新闻怎么感觉也像是AI写的）。那今天趁着周末来给大家推荐下前不久刚刚结束的NDSS 2026上的一篇好文——AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks

先引用一下原作者钱志云老师的介绍，免得大家说我们的介绍不正宗：

简单来讲，这个工作研究了如何绕过 Wifi client isolation 的机制，导致一个恶意 client (连着guest ssid）可以攻击另一个 victim 用户（连着admin ssid）达成中间人的攻击。在client isolation下，传统的攻击如 arp spoofing 都是无效的。在校园，酒店，企业，甚至是家庭网络里，client isolation 都挺普遍的。

当然，这里又要cue一下Ars Technica，因为关于论文提到的AirSnitch攻击，在该网站上有一篇详细的科普好文：https://arstechnica.com/security/2026/02/new-airsnitch-attack-breaks-wi-fi-encryption-in-homes-offices-and-enterprises/

不过我们显然不信任他们的记者，所以我们也有我们自己的推荐（古法写作），其实关于这篇论文的核心内容，钱志云老师在介绍里面讲得蛮清楚了，不过如果你不熟悉Wi-Fi组网结构，可以先看看下面这幅图：

关于无线组网这事，门路还挺多的，特别是国内很多论坛上大家天天都在讨论怎么给自己的大别墅去弄一个全方位无死角信号满格的Wi-Fi，不过真的讨论到复杂的细节，论坛老哥们都会跟你说“直接买菊花家的企业解决方案比较靠谱”，可见这个里面技术细节还蛮多的，一般人不太容易掌握。论文的第二章Wi-Fi Primer是一个非常好的技术科普，不过读起来还是需要花点时间，里面最重要的知识点包括：

1. 除了AP、SSID、WPA2/3这些大家接触比较多的概念，我们还应该知道有一个Basic Service Set（BSS）的概念：一个BSS包含了一个核心的AP和相关的许多client设备，且这个BSS的设备均使用相同的频段和参数；注意到上图中一个AP支持了多个频段（通常也对应了多个BSS），而每个BSS都有一个独特的BSSID；

2. 在Wi-Fi加密通信过程中，除了WPA2/3标准要求的会话密钥（通过4-way handshake认证过程生成出来一个临时的Pairwise Transient Key，PTK）之外，还有一个用来加密广播（broadcast）和多播（multicast）消息的Group Temporal Key（GTK）；

带着这些预备知识，我们就要看看论文研究的这个client isolation机制是什么东东了。所谓的client isolation机制其实就是无线网络中的网络设备（无线路由器或者AP）对内部的client设备之间互相通信的隔离机制（防止内部设备被攻击后变成特洛伊木马然后到处内网巡游），这里面的隔离机制包括两种：一种是基于密码学的隔离机制，即给不同client分配不同的会话密钥，使得一个client就算能监听到空中的数据包（不是给它自己的），也没法解密；另一种是由网络设备执行的访问控制，即路由器网关或AP在MAC层和IP层上直接进行丢包处理，这里又可以分为同一个BSS之内的隔离（Intra-BSSID isolation）和BSS之间的隔离（Inter-BSSID isolation），注意那种通过把不同的client隔离到不同的SSID的做法不在我们的讨论范围之内。

这篇论文的出彩之处在于它发现了网络设备在实施client isolation过程中的诸多疏忽之处。首先，由于GTK是同一个BSS内部共享的，因此攻击者完全可以滥用这个GTK来伪造加密的广播和多播包，实施注入攻击，当然这里要提一下，在使用passphrase的WPA2家用网络环境下甚至都不需要靠GTK完成攻击，攻击者只需要监听其他设备入网的过程（借助自己掌握的passphrase知识）就可以解密其他client的会话密钥，而对于WPA3来说要复杂一些，需要弄一个恶意的AP去欺骗用户（不太现实）。总之，利用GTK实施注入攻击，破坏了基于密码学的client isolation机制。

其次，论文发现了在client isolation中的一个大问题：对于IP层和MAC层的数据包缺乏完整性校验这个历史黑锅，client isolation也没有严格的检查，这就会让攻击者可以利用一系列恶意构造的数据包实施isolation绕过。下图展示的这个被称为gateway bouncing的攻击就是构造了一个特定的数据包，它在IP层上的source和destination是不允许通信的，但是攻击者很坏地把MAC层上的destination改成了网关的值，也就是说在MAC层传输的时候，这个包会被丢给gateway，而gateway又回去检查IP层的信息，然后就傻乎乎地转发给了特定的目标（隔离绕过达成！）

除了利用IP层和MAC层的不一致构造攻击，作者还在交换层上实施了另一种攻击：这种攻击关注了AP在工作上的一个特定设计——把每个BSSID绑定到了一个虚拟的hardware port（注意这里并不是TCP/IP层的那个端口，应该理解为特定的网口），这个port和有线以太网的网口是等价的，而过去就已经针对有线网的port stealing攻击（参见Blackhat Europe 2003的古老文章Man in the middle attacks），那么本文作者也把这种攻击搬到了Wi-Fi网络上来：

关于如何构造具体的攻击包来实施port stealing，这部分内容我们就偷懒了（偷懒才显得我们是在古法写作），以及后面在企业级的WPA网络上，如何利用前面的技术来实现中间人攻击，这些核心的内容大家如果感兴趣一定要去读原文，不要看总结！不要看总结！

最后呢作者也去测试了各家路由器（主要是一些家用路由器，有一些还刷了OpenWRT和DD-WRT），测试下来发现基本上都没有做好client isolation：

作者还测试了校园网（为了测试企业级的WPA配置），问题也一样存在，不过在讨论相关防护措施的时候，作者也提到只要进行了VLAN划分隔离，那么很大程度上就阻止了攻击，但是一般的家用路由器似乎也不太支持VLAN隔离对不对？最后作者也建议，Wi-Fi相关的标准制定组织要好好来规范一下client isolation的实施细节才行了！

本文还提供了相关测试代码，大家可以使用一下，钱老师表示也欢迎大家包括测试结果给他们：

代码：https://github.com/seclab-ucr/airsnitch

论文：https://www.cs.ucr.edu/~zhiyunq/pub/ndss26_airsnitch.pdf

跳转微信打开

以下文章来源于：非尝咸鱼贩

临渊羡鱼，不如在家咸鱼

用 frida 向 React Native 动态注入 js 代码

动机和背景

我好像有个偏小众的恶趣味，就是给别人生产环境的应用开 js 控制台。虽然几年前发的那个某小程序的思路早就不能用了。

最近看到国外开发者 Pilfer 一直在社交网络上宣传他的新产品 Bytecode Studio，这是一款专门用于反编译和分析 React Native 字节码的工具。

https://bytecodestudio.com

他在两年前写过一篇博客 Reverse Engineering and Instrumenting React Native Apps：

https://pilfer.github.io/mobile-reverse-engineering/react-native/reverse-engineering-and-instrumenting-react-native-apps/

这篇文章介绍了在 Android 平台的 legacy 架构下动态向当前运行的 React Native 应用注入 JavaScript 代码的过程。通过 js 层的 hook，他可以实现拦截网络请求、JSON 序列化，以及无意中 dump 一些 UI 层级结构等功能。文章里的相关代码开源了：

https://github.com/Pilfer/heresy

他的 GitHub 主页还有一个基于 Rust 的 hermes 字节码反编译工具。有了这些技术积累，并不奇怪他会做 Bytecode Studio。

而数天前 React Native 发布了 0.74 版本，默认启用 Bridgeless 架构。请注意之前引用的文章只讲了 legacy 架构。

https://reactnative.dev/blog/2024/04/22/release-0.74

而还是这几天，radare2 发布了一款插件 r2hermes，专门用于分析 hermes 字节码。

https://github.com/radareorg/r2hermes

虽然笔者不做客户端，这一系列内容勾起了我的兴趣，也就有了今天这篇文章。

Legacy 和 Bridgeless 是什么鬼

React Native 有两套架构。

Legacy 架构下，JavaScript 运行在独立线程，通过 Bridge 与 Native 通信。Native 侧核心类在 iOS 是 RCTCxxBridge，Android 是 CatalystInstanceImpl。所有跨语言调用都要序列化成 JSON 经过 Bridge 传递。

0.74 版本默认启用的 Bridgeless 架构移除了这座"桥"，JavaScript 直接调用 Native 方法，性能更好。iOS 侧核心类变为 RCTInstance，Android 侧变为 ReactInstance。

向其中注入 JS 代码可以拦截网络请求、修改界面、调试业务逻辑等，静态反编译和动态修改运行时是软件逆向常见的手法。下面结合具体代码来说明实现思路。

脚本实现

我们一共要支持 4 种情况：Android 和 iOS 的 Legacy 和 Bridgeless 架构。

frida 里可以简单实用 ObjC.classes 和 Java.classes 来检查类是否存在。

拦截 JS Bundle 加载

React Native 的 JS 代码以 Bundle 的形式加载。如果应用版本很旧，可能用的是压缩混淆后的 js，分析很简单。不过目前多数情况都是 hemes 字节码，分析门槛比前者显著提高。

我们可以拦截以下方法拿到 js 或者字节码。

iOS legacy 架构：

-[RCTCxxBridge executeSourceCode:withSourceURL:sync:]-[RCTCxxBridge executeApplicationScript:url:async:]

iOS bridgeless 架构：

-[RCTInstance _loadJSBundle:]

Android legacy 架构：

CatalystInstanceImpl 的 loadScriptFromAssets 以及 loadScriptFromFile

Android bridgeless 架构：

com.facebook.react.runtime.ReactInstance 的 loadJSBundleFromFile 和 loadJSBundleFromAssets

主动注入 JS 代码

React Native 核心的逻辑使用 C++ 实现，用 frida 直接交互虽然不是不可能，但是构造参数非常麻烦，还得处理内存管理和偏移量适配等问题。

从 Java 层或者 Objective-C 层并没有提供可以传入字符串的接口，只能把 js 写入临时的 bundle 然后载入。

在文章开头提到的 Pilfer 的博客里，作者为了拿到当前运行的 CatalystInstanceImpl 实例，用了比较 hack 的方法，创建定时器等待 loadScriptFromAssets 被调用，然后在 hook 里把实例保存下来。

// This is the app identifier you're trying to hook
const package_name = 'com.foo.bar';
// Write the hermes-hook.js payload to file
const f = new File(`/data/data/${package_name}/files/hermes-hook.js`, 'w');
f.write(`console.log(Object.keys(this)); console.log('hello from React Native!');`);
f.close();
Java.perform(function () {
  // Lazily wait for the class to be available to us  
  var looper = setInterval(function () {
    try {
      const CatalystInstanceImpl = Java.use("com.facebook.react.bridge.CatalystInstanceImpl");
      CatalystInstanceImpl.loadScriptFromAssets.implementation = function (assetManager, assetURL, z) {
        // Load the original index.android.bundle
        this.loadScriptFromAssets(assetManager, assetURL, z);
        // Load custom JS into the global hermes context
        this.loadScriptFromFile(`/data/data/${package_name}/files/hermes-hook.js`, `/data/data/${package_name}/files/hermes-hook.js`, z);
      };
      clearInterval(looper);
    } catch (error) {
      console.log('failed');
    }
  }, 10);
});

其实 frida 本身的 Java.choose 和 ObjC.choose 就可以直接在内存里检索到实例。

以 iOS 的 legacy 架构为例：

const nsData = ObjC.classes.NSData.dataWithContentsOfFile_(path);
const nsURL = ObjC.classes.NSURL.fileURLWithPath_(path);
instance["- enqueueApplicationScript:url:onComplete:"](nsData, nsURL, NULL);

新架构注入 js bundle 用的是 RCTInstance 的 _loadJSBundle: 方法。但是没想到吧，还有惊喜。这个方法在三年前的提交改过名字，之前是没有下划线的

https://github.com/facebook/react-native/commit/0dcf81b4f19484a4e43

不过这个适配好做，直接 respondsToSelector: 判断一下就行。

获取返回值

在这里遇到了另一个问题，上层封装的加载 js 接口并不等待脚本执行完成，也没有提供获取执行结果的接口。虽然我们在 js 脚本里使用 console.log 可以在 iOS 的系统日志或者 Android 的 logcat 里看到输出，对手工测试的场景绰绰有余，但如果想开发自动化工具，到处 grep 就不太优雅。

很容易想到一个很糟糕的思路：js 里内置了 XMLHttpRequest，直接把执行的结果回传到一个本地监听的 http 服务器上。也不是不可以。

那么既然我们想到了 React Native 内置函数这一点，又有二进制级别的函数插桩，不妨直接用 alert 当作 callback 回传。这并不是笔者原创，多年以前就有人用这个思路实现 WebView 的 js 和 native 互传数据了。

先把待执行代码包装一下：

const wrapped = `
try {
  var r = (function() { return ${script} })();
  alert('frida-callback:${id}:' + JSON.stringify(r));
} catch(e) {
  alert('frida-callback:${id}:' + JSON.stringify({ error: e.message }));
}
`;

接着这个字符串 frida-callback:... 会被封装成字典格式传到 native 层。以 iOS 为例，就是一个 NSMutableDictionary，其中的 key 是 "message"。但这里有一个小坑。从 6 年前的一个提交到截止本文发布的版本，这个 native 方法接受的参数是一个 C++ 的对象，解引用第一个指针才是 NSMutableDictionary：

RCT_EXPORT_METHOD(alertWithArgs : (JS::NativeAlertManager::Args &)args callback : (RCTResponseSenderBlock)callback)

而 2019 年的这个 a5ad0bf12468fc831c2a 提交当中，函数原型曾经是直接传的：

RCT_EXPORT_METHOD(alertWithArgs:(NSDictionary *)args
                  callback:(RCTResponseSenderBlock)callback)

这就导致同样的代码会崩，还得特殊处理一下。不过都 7 年了，如果不是特别执着兼容性，直接按照新的函数原型来构造参数就好了。

  const { RCTAlertManager } = ObjC.classes;
  const method = RCTAlertManager["- alertWithArgs:callback:"];
  const original = method.implementation;
  method.implementation = ObjC.implement(
    method,
    function (
      handle: NativePointer,
      selector: NativePointer,
      args: NativePointer,
      callback: NativePointer,
    ) {
      const message = new ObjC.Object(args.readPointer()) // <- 注意 readPointer
        .objectForKey_("message")
        .toString();
      console.debug(`React Native alert(${message})`);
      return original(handle, selector, args, callback);
    },
  );
  console.log('replaced RCTAlertManager["- alertWithArgs:callback:"]');

这个 Module 看上去不受 bridgeless 架构的影响，都可以用同样的方式 hook。

最后看看效果，搞了个类似 F12 的东西：

阅读原文

跳转微信打开

如果要回到过去，摧毁一项技术，从而让AI无法统治人类，应该怎么办？

提问：如果要回到过去，摧毁一项技术，从而让AI无法统治人类应该怎么办？

答案当然是摧毁掉万维网（World Wide Web），只要没有万维网，机器就没法学习知识，除了发热之外什么也做不了~

那么问题来了，怎么摧毁万维网？请先访问如下网址（诶，如果摧毁了万维网，下面的网址不就没了吗，那怎么摧毁万维网？）了解相关知识：

https://www.w3.org/History/1989/proposal.html

上面这便是Tim Berners-Lee（爵士！）在1989年发明万维网时候的原始提案。1989年，Tim Berners-Lee在欧洲核子研究组织也就是CERN（法语：Conseil Européen pour la Recherche Nucléaire；英语：European Organization for Nuclear Research，1954年9月29日成立）发明了万维网，看来物理学确实改变了世界。Tim Berners-Lee不仅创造了“万维网”（World Wide Web）这个词，并在1990年10月编写了第一个万维网服务器“httpd”和第一个客户端程序（浏览器及编辑器）“WorldWideWeb”。他还编写了第一版“超文本标记语言”（HyperText Markup Language，HTML），这种文档格式化语言具备超文本链接功能，成为Web的主要发布格式。随着Web技术的传播，他对URI、HTTP和HTML的初始规范进行了改进，并在更大范围内进行了讨论。然后就是AI利用WWW学习并统治人类的历史了

在下面这个网址有一篇《WWW简史》，就差一位霍金来推广了：

https://www.w3.org/History.html

不过我们今天的重头戏不是单纯地介绍WWW的历史，而是要带大家熟悉古早的WWW，从而更好地回去执行拯救人类的任务。可是现在哪有古早WWW给你熟悉？嘿嘿，CERN早就考虑好了，在如下网址（如果摧毁了万维网悖论又来了）给大家提供了一个完全模拟的复古环境，专为人类特工准备：

https://worldwideweb.cern.ch/

当你点击下面的链接，就会启动时光机，回到1989年，然后你可以尝试下如何操作（以及如何摧毁它）：

https://worldwideweb.cern.ch/browser/

行动起来吧！祝人类能够得到拯救 

阅读原文

跳转微信打开