在接下来的篇幅中，我要讲一个目前还没结束的故事。故事可能还会继续发展下去，也可能因为我的懒而就此打住。但至少我觉得目前已经有足够有意思的信息可以让诸位知道了。这件事，跟支付宝有关，跟（网络）信息安全也可能有一些关系。有兴趣的朋友，可以接着看下去。
我以前曾写过一个服务器Ping值测试程序（参见这里《写了个批量测试服务器Ping值的小工具》）。这个程序一直都能满足我的需要，直到有一天在我老婆的笔记本上遇到了问题：对几乎所有的IP，我这个程序的Ping都很快收到了回应，快得不正常，几乎就像做了个本地调用一样，与实际情况不相符。于是我打算看看这是怎么回事情。
当时我人在公司，VC6远程调试又不方便。最后靠着DbgView终于搞清楚了：接收到的数据中，多出来了一份不正常的东西。我之前的代码，并没有估计到这份不正常的数据可能会出现，所以处理上出了些问题。
OK，这算是我的Bug。可这“不正常的数据”到底是什么东西？我把它Dump出来一看，还真是有点奇怪！ICMP Type是8，源地址和目的地址则与预期的Echo回应包刚好相反。算上sendto时候系统自己加上的IP包的包头，跟我送去发送缓冲区里的数据那是一模一样。
要解决我程序里的这个问题非常简单。但是另一个问题就不那么好回答了：为什么其它电脑上不会这样，偏偏这台电脑会出现这种奇怪的事情？
直接答案很简单——它一定跟别的电脑有什么地方不一样！
那么还有第二个问题：到底是什么地方不一样呢？
可以说是我的幸运，也可以说是阿里集团的不幸。因为我的Taskmgr里面进程列表设置为按ASCII字母序排升序的缘故，我很快就找到了这第二个问题的答案：Alipaybsm.exe。杀掉Alipaybsm.exe这个进程，前面提到的那份“不正常的数据”就不再出现。而这个Alipaybsm.exe似乎由AlipaySecSvc.exe在守护，过了一会儿就又自己启动起来了。它一出现在进程列表中，我一试，哈，那个奇怪的现象就又出现了。
后来，我把这事情在Twitter上说了一下，还引发了一场小小的讨论。
我目前还没完全想明白Alipaybsm.exe这样做的目的是什么。初步感觉，有可能是跟背地里监控网络流量有关。毕竟，目的地址不正确的数据，就算被放入Socket接收缓冲里面，在网络层与传输层之间估计也被滤掉了。我这次是因为用了SOCK_RAW，需要自己下到网络（IP）层来处理数据，才碰巧发现了这个情况。如果只是在传输层（TCP/UDP）从事工作，估计不会有任何察觉。
只不过，反过来讲，如果能做到复制数据到Socket接收缓冲，那应该完全可以做到监控流量而不带任何痕迹才对。所以我目前还只能理解为，Alipaybsm.exe想完全监控网络流量，所以利用了这个手段（复制发送的数据到接收缓冲中），但干这事屁股没擦干净（也可能没法擦干净），才产生了我遇到的这些情况。
我本来以为当时那个Alipaybsm.exe是个假货。但看EXE的详细信息，以及绑定的数字证书，都像是支付宝官方的真货。我又以为那只是一个不成熟的版本，可能有Bug，但我前两天为了转一笔账，又去下载并安装了一个支付宝安全控件，然后它又出现了，带着它那奇怪的行为又出现了。
所以，我们来仔细看看这货吧：
看上去挺正常吧？
在Twitter上讨论的时候，有人表示，在Mac上用防火墙没观察到有这个现象。为此，我今天特意去确认了一下：在Windows上抓包，也观察不到这个现象。我估计，只有自己写基于SOCK_RAW的程序，才能收到这些数据。为了检查这种特殊的行为，我专门写了个小程序AlipaybsmTester，基本上就是一个单地址单次单线程的PingTester。
从这幅截图中可以看到，Microsoft Network Monitor只抓到了一来一回共两个包，但我的测试程序发了一个包收到了两个，内容各不相同。如果杀掉Alipaybsm.exe，那就只会收到后一个包了。
接下来再看看这个Alipaybsm.exe的一些更好玩的事情：
很奇怪的是，它其实并不是随着“支付宝安全控件”（Aliedit.exe）装上去的。当你登录支付宝，根据Web页面上的提示安装了“支付宝安全控件”时，只会在Program Files (x86)\alipay下面建一个名字叫alieditplus的目录。
但是过一会儿（我这次过了30分钟左右），在alieditplus下面会出现一个update目录，并下载一个SafeTransaction_Setup.exe放在其“\job\file\tmp\zip_1009_”子目录中（不同时期不同环境中路径可能会有所不同）。随后Program Files (x86)\alipay\SafeTransaction目录便出现，里面就有Alipaybsm.exe（当然还有一些别的）。
我在网上想搜一下关于这个Alipaybsm.exe或SafeTransaction_Setup.exe的相关信息，发现少得可怜。Alipay官方完全没有提到过这些东西，好像它们是感染了AIDS的私生子一样。不过每个安装了支付宝安全控件的电脑上，估计都会有这些个东西（还有个AlipayDHC也值得注意）。我认为以这种方式进行推广的程序，很可能另有其目的，不见得真的是保障个浏览器安全这么简单。如果真是为了保障浏览器安全，完全可以公开（乃至大张旗鼓地）宣传，然后打包到安装包里一起分发下去正大光明地安装，不是吗？
PS: 我后来发现，杀掉AlipaySecSvc.exe也会导致复制数据包的现象中断，并且重启该服务之后，恢复现象花的时间比单单杀掉Alipaybsm.exe要长。可见Alipaybsm.exe的角色大概只是一个行动的发起者和结果的分析者，具体对流量实施监控的行为，很可能是它去调用AlipaySecSvc.exe中的某些个服务来完成的。这说明对于“支付宝安全控件”本身也不能掉以轻心。相关功能其实可能一直就放在AlipaySecSvc.exe中，只是没有人来扣扳机而已。而这个扣扳机的可以是Alipaybsm.exe，也可以是别的谁，那谁谁谁。
来源：http://blog.superliufa.com/2014/07/Alipaybsm-RawSocket.html
我以前曾写过一个服务器Ping值测试程序（参见这里《写了个批量测试服务器Ping值的小工具》）。这个程序一直都能满足我的需要，直到有一天在我老婆的笔记本上遇到了问题：对几乎所有的IP，我这个程序的Ping都很快收到了回应，快得不正常，几乎就像做了个本地调用一样，与实际情况不相符。于是我打算看看这是怎么回事情。
当时我人在公司，VC6远程调试又不方便。最后靠着DbgView终于搞清楚了：接收到的数据中，多出来了一份不正常的东西。我之前的代码，并没有估计到这份不正常的数据可能会出现，所以处理上出了些问题。
OK，这算是我的Bug。可这“不正常的数据”到底是什么东西？我把它Dump出来一看，还真是有点奇怪！ICMP Type是8，源地址和目的地址则与预期的Echo回应包刚好相反。算上sendto时候系统自己加上的IP包的包头，跟我送去发送缓冲区里的数据那是一模一样。
要解决我程序里的这个问题非常简单。但是另一个问题就不那么好回答了：为什么其它电脑上不会这样，偏偏这台电脑会出现这种奇怪的事情？
直接答案很简单——它一定跟别的电脑有什么地方不一样！
那么还有第二个问题：到底是什么地方不一样呢？
可以说是我的幸运，也可以说是阿里集团的不幸。因为我的Taskmgr里面进程列表设置为按ASCII字母序排升序的缘故，我很快就找到了这第二个问题的答案：Alipaybsm.exe。杀掉Alipaybsm.exe这个进程，前面提到的那份“不正常的数据”就不再出现。而这个Alipaybsm.exe似乎由AlipaySecSvc.exe在守护，过了一会儿就又自己启动起来了。它一出现在进程列表中，我一试，哈，那个奇怪的现象就又出现了。
后来，我把这事情在Twitter上说了一下，还引发了一场小小的讨论。
我目前还没完全想明白Alipaybsm.exe这样做的目的是什么。初步感觉，有可能是跟背地里监控网络流量有关。毕竟，目的地址不正确的数据，就算被放入Socket接收缓冲里面，在网络层与传输层之间估计也被滤掉了。我这次是因为用了SOCK_RAW，需要自己下到网络（IP）层来处理数据，才碰巧发现了这个情况。如果只是在传输层（TCP/UDP）从事工作，估计不会有任何察觉。
只不过，反过来讲，如果能做到复制数据到Socket接收缓冲，那应该完全可以做到监控流量而不带任何痕迹才对。所以我目前还只能理解为，Alipaybsm.exe想完全监控网络流量，所以利用了这个手段（复制发送的数据到接收缓冲中），但干这事屁股没擦干净（也可能没法擦干净），才产生了我遇到的这些情况。
我本来以为当时那个Alipaybsm.exe是个假货。但看EXE的详细信息，以及绑定的数字证书，都像是支付宝官方的真货。我又以为那只是一个不成熟的版本，可能有Bug，但我前两天为了转一笔账，又去下载并安装了一个支付宝安全控件，然后它又出现了，带着它那奇怪的行为又出现了。
所以，我们来仔细看看这货吧：
看上去挺正常吧？
在Twitter上讨论的时候，有人表示，在Mac上用防火墙没观察到有这个现象。为此，我今天特意去确认了一下：在Windows上抓包，也观察不到这个现象。我估计，只有自己写基于SOCK_RAW的程序，才能收到这些数据。为了检查这种特殊的行为，我专门写了个小程序AlipaybsmTester，基本上就是一个单地址单次单线程的PingTester。
从这幅截图中可以看到，Microsoft Network Monitor只抓到了一来一回共两个包，但我的测试程序发了一个包收到了两个，内容各不相同。如果杀掉Alipaybsm.exe，那就只会收到后一个包了。
接下来再看看这个Alipaybsm.exe的一些更好玩的事情：
很奇怪的是，它其实并不是随着“支付宝安全控件”（Aliedit.exe）装上去的。当你登录支付宝，根据Web页面上的提示安装了“支付宝安全控件”时，只会在Program Files (x86)\alipay下面建一个名字叫alieditplus的目录。
但是过一会儿（我这次过了30分钟左右），在alieditplus下面会出现一个update目录，并下载一个SafeTransaction_Setup.exe放在其“\job\file\tmp\zip_1009_”子目录中（不同时期不同环境中路径可能会有所不同）。随后Program Files (x86)\alipay\SafeTransaction目录便出现，里面就有Alipaybsm.exe（当然还有一些别的）。
我在网上想搜一下关于这个Alipaybsm.exe或SafeTransaction_Setup.exe的相关信息，发现少得可怜。Alipay官方完全没有提到过这些东西，好像它们是感染了AIDS的私生子一样。不过每个安装了支付宝安全控件的电脑上，估计都会有这些个东西（还有个AlipayDHC也值得注意）。我认为以这种方式进行推广的程序，很可能另有其目的，不见得真的是保障个浏览器安全这么简单。如果真是为了保障浏览器安全，完全可以公开（乃至大张旗鼓地）宣传，然后打包到安装包里一起分发下去正大光明地安装，不是吗？
PS: 我后来发现，杀掉AlipaySecSvc.exe也会导致复制数据包的现象中断，并且重启该服务之后，恢复现象花的时间比单单杀掉Alipaybsm.exe要长。可见Alipaybsm.exe的角色大概只是一个行动的发起者和结果的分析者，具体对流量实施监控的行为，很可能是它去调用AlipaySecSvc.exe中的某些个服务来完成的。这说明对于“支付宝安全控件”本身也不能掉以轻心。相关功能其实可能一直就放在AlipaySecSvc.exe中，只是没有人来扣扳机而已。而这个扣扳机的可以是Alipaybsm.exe，也可以是别的谁，那谁谁谁。
来源：http://blog.superliufa.com/2014/07/Alipaybsm-RawSocket.html
没有评论:
发表评论