[Java安全]HashMap的readObject都发生了什么

本文主要是介绍[Java安全]HashMap的readObject都发生了什么，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

写在前面

这篇文章的灵感来自纯好奇大佬的文章
当然推荐大家看看大佬的文章，学点骚操作，我只是顺便分析一下为什么这样可以而已，大佬可乐嗯觉得这些比较简单没有写原因，那我来学习学习顺便记录，大佬文章直达
Java反序列化数据绕WAF之加大量脏数据

分析(以URLDNS为例)

首先我们要知道ObjectInputStream的readObject的调用栈，来个网图自己懒的画，很简单的关系

至于为什么URLDNS，便于我更好的进行跟踪操作，仅此而已
首先看看函数调用栈，看关键的

首先是去触发readObject方法

这个s根据地址来看769那就是和上面图对应部分的输入流

那么我想要知道ObjectInputStream都干了些什么，将文件流传入BlockDataInputStream

再传入

前面这一部分没啥分析的意义，就是一些初始化读取属性过程

我这里直接跳过垃圾数据那阶段了，反正都是一样的道理

跟入

继续跟入

这里根据数据流类型进入对应分支

看这里似乎是对流执行了序列化

跟进

跟进

跟进lookupObject

查找并返回与给定句柄相关的对象

实例化

很明显了到这里

后面就是到URLDNS链子了，没必要了

分析LinkedHashSet,HashSet，TreeSet等类为什么不可以

文章里面师傅说的有点小错误，不是所有的例子都不可以，这里以URLDNS的HashSet为例，可以看到这里因为Hashcode不为-1被返回了

去找一下hashcode咋来的

可以看见重点是primVals

好奇这个哪来的吗，跟入URL的readFields

跟入

这里进行了简单的初始化，下面过程比较枯燥

接下来到readFields

跟进

继续跟进

再往下跟进

继续往下跟进

可以看到最终调用了readBytes是个native方法，没办法往下跟进的


具体原因就出这里了，有兴趣的大佬可以试试分析Java底层C实现这个方法

这篇关于[Java安全]HashMap的readObject都发生了什么的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---