SupArc启动过程抓包

首先启动suparc.exe之后，进入这个界面

然后点击“继续启动SuperARC”之后，进入到这里

使用QPA抓包
http://protocol.sinaapp.com/
从SuperARC启动到进入这个界面这个过程。
从抓到的SupArc.exe_9888.pcap这个文件在wireshark中打开，就可以只看9888这个SupArc.exe进程的流量。
由于之前看到这个“服务器”这个标签下拉框的三个选项中的好像是延迟的值一直在动，所以我想看看从抓到的包里有什么体现。
用QPA的好处就是抓的流量都是纯的来自某个进程的流量，然后看到只有UDP和TCP/HTTP流量，感觉很舒服。

然后用新学的Wireshark的Statistics菜单。

发现SupARC跟四个地址通信了。基本可以猜出来。应该其中一个就是www.suparc.com，从这里拿到最新的版本信息，备份域名什么的。另外三个就是跟三个游戏服务器通信了。用ip138和ipip的接口查了一下，确实分别属于福建(默认)->proxy.suparc.com，武汉->proxywh.suparc.com，北京->proxybj.suparc.com。

$ ip1 218.6.8.243                                                 [15:58:30]
福建省莆田市  电信
$ ip1 117.79.150.227                                              [15:58:52]
北京市北京市  联通
$ ip1 119.97.178.180                                              [15:59:15]
湖北省武汉市  电信
$ ipip 183.129.179.238                                            [15:59:30]中国浙江杭州  电信

查看一下本地发出去的HTTP请求。

其中第一个请求，先得到一个获取游戏服务器的url

GET /arcplat/scrips/GetUrls.aspx?version=PROXY HTTP/1.1
Host: www.suparc.com
Accept: */*HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
Date: Sun, 02 Jul 2017 07:41:51 GMT
Content-Length: 42http://www.suparc.com/arcplat/proxycfg.xml

返回一个urlhttp://www.suparc.com/arcplat/proxycfg.xml.
然后紧接着第二个HTTP请求获取游戏公告，

GET /arcplat/news/notice.txt HTTP/1.1
Host: www.suparc.com
Accept: */*

前两个从时间上来看，可能是一个顺序执行的代码的先后两部分。这第三个应该是经过了一个条件判断之后执行的吧？

GET /arcplat/update/accv39.txt HTTP/1.1
Host: www.suparc.com
Accept: */*HTTP/1.1 200 OK
Content-Type: text/plain
Last-Modified: Fri, 24 Mar 2017 09:08:51 GMT
Accept-Ranges: bytes
ETag: "8013f8407ea4d21:0"
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Sun, 02 Jul 2017 07:41:51 GMT
Content-Length: 104............ Running Ver. 2017.03.24
......... New Domain: SupARC.Com
...... Backup Domain: ARCLive.Co

返回的内容最终显示到了主界面上，可以看到主界面有一个加载的过程。从...变成了

............ Running Ver. 2017.03.24
......... New Domain: SupARC.Com
...... Backup Domain: ARCLive.Co

最后那个HTTP请求就是请求第一个包得到的url

GET /arcplat/proxycfg.xml HTTP/1.1
Host: www.suparc.com
Accept: */*

其返回的内容被程序存储为一个同名文件proxycfg.xml。这个文件每次打开SupARC都会从服务器从新下载，所以当前得到的文件就是最近一次打开SupARC下载的版本。其内容为

注意到在proxycfg.xml旁边还有一个proxyscanned.xml这个文件基本的最后修改时间跟前者差不多，可能是程序读取前者之后写入到后者的。

然后再看看那几个服务器的像延迟一样的是怎么获得的。
从前面的图中可以看出来，这三个中，跟那个218.6.8.243(福建服务器)通信的数据包最多，达到了16对(一去一回)，而另外两个每个都是5对。这个应该跟他们放在界面的位置有关。因为218.6.8.243这个服务器是默认服务器，当打开主界面时，本地程序就开始尝试与这个服务器用UDP来，而当我点击那个下拉框的时候，才会出现另外两个服务器，然后程序才会更那两个服务器发UDP数据包。程序通过时间差测将得到的延迟动态地显示在界面上。

默认服务器的16对UDP数据包

其他两个服务器的5对UDP数据包

然后我想既然suparc向这个服务器的这几个端口发包而且有回应，那我就用nmap来试一下咯，结果发现同样的命令用powershell和cmd的结果不太一样。应该是每个shell的语法不太一样吧。我明明看的是nmap的help文档啊，奇怪。

用powershell

用cmd