文章来源：

衡宇 发自 凹非寺
量子位 | 公众号 QbitAI

图片来源：由无界AI生成

阿里云正式发布通义千问2.5大模型，同时宣布性能全面赶超GPT-4 Turbo。
此时，距离阿里云通义大模型发布，恰好过去一周年；距离GPT-4发布，也已经过去一年有余。
根据最新公布的数据，通义大模型通过阿里云服务企业超9万，通义开源模型累计下载量突破700万。

同时，阿里云也正式宣布了“通义千问App”更名为“通义App”，为所有用户提供免费服务。
通义意为“通情，达义”，该App以最新通义基础大模型为底座，并把通义实验室的文生图、智能编码、文档解析、音视频理解、视觉生成等能力“All in one”。
阿里云CTO周靖人表示：
大模型这么多家，大家都说的是同样的故事，但最后比拼的就是能力差异。包括最后比拼的是怎么融合生态，尤其是开发者的生态。
怎么把它落地运用起来，才是最大的差异。

通义千问2.5发布

先来看看最新发布的通义千问2.5版本。
周靖人介绍，相比通义千问2.1（去年12月1日发布），2.5版本的理解能力、逻辑推理、指令遵循、代码能力分别提升9%、16%、19%、10%，中文能力尤其突出。
在权威基准OpenCompass（上海AI Lab出品）上，通义千问2.5得分追平GPT-4Turbo。这是该基准首次录得国产大模型取得此等成绩。

会上介绍，通义2.5加强了文档处理能力。
可单次可处理多达1000万字的长文档，还能同时解析100份不同格式的文档，支持多文件类型、多数据格式解析、多场景优化，便于用户使用和继承。

同时，通义的音视频理解能力也有迭代升级。
发布会上，周靖人着重介绍了专业提供智能编码能力的通义灵码，现在它不只支持个人程序员，也推出通义灵码企业版本。
通义灵码基于SOTA水准的通义千问代码模型CodeQwen1.5研发，目前插件下载量超过350万。刚刚过去的4月份，通义灵码登顶了Big Code模型排行榜。

在技术能力迭代的基础上，上述能力都集成在刚刚改名的通义App内，用户可以通过App和Web端进行使用。

百炼升级2.0版本

除了通义2.5模型以外，阿里云的百炼大模型平台最新进展也进行了展示。
去年10月，阿里云发布了百炼大模型平台，主要功能就是让开发者通过简单的拖拉拽，在5分钟开发一款大模型应用，几小时炼出一个专属模型。
现在升级后，百炼有了2.0版本，成为阿里云承载云+AI能力的重要平台，提供一站式、全托管的大模型定制与应用服务。

“当下企业应用大模型存在三种范式：一是对大模型开箱即用，二是对大模型进行微调和持续训练，三是基于模型开发应用，其中最典型的需求是RAG，以企业数据对大模型进行知识增强。”周靖人展开介绍，“围绕这些需求，百炼打造了模型中心和应用中心，提供最丰富的模型和最易用的工具箱。”
目前，百炼联动魔搭开源社区，集成了上百款大模型API，除了通义、Llama等系列，还有智谱ChatGLM、百川、月之暗面等系列模型。

对需进一步训练模型的用户，百炼提供从数据管理、模型调优、评测到部署的模型服务，用户可对算力按需调用，无需因底层架构费脑筋。
此外，百炼还支持基于prompt定制和优化、支持Assistant API开发模式，实现智能应用的编排，结合自身需求做定制化开发。
持续开源
去年8月，通义宣布加入开源行列，随之沿着“全模态、全尺寸”路线，陆续推出十多款模型。
其中较为瞩目的是参数规模横跨5亿到1100亿的八款大语言模型。

• 小尺寸开源模型：0.5B、1.8B、4B、7B、14B，可便捷地在手机、PC等端侧设备部署；
• 中等尺寸开源模型：32B试图在性能、效率和内存占用之间找到最具性价比的平衡点。
• 大尺寸模型：如72B、110B能支持企业级和科研级的应用。

此外，通义还开源了视觉理解模型Qwen-VL、音频理解模型Qwen-Audio、代码模型CodeQwen1.5-7B、混合专家模型Qwen1.5-MoE。
目前，通义开源模型系列下载量已经超过700万。
阿里云表示，自己是全球唯一持续开发模型、坚持开源的公司。

此次发布会上，通义也发布了最新款开源模型：1100亿参数的Qwen1.5-110B。
该模型在MMLU、TheoremQA、GPQA等基准测评中，超越了Meta的Llama-3-70B模型；在HuggingFace推出的开源大模型排行榜OpenLLMLeaderboard上，Qwen1.5-110B冲上榜首。

最后，在谈及开源技术时，周靖人表示，开源对全球技术的贡献毋庸置疑，闭源模型至少要超过所有开源模型才有机会参与讨论。

文章来源：

图片来源：由无界AI生成

随着诸如 ChatGPT 之类的生成式 AI 工具的迅速普及，越来越多人开始猜测苹果公司在 AI 时代的未来动向：是端出 iOS 版的对话式人工智能？还是革新智能语音助手 Siri？

昨晚，苹果以一场仅 38 分钟的发布会为六月份 WWDC 2024 预热，CEO 蒂姆·库克宣布，此次发布将是 iPad 历史上的重要里程碑。在苹果的一系列宣传中，除了“最薄 iPad”，最引人瞩目的便是苹果推出的最新 M4 芯片：它搭载苹果最强大的神经引擎，每秒执行 38 万亿次操作，比 A11 Bionic 的首代神经引擎快 60 倍，被誉为“极端强大的 AI 芯片”，只需 M2 一半的功耗即可提供相同性能，且在 AI 处理能力上超越当前任何 PC 神经处理单元。

库克曾经如此评价过 AI：它们会嵌入到我们制造的每一个产品中。现在看看苹果在 AI 领域的一系列动作，特别是 Ferret、HUGS、MM1、ReALM 等论文的发布，我们会发现苹果的战略方向仍是“软硬件的结合”，在资源有限的移动设备上高效部署大型语言模型，是实现 AI 技术大众化应用的关键。

WWDC 还有一整月才会亮相，本文将简单回顾苹果这半年的各种动向作为前瞻，让我们一起看看苹果将怎么逐步构建一个以 AI 为驱动的全新生态系统。

Siri——改造它还是“生二胎”？

2023 年 5 月，蒂姆·库克（Tim Cook）在苹果的财报电话会议上表示，人工智能有“许多问题需要解决”，重要的是“在开发方法上要深思熟虑”，并计划继续在深思熟虑的基础上将 AI 融入到产品中。

实际上早在 2019 年，苹果就组建了专注于对话式 AI 的团队，AI 部门主管约翰·詹南德里亚（John Giannandrea）在公司内部领导着大语言模型的研发，他的工作直接向苹果 CEO 蒂姆·库克汇报。但直到 OpenAI 发布 ChatGPT 之前，这个团队一直没传出过什么消息，可谓是起了个大早、赶了个晚集。

时间回到 2023 年，彭博社专职报道苹果科技新闻的记者马克·古尔曼（Mark Gurman）透露，AI 研发在苹果内部被赋予高度优先级，公司设计了一套名为“Ajax”的大型语言模型框架。当时的新闻表示 Ajax 相较于 ChatGPT 3.5 在能力上有所超越，且已基于超过 2000 亿参数进行训练（虽然从今天的角度来看已经不怎么样了）。事实是，OpenAI 随后发布的 GPT-4 模型就已超越 Ajax 泄露出的纸面数据。

这段时期的苹果对于如何面向消费者推出生成式 AI 产品尚无清晰策略。

2023 年 9 月，外媒 The Information 首次曝光了苹果 AI 研发的种种细节：

• 苹果在对话式人工智能的研究上每日投入数百万美元，因为训练语言模型需庞大硬件支持。
• 核心团队只有 16 人。
• 核心目标之一是让 Siri 能够执行多步骤任务。

团队核心成员也相继曝光：

• John Giannandre，前文提及的这位领导者其实是苹果公司的机器学习和 AI 战略高级副总裁。
• Daphne Luong，苹果特意从谷歌挖来的 AI 高管。
• Arthur Van Hoff，他曾从事 Java 程序语言的早期开发工作，传闻中 Java 名字中的那个“v”就来自于他。
• Ruoming Pang，2021 年加入苹果，擅长神经网络研究。

苹果在生成式 AI 领域的探索，有望最终融入 Siri 语音助手。

负责 2014 年改进 Siri 的前苹果工程师 John Burkey 曾如此批评这款语音助手：Siri “基于笨拙的代码构建”，其“累赘的设计”使得工程师很难添加新功能，即使是最基本的功能更新也需要数周时间。比如，Siri 的数据库包含接近二十多种语言的大量短语列表，形成一个“大雪球”。因此，Burkey 认为，Siri 最终无法成为像 ChatGPT 那样的人工智能助手。

John Burkey

苹果公司的研究人员一直在研究「无需使用唤醒词即可使用 Siri」的方法，也就是让语音助手“凭直觉”判断机主是否正在与其交谈，而不是聆听“嘿 Siri”或“Siri”。2023 年 10 月份，苹果的研究人员发表了一篇论文研究唤醒词的这个问题：

论文地址：https://arxiv.org/pdf/2310.16990

这篇论文旨在让 Siri 设法弄清你什么时候在问一个后续问题，什么时候在问一个新问题。它利用 LLM 来更好地理解所谓“模棱两可的询问”，无论你怎么说，它都能猜出你的意思。

文中写道：“在不清楚对话者的意图时，智能对话代理可能需要「主动出击」，通过主动提出好问题来减少不确定性，从而更有效地解决问题。”

除了 Siri 的问题，苹果本身还需要解决另一项大麻烦。2023 年年底，Keivan Alizadeh 等人发布了一篇论文，针对现代自然语言处理领域核心的大型语言模型（LLMs）进行了研究。他们要解决的问题是当今的一大挑战：怎么把动辄千亿参数的这些 AI 大模型塞到小小的 iPhone 里面？

论文地址：https://arxiv.org/pdf/2312.11514

他们的研究通过细致设计的系统策略，着力于最小化在模型推断阶段从闪存到设备有限 DRAM 资源的数据迁移负担。核心在于构建一个与闪存特性和操作机制紧密配合的推理成本模型，籍此双管齐下优化数据处理流程：一方面，减少数据在闪存与 DRAM 间往返的总量；另一方面，优化数据读取模式，倾向于更大规模和更高连贯性的数据块读取操作。

研究团队创新性地推出了两项关键技术：“窗口化”策略，这种方法聪明地复用近期推理中已激活的数据，减少不必要的重复加载；以及“行列捆绑”技术，通过智能组织数据的存储布局，使得每次从闪存提取的数据块更为庞大且读取连续，尤其适合闪存介质的读取特性。在苹果自家 M1 Max CPU 平台上实施这些技术，与常规的数据加载方案对比，推理效率实现了显著的 4 至 5 倍跃升；而转移到 GPU 环境，这一效率提升更是激增到 20 至 25 倍，成效斐然。

未来展望中，这些优化技术的实装，或将很快赋能诸如 iPhone、iPad 以及其他移动设备，使复杂的 AI 助手和聊天机器人在这些平台上的运行变得丝滑无阻。如今看来，M4 芯片的发布或许就是苹果端侧 AI 的最后一块垫脚石。

除此之外，苹果欲将生成式 AI 引入移动设备，可能还需要解决隐私问题。从 Siri 的历史可以看出，苹果素来对隐私保护持审慎态度，这种决策虽使 Siri 在功能性上略逊于 Alexa、Google 助手等竞品，却彰显了其对用户隐私的重视。

“百模大战”时期的苹果：封闭，还是开源？

2023 年 10 月份，苹果悄然发布了 Ferret 开源多模态大型语言模型。这篇论文相当不得了，同时包含了“苹果”“开源”以及“全华班”几大元素——没错，论文的作者全是华人。

论文地址：https://arxiv.org/pdf/2310.07704

开源地址：https://github.com/apple/ml-ferret

这篇论文介绍的多模态模型 Ferret 能够理解和处理图像中任意形状或粒度级别的空间参照，并准确地对开放词汇描述进行定位。其核心创新在于它采用了一种新颖且强大的混合区域表示方法，这种方法将离散坐标与连续特征结合起来，共同表征图像中的某个区域。这不仅融合了传统上分开处理的参照（referring）和定位（grounding）任务，还在 LLM 的框架内实现了两者的统一。

为了提取不同区域的连续特征，苹果提出了一种空间感知的视觉采样器。这种采样器擅长处理不同形状间变化的稀疏性，使得 Ferret 能够接受多样化的区域输入形式，包括点、边界框以及自由形态的形状。这一设计显著增强了模型处理复杂视觉信息的能力。

为了强化 Ferret 的这些特有能力，研究团队还精心构建了 GRIT 数据集，这是一个全面的参照与定位指令微调数据集，包含 110 万个样本，这些样本富含层次化的空间知识，并特别加入了 9.5 万个困难负例数据来增强模型的稳健性。GRIT 数据集的设计旨在通过丰富的训练实例，促进模型在理解和生成基于空间关系的多模态指令方面的表现。

实验结果显示，Ferret 不仅在经典的参照和定位任务上取得了卓越的性能，在基于区域的以及需要精确定位的多模态对话任务上，其表现更是远超当时的其他多模态大语言模型。

评估还揭示了 Ferret 在描述图像细节方面的显著提升，以及在减少臭名昭著的“幻觉”（hallucination）现象上的明显改善。这意味着 Ferret 不仅能更准确地理解和生成与图像内容相关的语言描述，还能在描述过程中减少不准确或不存在信息的引入，从而提高了生成内容的真实性和可靠性。

尽管 Ferret 公布材料含代码与权重（仅供科研，无商用授权），导致初时并未引发广泛关注，但随着开源 Mistral 模型近期炙手可热，小型设备上本地 LLMs 的应用潜能日益受到瞩目。苹果宣布在 iPhone 上实现 LLM 部署的重大突破后，讨论热度也是随之骤增。

当时引起了 Hacker News 三百多条的评论

2023 年底伴随而来的一项研究报告还揭示了苹果最新的 HUGS（Human Gaussian Splats）技术，旨在从单镜头短视频中创制动态 3D 虚拟形象，提供更为沉浸的视觉体验。论文一作 Muhammed Kocabas 还曾放言：“我们的方法可以从一段单镜头短视频（50 – 100 帧）中自动区分静态场景与全动画虚拟形象，整个过程仅需 30 分钟。”

论文地址：https://arxiv.org/pdf/2311.17910

HUGS 借助高效的 3D 高斯斑点渲染技术，同步展现主体与背景。人体模型依托 SMPL（统计形体模型），HUGS 凭借高斯形变捕获衣物、发型等细微之处。一新型神经变形模块借力线性混合蒙皮技术，使高斯动态表现更为真实，避免了摆姿调整中的视觉扭曲。

相比早期虚拟形象生成手段，HUGS 在训练和渲染速度上快至 100 倍，仅需 30 分钟即可在标准游戏 GPU 上优化出逼真的效果。在 3D 重建质量方面，HUGS 也超越了诸如 Vid2Avatar 和 NeuMan 等最先进技术。

此项创新让用户仅凭一段含人物与场景的视频，即可将各式数字角色或“虚拟形象”置入新情境，以每秒 60 帧的速率刷新，呈现流畅逼真的效果。

苹果的一系列 AI 技术发布——尤其是开源多模态模型的举动，直接给许多业内人士送上了一份惊喜。专注于医疗领域开源 AI 的欧洲非营利组织负责人 Bart de Witte 当时在 X 平台上赞扬苹果：“不知怎的，我错过了这个消息。苹果在 10 月份加入了开源 AI 行列。Ferret 的问世，彰显了苹果致力于有影响力的 AI 研究的决心，并巩固了其在多模态 AI 领域的领头羊地位……我对将来本地大型语言模型（LLLMs）作为 iOS 新设计一部分运行于 iPhone 上充满期待。”

德国 AI 音乐艺术家及顾问 Tristan Behrens 在 Linkedin 上写道：“圣诞节提前到来，但你知道吗？苹果（没错，就是苹果！）最近发布了一个包含代码和权重的多模态大型语言模型。”

科技博主 Ben Dickson 曾就这一惊喜发表意见：“2023 年最让你惊讶的 AI 发展是什么？对我来说，是苹果发布了开源 LLM（虽然是非商业许可的）。”他指出，苹果历来坚持封闭系统、保密、严格的保密协议，甚至对微小创新也会严格申请专利。

他接着说：“但回过头看，苹果（像 Meta 一样）发布开源 LLM 模型是有道理的。要与像 ChatGPT 这样的模型竞争，要么你得有台超级计算机，要么得有强大的合作伙伴。虽然苹果资源丰富，但其基础设施并不适合支持大规模 LLMs。另一个选择是依赖像微软或谷歌（两大竞争对手）这样的云服务提供商，或者像 Meta 那样开始发布自己的开源模型。”

回顾完 2023 年的“旧闻”，再来看目前苹果对于战略合作的最新动向：2024 年 3 月彭博社曾报道，苹果正与谷歌探讨在 iOS 18 中集成 Gemini AI 引擎的可能性。苹果意在获取谷歌大型语言模型的授权，但具体条款与品牌命名尚未敲定。

此外，苹果还正开发基于设备的 AI 新功能，同时寻求拥有强大硬件基础的合作伙伴以支持云端生成式 AI 应用，如根据提示生成图像和编写文章，但目前并无开发 ChatGPT 风格聊天机器人的计划。

除谷歌外，苹果今年亦与 OpenAI 接洽，探讨如何在 iOS 18 中运用 OpenAI 技术。在中国市场，苹果同样于三月份引起过一波热议，也就是先前传闻的和百度的合作：

到了今年四月份，苹果寻求与照片分享服务网站 Photobucket 达成协议，利用其超过 130 亿份图像和视频资料训练 AI 模型，并已从 Shutterstock 购得数百万张图片授权。

苹果的生成式 AI 蓝图徐徐铺开，一切皆待下个月的 WWDC24 大会正式揭晓。当前，几乎每家大型科技企业均有 AI 产品筹备中。除 OpenAI 的 ChatGPT 以外，国际知名的谷歌、微软、亚马逊等大厂都蓄势待发：

• 谷歌：推出了 Bard 和 Gemini。已将生成式 AI 融入搜索产品与应用，而 Bard 还与 Google Flights、地图、Drive 等服务整合。
• 微软：前脚与 OpenAI 合作，。将 ChatGPT 融入自家 Bing 搜索引擎，并拥有 Copilot AI 应用。
• 亚马逊：努力通过生成式 AI 改进国外火爆的 Alexa 语音助手。
• Meta：发布了开源模型 LLaMA 造福世界，坐拥 AI 教父杨立昆，准备今年下半年再发布 LLaMA-3 的最强版本。此外，还将生成式 AI 融入多款应用，如 WhatsApp 和 Messenger 和 Instagram。

透明到底不妥协

如果说去年的苹果还让人有些难以捉摸，那今年全面专攻 AI 的苹果可谓是大显身手了。2 月份，在「造车」与「AI」两条截然不同的赛道上，苹果毅然决定取消搞了十多年的电动车项目，引得乐视创始人贾跃亭点评：

同一时间段发布的 VisionPro 亦是争议满满，但由于本文主讲 AI，便不再深入，等待六月份苹果的进一步更新。

很快来到 3 月，苹果并没有闲着，而是扎出了一记利枪：。30 多位研究员，且和前文提到的 Ferret 大模型一样，华人含量极高。

论文地址：https://arxiv.org/pdf/2311.17910

MM1 继承了 Ferret 的理念，在论文中直接指出当前众多 AI 公司在 AI 模型的学习方法上有着“不透明性”的痛点。大多数的模型对于他们所使用的算法设计选择的过程几乎没怎么进行公开，而今年爆火的多模态预训练更是如此。为了在多模态这条赛道跑下去，苹果发布了这篇论文，完整记载了模型的构建过程。

当时还引起了英伟达研究科学家 Jim Fan 的吐槽：

我们正处在一个如此奇特的时代。苹果，一家以保密著称的公司，竟然发表了一篇关于其多模态基础模型的论文，其中包含了令人震惊的详尽细节。那些本应更加开放的公司，如今在这方面反而远不如苹果透明。MM1（假设这是苹果模型的代号）是一座分析的宝库。他们讨论了许多架构设计方面的问题，甚至透露他们使用了 GPT-4V 生成的数据进行训练。他们提供了精确到四位有效数字的缩放定律系数、MoE（专家混合网络）设置，乃至最优学习率函数等信息。我已经很久很久没有在大型科技公司的白皮书中看到过如此详尽的内容了。苹果真的回来了！（Apple’s so back!）

三月底，苹果再发力作，推出 ReALM 框架，附带四款神秘的超小参数模型，性能直逼 GPT-4。

论文地址：https://arxiv.org/pdf/2311.17910

ReALM 对抗了曾经“参数量即王道”的普遍认知，在不依赖于模型规模的持续膨胀下，通过算法和架构创新达到与当前顶尖模型如 GPT-4 相当的性能。其中，参数最“大”的 30 亿参数 LLM 在标准对话数据集中达到了 97.9% 的准确率，在合成数据集上则达到了 99.8% 的准确率；在涉及屏幕上的实体引用解析任务上，3B LLM 达到了 93.0% 的准确率；在未知领域，如警报系统的测试中，该模型依然保持了 97.8% 的准确率，与 GPT-4 的表现相近。

ReALM 对 Siri 最显著的强化在于上下文理解的升级，它可以掌握诸如“再次播放那首歌”或“给她打电话”等参考信息，甚至预测用户的需求和偏好，根据过去的行为和上下文理解建议或启动操作。

2011 年推出 Siri 时，苹果曾一度走在语音助手创新的前沿，适应着全球用户的需求。时间一点点推进，Siri 逐渐变成大家所调侃的“人工智障”，其未来形态也成为了本次 WWDC 2024 被关注的焦点。

库克曾在今年二月的股东大会上曾用一个词形容苹果的 AI 计划：“break new ground”——开辟新天地。最晚进场的苹果，这次是姗姗来迟还是伺机待发？此刻，你心中或许已经有了答案。

背景

CertiK之前的文章《链上打新局中局，大规模RugPull手法揭秘》中，揭示了一个针对打新机器人的大规模退出骗局自动化收割机地址0xdf1a，该地址在短短两个月左右就完成了超过200次退出骗局（以下统称RugPull），但这个团伙并非只有一种RugPull手法。

之前的文章中以MUMI代币为例描述了该地址背后团伙的RugPull手法：通过代码后门直接修改税收地址的代币余额，却没有修改代币的总供应量，也没有发送Transfer事件，从而使查看了etherscan的用户也无法发现项目方偷偷铸造代币的行为。

今天的文章则是以代币“ZhongHua”为例解析该团伙的另一种RugPull手法：用复杂的税收功能逻辑，掩盖可用于RugPull的转账功能。接下来，我们通过“ZhongHua”代币案例，分析地址0xdf1a的另一种RugPull手法细节。

深入骗局

在该案例中，项目方共计用9,990亿个ZhongHua兑换出了约5.884个WETH，耗干了池子的流动性。为了深入了解整个RugPull骗局，我们从头梳理一下事件脉络。

  部署代币

1月18日凌晨1点40分（UTC时间，下文同），攻击者地址（?0x74fc） 部署了名为ZhongHua的ERC20代币（?0x71d7），并预挖了10亿个代币发送给攻击者地址（?0x74fcfc）。

预挖代币数量与合约源码内定义的数量一致。

  添加流动性

1点50分（代币创建10分钟后），攻击者地址（?0x74fc）向Uniswap V2 Router授予ZhongHua代币的approve权限，以准备添加流动性。

1分钟后，攻击者地址（?0x74fc）调用Router中addLiquidityETH函数添加流动以创建ZhongHua-WETH流动性池（?0x5c8b），将预挖的所有代币和1.5个ETH添加到流动性池中，最后获得约1.225个LP代币。

从上述代币转账记录中我们可以看到，有一笔转账是攻击者（?0x74fc）发送了0个代币给ZhongHua代币合约自身。

这笔转账不属于添加流动性的常规转账，通过查看代币合约源码发现，其中实现了一个_getAmount函数，该函数负责从转账的from地址扣款并计算所要收取的手续费，然后将手续费发送至代币地址，再触发表示代币地址收到手续费的Transfer事件。

_getAmount函数中会判断转账的sender是不是_owner，若是_owner则将手续费置为0。_owner在Ownable合约部署时由构造函数constructor的输入参数赋予。

而ZhongHua代币合约继承了Ownable合约，并在部署时将部署者msg.sender作为Ownable构造函数的输入参数。

因此攻击者地址（?0x74fc）就是代币合约的_owner。而添加流动性的那笔0代币转账正是通过_getAmount函数发出，因为_getAmount会在transfer和transferFrom函数内被调用。

  永久锁定流动性

1点51分（流动性池创建的1分钟内），攻击者地址（?0x74fc）将通过添加流动性获取的全部1.225个LP代币直接发送至0xdead地址，以完成对LP代币的永久锁定。

同MUMI代币案例一样，当LP被锁定后，理论上攻击者地址（?0x74fc）便不再具备通过移除流动性进行RugPull的能力。而在地址0xdf1a主导的针对打新机器人的RugPull骗局中，这一步主要是用于骗过打新机器人的反诈脚本。

至此，在用户看来所有的预挖Token都用于添加到流动性池中，并未有异常情况出现。

  RugPull

凌晨2点10分（ZhongHua代币创建约30分钟后），攻击者地址2（?0x5100）部署了专门用于RugPull的攻击合约（?0xc403）。

同MUMI代币的案例一样，项目方没有用部署ZhongHua代币合约的那个攻击地址，且用于RugPull的攻击合约不开源，目的都是为了提高技术人员溯源的难度，大部分RugPull骗局都有这样的特点。

上午7点46分（代币合约创建约6小时后），攻击者地址2（?0x5100）进行了RugPull。

他通过调用攻击合约（?0xc403）的“swapExactETHForTokens”方法，从攻击合约中转出9,990亿个ZhongHua代币兑换出了约5.884个ETH，并耗尽了池子中大部分流动性。

由于攻击合约（?0xc403）不开源，我们对其字节码进行了反编译，结果如下：

https://app.dedaub.com/ethereum/address/0xc40343c5d0e9744a7dfd8eb7cd311e9cec49bd2e/decompiled

攻击合约（?0xc403）的“swapExactETHForTokens”函数主要功能就是先用approve为UniswapV2 Router授予最大数量的ZhongHua代币转账权限，再通过Router将调用者指定数量为“xt”的ZhongHua代币（攻击合约（?0xc403）拥有的）兑换成ETH，并发送给攻击合约（?0xc403）中声明的“_rescue”地址。

可以看到“_rescue”对应的地址正是攻击合约（?0xc403）的部署者：攻击者地址2（?0x5100）。

该笔RugPull交易的输入参数xt为999,000,000,000,000,000,000，对应9,990亿个ZhongHua代币（ZhongHua的decimal为9）。

最终项目方用9,990亿个ZhongHua将流动性池中的WETH耗干，完成RugPull。

和之前文章的MUMI案例一样，我们需要先确认攻击合约（?0xc403）中ZhongHua代币的来源。从前文我们得知ZhongHua代币的总供应量为10亿，而在RugPull结束后，我们在区块浏览器中查询到的ZhongHua代币总供应量依旧是10亿，但是攻击合约（?0xc403）出售的代币数量却是9,990亿，是合约记录的总供应量的999倍，这些远超总供应量的代币从何而来？

我们查看了合约的ERC20转账事件历史，发现和MUMI代币的RugPull案例一样，ZhongHua代币案例中攻击合约（?0xc403）同样没有ERC20代币的转入事件。

在MUMI的案例中，税收合约的代币来自于代币合约中直接对balance的修改，使得税收合约直接拥有远超总供应量的代币。由于MUMI代币合约在修改balance时不对应修改代币的totalSupply，也不触发Transfer事件，因此我们无法看到MUMI案例中税收合约的代币转入记录，仿佛税收合约用来RugPull的代币像是凭空出现的一样。

回到ZhongHua这个案例，攻击合约（?0xc403）中的ZhongHua代币也像是凭空出现的一样，因此我们也去ZhongHua代币合约中搜索“balance”这个关键字。

结果显示整个代币合约仅有三处对balance变量的修改，分别在“_getAmount”、“_transferFrom”和“_transferBasic”函数中。

其中“_getAmount”用于处理收取转账手续费的逻辑，“_transferFrom”和“_transferBasic”则是在处理转账逻辑，并没有出现如下图MUMI代币一般明显地直接修改balance的语句。

更关键的是，MUMI代币合约直接修改税收合约的balance时没有触发Tranfer事件，这也是我们无法在区块浏览器中查询到税收合约的代币转入事件，但税收合约却能拥有大量代币的原因。

然而在ZhongHua代币合约中，无论是“_getAmount”、“_transferFrom”还是“_transferBasic”函数，它们在对balance进行修改后，都有正确触发Transfer事件，这与我们前面查询与攻击合约（?0xc403）相关的Transfer事件时无法发现代币转入的Tranfer事件的情况是冲突的。

难道与MUMI的案例不同，这次攻击合约（?0xc403）中的代币真是凭空出现的？

手法揭秘

  攻击合约的代币从何而来

在分析案例的过程中，当我们发现ZhongHua合约中每一次修改balance都正确触发了Transfer事件，却又始终找不到与攻击合约（?0xc403）相关的代币转入记录或Transfer事件时，就需要找到新的分析思路。

我们查询了大量的转账记录，也一度把合约中的“performZhongSwap”函数当作突破口，该函数负责将代币合约中的代币出售，在我们分析的其他的RugPull事件中，存在不少以这类函数作为RugPull后门的案例。

尽管检查了其他函数，结果还是一无所获。于是我们开始将视野放到了“transfer”函数本身，无论攻击者以什么方式进行RugPull，“transfer”函数的实现逻辑一定都包含着最重要的信息。

  致命的Transfer

代币合约中“transfer”函数直接调用了“_transferFrom”函数。

看上去“transfer”函数进行代币转账操作，转账完成后会触发Transfer事件。

但在进行代币转账前，“transfer”函数会先用“_isNotTax”函数判断转账的sender是否为免税地址：若不是则用“_getAmount”函数收税；若是则不收税，将代币直接发送到recipient。而问题也正是出在这里。

前文也提到，在“_getAmount”的实现中，代币合约校验了sender的余额，并对sender进行了扣款，然后将手续费发送至代币合约。

而问题在于，“_getAmount”仅在sender不是免税地址的时候被调用。当sender是免税地址时，则直接为recipient的余额加上amount。

此时问题变得十分明确：当免税地址作为sender转账时，代币合约并没有去校验sender的余额是否充足，甚至都没有从sender的balance中减去amount的操作。这也就意味着只要是代币合约定义的免税地址，就可以向任意地址发送任意数量的代币。这就是攻击合约（?0xc403）能直接转出999倍于总供应量的代币的原因。

经检查后发现，代币合约仅在构造函数中将_taxReceipt设置为免税地址，而_taxReceipt对应的地址正是攻击合约（?0xc403）。

自此确定了ZhongHua代币的RugPull的手法：攻击者利用特定的逻辑规避了对特权地址的余额校验，使得特权地址能凭空转出代币，进而完成RugPull。

  如何获利

利用上述的漏洞，攻击者地址2（?0x5100）直接调用拥有特权的攻击合约（?0xc403）的“swapExactETHForTokens”完成RugPull。“swapExactETHForTokens”函数中，攻击合约（?0xc403）为Uniswap V2 Router授予了代币转账权限，然后直接调用Router的代币兑换函数，用9,990亿个ZhongHua代币兑换出了池子中的5.88个ETH。

实际上，除了上述这笔进行RugPull的交易之外，项目方还通过攻击合约（?0xc403）在中途出售过11次代币，累计获得9.64ETH；加上最后一笔RugPull交易，共计获得15.52ETH。而成本不过是用于添加流动性的1.5个ETH、用于部署合约的少量手续费以及用于诱导打新机器人而进行主动兑换所花费的少量ETH。

甚至项目方中途还用不同的EOA地址去调用该攻击合约（?0xc403）进行代币出售，看上去是不同的sender在出售代币，以伪装其不断套现的真实意图。

总结

现在回过头来思考整个ZhongHua代币的RugPull案例，发现其手法本身很简单，不过是取消特权地址的代币余额校验而已。但是为什么在分析这个案例的时候却并没有那么顺利？主要原因可能有2点：

 1.安全防护和攻击的视野不同。对于安全从业者来说，代码中的余额校验是最基础需要完成的安全保障，因此大多数安全从业者都会潜意识地认为“transfer”函数理所应当地会完成对用户余额的校验，放松对这类漏洞的警惕（或者说认为这类漏洞太基础，攻击者不会采用）。

然而站在攻击者视角，最有效的攻击方式往往是最朴素的：不校验余额作为一种既有效又容易被忽略的RugPull手法，没有不使用的理由。事实也确实如此，至少从案例表征来看，ZhongHua代币案例的RugPull手法留下的痕迹是最少的，追踪起来难度远大于其他类型的RugPull，最后仍需要通过人工审计代码定位代码后门。

 2.项目方在有意识地掩盖特权地址不需要校验余额的后门代码。项目方甚至单独为非特权地址实现了一套完整的税收转账计算逻辑、代币地址提现再复投的逻辑，使得代币实现了复杂的转账逻辑看上去也合情合理。而其他普通地址进行转账时也与正常行为无异，在不仔细看代码的前提下完全无法发现任何端倪。

对比这个团队针对MUMI代币和ZhongHua代币的RugPull手法案例，二者都是通过相对隐蔽的方式使得特权地址拥有支配大量代币的权利。

在MUMI代币RugPull案例中，项目方直接修改balance，且不修改totalSupply，也不触发Transfer事件，使得用户无法感知特权地址已经拥有巨额代币。

而ZhongHua代币案例则是更彻底，通过直接不校验特权地址的余额，使得除看源码以外的任何手段都无法发现特权地址已经拥有了无上限的代币（用balanceOf查询特权地址的余额会显示是0，但却可以转出无限的代币）。

ZhongHua代币的RugPull案例反映出代币标准的潜在安全问题，ERC20代币标准在安全性方面只能用来约束君子而无法防范小人。攻击者往往会在实现符合标准的业务逻辑的前提下，藏下令人难以发觉的后门。如果通过将代币行为标准化，虽然减少了功能的灵活性，但避免了隐藏后门的可能性，提供了更多的安全保障。