南宫雪珊

特权隔离 本应该是Android系统中最受限的隔离进程，却拥有众多特权，非常奇妙。 0. 随机uid，曾经的magiskhide绕过方案，magisk已处理。 https://t.me/magiskalpha/255 1. app zygote的setuid权能在selinux关闭时不受限制，已失效。 https://t.me/vvb2060_Channel/81 2. app zygote可以检测selinux状态，ksu已处理。 https://t.me/magiskalpha/714 3. app zygote native没有unshare，和init挂载命名空间相同，无法隐藏。 https://t.me/vvb2060_Channel/60 现在，我们又发现了一个隔离进程的特权：遍历进程。隔离进程拥有gid 3009，可以不受限访问/proc。 这是从隔离进程诞生起就拥有的能力，但10年来无人发现。2020年Project Zero偶然发现app zygote拥有gid 3009，可惜的是，没有发现存在时间更久的隔离进程有一模一样的问题，并且修复补丁特意忽略了隔离进程情况，只对is_child_zygote清空groups，真是哭笑不得。 由于我们在某加固壳中观察到了野外利用，因此决定直接公开该漏洞细节。我们还编写了一个poc，以检测root为例： https://github.com/LSPosed/Privisolated

网上的资料都说 io_uring 因为漏洞过多，被Google在全部生产内核禁用，包括Android。但是 Android 2022 年就开始用 io_uring 了，当然仅限root进程：fastbootd、snapuserd、logd、statsd。 毕竟io_uring可以把OTA快照合并从15分钟减少到38秒，这等性能提升，无论如何也不该忽视。 https://cs.android.com/android/_/android/platform/system/fs/fs_mgr/+/beb8a96b61c38c9ddfa99e266abfb4718b67f86f

chrome 现在明确区分本地网络和本机回环

内部存储空间(显示为设备名字)，由外部存储设备(com.android.externalstorage)提供给SAF。 最近/图片/视频/音频/文档，由媒体选择工具(com.android.providers.media.module)提供给SAF。 下载由下载管理器(com.android.providers.downloads)提供给SAF。 SAF本身(com.android.documentsui) 并无存储访问权限，它只是中介，让用户浏览并且授权的界面。 同一个文件，显示在SAF不同位置，代表不同的来源和不同的URI，甚至文件类型也不同。例如下载管理器说某文件的类型是application/octet-stream，但在外部存储设备看来它是application/zip。通过SAF选择特定文件类型时需要注意这一点。 （补充一下老频道的帖子 https://t.me/vvb2060Channel/910

截止2025年12月，最低SDK级别28(Android 9)可以覆盖95%的设备。 SDK级别23(Android 6)已经是10年之前的版本。

GrapheneOS的胁迫密码是个失败设计，不如VeraCrypt的可否认嵌套卷。其实AOSP里面有类似功能，可以悄悄用起来：维修模式。 进入维修模式后，可以用sim卡，可以登录Google，可以安装app，可以设置锁屏密码，可以用adb，可以重启，什么都能做。 在系统设置中输入口令后退出维修模式，这个临时环境才会清空，回到原系统，特别适合入境审查这种场景。 当然，如果GrapheneOS宣传这个功能，它就不能用了，毕竟不能像VeraCrypt那样可以似是而非地否认其存在。通知、受管状态和系统设置都能发现这是维修模式，通知还能推迟让它不可见，另外两个没有办法。 或许GrapheneOS可以在这个功能的基础上改造出稳定存在的双系统，重点是可否认性，不能让肉眼和adb发现还有一个系统。data分区砍一半空间其实不难藏，Android本来就有很多内部占用。更极端一点可以让伪装系统越界覆盖原系统数据，这种VeraCrypt模式就真不可能发现了。 另外，这是针对adb检查的防御，如果只是肉眼看，多用户明显更好。注意，不是访客或者工作用户，是完整多用户。输入不同锁屏密码进入不同用户对GrapheneOS来说很简单，至少比胁迫密码好用。只可惜这种功能的有效性来源于隐秘，按照GrapheneOS的风格不会做。

https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getruntimeattestationreport 终于来了，调用这个API需要设备启用 TPM 2.0、安全启动、VBS、HVCI 和 IOMMU，信任根绑定到TPM根证书。现在全部主流操作系统均有设备运行状态证明。 GetRuntimeAttestationReport API 允许 VTL0 用户模式进程从安全内核检索已签名的运行时证明报告…

在任何SELinux宽容设备上临时安装Magisk 首先下载安装Magica，打开后如果是SELinux宽容，应该能看见启用adb root按钮，点按按钮。 第二步，使用电脑连接adb，这是具备完整Linux权能的root shell。 第三步，使用magisk官方脚本，临时安装magisk，具体操作可以看这里 https://t.me/magiskalpha/677 完毕，重启失效，因此安装模块后不要重启，重新执行第三步模拟重启即可。 警告：由于没有解锁bootloader，因此任何写入只读分区的行…

https://github.com/AnInsomniacy/aria2-builder/releases/tag/v1.37.0-9 发现一个使用OpenSSL作为TLS库的aria2构建项目，需要在 $HOME/.aria2/aria2.conf 配置 ca-certificate=${HOME}/.aria2/cacert.pem ，证书库在 https://curl.se/ca/cacert.pem 下载。 aria2 只对OpenSSL支持了TLS1.3，看来它还能苟很久，其它下载器都不争气啊（

假设使用最大带宽不断地发送数据，那么从发送第一个字节起，到得知第一个字节已被接收的这段时间内，一共发送了多少数据？ 这个数字可以用 带宽 乘以 来回延迟 计算，例如1 Gbps光纤 200ms延迟，1Gbit/s换算一下119.2MiB/s 乘 0.2s 等于 23.8MiB，这就是最大未确认数据大小。注意这是在途数据大小的2倍，因为有一半数据已经被接收，但发送端还不知道。 在TCP上，用发送窗口描述这个概念，它代表发送端需要多大的内存记录这些还未被确认接收的数据以便重发。发送窗口大小等于接收窗口和拥塞窗口较小的那个。 接收窗口由接收端控制，它表示可以积压多少已接收但未处理的数据。拥塞窗口由发送端根据网络状态计算，避免网络过载。 可以注意到，TCP发送窗口不等于链路的最大未确认数据大小，而是由接收端和拥塞状况控制。也就是说，假设接收端立即处理，接收窗口保持最大值；网络无拥塞，发送窗口等于接收窗口，一条TCP连接的速度也不会等于最大带宽，而是等于 接收窗口 除以 来回延迟。例如2MiB接收窗口，速度就是10MiB/s。 要充分使用带宽，必须调大接收窗口。虽然内核会自动增长接收窗口，但有最大值限制，例如系统管理员可能设置为8MiB，依然远远不够23.8MiB。所以程序唯一的办法是使用多条TCP连接，只需3条8MiB接收窗口的TCP连接，就能挤满这根1 Gbps光纤。如果往返延迟增加到500ms，59.6MiB需要8条TCP连接来填充。 以上内容并没有涉及到HTTP，HTTP/2的多路复用对充分使用带宽有帮助吗？答案是没有。HTTP1.0，客户端发送请求，接收服务器响应，随后TCP连接关闭。HTTP1.1启用长连接，客户端接收响应后不关闭连接，可以在同一TCP连接上继续发送请求并等待服务器响应。虽然两端都可以收发，但收的时候不能发，发的时候不能收，这被叫做半双工。意味着接收第一个JavaScript时，不能请求第二个JavaScript，需要等待前者下载完成。浏览器的解决方法是使用多个连接，直接发起新TCP连接下载第二个JavaScript，避免等待。虽然TCP是全双工的，也就是收的时候可以发，发的时候可以收，但HTTP1.1限制了这个能力，这才是HTTP/2多路复用解决的问题：HTTP/2随时发起请求，可以在一个TCP连接内承载多个HTTP请求-响应流，避免发起新TCP连接的握手时间。即使网页在一条TCP连接中同时接收多个文件，也没有触及这条连接的速度上限，网页显示更快的原因是延迟减少，而不是下载速度增加，所以HTTP/2是对大量小文件下载场景的优化。对于握手时间占比忽略不计的大文件下载，HTTP/2没有用处，反而会因为仅一条TCP连接限制了速度上限。 那么HTTP/3对充分使用带宽有帮助吗？QUIC能让客户端自定义接收窗口大小，肯定可以。但在目前的网络环境中，UDP丢包严重，所以QUIC的拥塞窗口远不如TCP大，拥有再大的接收窗口也无意义，用HTTP/3下载大文件暂时不是一个好主意。

Android已允许app绑定特权端口 这是通过 Connectivity/Tethering Mainline APEX 模块中的 eBPF cgroup 绑定钩子实现的。 该功能将作为 2026 年 5 月 Google Play 系统更新的一部分发布，该更新是 Android 17（包括最新 beta 版）的基本网络堆栈要求。 由于这是通过 cgroup/bind eBPF 程序动态评估的，因此系统避免降低全局 net.ipv4.ip_unprivileged_port_start sysctl…

https://keepandroidopen.org/zh-CN/ 今天第一次打开了这个网站，发现它的宣传方式和诈骗一模一样，没有理智的解释，只有耸人听闻的口号和充满暗示的文字。这让我很怀疑作者的目的是炒作。 Windows有SmartScreen，使用公共证书识别开发者身份，拦截未积累信誉的软件。MacOS有门禁，阻止运行未经签名和苹果公证的软件。 在它们实装这些功能时，没见有人出来抗议。在恶意软件危害最严重的Android平台，推出app来源认证时，开始抗议了。 最让我反感的是，这个网站在说谎，传播错误观点。 其开发的应用就会被封禁 错误，仅仅是不能立即安装或更新，已经安装的应用可以继续运行。 全世界所有应用、所有设备都不例外 错误，从系统自带商店安装的应用例外，例如企业政策安装。没有包含完整gms套件的设备例外，例如中国设备。 全球所有 Android 设备会悄然屏蔽他开发的应用 错误，不是悄悄的。不是突然执行的政策，apk也不会静默安装失败。 独立开发者、社区组织、业余爱好者等都将无法开发、发布自己的软件 错误，可以开发，可以发布。 无论是求学少年编写的第一个应用、志愿开发者制作的隐私工具，还是公司内部的保密测试版，均难逃一劫。自 2026 年 9 月之后，以上软件，若 Google 不“赏赐许可”，则都无法安装 错误，开发者可以通过adb直接安装任何apk。 Google 给予的“退路”，实则是陷阱 没有解释为什么称之为陷阱，它有什么意外的负面效果吗？ 关闭“确认你是否受到了胁迫”的恐吓性提示 把 「确认是否受到胁迫」称之为恐吓性提示，到底是谁在恐吓谁？ 如果 Google 能事后锁定数十亿台当初打着“开放平台”旗号售卖出去的设备，全世界其他硬件厂商都可能效仿 继续暗示高级流程不存在，是不能操作的陷阱，你的设备已经被锁定，无法使用。 安全只是借口。Google Play Protect 本身无需了解开发者的身份，即可扫描出恶意软件。即使 Google 索要开发者的身份证件，也无法保证代码安全，只能让开发者受到识别和监控。播撒恶意软件的开发者能够注册，独立开发者和异见人士却反而未必。EFF的评论一针见血：用身份证件把关，就是审查手段，而非安全措施。 正确，这套系统就是为了识别应用开发者身份，安全只是它的副产物。它在事前可以威慑恶意开发者，事发可以减少受害者数量，事后可以追溯开发者其它应用。 然而需要九步操作、等待二十四小时强制冷静期，不仅埋藏在开发者选项中，还依赖 Google 随时可中断的专有服务。这并非侧载，而是劝退机制，意图正是让大多数人都无法侧载。而且因为该功能通过 Play 服务而非系统实现，Google 可以悄然收紧或关停。 错误， 这就是侧载，并且不会劝退任何坚持侧载的人。另外开发者身份验证工具使用的框架在AOSP实现，并且adb shell持有android.permission.DEVELOPER_VERIFICATION_AGENT权限，与验证工具权限相同，开发者可以随意调整身份验证结果而不经过Google。 威权政府下的吹哨人、记者、活动家会首当其冲。其次会轮到家庭暴力受害者。这些群体有必要在分发或使用软件时不向 Google 数据库提供真实身份，理由正当。匿名贡献开源代码的传统早在 Google 建立前就已形成，但新政策会在 Android 上消灭这一传统。 错误，这些群体在安装使用app时不需要提供身份，我也不认为这些群体会由于所述身份而需要开发app。还有，所有贡献代码的人都需要实名的说法也是错误的，只有负责签名apk的实体需要身份证明，例如f-droid分发的所有apk应该由f-droid登记认证而不是具体项目的拥有者。 这个网页充满了诱导性文字，是欺诈的惯用手法，它刻意忽略了恶意软件开发者，认为所有开发者都是善意的，还强调受到政府压迫的群体。事实上，最担心自己app无法安装，又不想去注册的人正是恶意软件开发者。普通的个人开发者根本不担心用户无法安装，担心的开发者已经把app上架商店了。我预计只有极少数实体会注册开发者认证，例如f-droid。 当强制执行后，大部分用户完全不受影响，他们只从系统商店安装应用，或者侧载已认证开发者的app，例如telegram web。 少部分用户习惯侧载，他们会第一时间关闭开发者验证，这对他们很轻松，等24小时即永久关闭，等不及还可以用adb，几乎没有影响。 当一个从不侧载apk的用户突然急需安装一个未上架商店apk，看见未认证开发者提示，要求等待24小时。这就是剩下的情况了，也是这套机制的预期目标。我认为等待24小时是其中最妙的一点，它不影响日常有侧载需求的人，但对突然侧载的人提供了冷静期。 如果一个人明明知道侧载未知来源的apk需要等待24小时，但他坚持不打开开关，突然有一天想安装未注册的apk，又不会用adb，所以抱怨为什么要等待24小时，我的手机不属于我了，这叫脑子有病。

Windows 11 允许第三方应用程序使用基于虚拟化的安全飞地 https://aka.ms/VBSEnclavesBlog https://aka.ms/VBSEnclavesDevGuide

https://learn.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getruntimeattestationreport 终于来了，调用这个API需要设备启用 TPM 2.0、安全启动、VBS、HVCI 和 IOMMU，信任根绑定到TPM根证书。现在全部主流操作系统均有设备运行状态证明。 GetRuntimeAttestationReport API 允许 VTL0 用户模式进程从安全内核检索已签名的运行时证明报告。该报告提供已加载驱动程序列表和代码完整性信息，这对于验证系统完整性以及在游戏和安全敏感型应用程序中强制执行反作弊策略至关重要。

https://lore.org/ Lore是一个集中式、内容寻址的版本控制系统，使用默克尔树和不可变的版本链来表示仓库状态，并针对二进制优先存储、重复数据删除以及大规模的稀疏/按需数据水合进行了优化。 Lore 旨在处理的工作负载 它们与内容无关。一个典型的代码仓库包含源代码、构建输入、配置、预构建工件、大型数据文件、生成的内容以及任意二进制数据块。没有哪一种内容形式占据主导地位，也没有任何实用工具能够专门针对一种内容形式而将其他内容形式视为降级处理。 它们在各个方面都非常庞大：文件数量达数百万，单个文件大小达到TB级，历史记录包含数百万次的修订，每个项目有数百个分支，数千个并发用户，以及数百个代码库共享同一个后端部署。任何一个方面都足以让现有系统不堪重负；而所有这些因素加在一起，更是让现有系统彻底无力应对。 它们由中央统一协调。必须存在一个单一的逻辑数据源——用于访问控制、持久性、审计和冲突解决——但开发人员仍然需要能够离线工作、排队提交版本，并在无需往返远程服务器的情况下暂存更改。 设计文档全文： https://epicgames.github.io/lore/explanation/system-design 看起来不错，设计很先进，从一开始就避免了git的诸多设计问题。

Android17正式版发布 https://source.android.com/docs/whatsnew/android-17-release https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-17.0.0_r1

https://github.com/Kindness-Kismet/One-Player 使用libass完整支持ass字幕的media3播放器 之前在Android上能正常渲染ass字幕的播放器只有mx和mpv。

Android已允许app绑定特权端口 这是通过 Connectivity/Tethering Mainline APEX 模块中的 eBPF cgroup 绑定钩子实现的。 该功能将作为 2026 年 5 月 Google Play 系统更新的一部分发布，该更新是 Android 17（包括最新 beta 版）的基本网络堆栈要求。 由于这是通过 cgroup/bind eBPF 程序动态评估的，因此系统避免降低全局 net.ipv4.ip_unprivileged_port_start sysctl 权限或全局分配 CAP_NET_BIND_SERVICE 权限。相反，它会选择性地允许特定的常用协议： - TCP：20/21（FTP）、22（SSH/SFTP）、23（Telnet）、80（HTTP）、443（HTTPS）、445（SMB）、515（LPD）、631（IPP） - UDP：319/320（PTP），443（HTTP/3 / QUIC） 激活此功能的条件： - Android 13（API 33）或更高版本。在此之前的版本中，相关的 eBPF 代码尚未包含在主线版本中。 - 内核版本需为 5.15 或更高版本。这是一项硬性要求，因为旧版本内核缺少必要的 eBPF 返回标志基础架构，无法在绑定钩子期间绕过功能检查。 - 设备必须能够接收并积极应用 Google Play 系统更新（涵盖大多数标准认证的手机和平板电脑）。 注意：Android Auto、Wear、TV 或 Go 等应用可能会滞后，或者取决于系统供应商的完整 OTA 更新，具体取决于其主线实现情况。 源代码应该会与 Android 17 的其他部分一起发布，预计会在以下位置发布： https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Connectivity/bpf/progs/netd.c

Google不老实啊，chrome的私货请求头越来越多了 https://github.com/dsekz/chrome-x-browser-validation-header