中国期刊服务平台逆向(瑞数6+补环境)

一、声明：

  本文仅供参考学习，请勿用于其他途径，违者后果自负！

二、前言：

        目标网站：某期刊服务平台

        目标接口:   如下

'aHR0cHM6Ly9xaWthbi5jcXZpcC5jb20vUWlrYW4vSm91cm5hbC9Kb3VybmFsR3VpZD9mcm9tPWluZGV4'

        逆向前提:清楚了解瑞数6加解密流程，与对代码混淆后补环境的方法。
        注意：本次逆向仅基于瑞数6文档逆向提供方法思路，不进行后续爬取操作，遵守目标网站的爬虫规则，对任何网站切忌大量异步爬取(危害堪比ddos)。

三、入口定位：
        首先，我们要知道瑞数并不是一个加密算法，而是一家安全公司，其中部分业务就是为国家政府等行政机构对应的网站做反爬，6呢就是反爬系统更新到第6代。而关于瑞数具体的加解密流程这里就不过多说明，想要了解的，可以自行搜索。
        好，这里话不多说开始我们的第一步，入口定位。在我们抓包之前，如果你之前访问过该网站，请根据下图清理掉登录缓存的cookie信息。

        当你第一次访问抓包时，如果跟下图一样有两个长相相同，颜色不同的包，上一步操作可以省略，如果没有第一个包(状态码为412)，则需要做完上部操作，再继续。

        到这里，有的师傅可能就会有疑惑，同一个页面文档为啥会有两个请求地址一模一样的包，而这就是瑞数的独特之处，这里粗略解释一下原因。瑞数加密过的网站跟其它网站通过请求参数或响应数据加密有所不相同，它需要请求者携带两个cookie，如果满足则会返回一个html页面，利用python通过标签解析的形式，拿到相应数据。

        而第一个状态码为：412的请求包就是拿到两个cookie的关键，第二个请求包则带着第一个包的两个cookie向服务器发出请求，服务器响应得到上述内容，即一个html页面。


        观察上述两个请求包对应的cookie，我们发现第一个包只有一个以6开头S结尾的cookie，我们叫它cookie1，但到第二个包除了有6开头S结尾的以为，是不是还有一个以6开头T结尾的cookie，我们叫他cookie2。在你了解瑞数后你就知道，两个cookie都是由第一个包生成，cookie1是第一个包向服务器发出412请求，服务器返回的。cookie2则是在本地经过他的一套流程生成的。
        总结一下：我们要想拿到数据，得先拿到第二个包响应返回的html页面，而携带数据的html页面得由第二个包带俩cookie作为请求参数发出请求获取。cookie1是服务器返回的，我们直接发个请求就可以拿到，那关键是不是cookie2。而cookie2是本地生成的(这里就跟其它加密有所不同，真正加密代码，它是在eval激活的一个虚拟环境中加密的，是在内存中跑的，本地搜索不到)，即js脚本生成的。那我们现在是不是要找到当页面请求加载时第一个执行的js脚本。
        这里我们点击源代码，找到事件监听器断点，把脚本勾上，这时我们刷新页面，它就可以帮我们断住第一个执行的js脚本跟后续的js脚本。
 

        下图中，三个红箭头标注的位置，就是cookie2生成的地方，也是瑞数逆向的关键地方。这里我们先解释一下各个部分的含义：
        第一部分meta标签，重要的是那个content的值(这个值是动态的，每次请求都会变化)，在后续eval执行第二层代码时使用到。
        第二部分，<script>标签内的一段js代码，为了有区分度，就暂且叫它ts代码。会被下面自执行函数解密生成后续eval执行需要的js源码。
        第三部分，<script>标签的src属性对应访问到的js脚本为一个自执行函数(每次请求首页都会动态变化)，在vm虚拟环境中使用。

         现在想想下一步要干什么？是不是让自执行函数，解密上述红线$_ts.cd的内容，而不是看不懂的一串字符，所以我们继续执行脚本。
        通过script标签的src属性跳转到如下js，自执行函数启动后，我们要获取的$_ts.cd的解密内容是不是还不知道在哪？而通过对瑞数逆向流程的了解，我们最后生成cookie的代码是通过eval激活自执行函数解密$_ts.cd的值从而生成的。而了解vm跟eval的师傅都知道，eval有个.call的方法，这种写法是合法的，eval.call(window, "alert('hi')");这里解释一下，只有当eval的call方法被调用后，"alert('hi')"，引号里面的内容才会被执行，下述代码对eval做了混淆直接搜搜不到，所以我们可以试着搜搜call，看能不能找到。
        发现找到两个，一个明显不是调用call方法，下述就看着很想，所以我们加上断点，让它执行到这一步。
        发现这跟我们刚刚想的结构一样，而下图二引号里的函数就是真正加密cookie的函数
        而引号里面的内容要想被执行，是不是eval的call方法被调用，所以，现在我们是不是要单步执行。
         发现进入了一个VM4027的虚拟环境中，了解vm虚拟环境的师傅都知道，这段代码是在浏览器内存跑的，所以这也解释了为啥本地搜索不到。只有当eval的call方法被调用才能看到，而这里面的代码就是我们补环境出错时，要来查找的地方。四、逆向解密：   
        现在我们是不是要把上面提到的三部分，copy到本地，进行补环境，得到cookie值。但这里我们要注意，上述三个部分的内容是动态变化的，这就导致，如果你不固定，那么你在补环境出现错误，去浏览器找对应位置的时候，就会出现查不到的问题。所以这里我们需要本地替换我们刷新页面的第一个脚本内容(替换步骤就不再说明，不明白的百度搜索)，保证后续补环境的顺利。
        这里切忌，在你从头开始本地替换的脚本文件一定为下图样式的，即第一次412请求返回的html源码，而不是替换第二次请求的可以看到具体文档内容的html页面，那要怎么做呢？跟前面说的一样，清除cookie，重新走完上述的流程即可。





        同时注意在代码复制到本地的时候，切忌不要格式化复制，即，不要点击箭头处复制内容，因为在瑞数6会对代码的格式化做校验，习惯性的跟浏览器保持一致。

        准备工作做完，接下来，是不是就到了重要的一步，补环境。

五、补环境：
        ReferenceError:window is not defined

        这次报ReferenceError: document is not defined，到这里我们可以上一下代理，监控一下对象与方法。
        缺少location对象，去浏览器控制台拿真实环境。
        我说从后往前补的，哪里报错补哪里，属于偷懒的做法，因为好多对象属性为undefined，补不补都不重要，补完location发现还是报locatiion，说明前面有地方没补完整，导致虽然location环境没问题，依然进行不了下一步，所以我们往回找代理信息，发现是window对象的top属性没补。

        在window环境中top跟self也代表全局对象，即node里的global意义相同，所以一起补上。同时要注意写法，是将globa赋给其它三个对象！
 
        出现新的问题，说明上一个问题解决。又出现新的错误，但出现的错误，_$jA[_$kJ[49]] is not a function，虽然它提示了，这不是一个方法，但我们并不知道_$jA[_$kJ[49]]是啥，明显做了混淆，目的就是不让我们知道。前面一篇文章，到补环境是明文的，但当时我就说了这种混淆的情况，说了两个解决办法。因为我这里对document对象加了代理，所以我们往上翻，就能看到代理提示的最后一个缺失的方法就为我们要补的。

        但如果仅仅这样，当下确实可以按提示，是document对象下的createElement方法缺失，但后续如果代理也监控不到呢？是不是还得根据提示，去我们固定替换的源码里面查找，而那样找就相对不够清晰，不能找到一开始出错的位置，为什么这么说呢？因为对象里面有方法，方法里面有属性，属性里面还可能套方法。如果你从中间开始找，如果你对前端标签不熟悉，是不是补起来就很困难，所以这次我选择直接从混淆的代码入手。
        copy混淆的函数方法:_$jA[_$kJ[49]]，去浏览器搜，果然可以搜到。(根据前面说到的，这个VM575里面的才是真正生成加密函数的地方，而这段代码是eval通过.call方法在vm中被调用的，存在浏览器内存中，不清楚的可以会看前面提到的)。
        好，接下来，这里有7个，我们是不是，一个个打上断点，鼠标悬浮，看看是不是跟我们代理报的那样。

        发现确实跟代理提示的一样，开始补环境。

        补完环境后是不是加一个打印，看它又创建了哪些属性。

        再结合浏览器，我们也能发现接下来要补的是div属性。

        当我补完，发现代理是不是跟我刚说的，不再继续吐缺失的内容了。

        所以我们继续根据它的报错去浏览器搜索。

        发现是不是我们刚才打断点的下一行，在下一行下断点，让它断在下面一行。

        发现是不是，div下又有个getElementsByTagName方法。这里是不是就体会到从头开始去浏览器搜混淆代码的好处了？不然你光看个div标签是不是很难知道他是哪个方法下的，当然对前端了解的师傅也能猜出来，但这样是不是就省时省力了？
        好，继续开始补环境。


        这是个获取元素的名称的方法，一样加上打印，看他调用了那个元素。
        打印发现是i元素，但不知道它具体的值是多少？？

        所以，这里还是得看源码，这箭头位置打上断点，让它执行到这个位置，结合控制台打印我们发现_$_C[69]就i标签，而它们整体的返回值为空[]。

        当我们补完环境，发现出现新的错误，而这正是我们想要的，说明上一步补环境没有问题。

        结合代理其实我们就可以看到哪里缺失环境，但就像前面提到的，保不齐哪里代理就监控不到了，所以我们两手看，通过代理看我们去浏览器找到地方对不对。

         通过搜索发现，如果_$db[_$ce]这样搜发现有40个，其实有点多，但我们通过报错信息，发现说_$db[_$ce]不是一个函数，所以我们在_$db[_$ce]后加个(，即：_$db[_$ce](，发现就只有12个，这其实也是个技巧，需要你不断练习摸索出来的。
        接下来是不是我们就要继续在那12个里面找是方法的？
        发现这里有个有个window对象下的setInterval方法，而这个方法，如果你要结合python拿到第二个请求里的文档内容，这个后续就要加上。但这个方法对你拿到cookie值没有影响，后续会说明，而且这个函数并不是这里需要补的，其实我们结合代理也知道我们要找的，是document对象下的getElementsByTagName函数，防止有的师傅复现说你为啥把这个函数忽略了。所以继续找。
        这不，就找到我们需要的，这里我把混淆的内容跟最后的返回值，都在控制台打印，方便大家查看。

        到这里其实就明了了，是document对象下的getElementsByTagName里的script属性，整体的返回值即script的值为[script,script]

        结合代理，我们也能看到，跟我们上述说的其实一模一样。所以继续补环境。

        出现新的错误，这里代理又监控不到了，继续找源码，其实这就是上一步那12个地方，继续往后找script里面又调用了哪些方法
        发现是少了getAttribute这个方法。而它又获取了r属性，返回值为m。

        加上打印也印证了，找的位置没问题。开始补环境。

        如果大家对替换的那个html源码还有印象，不难发现，其实就是获取第一个script标签下r的属性值m。而前面返回的[script,script]在这里也得到印证，有俩script标签。

        出现新的错误。

        但我们并不知道是哪个对象调用的，所以，我们给script也加上代理，发现它说是script标签缺少parentElement方法，但在这个跟报错出现的removeChild又不相同。

        到这里，如果你熟悉前端标签属性，或者懂英语，其实你试着理解标签含义，发现说的是script标签的父亲元素未找到。结合前面第三张图，你会发现它的父亲元素不就是head标签吗？而head标签正好又一个removeChild方法。
        但这里可能有人会说，这是侥幸，正好让你狗运撞到了。所以，这里我还有一种思路，既然前面我们补document对象的内容，中间搜出来12个相关项，而script对象的头的头是不是也是document，所以我们继续一个断点一个断点这样往下找，看看能不能找到？？
        必然，功夫不负有心人。找到了，跟我们前面猜想的一样。
        当我们补完removeChild方法后执行，发现出现新的错误，说明我们没有必要再将继续补它后续的值，当然我们知道，它要移除的值为script。
        我们把head加入代理，结合代理与源码，发现是attachEvent，addEventListener方法缺失。

    出现新的错误，去源码搜混淆代码找到相应位置，结合代判断是不是对应位置。


        果然，就找到了相关内容，相关信息在看控制台，跟代理检测的一样，位置确定，继续补环境，如果值为FbkwzLN5XOx0，是不是就返回meta对象。

        补完发现，代理输出的是如下内容，FbkwzLN5XOx0，再结合源码跟第我们替换的html源码，我们知道是不是就是meta标签下的id属性的值。跟上述做的判断相同。继续补环境，同时给meta对象上代理。


        还是一样，两步走，结合代理信息，去看源码。


        发现跟代理信息相同meta对象的getAttribute方法获取“r”属性，值为m。

        打印的信息跟我们源码打印的相同，继续补环境。

        报错信息还是之前那里，所以看代理信息，两个结合着看。发现缺少parentNode值。

        但这里我们不知道具体提要补的值，而报错的地方又没给我们混淆的代码，也就说不好在源码中找到相应位置。
        所以我选择先给他赋一个空对象，如果出新的错误，说明这里这样补就没问题，否则就根据新错误继续往下补。

        果然，出现了新的错误，但找到浏览器源码，其实就是上述错误的具体要补内容。发现跟前面script里的parentElement属性对应的方法相同，即：removeChild()。

        所以，直接这样补，其实跟前面一样看替换的html源码，也不难理解script跟meta的父亲元素都为head，补完发现出现新的错误。

        又是meta下的content属性未找到。而content的值不就是之前说的第一部分里那个非常重要的值吗？

        补完发现，这里依旧报错，这里有个打印提示。继续补环境。

        去浏览器控制台打印，发现值为[]

        补完又有新错误，继续补环境。

        补完继续报错，继续补环境。

        在你补完document的两个环境后，cookie2的值就出来了，大功告成！
        如果你想让后续输出停下来，输入下面两行代码，其实这就是个循环定时器一样，一直执行，制空就解决了！

        五、利用方式：
        这里简单说明，结合两个cookie，通过第二个请求地址，发送携带相关参数的请求，即可获取html页码，里面内容即为首页文档内容，配合python通过标签解析，即可获取相关数据，这里就不进行演示，有兴趣的师傅，可以自行尝试！
        最后，感谢大家观看，后续也会持续更新较好案例。如有其它问题可以评论区交流。
        ​​​​​​​