ICode9

精准搜索请尝试: 精确搜索
首页 > 编程语言> 文章详细

RMI源码调试

2021-08-02 18:34:57  阅读:177  来源: 互联网

标签:调用 对象 bind 源码 UnicastServerRef RMI exportObject 调试 RegistryImpl


看RMI漏洞时候,对其漏洞原理并不是很理解,所以简单调试了下源码加强下漏洞理解

由于要调试到RegistryImpl_Stub这种动态类,刚开始用的源码版本是JDK8u141,后来发现源码有些地方进行了修改,故此换回了JDK 7u80

以下是源码版本JDK 7u80的源码

创建注册中心

createRegistry

Registry registry = LocateRegistry.createRegistry(1099);

从上面这句代码入手,追溯下去,可以发现服务端创建了一个RegistryImpl对象。

image-20210721160608629

LiveRef var2 = new LiveRef(id, var1);这里进行了一些数据的封装并赋值给var2

image-20210720101224511

跟进下一行this.setup()

1.首先创建了个UnicastServerRef对象,把刚刚封装的var2传入了进去

image-20210721160757652

2.跟进下一行setup,把创建UnicastServerRef的对象作为var1传入了setup()中

image-20210721160852013

在setup()中调用了UnicastServerRef的exportObject()方法

image-20210721160953929

跟进UnicastServerRef的exportObject()方法

image-20210721161102356

第85行创建了RegistryImpl的代理对象RegistryImpl_stub,这个对象就是后面服务于客户端的RegistryImpl的Stub对象

image-20210721161201211

第91行传入RegistryImpl,创建出RegistryImpl_Skel对象

image-20210721161242428

继续回到前面,看94行,这里用skeleton、stub、UnicastServerRef对象、ObjID和一个boolean值等构造了一个Target对象,也就是这个Target对象基本上包含了全部的信息

image-20210721161658318

在这上面都是没有进行网络操作,只是进行了一些对象的创建和变量的赋值操作。

接下来就是网络层的一些操作了

调用this.ref的exportObject方法,传入了Target对象,跟进LiveRef的exportObject

image-20210721161754589

又调用了TCPEndpoint的exportObject方法,然后最终到达了TCPTransport的exportObject方法。以下是调用栈

TCPTransport的exportObject方法做的事情就是将上面构造的Target对象暴露出去。

image-20210721161854206

此时的this是TCPTransport对象,跟进TCPTransport的listen()方法

image-20210721161937919

调用TCPEndpoint#newServerSocket方法,会开启端口监听

image-20210720142736629

接下来的第231行就是启动一条线程,等待客户端的请求

回到TCPTransport#exportObject,往下看

image-20210721162046054

调用了父类Transport的exportObject()将Target对象存放进ObjectTable中

image-20210721162130829

注册中心处理请求

接上,在TCPTransport#listen中

image-20210721162252201

跟进AcceptLoop()到executeAcceptLoop

image-20210721162350489

这里就是获取了请求中的一些信息,在371行创建一个线程,调用内部类ConnectionHandler来处理请求

image-20210721162439831

进入ConnectionHandler,此内部类就是用来处理请求的

image-20210721162657289

接收请求,在run()中获取的ServerSocket对象

跟进上图中的run0()后,handleMessages来处理请求

image-20210716151754153

进入handleMessages(),在之前获取一些客户端传过来的数据。然后转到case 80

image-20210720145438170

先是创建了一个StreamRemoteCall对象,并传入var1,var1是当前连接的Connection对象

紧接着跟入下一行TCPTransport#serviceCall

image-20210721163157301

这里获取了OBJID,后面会获取到Target对象

最后在下面调用了UnicastServerRef#dispatch来处理请求

image-20210716152137008

接着跟dispatch:

image-20210721163511205

这里传递的两个参数,一个是Target对象,一个是当前连接的StreamRemoteCall对象,

image-20210721163445933

接着调用到了oldDispatch

跟进oldDispatch,在最后调用到了this.skel.dispatch

image-20210721163602416

可以看到this.skel就是之前创建的RegistryImpl_Skel对象,也就是说UnicastServerRef#dispatch最后会调用到RegistryImpl_Skel#dispatch来处理请求

接着跟RegistryImpl_Skel#dispatch方法:

var3是一个int类型的数组,分别对应了

  • 0->bind
  • 1->list
  • 2->lookup
  • 3->rebind
  • 4->unbind

image-20210721163806065

然后会进入case对方法进行处理,可以看到case 0对应的是bind,有执行readObject,而最后var6.bind中的var6是RegistryImpl对象,由createRegistry获得

比如调用了bind,则会进入RegistryImpl_Skel#dispatch中,先反序列化readObject传过来的序列化对象,之后进行var6.bind来注册服务,而var6则是RegistryImpl对象。也就是说无论是客户端还是服务端,最终其调用注册中心的方法都是通过创建的RegistryImpl对象进行调用的。

获取注册中心

getRegistry

在前面createRegistry获得的是RegistryImpl对象,而getRegistry获得的是RegistryImpl_Stub对象

Registry registry = LocateRegistry.getRegistry("192.168.202.1",1099);

直接查看getRegistry源码最后返回的是一个RegistryImpl_Stub对象

image-20210720154718641

调用bind绑定到注册中心

在两种方式获取的RegistryImpl和RegistryImpl_Stub对象中,其bind方法有什么区别呢

RegistryImpl#bind

在第一步会checkAccess,里边有一些判断,会对你当前的权限、来源IP进行判断。

之后判断这个键是否已经被绑定过,如果已经被绑定过,则抛出一个AlreadyBoundException的错误,否则将键和对象都put到Hashtable中。

这里的bindings是一个Hashtable,以键-值的方式存储了服务端注册的服务。

image-20210716154012509

RegistryImpl_Stub#bind

进入RegistryImpl_Stub#bind,这里的var3,前面说过,bind方法对于的数字为0,此时的var3就代表了bind方法对应的数字

image-20210721165241073

调用UnicastRef#newCall,将RegistryImpl_Stub对象传了进去,RegistryImpl_Stub存了一些服务器相关的信息。

简单来看newCall就是与远程RegistryImpl的Skeleton对象的连接

image-20210721165333020

new newConnection用来创建一个TCPConnection对象,里面写了一些ip、端口

new StreamRemoteCall创建了一个StreamRemoteCall对象,把var6,LiveRef,ObjID,调用bind方法的值var3和4905912898345647071传入了StreamRemoteCall对象

image-20210721165428771

以上两个都是进行数据的封装

调用完后,回到RegistryImpl_Stub#bind(因为这里RegistryImpl_Stub是动态类,故用了jdk8u141的源码调试的截图)

image-20210720163445451

序列化两个内容

  • 序列化后的var1,var1为我们要绑定远程对象对应的名称
  • 序列化后的var2,var2为我们要绑定的远程对象

最后调用invoke方法把请求发出去,注册中心就会接收到请求调用RegistryImpl_Skel#dispatch进行处理。

以下是注册中心的RegistryImpl_Skel#dispatch处理请求

image-20210720164250741

注册中心首先会反序列化readObject两个对象,第一个和第二个对应上面两个writeObject写入的对象,绑定远程对象对应的名称和要绑定的远程对象

接着调用var6.bind来绑定服务,var6即RegistryImpl对象,调用到RegistryImpl#bind把键和对象都put到Hashtable中。

创建远程对象

其实创建远程对象的时候,和创建注册中心是类似。生成其存根stub和skel,并且会绑定随机一个端口发布

在这里下个断点

image-20210720201106091

HelloImpl继承了UnicastRemoteObject

image-20210720201155496

跟进super方法,传入port为0

image-20210720201218588

这里调用了exportObject,并且传入了HelloImpl对象

image-20210720201412353

跟进exportObject

image-20210720201936431

new UnicastServerRef()就是封装了一些host,ObjID等

image-20210720201819801

经过了几次exportObject调用后,到了UnicastServerRef#exportObject

image-20210721165957623

Util.createProxy创建了一个远程对象的代理对象proxy。这点和之前注册中心的并不同,注册中心创建的是RegistryImpl_Stub

跟进Util.createProxy看到,后面返回了动态代理对象,而其invocationHandler值为RemoteObjectInvocationHandler(远程调用该对象时,客户端获取到的其实是该代理对象)

image-20210721170043247

回到UnicastServerRef#exportObject,看到var5的值最终是一个动态代理类

image-20210721170152141

继续往下看,if判断是否为RemoteStub类,显然RemoteObjectInvocationHandler不属于RemoteStub,返回false,不执行if里面的语句

下面构造了一个Target对象,然后调用this.ref的exportObject方法,传入了Target对象

image-20210721170246121

下面就是网络层的操作了

跟进exportObject,最终调用 TCPTransport#exportObject 方法

image-20210721170332390

跟进listen()

image-20210721170409240

调用newServerSocket开启一个随机端口监听,这里开启的是11061

image-20210721170425716

回到TCPTransport#exportObject。

最终服务暴露(exportObject)时做了两件事,一是如果 socket 没有启动,启动 socket 监听;二是将 Target 实例注册到 ObjectTable 对象中。

通信调用

接下来讲客户端与服务器之间通信是怎么进行的

客户端与服务端的通信

客户端代码:

        //获取远程主机对象
        Registry registry = LocateRegistry.getRegistry("127.0.0.1",1099);
        //查找注册中心得hello对象
        Hello hello = (Hello)registry.lookup("hello");
        //调用方法
        System.out.println(hello.hello("yangyang"));

客户端与服务端的通信发生在调用远程方法时

hello.hello(); //调用方法

前面两行,拿到的hello对象是proxy代理对象,且该代理对象的handler为RemoteObjectInvocationHandler

image-20210727121100708

此时是远程代理对象RemoteObjectInvocationHandler与服务器的Skel进行通信

在Proxy调用方法时候,会进入对应的InvocationHandler的invoke方法中,也就是RemoteObjectInvocationHandler的invoke方法

image-20210721170640773

在这个做了个if判断为false,跳转到else中

image-20210721170708904

跟进invokeRemoteMethod

image-20210721170849011

这里调用了this.ref.invoke,而this.ref则是UnicastRef对象

跟进UnicastRef#invoke

image-20210721170913168

和前面一样newConnection用来创建一个TCPConnection对象,里面写了一些ip、端口

new StreamRemoteCall创建了一个StreamRemoteCall对象,把TCPConnection对象,ObjID,-5976794856777945295传入了StreamRemoteCall对象

image-20210721170939921

然后往下看,for循环条件满足(前提是传递的参数是一个对象)跟入下面的marshalValue

这个方法是把调用方法的参数进行了序列化

image-20210721171028950

回到UnicastRef#invoke,下面调用了executeCall()方法

image-20210721171101813

跟进StreamRemoteCall#executeCall方法,这个方法就是用来发送给服务端数据的了

image-20210721171128769

继续跟进releaseOutputStream方法,this.out.flush就是把数据发送给服务端

image-20210721152551532

发送完数据后,回到UnicastRef#invoke,下面的unmarshalValue

unmarshalValue则是接受服务端发过来的数据进行readObject读取,然后赋值给var13返回。

image-20210721153035565

到这里整个客户端与服务端通信流程就走完了,下面来看下服务端和客户端的通信

服务端和客户端的通信

和注册中心一样,服务端的接收到请求后,最后会进入UnicastServerRef#dispatch进行处理

image-20210727141831779

这里有两次处理请求:

第一次是在lookup的时候

image-20210727141747496

当执行lookup的时候,会进入UnicastServerRef#dispatch中,到124行进入oldDispatch

image-20210727141947011

跟进oldDispatch,看到调用了DGCImpl_Skel的dispatch处理

image-20210727142239582

第二次是发生在UnicastServerRef#dispatch中的第151行进行处理

image-20210727142445741

当传入的参数类型是一个Object的时候,这里也会进行unmarshalValue

image-20210721155635914

unmarshalValue中进行了readObject,此处就是服务端反序列化触发的一个点

标签:调用,对象,bind,源码,UnicastServerRef,RMI,exportObject,调试,RegistryImpl
来源: https://www.cnblogs.com/yyhuni/p/15091121.html

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有