原贴 此地仅作为存档
https://tieba.baidu.com/p/9378338548

大家新年快乐！！#(太开心)新的一年从榜单开始吧！因为是昨晚熬夜查的，如果有错漏请大家多多包涵#(阴险)，帮忙指正一下谢谢~
以下是注意事项：
1.计算投稿在1/1/2024 0:00 - 31/12/2024 23:59期间的作品。
2.投稿包括R18，R18率是全时间的。
3.这个排名的目的是向大家推荐各种令人喜爱的角色，希望大家都能抱着好奇的心情去了解不熟悉的角色和作品，说不定会有意外的惊喜哦~
4.所用图片下方都标明了id和画师，如果有喜欢的请去Pixiv关注吧~
5.本排行完全是个人统计，不保证数据准确性，排名也不代表角色或者作品人气，请勿用于黑吹婊，如需转载，请注明出处。
6.绿色部分为人工部分，不含AI作品。浅红色部分为AI作品数据。

Nginx使用OQS提供的椭圆曲线

在网上和GPT找不到教程干脆写一个存档

前提：需要openssl版本大于3.0

编译 oqs-provider

git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider
cmake -S . -B _build && cmake --build _build && cmake --install _build

配置openssl文件 vim /etc/ssl/openssl.cnf

[openssl_init]
providers = provider_sect

[provider_sect] #加载OQS
default = default_sect                                                     oqsprovider = oqsprovider_sect

[default_sect]
activate = 1
[oqsprovider_sect] #启用OQS
activate = 1

验证是否生效

openssl list -signature-algorithms -provider oqsprovider

在Nginx随便一个站点添加配置

ssl_ecdh_curve X25519MLKEM768:SecP256r1MLKEM768:x25519_kyber768:p384_kyber768:x25519:secp384r1:x448:secp256r1:secp521r1;

使用openssl链接网站验证曲线配置是否生效

openssl s_client -connect yourdomain.com:443 -curves X25519

前天 alist 直接被端，真的无话可说。GitHub 这种大型开源的社区，这种绝对是自动化封杀的，为了那 Tos 宁可先杀，先不管有没有错，最后遭殃的是焦虑的客户等待工单还有一天面对几万工单的客服。
根据 GitHub 透明度报告 在2024年至少有30K的账号和30K的项目被端，恢复完整访问权限的寥寥无几。what can I say。

Android 15+ 部分设备在某些路由器下遇到 IPv6 路由获取不正常

具体表现
设备上 WiFi 设置里能看到 IPv6 地址，但实际上测试（如 test-ipv6.com、mtr 工具）不通。

根本原因
Android 15 新增了对IPv6路由通告(RA)的要求，在Android 15 的源码 IpClient.java [1]，引入了一个新参数：CONFIG_ACCEPT_RA_MIN_LFT（最小可接受前缀/路由终生期），默认值设为180秒，即接收到的路由RA生存时间，必须大于等于180秒才被接受。这意味着，如果路由器发送给客户端的 IPv6 RA（路由通告）报文的「Router Lifetime」字段小于180秒，中会直接丢弃该RA信息。

部分路由器，如小米、TP-Link部分型号会自行修改RA报文的参数，把 Router Lifetime、prefix lifetime 设置非常短。列如在小米的AX6000的路由生存通告时间设置为60S。

部分运营商移动网络的路由也存在生存通告时间过低的问题。

结论
Android 15+ 新增了更严格的 IPv6 路由通告生存时间下限，要求RA中Router Lifetime至少为180秒。部分家用路由器参数配置太低、固件实现不规范，导致RA报文被新的Android系统丢弃，进而无法正常获取IPv6路由信息、实际无法访问IPv6互联网。考虑到国内路由器固件更新周期，可能换一个路由器是终极解决办法。

致谢
感谢lurenjia、ξ | Ver 1 、風華流沙提供的信息。

引用
[1]:https://cs.android.com/android/platform/superproject/+/android15-release:packages/modules/NetworkStack/src/android/net/ip/IpClient.java

本来不想发的，但是绷不住了，这也太变态了。获取系统信息偷偷上传，这代码一眼AI写的，太sh*t了。吓得我赶紧把服务器的 alist 清理了，现在有没有替代品都不知道。

Update：已经确认该公司劣迹斑斑，无法保证后续二进制可执行文件安全，建议跑路。

https://github.com/AlistGo/alist/issues/8649#issuecomment-2961048289

https://github.com/AlistGo/alist/pull/8633

https://www.v2ex.com/t/994143
https://www.v2ex.com/t/1138125

如何使用 Windbg 排除程序错误

今天从另一台电脑打开某大型动作软件，需要 InitSettingCN 才能运行，但是一启动就闪退了，服了，无奈之下打开 Windbg 进行调试。
以调试模式启动程序，选择 Start debugging → Launch executable 选择需要调试的文件。
这里是因为启动就崩溃，所以说直接点击 Go 让其执行下去即可，并观察输出。

(4bf0.2da8): CLR exception - code e0434f4d (first chance)
(4bf0.2da8): CLR exception - code e0434f4d (first chance)
(4bf0.2da8): CLR exception - code e0434f4d (!!! second chance !!!)
    "“System.Windows.Media.FontFamily”的类型初始值设定项引发异常。"
KERNELBASE!RaiseException+0x69:
00007ff8`5abe5339 0f1f440000      nop     dword ptr [rax+rax]

因为有CLR异常处理，其中 First chance 异常，表示程序可能会捕获并处理，不会导致崩溃。Second chance 异常表示连续二次一样异常，程序无法处理该异常，将导致程序终止。
其中异常信息为 System.Windows.Media.FontFamily类型初始化失败 ，从名称看应该是WPF相关字体系统问题。
输入 !analyze -v 查看异常详细信息。（下述我简化了部分信息，列如调用堆栈的具体地址）

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ff85abe5339 (KERNELBASE!RaiseException+0x0000000000000069)
   ExceptionCode: e0434f4d (CLR exception)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: ffffffff80131534
    "“System.Windows.Media.FontFamily”的类型初始值设定项引发异常。"
FAULTING_THREAD:  2da8
PROCESS_NAME:  InitSettingCN.exe
EXCEPTION_CODE_STR:  ea
STACK_TEXT:  
mscorlib_ni!Microsoft.Win32.RegistryKey.Win32Error+0x3dfac7
mscorlib_ni!Microsoft.Win32.RegistryKey.GetValueNames+0xa5558f
PresentationCore_ni!MS.Internal.FontCache.FontSourceCollection.SetFontSources+0x1ec
PresentationCore_ni!MS.Internal.FontCache.FontSourceCollection.GetEnumerator+0x11
PresentationCore_ni!MS.Internal.FontCache.FamilyCollection.BuildFamilyList+0x6b
PresentationCore_ni!MS.Internal.FontCache.FamilyCollection.MS.Internal.FontCache.IFontCacheElement.AddToCache+0x103
PresentationCore_ni!MS.Internal.FontCache.HashTable.Lookup+0x122
PresentationCore_ni!MS.Internal.FontCache.CacheManager.Lookup+0x86
PresentationCore_ni!System.Windows.Media.FontFamily..cctor+0xbf

从通过微软文档 System Error Codes查询可知，异常代码 EXCEPTION_CODE_STR 0xea (234) = ERROR_MORE_DATA 表示表示缓冲区太小无法容纳数据，需要更大缓冲区。从调用堆栈看出 Microsoft.Win32.RegistryKey.GetValueNames 调用失败导致的异常。综合来看是因为WPF相关字体系统尝试从注册表获取字体列表时发生了缓冲区过小，接下来去找的对于操作的注册表路径就行了。
因为CLR异常处理导致寄存器/堆栈信息已经覆盖坏并且未保留相关异常信息，我们无法知道具体获取是操作了那个注册表，但是我们可以通过 Process Monitor 对注册表进行监控。
打开 Process Monitor 后找到菜单 Filter → Filter 后会弹出一个 Process Monito Filter 页面，你需要设置为 Process Name Is InitSettingCN.exe 然后点击应用后再点击确定保存。
重新调试程序到崩溃处观察 Process Monito ，可以看到最后有个很明显的 BUFFER OVERFLOW 的执行结果，具体如下。

Date:  2025/7/11 15:33:26.9002847
Thread:  18128
Class:  Registry
Operation:  RegEnumValue
Result:  BUFFER OVERFLOW
Path:  HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts
Duration:  0.0000078
Index:  537
Length:  512

很明显可以看见，发生在从注册表获取字体列表中，其中缓冲区长度为521，但是需要的长度为537，最终导致了崩溃。
这时检查注册表发现果然有个字体命名长度已经超过其缓冲区长度，真逆天。
总结：TM的沟槽微软和逆天字体，我*你*。

Android 15+ 部分设备在某些路由器下遇到 IPv6 路由获取不正常

具体表现
设备上 WiFi 设置里能看到 IPv6 地址，但实际上测试（如 test-ipv6.com、mtr 工具）不通。

根本原因
Android 15 新增了对IPv6路由通告(RA)的要求，在Android 15 的源码 IpClient.java [1]，引入了一个新参数：DEFAULT_ACCEPT_RA_MIN_LFT（最小可接受前缀/路由终生期），默认值设为180秒，即接收到的路由RA生存时间，必须大于等于180秒才被接受。这意味着，如果路由器发送给客户端的 IPv6 RA（路由通告）报文的「Router Lifetime」字段小于180秒，中会直接丢弃该RA信息。

部分路由器，如小米、TP-Link部分型号会自行修改RA报文的参数，把 Router Lifetime、prefix lifetime 设置非常短。列如在小米的AX6000的路由生存通告时间设置为60S。

部分运营商移动网络的路由也存在生存通告时间过低的问题。

结论
Android 15+ 新增了更严格的 IPv6 路由通告生存时间下限，要求RA中Router Lifetime至少为180秒。部分家用路由器参数配置太低、固件实现不规范，导致RA报文被新的Android系统丢弃，进而无法正常获取IPv6路由信息、实际无法访问IPv6互联网。考虑到国内路由器固件更新周期，可能换一个路由器是终极解决办法。

致谢
感谢lurenjia、ξ | Ver 1 、風華流沙提供的信息。

引用
[1]:https://cs.android.com/android/platform/superproject/+/android15-release:packages/modules/NetworkStack/src/android/net/ip/IpClient.java

解锁/固化SSH小米路由器脚本

https://github.com/openwrt-xiaomi/xmir-patcher

连接 SSH 修改小米路由 RA Lifetine 修复 Android15 ipv6 网络不可达的问题

编辑文件 vim /etc/config/dhcp
找到 config dhcp 'lan' 添加 option ra_lifetime '1800'

感谢某位不愿意透露姓名的三月七群友提供的脚本
PS：这个脚本怎么把整个 Python 打包进仓库了 离谱

下面是一个使用EPT技术实现对抗反调试的项目，其中著名的反作弊程序TX驱动也使用了这个技术。
EPT 全称叫 Extended Page Tables，是 Intel 平台上的虚拟化页表技术。其中 AMD 对应的是 NPT ，全称叫 Nested Page Table。
工作原理：

传统内存访问：
虚拟地址 → 物理地址
虚拟化环境（内存访问隔离）：
客户机虚拟地址 → 客户机物理地址(GPA) → 宿主机物理地址(HPA)

其中EPT主要负责客户机物理地址和宿主机物理地址之间转换。
这样一个特性，就很轻松实现。

通过 EPT/NPT 修改特定内存页的权限（如设为不可执行）
当目标代码执行时触发 VM-Exit
Hypervisor 捕获并处理

并且隐蔽性极强，在 Ring 0 系统操作层无法查看其修改内容，具体来说无法通过读取 EPT 表去查看那些内存页设置的权限，更没办法查看宿主机物理地址，因为 Hypervisor 运行在 Ring -1 (Hypervisor/VMM) 层，和 Ring 0 是单向透明关系，CPU硬件强制隔离，很难进行检测，除非 Hypervisor 有漏洞。
在 EPT Hook 的应用：
通过 EPT 修改特定函数所在内存页的权限 (可读写，不可执行)，当CPU执行到该函数所在的页面时，因为标记为不可执行触发 VM-Exit，在 Hypervisor 层拦截并处理，切换到 Hook 页面 (可执行)。
这个对于现在 Windows 操作系统存在 PatchGuard ，无法直接进行 SSTD Hook 和 Inline Hook 是非常好的办法。
https://github.com/Air14/HyperHide

今天突然好奇，用 Rust 编写 Windows 驱动咋样，看到例子[1]，实在有点炸裂。
在例子中，基本使用的是原始绑定层（raw bindings），直接暴露 C API，相当于在写 C 代码，只是用 Rust 语法。导致所有 WDF API 调用都需要 unsafe。一个简单的 Print 需要大量样板代码。写的时候你会发现非常难受。而且还抵消了 Rust 的内存安全优势。
相比隔壁 Linux 的 Rust 驱动支持更成熟，虽然说框架使用的是中间层作为安全抽象，依然逃不过因为 FFI 边界调用需要 unsafe ，但开发者实际用起来舒服很多。

// 驱动开发者使用的 API
kernel::pr_info!("Driver loaded\n");

相比之下 Windows 的 Rust 驱动支持，复杂度激增。

// 需要把字串符转换为 CString
let string = CString::new("Driver loaded\n").unwrap();
// 转换为字符串的原始指针传递给 DbgPrint
unsafe {
    DbgPrint(c"%s".as_ptr().cast(), string.as_ptr());
}

当然，官方也是承认了这些问题[2]，说处于非常早期阶段，但是我看了一眼提交历史，似乎2年前就开始部署了，嗯……不好评价。
[1]:https://github.com/microsoft/windows-drivers-rs/blob/main/examples/sample-kmdf-driver/src/lib.rs
[2]:https://techcommunity.microsoft.com/blog/windowsdriverdev/towards-rust-in-windows-drivers/4449718