geacon_plus
geacon_plus copied to clipboard
Z3ratu1
TODO list
- [x] shell和run命令的异步执行
- [x] 上传下载的异步操作
- [x] timestomp
- [ ] ppid功能实现
- [x] 设置销毁时间
- [x] 实现端口转发，添加一个代理功能
- [x] 32位下测试
- [x] 域前置实现
- [x] 实现dns beacon
- [x] 在view file中对linux下的软链接进行了解析
- [ ] 在Windows server 2008下窃取token后执行shell命令会导致用户桌面上出现一闪而过的黑框，暂且不能理解
IsHighPriv的新实现有一个非常奇怪的bug，会影响metadata中localIP的第一个字节，而debug时会变的正常，目前来看应该是debug的时候添加了gcflags "all=-N -l"，这个flag是禁止优化和内联操作，可能是go的迷之优化把哪里搞坏了吗？非常玄学
叫朋友帮忙测试后发现好像这个bug只在我的电脑上存在。。。其他人无法复现，未解之谜
文件的异步下载也有问题，下载的时候有其他操作回传数据的话就会导致下载失败，server端会报错counter错误是否重放，但是debug了一下beacon的counter并没有被条件竞争，还是顺序增长的，难道说文件下载过程中要保持连续的counter吗。。。不可能吧。。。不想翻源码了捏。暂时先将实现返回到原来的同步下载环节
又换回异步了，改了一点点东西只会又能用了，不过未进行健壮性测试
终于修好了，似乎是不同的goroutine之间存在迷之条件竞争，就是counter的生成顺序和发送顺序不一致，昨天翻了半天原生实现抄了一版也没什么用，最后把pushResult那段加了个互斥锁一劳永逸了。。。
玄学事件再次发生，今天上午原来能用的ExecASM功能没法加载ladon，go版本和dllinject版本都不能用，但是自己写的小玩具C#仍然能用，对比源码反复测试无果，中午吃了个午饭回来之后两个又都能用了。一度怀疑是不是ladon有暗桩。。。
端口转发还挺好写的，但是CS原生的端口转发命令是beacon回连到server然后server把流量再往外转，感觉意义不是很大。所以在run上面写了点垃圾代码手动扩展出一个普通的端口转发功能。socks5代理也可以写一个，不过感觉用处也不是很大，frp那种反连后代理进内网的命令cs4.7好像支持了socks5，但是用http套一层的socks5好不好用我不好说，没事做再写吧 以及之前考虑过frp这种操作比较困难的是如何在一个tcp连接中区分多个连上来的连接，最近看到了一个叫yamux的项目，能很好的完成这个支持捏。不过显然这个项目是不能整合进cs的。
我也跟师傅一样， 写这类功能容易遇到奇奇怪怪的问题， hhhh
frp也用到了yamux， 导致frp的通信流量留有通信特征, 师傅哪天在项目里用到了的话， 需要留意一下。 具体特征的话，师傅用fofa搜索app='frp' 就知道是什么了
frp特征是yamux的特征吗？我看fofa上是\x00\x01\x00\x02\x00\x00\x00\x01\x00\x00\x00\x00的序列。我印象里是frp在client回连的时候会用json格式通信，里面的字段特征拉满
之前写过一版，DNS的传输效率太低了，一次查询传不了几个字节，按个ps都能传半天，并且流量特征明显的离谱。觉得实战用不到就拉倒了，并且当时也只测了能用shell按两个基础命令就算结束了。（当时写的实验的那版放在pro项目的dns分支了，师傅可以参考一下）
之前写过一版，DNS的传输效率太低了，一次查询传不了几个字节，按个ps都能传半天，并且流量特征明显的离谱。觉得实战用不到就拉倒了，并且当时也只测了能用shell按两个基础命令就算结束了。（当时写的实验的那版放在pro项目的dns分支了，师傅可以参考一下）
我找找
之前写过一版，DNS的传输效率太低了，一次查询传不了几个字节，按个ps都能传半天，并且流量特征明显的离谱。觉得实战用不到就拉倒了，并且当时也只测了能用shell按两个基础命令就算结束了。（当时写的实验的那版放在pro项目的dns分支了，师傅可以参考一下）
我找找
或者我过两天看看修一下整合到这里面
之前写过一版，DNS的传输效率太低了，一次查询传不了几个字节，按个ps都能传半天，并且流量特征明显的离谱。觉得实战用不到就拉倒了，并且当时也只测了能用shell按两个基础命令就算结束了。（当时写的实验的那版放在pro项目的dns分支了，师傅可以参考一下）
我找找
或者我过两天看看修一下整合到这里面
行的。 原项目无了。https://github.com/testxxxzzz/geacon_pro下好像没dns分支了
之前写过一版，DNS的传输效率太低了，一次查询传不了几个字节，按个ps都能传半天，并且流量特征明显的离谱。觉得实战用不到就拉倒了，并且当时也只测了能用shell按两个基础命令就算结束了。（当时写的实验的那版放在pro项目的dns分支了，师傅可以参考一下）
我找找
或者我过两天看看修一下整合到这里面
行的。 原项目无了。https://github.com/testxxxzzz/geacon_pro下好像没dns分支了
原项目有被大佬劝有喝茶风险转私有了，这个是别人fork的，我过两天整合一下把dns缝上去吧
okok
之前写过一版，DNS的传输效率太低了，一次查询传不了几个字节，按个ps都能传半天，并且流量特征明显的离谱。觉得实战用不到就拉倒了，并且当时也只测了能用shell按两个基础命令就算结束了。（当时写的实验的那版放在pro项目的dns分支了，师傅可以参考一下）
我找找
或者我过两天看看修一下整合到这里面
行的。 原项目无了。https://github.com/testxxxzzz/geacon_pro下好像没dns分支了
原项目有被大佬劝有喝茶风险转私有了，这个是别人fork的，我过两天整合一下把dns缝上去吧
frp特征是yamux的特征吗？我看fofa上是
\x00\x01\x00\x02\x00\x00\x00\x01\x00\x00\x00\x00的序列。我印象里是frp在client回连的时候会用json格式通信，里面的字段特征拉满
这个序列是frpc发出登录请求后， server的第一个回包的特征， 是yamux产生的。 无论frps/c是否启用加密都会有这个流量上的特征。 json格式的通信， 则是可以通过tls_enable消除的
frp特征是yamux的特征吗？我看fofa上是
\x00\x01\x00\x02\x00\x00\x00\x01\x00\x00\x00\x00的序列。我印象里是frp在client回连的时候会用json格式通信，里面的字段特征拉满这个序列是frpc发出登录请求后， server的第一个回包的特征， 是yamux产生的。 无论frps/c是否启用加密都会有这个流量上的特征。 json格式的通信， 则是可以通过tls_enable消除的
还有这种事？套了一层tls整个流量应该是在加密后再传输整个都应该是加密的，这个\x00\x01\x00\x02\x00\x00\x00\x01\x00\x00\x00\x00序列应该也会加密吧
