https://github.com/QChWnd/QChWnd.GitHub.io/blob/master/blog-source/4%23%202023%E5%B9%B4%E6%96%B0%E6%98%A5%E9%9A%A8%E7%AD%86%EF%BC%9A%E5%88%9D%E6%8E%A2%E3%80%8C%E7%9C%81%E7%89%86%E3%80%8D/2023%E5%B9%B4%E6%96%B0%E6%98%A5%E9%9A%A8%E7%AD%86%EF%BC%9A%E5%88%9D%E6%8E%A2%E3%80%8C%E7%9C%81%E7%89%86%E3%80%8D.md

若有錯誤請指正，感謝。

https://ourl.co/97275
我這邊暫時沒拿到這個庫
機器人在 13 日 00:41 掛了，資料真實有效，但不確定是同一庫

https://www.v2ex.com/t/928400

Archive: https://archive.is/I0WcC

關於此次 wxid->phone 的洩漏，個人想提的問題主要是 wxid 性質的方面。
目前有證實的傳言簡而言之：有可出 wxid->phone 即時綁定的 api 接口。
wxid 是小寫英文和數字組成的長度 14 的獨一 id，若沒有 phone->wxid 接口，那麼窮舉 36^14 的數量級是不現實的。這種情況下， wxid-phone 無法被做成 database 形式，只要 api 缺陷被堵，事件就完全告終。沒成 db 一般不會賤賣查詢，但目前顯然是已經有在賤賣的了。
那麼理應也會有 phone->wxid 反向的方法並有拖出 db。但若產生了 db 形式，那就盈利而言，拍賣通常優先於提供查詢（收益高，參考上海公安等），而拍賣必然會有其規模大小的公開。
想象若 phone->wxid 的 api 不存在，那麼產生 db 的前提是蒐集足夠多的 wxid。什麼樣的渠道可以獲取到數億 wxid 呢？是有很多的，可以自行想象一下。
phone->wxid 之 api 的存在性我不做過多猜測，但我個人暫時傾向於認為：db 尚未成型、api 與某些中國官方機構有關、普通用戶可考慮改綁至非 +86 手機號、EU/US 會開罰。

SagerNet 等软件的“安全建议”，就是那个红色的叹号，实际上是非常鸡肋的功能。下面我简单喵几句。

一、节点安全 不等于 不会被发现翻墙/不会被阻断

反例：1.你使用了全加密的ss，墙判断为随机流量，有概率被阻断。
2.你使用了 TLS 并设置好证书校验，但你服务器/客户端程序有特征，被扫描/识别了，有概率被阻断。
3. 今天刚好是6月4日，有概率被戒严部队指挥部阻断。
4. 你在国产系统上安装了 Clash For Android，这是诈骗软件，系统会建议你接受反炸教育。

二、节点安全 不等于 流量不会被解密/不会泄露任何信息

反例：1. ss vmess这种没有前向安全性的协议，一旦同时拥有抓包文件和密码，就能解密。但是安全建议没说。
2. TLS这种协议握手期间包含特别多的信息，比如sni alpn和证书。但是安全建议没说。
3. 你使用的机场/VPS提供商/手机系统/app都非常爱国，实时记录你访问的网站并上报国家反炸中心。但显然不可能有人告诉你。

三、节点不安全 不等于 流量会被解密

虽然存在可能性，但目前没有GFW实时解密的报导。在国际出口上部署解密是不现实的，倒是要注意某些商业防火墙可能有这种小动作。

四、节点不安全 不等于 会被封

除去流量特征，这也是一个运气问题。

综上，安全建议不仅不能阻止用户作死，而且有误导的嫌疑。实属无用的功能。

https://gfw.report/publications/usenixsecurity23/zh/
建議閱讀全文。
重點並不在於此時用怎樣的方案可以實現如上的「Shadowsocks 直連」，而在於 GFW 策略的演進。
不變的是檢測方案依舊簡單高效。
變化的是，比先前的主動探測機制更允許了誤判誤殺，但也透過不同 IP Range 的區別處理以補正這一不良影響。
這一變化已經生效了超過一年（文中稱 2021.11），判定對象也遠非（偽）隨機流。我們需要考慮更加在意偽裝能力的實作，已是不爭的事實。在流行 WebSocket/grpc/kcp 並更多地使用 (D)TLS 的當下，IV 開頭且通常並行的（偽）隨機流是否將成為對抗 GFW 的歷史，答案似乎已經很明確了。
題外話是，我認為將激進方案作為保守目的之方法，這樣的思維方式的轉變對於某國來說，應是不僅限體現於網路審查上。
話再說回來。這一判定邏輯是一種流氓式的「小聰明」，針對其的暫時繞過方案亦是如此。這不會是終點，只是車輪戰，而預計會以 GFW 的某種「智慧」告終。目前而言確實全盤否定了危言聳聽中的「GFW 機器學習論」（真是太瞧不起機器學習了）。但，基於 IP Range 的區別處理，也符合我在 GitHub 443 L4 劫持事件時就提出的路由表 & 處理層的模型（當然實際方案應該是更緊湊優秀的），這一模型是一定可以擴展至比「小聰明」走得更遠、實現更複雜可靠。當我們考慮長期開放的方案，我們應當考慮可能有效的複雜分析，包括但不限於早就存在於理論中的長度、時序、擁塞控制方式和並行特徵分析，以及研究其錯殺率。
近期我可能會釋出一批針對對抗 GFW 常用的 proxy/tunneling 相關工具鏈的簡易探測 PoC。

今天倉促寫了兩個稱不上 PoC 的主動探測特徵匹配器，分別針對 gost 和 ehco 的默認配置，也是被閑蛋轉發面板以及不少 shell script 提供的默認配置。
https://github.com/QChWnd/relay_detectors
我想表達的意思是，使用各類不含 Fallback 的「默認配置」偽裝 HTTP(S) 服務是一種「此地無銀三百兩」的行為。
兩個匹配器的主動探測甚至暫時沒有涉及協議細節的利用（打算稍晚一些的時候去做）。而且除了主動探測，被動探測和 MITM 針對這二者也是非常可用的。

#科技资讯 #安全资讯 重要提醒！黑客通过软件破解站分发带毒软件专门攻击 Mac 用户，请下载过 Mac 破解软件的用户立即自查。

查看全文：https://ourl.co/101996

据国内安全公司安天发布的消息，安天监测到 Mac 破解软件站 MACYY 分发多款带毒破解软件。

这些破解软件全部与开发和运维相关，专门针对运维人士，试图通过运维人士入侵企业内网。

值得注意的是，背后的黑产团伙此前收购了 LNMP[.]org 一键安装包和 Oneinstack，并且通过这两个集成 Web 环境投毒，本质上也是针对运维人士。

被投毒的软件目前检测到的包括 SecureCRT、FinalShell、Navicat、UltraEdit、微软远程桌面。

请下载过破解软件的 Mac 用户以及 IT 运维人员对 Mac 和 Linux 服务器进行排查，排查方法见链接。

相关内容：

1. 知名 Web 集成环境 Lnmp.org 一键安装包被投毒 请各位站长立即检查服务器

2. 继 LNMP 后 oneinstack 也被金华矜贵收购 该公司还试图买下 LAMP

3. 继 LNMP 后 oneinstack 也被添加了后门程序 建议用户不要使用这类脚本

因重要性较高，本条消息置顶 24 小时。

🎉 订阅频道：蓝点网订阅
🥰 𝕏(原推特)：@landiantech
👋 交流频道：蓝点网读者群