首页 > 编程 > 记录一下诡异的ID被误杀事件

记录一下诡异的ID被误杀事件

2006年8月12日

今天和onelittlefox在机房,其间聊到wenhou这么水,可以去学工组了,于是我下意识地u了一下GCHEM,竟然发现没这个号!
查了一下.PASSWDS,发现这个号确实是没了,而且是全成0了,只剩最后的4个FF

看了一下老的.PASSWDS,GCHEM前面的号是SSPKU,这个ID在7月13号自杀了,昨天刚好到期。于是我们觉得是在杀SSPKU时把GCHEM的记录也给抹了。于是在代码里找,缺也发现不了啥问题。后来开始考虑,会不会这俩ID不是一块没的,只是巧合比较近而已。于是开始逐个对照6小时一次的passwds备份,结果竟然发现是GCHEM先消失的,SSPKU后消失的!再进一步的观察,usies记录里有两个SSPKU被杀的记录。于是大概猜出了问题的所在:

自动杀ID时,到SSPKU时可能由于位移错误,把它后面的GCHEM的记录给清0了,所以GCHEM先死的,再到7小时后另一轮杀ID时SSPKU还在那,所以会再杀一次。
验证了一下,把八月的usies中KILL的记录都给提取了出来,找到了几个被杀两次的ID,其中一个是missphebee,它在较早的passwds可以看到排在GoldenTrue前,而现在这个GoldenTrue果然也没了。

不过现在看杀人的这部分代码仍然没有明显的问题,也无法解释为什么GCHEM和GoldenTrue的记录后面都有4个0xFF(不知道是光这4个0xFF没被盖还是有更多字节,因为前面是0,看不出来),只是多加了点代码加强安全性
1.如果.PASSWDS没被lock住,记错并不再杀
2.如果lseek的相对位置的结果与绝对位置的理论值不同,记错并不再杀

编程

  1. 目前还没有任何评论.
  1. 目前还没有任何 trackbacks 和 pingbacks.