开发工具【免费下载链接】HyperCeilerHyperOS enhancement module - Make HyperOS Great Again!项目地址https://gitcode.com/gh_mirrors/hy/HyperCeiler点击查看免费下载导读HyperCeiler 的统一 native hook 运行时位于 app/src/main/cpp/nativehook/其中一部分核心组件并非从零编写而是移植自开源项目 MiuiBackGestureHookApache License 2.0。本文以仓库内的 THIRD_PARTY_NOTICES.md 为骨架逐文件梳理这些派生代码的来源、移植差异、许可证义务与署名要求并结合源码与测试说明每一个移植点在实际代码中的落位。读完本文你将能准确回答三个问题哪些文件属于 Apache-2.0 派生、与上游相比改了什么、HyperCeiler 在 AGPL-3.0-or-later 主许可证下如何合规承载这些 Apache-2.0 代码。1. 背景nativehook 目录的两个来源合流在深入派生清单之前有必要先明确这组文件在项目中的定位。根据 NATIVE_HOOK_RUNTIME.md 的说明HyperCeiler 的 NativeHookRuntime 由两部分能力合流而成MiuiBackGestureHook HyperCeiler本仓库 成熟的 ELF / dynsym / PLT-GOT / 成熟的 mapping / snapshot / generation / ARM64 运行时解析能力 continuation 校验 / health / re-arm / Apache-2.0见 THIRD_PARTY_NOTICES.md Dart AOT hook 生命周期 \ / 统一 NativeHookRuntimeapp/src/main/cpp/nativehook/上游贡献MiuiBackGestureHook 提供了成熟的 ELF / dynsym / PLT-GOT / ARM64 运行时解析能力本仓库从中移植了六个文件层组件本仓库贡献HyperCeiler 自身的 mapping / snapshot / generation / continuation 校验 / health / re-arm / Dart AOT hook 生命周期构成了运行时另一半能力并决定了移植代码如何被调用、如何做健康维护。因此 THIRD_PARTY_NOTICES.md 记录的不是整个目录是第三方代码而是目录中哪些文件派生自 Apache-2.0 上游、派生到何种程度这正是开源合规中逐文件溯源的正确粒度。2. 上游项目与基准修订按文档记录本目录代码派生自 MiuiBackGestureHook 项目其子目录miui-home-hyos-native/遵循Apache License, Version 2.0。移植所参照的源码修订为aab59e2b78561271d56ea10952373bd28718596b仓库内的移植过程遵守了两个约束仅查阅miui-home-hyos-native/子目录本地只读 checkout仅用于分析且未对该仓库做任何修改。这意味着本项目对上游的利用方式是阅读源码 → 移植重写而不是拷贝文件 → 附带修改派生关系需要靠文件头声明与本文档逐条对应。3. Apache-2.0 派生代码清单原表完整保留文件派生来源Derivationelf_image.h移植自runtime_profile_resolver.cppParseElf、动态表解析与lsposed_hook_backend.cppBuildDynamicView、符号/重定位扫描。差异字节偏移解码无elf.h依赖、GNU/SYSV 哈希表查找上游仅派生符号数量、基于快照跨度解析而非实时内存读取。got_hook_backend.h移植自lsposed_hook_backend.cppWritePointer、CollectRelocationSlots、PltHookRaw、RELRO 处理、全成或全滚回。差异以ElfImage参数化取代硬编码的 launcher 模块身份健康模型与本项目 hook bank 语义对齐。page_guard.h移植自lsposed_hook_backend.cppAddProtectedPage、GuardedMadvise、guard 状态机。差异被 hook 的库原为 HyperOS Flutter 运行时改由调用方决定guard 是可选策略而非强制依赖。arm64_decode.hADRP/ADD 指令对、PLT-stub、条件分支解码派生自runtime_profile_resolver.cpp寄存器/加载存储/位段解码抽象自本项目自己的 Dart resolver。inline_hook_backend.hNativeAPIEntrieshookFunc/unhookFunc边界形状遵循上游native_api.hnull continuation 拒绝与回滚逻辑来自本项目的targets/home/dock_native_hooks.cpp。nhk_base.hAddOverflows/ 有界范围纪律遵循上游的溢出防护风格。注上表为 THIRD_PARTY_NOTICES.md 原文照录。所有文件均位于app/src/main/cpp/nativehook/目录下下文将逐一展开其移植细节。4. 逐文件移植差异详解这一节把上表差异Deltas展开落到实际源码理解派生与重写之间的边界。4.1 elf_image.h从读内存到读快照elf_image.h 是 ELF64 解析层负责 PT_LOAD / PT_DYNAMIC / dynsym / strtab / SYSVGNU hash / JMPREL / RELA 的解析与查询。相比上游的三处关键差异字节偏移解码无elf.h依赖文件头注释明确说明 Decoding is byte-offset based (noelf.hlayout assumptions)所有字段通过 nhk_base.h 提供的load_le16/load_le32/load_le64手工解码因此同一份代码既能在设备上运行也能在任何操作系统的主机测试中运行——这正是tests/run_host_native_tests.sh能在宿主机直接编译运行这些测试的前提。哈希表用于查找而非计数上游只从 GNU/SYSV 哈希表派生符号数量本仓库实现了find_by_gnu_hash()/find_by_sysv_hash()/find_by_linear_scan()三级查找见ElfImage::find_symbol并保持顺序GNU hash → SYSV hash → 有界线性回退。快照跨度解析解析只读调用方提供的 snapshot span绝不 dereference 可能被并发回收的内存映射调用方先快照元数据区域运行时再在快照上做语义匹配。这对应 NATIVE_HOOK_RUNTIME.md 中长时间扫描ELF 解析、语义匹配在快照上进行不持有 WMS 全局锁的并发约束。4.2 got_hook_backend.h从launcher 专用到ElfImage 参数化got_hook_backend.h 是 caller-specific PLT/GOT hook 后端移植自上游lsposed_hook_backend.cpp的WritePointer、CollectRelocationSlots、PltHookRaw与 RELRO 处理。核心语义被原样继承一个符号的槽位包括 JUMP_SLOT 与 GLOB_DAT 重定位多槽位仅在所有槽位仍指向同一 original 指针时才可接受任一槽位偏离即整个安装失败install_got_hooks中current ! expected即返回 falseRELRO 页按页临时加写、原子存储指针、随后恢复原保护位write_pointer_with_protection中的 mprotect 切换 __atomic_store_n的__ATOMIC_RELEASE存储安装是 all-or-nothing中途失败回滚已写槽位write_all_or_rollback健康模型全部槽位 replacement 为 healthy全部 已知 original 为 rearmable其他为 foreign第三方接管只上报不覆盖。最大差异是解耦上游把被 hook 的库身份硬编码进后端本仓库后端改为对调用方传入的elf::ElfImage工作never names a module itself文件头注释原句。被 hook 哪个库的madviseimport 由调用方决定例如桌面 Dart hook 的maybe_install_madvise_guard()针对libhyper_os_flutter.so——该决策在 feature 层不在 Core见 NATIVE_HOOK_RUNTIME.md §6。4.3 page_guard.h从强制依赖到可选策略page_guard.h 是页生命周期策略移植自上游AddProtectedPage/GuardedMadvise/ guard 状态机。模型用add_protected_page()注册的 hook 目标页能在任何人通过被 hook 的madviseimport 发起MADV_DONTNEED时存活——guard 会围绕受保护页把请求范围切开其余片段转发给真实madvise。两处关键差异被守护库由调用方决定上游把被 hook 的库硬编码为 HyperOS Flutter 运行时本仓库将其参数化an ordinary native library never issues MADV_DONTNEED against its own code and must not pay for this machinery——普通 native 库默认只用 generation/health/re-arm 机制不付出这套机制的开销。可选而非强制guard 不是所有 hook 的强制依赖InlineHookHost::protect_range在 inline 安装入口被调用、失败即拒绝该槽位add_protected_page()返回 bool页表上限kMaxProtectedPages 128满时必须明确报告拒绝绝不静默丢弃页面。4.4 arm64_decode.h上游形状 本项目解码器的合流arm64_decode.h 是通用 ARM64 指令解码层明确标注了双来源文件头注释来自上游runtime_profile_resolver.cppdecode_adrp4KB 页 PC 相对立即数、decode_add_immediateADRPADD 地址对低半、decode_ldr64_immediate、decode_plt_gotADRP x16, page; LDR x17, [x16, imm]; ADD x16, x16, imm; BR x17形状识别返回 GOT 槽位地址、decode_conditional_branch_target、call_targets_import来自本项目自己的 Dart resolver寄存器 / load-store / bitfield 解码器is_bl/is_b/is_ret、is_ldur_w/x/d、is_stur_w/x/d、is_add_imm_x、materialized_u32、ubfx、lsl_amount等此前内联在dock_native_resolver.h中被抽象进 Core。该层有一个明确的边界声明所有解码基于快照字snapshotted word span不读实时内存、不装 hook目标特定形状Dart prologue、压缩指针、launcher 指纹不属于这里留在 feature 层。4.5 inline_hook_backend.hNativeAPIEntries 边界 本项目的失败教训inline_hook_backend.h 是 LSPosed inline hook 后端边界。NativeApiEntrieshookFunc/unhookFunc两个入口的形状遵循上游native_api.h——LSPosed 在native_init时注入这两个入口这是 MiuiBackGestureHook 在上游native_api.h中正式化的同一契约。在此之上本仓库加入了两个双方项目都踩过坑的强化null continuation 拒绝后端报告成功但没有续跳指针时目标会经由我们不拥有的 out 参数分支跳转必须视为槽位被拒绝而非已安装——hook_bank.h强制执行install_slot中*slot.original nullptr时写回原 prologue 并拒绝trampoline 页回收竞争file-backed 镜像的 trampoline 页可能被内核回收再填充安装前用可选的 page guard 登记page_guard.h关闭 reclaim-vs-patch 竞争窗口。注意文件头的另一声明该层不依赖任何具体 inline hook 实现The engine behind the entry points is whatever LSPosed ships因此移植面只到 API 契约形状不涉及 LSPosed 内部。4.6 nhk_base.h溢出防护纪律的风格继承nhk_base.h 是共享基础原语溢出检查算术、有界范围检查、小端读取、页工具。其add_overflows()/in_image()/page_down()/page_up()遵循上游 resolver 风格的溢出防护纪律——an address arithmetic that could wrap is a hard failure, never a wrapped value。整层依赖为零inline 且 host-testable不与进程、文件系统或 hook 后端通信。这条纪律贯穿整个 CoreElfImage的contains()、file_offset_to_vaddr()、哈希链预算GNU 按表容量、SYSV 按nchain全部建立在add_overflows/in_image之上是损坏/截断 ELF 不得越界这一 fail-closed 规则的地基。5. 派生代码在运行时中的角色以 fail-closed 规则印证THIRD_PARTY_NOTICES.md 只记录许可证与来源但派生代码的实际行为约束在 NATIVE_HOOK_RUNTIME.md §4 中逐条与代码对应。以下几条最能体现上游解析能力 本项目生命周期纪律的合流效果多候选默认失败resolve()的candidate_count与unique_slot()elf_image.h落实0 候选失败1 候选继续验证多候选默认失败多候选必须结构化消歧evidence_acceptable()resolver.h要求candidate_count 1或 ≥2 时disambiguators非空——但诊断文本不算证明禁止取第一个像的GotHook安装要求所有 slot 指向同一 originalgot_hook_backend.h 中install_got_hooks的current ! expected即整体失败AArch64 重定位编号防错R_AARCH64_GLOB_DAT 1025 (0x401)、R_AARCH64_JUMP_SLOT 1026 (0x402)、R_AARCH64_RELATIVE 1027 (0x403)三者必须在 elf_image.h 中区分——JUMP_SLOT写成0x403会把所有 PLT 导入识别成 RELATIVE 而静默丢失且自洽的合成 fixture 完全看不出这个错误只有真实镜像能暴露详见 NATIVE_HOOK_RUNTIME.md §4.2。6. 许可证文本与署名要求Apache-2.0 §4按原文档Apache License 2.0 全文可查阅上游 MiuiBackGestureHook 仓库随附的LICENSE文件或 Apache 官网许可证页面。**署名义务Attribution requirement**是合规关键依据 Apache-2.0 §4移植文件在文件头携带声明 notice指明源项目与本文件的关系。本仓库中每个移植文件都以SPDX-License-Identifier: AGPL-3.0-or-later开头随后注释块明确写出移植来源如elf_image.h首行注释 Ported and generalized from MiuiBackGestureHooks runtime ELF resolution ... Apache-2.0, see THIRD_PARTY_NOTICES.md in this directorygot_hook_backend.h、page_guard.h、inline_hook_backend.h、nhk_base.h、arm64_decode.h均有对应声明可逐文件核对。双许可证并存的结构HyperCeiler 本身是AGPL-3.0-or-later但上述派生文件继续受 Apache-2.0 约束且保留 notice。这意味着这些文件在 AGPL 项目内承载 Apache-2.0 条款两者各自生效不能因主项目换证而抹掉 Apache 义务。类似的第三方处理也存在于其他位置例如 CMakeLists.txt 中 launcher tweaks 目录targets/home/tweaks/的文件同样标注为 Apache-2.0 并保留各自文件头各文件首行SPDX-License-Identifier: Apache-2.0且构建系统对其放宽了编译告警级别但不放宽正确性检查——这是仓库处理第三方代码的统一姿态。7. 如何验证主机测试与真实镜像端到端派生代码不是信则有的声明仓库用测试固定了它们的语义。运行方式摘自 NATIVE_HOOK_RUNTIME.md §9tests/run_host_native_tests.sh [libapp.so ...] # 直接跑 NHK_FLUTTER_LIB/path/libhyper_os_flutter.so tests/run_host_native_tests.sh ./gradlew :app:hostNativeTests # 或经 Gradle ./gradlew :app:hostNativeTests -PlibappSo/path/to/libapp.so对应测试覆盖可在 tests/nativehook/ 下逐一查看ELF 层NativeHookElfTest.cpp直接断言三个 AArch64 重定位编号常量kRelocJumpSlot 1026等、GNU/SYSV/线性三路查找一致、unique_slot唯一性门memcpy 两个槽位必须失败、RELATIVE 不算导入槽位、损坏/截断镜像拒绝、坏 GNU 表被禁用而非武装、SYSV 循环链必须终止、p_vaddr与p_offset不同的内存视图GOT 后端NativeHookGotTest.cpp原子替换 权限恢复、多槽位一致性门、healthy/rearmable/foreign 三态、write_all_or_rollback的全成或全滚回含失败槽位本身、不干净回滚必须产出GotHook{partialtrue}残留记录、ImageIdentity区分重映射与被接管页生命周期NativeHookPageGuardTest.cpp非 DONTNEED 透传、无保护时 DONTNEED 单次透传、受保护页被分段切出、幂等注册、未对齐请求原样转交内核、页表满必须拒绝。其中DockNativeArm64Test需要Linux aarch64eventfd 真实执行 AArch64 指令脚本按 OS 与架构双重判断后打印 SKIP 原因CI 的 x86_64 runner 同样跳过——这是文档明确标注的已知缺口不以CI 全绿代替见 tests/run_host_native_tests.sh 与 NATIVE_HOOK_RUNTIME.md §9。8. 合规自查清单面向维护者基于原文档与源码整理一份针对本目录的合规自查要点逐文件声明是否齐全六个派生文件elf_image.h、got_hook_backend.h、page_guard.h、arm64_decode.h、inline_hook_backend.h、nhk_base.h头部必须能对到 THIRD_PARTY_NOTICES.md 表格中的来源说明上游基准修订是否记录移植参照的aab59e2b78561271d56ea10952373bd28718596b应保留在本文档中便于未来审计比对许可证边界不得混淆这些文件保持 Apache-2.0 条款与 notice不得仅以项目主许可证 AGPL-3.0-or-later 覆盖新增移植文件应同步更新派生清单派生不等于拷贝本仓库对上游的利用方式是阅读后重写并泛化字节偏移解码、快照解析、ElfImage 参数化、可选策略化这些差异是实质性的技术工作也应在文档中如实描述既不夸大也不隐瞒测试即证据每次改动派生层语义应保持 tests/nativehook/ 下的主机测试通过其中真实镜像端到端用例NativeHookFlutterImageTest通过NHK_FLUTTER_LIB注入用于验证4 MiB 前缀不可用这类只有真实库能暴露的问题。9. 已知限制与阅读建议从 NATIVE_HOOK_RUNTIME.md §10 可知与本文主题相关的限制包括madvise 防护的真机行为尚未验收设备上确认挡住一次真实MADV_DONTNEED需要 arm64 设备观察日志madvise guard installed; N slot(s) protected页保护的镜像选择目前仅支持裸文件路径的运行时库映射在 APK 容器内的库需走容器归属但尚未接入该调用链。这些限制同样适用于对派生组件能力边界的判断——文档如实记录了未验证与未实现读者不应据此推断派生组件具备超出声明的能力。建议按此顺序阅读先读本文件第三方边界再读 NATIVE_HOOK_RUNTIME.md运行时职责与 fail-closed 规则最后对照六个头文件与 tests/nativehook/ 测试即可对哪些代码来自上游、如何被泛化、如何被验证形成完整闭环。赞分享开发工具【免费下载链接】HyperCeilerHyperOS enhancement module - Make HyperOS Great Again!项目地址https://gitcode.com/gh_mirrors/hy/HyperCeiler点击查看免费下载相关推荐PlotJuggler pj_scene3D 第三方派生 GLSL 溯源与许可证合规指南PlotJuggler pj_scene3D 第三方派生 GLSL 溯源与许可证合规指南 本篇指南以 PlotJuggler 仓库中 pj_scene3D/TH数据可视化桌面应用数据分析Apache Airflow 的 Apache-2.0 许可证全解析许可文本、授权条款与第三方组件合规清单Apache Airflow 的 Apache 2.0 许可证全解析许可文本、授权条款与第三方组件合规清单 本文以 Apache Airflow 官方文档中的后端任务调度工作流自动化数据编排批处理数据工程流程编排GitBucket 第三方依赖许可证清单全解读doc/licenses.md 的组成、生成机制与合规要点GitBucket 第三方依赖许可证清单全解读doc/licenses.md 的组成、生成机制与合规要点 GitBucket 是一款基于 Scala 构建的后端代码托管开发工具DevOps上一篇EcoPaste 项目中的 Trellis 本地架构与自定义指南深入解析 trellis-meta 技能下一篇免费解锁Microsoft 365完整功能Ohook开源激活方案完全指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考