看到这个项目有点开心，想写点东西供你参考。

[rootkiter]

1. 节点可视化。你的操作逻辑基本在复用Termite，但show的时候展示的信息太少了。当连接的同级节点比较多之后，是很难把节点ID和对应的主机对应关系记住的，Termite中之所以会把ID及各种系统类型，自定义配置等内容统一展示出来，正是为了应对这种难于长期记忆的问题，提示信息越多，对使用者越友好。
2. ID分配机制。时间有限，只是粗略的看了一下代码，没看到ID分配机制的部分。从文档中推测是在show的时候触发的ID分配过程。这就要考虑每两次ID刷新时，主机是不是还能够维持上一次的ID，如果ID会改变的话，使用的时候也会比较困惑。尤其是像当前这种只展示了拓扑关系和ID值的方式，在这样的场景下，会更难用。
3. 把shell绑定到本地端口会更舒服。你现阶段shell指令是直接复用当前控制台的。然而shell控制台是个很基础的需求，它和文件同步类指令要交替使用，才能完成一个完整的控制效果。这样的话，经常来回切换shell模式会比较繁琐，不如绑到一个独立的端口，用起来顺手。而且，shell绑定到端口，也可以方便和其他小组成员分享主机权限，只要大家都在同一局域网，就可以直接nc访问了。
4. 可执行文件大小问题。项目是用Go写的，后面在IOT环境的扩展问题会很多。其中最核心的问题，是ELF文件太大（IOT的编译大部分都要通过static编译，因为IoT设备环境太复杂了，各种基础库都会遇到，这样的话产品文件就会更大）。而 IoT 设备内存相对又比较小，老些的设备内存只有几十M，加上网络也不会太稳定，这样的前提下，传输的文件越大，成功率就越低。虽然项目中考虑了部分代码选择性编译控制文件大小，然而实际效果有限，毕竟产品中大部分内容都是Go的运行环境（其实说产品中有90%的代码是Go运行环境都不为过，找个IDA看一眼就行，挺明显的）。我当初也是纠结了很久才选择的 C。其实Go还会带来个潜在的问题，那就是 IoT设备的 CPU 资源也有限，如果某程序长时间占用CPU和 内存资源导致系统反应过慢，可能会被 watchdog 误认为设备假死，触发设备重启，那之前的工作很可能就白做了。

[Dliv3]

非常感谢您的建议，这几点确实也是当时我开发的时候纠结的问题。
Termite是一个非常优秀的工具，当时还想贡献代码来着🙈。
Venom的操作习惯基本是参考的Termite，关于您说的几点我做一下解释。

1. 节点可视化。当时开发的时候确实在是否加提示信息和加多少提示信息比较合适上面纠结了很久。最后是只给了ID信息，但是加入了setdes和getdes两个命令，让用户可以自己给节点设置一些描述信息。因为管理端现在是命令行界面，开发时考虑过多提示信息可能会导致拓扑图太拥挤，之后可能会考虑在管理端加入RESTful API然后再单独做一个界面。
2. ID分配机制。每个节点是通过hash来唯一标识的，ID只是提供给用户操作的。
3. shell绑定到本地端口。这个也是当时开发的时候纠结的一个问题，最后还是选择了类似meterpreter的复用当前控制台，当时考虑的是如果给shell单独开一个端口，开的多了可能就分不清哪个端口对应的是哪个agent了。这个我之后会考虑怎么做更好一点。
4. 可执行文件大小及资源占用问题。Go静态编译出的文件确实有点大，对于配置较差的IoT设备确实是一个问题。当时选Go其中一个原因是因为功能性需求，比如ssh隧道可能用C写起来麻烦一点，因为有些功能对于渗透测试确实还是挺有用的，但是对于IoT设备可能用处不是特别大。关于IoT，我之后会多做一些测试，可能之后对IoT支持的部分单独用C开发也是一种选择😂。

希望之后能多跟您交流，不知道是否方便加个微信啥的😝。