360 病及其它

提到不要用 360，总会有人跳出来问：你有更好的吗？
别人说自己笨就算了，没怎么见过把自己的笨拿出来秀的。不过算了，术业有专攻，确实不能期望每个人都有及格的信息安全相关技能。那么，这个逻辑是否正确呢？是不是没有更好的替代品之前，360 尽管是个臭流氓，但仍然是个还算不错的选择呢？

要我说，这是一种典型的把自己的 XX 寄托在别人身上的毛病。这毛病极坏！不过，所有使用360 的人，或多或少都有这个毛病。
自己安全不安全？不知道。不知道要去弄明白啊！他不，他去听 360 的。360 说我安全，360 说我体检一百分，360 说你的电脑高风险，360 说你给我装的 GoAgent 是病毒。

许多年前，有一群人也是，觉得某个党挺好，于是什么都相信它。于是他们觉得找到了替代品，旧的那个可以不要了。于是旧的那个被赶到了一个小岛上，后面的事情大家都知道了。
人民是很容易偷懒的，一旦他们觉得某个英雄可以拯救他们，某个国王英明贤德，他们很容易就会把一切都交付了。国人如此，其他国家的人民同样是如此。不过区别是，不少其他国家的人民已经从历史的教训中学得比较聪明了，而我们的政府还在不停地对我们的人民洗脑、欺骗。
360 也一样。把操作傻瓜化的同时，一切都拱手交给它了。我还记得 WALLE 里面飞船上那些人类，一切都交给了机器，以至于变得肥头大耳四体不勤站都站不稳活像笼子里的哈姆太郎宠物鼠，自己却浑然不觉。不同的是，船长与方向盘搏斗的时候，所有人都在为他加油，没有傻逼跳出来说我们活得挺好的挺舒服的要吃有吃要睡有睡要玩有玩安全和谐别给劳资破坏来之不易的大好稳定局面。

好吧，我再次承认，不是所有人都有及格的信息安全相关技能（事实上是大部分人都没有）。这不丢脸，就好象我不会任何武功，来个强盗一刀就把我给灭了。只是，我也不会去做那些危险的事情，爬上火车打架就留给 007 他们吧。不具备信息安全相关技能，就自己小心谨慎一点。查杀木马你不会，预防堵漏你也不会，物理断网你总会吧？怕中木马，污七八糟的网站就少去晃荡，盗版软件就少去下载。怕网游被盗号，就别扔那么多钱和时间进去玩，更别去到处翻什么破解外挂。老在垃圾堆里刨吃的，人能健康吗？步行街上那么多漂亮妹子你不去追，宅在家里玩什么网游？妹子会传染你艾滋病吗？12 月 1 日的讲座你真该好好听听。怕网银丢钞票，就别去玩网上支付，货到付款总会吧？什么你不会数钞票……？思想有多远，你就给我滚多远。

关于 GFW 请愿的那些事儿

白宫网站上那个关于 GFW 的请愿活动，我最开始是在周末看到的。大约在一月底的时候。

因为个人原因，周末上 G+ 的时间并不多，基本上就是瞄上一眼，发评论都不一定有时间。当时只是简单把 PO 转了一下（G+ 还没有收藏功能真遗憾）。一方面因为我之前在「死星事件」中刚知道白宫网站请愿这事儿，觉得这次活动还有那么一点儿小意思，值得去做一下。另一方面，当时那个 PO 是以一个教程的形式写出来的。也许作者的初衷是想让读者无需任何脑力即可操作，但结果就是那段文字看起来相当复杂，普通人（包括我）一眼看上去就会觉得「哎呀这么麻烦啊」。当时我的想法很简单：这大概是一个要花点时间的事情，等有空再做吧。反正截止日期我看过，2 月 24 日，还有近一个月，中间还有春节假期，时间大把的有。

后来没过两天，我发现这件事情其实很简单。起码比我上 1 号店买个牛奶要简单多了。唯一的问题就在于，即使用 Gmail 注册，确认邮件也是过了一阵子才收到，至少没有像大多数网站那样秒到。流程稍微一卡，我转过头就做别的事情去了，以至于这事儿最终分了两步才完成。不过我想说的是，过程真的很简单，除了一个邮箱无需任何其它条件，也没有什么后遗症——如果你连转发政治 PO 都不怕的话。

再后来，签名进展异常缓慢。我签的时候有三千多，现在也才刚过一万。估计信息就只在一个不大的圈子里面传播。同时，还有网评员和小秘书在信息流动过程中捣蛋。总结了一下，我大致见过以下论调：

1. 投了也没用。
2. 懒得去理这样的破事。
3. 侵犯 GFW 工作人员的自由！
4. 太麻烦！
5. 不懂英文！
6. 不是只有美国籍才能投票吗？
7. 什么是 GFW？

有兴趣的话各自对号入座。至于对这些论调，我就不发表评论了。不是没有话说。要说的话很多。但是相信各位至此已有相关的心理准备，在下就不多啰嗦了。
我 Google+ 个人资料里面的个人宣言是这样写的：人在做，我在看。不是我以老天爷自居。所谓众生相，其实谁都看在眼里。至于在不在乎，那就只有各位自己心里去掂量了。不管诸位在不在乎，这破事儿，反正我，是看定了。

VC6 最佳拍档，Platform SDK Feb 2003

很长一段时间内，一直用 Platform SDK Server 2003 SP1 来搭配 VC6 进行开发工作。但这个组合其实并不是很合适。这个版本的 Platform SDK 里面，有一些东西是 VC6 的 CRT 已经无法支持的，比如对 __time64_t 进行操作的那些时间函数。另外在链接到 shell32.lib 之类的库的时候，也会报错说调试信息的格式已经不匹配了。

最后一个支持 VC6 的 Platform SDK，是 Platform SDK Feb 2003，比我之前用的 SDK 版本要更旧一点。微软官网已经不提供下载了，目前给出的所有链接都是失效的。好在有网友通过 独立Blog 提供了 cab 包方式的下载。我把这些 cab 包中打包的文件提取出来后制作成了 ISO 光盘镜像，便于刻盘保存，也更方便下载。

以下下载链接来自于 Mega 网盘。下载无需注册，但国内下载速度不太好说，有快有慢，并且（从 Mega 的性质看来）随时可能被墙。可以尝试一下 ping mega.co.nz，如果 ping 值高于 600ms，建议通过 VPN 下载（GoAgent对于Mega不顶用），或者另寻它途。
Platform SDK Feb 2003.iso (346.8 MB)

值得一提的是，这个版本的 SDK 需要你的默认浏览器是 IE 才行。貌似通过 ActiveX 控件实现的安装向导，以后的版本没有继续采用，明显是一个失败的设计。

关于 BCB 中 Package 的两点注意事项

BCB 通过 Package 实现了自定义控件的能力，用起来的确很方便。很容易地就可以扩展 IDE 的能力，设计出更为强大的软件。但在实际使用中也发现有两个值得注意的地方。

1. Runtime packages

如果打上了 Build with runtime packages 复选框的勾，那么 BCB 在 Link 的时候将会把 Runtime packages 中列出的 Package 以动态链接的方式 Link 到 Project 的输出文件（EXE 或 DLL 等）中。在发行的时候，必须带上这些 Package 对应的 BPL 文件，EXE（或 DLL）才能正常工作。

Runtime packages 是一个分号分隔的 Package 名列表。没有在列表中的 Package，会静态链接到 Project 输出文件。如果不选择 Build with runtime packages，则所有的 Package 都会静态链接到 Project 输出文件。这大致相当于在 VC 中选择 Use MFC in a Static Library。

2. Package 设置的归属

一直以为 BCB 的 Components->Install Packages 里面的内容是个全局的设置。后来才发现原来是属于 Project 里面的 Options 之一。准确地说，是其中的 Runtime packages 部分的设置属于 Project。

也就是说，如果在某一个 Project 中设置了一个 Runtime packages 列表。那么这个设置只会应用在这个 Project 的编译结果中。对于别的 Project，依然保有并使用各自的设置。

国内域名快要到期

八年前不懂事，通过国内商注册了域名，而且后来图便宜一下子续费了好多年。于是 superliufa.com 这个域名一直要到 2013 年 01 月 10 日才到期。当时看来是很久远的事情，不过现在看来大限就快到了。

根据以前过期的域名看来，该国内商有个流氓措施，就是会在域名过期后自己掏钱续费一年，但是收回所有管理权限，让你没法马上转移。不过我不着急呀！我的网站，一不用来挣钱，二不用来炒流量。一年后咱们走着瞧，奸商您要是兜里有俩闲钱咱们就再斗个一年，爷生命线挺长，耗得起。

不过，如此一来，这个架在 Blogger 上的博客，墙内的朋友很快就要无法访问了。墙外的地址是 superliufa.blogspot.com，届时（2013 年 01 月 10 日后）我将会取消博客上的自定义域名选项，这样首页就不会再跳转到 blog.superliufa.com 了。要翻墙的赶紧啊！可以参考我的 翻墙系列文章（虽然还不多），千万别输在起跑线上哦！

真与假，真的那么重要吗？

经常看到有人跳出来说，某某消息是假的，某某图片是 PS 的，这都看不出来，傻 B。

我承认，说以上的话，的确是会产生一种优越感。而且很容易用「人云亦云的家伙」、「没脑子啊你」、「缺乏独立思考能力」等等理由继续攻击下去，痛快一番，嘴嗨翻天。
不过，很多次，我都想问这些优越人一句：真或假，真的有你以为的那么重要吗？

谣言之所以成为谣言，仅仅因为它与事实不符。事实是否存在，是贴不贴「谣言」标签的关键。但是，所述内容本身并不会因此有任何的改变。
当大家还没去了解事实到底存不存在的时候，对于这个谣言的理解，就反映了直觉及经验性的判断。而这也正是某些谣言得以流传，而另一些谣言根本没人相信的原因。
为什么会有这个判断，我认为这才是重要的。换句话说，大家愿意相信什么？

基本上，大家更倾向于相信：

• 符合日常生活经验的事情：比如铁球比木球掉落得快
• 符合心中期许的事情：「本该如此嘛」
• 更具有公信力的机构的宣称：政府说了……
• 三观接近的描述：各种信徒
• 可能会对自己有益和/或避免对自己有害的事情：转发中奖/买盐防辐射
• 毫不关己、无关痛痒的事情：西安有个薛姓小孩捡了颗玻璃珠……
• 具有更多论据（但真伪并不确定）的论述：图片好多！
• 自己力所不能及的事情：到底有没有上帝？
• 负负得正类的消息：所谓高级黑
• ……

这也就是所谓的「谣言的土壤」。在证据不足的情况下，为什么谣言会生根发芽，这就取决于它本身的「营养」。一个事实很容易修改成谣言，只要把其中的具体时间、地点、人物等关键因素进行置换就可以简单做到。优越人、证据人们可以轻易地把这些谣言驳成个筛子。但是这并不妨碍这个事情固有的性质。摸着自己的良心问问自己，如果它是真的，你有什么看法，以及你为什么会有这些看法。

然后你会发现，即使是抢盐这种事情，都没有看上去那么简单。那么多人真的都吃了脑残片吗？如果有人告诉你，你正处于某种恶性重大疾病的威胁之下，得了那种病只有死路一条，死前身上插满管子，气管被切开口不能言，大小便失禁，生活不能自理，并且还会耗光你的所有家财，倒欠一大屁股债，你会妻离子散、家破人亡，DNA 面临被淘汰的厄运，而能预防这个疾病的药物却很便宜……

在最后，要提醒某些人一件更可怕（但不是没有过）的事：「狼来了」这句话，不只有放羊的小孩会讲。在我们这个科技的时代，狼，也会讲！

头一次埋彩蛋哩

在改某个 Bug 的时候，需要通过已知的 HWND 来判断该子窗口是不是一个 DateTimePicker 控件。办法很简单，只要给这个子窗口发一个 DateTimePicker 控件的特定消息，如果返回值正确，那么就认为猜对了。

但是在选择这个「特定消息」的时候，我犯了难。DateTimePicker 支持的消息本来就不多。为了避免对正在编辑的数据带来扰动，只能选择 GETXXX 之类的消息。并且这个消息还得有定义良好的返回值，用于鉴别消息是不是发对了人。

一开始我选的是 DTM_GETSYSTEMTIME，这货能返回当前编辑的时间。但我发现控件一旦响应了这个消息，键盘输入就像按过回车一样被 COMMIT 过了，导致年份之类的多位数字根本输不完整。回头看了看 DTM_GETMCCOLOR，又无法确定返回值是不是能够鉴别出来。有个 DTM_GETDATETIMEPICKERINFO 倒是看上去挺好，可惜只支持 VISTA 往上。最后我选择了 DTM_GETRANGE。

DTM_GETRANGE 可以返回设计者在 IDE 上给 DateTimePicker 控件定下的最大/最小值。所以我只要把最小值设一个特定的日子，然后看看返回值正不正确就 OK。实验下来对输入也没有扰动，是个很好的选择。那么，日子选哪一天呢？

……我敲入了 1989-06-04

一个关于浮点运算的坑

这两天遇到一个很奇怪的问题，后来通过排除法终于把故障点缩小到一句代码，但还是很奇怪：

某个同事以前用 VC 写了一个 DLL 用于提供某类通用计算，相当于一个计算模块，由我这边写 BCB 程序来调用。不过在这次的问题中发现，一旦线程调用过 pow() 这个 C 库函数来计算过一个非整数指数的幂，那么这个计算模块接下来同样的参数再次用就会得出不一样的结果。调用过 pow() 之前是一种结果，调用之后是另一种结果，现象相当稳定。

诡异就诡异在 pow() 的返回值既没有错，也没有被采用过。比如仅仅一句：
pow(2.0, 3.1);
函数返回值根本没有用来干过任何事情，相当于直接丢掉了。那么按道理来说这行代码应该不会对之前或之后的代码造成任何影响。但它确确实实影响了。
然而指数如果是整数，就不会，比如：
pow(2.0, 3.0);

那个写 DLL 的同事对此也是一头雾水。怀疑点一度被放在 VC / BCB 身上，因为它们的 CRT 不一样。但因为正好有一个测试工具，稍加改造便可以针对计算过程输出详细的结果报表，因此用来比较了一下，发现了问题：出问题的地方，有两个本来应该用来比较的 double 型输入数据正好是相等的。在 pow() 调用之前，它们的确被判断为相等。但调用 pow() 之后，计算结果显示它们被判断为不相等了。

这种事情对于常写浮点运算相关代码的程序员而言是很容易引起警惕的。浮点数不能直接用 == 之类来比较，必须去判断两数相减的绝对值是否小于某个精度。所以将这个测试结果提交给写 DLL 的同事之后，很快就定位并解决了问题。
但这里我更关注的是以下几个问题：

1. pow(2.0, 3.0) 和 pow(2.0, 3.1) 的不同，使我相信 CRT 肯定对前者作了优化。这种事情，想得通，但后果可能是个坑。
2. 很明显，CRT 在 pow() 被调用之后，处理浮点数时的行为模式改变了。通过观察 _statusfp() 的返回值，我发现调用前为 0，调用后变成了 0x20。但这个 0x20 是一个 Undocumented 的东西，哪怕是最新的 MSDN 上也找不到。并且我通过 _fpreset() 将状态字变回了 0，但计算模块仍然会出错，说明应该还有别的东西也被改了。这个坑是不是 VC 和 BCB 联合挖的，目前还不知道。
3. 如果不知道有这个坑，就可能导致一些大麻烦。在特定的代码逻辑中，这个问题很难通过黑盒测试发现。它可能在很长一段时间内都能工作得很好，直到某一次有个用户算了一个指数带小数点的幂，然后……一切就不一样了。这简直就是逻辑炸弹嘛！让我想起了《深渊上的火》里面可怜的蓝荚和绿茎。
4. MSDN 真心不是完全靠得住的。

在本文最后，还要对提供过重要帮助的 Libin Yan 表示感谢！并感谢所有关注和评论过这个 PO 的 G+ 网友！

黑客故事 2：关于弱口令设备的闲话

家庭路由器都有 HTTP 的管理界面的。不过我估计给这些人家布网络的人大概都很不耐烦，因为那些用着 admin / admin 这样密码的路由器，80 或者 8080 端口就这样开在 WAN 口上，在自己附近的网段上完全是一扫一大片。另外，早期家庭路由器大概厂商这边投入也不够，大部分都偷懒把 PPPoE 密码写在了网页上。据我当时看下来，什么网件、D-Link、腾达、贝尔，统统中招。唯一做了防范措施的，是 TP-Link，这导致我之后买路由器时几乎没有考虑过别的任何牌子。

话说这 PPPoE 密码我轻易拿到了一大批。要是到了坏人手里头，互联星空就有得赚了。不过我系好人呀，好人我只是去电信营业厅看了看大家的住址，从来没用来干过坏事。不过就算不知道 PPPoE 的密码，也能干坏事。断网什么的都是小事。当年还没有 360，一台没打过补丁的 Ghost 机器被 DMZ 暴露在外网，会出现什么情况？

这些年，中国电信大力推广它的定制路由器。无论是管理密码还是无线安全都得到了加强，从这方面我觉得还是应该予以正面的肯定。不过我还是嫌它太烦，让它下岗了。用刀能自杀，也能防身。既然我不是小白，就不需要给我学生剪刀玩吧。

专业级的设备，比如机架式的路由器、防火墙，铁皮壳子，比家用路由器那种塑料玩意儿容易让人觉得可靠。呵呵，看起来可靠，于是某些人就不设密码，23 端口开着就往外网上放。哎呀，这种设备要是被扫到那能怪谁？其实我很多次都怀疑这些统统都是蜜罐。23端口开着，弱口令，轻易就能拿到最高权限。哦，被我第一个找到？这世上有这么好的事情？

当然，从这些设备上的情况看来，它们只是被当作傻瓜型设备在使用。SSH 没开就不用说了，连私钥都没有，说明 SSH 从来就没开起来用过。日志也是只开了默认的 syslogd。有个单位的硬件千兆防火墙连一条 IP 过滤规则都没有配，完全当路由器在用，下面接的 PC 却只有五台。但即使这样，我也只是逛了逛，浏览并学习了一下这些网络设备的命令和界面，除了清掉日志停掉 syslogd，不敢做任何改动。没必要自己给自己找麻烦，对吧？

我想说的是，这些设备，完全可能成为僵尸网络的一部分。不要以为只有电脑才能被僵尸网络控制。防火墙不好好设置，比 PC 还残，关键是你根本想不到它会成为威胁的一部分。为了维护自己网络的安全，你可能还离不开它，但真正的内鬼其实就是它。甚至也许都不是防火墙、路由器。交换机？也有可能。但问一句，你们单位有摄像头吗？

黑客故事 1：图形验证码上的 SQL 注入点

有一次，遇到有人在街上发宣传材料。本以为是什么餐馆开张之类，拿回家一看才发现是个类似网络传销的东西。我当然无意参加，但既然是「网络」传销，就必定得有网站和服务器，于是打开电脑看了看。

网站挺简单，就是一些宣传页。但我觉得肯定得有后台系统。果然没多久就被我找到了，PHP + MySQL 做的。登录输用户名+密码，另外还有图形验证码，没有 SQL 注入漏洞。看来开发者对登录这块还是相当注意的。又看了几个页面，还是没有注入点。我想撤，但又有点儿不甘心。向这种非法组织的服务器下手，基本上是没有法律风险的。他们显然不敢报警。所以我又回到登录界面上。在看 HTML 代码的时候，图形验证码那部分吸引了我。

我发现他们的图形验证码没有用 Session 来控制，用的是 URL 传参，GET 方式。也就是说在 URL 中给出了一个数字，然后服务器上返回一个生成的验证码图片。我在表单中也找到了那个数字，试着刷新了一下页面，数字加了 1。用旧的 URL 还是能拿回原来那幅图片，但一旦该图片中的验证码被「使用」过，就不能再拿到了。

这意味着什么？这意味着验证码与这个数字之间有某种联系，某种对应关系。这个联系可能是 Hash 出来的，但根据现象，更可能是存下来的。我决定赌一把。果然，验证码图片的 URL 存在 SQL 注入点。每次读出来的是存起来的四个字母，然后交给 PHP 生成图片。

也许开发者认为，就算被注入，入侵者面对着四个字母的图片也干不了什么破坏。但他可能忘了有 MID 这个函数。我利用这个漏洞确认了 admin 这个用户名确实存在，也拿到了 Hash 过的密码。不过接下来我收手了。我想再潜伏一段时间再动手。结果一个月之后，我再去看的时候，这个服务器已经不在了，网站也不在了。大概被警方打掉了吧，可惜！

在这个故事里面，我想强调的是，SQL 注入每一个地方都要防！哪怕再小的漏洞，也能造成危害，一个都不能疏忽。