new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(new Object[]{request,response});
至于为什么要改这个玩意要从内存马的兼容说起。
除了由于写法问题而导致的各种乱七八糟的问题以外，连接内存马的一个主要问题是冰蝎在入口处采用了pageContext这个类来获取request response session对象。但是以filter型内存马为例，doFilter中三个参数分别是ServletRequest，ServletResponse，FilterChain，并不存在pageContext这个东西，并且在SpringBoot这种容器里根本没有pageContext这个类。
于是就有跟多师傅提出了自己的解决办法，大体分为三种：
自己声明一个pageContext类，在里面实现对应的request跟response的getter setter。
冰蝎改造之不改动客户端=>内存马
。
改写冰蝎的入口为request+response，不再采用pageContext作为入口。但是弊端就是不能再用equals了，要重新写一个方法用反射调用。
冰蝎改造之适配基于tomcat Filter的无文件webshell
采用蚁剑原来的Custom模式，把恶意函数直接通过字节码打进去，然后通过方法名调用。不过由于直接编译恶意函数的字节码较大会超过最大长度限制，一般要先写入目标然后配合URLClassLoader才能使用。
使用WebLogic CVE-2020-2883配合Shiro rememberMe反序列化一键注入蚁剑shell
以上的这些方法可以是可以，但是不够优雅。
回想我们最开始的问题，为什么要用pageContext，是为了拿到当前请求的上下文，更精确一点就是输入输出：request,response。request是接收参数，response是回显，两者缺一不可。
后来自己调试的时候发现在request中本身就包含了当前的response，同样response中也包含了当前的request。
当时就想着我shell中传个request，然后在payload里面利用反射把requst里面的response取出来，或者response里面的request取出来不就完事了？
这样确实可以，在2020年9月4日，勤劳的我一大早就起来写了一波代码，然后发了上去，
commit记录
可以证明我没有瞎bb。当时蚁剑算是最早兼容内存马的。
因为Tomcat喜欢用门面模式，所以要反射两层，结果后来发现在WebLogic下用不了了，因为WebLogic不喜欢搞门面模式，只需要反射一层就够了。
行吧，那我就再加一种情况，在JSP
V1.4版本
又增加了一层反射的情况。
本来以为没事了，后来又发现在有shiro的情况下打一个servlet内存马进去，这时候去连接内存马需要反射三次？？
WTF？？？
然后意识到，这种case by case的解决方式是不行的，世界上还有那么多种Web容器中间件，不可能一个一个去调吧。
所以为了彻底解决这个问题，在520师傅的建议下采用了数组的方式将两者直接传进去，把分析的逻辑放在打内存Shell的时候去做，而不在payload里面去做。
现在冰蝎跟哥斯拉也都有了相应的机制，思路大体是一样的，感兴趣的小伙伴可以自己研究一下。
