restkhz

海星。650 分，打赢了？如果可以升级武器就好了。

正好这两天在玩。

1-3b 小模型：
LLAMA 的中文不够好，这种尺寸甚至有时候中文语法会出问题，完全不推荐。
Gemma-2-2b 还算正常，智商不咋高，但是能用。
千问 3b 值得一试。Qwen 有一个 0.5b 模型，跑起来没问题，但是没啥用。
其实这种 3b 以下的模型都不算特别实用。我在手机上运行过 llama 那个，卡，非常卡。
简而言之，这个等级的模型我目前没找到什么特别好的用处。可能一些非常简单又机械的任务可以用吧。

PC 能跑的：
我用的 Gemma-2-9b 。有 GPT-3.5 的感觉，但是逊于 GPT-3.5 。我的机器配置不好，在 CPU 中跑的，9b 跑起来不快。大概 3 token/s 这样，但是能用！
DeepSeek R-1 蒸馏那些 7-8b 的模型就比较痛苦。因为经常一言不合开始推理，一推理就要推理一两分钟，给出的结果还是错的。完全不推荐弱 GPU 的 PC 跑。
Llama 3 中文依然不好。我做的测试中，只要用中文，智商就低一个档次。英文感觉还行。

云端：
R-1 在云端跑大一些的模型就量变引起质变了。30B 左右那个等级加上烧钱的配置才有用处。感觉接近 o1-mini 但成本真的高。
Gemma-2-9b 在云端能流畅跑，成本高，而且 token 限制问题，不如你一个好一些的 PC 本地跑一个量化模型了。
Gemma-2-27b 终于能流畅跑，但是质量基本就是 GPT-3.5-turbo ，没必要。


Msty 在我电脑上默认下载的是 Gemma-2b 。可以在网上搜索和总结，效果惊人的还行，速度快，质量算能用。

综上，PC 上 Gemma2 2b 或 9b ，推荐。看你配置了。
手机如果你性能够好，如果 Gemma2 2b 能跑就选择这个。

有条件的话，用 lmstudio 都跑跑。

我来暴论几句。

这个问题主要取决于游戏开发怎么做的了。
可能种子才是更加关键的问题。不管你是普通 PRNG 还是 CSPRNG 都不可能真正扔一个随机数出来，必须要一个种子。问题就在这个种子这里。

操作系统一般都有一个熵池，直接从这里获取种子是最好的。
从服务器熵池生成一个随机数并且确定结果，客户端放动画，PRNG 一次一种子，这种场景是安全的。

首先客户端。
客户端那里没有安全性可言。但是对于很多游戏大量用随机的时候基本都是客户端获取。比如你打怪随机伤害，暴击的随机。至于抽卡，取决于开发怎么想的。理论上，如果你能控制比如/dev/urandom ，逆向出算法，是可以控制抽卡等结果的。但是讲道理哦，你都能做到这些了，为什么不直接修改游戏本身...直接劫持函数或者改包改存档...

服务器上用时间做种子呢？即便在服务器上这东西也不安全。有一个教科书级别的案例就是有某个 PHPbbs 的密码找回链接用的 md5(时间戳)。时间戳有多少可能呢？反正就那几种可能暴力一下就行了。一旦算法被研究出点眉目就容易出事。

好的，排除这些情况。回到楼主的问题。。

服务器生成，种子来源可靠且不可知，算法是普通 PRNG ，但是种子一直被重用，其他因素没有不太可控的，抽卡算法是可知的，那么这样我们可以通过 PRNG 的结果推算种子，的确有可能做到预测结果。如果不只是抽卡，还可以押东西，考虑赔率，那么我们就能“控制”一些东西了。

如果服务器用的是精确到毫秒的那种时间做种子，那么就像抛硬币，只要你抛够多也能有连续 100 次正面一样。如果可以预测，即便做不到精确控制时间，假设网络延迟波动不大，我们依旧能有效找到“胜率”更高的一小段时间。确保服务器在那段时间处理请求就好了。这种情况就算 CSPRNG 也没用。种子得要当密钥看。种子泄漏了不管你是不是密码学伪随机都不会安全。

上面 mc 的例子我猜测，瞎猜，是可以通过强行刷新种子并且种子可知，结果可预测才做到控制。
不好意思暴论太多了。

我大概在十年前玩过这类东西，那会还在中学，穷得很。
当时手头有一个树莓派，于是当时直接在 tb 上搞了一个 pn532 模块，买就送白卡，非常便宜。
直接 GPIO 插上，编译 libnfc 和 mfoc ，mfoc 是...呃...“恢复密钥”的工具。
你想要白卡直接搜 m1 卡，整活的话你可能要那种能改 uid 的卡。uid 卡贵一点。直接搜 uid 白卡就有。

还有一个 Android APP 你可能用得到，这个可以读写 M1 卡，还会“尝试用出厂默认密钥”读卡。要求不高的话这个工具能应付绝大多数场景了。
https://f-droid.org/packages/de.syss.MifareClassicTool/

我不得不说...

我自己就是 Manjaro+KDE 。用了好多年了。一个有 1050N 卡的笔记本。
第一天的时候刚装 Manjaro 直接不能开机. 最后要改内核引导参数。和 ACPI ，N 卡什么毛病有关。
而后想双显卡，经常出问题。卡顿，画面撕裂。后来直接全部 GPU 渲染，
不记得后面又有什么问题了，反正一番折腾再接下来就累了，直接 mhwd 默认 video-hybrid-intel-nvidia-prime 了。
但是默认配置也一直有问题。什么问题呢？

1. KDEconnect 或者什么东西弹出提示后有概率 KDE 卡死。弹窗不消失，工具栏，菜单无响应。
2. Alt+Tab 后界面直接卡死，卡到崩溃，等待几秒中然后 plasma 自己会重启。
3. 任何 CPU 渲染的界面都低帧率。弹个开始菜单卡成 PPT 。

这些问题困扰了我两年，甚至有时候弹窗卡住我就按 Alt+Tab 同时触发 Bug1 和 2 直接卡死让 plasma 快捷重启。试着解决无数遍，一直没啥效果...

直到今天，
楼主你发了这个帖子，我为了看看你说的 kvantum 全面升级了一下系统。
然后上面这个困扰我两年的问题莫名其妙的好了，但是 Chrome 莫名其妙卡得很，打开硬件加速就好了，跑起来一点问题没有。之前不开硬件加速是因为开硬件加速 Chrome 会崩溃....

额，谢谢楼主！...

顺便一说，我觉得 Manjaro KDE 默认的配置稍稍调调也很不错啊。

不好意思，没仔细审题，一次一密码，给上上下下都道个歉，想删除的时候不小心发出来了。尤其是给 @Citrus 道个歉，我没仔细审题。
你提醒我了，你说的对。送一个感谢表示诚意。

感觉怪怪的，想了一会，没想出有啥问题。

不安全，某些情况请千万不要这么做。你的理解大致是正确的，但是尽可能不要固定 IV 。

赞同 @liuidetmks

AES 归 AES ，但是你的加密模式是什么？楼主没有说。
比如，在上面说的 OFB 和 CTR 模式等等情况下，IV 重用并且密码重用的情况下基本就完蛋了。
比如 CTR ，你只需要知道你的明文去和密文 XOR 一下你就知道密码流了。未来的加密形同虚设。
在 CBC 模式虽然不会被直接破解，但是密文相同，破坏了语义安全。有些场景可以接受。

我简单介绍一下一些概念吧，完美安全和语义安全。
完美安全性就是密文本身不会透露任何明文信息。这个太难了。根据信息论，你需要随机密钥+密钥长度至少有明文那么长才能做到。这个时候你的熵就高的足以用来混淆任何一个明文 bit 。
所以楼上 @Citrus 其实说的不完全正确。因为你密码长度只要小了就是不行。不是说会暴力破解，单纯就是熵不够。
你说的严格一次一密，你是指每个 block 都一密码还是完全参照已有的 AES 模式呢？如果你能做到前者，恭喜你，但是直接换成 XOR 玩 OTP 可能更好。做到后者，比如 CBC 模式中，密码随机 IV 固定依旧做不到语义安全。
做到这个太难了。密钥生成，传输，都是问题。

于是人们退而求其次，密文可能会暴露明文信息，但无法被有效利用。这个就是语义安全了。
保存和更新密码的成本太高了。默认密码就会重用。设计的时候也是这么设计的。

这个时候引入 IV 你的确可以理解为增加信息熵，增加密文随机性。某种意义上来说 IV 解决了密码重用的问题(密码学角度的问题)

@raw0xff 你没搞明白的是谁在防谁。
这个机制不是让你服务器防着恶意客户，而是让正常客户防第三方网站的攻击。防止第三方攻击者在正常客户的浏览器中模拟正常请求访问你的接口。这个是在保护浏览器安全，不是保护服务器安全。

你的客户可能在第三方网站被钓鱼，假设没有同源策略，假设你是银行，此时恶意的第三方网站里有个脚本会在用户浏览器里运行：自动模拟你网站的转账操作，发给你的接口。由于没有同源策略，这个请求因为带着你客户的 cookie 等信息。你的客户就这样莫名其妙被偷了钱。

或者你是一个 webmail 但是人家也可以通过类似手段，在三方钓鱼网站里插脚本控制用户浏览器，进而偷到你客户的邮件。

你说请求在接口处理与否取决于你的代码，但是这个伪造的请求千真万确是客户端浏览器发的。看似完全正常的请求，正常的 Cookie ，同样的 IP 。Referer 头不靠谱而且可能被绕过，你说用 Token 但是 Token 也可能被偷(如果没有同源策略)。你服务器要怎么检查？？

因为这种攻击发生在客户端，所以客户的浏览器实现防御才比较容易。
于是有了同源策略 SOP ，注意，SOP 不阻止请求发出，但是可以阻止带着 Cookie 。还有非同源页面能否读网站响应。

你会发现请求不带 Cookie, 同时脚本不能跨源读数据，
上面说的两种攻击基本上就被阻断了。（当然实际情况更复杂些）
但是前后端分离也同样被阻断了。


你说的：
> "浏览器访问 a 网站时 a 网站的脚本访问 b 网站，无论是 post get 还是 options ，是否响应是 b 网站自身逻辑说的算的，即便 Access-Control-Allow-Origin:* 也只是告诉浏览器 b 允许所有来源访问，至于如何响应是看代码。"


带上 SOP 以后，由 a 发起的访问 b 网站的请求不会带有 b 的 cookie ，响应也未必能被 a 的页面读取。敏感操作和敏感信息都 a 都搞不了。

而 Access-Control-Allow-Origin 是 CORS 的一部分，作为同源策略 SOP 的扩展，允许你提供接口的服务器指定哪个网站可信(可以发 cookie 和可以读响应)，就是告诉浏览器第三方网站的白名单，白名单里的网站应该不会让浏览器发恶意请求，可以让 SOP 信任。CORS 给开发部署提供一些灵活性。这样你又可以前后端分离了。

顺便，你设置成 Access-Control-Allow-Origin:*的时候，浏览器的 Cookie 是不会发出去的。这整套机制都是怕浏览器被第三方恶意网站利用。
至于调试工具，，你不用调试工具当日常浏览器，不用担心被钓鱼，而且 CORS 也要被调试。所以当然不遵守这些。

楼上有人说的 CSS 应该是 XSS. 那个是 CSP 机制的事情。因为恶意脚本插入正常网站后是同源的。