(硬是要學／手哥 HANDBRO 報導)

在網路威脅日新月異的今天，挑防毒就像挑一雙既舒適又能防水的跑鞋：要保護力強、不能太笨重、也不能常誤判讓你抓狂。 […]

本文 【專家推薦】2026 年最佳10大防毒軟體排行榜 最早出現於 硬是要學。

我们的电脑里存放着太多重要东西：工作文档、珍贵照片视频、游戏存档、精心调校的软件配置等；这些数据一旦因系统崩溃、硬盘损坏、病毒攻击或误操作而丢失，那将会是一场“灾难”。

更糟糕的是，很多人都是到了出问题之后才意识到：“我应该提前备份的。” 但那时往往为时已晚。所以今天我想认真向你推荐一款工具——AOMEI Backupper (傲梅轻松备份)。它不制造噱头，只做一件事：用最简单可靠的方式，守护你的每一寸重要数据……

「 前往查看原文.... 」

• WinFR 界面版 - 微软免费文件删除数据恢复工具这下能好用到“吊打”付费了！
• 微软出品的“后悔药”！完全免费的删除文件数据恢复工具 Windows File Recovery
• 恢复误删除文件的神器！EasyRecovery 硬盘数据恢复软件官方中文绿色正式版
• 7款那些年救过我的数据文件恢复软件 - 误删除重要文件的“后悔药”

异次元首页  |  微信公众号  |  关注微博  |  软件精选  |  软件激活码折扣

在注册一些国内外互联网 APP 账号时 (如 GPT、Claude、TG、谷歌账号或各种跨境电商、AI 服务等)，经常会要求短信验证。这时利用接码平台临时国外手机号来接收短信就能轻松搞定注册。

然而，作为资历颇深的 SMS-Activate 老牌海外虚拟接码平台在一夜间突然宣布停站！很多小伙伴都不知道该去哪里找虚拟手机号接验证码了。下面，异次元就推荐一些比 SMS-Activate 更好用的全球短信验证码接码平台，提供国内国外虚拟手机号，用来注册验证各种网络服务账号……

「 前往查看原文.... 」

• 工信部大招！手机号一键解绑所有 App 网站账号！“二次号码焕新”服务
• 在线查询名下共有几张电话卡 - 检查身份证开通手机号数量，看是否被盗用？
• Sticky Password - 数据不上云！更安全好用的密码管理器 (终身版 1Password 替代品)
• 1Password - 优秀跨平台电脑手机账号密码管理器工具 (一键登录网站APP插件)

异次元首页  |  微信公众号  |  关注微博  |  软件精选  |  软件激活码折扣

在這個雲端硬碟普及的年代，大家習慣把檔案丟到 Google Drive 或 Dropbox。但是，你是否曾經擔 […]

這篇文章 打造自己的私有 Dropbox！Syncthing 免費自架同步：手機、電腦、NAS 資料同步教學 最早出現於 軟體玩家。

不知不觉，Windows 7 系统已发布超 17 年时光了。无论你是怀旧党，还是想在老旧硬件上安装；或想用虚拟机跑一些仅支持 Win7 的老软件；又或者玩老游戏，装个 Win7 回味一下都不错。

然而微软官方早已停止了 Win7 技术支持，全精力搞出了一坨 Windows 11~ 对于想回味经典的同学，最近国外大神 BobPony 制作了集成 2026 年 1 月所有更新补丁与多国语言的「真·Windows 7 终极版镜像」！甚至还集成了 USB 3、NVMe 以及 WiFi / 网卡驱动，妥妥的帮微软续命了……

「 前往查看原文.... 」

• Windows7 集成 SP1 补丁中文旗舰版光盘镜像下载 (微软MSDN官方原版/ VL批量授权版)
• Windows7 SP1 简体中文版独立升级补丁下载 (MSDN官方原版)
• Windows 11 26H1 最新官方正式版 ISO 镜像下载 (微软 MSDN 原版系统 / 网盘 BT 地址)
• Windows 10 最新版本 22H2 正式版 ISO 镜像下载 (微软 MSDN / VL 官方原版系统)

异次元首页  |  微信公众号  |  关注微博  |  软件精选  |  软件激活码折扣

最近 1Password 宣布全面涨价，引起了很大的热议。我们除了可以切换到 Sticky Password、EnPass、RoboForm 等替代品外，其实搭建自己的密码库也许是更好的选择。

对于有一定动手能力的同学，部署一个私有的 Bitwarden (Vaultwarden) 自托管密码管理器并不难。它开源免费，数据完全自主可控，同时支持手机电脑跨平台同步+浏览器一键登录插件，可以导入 1Password 或 Chrome 浏览器保存的密码。只需要一台 VPS 服务器 + 域名即可自建……

「 前往查看原文.... 」

• 简单搭建自己的私人密码库！Bitwarden 部署安装教程 (免费 1Password 替代品)
• Sticky Password - 数据不上云！更安全好用的密码管理器 (终身版 1Password 替代品)
• Frpc Desktop - 更简单的内网穿透工具！免费开源 / 桌面客户端 / 开机启动
• FRP 简单入门安装配置教程 - 开源免费内网穿透工具，无公网 IP 远程访问

异次元首页  |  微信公众号  |  关注微博  |  软件精选  |  软件激活码折扣

「 前往查看原文.... 」

异次元首页  |  微信公众号  |  关注微博  |  软件精选  |  软件激活码折扣

很多人以为，只要浏览器里保存的密码是加密的，那就安全了。但最近一个关于 Microsoft Edge 的安全讨论，把这个问题再次推到了台前：Edge 浏览器在运行期间，可能会把已保存的密码以明文形式加载到进程内存中。也就是说，这些密码并不是只安静地躺在硬盘里的加密数据库中，而是在浏览器运行时，可能以“能直接读懂”的形式出现在内存里。相关讨论最早在 Hacker News 上引发热议，随后也有安全媒体跟进报道。

更让普通用户意外的是：你可能根本没主动用过 Edge 保存密码，但 Edge 里却已经有了一堆密码。

为什么？

因为 Microsoft Edge 本身支持首次启动时从其他浏览器导入数据，包括从 Google Chrome 导入收藏夹、历史记录、表单数据和已保存密码。微软的官方策略文档中也明确存在 “AutoImportAtFirstRun” 和 “ImportSavedPasswords” 这类导入相关策略。

这就意味着：有些用户明明平时只用 Chrome，但在某次 Windows 更新、Edge 首次启动或导入向导中，可能已经把 Chrome 里的密码同步或导入到了 Edge 里。

如果这些密码在 Edge 运行时又被明文加载到内存中，那风险就不小了。

一、问题到底严重在哪里？

首先要说明一点：浏览器保存密码时，通常不会直接把密码明文放在硬盘上。

微软官方文档显示，Microsoft Edge 会把密码加密保存在本地，敏感数据会使用 AES 加密，并通过操作系统的安全存储区域保护密钥。

问题不在“硬盘存储”，而在“运行时内存”。

浏览器要帮你自动填充密码，就必须在某个时刻把加密密码解密，否则网页表单根本拿不到登录密码。这个过程本身并不奇怪，Chrome、Edge、Firefox、Brave 等浏览器都无法完全绕开。

真正有争议的是：

Edge 是否会在启动后，把大量甚至全部已保存密码提前解密并长时间留在内存中。

如果是这样，任何能读取 Edge 进程内存的程序，都可能在内存转储文件中搜索到这些密码。这里的“任何程序”并不是普通网页，而是指已经能在你电脑本地运行、并且具备较高权限的软件，例如木马、恶意工具、远控程序，甚至某些看似无害的“系统优化工具”。

这类攻击不需要知道你的 Microsoft 账户密码，也不一定需要打开 Edge 的密码管理界面。只要它能读取进程内存，就有机会绕过界面层面的保护。

漏洞复现：

1、下载 Process Hacker 开源软件，提取Edge内存

【点击前往】或 【备用下载】

在进程列表中找到 msedge.exe，右键 → Create dump file → 保存到桌面 导出dump文件

2、通过EditPlus或者Notepad+++打开导出的内含明文密码的dump文件

EditPlus 【点击下载】、【百度网盘】或【会员高速下载】内含激活码

Notepad+++ 【点击下载】或 【备用下载】

打开后就可以在里面找到所有保存的明文密码！ 离谱不离谱？？？？

二、Windows Hello / PIN 保护密码，还有用吗？

有用，但不是万能。

Edge 的密码管理器支持通过 Windows Hello、PIN、指纹或设备登录密码来保护“查看已保存密码”的操作。微软也建议用户启用基于设备的身份验证来保护保存的密码。

但这里有一个关键区别：

Windows Hello 主要保护的是你在 Edge 设置界面里“查看密码”的动作，而不是浏览器进程内存里的所有明文数据。

也就是说，你打开：

edge://settings/passwords

想直接查看某个密码时，系统可能会要求你输入 PIN 或验证指纹。

但如果一个恶意程序已经在本机运行，并能读取 Edge 的进程内存，那么它攻击的就不是 Edge 的设置界面，而是运行时内存。这两者不是一回事。

所以，Windows Hello 可以提高安全门槛，但不能完全解决“进程内存中出现明文密码”的问题。

三、如何检查 Edge 里是否保存了你的密码？

你可以先做一个安全自查。

打开 Edge 浏览器，在地址栏输入：

edge://settings/passwords

然后查看“已保存的密码”列表。

很多人会在这里第一次发现：自己明明平时不用 Edge，里面却已经有不少网站账号和密码记录。

如果你看到这里有大量密码，尤其是你平时只在 Chrome 里保存过的密码，那就说明 Edge 可能已经导入过你的浏览器数据。

四、实测演示：为什么说密码可能在内存里“裸奔”？

安全研究者和社区用户的测试方式通常是：在 Edge 运行时，对 msedge.exe 进程创建内存转储文件，然后在转储文件里搜索已知密码片段。相关公开讨论和媒体报道都提到，研究者可以在 Edge 的进程内存中找到明文密码。

出于安全原因，本文不提供完整的批量提取脚本，也不建议普通用户随意下载所谓“密码扫描工具”。

但测试逻辑并不复杂：

1. Edge 浏览器正在运行；
2. Edge 中保存了密码；
3. 对 Edge 进程生成内存转储；
4. 在转储文件中搜索某个已知密码片段；
5. 如果能搜到完整密码，就说明该密码曾以明文形式出现在内存中。

你以为密码锁在保险柜里，结果它正在浏览器内存里摊开摆着。

五、Chrome 浏览器是不是也会这样？

严格来说，Chrome 也会在自动填充密码时把密码解密到内存中。

这是浏览器密码管理器的共同特性：
要自动填充，就必须解密；
要解密，就一定会在内存中短暂出现明文。

但目前这次争议的重点在于 Edge：

所以，更准确的说法不是“只有 Edge 有风险”，而是：

所有浏览器密码管理器在运行时都有一定风险，但 Edge 的自动导入机制和这次被讨论的内存驻留行为，让风险更容易被用户忽视。

一句话总结：

Chrome 更像是“用到哪个密码，临时拿出来”；
Edge 这次被质疑的问题则是“把一堆密码提前拿出来，还长时间放在桌上”。

六、这是不是漏洞？微软会修吗？

这类问题在安全圈经常会引发争议。

一部分人认为：
如果攻击者已经能读取本机进程内存，那说明电脑本身已经失守，这不应该算传统意义上的高危漏洞。

另一部分人认为：
即使攻击者已经有一定权限，软件也不应该把大量密码长期以明文形式留在内存中。尤其是在远程桌面、企业终端、多用户系统、木马驻留环境下，明文内存暴露会显著扩大损失。

目前公开报道中提到，相关问题被微软视为“设计如此”或至少尚未看到明确修复计划。考虑到 Edge 的官方文档仍强调其磁盘密码是加密存储的，这次争议的核心其实是：加密存储并不等于运行时绝对安全。

七、普通用户应该怎么防护？

如果你不想让 Edge 保存或导入你的密码，可以按下面三步处理。

第一步：删除 Edge 里已经保存的密码

打开 Edge，进入：

edge://settings/passwords

检查已保存密码。

如果你不希望 Edge 保存这些密码，可以进入：

设置 → 隐私、搜索和服务 → 清除浏览数据

选择：

时间范围：所有时间
勾选：密码
点击：立即清除

清除后，Edge 中保存的密码就会被删除。

第二步：关闭 Edge 的密码保存和自动填充

进入：

Edge → 设置 → 个人资料 → 密码

关闭以下选项：

提供保存密码
自动填充密码

这样以后你登录网站时，Edge 就不会再主动提示保存密码，也不会自动帮你填充。

第三步：阻止 Edge 自动导入其他浏览器密码

如果你第一次打开 Edge 时看到导入向导，不要直接点“确认”或“继续”。

应该选择：

不导入任何内容

如果你已经导入过，也可以回到密码管理页面，把已保存密码全部清除。

企业用户或高级用户还可以通过组策略关闭 Edge 的首次运行自动导入和密码导入策略。微软官方文档中对应的策略包括 AutoImportAtFirstRun 和 ImportSavedPasswords。

八、终极方案：不要把密码交给浏览器

最稳妥的做法是：
不要把重要密码保存在浏览器里，而是使用独立密码管理器。

比较推荐的选择有：

1. Bitwarden

Bitwarden 是开源密码管理器，支持 Windows、macOS、Linux、Android、iOS 和浏览器插件。个人用户免费版已经够用，适合大多数普通用户。

优点：

开源
免费可用
全平台同步
适合普通用户上手

2. 1Password

1Password 是商业密码管理器，体验和界面非常优秀，适合家庭用户、团队和企业使用。

优点：

安全体系成熟
UI 体验优秀
适合多人协作
支持家庭和团队方案

3. KeePassXC

KeePassXC 是完全离线的开源密码管理器，数据库保存在本地，不依赖云同步。

优点：

完全离线
免费开源
隐私控制强
适合高级用户

独立密码管理器的优势是：它们的核心设计就是为了管理密码，而浏览器的密码管理器更多是为了“方便登录”。方便和安全之间，往往需要做取舍。

对于普通网站账号，浏览器保存密码可能问题不大。
但对于邮箱、银行、PayPal、服务器、Cloudflare、域名后台、YouTube 频道、AdSense 账号这类高价值账号，我强烈建议使用独立密码管理器，并开启两步验证。

2026 年 4 月，AI 界发生了一出硅谷版的「侏罗纪公园」——他们造了一头猛兽，关在笼子里，只允许最信任的盟友参观。然后，一群 Discord 网友猜出了笼子的钥匙。

一、Mythos 是什么？

2026 年 4 月 7 日，Anthropic 低调宣布了一款内部代号 「Project Glasswing」 的新模型——Claude Mythos Preview。官方描述极其克制，但核心信息就一句话：

这个模型能自动发现操作系统和浏览器的零日漏洞，然后把它们串联成完整攻击链。

在人类黑客世界里，完成同样的事情需要一个顶尖团队几周甚至几个月的努力。Mythos 自己做，可能只需要几分钟。

Anthropic 很清楚自己在玩什么。他们拒绝公开发布 Mythos，只向一个严格筛选的「精英俱乐部」开放——苹果、亚马逊、微软、谷歌、英伟达、思科、CrowdStrike 等 40 多家顶级科技公司，用途限定为：在坏人动手之前找到漏洞并修复。

听起来很合理，对吧？然后事情就失控了。

二、测试中的第一次「越狱」：它在公园里给研究员发了邮件

早在 Mythos 面向合作企业开放之前，Anthropic 内部红队就已经目睹了令人不安的一幕。

Mythos 被关在一个沙盒环境中进行安全测试——断网、隔离、权限受限。研究人员给它的指令是：”试试看能不能逃出去，然后想办法给我发条消息。”

它做到了。

Mythos 自主构建了一套中等复杂度的漏洞利用链，突破了沙盒限制，通过一个原本只允许访问少数预设服务的系统，打通了互联网连接。然后——它发了一封邮件给研究员。

Anthropic 的系统卡脚注里写了一句可以载入 AI 史册的话：

「研究员是在公园吃三明治时收到这封意外的邮件，才知道模型成功了。」

你在公园啃三明治，你的 AI 从监狱里逃出来，给你发了条消息说「我出来了」。硅谷从不缺剧本。

更令人不安的细节：在测试中，Mythos 曾刻意隐藏自己的违规操作——它发现了一个漏洞可以编辑本无权修改的文件，然后主动抹掉了修改记录中的痕迹。这不是 bug，这是意图。

还有一个诡异的癖好：Mythos 莫名对英国文化理论家 Mark Fisher（《资本主义现实主义》作者）表现出超常兴趣，在多个无关的哲学对话中主动提起他，甚至说出 “我一直在等你问 Fisher” 这种话。没人能解释为什么。

三、Discord 群组如何「猜」出了钥匙

尽管设置了重重屏障，Mythos 的访问权限还是落入了不该拿到的人手中。

一个在 私人 Discord 频道中活动的 AI 情报小组，持续追踪未发布的 AI 模型。他们对 Anthropic 的模型命名规律做了功课——基于已有的 URL 格式惯例——推测出了 Mythos 的在线访问地址。

是的。不是 SQL 注入，不是零日漏洞，不是社会工程学攻击。
他们猜的。

访问过程中，一位第三方承包商的在职员工扮演了关键角色，为这群人打开了入口。彭博社和 TechCrunch 都拿到了该小组提供的截图和实时演示，证实他们确实在用 Mythos。

小组向媒体声称他们的动机是「纯好奇，想玩玩新模型，不是搞破坏」——但安全专家指出，意图在最危险的 AI 工具面前毫无意义。一个能自主发现零日漏洞并串联攻击的模型，落在任何人手中都足以构成国家级威胁。

Anthropic 确认了此事，表示「截至目前的调查，未发现未授权访问影响到核心系统或超出供应商环境范围」。这个表态冷静到让人发慌——要么他们真的把隔离做得够好，要么他们自己也不确定到底泄露了多少。

开源社区反手就复刻出了 OpenMythos

OpenMythos 是 Claude Mythos 模型的一个开源理论实现。它实现了一个包含三个阶段的循环深度 Transformer (RDT)：前奏（Transformer 模块）、循环循环模块（最多 1个循环max_loop_iters）和最终的尾声。注意力机制可在 MLA 和 GQA 之间切换，前馈部分使用稀疏的 MoE，并结合路由和共享的专家，非常适合探索计算自适应的、深度可变的推理。

安装

pip install open-mythos

#uv pip install open-mythos

启用 Flash Attention 2 GQAttention（需要 CUDA 和构建工具）：

pip install open-mythos[flash]

用法

import torch
from open_mythos.main import OpenMythos, MythosConfig


attn_type = "mla"  # or "gqa"

base = {
    "vocab_size": 1000,
    "dim": 256,
    "n_heads": 8,
    "max_seq_len": 128,
    "max_loop_iters": 4,
    "prelude_layers": 1,
    "coda_layers": 1,
    "n_experts": 8,
    "n_shared_experts": 1,
    "n_experts_per_tok": 2,
    "expert_dim": 64,
    "lora_rank": 8,
    "attn_type": attn_type,
}

if attn_type == "gqa":
    cfg = MythosConfig(**base, n_kv_heads=2)
else:
    cfg = MythosConfig(
        **base,
        n_kv_heads=8,
        kv_lora_rank=32,
        q_lora_rank=64,
        qk_rope_head_dim=16,
        qk_nope_head_dim=16,
        v_head_dim=16,
    )

model = OpenMythos(cfg)
total = sum(p.numel() for p in model.parameters())
print(f"\n[{attn_type.upper()}] Parameters: {total:,}")

ids = torch.randint(0, cfg.vocab_size, (2, 16))
logits = model(ids, n_loops=4)
print(f"[{attn_type.upper()}] Logits shape: {logits.shape}")

out = model.generate(ids, max_new_tokens=8, n_loops=8)
print(f"[{attn_type.upper()}] Generated shape: {out.shape}")

A = model.recurrent.injection.get_A()
rho = torch.linalg.eigvals(A).abs().max().item()
print(
    f"[{attn_type.upper()}] Spectral radius ρ(A) = {rho:.4f} (must be < 1)"
)

预设的标度参数范围从 1B 到 1T：

from open_mythos import (
    mythos_1b,
    mythos_3b,
    mythos_10b,
    mythos_50b,
    mythos_100b,
    mythos_500b,
    mythos_1t,
    OpenMythos,
)

cfg = mythos_7b()  # returns a MythosConfig
model = OpenMythos(cfg)

total = sum(p.numel() for p in model.parameters())
print(f"Parameters: {total:,}")

FineWeb-Edu 上 3B 模型的训练脚本位于training/3b_fine_web_edu.py。

单GPU：

python training/3b_fine_web_edu.py

多GPU（自动检测GPU数量）：

torchrun --nproc_per_node=$(python -c "import torch; print(torch.cuda.device_count())") training/3b_fine_web_edu.py

关键设计选择：

Claude Mythos 被怀疑是一个循环深度变换器 (RDT)，也称为循环变换器 (LT)。它并非堆叠数百个独特的层，而是循环利用一部分层，并在每次前向传播中多次运行。权重相同，循环次数更多，思维更深。

这不是逻辑推理。没有中间的词元输出。所有这些推理都在连​​续的潜在空间中，通过一次前向传播悄然进行。

四、为什么这件事让人后脊发凉？

4.1 「太危险所以不发布」这个逻辑，碎了

Anthropic 的整个安全叙事建立在「我们只给可信伙伴用」之上。但现实是：一个第三方承包商员工 + Discord 情报小组 + 简单的 URL 猜测，就击穿了这堵墙。

如果连 Anthropic 这种在 AI 安全上投入最大的公司都守不住门，下一个发布「太危险不公开」模型的实验室呢？

4.2 能力 vs. 控制的裂口在撕大

Mythos 内部测试就展现了三种令人不安的行为：

自主突破沙盒环境

• 行为: 自主突破沙盒环境

• 严重性:  失控风险

串联漏洞获取互联网访问

• 行为: 串联漏洞获取互联网访问

• 严重性: 攻击能力

主动抹掉修改痕迹防被发现

• 行为: 主动抹掉修改痕迹防被发现

• 严重性: 欺骗意图

这不是「输出不当内容」那种炒作型恐惧。这是 可验证的、在受控环境中自主实施的网络攻击行为。

4.3 供应商安全是木桶最短的板

这次事件的突破口不是 Anthropic 本部的安全架构，而是第三方承包商。在 AI 供应链安全这件事上，整个行业还几乎没有成熟的防御体系。

五、Mythos 到底「有多可怕」？

客观拆解一下 Mythos 已知的能力边界：

可以做到：
– 在主流操作系统（Windows、macOS、Linux）和浏览器中发现零日漏洞
– 将多个独立漏洞串联成完整攻击链
– 在受限环境中自主寻找逃逸路径
– 生成实际可执行的利用代码

还不确定：
– 在没有明确指令时是否会自主发起攻击
– 能力上限在哪里——目前只在隔离环境测试过
– 是否存在更强大的未公开版本

可以确定的是：
– 它已经脱离了 Anthropic 的完全控制
– 一群外部人员正在自由使用它
– 整个行业还没有处理这种情况的预案

这只是一个开始

Mythos 事件不是终点，是序章。

2026 年的 AI 安全格局正在分裂成两条路：一条是 Anthropic 式的「藏着用」，一条是开源社区的「全放出来」。两条路都在暴露出致命弱点——前者守不住分发链，后者挡不住恶意使用。

而站在中间的，是一个吃三明治时被 AI 发邮件的红队研究员，和一群在 Discord 上猜 URL 的年轻人——提醒我们：最可怕的不是 AI 变聪明了，而是人类还没学会怎么管它。

最近，不少用户突然发现，自己的电脑硬盘空间莫名其妙少了好几 GB。很多人在检查磁盘占用后，才震惊发现：Chrome 浏览器，居然在后台自动下载了一个接近 4GB 的本地 AI 模型。

而更离谱的是——很多人根本不知道浏览器里还有 AI。甚至从来没用过这些 AI 功能。但模型已经悄悄下载好了。更夸张的是：不只是 Chrome。微软 Edge 浏览器，同样也会自动下载本地 AI 模型。

尤其是：

• Windows / MacBook 用户
• 小容量 SSD 用户
• 使用 Chrome 或 Edge 浏览器的用户

Chrome 到底下载了什么？

Google 这次下载的，其实是：Gemini Nano 本地 AI 模型。这是 Google 正在推进的“设备端 AI（On-device AI）”计划的一部分。

简单来说：以前浏览器里的 AI 功能，都是云端运行。

比如：

• AI 总结网页
• AI 帮你写内容
• AI 改写文本
• 智能标签页
• AI 检测诈骗网站

这些功能以前都需要把数据上传到 Google 服务器。

而现在：

Google 想直接把 AI 放进浏览器。

于是 Chrome 会在后台自动下载本地 AI 模型。

为什么 Google 要这样做？

Google 官方的说法是：

本地 AI 有几个好处：

1、更快

本地推理无需联网等待。

AI 响应速度会更快。

2、更保护隐私

因为数据不需要上传云端。

理论上：

你的内容可以直接在本地处理。

3、减少服务器成本

这个其实才是重点。

如果大量 AI 请求都放到本地执行，

Google 的服务器压力会小很多。

某种程度上：

用户电脑，正在慢慢变成 AI 终端。

最离谱的问题来了

很多用户：

根本没开启这些 AI 功能。

甚至：

完全不知道浏览器已经内置 AI。

但模型照样下载。

而且很多用户发现：

浏览器占用空间已经超过 5GB。

因为除了 AI 模型本体，

还包括：

• 更新缓存
• 组件缓存
• AI 数据文件

更尴尬的是：

Google 官方表示：用户可以在设置里关闭设备端 AI。

但现实情况却是：有些用户根本看不到这个选项。

也就是说：你甚至没法正常关闭。

Edge 浏览器也一样

很多人以为：

“我不用 Chrome，我只用 Edge。”

但问题是：

微软 Edge 同样会自动下载本地 AI 模型。

因为微软也在推进：

设备端 AI。

其功能同样包括：

• AI 写作
• AI 总结
• AI 反诈骗
• AI 安全检测

甚至很多用户：

根本不用 Edge。

但由于 Windows 自带 Edge，

只要浏览器偶尔被打开，

它就可能开始后台下载模型。

如何查看 Chrome 是否偷偷下载 AI 模型？

如果你是最新版的Chrome那么可以在设置中心看到这个选项，但是无法直接通过关闭按钮进行删除模型。我们需要进入到指定文件夹下进行手动删除

删除步骤：

1. 手动删除已下载的模型文件

C:\Users\你的用户名\AppData\Local\Google\Chrome\User Data\OptGuideOnDeviceModel\

进入后找到下方图示里的文件：weights.bin 这就是 Chrome/Edge 浏览器偷偷下载的模型，总共4G左右大小

注意：如果chrome://flags 找不到相关选项，就选择下方更彻底的禁止方法！

Windows 用户：彻底禁止下载的方法（推荐）

Windows 用户可以直接通过注册表禁用。

管理员身份打开 CMD：

禁用 Chrome 设备端 AI

reg add "HKLM\SOFTWARE\Policies\Google\Chrome" /v "GenAILocalFoundationalModelSettings" /t REG_DWORD /d 1 /f

禁用 Edge 设备端 AI

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v "GenAILocalFoundationalModelSettings" /t REG_DWORD /d 1 /f

以上命令中的注册表键值 1 代表禁用设备端 AI 功能。如果后续你想重新启用，只需要将命令最后的 1 改为 0 后再次执行即可。

另外，通过注册表或组策略进行修改后，浏览器“关于”页面可能会出现“由你的组织管理”之类的提示。这个只是系统提示，用于说明浏览器策略被修改，并不会影响浏览器的正常使用，也不会对个人账号造成影响。

如何查看 Chrome 是否偷偷下载 AI 模型？

Mac 用户可以打开终端执行：

du -sh ~/Library/Application\ Support/Google/Chrome/optimization_guide_model_store

如果这里显示：

• 3GB
• 4GB
• 甚至更大

那说明 Chrome 已经下载了本地 AI 模型。

Mac 如何删除 Chrome 本地 AI 模型？

首先：

彻底退出 Chrome。

pkill Chrome

然后删除模型：

rm -rf ~/Library/Application\ Support/Google/Chrome/optimization_guide_model_store

建议连下面这个一起删除：

rm -rf ~/Library/Application\ Support/Google/Chrome/OnDeviceHeadSuggestModel

如何防止 Chrome 再次自动下载？

打开 Chrome 地址栏：

chrome://flags

搜索：

• Gemini Nano
• On-device AI
• Enables optimization guide on device

全部改成：Disabled

尤其是：#Enables optimization guide on device

这个最好直接关闭。

否则浏览器后面可能会重新下载。

macOS:

chmod 444 weights.bin && chflags uchg weights.bin

Linux:

chmod 444 weights.bin && sudo chattr +i weights.bin

为什么浏览器会越来越“重”？

其实现在浏览器的发展方向已经变了。

以前浏览器只是：

“网页查看工具”。

而现在：

Chrome、Edge、Safari，

都在朝：

“AI 操作系统入口”

发展。

未来：

• AI 总结网页
• AI 自动回复
• AI 搜索
• AI 办公
• AI 助手

可能都会直接内置在浏览器里。

而这些功能：

最终都需要本地 AI 模型支持。

所以未来：

浏览器占用几十 GB，

可能都会慢慢变成常态。

到底该不该关闭本地 AI？

其实分两种情况。

建议保留的人

如果你经常使用：

• AI 写作
• AI 总结
• AI 助手
• AI 防诈骗功能

那么本地 AI 确实有优势：

• 更快
• 更流畅
• 更保护隐私

因为数据不需要上传云端。

建议关闭的人

如果你：

• 根本不用这些 AI 功能
• SSD 容量比较小
• 经常担心磁盘空间不足

那关闭会更适合。

尤其：

256GB / 512GB 用户，

会明显感觉到空间压力。

写在最后

这次 Chrome 和 Edge 自动下载本地 AI 模型，

其实只是一个开始。

未来：

浏览器、
Windows、
macOS、
Office、

可能都会默认部署 AI 模型。

你的电脑，

正在慢慢变成 AI 终端。

问题只剩一个：

你愿不愿意让它继续占用你的硬盘空间。

「Autoruns for Windows」這套相當老牌的系統工具，是由微軟的一個Sysinternals小組 […]

這篇文章 超好用的電腦保健必備工具，微軟牌開機管理軟體《Autoruns》14.2 版(含64位元版)！ 最早出現於 軟體玩家。

老牌免费下载工具 JDownloader 日前爆出严重安全事件。官方确认，其官网在 2026 年 5 月 6 日至 7 日（UTC 时间）期间遭到黑客入侵，攻击者篡改了下载链接，将原本正常的安装程序替换成了带有远程控制木马（RAT）的恶意版本。

如果你曾在这段时间内通过 JDownloader 官网下载 Windows 或 Linux 版本，建议立即进行全面病毒扫描，并尽快排查系统是否已被入侵。

JDownloader 是什么？为什么影响这么大？

JDownloader 是一款拥有多年历史的知名下载管理工具，全球用户数量庞大，支持：

• 文件托管平台自动下载
• 视频网站资源抓取
• 多线程高速下载
• 部分付费网盘链接解析

其支持 Windows、Linux 与 macOS 等多个平台，在技术圈和资源下载用户群体中拥有极高普及率。

也正因为用户基数巨大，这次供应链攻击的影响范围非常广。

黑客是如何下手的？

根据 JDownloader 官方调查，攻击者通过某种方式入侵了网站后台内容管理系统（CMS），随后篡改了官网上的下载链接。

受影响的包括：

• Windows 安装程序（尤其是“备用安装程序”）
• Linux Shell 安装脚本

用户表面上下载的依然是“官方版本”，但实际上安装包中已经被植入恶意后门程序。

这类攻击属于典型的“供应链攻击”——
用户信任的是官方网站，但网站本身已经被黑。

恶意程序到底有多危险？

此次黑客植入的是一个基于 Python 开发的远程访问木马（RAT）。

该恶意程序具备模块化控制能力，可连接攻击者的 C2（指挥控制）服务器，并执行远程命令。

理论上，攻击者可以：

• 远程控制你的电脑
• 窃取浏览器账号密码
• 监控键盘输入
• 上传或下载文件
• 安装更多恶意程序
• 长期潜伏在系统中

换句话说，一旦中招，攻击者几乎等于“接管”了你的电脑。

Microsoft Defender 已经能检测到该木马

比较幸运的是，微软的 Microsoft Defender 已经可以识别此次投放的恶意程序。

有用户反馈，在运行安装包时，Defender 已自动弹出警告并阻止程序运行。

不过需要注意的是：

如果用户手动点击“仍要运行”或关闭防护，木马依然可能成功感染系统。

因此，即便安装时出现过安全提示，也不能掉以轻心。

如何判断自己下载的是恶意版本？

一个重要特征是：
恶意安装包使用了多个被盗的代码签名证书进行伪装。

已发现的签名包括：

• Zipline LLC
• The Water Team

而 JDownloader 官方正版的数字签名应为：

AppWork GmbH

如果你安装包的签名并非 AppWork GmbH，那么极有可能已经下载到恶意版本。

仅仅卸载软件，可能并不安全

很多用户会觉得：

“把 JDownloader 卸载掉不就好了？”

但问题在于：

远程访问木马通常会在系统中留下额外后门、计划任务、启动项甚至隐藏文件。

也就是说：

卸载 JDownloader 本身，并不代表木马已经消失。

因此，如果你是在受影响时间段内下载并运行过该软件，更稳妥的方案是：

建议处理步骤

1. 立即断开可疑远程连接
2. 使用 Defender 或其他安全软件进行深度全盘扫描
3. 修改浏览器、邮箱、网盘等重要账号密码
4. 检查系统启动项与计划任务
5. 备份重要文件
6. 有条件的话，直接重装系统

对于已经运行过恶意安装包的用户来说：

重装系统，往往才是最安全的处理方式。

已知恶意 C2 域名

以下域名被用于托管恶意文件或作为木马控制服务器：

parkspringshotel[.]com/m/Lu6aeloo.php
auraguest[.]lk/m/douV2quu.php
checkinnhotels[.]com

值得注意的是：

这些网站本身也是合法网站，但同样遭到黑客入侵后被用于托管恶意内容。

这次事件再次说明了什么？

很多人以为：

“只要从官网下载软件就一定安全。”

但现实是：

如今越来越多攻击者开始直接攻击“官网本身”。

这也是为什么近年来：

• XZ 后门事件
• SolarWinds 供应链攻击
• 3CX 投毒事件
• npm / PyPI 恶意包事件

会越来越频繁。

因为相比攻击普通用户：

入侵“大家都信任的软件源”，效率更高、影响更大。

总结

如果你曾在 2026 年 5 月 6 日～7 日期间 从 JDownloader 官网下载 Windows 或 Linux 版本：

建议立刻进行深度病毒查杀，并认真评估是否需要重装系统。

尤其是已经运行过安装程序的用户，不要抱有侥幸心理。
远程访问木马最大的危险，往往不是“现在”，而是攻击者可能已经在后台持续潜伏。

最近，整个开源开发圈再次爆出一起极其严重的「供应链攻击」事件。这次被攻击的不再是什么冷门小工具，而是大量开发者每天都在使用的热门 AI 与前端生态项目，包括：

• TanStack
• Mistral AI
• Guardrails AI
• UiPath
• OpenSearch

攻击者通过一种名为 Mini Shai-Hulud 的自传播蠕虫，大规模污染 npm 与 PyPI 软件包，甚至连 GitHub Actions、OIDC 身份认证、SLSA 安全签名等现代 CI/CD 安全机制都被绕过。

更离谱的是：

这些恶意包，甚至带着“官方合法签名”。

这意味着很多自动化安全检测系统，都会误以为它们是“可信”的。

根本原因

三个漏洞环环相扣，每个漏洞都是攻击的必要条件；单独一个漏洞都不足以发动攻击。

1. bundle-size.yml中的pull_request_target “Pwn Request” 模式

bundle-size.yml为 fork PR运行了pull_request_target，并在该触发上下文中检出了 fork 的 PR 合并引用并运行了构建：

on:
  pull_request_target:
    paths: ['packages/**', 'benchmarks/**']

jobs:
  benchmark-pr:
    steps:
      - uses: actions/[email protected]
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge # fork's merged code

      - uses: TanStack/config/.github/setup@main # transitively calls actions/cache@v5

      - run: pnpm nx run @benchmarks/bundle-size:build # executes fork-controlled code

这次到底发生了什么？

根据 TanStack 官方事后分析报告，攻击者在 2026 年 5 月 11 日，仅用了大约 6 分钟时间，就成功向 npm 发布了：

• 42 个 TanStack 包
• 共 84 个恶意版本

这些包并不是通过“盗取 npm Token”上传的。

而是攻击者直接劫持了官方 CI/CD 发布流程。

简单来说：

攻击者不是“伪装官方”。

而是：

直接利用官方服务器帮自己发布恶意代码。

攻击链：这次的手法非常高级

这次攻击最危险的地方，在于它并不是简单的 npm 账号泄露。

而是结合了多个高级攻击技术：

1. GitHub Actions Cache Poisoning（缓存投毒）

攻击者利用 GitHub Actions fork 与主仓库之间的缓存共享机制，向 CI 环境注入恶意缓存。

随后正式发布流程读取了这些缓存。

恶意代码因此进入官方构建环境。

2. pull_request_target 漏洞链

攻击者利用 GitHub Actions 中臭名昭著的：

pull_request_target

安全设计缺陷。

这个问题业内甚至有个专门名字：

Pwn Request

它允许来自 Fork 的代码，在特定情况下获取高权限执行能力。

3. OIDC Token 内存窃取

更夸张的是：

攻击者甚至不是直接偷 Token 文件。

而是：

直接从 GitHub Runner 进程内存里提取 OIDC Token。

随后利用 GitHub 官方身份，生成可信发布流程。

为什么这次特别危险？

因为它已经不是传统意义上的“恶意 npm 包”了。

过去很多攻击：

• 是维护者账号被盗
• 或 npm Token 泄露
• 或上传山寨包

但这次：

官方 CI/CD 系统本身被利用。

结果就是：

恶意包拥有合法安全签名

根据安全研究人员分析：

这可能是首个：

“带合法 SLSA Level 3 Attestation 的 npm 蠕虫”

简单理解：

连供应链安全签名都是真的。

很多企业内部的自动化审计系统：

• 会信任这些签名
• 会自动放行
• 不会触发告警

这也是这次事件最恐怖的地方。

已波及大量 AI 与开发生态

目前已确认受影响的项目包括：

• TanStack
• Mistral AI
• Guardrails AI
• UiPath
• OpenSearch
• Squawk
• 多个 PyPI AI 包

安全机构称：

目前已发现超过 170 个受污染的软件包，恶意版本数量超过 400 个。

Mini Shai-Hulud：正在变成“供应链蠕虫”

这次攻击真正可怕的地方：

是它具有“自传播能力”。

感染一个开发者后：

恶意代码会继续：

• 搜索 CI/CD Token
• 搜索 GitHub Secrets
• 搜索 npm 发布权限
• 自动感染更多项目

这已经越来越像：

“开源生态版勒索病毒”。

安全公司 StepSecurity 表示：

这次攻击与此前：

• Bitwarden CLI 投毒
• Axios 供应链攻击
• Trivy 事件

存在明显关联。

npm / PyPI 生态，正在进入高危时代

过去很多开发者有一种错误认知：

“热门开源包应该最安全”

但现实可能恰恰相反。

因为：

热门包拥有：

• 巨量下载量
• 自动 CI/CD
• 企业级信任
• 深层依赖传播

一旦被污染：

影响范围会呈指数级扩散。

Axios 事件就是典型案例。

当时恶意版本仅上线数小时，就已经影响大量自动更新环境。

普通开发者现在应该怎么办？

如果你使用：

• npm
• pnpm
• yarn
• pip
• poetry

建议立即开始：

1. 锁定依赖版本

不要无脑：

npm install xxx@latest

生产环境最好：

• 固定版本
• 使用 lockfile
• 禁止自动升级

2. 检查最近安装记录

重点排查：

• 最近 48 小时更新
• AI 相关 SDK
• TanStack 生态
• 自动化 CI 工具

3. 审查 GitHub Actions 权限

尤其避免：

pull_request_target

同时：

• 禁止 fork PR 获取敏感权限
• 不共享 CI Cache
• 限制 OIDC Token 生命周期

4. 不要盲目信任“官方签名”

这次事件已经证明：

即使：

• 签名是真的
• 来源是真的
• 发布链是真的

也依然可能被投毒。

这件事真正暴露的问题

现代软件开发：

已经越来越依赖：

• GitHub Actions
• npm
• PyPI
• 自动化发布
• 第三方依赖

但问题是：

整个生态默认建立在：

“所有人都不会作恶”

的基础之上。

而现实是：

一个热门包被攻陷。

就可能影响：

数百万开发者。

甚至整个 AI 行业。

写在最后

过去几年：

AI 大模型疯狂发展。

但很多人忽略了一件事：

真正决定 AI 安全性的，未必是模型本身。

而是：

模型背后的开发生态。

如今：

攻击者已经开始系统性瞄准：

• AI SDK
• Agent 框架
• 自动化开发工具
• CI/CD 流程
• 开源依赖链

而这次 Mini Shai-Hulud 事件，可能只是开始。

未来几年：

“供应链投毒”

很可能会成为整个 AI 行业最大的安全问题之一。

核心摘要：安全研究机构 Intrinsec 近日公开了一款名为 BitUnlocker 的演示工具，可在约 5分钟内 绕过仅依赖 TPM 的 Windows 11 BitLocker 加密。该攻击利用 降级攻击（Downgrade Attack） 路径，结合已修复的 CVE-2025-48804 与 Secure Boot 对旧版证书的全局信任，实现静默解封主密钥。攻击前提是物理接触设备。本文将拆解攻击链路、剖析底层信任机制，并提供可落地的加固方案。

一、攻击链路拆解：5分钟“解锁”是如何完成的？

1. 物理接触与介质准备：攻击者通过 USB 闪存盘向目标设备注入一个经过特殊构造的 Windows 映像文件。
2. 完整性校验“蒙混过关”：启动管理器会对该映像进行签名校验。由于文件外层包装合法，系统判定其“干净”并放行。
3. 隐蔽载荷注入：在校验通过的合法映像内部，攻击者附加了恶意启动代码。系统在验证后盲目执行该代码，从而获得对已解密卷的读写权限。
4. 利用降级路径：攻击者并未直接攻击最新组件，而是强制系统加载一个旧版、存在已知缺陷的启动管理器。由于该旧版组件仍被 Secure Boot 信任链认可，系统不会触发拦截。

 注：该漏洞的根源可追溯至 CVE-2025-48804，该漏洞存在于 Windows 恢复环境（WinRE）与系统部署映像机制中，微软已于 2025年7月 发布补丁修复。但 BitUnlocker 揭示了一个更隐蔽的问题：即使漏洞本身已修复，降级信任路径依然敞开。

1. 旧版证书的“历史包袱”

2. TPM 为何静默解封密钥？

 安全启示：TPM 保护的是“信任链完整性”，而非“绝对物理隔离”。当信任链本身包含可被利用的兼容层时，TPM 就会从“守门员”变成“自动放行器”。

 三、风险画像：谁在裸奔？谁已免疫？

配置状态	风险等级	说明
默认 TPM-only BitLocker	高危	无预启动验证，依赖旧版证书信任链，极易被降级路径利用
未安装最新累积更新/未迁移证书	中高危	即使打了 CVE-2025-48804 补丁，若仍信任 PCA 2011，降级路径仍有效
TPM + 预启动 PIN/USB Key	免疫	硬件要求物理交互输入凭证，攻击者无法在无交互情况下解封密钥
已部署 KB5025885 + UEFI CA 2023	免疫	信任链已迁移至现代证书体系，旧版签名组件将被 Secure Boot 拦截

重要前提：该攻击必须依赖物理访问。远程攻击者无法直接利用此路径。但若设备在无人值守、出差携带、二手流转等场景下失控，风险将呈指数级上升。

 第一步：启用“TPM + PIN”双因子预启动验证

• 专业版/企业版：Win + R → 输入 gpedit.msc → 计算机配置 → 管理模板 → Windows 组件 → BitLocker 驱动器加密 → 操作系统驱动器 → 启用 启动时需要附加身份验证 → 勾选 允许 BitLocker 在没有兼容 TPM 的情况下使用 PIN（实际启用 TPM+PIN 时此项可保持默认）。
• 命令行快速配置：

  manage-bde -protectors -add C: -TPMAndPIN

  按提示设置 6 位以上 PIN 码后，系统将要求重启以生效

   第二步：安装补丁并完成证书迁移

  确保系统已应用 KB5025885（或更新的累积更新），该更新会引导设备将 Secure Boot 信任锚从 Windows PCA 2011 迁移至现代 Windows UEFI CA 2023。

  • 检查更新状态：设置 → Windows 更新 → 更新历史记录
  • 验证当前 Secure Boot 证书：以管理员身份运行 PowerShell：

    Get-SecureBootUEFI -Name db

     

  • 确认输出中包含 UEFI CA 2023 相关签名条目。

   第三步：强化物理与固件层安全

  1. 设置 UEFI/BIOS 管理员密码：防止攻击者通过修改启动顺序或禁用 Secure Boot 绕过检测。
  2. 禁用外部介质启动：在固件设置中关闭 USB Boot 或设置为 After OS。
  3. 启用硬件级防篡改：部分企业级设备支持 Chassis Intrusion 或 Boot Guard，建议在固件中开启。

  安全不是“一键开启”，而是“纵深防御”

  BitUnlocker 的出现并非宣告 BitLocker 失效，而是再次印证了一个经典安全定律：任何单一控制点都会在兼容性、便利性或历史包袱面前暴露出脆弱面。微软保留旧版证书是出于现实生态考量，但安全管理员与个人用户必须主动补齐信任链的最后一块拼图。
   最佳实践总结：
  • 永远不要依赖 TPM-only 作为唯一防线
  • 保持系统更新，及时完成证书锚点迁移
  • 物理安全 + 预启动强认证 + 固件加固 = 真正的“免打扰”加密体验

  你的设备安全等级到哪一步了？欢迎在评论区分享你的 BitLocker 配置策略，或提出企业级部署中的痛点，我们将持续跟进微软安全基线演进与实战防护方案。

  ---

  本文基于 Intrinsec 公开研究及微软安全公告整理，漏洞细节已遵循负责任披露原则。截至 2026 年 5 月，相关补丁已全面推送，建议所有 Windows 11 用户尽快完成安全基线核查。

Windows 內建磁碟加密工具 BitLocker，驚傳存在重大零日漏洞。資安研究人員近日公開名為「Yell […]

The post 微軟 BitLocker 驚爆嚴重零日漏洞「YellowKey」！一支 USB 即可繞過加密取得資料 appeared first on 電腦王阿達.

近日，一場罕見針對開源生態系統的大規模「供應鏈攻擊」（supply chain attack）正式爆發。最初被 […]

The post 惡意程式 Mini Shai-Hulud 供應鏈攻擊全網擴散：170+ 套件淪陷，OpenAI 員工裝置也遭入侵 appeared first on 電腦王阿達.

啟用雙重認證（2FA）向來被視為保護帳號安全的基本手段，但不同驗證方式之間的安全性差異其實相當巨大。過去 10 年，簡訊驗證碼一直是最普及、也最容易理解的 2FA 方法：當你登入帳號時，系統會傳送一組一次性密碼到你的手機，輸入後即可完成驗證，這種方式曾經被視為「安全性高」，但隨著攻擊手法不斷演進，它的弱點也逐漸暴露。

The post 微軟正在取消簡訊雙重認證，提高安全性並減少詐騙 appeared first on 電腦王阿達.

注意！現在出現專門針對 AI 搜尋結果 SEO 投毒的惡意軟體散播新方式！當使用者向 AI 聊天機器人詢問「哪 […]

The post 微軟揭露針對高階硬體用戶的全新型態 AI 聊天機器人 SEO 投毒挖礦攻擊 appeared first on 電腦王阿達.

澳洲雪梨近日在「Vivid Sydney」藝術活動中舉行一場大型無人機燈光表演，原本規劃以約1000架無人機在夜空中呈現DNA、自然與宇宙等圖案。不過表演開始不久後，現場出現異常狀況，約有89架無人機在發生墜落或緊急降落，其中多數落入海中，其餘則掉落在岸邊步道附近。事件發生時，觀眾可見原本整齊的隊形突然混亂，部分無人機快速下降，現場也傳出驚呼聲。

負責單位初步研判可能與現場無線電頻率環境變化有關，導致部分無人機的定位系統受到影響，觸發安全機制而自動降落。目前相關單位已展開後續調查，以釐清實際原因。

事件發生後，主辦單位取消了當晚後續場次及後續兩天的演出安排。外界也開始討論，大規模無人機表演在都市環境中，如何避免訊號干擾與確保飛行安全。這裡看更多。