作者归档:admin

我的那些微软外设

今年(2023 年)上半年看到一则新闻—— Microsoft’s mice, keyboards, and webcams are being discontinued in favor of Surface accessories ,微软竟然就这么要放弃外设市场了,心里暗暗地觉得有些可惜。下半年在某东商城中发现二手 9.9 新 IE3.0 蓝影复刻版,连邮费都只要 RMB70 不到,顿时那些年看的《电脑爱好者》中对 IntelliMouse Explorer 系列鼠标尤其是 IE4.0 的吹捧又浮上心头。翻了翻网上的文章,不料到大家对 IE3.0 这第二次也就是蓝光引擎复刻版意见极大,丢帧、不适合游戏云云,但我本就是以 “情怀” 为主,办公为辅,对游戏表现毫不在意。到手之后发现设备几乎可算作全新,性价比——哦不,情价比真是爆棚了。

我中学的时候课业繁重,只被允许接触家中不能联网的电脑,以《电脑爱好者》为主的电脑杂志成了我的重要娱乐活动。我至今清楚地记得,那段时间在心里一直有一份 “梦想装机配置表”(如此 YY 的好处之一是可以随时更新 “硬件” 而不用花钱:D)其中微软 IE4.0 曾常年霸榜,成为我的终极梦想外设,甚至到了如果有幸能去虾头微软总部要去纪念品店买一座的夸张想法。没曾想,IE4.0 虽然在初代 IE3.0 之后被微软寄予厚望,但就像红巨星一样昙花一现,倒是初代 IE3.0 歪打正着,成为职业 CS 选手 “非官方指定外设” 后又出了两次复刻版,系列寿命接近 20 年,成为微软外设史上的传奇。

高中时,曾经参加《电脑爱好者》举办的活动而中奖,奖品是微软的 SideWinder 手柄一部,到现在都记得在计算机课上查看中奖名单时的兴奋之情,当然还有邻桌同学 “你的名字为什么会出现网页上” 的疑问。这部手柄左侧有一个方向键盘,右侧功能键区不同于现在的 XBOX 手柄,有 6 个操作键,中间的 2 个功能键被我用作红白机模拟器的 SELECT 和 START 。这个手柄的握持感非常好,但有个致命问题是:玩红白机模拟器时 “下” 经常误触发为 “左下” 或 “右下”,后来自己维修——也就是用铅笔涂导电橡胶增加导电性时发现:方向键的导电橡胶的分布不是按照 “上、下、左、右”,而是在 “左上、右上、左下、右下” 四个位置,这意味着按 “下” 键时 “左下、右下” 两个触点须同时导通才能正确传递 “下” 信号,导致方向键极易误触发。因为上述原因,这个手柄上座率较低,几乎成为了可远观而不可亵玩的供品。

大学时,我对微软外设的喜爱仍然未减,在电脑城购置了微软舒适鲨 3000 。除了微软这块招牌,我已经不太记得到底是什么驱使我出手,从舒适鲨上也不太能看出 IE4.0 的影子(滚轮除外 XD)。磨砂材质不惧手汗,独特的红色侧键可以通过驱动自定义,我设为了在 CS 游戏中按住临时降低 DPI 以便狙击瞄准使用,自鸣得意。特殊的松下微动(甚至连外形都和常见微动不同)按压手感松垮不清脆,但还算长寿,恼人的是不时会有卡键问题;滚轮完全无段落感,但我记得阻尼感觉很舒服,且滚轮支持左右点击以横向滚动,也使我在后来在鼠标上一直追求类似的功能,因使用场景实在有限后来也不再强求(现在印象最深的就是英雄无敌 3 地图编辑器中横向滚动地图使用 XD)。这个鼠标最搞笑的就是具有来电显示功能,不知道为什么一款鼠标居然在 GSM 网络来电信号干扰下会短暂罢工,和音响中沉闷的 “嘟嘟,嘟,嘟嘟——” 干扰声一样成为放下鼠标拿起手机的信号,当时网上也可找到不少受害者的帖子,实在是又好气又好笑。

工作后不久,微软的一揽子鼠标外设开始转向蓝光引擎,诸如 “甚至能在大腿表面使用” 之类的广告宣传深深打动了我,我又鬼使神差地在没有刚需的情况下购入蓝影 4500,谁料这次我竟然落入深坑。鼠标侧裙是讨喜的橡胶材质,但竟然正在拇指处有两片橡胶的接缝,我可不想没事就去盘缝玩儿;滚轮依然延续了无段落设计,但阻尼太小体验很差,一个字就是 “滑”——我能和滚动条打起来。最终蓝影 4500 几乎未投入正式使用而直接束之高阁。其他诸如底部光溜溜的像山寨,据称是因为怕磨损而把产品信息印在纸上栓于鼠标绳之类,那都是止增笑耳了。

那段时间,也曾在同学那里体验过 Basic Optical Mouse 基础光学鲨,其轻盈压到了一切,其他方面都中规中矩不犯错,也如其名一样成为装机的基本标配一般。我给家人买过,多年以后不是死于微动,而是芯片故障变成无法识别的 USB 设备,也算是独树一帜了,既然是微软,那就算他独树四帜吧。在前公司,还体验过集中采购的黑色版 IO1.1 红光鲨,从打油程度来看属于饱经风霜,但质量却依然坚挺,手感也是人体工学没得说,在多少个值班的独孤夜手握经典,也算是我对前司的深刻记忆之一了。

回忆到此,竟然发觉微软外设给我挖的坑着实不算少了,可我对他的喜爱还是能在填满坑后堆出个小山丘来。除了沉稳的外形外,看得见握得着的人体工学也一如其宣传。归根结底,Microsoft 那几个字母(曾经?)在我心里的分量还是不一般那。

眼见不为实,curl | bash 带来的安全问题

之前在 timeline 上看到一篇 2016 年的老文章 Detecting the use of “curl | bash” server side档案馆备份),指出从服务器端可以检测出客户端是在用 curl 拉脚本还是在用 curl | bash 边拉边执行。如果检测到后者,可以返回不同脚本的内容以达到 “加料” 的效果。整个 blog 都干货满满,就是很久没更新了,站点开了 HSTS,(2023 年 3 月 12 日后)还不更新证书,正好让我学到了 Chrome(v111)在证书错误且不能跳过的警告界面盲敲 “thisisunsafe” 就可以强制跳过…

HTTP 是被 TCP 一块儿一块儿驮着在服务器端和客户端之间传输的,服务器端和客户端各有一块缓冲区,这里服务器端得先把己方发送缓冲区固定住。脚本的第一行可以用一条比较耗(客户端的)时的命令如 pingfind 等,文章 demo 的 py 脚本中以 sleep 3 为例,在此之后立即输出一大堆 NUL 空字符给客户端(使用 NUL 的原因是不会把命令行或浏览器弄得乱糟糟,但是可以被抓包或 curl --output 看到),每个 chunk 都与当前 Linux 系统的发送缓冲区大小相当,此时:

  • 如果客户端是在用 curl 拉脚本,由于缓冲区大小被定住了,那么每个 chunk 的发送间隔应该差不多,因为不管脚本里面写了什么,curl 只是当文本拉下来;
  • 如果客户端在用 curl 边拉边交给 bash 执行,由于 bash 执行东西是一行一行的,上面的 sleep 3 被拉下来交给 bash 执行要停止传输 3 秒,服务器端就会检测到有那么一个 chunk 传输间隔时间明显超出其他 chunk 。

因为要排除网络波动的原因,demo 脚本中还使用了 numpy 库中的 std 求标准差的方法来进行统计运算,当找到那个偏离平均值很大的传输间隔时则认为客户端在用 curl | bash 。文中也指出客户端可以使用 curl | (sleep 3; cat) 来反制服务器端的上述行为。其实 curlwget 拉下来看清楚再在本地执行就可以应对以上问题。

又是一个连自己的眼睛都不能相信的案例。