RAT开发小结

前言

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

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

目前就想到这么多啦

Tags: 木马, rat, 远控

正在写的一个WebRat

2019/8/19

嘛,整出来了Manager

咕咕咕了这么久(其实这期间是去整其他事情了)

怎么说呢,勉强能用的那种吧
TIM截图20190819211716.jpg

与其说是远控,不如说更像一个权限维持工具吧。

目前是全网免杀的_(:з)∠)_。。还有许多功能没添加

2019/8/5

基于:反弹式shell后门 实现

基本就是用这货整了个控制端,再用jq+ws整了个前端。

控制端用的是Golang写的,这样可以在多平台上跑。
还未完善,地址在这:tkit

暑假过去一半了啊啊啊啊啊啊啊,感觉自己啥也没干。

非常的烦.jpg

挖了好多坑都没填 ,其中就是那个pantsuWorld了,和一群人设定半天,连框架都没搭出来

完成度0.3%左右吧hhhhh

就是这些了
TIM图片20190805040518.jpg

Tags: 木马, 程序