前沿
繼續接着前面的進行分析。
說一句感想：YSO的Payloads有個特點：在目標的readObject的過程中儘量不觸發異常。emm，當然後面由於類型的不匹配什麼的造成的異常就跟反序列化過程沒關係了。
BeanShell1
BeanShell是什麼？
BeanShell是一個小型嵌入式Java源代碼解釋器，具有對象腳本語言特性，能夠動態地執行標準JAVA語法，並利用在JavaScript和Perl中常見的的鬆散類型、命令、閉包等通用腳本來對其進行拓展。BeanShell不僅僅可以通過運行其內部的腳本來處理Java應用程序，還可以在運行過程中動態執行你java應用程序執行java代碼。因爲BeanShell是用java寫的，運行在同一個虛擬機的應用程序，因此可以自由地引用對象腳本並返回結果。
總之是一個用類似於腳本方式執行Java代碼的解析器。
外層還是利用了PriorityQueue在readObject時會調用Comparator進行重新排序的特點。
這裏通過BeanShell的Interpreter創建了一個compare函數。
同時這裏有個XThis：Extended ‘this’ with support for the new jdk1.3 proxy mechanism.
擴展了"this"（應該是Beanshell的this類）用來支持jdk1.3的代理技巧。
這裏如CommonsCollections1中一樣創建了動態代理。
該動態代理代理Comparator接口，使用了XThis類中的Handler子類作爲InvocationHandler。這裏通過反射的方法拿到了內部的Handler對象來創建代理。
題外話：其實直接調用XThis的正規代理創建接口getInterface也可以達到一樣的效果，只是創建的Payload會由於有個額外的HashTable會大一點：
Comparator comparator = (Comparator)xt.getInterface(Comparator.class);
當該comparator的compare函數被調用時會進入Handler的invoke函數：
而後進入invokeImpl函數：
經過判斷函數名不等於equals與toString，會開始調用invokeMethod函數：
最後會根據方法名compare獲取到剛剛創建的BeanShell中的compare方法，最後進行執行：
有關BeanShell的XThis沒有去查更多的資料，但看起來是讓開發者可以用動態代理的方式去訪問BeanShell所創建的函數的類。
http://javadox.com/org.beanshell/bsh/2.0b5/bsh/XThis.html
膜拜下大佬們對庫的熟悉程度。。