最近某里滑块更新到227，导致之前的226代码过不去了，于是得排查下原因。在这之前，想着先把混淆代码还原下，这样更方便调试。

之前虽然还原过221，但现在已经更新到227了，得花时间写很多插件，好在可以站在巨人的肩膀，蔡老板的226还原文章就是一个很好的参考，蔡老板的星球里有很多现成的插件，直接拿来用就完事了。

还原的过程中遇到两个问题，一个是自执行函数作用域的问题，另一个是假节点。秋裤佬写过还原出现作用域异常的解决方案，自执行函数作用域问题迎刃而解。假节点就是条件语句里会有很多数学计算，但其实值永远为true，仔细观察它们的特征后写插件解决即可。每次执行完一个插件后，都替换原文件然后在网站上测试代码是否正常，保证还原的准确性。最终的效果是核心代码合并后只有一个case。还有一些字符串常量没有还原，得花不少时间写，等后续有时间了再写插件还原。

代码还原后，我们就可以调试了。先把代码放到补环境框架中跑一跑，token能生成，但过不去，于是只能慢慢调试，这次调试才发现某里滑块混淆代码的厉害之处，它会根据传进来的参数执行不同的流程，调试起来依然很费劲，不愧是国内混淆js的天花板。对比核心数组和浏览器之间的差异，慢慢调试，最后发现增加FocusEvent, 然后第13位固定写死就能跑通了。这次更新和226相比核心代码几乎没变，只是数组位置变了下，然后轨迹校验变严格了，问题不大。

在APP抓包入门中，我们有说过有一些复杂的APP，抓包软件是抓不到HTTPS包，这其中的原因有很多，比较常见的如SSL Pinning，还有双向认证，还有一些情况是不走HTTP协议。这里我们来解决最常见的SSL Pinning问题。

SSL pinning简单来说就是证书绑定，SSL证书绑定，即客户端内置了服务端真正的公钥证书。在 HTTPS 请求时，服务端发给客户端的公钥证书必须与客户端内置的公钥证书一致，这样请求才会成功。而使用抓包软件后，抓包软件的公钥证书和客户端内置的公钥证书不一致，这样请求就会失败。

网上有很多解决办法，其中如DroidSSLUnpinning, r0capture, 这里我们使用DroidSSLUnpinning来解决这个问题。

查看DroidSSLUnpinning的使用方法，进入ObjectionUnpinningPlus目录，使用hooks.js脚本即可。需要安装frida使用。frida脚本使用方法有两种，一种attach, 一种spawn。com.example.mennomorsink.webviewtest2 是应用包名，可使用frida-ps -U命令进行查找报名。也可以使用jadx反编译工具，在资源文件AndroidManifest.xml中的第一行，找到package字段即可。有一些frida版本会提示–no-pause无法使用，去掉这个参数即可。

• 使用方法1 attach : frida -U com.example.mennomorsink.webviewtest2 –no-pause -l hooks.js
• 使用方法2 spawn : frida -U -f com.example.mennomorsink.webviewtest2 -l hooks.js –no-pause

至于r0capture的使用，可以查看r0capture仓库里的使用文档。这个库功能更强，但要配合WireShark使用。

之前有段时间，Node服务的可用性从99.99%跌到了99.3%，502错误明显增加，于是得排查下原因。

在本地打包镜像，启动容器后，把并发打上去，发现PM2守护的进程会时不时重启, 日志如下

1
2
3

PM2      | App [server:1] exited with code [0] via signal [SIGKILL]
PM2      | App [server:1] starting in -cluster mode-
PM2      | App [server:1] online

仔细观察后发现是内存到达上限后会把进程杀死，重启。估计是内存泄漏的原因，一时半会找不到原因，于是只好祭出开始佬写的内存回收插件，加上插件之后内存急剧下降，服务稳如泰山。带来的副作用是内存GC存在时间开销，整体响应时间比原先的服务慢20%，这就得做个取舍。

把插件发布到测试环境后，再次测试，一样稳如狗，于是发布到线上环境，结果还是存在很多502错误，想不到错在哪里。联系网关服务的开发一起排查。网关服务的开发推测是keepalive时间设置的原因。因为请求先到网关，再到服务中，而网关设置的keepalive大于服务设置的keepalive时间时，就会出现网络连接不可用的情况，于是就会认为服务502。

在Express中keepalive时间默认是5秒，改一下keepalive时间即可，配置如下。

1
2

const server = app.listen(port);
server.keepAliveTimeout = 70000;

最终服务可用性达到99.99%，达到目标。

在Node服务高并发高可用之容器化与负载均衡中，我们已经解决了QPS如何满足用户需求的问题，这一篇我们再讲讲限流，以及如何使用限流来提高我们服务的可用性。在使用node-rate-limiter-flexible服务限流中，已经提过一次限流，这里我们继续说一说。

限流有很多用途，比如很多道友会提供接口给人用，为了限制对方调用的调用频率，此时就可以加上限流功能。

比如有个网站每秒只支持100个人访问，结果有同时有10000个人去访问，如果没有限流，可能网站就会奔溃了。

比如一个接口每秒只能支持10QPS, 但调用方因为突发流量，每秒调用100次，那这时候第10次～20次请求就要1～2秒才响应，第20～30次请求就要2～3秒才响应，第90～100次请求就要9～10秒才响应，导致接口超时严重，运维就会找过来了。

如果加上限流功能，这上面的问题就都解决了。当访问数量超过支持的数量时，就直接告诉对方，你被限流了，这样能保证自己的服务不会奔溃。

Node里有很多限流模块，我这里使用node-rate-limiter-flexible，它不需要引入额外模块如Redis等做限流，只是在每个Node进程里做限流，满足我的需求。一个简单的配置如下

1
2
3
4
5
6
7
8
9
10
11

const burstyLimiter = new BurstyRateLimiter(
  new RateLimiterMemory({
    points: 3,
    duration: 1,
  }),
  new RateLimiterMemory({
    keyPrefix: 'burst',
    points: 5,
    duration: 5,
  })
);

它是用了两个限流配置，第一个的令牌用完了，就会去用第二个的。如下就是一个QPS是4，支持突发流量到8的配置，相当好用。第一个配置每一秒生成3个令牌，第二个配置每5秒生成5个令牌，那么5秒内就一共可以生成3 * 5 + 5 = 20个令牌，相当于这5秒内的QPS是4，而它的突发流量是8，也就是第一秒内如果进来8个请求，它也不会触发限流。

在服务高可用方面，除了限流，还有熔断，服务降级，我也只听过，没用过。我这里只使用限流功能就够了，其它就不管了。

在Node服务高并发之PM2使用中，我们介绍了如何使用PM2将单台机器上Node服务性能最大化，这一篇我们讲一讲当单台机器的QPS无法满足需求时，如何解决。

其中一个解决办法是提高单台机器的CPU核数，比如之前是2核(即2C)的，提高到4核，再不够提高到8核，再不够继续提高。虽然这也能解决问题，但这意味着这个服务是单点的，假设服务器宕机了，服务就挂了。

这里我更赞成使用多台服务器，比如原先单台需要32核服务器，我们可以分成申请8台4核服务器。这样当其中一台服务器宕机了，还能有7台服务器提供服务。这里我提一句，有道友申请4C/8G的服务器用来做Node服务，大可不必，一般Node token生成服务都是CPU密集型，内存占用不会太多，有这个钱还不如申请两台4C/4G的服务器。

现在我们就需要涉及到如何讲代码发布到这多台服务器中，其中一个办法先到每台服务器上安装需要的Node环境，然后再上传代码。另一个更好办法是容器化，例如使用Docker技术，将需要的Node环境和代码一起打包到镜像中，然后把镜像上传到服务器中。

既然涉及到多台服务器，就得加上负载均衡，让请求均匀分发到各台服务器上。简单点就用Nginx做负载均衡，还有一些更复杂的API网关如Envoy, APISIX等等。

具体如何使用我也没有深入了解，毕竟公司有现成的一套容器化和API网关，还有动态迁移(容器所在的物理机宕机时，在其它物理机重新启动一个新容器提供服务)，动态库容(CPU负载过高时，扩容)等功能，直接用就完事, 美滋滋了。

最近和yd验证码看对眼了，于是决定锤一锤它。在锤它之前先看了十一姐和y小白的文章，再参考小白佬的例子，就开始干活了。具体要搞定哪一些参数，直接看十一姐的文章好了，十一姐的文章目前是我看到的最详细的，实在是太细了，我这里就只讲讲我遇到的一些坑点。

代码有一万多行，ob风格的混淆，但因为蔡老板的星球一直提供ob解混淆脚本的原因，我已经是个ob废物了，用脚本跑了下，没有还原出来，估计是版本不一致的原因，于是只好硬刚了。在掏出补环境框架之前，先尝试手动抠了一份生成cb参数的代码，虽然生成的参数能用，但还是有些麻烦，于是决定用补环境来解决。先拿官网的例子练练手，因为官网参数会少一些，会更简单。站在大佬们的肩膀上，很快就搞定了。

然后去测试具体网站，这时就开始遇到问题了，先是生成的fp参数不能用，慢慢排查后才发现location还用的是官网的地址，改过来后就好了。然后又遇到个现象，能获取两次验证码，第三次就不行了，隔一段时间又能获取两次验证码，第三次就不行了，百思不得其解，问了一圈道友都没有遇到过这种情况。于是只好一个个接口，一个个参数慢慢排查，排查了好几天，最后发现是验证码校验接口cb参数没有动态生成，就离谱。

明明记得这个参数改成动态生成了，但事实就是没改，估计是记忆错乱了，把改过官网的代码记成具体网站了。除了这个问题，全程再没有遇到其它坑点。

像这种代码是固定的网站，是真的好搞，补环境也是真的香，即便现在所有接口都跑通了，我都不知道它这混淆代码写的都是些啥。

最近十一姐和时光佬搞了个星球，值得一看。

两年前，去了某里的同事发来一个滑块，是他们所在的团队维护的，让我试试能不能通过校验。但那时我对补环境还不是很熟悉，某里的控制流也没能还原，硬刚太累了，业务上也没有需求，就只好放在收藏夹中吃灰。

去年学习了蔡老板的9大节点合并算法，能还原221版本的滑块代码，但代码量实在是太多了，一个case里塞进去2万多行代码，没有耐心看下去，于是继续吃灰。

今年，某里滑块已经有人均的趋势，圈子里已经卷到飞起，00后已经开始乱杀。自己业务上也没有前些年紧张，于是可以腾出手来搞一搞。此前已经能生成226的签名，但就是过不去，也不知道错在哪里。最近正好时光佬也在搞滑块，开始佬也写了篇分析226的文章，在他们的帮助下很快就搞好了普通226滑块。此时我才知道，上一次生成226签名时就差临门一脚。

真正的挑战来自于某里系旗下网站的滑块，这些滑块圈子里一般称之为x82y。虽然代码和226是一样的，但校验更严格。此时才真正开始看226的代码，和浏览器对比，大大小小有35处不一致的地方，只好一个一个排查，排查的过程中，才知道自己的补环境框架的缺陷，才知道自己的补环境方法不合理的地方，是时候回炉重造了。好在目前应付普通226滑块就够用了，x82y等有需要了再慢慢搞了。

其实不补环境，扣算法的话，也是可以的，某里滑块离谱的是代码是固定的，能够通过AST还原代码的话，搞起来容易很多。

一直都只在国内反爬圈里打转，某里滑块是迄今为止遇到的检验最多的js反爬了，如果想测试自己补环境框架的强度，某里滑块是首选。

和道友交流的时候，发现他对Node服务高并发一知半解，于是和他讲了下自己的理解，他说受益匪浅，于是写文章记录下来，希望能帮助到其他人。

当我们用 Express 搭建好一个 token 生成服务给其他开发调用时，我们就要开始考虑服务的性能，考虑服务的并发能力。同时也要考虑服务如何方便部署，方便更新程序。而由于 token 生成服务都是 CPU 密集型程序，所以只能通过提高进程数，提高 CPU 核数来提高并发能力。

刚来公司的时候，看到接手的 token 生成服务是这样部署的，在连续的几个端口中，比如5000，5001，5002，每个端口用 Node 启动一个 Express 服务，客户端调用的时候，随机取其中一个端口访问。服务需要更新的时候，得一个一个 Node 进程杀死后再重新启动，过程很不友好。

正好之前做过一点前端开发，前后端分离时用到过 PM2 来管理Node进程, 于是将这些服务都用 PM2 来管理，并在全组范围内推广使用 PM2，现在我们所有的 token 生成服务都用 PM2 来管理，就挺好。

PM2 很好用的一点是可以设置进程超过一定内存后就重启，通过配置 –max-memory-restart 参数即可实现。这个功能就很实用，因为 JavaScript 的闭包使用真的很容易内存泄漏，想找到原因不容易。为了不影响服务器上的其它进程，得不断重启Node进程。

单台机器上，CPU核数和进程数一致，此时并发性能最高。如果这样了还不能满足业务需求，只能堆机器，在多台机器上部署。

wasm补环境初体验

最近看到群里在讨论，y小白也写了篇相关的文章，于是也想试试。wasm 即 WebAssembly，这还是第一次遇到了。

放在补环境框架里跑一跑，就遇到 vm2 读取 wasm 文件的问题。具体是这样的，在 Node里先把文件加载进来后，在传到 vm2 沙盒里时，一般都是通过 sandbox 对象传入。代码如下

1
2
3
4
5
6
7
8

wasmCode = fs.readFileSync('test.wasm');
const sandbox = {
    wasmCode: Buffer.from(wasmCode).buffer,
}

const vm = new VM({
    sandbox: sandbox,
});

然后 sandbox 会被 proxy 代理了，此时发现无法使用 WebAssembly.instantiate 来实例化 WebAssembly 代码。查看 vm2 源码就会发现代码里会对sandbox进行操作。目前只想到通过修改 vm2 源码的办法来解决这个问题。这到时候发布啥的就会麻烦一些，需要单独打Docker镜像。

解决这个问题后就简单多了，缺啥补啥就行了，补出来的token直接就能访问。估计现在还是初级版本，还在持续更新中，目前没有什么特别的检测点。

为了便于发布，顺便搞了个Node的版本，有了之前的 vm2 版本基础，补起来就挺顺畅的，没遇到什么困难。

唯一值得一提的是，它这个环境会根据传入的参数不同，做不同的环境检测，走不同的检测分支，这还是第一次见这种情况。整体下来并没遇到什么难点，估计后面会越来越难了，得先准备起来。

关于DOM树解析功能，本来想着套用jsdom，但jsDOM太大了，于是看jsdom底层如何实现DOM树解析，发现是使用的parse5，从parse5的相关项目中又知道了cheerio, 于是想着如何套到框架里。后来从蔡老板和风佬的补环境课程里学了一手DOM树解析后，把之前的补环境框架中DOM树解析相关代码更新了下，简化了很多代码。DOM树相关的操作如createElement, appendChild，childNodes也不再是硬编码了，框架也变得通用一些。这就挺好的，虽然执行速度上慢了一些，也不像浏览器的DOM树操作那样完备，但通用性已经大大增强。

于是拿着这个补环境框架锤子到处锤一锤，反正不用细细研究加密逻辑，花不了太多时间。锤rsvmp，把之前的服务升级了一下，简化了下代码。锤某里225，目前的情况是能生成token但过不去，估计补的不对，225主要不是刚需，就先放一放。后续有时间了，还是先锤一下某里的140才行，循序渐进，正好140有哲哥现成的AST还原代码，补不对的时候可以对着代码看一看，而225的还原没有现成的，得自己写AST还原插件。

蔡老板和风佬的补环境课程还是值得一学的。