我们已对
Baseband_guard(内核级基带防护模块) 进行开源

理论已兼容所有内核(GKI、OKI均适配)及ngki4.14&qgki5.4测试均可完美集成

需要的小伙伴可对本仓库进行fork自行集成 请遵循GPL-2.0规范

诚邀各路Developer对本仓库提交更多优化及适配

开源地址：
https://github.com/vc-teahouse/Baseband-guard/

不妨点点star加星标 非常感谢你的支持

BBG分区保护自检脚本更新

本脚本SHA256值：

94bb89bfa1a99c1100d11b524e7b76d737d5ccc2c953fcb407922ea4cac5b566

执行任何非本SHA256值的脚本造成的一切后果自负

秋刀鱼内核用户手册

因telegram的字数和格式限制，强烈建议到github仓库阅读完整版并参与编辑
https://github.com/QDYGKI/qdy_kernel_manual/blob/main/README.md

秋刀鱼内核适用范围
- 品牌：一加、真我
- 处理器：骁龙8至尊版、天玑9400+
- 内核版本：6.6.X
- 系统：ColorOS OxygenOS Realme. 20251101更新:已适配ColorOS16，但使用前请确保fastboot模式正常且具有救砖能力. 锁fastboot就不要用了. 一加平板2pro 系统版本小于15.0.1.600的禁止刷入，否则不开机.

前提条件
1. 手机已有 root 权限（无论是 Magisk、KernelSU 还是 Apatch）。
2. 下载安装 Sukisu Ultra 管理器 和 MT 管理器 这两个 app，并用你现在的 root 方案的管理器授予其 root 权限。
3. 手机上有一个可用的 VPN（国外或软路由用户可忽略），如果开启了应用白名单，需要把 MT 管理器添加至白名单。

快速开始
1. 在 Telegram 中找到秋刀鱼内核下载 bot：@qdykernel_download_bot，向bot发送 /download 指令。
2. 复制 bot 回复的命令，打开 MT 管理器，从左上角菜单键打开工具栏中的 终端模拟器（MT 终端扩展包装不装都行）。
3. 在终端中粘贴命令并回车，等待几秒。
4. 如果一切正常，终端将输出设备码，例如：

Please copy the following string and send it to the bot(including ==). 
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ 
BwRaWFcMFVlnhdzhiufBSTIKCEFRQTafDmMjIj9QVVEwXFRHQ0ddT1xWX0UiJ0NYRA==

5. 复制设备码（注意 ↓↓↓ 下方的才是设备码，不要把英文提示也复制了。设备码末尾是否有等号、有几个等号都不重要，但如果有等号一定不要漏掉），将设备码发送给 bot，等待内核上传（访问量小的情况下大概 10 秒，内核文件大小在 30Mb 左右）。
6. 下载内核，保存到自己能找到的路径。（不要试图解压下载的zip文件，保持原样。）
7. 打开 Sukisu Ultra app，点主页上方的状态显示（显示未安装或工作中的大方框），点击 刷写AnyKernel3，选择刚才保存的zip格式的内核文件（使用系统文件选择器而不是MT管理器等第三方文件管理器），选择槽位不用动，保持默认，点确认，KPM修补保持跟随内核，点下一步。
8. 刷入内核时，脚本会询问是否修补KPM，如果你不知道什么是KPM，建议直接按一下音量上键，跳过修补。当跳转浏览器显示秋刀鱼内核声明时，表示内核安装成功，可以重启手机了。

设备码理论上只需要获取一次，后续获取内核时可以先发送 /download 指令，再复制粘贴发送之前聊天记录中的设备码给bot，无需再次到MT管理器执行命令获取。
相同设备每两小时只能从bot获取一次内核。触发速率限制将返回 "错误: 内核制作失败，服务器内部问题。"

内核获取和刷入步骤视频演示 https://github.com/EU65/qdy_bot_manual/raw/refs/heads/main/media/video_guide.mp4

下载bot如果无法正常回复或者下载，请使用备用方案（需要登录，Telegram、Github都可以直接登录，一个不行就试试另一个）

1. 访问 https://ttydtest0.1007890.xyz/
并按提示登录github账号（复制链接到Chrome、Firefox等浏览器打开，不要直接在TG内打开）
2.MT管理器终端模拟器执行命令获得设备码

/system/bin/su -c "curl -Ls https://github.com/QDYGKI/scripts/raw/main/read-id -o /data/read-id-elf.sh&&chmod +x /data/read-id-elf.sh&&/data/read-id-elf.sh"

3.将设备码粘贴到网页，点提交
4.按提示检查内核制作状态并下载

制作后请尽快下载，24h不下载可能会被清理，清理后网页状态会显示正在制作

注意，域名换了，解决了oppo系统浏览器和via浏览器无法访问或无法下载的问题。1dm+、ADM等多数外部下载器现在也可以正常使用了。

https://github.com/cctv18/oppo_oplus_realme_sm8750
欧加真6.6系列风驰移植内核编译脚本已经正式发布
目前已有版本：6.6.30/6.6.50（天玑）/6.6.56/6.6.57/6.6.66/6.6.89，均已移植官方风驰scx调速器（来自真我官方源码，在支持风驰内核的机型上可实现完整风驰调度功能）
支持可选SukiSU Ultra&KernelSU Next/lz4 1.10.0+zstd 1.5.7补丁/ADIOS IO调度器/BBG防格机保护/Re:Kernel等
欢迎大家测试，如果遇到bug或有改进建议可在群里反馈
Ciallo～(∠・ω< )⌒☆

https://github.com/showdo/AOSP-Testkey-BootSigner
使用Google公钥对init_boot/boot/vbmeta等镜像签名

适用于联想拯救者Y700四/三/二代等由Google公钥签名的镜像

联想拯救者Y700四/三/二代签名boot后可免解BL刷入GKI

使用示例：

aria2c -s16 -x16 -k1M "https://github.com/showdo/AOSP-Testkey-BootSigner/archive/refs/heads/main.tar.gz" -o boot_avb_tool.tar.gz && \
mkdir -p boot_avb_tool && \
tar -xzf boot_avb_tool.tar.gz -C boot_avb_tool && \
rm -f boot_avb_tool.tar.gz && \
cp ./common/out/arch/arm64/boot/Image ./boot_avb_tool/AOSP-Testkey-BootSigner-main/kernel
 cd boot_avb_tool/AOSP-Testkey-BootSigner-main && \
curl -L -o boot.img https://github.com/showdo/AOSP-Testkey-BootSigner/releases/download/TB322FC_1.1.11.202/boot.img
cp ./tools/magiskboot ./magiskboot
chmod +x ./magiskboot
./magiskboot repack boot.img
rm -f ./boot.img kernel
mv ./new-boot.img ./boot.img
python3 rebuild_avb.py --chained-mode
#最后签名完成的boot.img会覆盖当前目录下原boot.img
#原未签名的boot.img将自动备份至当前目录下backup*开头目录中

https://github.com/Tools-cx-app/vintf-check
用于检测/system/etc/vintf/*的文件内容是否与当前config.gz冲突的（如果有 https://www.coolapk.com/feed/66267336?s=YjMxODFiOGUwZzY5MDcyY2Niega1560 类似情况，可以使用此工具进行排查）

#misc

联想拯救者Y700四代内核构建支持免解BL自签工作流

✅可自定义内核名称+内核构建时间
✅支持默认官方构建时间
✅默认开启KPM补丁
✅添加Lz4 v1.10.0 & zstd v1.5.7补丁
✅自定义开启BBG基带防护
✅自选使用AOSP公钥签名boot(支持免解BL刷入)

⭐构建前须知：
其中6.6.56为120及以下系统使用 6.6.89为188、202系统使用

开源地址：
https://github.com/showdo/build_Lenovo_sm8750

几个昨天出现的常见问题
1.在SukiSU v3 修补过LKM的，刷入SukiSU v4 GKI后需要还原原厂 init_boot,否则旧版本LKM与新版本GKI共存可能会遇到不定时崩溃重启、掉root、炸环境等问题。
另请参考sukisu issue https://github.com/SukiSU-Ultra/SukiSU-Ultra/issues/557
尽量使用zygisknext和lsposed-it.部分分支似乎在ksu2.0会不工作甚至导致卡开机
如果仍然频繁重启，特别是打开mt管理器等需要root的软件就卡住重启，卸载管理器重新安装一次试试
2.昨天获取设备码发给bot但解析失败的，可以重新执行获取命令，读取程序已修复
3.从其他root方案转到sukisu或者全新安装,刷完新内核重启后管理器仍显示未安装，可以先装一个3.2.0的旧版本管理器，重启，然后再升到4.0.0
4.使用40119版本内核的，管理器最好也用40119，升级管理器可能导致增强安全性等开关不可用、看不了sulog等小问题

支持的机型：
一加13
一加13T
一加Ace5Pro
一加Ace5至尊版
一加平板2Pro
真我GT7
真我GT7Pro
真我GT7Pro竞速版
真我GT8

Xposed 模块，用于修复可忽略码点（如零宽空格
导致的可访问 /sdcard/Android/{data,obb}/package 漏洞。

我们的内核均已支持fuse bpf ^1 无需配用vold app data 隔离
直接安装该模块并启用勾选
「媒体选择工具」即生效

MT终端直接输入以下测试命令(不要以SU执行)并回车

测试命令：

find $'/storage/emulated/\342\200\2130/Android/data/'

报错Permission denied即成功

模块下载链接：
https://t.me/real5ec1cff/271

注意：
本次更新为集成ReSukiSU，非SukiSU-Ultra

更换ReSukiSU的食用方式：

1️⃣使用原SukiSU管理器刷入本内核(不要直接重启)
2️⃣安装ReSukiSU管理器
3️⃣卸载原SukiSU-Ultra管理器
4️⃣重启手机

Q：为什么突然换ReSukiSU了？
A：光管理器上的ui就有很多原sukisu没有的，目前原SukiSU已经随缘更新，且最新的SukiSU管理器默认为miuix了，故更换为ReSukiSU

@QDYGKI_CHAT 另一个chat，此群不限制发言（但是仍不允许挂）

由于挂钩太多，现已private

#里群链接

echo eHdyenc6Ly9rLnppLyttS2FjcEFiWTM5OGFLSmY5Cg== | base64 -d

不过有套一层简单的加密

提示1：base64解密后的文本是一个某个古典密码学上产生的结果，它将凯撒密码的全部 25 种位移排序为一张表，与原字母序列共同组成 26 行及 26 列的字母表。另外，必须要一个秘钥密钥长度需要与明文长度相同，如果少于明文长度，则重复拼接直到相同。
提示 2: 大小写区分
秘钥就在频道上

祝大家元宵节快乐！

暂时的离别是为了更好的重逢！

群组被封申诉请前往 @vc_yc_bot 提交申诉
请不要直接私信管理or秋刀鱼
一般最常见封禁是加入挂群被ban的 申诉前请将挂群退出 退出后基本都会解除封禁
再次说明：
不要直接私信任何管理！

/** @file VbRwStateApp.c

  UEFI Application that calls QCOM_VERIFIEDBOOT_PROTOCOL.VBRwDeviceState
  with op=WRITE_CONFIG (1), 16-byte buffer: byte0=1, byte8=1.

  Copyright (c) 2025. All rights reserved.

**/

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/UefiApplicationEntryPoint.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/BaseMemoryLib.h>
#include <Protocol/EFIVerifiedBoot.h>

#define VB_RW_BUF_SIZE  3344

/**
  Entry point: Locate QCOM_VERIFIEDBOOT_PROTOCOL and call VBRwDeviceState
  with op=WRITE_CONFIG (1), 16-byte buffer with buf[0]=1, buf[8]=1.

  @param[in] ImageHandle    Image handle for this application.
  @param[in] SystemTable    Pointer to the EFI System Table.

  @retval EFI_SUCCESS      Call succeeded.
  @retval other            LocateProtocol or VBRwDeviceState failed.
**/
EFI_STATUS
EFIAPI
UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS                    Status;
  QCOM_VERIFIEDBOOT_PROTOCOL   *VbProtocol;
  // UINT8                         Buf[VB_RW_BUF_SIZE];
  UINT32                        BufLen = VB_RW_BUF_SIZE;
    // EFI_GUID gEfiQcomVerifiedBootProtocolGuid1 =       { 0x8e5eff91, 0x21b6, 0x47d3, { 0xaf, 0x2b, 0xc1, 0x5a, 0x1, 0xe0, 0x20, 0xec } };
  UINT8 Buf[3344];

  // Locate QCOM Verified Boot Protocol
  Status = gBS->LocateProtocol (
                  &gEfiQcomVerifiedBootProtocolGuid,
                  NULL,
                  (VOID **)&VbProtocol
                  );
  if (EFI_ERROR (Status)) {
    Print (L"VbRwStateApp: LocateProtocol(VerifiedBoot) failed: %r\n", Status);
    return Status;
  }
  Status = VbProtocol->VBRwDeviceState (
                         VbProtocol,
                         READ_CONFIG,
                         Buf,
                         BufLen
                         );
  if (EFI_ERROR (Status)) {
    Print (L"VbRwStateApp: VBRwDeviceState(READ_CONFIG) failed: %r\n", Status);
    return Status;
  }
  // Prepare 16-byte buffer: byte 0 = 1, byte 8 = 1, rest zero
  // SetMem (Buf, sizeof (Buf), 0);
  Buf[13] = 0;
  Buf[14] = 0;
  // Buf[15]=1;
  // Call VBRwDeviceState: op = WRITE_CONFIG (1)
  Status = VbProtocol->VBRwDeviceState (
                         VbProtocol,
                         WRITE_CONFIG,
                         Buf,
                         BufLen
                         );
  if (EFI_ERROR (Status)) {
    Print (L"VbRwStateApp: VBRwDeviceState(WRITE_CONFIG) failed: %r\n", Status);
    return Status;
  }

  Print (L"VbRwStateApp: VBRwDeviceState(WRITE_CONFIG) success.\n");
//   while(1);
  return EFI_SUCCESS;
}

数行代码干碎BL魂，报告长官我是小米人

KernelSU 建议的更新顺序：安装新版管理器 → 打开管理器 → 通过管理器安装内核更新 → 重启，完成更新。

在 KernelSU 已安装的情况下打开管理器时，会释放新版本的 ksud ，这样确保所有组件都是同一版本。（在这个提交后，如果老内核与新管理器不兼容，则不会立刻释放新版本 ksud ，只有在管理器中刷入更新才安装）

以下是没有按照这一顺序更新而产生的 bug 的实际案例：

某用户原先使用 KernelSU 1.0 ，在更新到 3.0 时，先刷入了其他方式 patch 的 boot ，启动之后才安装新版管理器，而管理器显示未工作，但是之前安装的模块可以正常工作。

这个 bug 通过一系列巧合触发：

1. 由于原本安装了旧版的 KernelSU ，因此 ksud 存在且为旧版。正常来说，ksud 会向内核汇报 post-fs-data 阶段，以便进入 ksu 的 on_post_fs_data ，执行注册 package observer （用于扫描管理器）和读取 root 授权列表等工作，然而旧版 KernelSU 使用 prctl 接口，新版则使用 ioctl 接口，因此这个过程未能执行。

2. 虽然 ksud 主动汇报 post-fs-data 失败了，但是 KernelSU 有一套用于初次启动（即无 ksud ）的备用方案，也就是检测首次 app_process 启动，这本应同样可以触发 on_post_fs_data 。

3. 然而由于该用户之前安装了 LSPosed ，并且旧版 ksud 是正常工作的，因此启动了 LSPosed 的 post-fs-data 脚本，其中启动了一个 app_process 。由于 KernelSU 假定无 ksud 情况下第一个 app_process 是 init 创建的，其 parent 应为 init ，因此向 parent task 添加 task work 以执行 on_post_fs_data 。但是由 LSPosed 创建的 app_process ，其 parent 是一个 sh 进程，通过 fork-execve 的方式执行这个 app_process 并退出，因此执行完成后可能处于已经退出还未被回收的状态，此时对这个 parent task 添加的 task work 实际上无法被执行。

4. 因此最终两种方式都没有执行到 on_post_fs_data ，导致内核无法识别管理器、也无法加载 root 权限列表，从而表现出无法获取 root 权限但是模块「正常」工作的现象。