12306本身有很多很明显的漏洞和缺陷。比如订票查询必须的5秒钟其实只是界面上的限制，服务器的查询没有任何限制。比如查询结果的mmstr是没有绑定用户的，一个账户查出所有用户可用。比如订单提交页的5秒时间没有任何提示。这些从12306存在的第一天开始就存在，在这些没有被微博大规模转发引人注目时，他们是懒得去修正的。
封堵……这种费力不讨好的事情，看起来很像小孩子才会做的事情。

好吧废话不多说了。说说12306的变更。

首先是验证码地址的变更。这个变更基本上没啥技术含量，但是神奇的是原地址居然还是有效的，便给了用户始终输不对的错觉。
地址从 passCodeAction.do 改为 passCodeNewAction.do。

然后，大招憋出来了。
在登录页面、查询页面、订单提交页面，分别会插入三个动态的脚本文件。基础地址都是这样的：
https://dynamic.12306.cn/otsweb/dynamicJsAction.do?jsversion=7576&method=loginJs

method=后面的内容根据页面不同会有差别，在登录、查询、订单提交页面，分别是 loginJS、queryJS、orderJS。
这个脚本的内容大致相同，有细微差别。典型内容如下：

 

这个脚本分为三个部分。第一部分是加密函数，实现了一个加密算法。第二部分是初始化执行函数，负责整个检测流程的初始化和引导。第三部分是检测函数，根据对应的特征来进行检测。

算法部分略去不谈，先看检测函数。检测函数基本上会分成四块。
第一块根据样式名来进行检测。样式名预置了一堆东西，基本上都是一些订票助手或抢票王会插入页面中的显示结构。
第二块根据ID检测，ID列表看起来都是一些订票助手会抢票王会插入页面中显示的内容。
第三块是Javascript变量检测。检测对应列表的JS对象属性。
第四块是HTML文本检测，检测指定的HTML结构中的文本是否带有指定的文本。
检测完成后，每个标记位检测到则设为0，没检测到则设为1，最终拼成一个四字符的字符串并返回。
值得一提的是这个检测函数名叫gc()，我一直在怀疑是不是写这个函数的伙计写到这里把自己写High了。。。

而第二块引导函数干了两件事。一件事是启动了一个定时器，每2秒钟调用一次检测函数，直到找到了证据。这种行为类似于一些软件定期扫描系统进程。当然扫描是为啥那就另当别论了。找到后上报给服务器。
第二件事就是对当前页面里面比较重要的表单（比如登录表单，提交预定表单）绑定事件，在提交的时候插入俩包含检测数据的隐藏域，提交后果断删除。对于为啥删除我一直很费解，可能是怕人发现吧。

当然，他们也很忙。这种忙体现在三个方面，一个是上报地址的变更。一开始是固定的，后来可能因为会被拦截，所以还冒出了好几个地址，而且都是整点放票的时候出现，平时不出现来迷惑你的视线。再一个就是预置的特征码变动很勤快，几乎每小时都会增加。最后就是自己的处理逻辑变更，比如提交订单的时候没有隐藏域开始时没事，后来被改得如果是整点，那么必须失败（体现为白屏）。
这些变更让我相信这群LS是完全有时间和精力的，所以我对他们于自己的功能上一点不上心愈发得愤慨。

大半年了，就这么点变动，还是变得这东西，真是让人绝望。回想历次变更，我最喜欢的是在提交订单页提交订单必须延迟五秒钟，这种延迟保证了一定的公平性，哪怕验证码被自动识别了，也能降低他们的优势。只不过设计得很粗糙——没有界面，没有提示，手快了还会告诉你验证码输错了。

以上不涉及反制细节，因为我相信这虽然无聊而蛋疼，但你们还是会上蹿下跳来做这些完全没意义的事情的。
经此一役，我相信以后独立的软件版和网页版会越来越多。你要检测你的界面，那不用就好了，没有说一定要改你的界面。
就好像我说，我没有一定要陪你们玩一样。