可是逐步地，CPU 的短板还是被逐渐感知到了。更何况近些时来，大家热热闹闹地玩 AI，这个家伙不管是对 CPU 还是内存/GPU，都不会特别迁就。所以故技重施，先把办公室的干活儿主力机升了升格，从 Latitude 5401 升级到 Latitude 5431，再把退下来的 Latitude 5401 搬回家里来用（因为它也可以支持三硬盘）。不过比较讨厌的是，它已经不支持 BIOS/MBR 引导了，而且虽然没有实测，可直觉上其 m.2 插槽也不会支持 SATA 协议的 SSD 了。这就是说，现有的 T450s 上的三个系统，每一个都得换盘，不仅如此，还要视情况进行针对性的外科手术式迁移适配。

最先，也最顺利的是 Windows 10，毕竟咱有积累的经验打底。Ubuntu 的使用频度目前在家里不算高，因此暂时搁置。比较不好搞的是那份黑苹果。从以往的历篇博文也可以看出，在 T450s 上表现完美的Monterey 时至今日也已略显过时，而升级到 Sequoia 之后，本身在 T450s 上还算不得完美。历尽艰难，才把升级后遇到的无法登录的问题解决掉，而进入桌面后，陆续又发现一些使用上的毛刺。一是触控板驱动的不太对头，想触发点击操作，需要在触控板上连点两次；二是显示屏的亮度无法调节，这个情况应该是和显卡有关，理由是当我把这款盘从双显卡的 T450s 上平移到另一台只有核显的 T450s 上之后，调节亮度的控件就会正常出现；第三个问题也比较古怪，那就是如果把外置电池接上的话，系统引导的时候会卡死。基于这些，心想正好把黑苹果也干脆迁到 Latitude 5401 上就好了。

找了一块闲置的 m.2 的 SSD，用 DiskGenius 的磁盘克隆功能成功把原来 NGFF SSD 上的内容克隆了过来。需要说明的是，这份黑苹果目前面临着两个问题：1. 如何在 Latitude 5401 上才能引导起来；2. 它自身的状态与 Latitude 5401 是否能兼容。第一个问题的解决方法很标准，那就是在网络上找是否有现成的 EFI 被人分享了出来，幸运的很，确实有，在这里。不过在看作者的文档时，发现了一个之前少有的要求：需要使用技术手段微调这台本子的固件界面里不曾体现的选项。途径则是在 OpenCore 引导时，按空格键调出额外的引导项，进入到 OpenShell 控制台，按需执行 setup_var.efi 命令。要调整项的偏移和值文档中有现成的，但作者又提醒说，各人应该自行确认一下，以免失误导致设备变砖。于是三太爷不得不阅读 setup_var.efi 的文档，按步骤操作。首先去下载了 Intel 的 CSME System Tools 工具集中的 Flash Programming Tool（FPTW64.exe），执行 FPTW64.exe -bios -d bios-dump.bin 把设备当前的 BIOS 转储，然后使用 UEFITool 把所需的 Setup/* 节抽取出来，再用 IFRExtractor RS 把配置信息转为文本格式。最后打开转换后的文本文件，一一核对提及的需要修改的配置项的偏移，顺便把当前值记录下来，以便将来可能需要恢复回去。还好，所有的偏移均与 EFI 的作者列出的一致。

作为一个好奇宝宝，显然在修改之前必须尝试一次引导，以观察不修改的话会有什么后果。后果其实很直接：不能引导成功，会重启。老老实实修改后，引导进入到了 macOS 的安装器界面。令人痛苦的是，界面的文字非中非英，一眼看去像是俄文。为了后续的步骤可以看明白，总得把这个界面显示问题解决掉。问了 AI 若干次，也按照它的回复对 OpenCore 的 config.plist 调整了若干次，统统无效（例如在 boot-args 里加上 -apple-language en_US，并指定 SystemLanguage 等）。最后没辙儿了，拿出手机打开 Google 翻译，照着屏幕一看，翻译 app 判定显示语言为匈牙利语。靠着它，才发现第二菜单下的唯一下拉菜单项其实就是语言切换的入口，这样一来，引导问题算是基本搞定。

接下来就要尝试用这份 EFI 引导一下前面克隆完成的 SSD 上的 macOS Sequoia 了。把 SSD 插入插槽，用带着定制了的 EFI 的 macOS 安装引导 U 盘启动，结果是令人意想不到的失望，一而再再而三地重启，根本不能像之前那样进入到安装界面。后来不禁想，不会是 U 盘自己输了什么问题了吧，决定验证下。把 SSD 取下，用最简单的环境来测试，结果这次好了，又能进入安装界面（也是 macOS 的恢复界面）了。这下恍然大悟，看来是 SSD 在作祟。赶忙到搜索引擎里查询，果然有人早就警示：若干多的 SSD 与黑苹果相克，而老夫所用的海力士 BC711 赫然在列。好像说西部数据的好一些。

于是到闲鱼上查访，发现 SSD 这半年涨价的实在离谱，西数的 SN520，512GB 的竟然要 350 元上下（这还不算更离谱的标价）。要知道去年十月份，1TB 的 SSD 也就这个价。唉，黑苹果的迁移大业，先停停吧。

在 Windows 10 下，把源盘（SATA 盘）和目标盘（NVMe 盘）都用 USB 方式连接好。

第一步是先用 DiskGenius 磁盘克隆，此后源盘抛开，不再参与后续步骤。成功克隆目标盘后的第二步是用 DiskGenius 的分区表类型转换功能把其 MBR 分区表格式转换为 GPT 分区表格式。

第三步有少许精微，其目的是要把 GPT 引导所需的 ESP 分区和 Windows 系统所需的 MSR 分区设定好。一个常见的 GPT 分区布局是，ESP 分区位于磁盘首，而 MSR 稍显随意，相邻地位于系统所在分区之前或者之后（暂不考虑 Windows 的恢复分区）。现实情况是在 MBR 布局下已经存在于系统所在分区之后，因此仅需将其分区类型在 DiskGenius 的编辑分区参数界面中重新调整为 MSR 类型即可。ESP 分区需要单独处理，主要原因是当前磁盘上没有空余空间可以使用，因此需要先用 DiskGenius 调整系统所在分区的大小，在其之前缩出 500MB 即可。此时即可通过 DiskGenius 的“建立ESP/MSR分区”菜单完成 ESP 分区的创建。

接下来还有两步路走。

首先是把刚刚创建好的 ESP 分区上置入引导文件。正好当前运行的主机也是 Windows 10，因此可以在管理员权限的命令行下执行 bcdboot C:\Windows /s S: /f UEFI /l zh-cn 来完成。其中的 S: 是给 ESP 分区分配的盘符，这个工作也可以在 DiskGenius 里做。

第二步则是确认上一步创建出来的 BCD 文件是否可用，最佳工具首推 Bootice。使用它打开 S:\EFI\Microsoft\Boot\BCD 文件，在高级编辑模式下，把左侧栏中的对象树里的必要节点仔细检查一遍（主要是 Windows Boot Manager 节点以及 Application Objects 和 Windows Resume Objects 分支下的节点，把带有 Device 字样的 key（一般是 ApplicationDevice 或者 OSDevice）都要仔细审视一番，把对应的磁盘和分区（要特别注意：引导分区和系统分区是不一样的！）选择正确后保存。理论上，这块磁盘应该准备就绪了。

在实践中，上述操作一次性成功。

收拾，隔三岔五上架到小黄鱼上。一下子就从灰堆里扒拉出来几个路由器。内存 512MB，即使放在今天，也不能算小。之前是在 TF 卡上烧的 OpenWrt，昨晚又想到，有没可能给它上面跑个 Debian？

搜了一下，竟然搜到一个博主，其博客地址是 HackPascal @ Home，在数年前写过一个系列文章，就是在讲这个目标。大体看了一下，还挺复杂的，真要搞需要投入相当多的时间和精力，暂备于此。

• Debian for MT7621 折腾记 (1) – 实现基础系统正常启动 | HackPascal @ Home
• Debian for MT7621 折腾记 (2) – 实现 MT7530 DSA | HackPascal @ Home
• Debian for MT7621 折腾记 (3) – 编译 Debian Kernel Package | HackPascal @ Home

顺便提一下，在查找阅读过程中发现，该博主似乎是所谓的不死引导器 Breed 的作者。未予追证，后续再说。

Microsoft Agent 是 Microsoft 开发的一项技术，允许用户与应用程序和网页内的动画角色进行交互。它使用文本到语音（TTS）引擎来允许动画角色与最终用户对话。这些动画角色被称为“Microsoft Agent”。从 Windows 98 开始，它就预装在 Windows 中。Microsoft Agent 持续与所有 Windows 版本一起发布，直到 2009 年的 Windows 7，此后 Microsoft 停止提供 Microsoft Agent。Microsoft Agent 的最新版本是 1998 年 10 月 12 日发布的 2.0 版。

Microsoft Agent 允许软件用户通过 Microsoft Agent 角色编辑器创建角色。微软在原始页面上制作了四个默认角色，包括精灵、梅林、皮迪和罗比。其他一些值得注意的角色是 1997 年至 2003 年 Microsoft Office 套件中出现的角色，包括 Clippy、Dot 或 Office Logo。Windows XP 搜索助手也是 Microsoft Agent，包括 Rover。另一个值得一提的 Microsoft Agent 是 Bonzi，一只紫色大猩猩，它与 BonziBUDDY 捆绑在一起，直到其停产。Bonzi 角色后来因其多个 meme 视频而成为 meme，随后受到了广泛关注，最后又因一名主播直播了 XP 损毁而导致 Bonzi 角色的受欢迎程度上升。

上述引言来自于一个围绕 Microsoft Agent 技术而创建的社区页面，比较全面地介绍了 Microsoft Agent 是什么这一命题。

对于国人来讲，最知名的一个 Microsoft Agent 其实应该是瑞星杀毒软件中的小狮子，尽管在后期，由于各种原因，把小狮子的展示技术迁移到了 Adobe Flash。由于小狮子的形象备受人民群众的喜爱，甚至有爱好者自行制作了不包含瑞星杀毒软件本体的独立的小狮子安装包，如果你想体验的话，可以到这里下载：瑞星小狮子独立版下载 – 非凡手机软件。

当对技术的追思到二这个份儿上的时候，老夫突然想把非 SWF 版本的原始小狮子找到再看看。这个工作稍微绕了点，因为首先就是要找一个更老版本的瑞星杀毒软件的安装包。当然功夫不负有心人，还是被俺找到一份：瑞星杀毒软件 2004 官方 PC 版免费下载-天极下载。下载解包后看到里面确实存在 RsAgent.acs，这就和记忆对上了。

acs 文件是微软的角色构建工具（可以在这里下载）生成的，而制作的原始素材会用到 bmp 位图文件以及 wav 音频文件。如果你想把现成的 acs 文件逆向恢复成素材集，最妥善的方法当然是去了解 acs 的文件格式，尽管微软官方并未公开，好在前人栽过这棵树的，可以参看这个链接。文档作者也写好了一个现成的工具，在这儿下载。

微软官方文档站里目前还有相关内存，可以在这儿参阅；一个简单的入门介绍文档可以参阅这儿。

有了这些，俺又不免想到，怎么在这新时代里，旧物利用一下儿呢？

后些年间，在一个还算比较知名的厂里写软件，繁中区管那类软件叫“防病毒软件”，简中区叫“反病毒软件”，更多的时候叫“杀毒软件”，英文就是 Anti-Virus Software，因此在那些年里，AV 会让三太爷第一时间想到反病毒。

再后来，发现不少设备上有个接口，赫然就叫 AV，比如电视机、有线电视机顶盒，以及现在还有的电视盒子等等，原来它是 Audio-Video 输入/输出接口。

这个接口见的不少，不过用的却不多，原因无他，实在是科技进步迅速，数字信号传输的协议和接口都已不知进化了多少版本，而还处于模拟信号世界的 AV 传输就基本都在默默吃灰的状态下了。模拟信号的音视频传输除了 AV 口之外，还有一些别的接口，例如 BNC（中文叫同轴电缆）接口，以及与之经常同时使用的 RCA 接口。

AV 接口的插头跟更常使用的音频线（例如耳机）很容易混淆，因为它们的接口物理规格基本就一样，大体来说，AV 接口是直接把最高级的音频线接口拿来使用了。

音频线接口的粗细有两种规格，3.5mm 和 2.5mm，这个规格指标不影响传输的数据定义。此外的变化就是接口分为几段了。拿音频线来说，一开始只有两段，对应的通路一条传输音频模拟信号，一条是地线；后来为了支持立体声，就成为三段，音频模拟信号分为左声道和右声道，再加地线；再后来又要满足耳机和麦克风一体化传输的需求，再扩充一段成为四段，新增的为语音输入的模拟信号。这种四段规格的音频线在物理上就等同于 AV 线了，只不过 AV 线上传输的是视频模拟信号、左右声道音频模拟信号，以及接地。

几年前鼓捣某一种 Pi（大概就是现在手上还留着有那么一两个的 Orange Pi Zero），发现这类板子上好些个都有 AV 输出能力，只不过有的是只定义在 GPIO 阵脚上，有的则已经把 AV 插口一并落实到板子上了。依稀记得有一回为了测试 Raspberry Pi OS，还特意在闲鱼上购买了一个小尺寸的显示器。回来后把它和板子连起来，确实看到了那个简陋的桌面。至于物理接口，板子上的输出端是音频线接口制式的插口（即母口），显示器上的输入端是黄白红三分量莲花头接口。

几天前拾掇杂物，发现了 AD 送我的一块十六七年前的 GPS 卫星导航仪，系统是 Windows CE 6.0。被他折腾得似乎导航软件已经进不去了，开机就是 Windows 桌面。心想它能干啥呢，咦，发现它有一个 AV 输入口，只不过不是 3.5mm 口径，而是 2.5mm。不过我疑惑的是，既然开机就是 Windows CE 系统一直在输出视频画面，那么 AV 口的输入何时切换？问了一下 AI，回答是这类导航仪的 AV 口通常用于连接倒车影像的信号输入，此信号优先级被定义得比较高，一旦有信号传入，或抢占屏幕画面。

也就是说，如果当年这个型号为乐驾/ROGA A1800KIT 的导航仪在手的话，那个小显示器应该是不需要的。为了验证这个设想，不得不下单购置合适的连接线：连接输出端的是 3.5mm 四段音频线公头，而连接输入端的是 2.5mm 四段音频线公头。在淘宝上搜索，没有成品，但是有两端都是 3.5mm 四段音频线公头的成品线，以及 3.5mm 母转 2.5mm 公的四段音频线转接头，价格分别为 6.29 元包邮，以及 3.43 元包邮。加起来还不到 10 块钱，毫不手软地下单了。

到手后先串接起来，再用它把导航仪和 Orange Pi Zero 连接起来，Pi 加电引导成功后导航仪上未检测到有 AV 信号，这是意识到，恐怕 Pi 里的系统（应该是 Debian 或者 OpenWRT）根本就没有驱动 AV 输出。那怎么检测这根组合线是否能正常工作呢？

先是跑到客厅，用正在服役的联通 IPTV 盒子的 AV 输出口测试，仍然没有接收到输出的信号，把 HDMI 输出线拔掉也不行，把盒子待机后唤醒还不行。沮丧地回到书房，蓦然想到还有一个闲置的比较新的联通宽带赠送的盒子，于是把导航仪直接和它连接后开机。吼吼，导航仪屏幕上果然出现了联通盒子的输出画面。至此，上面开始的想法验证通过，这个导航仪确实可以当个显示器（准确地说是电视/监视器）使唤。

上图中，右上方的导航仪屏幕上显示的正是下面黑色的联通盒子输出的画面，左上的小显示器并未投入使用，只是出镜以供参看。导航仪的内置电池已经完全耗尽，因此需要 USB 供电，以后可以考虑拆开换一块电池。

最后的一个问题是，为什么客厅的盒子没能成功输出画面？猜想是跟盒子的状态有关，需要它在开机时就能检测到 AV 输出端口有线材接入了，从而激活输出信号。懒得去试了。

尽管已经证实，导航仪在一定程度上能代替小显示器，不过考虑到小显示器可以支持的信号输入硬件接口多样，暂时打消了断舍离将其脱手的念头。

简要总结： 这个页面是 Trammell Hudson 在 31C3 大会上关于 Thunderstrike 漏洞的演讲内容整理。它介绍了苹果 Mac EFI 固件的逆向工程过程、Thunderstrike 漏洞的原理，以及攻击方式和可能的防御措施。

内容要点

• 背景与动机
  • Thunderstrike 是一种针对苹果 EFI 固件的攻击方法。
  • 攻击者只需几秒钟的物理访问，就能将恶意代码写入 Mac 的启动 ROM。
  • 这种固件级 rootkit 很难清除，甚至能抵抗系统重装。
• 逆向工程过程
  • 演讲前半部分详细展示了如何逆向苹果的 EFI 启动 ROM，包括固件结构、校验机制和压缩方式。
  • 发现苹果使用 CRC32 校验而非加密签名来验证 ROM 内容，这意味着攻击者可以轻松绕过。
• Thunderstrike 漏洞原理
  • Thunderbolt 接口允许外部设备在启动时加载 Option ROM。
  • 攻击者可通过修改 Option ROM，在固件更新流程中替换苹果的 RSA 公钥，从而让系统接受伪造的固件。
  • 一旦攻击成功，ROM 中的公钥被替换，只有攻击者签名的更新才能被接受，形成持久控制。
• 演示与影响
  • 演讲展示了概念验证攻击：利用 Thunderbolt 设备在恢复模式下注入恶意固件。
  • 成功后，攻击者能安装不可移除的 rootkit，绕过密码、记录键盘输入等。
  • 这是典型的“evil maid attack”（恶意女仆攻击），即在用户不在场时通过外部设备入侵。
• 防御与缓解措施
  • Hudson 提到的防御策略包括：
    • 改进固件签名机制（使用真正的加密验证）。
    • 限制 Option ROM 的加载。
    • 加强物理安全（例如封堵接口）。
  • 他批评苹果当时的防御不足，强调需要硬件级的安全检查。

总结

Thunderstrike 漏洞揭示了苹果 Mac 在固件安全上的重大缺陷：攻击者可通过 Thunderbolt 接口在启动阶段写入恶意代码，获得持久控制。 这次演讲不仅展示了攻击过程，还呼吁业界加强固件层面的安全防护。

文 3 的参考链接 2 也可以一看。

[crayon-69e058b35a4b6581741191 inline="true" ]C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: overriding recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o'
C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: ignoring old recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o'
C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: overriding recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o.commands.json'
C/C++: C:/Android/Sdk/ndk/27.0.12077973/build/core/build-binary.mk:418: warning: ignoring old recipe for target 'C:\code\doom\build\intermediates\cxx\Debug\5523b6rn/obj/local/arm64-v8a/objs-debug/lzma_1.9/C/7zDec.o.commands.json'

不管是 overriding recipe for target 还是 ignoring old recipe for target，都没看懂是怎么回事。网上搜索到 SO 上的一篇帖子，说的也是含含糊糊，但似乎说到是跟目标重复有关。打开 build-binary.mk 脚本的看第 418 行是没有线索的，于是又去看工程里跟指定的对象 7zDec 相关的 makefile，这下就找到了问题，7zDec.c 这个要编译的源码文件被写了两回，显然就是导致了“overring”以及“ignoring”的“重复”的来源。

自适应图标是 Android O 引入的，也就是 Android 8（API level 是 26 的 Android 8.0 其 code name 是 O，而 API level 是 27 的 Android 8.1 也是）。

资源。为自适应图标做基础的资源类型也是相应新增的，叫做 AdaptiveIconDrawable。其定义形如：

[crayon-69e058b35a6e9205647920 inline="true" ]<adaptive-icon>
  <background android:drawable="@[drawable|mipmap|color]/bg_foo"/>
  <foreground android:drawable="@[drawable|mipmap|color]/fg_bar"/>
</adaptive-icon>

两个 drawable 的大小都必须是 108dp，背景 drawable 必须不透明，而前景 drawable 可以包含透明区域。

遮罩。需要说明的是，尽管自适应图标的大小是 108dp，但是最终显示/渲染一个自适应图标时，系统/设备/启动器所使用的施加于其上用以控制可见区域的遮罩，其大小却只能是 72dp。也就意味着，一个自适应图标的上下左右四个边，均有尺寸为 18dp 的部分在通常情况下是不可见的。

遮罩的形状必须是外凸（convex）的，其形状边缘至中心点的最小距离是 33dp。这也是下图中直径为 66dp 的所谓圆形“安全区”的由来。

渲染。从 Android 8 开始，截止到 Android 12 之前，如果创建图标时使用的是 createWithBitmap 方法，系统（此处主要是指 Google/Android 官方的行为）会对传统图标“以示尊重”，原样渲染，如果位图中存在透明区域，要么保持透明，要么可能渲染为某种特定的背景色（如黑色）。而从 Android 12 开始，系统决定不再给予传统图标那样的优惠待遇，使其长久地破坏系统的视觉效果一致性，于是决定将其缩小，并放置在白色的背景层之上。那会缩小到什么程度呢？就是可以完全放置在安全区以内的程度（可以参见旧文：Android 对非自适应图标的处理）。

Medium 上有人写的两篇博客，对于理解、应用、设计自适应图标具有参考价值。而且其中还提到了上文提及的被遮罩排除的那部分可以有什么样的利用价值。

• https://medium.com/androiddevelopers/implementing-adaptive-icons-1e4d1795470e
• https://medium.com/google-design/designing-adaptive-icons-515af294c783

Android 官方对 Icon 类的文档在：https://developer.android.com/reference/android/graphics/drawable/Icon。

尽管心里甚至有过设计原本如此的情愿，但还是想试验证实一下。首先把已经没电了的 BIOS 电池换掉，又尝试开机，开机失败，这排除了 BIOS 电池的影响。于是接入电源适配器后开机，进入 BIOS 设置，把内置电池设置为禁用。原本的计划是，再次进入 BIOS 后改为启用，但是看说明文字的叙述，禁用自动就是一个临时性措施，一旦重新接入电源适配器，内置电池就会自动启用。所以当第二次插入电源适配器后，没有再对 BIOS 进行修改，而是直接关机，然后拔掉电源适配器。

这时按下开关按键，开机了。显然只有内置电池是可以开机的。也许正是因为更换 BIOS 电池后，才使得内置电池的存在以及启用状态被持久化记忆了，所以开关键才可以正常触发。