防破解确实是个成本收益的问题，但是你如果认为 hook 就能拦住 99% 那就太理想化了。由于逆向工具的进步，学习 hook 的门槛非常低。你有正向开发的能力，半个小时学习一下 frida 甚至脚本都不用自己写，就能绕过绝大部分不设防的应用。

从知己知彼的角度上说，还是要了解逆向是怎么做的。精力放在抵御那些高度自动化的逆向方案上。

静态方面，一般防御手段是混淆和加壳。混淆可以某种程度上避免反编译后你自己的程序逻辑被分析，但是涉及到的系统 api 调用是不好藏的，所以聊胜于无。加壳对于大部分开发者来说门槛过高，选择加壳的时候，顺便搜一下对应的脱壳工具，大致上可以防技术不过硬的选手了。

动态方面，核心思路是将关键代码 native 化。同时 native 接口要采用互操作的形式，否则很容易被当作黑盒来直接调用。通常 hook native 只有在 onEnter/onLeave 环节能做一些记录入参，修改返回值的操作，所以拆解 native 逻辑避开这种利用方式也能防住很大一部分。

另外就是所有你认为的“检测”结果都不可信，这个事情哲学上就是你不可能判断自己是不是生活在虚拟世界是一个意思。相关的检测还是可以做的，但这种检测必然依赖 api 和特征，在 hook 环境中都可能是假象。检测到了随机插入假结果给逆向的人带来迷惑，远比粗暴禁用等手段有意义。这也是多数大厂的做法，用风控替代对抗。

抓包层面，大部分人都说了，除非你像 fb 一样自己实现 tls 库，不然都有自动化的解决方案。另外 ecapture 还是 hook 方案，知道的人少，被检测的几率小。如果项目合适，可以考虑用 protobuf 之类替代 http 。

我不确定你说的是具体哪个型号，如果没猜错的话，应该是纯平的 34WK95U 。微星有一款用了同样面板的 PS341WU 。其他的带鱼屏都是曲面。这两款我都有，LG/MSI 这两款的区别是 LG 内置一个 tb3 hub ，微星那款没有，所以微星稍微便宜一点。微星那边可以支持 PBP 拆四个 1920x1080 ，LG 只能拆两个。做工支架方面微星略好于 LG 。

以剪视频的需求来说，垂直分辨率在 2160 是有质变的。原因是只有超过 2160 才能在一个屏幕上 100%
缩放显示视频以及软件的 ui 界面。

以写代码的需求来说，3840->5120 也是有质变的。一般来说，目前的 4k 多数时间要配合缩放使用，所以写代码常见的左右分屏场景，1920 再缩放一下，实际上水平宽度经常不够用。

如果是带鱼替代双屏，体验会很好。物理方面视觉中心是一块屏幕，没有边框分割也没有色差，还更省空间。软件方面不涉及多屏易用性也好很多。如果是三屏的话，带鱼屏的优势反倒不明显了。

楼主的问题可以参考 https://github.com/linux-surface/linux-surface 里面有 surface 各硬件的内核驱动支持，SGO2 算是比较完善的，选一个方便切换内核的发行版就可以了。考虑到硬件平台比较久远了，桌面平台使用 xfce 这种轻量型体验会比较好，硬核一点可以 i3/sway 来自定义。

因为你这个做法很不常见，我猜测可能是 XY 问题导致的偏差，所以特地去看了你的使用场景。

这里我引用一下"为什么要搞 IP 保护"的描述："暴露的端口会被探测"，看到这里我就理解你的需求了。

本质上你是在保护自己的 IP 资产，而不是客户，客户只是租用而已。因为你以虚拟机的形式为客户交付服务，并不能控制客户在虚拟机上的行为，比如客户可以在在这个公网 IP 上开放公开的 http/socks 服务等等。

怎么向客户描述这个问题不重要，但是你的思路被带偏了，甚至说你的整体产品架构思路都被带偏了。当然这只是我个人的想法，可能理解有偏差。

如果我来设计的话，向客户交付的部分其实是 B ，而 A 是由自己完全控制的，A 是 B 的路由器。技术层面，B 本身就是云服务，利用 VPC 保证 B 的所有出站流量都一定由 A 路由就可以了。

这样做的附加好处是，所有 A 节点都可以用低成本标准化的网络设备完成，无需托管真实主机，至于 B 完全可以利用云服务来提供定制。

直接说结论：

如果 A 的防火墙是类似于 `iptables -t nat -A PREROUTING -s 2.2.2.2 -j ACCEPT` 的形式，那就无法通过 NAT 的形式做端口映射。

做全端口映射的原理就是楼上说的 DMZ ，转换成 iptables 规则就是 B 作为 A 的网关，对出流量做 SNAT ，对入流量做 DNAT 。

但是 A 的防火墙规则限制了来源只能是 B ，那 B 要对入流量同时做 SNAT ，修改其来源 IP 为 B 2.2.2.2 ，这就导致 A 认为请求来源都是 B ，回复的 DstIP 都是 B 2.2.2.2 ，因而无法正常返回数据。

解决的办法是：

1. B 以反向代理（ reverse proxy ）的形式工作，这样 A 可以保留防火墙规则。但反向代理对于协议有限制，tcp/http 类可以，udp 很难。

2. A/B 各自增加一个网络接口，两个接口之间建立某种点对点链路，然后走 NAT 映射

直接说结论：如果 A 的防火墙

OP 发了不少帖子了，一直想证明前端利用 wasm 做混淆很难破解。这个结论本身没问题，你要逆向 wasm 的内部逻辑就要走汇编调试那一套。只靠单纯的前端技术应付不了，但是在做逆向的人眼里，没什么区别。

这里大部分回复的都是在说，wasm/js 的交互机制决定了，多数时间把 wasm 当黑盒，用 RPC 方式调用就好了。没有必要去理会内部实现。

这里讨论的隐藏前提是用混淆手段防机器人的，基于加密参数限制非 web 客户端对于后端 api 的调用。

然后 OP 提出，这个加密逻辑全生命流程只能执行一次。说实话我想象不到这样的代码的应用场景，特别是防机器人的方面。（比较接近的是类似微信读书，原始 html 用 canvas 重渲染然后删掉原始数据）

对于 RPC 调用的应对，OP 认为可以在 wasm 内部做针对外部环境的检测。这一点我从根本上就不认同。

因为从根本上，客户端就不是可信的运行环境。别说浏览器了，手机 app 为什么都要做 root 越狱检测，都是一样的道理。这是个技术之外的哲学问题，你能判断自己是不是生活在虚拟世界里吗？

至于实践方面，我是比较赞同 @tool2d 的，基于虚拟机的混淆，模糊掉控制流和调用逻辑，给逆向的人造成的烦躁感远比 wasm 大多了。

而且虚拟机类型的混淆是可以高度自动化的，你可以每天都变换生成参数和算法。然而逆向虚拟机类混淆是没有什么自动化手段的。

做得挺好的啊。

请问 http3/quic 抓包路线图计划吗？这个功能虽然和 http 1/2 列在一起，但完全没法复用已有的功能框架，而且实现这个功能需要程序外做很多工作。

因为我自己前两个月就在写 quic mitm 的 poc ，还是非常麻烦的，而且现在 quic 各个实现之间 interop 还不是很理想。如果 op 这边能做个商业成品就最好了。

@hsuehliuyang 这和有没有自信没关系啊。

前段混淆无非就是防君子、小人和机器人。第一个网站的业务，显然不是防君子防机器人，防小人也用不着，因为没有一点东西是自己的。

但是你看它用伪造的 png 头假装图片跑视频流，然后用某站的缓存漏洞托管自己的播放列表文件，这种手段水平，想加个 js 混淆太容易了。

它真想藏的大概不是 url 而是流量。

@hsuehliuyang 这和有没有自信没关系啊。

前段混淆无非就是防君子、小人和机器人。第一个网站的业务，显然不是防君子防机器人

RPC 对于没有混淆的代码来说很好用。


@hsuehliuyang 过 debugger 方法太多了，浏览器内的话方法重载、条件断点、源文件 overrride 都行。浏览器之外的话，重编译一个修改了 js 引擎 debugger 方法的版本。