Lexe如何将JS代码嵌入可执行文件魔数与ELF自定义段技术内幕全解析【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexe你是否想过Lexe 是如何把 JS 代码直接嵌入到可执行文件中让整个 Node.js 应用变成一个仅 8~10MB 的单文件二进制本文将从魔数Magic Number和ELF 自定义段两个核心技术点出发带你看懂 Lexe 打包 JS 应用为独立可执行文件的完整原理。 为什么 Lexe 的打包结果只有 10MB传统打包工具pkg、deno、bun 等生成的单文件可执行文件动辄 40~60MB而 Lexe 基于 LLRT 运行时采用运行时 压缩字节码 自定义段嵌入的方案将 Hello World 应用的打包体积压到了8.31MB秘密在于三个环节字节码化 → zstd 字典压缩 → 嵌入自定义二进制段。下面逐个拆解。 构建流水线JS 源码如何变成一段字节当你在终端执行llrt build -ihello.js时构建流程实现在 llrt/src/build.rs 对应的run_build方法中会依次完成以下工作读取并编译 JS 源码调用 QuickJS 引擎把 JS 直接编译为字节码而非保留明文源码入口在llrt_core/src/compiler.rs的compile_string函数zstd 字典压缩字节码用 zstd 以 22 级压缩率压缩且使用预训练压缩字典prebuild/compression.dict进一步缩小体积添加字节码头压缩后的数据前会加上版本头lrt01再加一个标志字节c压缩或u未压缩和解压后长度见llrt_core/src/bytecode.rs中的add_bytecode_header函数注入宿主二进制把这段带头的压缩字节码写进目标平台的 LLRT 运行时可执行文件中下文详述。 魔数可执行文件如何自证身份打包后的二进制里藏着一个关键问题运行时怎么知道自己不是普通程序而是一个内嵌了 JS 代码的打包产物答案是魔数。Lexe 在不同平台上用了两套魔数策略定义于llrt/src/build.rs顶部的三个常量魔数形态适用平台说明1exe6und1e10 字节字符串Windows / macOS构建时直接追加在文件末尾运行时从文件尾部 1KB 内反向搜索0x501e4 字节二进制Linux由 libsui 库自动追加在末尾构成 16 字节尾部魔数(4) 哈希(4) 大小(8)为什么 Linux 不用字符串魔数因为 Linux 下字节码走的是 ELF 自定义段libsui 已按自己的格式写入尾部元数据若再追加字符串魔数反而会干扰段定位——源码注释里特别说明了这一点。运行时启动时has_magic_number函数会打开自己当前可执行文件检查尾部魔数检测到魔数→ 说明内嵌了字节码进入执行嵌入代码分支未检测到→ 普通模式进入交互式 REPL。这个自检查逻辑位于llrt/src/main.rs的start_cli中是单文件可执行文件得以自包含的关键。 自定义段代码到底藏在哪真正存放 JS 字节码的位置是二进制文件里的自定义段段名为1exec0de一个把易读字符写成数字的伪装名字便于二进制搜索定位。三大平台的段写入方式各不相同LinuxElf::new(llrt_binary).append(SECTION_NAME, compiled, ...)—— 向 ELF 文件追加一个自定义 sectionWindowsPortableExecutable::from(...).write_resource(...)—— 写入 PE 资源段之后手动补写字符串魔数macOSMacho::from(...).write_section(...).build_and_sign(...)—— 写入 MachO 段并完成代码签名。这就是ELF 自定义段的精髓操作系统只认标准段完全忽略1exec0de这个陌生段不会加载执行它而 Lexe 运行时的extract_code_binary函数借助 libsui 的find_section按段名精确定位把压缩字节码原样读出来。⚡ 运行时还原从字节到执行的最后一公里魔数命中后执行链路只有三步llrt/src/main.rsextract_code_binary()按段名1exec0de取出字节码CustomLoader::load_bytecode_module按字节码头lrt01c判断压缩状态用同一份 zstd 字典解压还原module.eval()在 QuickJS 上下文中求值运行——你的 JS 应用就这样跑了起来。 小结技术点作用关键位置QuickJS 字节码源码不落盘体积与可读性双降llrt_core/src/compiler.rszstd 字典压缩进一步压缩字节码prebuild/compression.dict魔数1exe6und1e/0x501e文件尾部自识别区分打包态与 REPL 态llrt/src/build.rs自定义段1exec0de字节码在 ELF/MachO/PE 中的隐藏容器llrt/src/build.rs尾部 16 字节 trailerlibsui 的魔数哈希大小元数据llrt/src/build.rsLexe 用字节码 字典压缩 自定义段 尾部魔数这套组合拳实现了 JS 代码到单文件可执行文件的无损嵌入。想动手验证克隆仓库后构建 LLRT执行llrt build -ifixtures/hello.js再用readelf -S观察产物中的1exec0de段即可亲眼看到这段藏起来的代码。【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Lexe如何将JS代码嵌入可执行文件？魔数与ELF自定义段技术内幕全解析
Lexe如何将JS代码嵌入可执行文件魔数与ELF自定义段技术内幕全解析【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexe你是否想过Lexe 是如何把 JS 代码直接嵌入到可执行文件中让整个 Node.js 应用变成一个仅 8~10MB 的单文件二进制本文将从魔数Magic Number和ELF 自定义段两个核心技术点出发带你看懂 Lexe 打包 JS 应用为独立可执行文件的完整原理。 为什么 Lexe 的打包结果只有 10MB传统打包工具pkg、deno、bun 等生成的单文件可执行文件动辄 40~60MB而 Lexe 基于 LLRT 运行时采用运行时 压缩字节码 自定义段嵌入的方案将 Hello World 应用的打包体积压到了8.31MB秘密在于三个环节字节码化 → zstd 字典压缩 → 嵌入自定义二进制段。下面逐个拆解。 构建流水线JS 源码如何变成一段字节当你在终端执行llrt build -ihello.js时构建流程实现在 llrt/src/build.rs 对应的run_build方法中会依次完成以下工作读取并编译 JS 源码调用 QuickJS 引擎把 JS 直接编译为字节码而非保留明文源码入口在llrt_core/src/compiler.rs的compile_string函数zstd 字典压缩字节码用 zstd 以 22 级压缩率压缩且使用预训练压缩字典prebuild/compression.dict进一步缩小体积添加字节码头压缩后的数据前会加上版本头lrt01再加一个标志字节c压缩或u未压缩和解压后长度见llrt_core/src/bytecode.rs中的add_bytecode_header函数注入宿主二进制把这段带头的压缩字节码写进目标平台的 LLRT 运行时可执行文件中下文详述。 魔数可执行文件如何自证身份打包后的二进制里藏着一个关键问题运行时怎么知道自己不是普通程序而是一个内嵌了 JS 代码的打包产物答案是魔数。Lexe 在不同平台上用了两套魔数策略定义于llrt/src/build.rs顶部的三个常量魔数形态适用平台说明1exe6und1e10 字节字符串Windows / macOS构建时直接追加在文件末尾运行时从文件尾部 1KB 内反向搜索0x501e4 字节二进制Linux由 libsui 库自动追加在末尾构成 16 字节尾部魔数(4) 哈希(4) 大小(8)为什么 Linux 不用字符串魔数因为 Linux 下字节码走的是 ELF 自定义段libsui 已按自己的格式写入尾部元数据若再追加字符串魔数反而会干扰段定位——源码注释里特别说明了这一点。运行时启动时has_magic_number函数会打开自己当前可执行文件检查尾部魔数检测到魔数→ 说明内嵌了字节码进入执行嵌入代码分支未检测到→ 普通模式进入交互式 REPL。这个自检查逻辑位于llrt/src/main.rs的start_cli中是单文件可执行文件得以自包含的关键。 自定义段代码到底藏在哪真正存放 JS 字节码的位置是二进制文件里的自定义段段名为1exec0de一个把易读字符写成数字的伪装名字便于二进制搜索定位。三大平台的段写入方式各不相同LinuxElf::new(llrt_binary).append(SECTION_NAME, compiled, ...)—— 向 ELF 文件追加一个自定义 sectionWindowsPortableExecutable::from(...).write_resource(...)—— 写入 PE 资源段之后手动补写字符串魔数macOSMacho::from(...).write_section(...).build_and_sign(...)—— 写入 MachO 段并完成代码签名。这就是ELF 自定义段的精髓操作系统只认标准段完全忽略1exec0de这个陌生段不会加载执行它而 Lexe 运行时的extract_code_binary函数借助 libsui 的find_section按段名精确定位把压缩字节码原样读出来。⚡ 运行时还原从字节到执行的最后一公里魔数命中后执行链路只有三步llrt/src/main.rsextract_code_binary()按段名1exec0de取出字节码CustomLoader::load_bytecode_module按字节码头lrt01c判断压缩状态用同一份 zstd 字典解压还原module.eval()在 QuickJS 上下文中求值运行——你的 JS 应用就这样跑了起来。 小结技术点作用关键位置QuickJS 字节码源码不落盘体积与可读性双降llrt_core/src/compiler.rszstd 字典压缩进一步压缩字节码prebuild/compression.dict魔数1exe6und1e/0x501e文件尾部自识别区分打包态与 REPL 态llrt/src/build.rs自定义段1exec0de字节码在 ELF/MachO/PE 中的隐藏容器llrt/src/build.rs尾部 16 字节 trailerlibsui 的魔数哈希大小元数据llrt/src/build.rsLexe 用字节码 字典压缩 自定义段 尾部魔数这套组合拳实现了 JS 代码到单文件可执行文件的无损嵌入。想动手验证克隆仓库后构建 LLRT执行llrt build -ifixtures/hello.js再用readelf -S观察产物中的1exec0de段即可亲眼看到这段藏起来的代码。【免费下载链接】lexePackage your Node.js application into a single executable file, but only 10MB.项目地址: https://gitcode.com/gh_mirrors/le/lexe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考