最近写的玩具，实际上感觉实战基本上用不到。。。我打的攻防还没有这么前沿，但是因为最近好久都没更新博客了。闲来无事水一篇
首先full credit to HackBrowserData，主体框架都是从这抄的，也是从这个的代码学的大概的还原浏览器数据的逻辑。
该项目是为了解决HackerBrowserData在目标机器上存在高强度edr防护时无法利用的情况。其实绕过的想法也很简单，并且已经到了高级对抗，实现的方法也还可以有很多，也可以针对特定规则搓出特定的方案，这里只是给出一个可能且稍微具有一点泛用性的一个例子。
前两天听说的新奇玩意，之前的C2隐藏的经典做法是域前置，在云厂商不验证域名所有权的情况下，可以注册域名，并且云厂商会为你签发对应的证书。显然，该方法是有悖于正常软件的运行逻辑的，随着该方法的普遍传播，云厂商都在用户绑定域名前对域名所有权进行了校验，使得域前置技术现在只能是作为一层套CDN的技术，并不能伪造出任意合法地名。虽说如此，但也能当一层cdn用，但使用的前提就是自己注册一个域名。
该方案能够隐藏C2的真实IP，但由于SNI的存在，即使在使用HTTPS的情况下流量监控设备仍然能够拿到客户端访问的目标域名（我感觉未备案下https的阻断也是这个道理），在国内顶级实名注册域名的情况下，一个域名反手社工全家完全不是问题。
因此，需要另一个合法的隐藏C2服务器的技术，也就是今天提到的云函数。该方案实际上也类似于一层CDN，但不需要自己签发域名，直接使用云服务商提供的域名，本身也属于较为可信的域名（大概）
不过以上几个办法都不能防止对C2（CDN）的IP封禁，因为CDN是由地理位置决定分发到哪个机器上的，如果当前地理位置对应的CDN被封了IP，CDN也不会知道你被封了而给你重新解析一个新IP出来，所以仅作隐藏使用。
标题党文章捏，这个通杀要看一定的运气（虽然我本地猛通猛通，但是实际上还是需要一点运气成分的），本文的起因是wjh和我说springboot通杀这么牛逼的技术怎么感觉都没什么反响，然后天哥说这个不是很通杀，有概率问题，进而导致了疑惑，从而对该方法是否通杀以及其原因进行的研究。（实际上是好久没跟博客了感觉这个稍微有点内容能水一下）
最近nacos rce好像很火，然后有一天whj好兄弟给我发了知名Java卷王y4er的文章里的一句话
Nacos Hessian 反序列化 RCE（说起来这篇文章里面居然还引了我这个不知名Java垃圾的文章。我不好说）
于是和@X1r0z讨论了一下，nacos是springboot，内置了jackson，可以用jndi lookup配合jackson POJONode的gadget打rce
看这意思，jndi lookup是打本地链，jackson的POJONODE能直接RCE。springboot自带jackson，那还要什么nacos，言外之意不是springboot有一个反序列化就直接走POJONode直接通？