javaweb-codereview 学习记录-3

Class类加载流程

实际上就是ClassLoader将会调用loadclass来尝试加载类,首先将会在jvm中尝试加载我们想要加载的类,如果jvm中没有的话,将调用自身的findclass,此时要是findclass重写了,并且传入了我们想要加载的类的字节码,那么应该调用defineclass在jvm中加载该类,最后返回java.lang.class类对象。

那么既然类加载器java.lang.ClassLoader是所有的类加载器的父类,我们可以来定义其子类从而实现加载任意字节码,当然加载恶意class也是可以的,重写findclass,遵循双亲委派机制

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import  java.lang.reflect.Method;
public class class_loader  extends  ClassLoader {

    private static String testClassName = "TestHelloWorld";

    private static byte[] testClassBytes = new byte[]{};

    {
        try{
        File fileName = new File("H:\\TestHelloWorld.class");
        FileInputStream in = new FileInputStream(fileName);
        ByteArrayOutputStream byt = new ByteArrayOutputStream();

        int b = -1;
        byte[] zi = new byte[1024];
        while ((b = in.read(zi)) != -1) {
            byt.write(zi, 0, b);
        }
            byte[] class_byte = byt.toByteArray();
            testClassBytes = class_byte;
        }
        catch (Exception e){

        }
    }

    @Override
    public Class<?> findClass(String name)  throws ClassNotFoundException{
        if(name.equals(testClassName)){

            return defineClass(testClassName,testClassBytes,0,testClassBytes.length);


        }
        return super.findClass(name);
    }

    public static void main(String[] args){

        class_loader loader = new class_loader();

        try {
            Class testClass = loader.loadClass(testClassName);

            Object testInstance = testClass.newInstance();

            Method method = testInstance.getClass().getMethod("hello");

            String str = (String)  method.invoke(testInstance);

            System.out.println(str);


        }catch (Exception e){

        }




    }
}

以上代码中字节码肯定是一个恶意类,那么只要编译得到class文件即可,我们直接将其读到byte数组中,然后再通过定义的findclass中return defineclass来通过我们的字节码生成类。

TestHelloWorld.java如下所示

public class TestHelloWorld {

    public String hello(){
        return "tr1ple 2333";
    }

}

利用自定义类加载器我们可以在webshell中实现加载并调用自己编译的类对象,比如本地命令执行漏洞调用自定义类字节码的native方法绕过RASP检测

URL类加载器

URLClassLoader也是ClassLoader的子类,那么URLClassloader可以用来加载本地或者远程资源某个目录下的资源,我们可以使用他来加载远程或本地的jar文件,如果存在security manager的话,创建一个类加载器将调用下面的方法检查是否当前是否允许创建classloader

import java.io.ByteArrayOutputStream;
import java.io.InputStream;
import java.net.URL;
import java.net.URLClassLoader;

public class TestURLClassLoader {

    public static void main(String[] args){
        try {
           URL url = new URL("http://127.0.0.1:9000/cmd.jar");
           URLClassLoader ucl = new URLClassLoader(new URL[]{url});
           String cmd = "calc";
           Class cmdClass = ucl.loadClass("cmd");
           Process process = (Process) cmdClass.getMethod("exec",String.class).invoke(null,cmd);

        }
        catch (Exception e){
            
        }


    }

}

线程上下文类加载器(Thread Context ClassLoader)

每个线程都有一个线程加载器,在创建该线程的时候指定,如果没有指定则从父类进行继承,如果全局都没有设置,则线程的实际类加载器为app classloader,利用线程上下文加载器,我们能够实现所有的代码热替换,热部署(相对于编译型语言来说的,动态更新class字节码文件,而不用重启应用)

类加载器的双亲委派模型

 

 每当一个类加载器收到一个类加载请求,则首先在父类加载器的搜索范围内尝试进行加载,当父类无法加载时子类才进行加载

 

 

在rt.jar下的sun.mics.Launch中完成类加载器的初始化,1处实例化extclassloader,2处实例化app classloader,3处设置父线程的子线程上下文类加载器也为app classloader,其中ext classloder是app classloder的父亲,这两个类加载器都继承与URLclassloader,AppClassLoader而非继承ExtClassLoader,父亲和父类不一样(划重点,要记住),如下图所示,classloader的parent变量即为父亲

 

 

继承关系:

继承关系:

java.lang.Object

       --- java.lang.ClassLoader
              --- java.security.SecureClassLoader
                      ---  java.net.URLClassLoader
                            --- sun.misc.Launcher$ExtClassLoader





java.lang.Object

       --- java.lang.ClassLoader
              --- java.security.SecureClassLoader
                      ---  java.net.URLClassLoader
                            --- sun.misc.Launcher$AppClassLoader

jvm动态加载jar包:

对于一个jar包中的类,用的classloder是第一次jvm加载该jar包中类所使用的class loader

如何确定jvm中类的唯一性:

对于任何一个类,都需要由加载它的类加载器和这个类本身一同确立在java虚拟机中的唯一性,也就是说不同的类加载器加载同一个类实际上是不同的class对象

需要自定义类加载器时,我们要重写的是findclass方法,这样是遵循双亲委派模型的,而不能重写loadclass

loadclass 类加载的顺序

1.首先调用findloadedclass查看要加载的类是否已经被加载

2.若没有被加载,并且父亲不为null,则调用父类的loadclass尝试加载class,使用双亲委派进行加载

3.如果父亲的loadclass都没有找到需要加载的类,则调用当前classloader的findclass去找要加载的类

如果以上两个步骤能够找到需要加载的类的话(findclass返回就是class类型),并且resolveclass为true的话此时将调用resolveclass对class类型的实例进行链接,默认调用loadclass(“class类名”),是不调用resolveclass进行链接的

 

所以从findclass的注释中也可以看到jdk是建议我们去在自己的classloader中重写该方法的,因为一般来说class文件来自本地文件系统,但是像rmi机制这种,class文件可以放在远程

 

在findclass中一般将调用defineclass来创建class

defineclass其中有两种:

第一种直接传字节数组,偏移,以及字节数组长度,保护域为null,此时调用defineclass创建的class是没有名称的,那这种情况是不会创建保护域的,这种是不推荐使用的

第二种是加上name参数,这也是常用的一种,安全的创建class类型实例的方法,将创建保护域

看下具体这种情况是如何给class实例封装保护域的,下图所示是一些操作方法

首先调用preDefineClass,传入要定义的name以及null的保护域,由注释可以看到主要检测要定义的name是不是以java.*开头的,以及要验证创建的class是不是和包内其它class的签名是一样的,其中checkname主要检测定义的name是否符合规范,不能出现/,不能出现[,接下来判断定义name包名不能是java开头的

 

此时定义pd为默认的保护域,如注释所言,为新创建的class建立一个默认的保护域

 

那保护域又是什么东西,保护域是由codesource(codesource感觉就是当前字节码文件的来源,和codebase类似,rmi中就用到了codebase的概念,就把它理解为一个存放字节码文件的位置),codesource是对codebase的扩展,加入了证书(x509证书,具体不再细看)的概念,用证书来验证url所指处的class文件

 permissions 一组权限集合

以及当前所用的类加载器,以及一组主体的抽象概念(principal数组),感觉是x509证书用来验证这个要被创建的类和包中类的关系的一个接口,从它重写的tostring、equals就能大概猜出来

创建完默认的保护域后,此时调用defineClassSourceLocation拿到codesource的地址

接下来就调用definClass1来创建class实例,可以看到是个native方法,具体操作是看不到的,如何验证字节码合法性也是看不到的,也包括相应的证书的验证,为什么不让我们看到,因为如果我们能看到具体定义过程,就可以自己按照规则地去定义class,那么检查就没有意义了

如果能够创建class实例的话,接下来就从保护域中拿出证书给该class签名,至此我们想要加载的class已经从文件系统上的字节码文件变成了class类型的实例

 

再回到最开始的loadclass方法里,当前的findclass找到了需要加载的class字节码文件并创建class实例以后,此时我们想要的类已经位于jvm中了,此时最后一步就是判断是否resolve进行链接(默认不进行链接)

 

那么class的链接也是native实现的,所以也是看不到的,链接完以后,还差最后一步初始化,就能使用该类了

 

举个🌰:

java idea下 debug的时候将会-javaagent参数加载 captureAgent\debugger-agent.jar,其中利用instructmentation加载含有premain方法的类,此时要加载的类为:

 因为这里是指定了name的loadclass,因此这里在创建class实例时将使用保护域,可以由下面看到为captureAgent所创建的保护域,如之前描述,这里从codesource就能看到此时的字节码地址,这里没有证书的相关验证,使用的类加载器是app classloader,从permissions就能看到当前的class所拥有的权限,即Runtime和io的read权限,之后还有captureagent的一些内部类的加载

 

 当然并不是所有的classloader在loadclass时都会创建一个保护域,比如bootstrap classloader,只有继承了SecurClassLoader的才会在defineclass的时候创建相应的保护域,而我们如果自定义classloader,那么默认继承自url classloader,而url classloader继承自secure classloader

 

secure classloader直接继承自class loader,主要是添加了额外的一些定义,包括codesource以及对class文件相应的权限(permission,java中提供了很多包括io 序列化 网络等),以及默认的一些系统策略(如何使权限为我们服务)

 默认情况下一个jar包就对应一个ProtectionDomain

参考:

https://github.com/Wasabi1234/Java-Interview-Tutorial/blob/master/Java/Java-%E7%B1%BB%E5%8A%A0%E8%BD%BD%E5%99%A8.md

https://blog.csdn.net/irelandken/article/details/7046689

 

posted @ 2019-12-30 20:48  tr1ple  阅读(374)  评论(0编辑  收藏  举报