黑盒调用场景下NPS和Sekiro的异同比较

  前段时间一直在思考NPS和Sekiro之间的异同点以及适用的场景，其实关于这个问题Sekiro的作者已经给出了很多观点，本文将从我自己的使用经验出发，整理总结一些我自己的想法

1.NPS

  用原作者的话说，这是"一款轻量级、高性能、功能强大的内网穿透代理服务器",举个例子来说，利用NPS，你可以将本地环境的服务暴露到公网环境，以达到可以通过域名或者公网ip访问的目的。当然，单纯的服务暴露将带来一系列安全隐患，为了解决这一问题，NPS也提供了例如白名单，身份验证等一系列功能。例如本博客基于solo，而solo部署在家里的树莓派中，利用NPS实现了通过域名进行访问。

  从我的使用经验来看，NPS最大的优点在于对项目的代码做到0侵入性，调用方和被穿透的目标是没有任何感知的，同时NPS也没有任何的语言依赖，只要目标项目使用的协议在NPS的支持范围内就都能够使用，而NPS已经支持了大多数流行的协议，例如tcp、udp、http(s)、p2p等。

  关于缺点，Sekiro作者的观点集中在两点，第一点是NPS对于客户端的状态没有更加细致的感知，仅仅停留在心跳阶段。第二点严格来说不能算是NPS的缺陷，由于如app签名计算等调用场景黑盒特性，NPS必须去配合另外一套server框架来使用，在xposed环境下用的比较多的是Nanohttp，其本身就是一个精简的demo，如果没有优雅的二次封装，那么应对高并发本就是无稽之谈。

  由于NPS的设计初衷本就不是为了黑盒调用，所以其设计上并没有对端口复用做过多考虑，这里需要指出文档是NPS使用文档上提出的端口复用概念其实是针对NPS本身，而不是配置规则所占用的端口，因此在大规模群控场景下，NPS是不适用的，首先是因为端口数量有限，其次尽管可以通过局域网ip来替代localhost，通过webapi来替代手动配置规则，但是这毕竟还是需要额外的代码实现。

基于以上，总结一下NPS的使用场景

1. 小规模的黑盒调用
2. 无法注入sekiro客户端的情况，例如ssh、远程桌面等
3. 需要其他协议支持例如udp、p2p等
4. 服务暴露需要做身份验证（当然这一点sekiro也能做到，只不过需要自己去实现）

2.Sekiro

  相比较于NPS，sekiro是一套专门服务于API服务暴露的框架，其中C端和B端通过socket长链接来通讯。在黑盒调用进行签名计算的场景下，C端往往可以注入我们自己的代码，因此Sekiro客户端的部署就变得尤为便捷，Sekiro官方做了Android和Js（浏览器）的实现，只需要短短数行代码便能够进行客户端的API暴露。
我们可以将Sekiro理解为一个颗粒度更细的内网穿透，它的作用范围仅仅在C端本身，而NPS则是整个局域网环境，由于C端注入了我们自己实现的代码，那么对于C端的各种状态感知可以变得更加细致，所以Sekiro在大规模群控场景下有着天然的优势。

  除此之外，Sekiro对于js端也有实现，使用起来也非常方便，使用见示例，这一特性使得Sekiro可以随意劫持浏览器来作为黑盒加解密的工具，在AST控制流混淆日益普遍的今天可以称得上降维打击了。

总结一下Sekiro的适用场景

1. 浏览器环境
2. 大规模群控
3. 黑盒调用