Urldns链可以用来探测某个类是否存在，原理见上篇文章。
我最近一直在研究这个，想要通过类来判断一个java环境是否引入某jar包很容易，但如果要判断这个jar包的小版本，来判断是否能够反序列化就并不太容易了。
刚开始我傻乎乎的反编译两个小版本的jar包，然后手动用Beyond Compare 4去对比两个文件夹的变化。
虽然可视化比较直观吧，但效率极低(喂喂喂，你好歹会点java吧)。
然后网上抄了份直接读jar包的代码，改了改，舒服多了(代码也一同在Urldns项目中)。
当然还是有一些问题，比如某些小版本没有独立的类，那么就只能判断它在更新之后少了哪些类。这样就必须发送两个dnslog来判断。
比如commons-collections4-4.0.jar和commons-collections4-4.1.jar对比，commons-collections4-4.0.jar没有独立类，那么只能先发一个共有类判断是否为commons-collections4，再发一个4.1的独立类判断是4.1还是4.0。
这样看dnslog，目标是4.0就会只有一个cc40.dnslog记录，目标是4.1就会有一个cc40.dnslog和一个cc41.dnslog的记录。不是很完美，但好像也没有解决办法了。
以及某些可反序列化的版本跨度比较大，我不但要找出它相比于无法反序列化的版本的独立类，还必须要求所有可反序列化的版本都有这个独立类。光是下载那么多历史版本就够我头疼的了。
这个问题在判断JDK版本的时候非常明显，本来我还准备写一个单独的模块来判断JDK版本，但在判断繁琐程度之后果断放弃了，并且连大版本都不想探测。
更坑的是，在jdk9之后，主要类不再放在rt.jar里，而是modules文件，而且不再以标准包名进行排序，而是单独的模块，又要写个专门的检索类的代码，实在是太麻烦。
于是我仅探测一些和反序列化有关的，比如becl，Jdk7u21，win还是linux。
关于win和linux的探测，有两个很有用的包名，sun.awt.X11和sun.awt.windows，它们从jdk6到jdk17都保留了下来，而且分别仅限linux和windows版本才有。
最近log4j的jndi注入比较流行，浅蓝又挖掘了更多的高版本jndi bypass，而jndi是可以反序列化的，因此我理所当然的在这个项目中增加了jndi功能，而且将浅蓝提供的一些类名写了进去。
https://tttang.com/archive/1405/
这是刚刚找到的一个存在log4j环境的效果。
最后附上地址:
https://github.com/kezibei/Urldns
原文始发于微信公众号（珂技知识分享）：Urldns链探测类工具发放
