RAT开发小结

一些小小的总结~

前言

最近闲着无聊又一次重构了这个项目:manager,这次算是最终比较完善的版本了

index.png
index.png

从去年断断续续的摸鱼到最近,总算整出了一套勉强能用的版本的。

其实rat原理上非常简单,无非就是控制端下发,然后被控端执行,最后把执行结果都给提交了上去。

从最开始的C/S,到现在的B/S,都尝试过,也用过C/PY/GOLANG分别写过马和控制端,先说说出我的经验吧。

架构选择

架构无非就是两种,一种C/S一种B/S,说是这么说,其实原理上也都是C/S,B/S只不过是再C/S的基础上加了个C/B通讯的过程而已。

如果你想要的是快速开发,重点在于可用性而不是易用性,那么我这推荐直接用C/S+cli,gui都不用写。方便快捷。当然如果要好用,而且还要好用的控制其他机器,那么gui肯定是必不可少的。

语言选择

如果不是对程序体积以及内存占用要求严格,在没有高超底层编写基础上,十分不推荐上C/C++来作为首选语言。虽然C/C++优点是这其中最多的,又快又小又灵活,但是同样缺点也很多,跨平台会很麻烦,并且不想其他"现代"语言一样有很多十分方便的库可以调用,想写一个东西直接调用就行,而且还和编写者水平挂钩,一不小心代码就会变的很shit(没错我的代码就是这么shit

golang暂时比较推荐,也是我目前再用的,然而,这编译出来的体积是真的不敢恭维,同时部署开发环境的时候也略微麻烦,但是优点也很明显,跨平台十分的轻松,而且语法也挺简单,C一样简单的语法C差不多的性能,如果没有这鬼畜的体积我绝对会吹爆golag

py是开发最轻松也是最灵活但也是最不灵活的。毕竟是脚本语言,会出现各种奇奇怪怪的问题,会整的你非常非常的迷惑,稳定性不能保证,但是作为控制端开发来说,py是最舒服的,毕竟他是脚本。同时还有个好处就是很多linux会自带python,但是还是归根一点,稳定性很捉急,所有东西都装了但是就是莫名其妙的跑不起来,非常的蛋疼

协议选择

TCP/UDP这类型的协议我就不说什么了,这里大家自行判断,我们这里说的是轮询类还是tcp那种长连接类保持。

tcp长连接类型的好处就是,操作反馈非常及时,最早的gh0st,上兴灰鸽子都是这种模式,然而缺点也很大,就是后台直溜溜的一个tcp链接,十分容易被发现。并且会收到网络波动影响。

轮询类的就是类似cs那种,缺点就是操作反馈不及时,必须等待各种间隔才能交换数据,这对于即时操作体验很麻烦。

所以最好的办法就是两种结合,普通模式轮询遇到特殊模式就建立tcp链接然后实时交换数据,然而这就也挺考研变成功底的

所以如果不考虑隐蔽性而注重体验那就直接走tcp最简单也最轻松,注重隐蔽性就走https,有时间有水平就上两者结合

服务端的一些小tips

接上条,如果选择轮询,还有一个优点是,你可以使用http/https,然后套个CDN,可以有效的隐蔽源服务端,当然这就肯定得预留个tips来设置http的请求头中CDN设置的客户的源IP

目前就想到这么多啦

添加新评论

评论列表