一文带你搞懂 JSRPC 到底是个啥
大家好，在JS逆向过程中，很多时候会因为复杂加密逻辑或反调试机制而陷入瓶颈。而 JSRPC 技术通过远程调用浏览器原生函数，可绕过逆向分析直接获取加密结果。本文将从 RPC 技术原理切入，详解 JSRPC 的实现原理。
RPC 是什么
要想解释 JSRPC 是什么，首先要先解释一下 RPC 是什么。
RPC（Remote Procedure Call）允许程序像调用本地函数一样调用远程服务器上的服务或者方法，但是在调用它的时候，具体的执行逻辑在远程服务器上面，远程服务器负责计算或者处理，完成后返回相应的结果。
RPC 主要由两部分组成：接口和协议。
接口主要是定义这个方法是做什么的，和定义一个方法一样，它会有方法名，入参和出参。
1 | # 接口示例：计算MD5加密 |
协议用来将调用方和被调用方连接起来，并且进行数据传输，具体的协议主要由框架来决定，常见的 RPC：
- grpc 使用 http2 协议，使用 Protobuf 进行序列化
- Apache Thrift 使用 http 或者 TCP 协议，使用 Thrift Binary 进行序列化
- Dubbo 使用基于 TCP 的自定义协议，支持多种序列化方式
- JSON-RPC 就是常见的 http 接口，使用 http 协议，使用 JSON 进行序列化
RPC 调用流程
一次完整的RPC调用包含以下阶段：
- 客户端序列化：将参数转换为二进制流
- 网络传输：通过协议通道发送至服务端
- 服务端反序列化：还原数据并执行函数逻辑
- 结果回传：逆序上述过程返回响应
在调用方法时，请求会被序列化后通过网络传输给另一个服务进行计算，计算完成后通过原路径返回计算的结果。在外界看来，计算结果就是调用的函数返回的。
在整个调用流程中，虚框线中的内容是可插拔的，理论上来说可以用任何协议和序列化方式来传输所需要的数据。
JSRPC
说完了 RPC， 现在来说说 JSRPC，JSRPC 其实就是在 JS逆向中用到了 RPC 的思路来实现远程调用，从而避免逆向操作，可以直接调用原始的加解密方法。
如图所示，在 JS逆向时，如果遇到比较复杂的 JS 代码，或者 JS 代码中有比较复杂的反调试逻辑暂时搞不定时，就可以将加解密接口通过 JSRPC 暴露出来直接调用，这样可以避免去逆向复杂的加解密逻辑，也不用管复杂的反调试逻辑，只要能找到加解密接口，即可实现远程调用。
JSRPC 协议
之前提到了 RPC 中协议和序列化方式都是可插拔的，但是在 JSRPC 中，情况有点不一样了。
由于浏览器的特殊性，它不能作为服务端提供服务，或者说它不能监听一个端口来给外部提供服务。但是在正常的 RPC 调用时，被调用方一定要暴露某个端口才能将所提供的接口暴露出来，那如何解决这个问题呢？
那既然浏览器不能作为服务端，那就让它作为客户端，我们再新建一个服务端让它来连接，连接成功以后让服务端先发起请求，浏览器来执行具体的计算逻辑就好了。
那什么协议可以实现上面的方案呢？可能有的小伙伴已经知道了，那就是 websocket 协议。websocket 是全双工通信，任意一方都可以发送请求和处理请求。
只要让浏览器连接到我们自己的服务端，连接成功后，外部向服务端发出 RPC 请求，服务端将请求通过 websocket 发送给浏览器，浏览器执行计算逻辑，将结果通过原路径返回给服务端，服务端正常返回结果给外部调用，是不是很像前面提到的 RPC 调用了？是的，这就是 JSRPC 的调用流程。所以说，在 JSRPC 中，一般常用的协议和序列化方式就是 websocket 和 JSON。
总结
JSRPC 利用 RPC 的核心思想，通过 webSocket 协议将浏览器中的 JS 函数（如加密方法）暴露为远程接口，使外部程序无需逆向分析即可直接调用。其本质是让浏览器执行原生代码，通过接口“透传”参数与结果，既绕过了反调试机制，又避免了重写加密逻辑，可以大大降低逆向的工作量。感兴趣的小伙伴可以尝试一下，下篇文章也会讲到 JSRPC 框架和实际操作方法。
本文章首发于个人博客 LLLibra146’s blog
本文作者：LLLibra146
更多文章请关注公众号 (LLLibra146)：
版权声明：本博客所有文章除特别声明外，均采用 © BY-NC-ND 许可协议。非商用转载请注明出处！严禁商业转载！
