自从 Workflow 全面支持 Web API 以来,Workflow 的想象空间更进一步得到提升,其中一个常用的情景就是模拟登录。通过试验很容易验证得知 Workflow 在支持 Web API 的同时也能够缓存 Cookie,这给模拟登录创造了先决条件。本文将以日常生活中常遇到的最简单的站点为示例,介绍模拟登录的思想和过程。

分析

日常所能遇到的登录请求大致有三类:

  1. 完全不加验证码;
  2. 使用简单的验证码,如简单数字、文字图片输入等;
  3. 使用新型验证码,如 Geetest 和新的 reCAPTCHA 等。

第三类验证码破解的成本相当高,它以人的行为特征为角度验证访问是否机器发起,因此遇到类似滑块、点击、选择图中某某某等验证,基本上应该放弃。而对于第二类尤其是简单的数字、文字图片输入验证码,可以尝试使用 OCR 来识别图片的内容,成功率视验证码的混淆程度而定,虽然有成功的可能,但成本也比较高。一般而言,我们需要使用 Workflow 模拟登录的情景还是比较少,依我观察,最多的大概是某些 ss 站的签到。所以,我们最欣喜的便是看到第一类情况——没有验证码。下面,我们以CCCAT为例分析最简单的模拟登录情景。

第一步:分析请求包

使用的工具不详细介绍,你可以根据自己的方便选择使用电脑工具或手机工具。电脑工具很充足,而手机工具 iOS 推荐使用 Surge 和 LDSS。有一点需要高度注意的是,很多站点都使用了 SSL 加密,对于这样的情况,选用的工具一定要支持 MITM,简单的说就是能解析 https 的包。以 iOS Surge 为例,基本的分析请求包过程如下:

  1. 启动抓包,本示例还应打开 HTTPS Decryption,具体使用方法不详述;Sign-1
  2. 浏览器访问CCCAT,完成一次完整的登录;
  3. 停止抓包,到 Saved Session 浏览整个登录请求过程,一般而言能够很容易从 URL 中得知哪一个包是处理什么请求。这里,我们应该找到 /user/_login.php 的 POST 包。Sign-2

    • Request 的内容便是 Workflow 中应填写的 Request Body。应该了解,网页提交一般是 Form,ajax 请求一般是 JSON;
    • Respond 的内容是请求返回的内容,可进一步分析请求的结果。

使用的工具不同,分析的过程略有不同,但总体大同小异,归结为:「完整登录抓包—分析包地址—分析包内容」。类似的,分析签到包也是同样的过程。Sign-3

第二步:获取网页信息

为获取如签到时间、使用流量等信息,我们需要解析网页源码。与前分析登录包不同,从一个网页抓取目标信息只能从其源码入手,因为这些内容一般都是 php 动态生成的表现为拥有若干 html 标签的源码,请求返回的便是生成后的源码。分析过程与前一致,但整个过程略有不同,归结为:「完整访问抓包—分析包地址—分析包内容—调试正则表达式」。这里特别讲一下正则表达式的调试。所谓正则表达式,简单来说是一个常用的、广泛的、用以提取大片文本中特定内容的技术,很有必要学习,但非一句半篇能够解释清楚。有心了解你会发现,正则表达式原理虽然很复杂,但其用法很简单,这里推荐正则表达式30分钟入门教程一文作为敲门砖,基本能够应对少量的匹配工作。以获取 CCCAT 签到时间为例,介绍简单的 ss 站信息提取模版:Sign-4

  1. 浏览网页源码,定位到自己想要的信息,联系周边内容发现目标信息的特征(如特有标签、固定文本等);
  2. 目标信息前有固定文本和标签上次签到时间:<code>,后以</code>结束,因此简单的反向匹配模版为

    (?<=上次签到时间:<code>)[^<]+

不同的网页不同的信息有不同的特征,即便是相同的特征,也有不同的正则表达式可以实现相同的功能。简单的反向匹配模版只要求你能找到目标信息前的固定文本,是最简单直接的表达式之一。它的使用情境很单一,但一般 ss 站都是那么些模版,所以在本例基本能够完成任务。初次尝试建议复制整段源码,在独立的流程中尝试 Match 想要的信息,直至成功获取目标信息再应用到原流程中。更多关于正则表达式的内容请自行学习。

第三步:逻辑梳理

通过前两步的处理,我们已经完成了三个独立的模块:登录、签到和信息提取,下一步我们便可以开始制作 Workflow 了。既然称为模拟登录,自然是依照正常访问的逻辑过程逐步完成登录和访问,顺序必然是:「登录—签到—信息提取」。有一个逻辑过程我们容易忽视,就是假如已经完成登录,在 Cookie 过期之前都不需要重新登录,此时顺序简化为:「签到—信息提取」。回想自己在使用浏览器访问网页的时候,每次都需要重新登录吗?同时,iOS Widget 内存分配十分寒碜,想必大家都试过 Workflow Widget「无法加载」或「Unable to load」吧。所以以 Widget 方式运行的 Workflow 从来都应该宜简不宜多,尤其是 Get Contents of URL 这一内存占用大户的 Action,能少则少。这里顺便解答一下有些人总问「为什么我的 N 合一签到流程老是跑到最后空白呢?」没错,就是因为你访问太多次 URL 内存溢出导致奔溃了,根除的方法要么精简流程,要么更换设备。梳理一下逻辑,流程就呼之欲出了,如下图详述。Workflow 详细制作过程不叙述。Sign-5

说明

  • 有些人简单的以为不同站只是更换站地址那么简单,那只是因为大多数 ss 站都是使用那么些模版建站而已,本质上还是应该遵循上述步骤分析其中的同与不同。
  • 签到作为免费站的使用条件,本人不提倡大家盲目签到。平心而论,每天签四、五个站是真的需要用这么多站吗?还是因为它免费所以才去签?如果真正只用到其中的两个甚至更少的站,那是极大的浪费免费资源。再者,未免会有别有用心的人去恶意利用机器签到来抢占资源。所以作为站长,我的愚见是:尽可能增加验证码。验证码的作用我就不必在关公面前耍大刀了,尽管 https 站点使用 Geetest 需要额外的开销,但是也应该考虑其它形式的验证码,尽可能降低被利用的风险。
  • 本文只是通过一个简单的示例介绍一般的分析过程,实质上遇到的其它情况可能更复杂,不局限于验证码这一种校验,可能需要伪装请求头等信息,这些情况大家在慢慢熟悉的过程中就会学习到了。万变不离其宗的是,分析的过程不会改变。

附件

Workflow:CCCAT


如有问题,欢迎留言或邮件咨询