@sky96111

我看了一下，QQProtect.exe 是会加载驱动的，只不过好像加载失败的时候也允许运行。

所以我更正一下。

QQProtect 我记得是有驱动的，沙盘禁止驱动加载的话不是应该会导致运行失败么？

先确定是否关机成功了吧，是不是点了关机就不管了，没等着关机成功？

@0312birdzhang
目前的话工具是不支持读 frp log 来获得 IP 的，我这里还是建议直接用 frp 提供的 stcp，基本上已经足够了。

@DoctorCat
因为目前是靠向 Windows 防火墙来写入规则阻止的，所以 Windows 防火墙关闭的话，那么本工具无效。

@0312birdzhang
按照我的理解，如果使用了 FRP 这样的内网穿透软件，那么 RDP Server 拿不到真正访问者的 IP，所以实际上也无效。
如果有使用 FRP 一类的软件，建议直接使用 FRP 自带的验证机制。

@miyunda
希望这个工具对你有用。
根据我在自己服务器上运行的结果，我改了端口号仍然有零星的尝试登录，虽然应该不会有什么威胁不过防护一下有胜于无。

Windows 才不是就几个版本那么简单。

打了一个补丁实际上就可能是一个不同版本了，不同语言的 Windows 有些文件也是不一样的（比如有些漏洞的 POC 可能就只能在英文版的 Windows 下运行成功），用户可能还会使用各种软件对系统文件进行各种魔改或者替换。

随便给你一台 Windows 的机器，如果对这个机器上运行的 OS 版本，语言，打过多少补丁不了解，单纯的缓冲区溢出类攻击成功率一样很低。

并且地址随机化这种机制，Windows 一样存在并不是 Linux Only，反倒是 Windows 默认提供了一些相当不错的防护机制。

此外针对缓冲区溢出，MSVC 编译器也是提供了不少安全机制的。
比如编译选项 /GS /DYNAMICBASE /NXCOMPAT /HIGHENTROPYVA /guard:cf
编译时附加的安全检查 /sdl
开发时针对不安全函数的各种 warning （尽管很多开发者不喜欢）

openwrt 其实是是有支持 RK3399 的，代码稍微改一下就能支持 R4S 了，后续应该很快也会加入支持。

只不过 R4S 的定位有点尴尬，价格不便宜，性能对比 R2S 又没提升多少。

推荐两张一起办

有种东西叫防火墙。
按照我的理解，只是单纯的不允许某个产品访问网络是没问题的。但是如果是有针对性的屏蔽一部分，放过一部分才有可能引起争议。

cpp 的 std::vector 是模板，模板本身只是个源码不使用的话本身并没有实例，你当然不可能用 python 直接调模板的源码。
想要用 std::vector 的话，只能你自己用 C 封装一套函数出来。

OpenWrt 可以设置 MAC 的。

LuCI 上可以在接口-》指定接口点击编辑按钮（例如：wan ）-》高级设置-》重设 MAC 地址
没有 LuCI 也可以手动编辑 /etc/config/network 来修改。

可以选择 Handle Direct Connections 选项看看。
p.s 另外 Proxifier for windows 4.0 以上的版本已经不是用 LSP 来重定向连接了，而是改用了 WFP （驱动）的方式。所以重置 Winsock 没有任何影响。

得看情况。
如果是 BitLocker 保护的系统盘，在无法得到 BitLocker 的密钥情况下是不可能的。
如果是系统盘未加密，能否取得密码取决于用户密码的复杂度，如果复杂度较低，完全有可能成功破解。

另外，系统盘未加密的情况下，如果只是为了登录系统，则不需要获取密码，可以直接通过 PE 重置密码来达成目的。

@acess
KDF 能为密码管理器这种用途增加多少强度这种问题并没有固定答案，因为 KDF 的算法，盐，迭代次数都是你自己定下来的，每个 CPU 的性能也是不一样，要加密的数据大小也未必是固定的，这里变量太多，没办法得到确切的数字。

只能说你用的 CPU 性能如果是顶尖水平，并且支付了对应的时间代价，那么其他人使用同等或者更差的 CPU 就需要尝试次数*代价时间 / CPU 核心数量次以上的代价。

当然，安全除了保密性还包括可用性之类的内容，这就是为什么要分析威胁模型。

有人直接物理上给你在 PC 上安装监视系统怎么去防护？
如果有人拿枪要你交出密码和数据库你要怎么防护？
如果有人能直接把你关进去，不让你接触密钥文件你要怎么防护？

如果你问我这样的问题我的答案是无法防护。

这种讨论实质上就是假设了攻击者无处不在（本质上无处不在也是一种无限资源）。

@acess
你应该去做威胁模型分析。
安全通常是要建立在一定前提下的，如果假设攻击者有无限的资源，无限的情报，无限的等等等，那就不存在任何安全。

以 KeePass 来举例我们以攻击者的视角来看，要得到用户密码必须具备 2 个条件：
1 、得到用户的数据库文件
2 、得到用户使用的主密钥
这两个条件缺一不可，把数据库备份到网盘上这一个单一的行为并不会导致密码泄漏，因为网盘不知道用户主密钥。
网盘服务商要是作为攻击者想穷举密码需要付出巨额的代价，这不符合经济原则，所以才可以确信数据库存在网盘上不会导致密码泄露。
至于网盘服务商封号，拒绝提供服务，也还是无法得到保存的密码，所以实际上跟安全性无关。
反过来也是一样，如果有人知道主密钥，拿不到数据库文件也没辙。

这里创建的先决条件有多难就决定了安全的上线在哪里，超过这个上线的讨论是没有意义的。

@acess
假设 KDF 的迭代次数高到用户的 CPU 需要 10 秒来得出结果，对合法用户只需要支付一次运算代价。
一个简单的 6 位数字密码存在 10^6 （ 100W 次可能），假设平均尝试 50%的组合即可攻击成功。
那么攻击者在使用同型号 CPU （假设 CPU 为 16 逻辑核心）时攻击时间则需要 500000 * 10S / 16 = 312500S 大约需要 87 小时来攻击成功。
如果不使用 KDF，通常尝试一个密码只需要毫秒级的时间（或者更少），假设只需要 100MS 即可尝试一个密码，同等条件下只需要 500000 * 0.1S / 16 = 3125S 也就是大约 52 分钟即可成功攻击。

毫无疑问的，KDF 在这里显著的提高了穷举的难度，并且当 CPU 的性能发生改变时，能迅速有效的的抵消性能提升带来攻击成本降低。

KDF 的迭代次数在理论上是无限的（具体到实践中虽然是有限的但是数字非常大，大到你绝对不会想去用到那么大）。

P.S：在我个人的实践中，KeePass 对保存数据库密钥的 AES-KDF 次数是 50W-100W 次，这仅仅只需要 1 秒的运算代价（单核心的状况下）。

此外，不同的算法在不同的场景下，作用可能是不一致的。
比如某软件就是通过 HKDF (HKDF 是 KDF 的一种典型实践) 来变换加密的密钥，使用 HKDF 的目的主要是让密钥不会重复的使用，而不是为了要拖慢暴力攻击的速度。

比特币的技术细节我个人不了解，不做任何评论。

@acess
信任是个很宽泛的词语，不太好一概而论。
在本贴里的案例来说，信任分为 2 个层面。
1 、是对个人的信任。
2 、是对事实的信任。

对个人的信任每个人有不同的想法，你可以相信某个人不会刻意去做危害你的事情，也可以相信某个人会因为各种各样的目的来危害你。大多数情况下因为其不可证伪性，这个问题没有绝对正确的答案。

为了克服对个人信任的不确定性，人类需要可以证明或者证伪的事实来确保信任。
正确的开源本身保障了：
1 、开发者难以通过插入恶意代码来危害用户。即使用户自己不懂代码，只要一旦存在恶意代码会很容易被人审查到并且披露出来。因为源代码人人都可以看到，不可能所有审查代码的人都自己主动包庇开发者，所以我们可以相信恶意行为会被披露。
2 、通常开发者会直接提供二进制文件供用户直接使用，开发者仍然可能在二进制文件上动手脚，开源保证了如果用户不信任开发者提供的二进制文件可以自行来制作二进制文件。
基于这两点来考虑开源之后对开发者的信任就不再重要了。因为可以相信社会上一定存在懂代码的好人，所以如果有问题这么一群人一定会指出来。

政治因素无法扭曲这个逻辑过程，所以政治因素不会影响这个结论。


至于 KDF 的问题


增加密码的熵值并不能起到和 KDF 一样的效果，原因是对于这种对称加密来说密码必须是可重现或者可预测的，而增加再多的熵都只能是一次性的，并且增加的熵必须要以某种方式来保存，所以找到增加的熵的时间必然很短，这并不能起到抗穷举攻击的作用。

单纯给密钥增加一个随机熵的思想密码学上通常是用来预防查表攻击的。
原因是任意的加密算法只要给完全一致的参数都会得到完全一致的结果，所以对于常见的加密结果我们可以通过预先生成的结果来比对加快破解的速度。增加随机熵后因为随机熵不可预测，所以不可能预先生成结果来比对。
具体到实践上，一种典型的实践方式是使用加盐密码哈希，以此来对抗查表攻击。

使用 KDF 时要得到解密所需要的密钥就必须符合下面的过程：
解密所需要的密钥=KDF(密钥， 随机盐， 迭代次数)

尽管单次 KDF 运算所需要的时间很短，但是由于有迭代次数的存在，即使知道了全部正确的参数，不执行迭代次数次的 KDF 函数仍然无法得到正确的密钥。
迭代次数增加将会拉长得到解密密钥的时间，提高攻击者的时间成本实质上就是降低了攻击者再有限时间内能尝试密码的次数，所以说 KDF 是能抗穷举攻击的。

可以问一个现实的问题，ARM 服务器可能只能运行定制的 Linux 内核你能接受么？