读书阁

第18章 与傲娇雌小鬼黑客少女的联合作战赛后终于向天降青梅深情告白（第27页）

选择无外乎两个——

要么屈从于不公。

要么打破它。

“……”

该怎么做呢？

对手的策略可以说是已经摆在明面。

自己目前是劣势，时间并不站在他这边，必须想办法要完成一次奇迹般的操作，才能掰回局势。

有机会吗……？

P4为了突破他的防御，同时运行着十几个攻击线程。

多线程强攻的打法极其消耗算力，任何一个理智的选手都不会在四人混战中这么玩，因为这意味着自己的防御形同虚设，但P4显然不在乎，因为他的搭档P2已经吸引了悠理的注意力。

他只要做到快速淘汰子墨就可以了。

但子墨注意到了一个奇怪的现象。

每隔大约十秒，这几个线程会同时卡顿零点一秒左右，然后又恢复正常。

卡顿很规律，不像偶发的网络延迟。

“（漏洞？）”

子墨的大脑飞速运转起来。

既然是同时卡顿，这说明不是攻击脚本本身的问题，而是支撑着攻击线程的某个软件在某个环节出现了周期性的漏洞。

他想起维尔西娅给他做培训时，曾经讲过，军科定制的AE工作站有一个较少人知晓的缺陷：如果启用了自定义日志追踪模块，每次请求处理完毕后，系统会在内存中分配一块缓冲区用于写入日志。

正常情况下，日志写入完成后缓冲区会被释放。但在一个特定的错误处理路径中，错误处理函数会直接跳过缓冲区释放步骤，导致内存泄露。

一次泄漏只有几KB，对于一个拥有十几GB内存的服务器来说，根本不值一提，所以这个缺陷从未被视为什么安全漏洞，毕竟它只会让系统在运行一段时间后微微卡顿一下，只需要重启一下就能解决。

但如果以极其频繁的频率触发漏洞呢？

子墨的手指悬在键盘上方。

他稍稍计算了一下，P4的每次内存泄漏大约只有10KB。

要让总泄漏量达到能卡死系统的程度——保守估计需要10GB以上——这意味着他需要发送超过一百万次请求。

这需要消耗海量的算力，哪怕他把所有可调用的资源全部压到攻击端，也未必能在自己被淘汰之前完成。

而他要付出的代价，很可能是自己的出局。

可如果他不这么做，接下来就是等待慢性死亡了。

如果——

能和悠理配合一下的话……他承担一半请求，悠理承担另一半，卡死P4的效率可以翻上一倍。

“……”

反正P2和P4已经光明正大地结盟了，他向另一人寻求合作，没人能说什么。

那么，该怎么让悠理领会到自己的意图呢？

不能直接通讯的话，就只能想办法吸引她的注意力了，然后期待她能看懂自己想干的事。

思索间，他向她发送了一个数据包。

……

P3隔离室。

在暂停的时间里，悠理已经想明白了场上几个人的身份。

P2和P4就是米尔科和雅各布，他们明摆着串通。

如果不是那两个混蛋，悠理就把这台工作站吞下去！

那么P1就是子墨。