ICDYCT / 我能, 你也行

纯记录笔记 Linux 可以用 sh -c "command"启动新进程, 再用进程组进行管理. 示例代码  https://github.com/crazypeace/my-dream-proxy-client/blob/main/process_unix.go Windows 有类似的启动方式 cmd /c "command", 但是没有方便的进程组. 只能用 Job Object（作业对象）, 代码一下子要加很多. 我考虑到 翻墙客户端(壳) 启动的 xray子进程 并不会启动孙子进程.  所以就先把 "command" 分解为 exe 和 args, 然后 exec.Command(exe, args...) 示例代码  https://github.com/crazypeace/my-dream-proxy-client/blob/main/process_windows.go

环境 Oracle 甲骨文 ARM VPS  非root用户 需求 Hermes 调用浏览器 用agent-browser工具 问题1 安装了firefox,  但 Hermes 说 TA的agent-browser工具 只能用 Chrome/Chromium 类 问题2 用snap安装了Chromium, sudo snap install chromium 但 Hermes 说 TA的agent-browser工具 只认识apt安装的 解决方案 要求 Hermes 研究了一下TA自己, agent-browser工具 可以加上 --executable-path参数 指定snap安装的Chromium 我让TA写在了自己的memory里面 ======== 看看别的 《指挥Agent操作 在你自己的VPS上尝试复现 VLESS-Reality-cracker 在Hermes-agent官方免费白嫖的qwen-3.6-plus的帮助下》 《token中转站记录关键字信息》 《安装OmniRoute 白嫖免费模型oc/deepseek-v4-flash-free 在 甲骨文Oracle ARM VPS Ubuntu系统 用非root用户 不用sudo -i》

前言 VLESS-Reality-cracker 的核心思路是: 如果被测试的TLS服务端是Reality服务端, 那么 重放抓包的client-hello数据包(1)      和     发送 {基于数据包(1)修改了sessionID} 的数据包 会使得随后发出的探针数据包被不同的TLS系统处理,  一个是Reality服务端的TLS系统, 一个是"偷"证书的域名所在的TLS系统. 预期的测试结果是, 探针在两轮测试中得到的返回结果会不同. 从反面讲, 如果被测试的TLS服务端是"正常"TLS服务端, 那么 探针在两轮测试中得到的返回结果会一致.

前言 原来, 我的 Xray-Reality极简一键脚本 是支持带参数运行的. 如, bash <(curl -L https://github.com/crazypeace/hy2/raw/main/install.sh) 4 8443 有FQer反馈, 说自己用的是nat机, 出入IP不一样, 需要人工控制IP的功能.

前言 根据 之前的测试 ,  Caddy的HTTPS服务端的测试结果中 探针的状态与 Reality服务端的第1轮测试是一致的

前言 上一篇我们已经实现了 手搓复现 VLESS-Reality-cracker 那么, 按照作者的理论, 如果测试对象不是 Reality 服务端, 而是一个真实的HTTPS服务器, 探针应该显示相同的结果. 让我们试试 Caddy 提供的 HTTPS 服务

前言 前两天 在Agent和模型的帮助下, 尝试复现VLESS-Reality-cracker 担心模型糊弄我, 所以准备自己复核一遍.