我最近买的新手机号能收到银行发来的欠款通知短信，银行还打过来问我是不是 XXX （实名）


但我登录不了这个人的微信，就因为有这个好友验证。

@studyrun 链路上的同网段机器不需要经过路由器转发。所以桥接和 NAT 不应该会有区别。

我的 wsl 和宿主机就是桥接的：

https://i.imgur.com/4oIsQJq.png

@bk201
> 人家就是混口饭吃，也是朝不保夕，被开了还没赔偿，你还能对对方有什么要求。

你知道 wuli 外包哥哥有多努力吗，你们非得看到他进监狱才开心吗

> 曾经纠结了一两周的问题，科班程序员因为知识面的原因，一天就搞定了

想多了。

但是， 你纠结一辈子也想不出任何入门方向的问题，科班的确实能受益于知识储备结构起码找到研究方向。

之前有过这样一个帖子：
https://www.v2ex.com/t/845892#r_11550945

我描述了一点科班出身的工程师解决问题的小优势。

最近几天我又见识了几个新问题，你可以尝试思考一下这个问题你有没有思路：





我要开发一款能分析二进制程序漏洞的自动化扫描器，我需要先搜索哪些论文？

@thisismr2 这样的描述还是有点模糊，由于细节你是没法全部表述清楚的，我也不可能很快地完整理解整个系统的结构，所以没法下确定性的判断。

但总之
1. 预设服务器不可能攻破并不十分可靠，无论是逻辑缺陷还是旁站业务还是侧信道都有可能从中提取信息，相比之下终端反而安全很多，甚至在考虑存在 0day 的情况下通常也需要 1-click 才会发生入侵
2. C 和 S 不需要共享任何信息，作为攻击者，他的做法可以分别获取想要的信息再重建关联。再说了，「 C 泄露的 K 是 S 上的某个通信密钥」这个关联已经很强了
3. TLS 只能保证链路安全，无法保证端点上的安全，除非 S 是一个单纯的流量转发器，不解析 TLS 中的内容，那么信道没有在 S 上落地，可以认为在 S 点上安全，但描述并非这么回事。
4. A 和 B 的认证 cookie 没有没有包含在信道建立的步骤中，因此没有作用，除非你的设计是登录后创建的信息与 AEAD 加密的 key 强关联，那么登录状态能同时保证消息完整且可认证，这样是可以确认消息只能由持有登录状态的人发出/解出的。


我就假设一个攻击手段好了
1. 想办法批量获取全网的 C ，记录在线时间和 K ，记录为 R
2. 在 S 上取得一组 AB 通信记录，查询对应时间区间的 R ，用 R 对应的 K 解密

如果你真的非要假设 S 绝对安全 —— 安全是基于可信的。S 安全意味着 S 可信，那么你其实不用避免 S 得知 K ，因为 S 理应拿着 K 也不会做任何事。

如果你不担保这点，就是在假设 S 存在「主动向 C 获取 K 来解密他自己正在中转的消息的行为」的可能性，这是你系统设计外的非预期行为，如果系统设计要考虑容许这个非预期也就意味着还要容许诸如「 S 中转的消息被泄露」之类的其它非预期。所以我对你「假定 S 安全」的前提持怀疑态度。

你要从攻击者的角度来看这个问题。

K 可由 C 泄露，消息可从 S 截获，这意味着 A 到 B 并未建立起安全的点对点通信，可以通过欺骗或攻陷 C 和 S 来取得完整消息。

从进攻方视角来说，这个体系存在暴露面。（毕竟你只预设 A 和 B 的终端是可信的，S 和 C 没有包含在内）

@Features 输入：「由于不一定从一个网站采集，所以找个兼职」

我此时很想看到那个秒杀 nginx 的哥们来点拨一下 OP

嵌入式落后业界 20 年不是瞎说的

需要注意不要因为上 B 站搜索鸽子怎么养无意间踩进鸟宠深坑……

@billzhuang 事情不是这么办的。

甲方让你来办有两个意思，一是信任你，有可能把利益分给你一部分，另一方面是作为信任伙伴，你得承担一部分责任。

你告诉甲方说这个事情我不搞你们自己找淘宝就等于在说生意不用找我做，这肯定行不通的。

看看 GCP 的 API 你就稍微能理解了，它那 API 也是不用 SDK 或 cli 根本没法用的

我数了一下现在塞得满满的浏览器标签栏，约有 50 个标签

2000 个标签，就得开 40 个浏览器窗口。

算你有 4 个显示器，那也要 10 个桌面才放得下

--------

又数了一下任务栈，一个任务大概会留下 10 到 30 个标签，就按 50 个标签来算吧…… 你怎么做到 同时/挂起 40 项任务一起处理的

@cencoroll

$ brew install file
$ file yourfile

是不是忘了
https://en.wikipedia.org/wiki/Wintel
了？


你说的「去抄苹果」的这个势力，他是谁？ 他有可能是谁？

/go/pointless