kuanat

@swordsmile #2

我看了一下，hyprland 支持创建 headless 的。

https://wiki.hyprland.org/Configuring/Using-hyprctl/#output

但我不确定 hyprland 启动的时候是不是能 headless ，不过看 hyprctl instances 似乎是可以这么用的，你可以试一下。

实在有需要可以考虑 sway 啊，我用这个方案已经很久了，也不用欺骗头。

我用 sway 的方式是

WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1 sway

然后

swaymsg create_output

最后

wayvnc --output=HEADLESS-1

你可以试试看能不能把类似方法用在 hyprland 上面。

不只是 GPD ，所有依赖差异化竞争的电子、硬件厂，受出货量限制研发成本难以均摊，即便设计层面不翻车，品控方面能过关的都很罕见。

就这个设计来说，我觉得以 GPD 现在的能力，屏轴、排线会是品控灾难。我能理解做 13 寸的技术理由，但我不理解做这个产品的商业决策。

你的疑问是对的。一旦离开 UEFI/grub 之后，之前 ventoy 虚拟出来的光驱设备就不存在了。

然后魔改 grub2 也是对的，只是如果你去看修改的代码 https://github.com/ventoy/Ventoy/tree/master/GRUB2/MOD_SRC/grub-2.04 会发现这些改动都是表面的，跟启动机制没有关系。

所以 ventoy 并不是用 grub2 loopback 加载 iso 完成引导的。

“除非系统内有对应的驱动程序去专门去访问这段内存及模拟驱动器”这句话不完全对，Win/Linux 内核都有 loopback 加载机制，也就是你说的“驱动”。真正的问题，去哪里加载。这里需要的是逻辑意义上的地址，不管它背后是内存还是硬盘文件。

如果你大致浏览一下 ventoy 的代码，肯定会注意到 vtoyjump 这个与众不同的名字，其他目录要么是一些基础功能，要么是 ventoy 的功能。另外 ventoy 是可以输出 log 的，你会在日志中看到 vtoyjump 相关功能的调用。

以下是我根据之前的印象总结的，我估计原理应该没问题，细节可能有出入。

如果是引导 Linux ，会首先引导 ventoy.cpio ，完成虚拟光驱初始化之后再链式引导 initrd 。

如果是引导 Windows ，会用 vtoyjump 替代 Windows 的引导文件（大概名字是 winpeXXX 的一个文件），然后原版在内存中保留一份副本。(这个“替代”是 overlay 的意思，并非修改原始文件，相关的 injection 功能也被 ventoy 做成了插件）此时还处于 grub 阶段，以你描述的 loopback 方式引导 boot.wim ，完成内核初始化。此时 grub 阶段虚拟的光驱设备就访问不到了。

原本下一步是引导 winpe 进入安装程序，这时被 vtoyjump 替代，vtoyjump 利用 NT 内核 API 加载原始 iso 成为 loopback 设备。 之后 vtoyjump 再引导 winpe 那个程序，就进入正常安装过程了。

你这个组合我没有用过，估计需要排查一下是谁崩了。从描述来看 wayvnc 晚于 hyprland ，是不是与 swaylock-effects 有关不清楚，看一下各自的 log 吧。

不启动 hyprland 这个应该做不到，就像 x11 一定要有 x server 一样。我估计你说的应该是 headless 模式？ wayvnc 应该支持，hyprland 不清楚。如果 hyprland 不支持 headless 模式的话，可以用一个 hdmi 欺骗头让 hyprland 输出到这个 hdmi 上。

这个话题搜 ssl pinning 会有很多信息。

如果抓包的时候 App 看不到相关数据了，这种一般只是简单拒绝走代理，或者拒绝了中间人证书，导致连不上了。如果 App 看到的数据正常，说明有 fallback 机制，多数都是非平台默认的 ssl 实现。

不管哪种方式，常规应对策略基本上是 frida hook 掉类似证书加载、证书验证和代理之类的调用。有比较通用的脚本，支持常见的 ssl 库。

但这样做的前提是应用本身没有混淆，调用的方法名没变过，或者有能力推断出混淆过的名字和地址。混淆一般是通过加壳完成的，除了少数基于 vmp 的方案，大多数都有比较通用的应对思路。

脱壳之后一般还会需要绕过 root/签名检测，拦截客户端异常汇报等等，比起脱壳来说要简单。


非常规的应对策略是类似 eCapture 这种非入侵式的方案，可以绕开证书校验。配合虚拟机效果会更好。

取决于用途和场景，大致有几个思路，你可以按照关键词去搜对应的做法。

如果以安装的包来划分，整个显示框架大概有：Framebuffer 层（ DRM/KMS ），Display Server 层（ X.org/Wayland ），窗口管理器，桌面附加组件四层。FB 层肯定都有也不需要关心，Display Server 层必须要有一个，根据你的应用来选。按照你的描述，桌面（ KDE/Gnome ）这些都可以不要，窗口管理器可以有也可以没有。

这里以 X11 作为显示后端为例：

在某个 tty 启动 X session 。用到的命令就是 `startx`，后面可以直接跟你的 x11 应用，也可以跟 `xterm` 之类的 vte 终端，之后可以在终端里面按需启动 x11 应用。

这里对于 tty 的分配，以及对应到显示器需要你手动配置。如果你是 ssh 连接到远程服务器，需要 ssh x11 tunneling 。

如果需要窗口管理器，可以 `startx` 先启动窗口管理器，然后再启动对应的应用。

榜单如果只有 10~20 个这样，更新频率不高的话，建议人工。

程序只负责筛选出一定量的备选。