[Agent / ASM] agent의 transform 메서드에 ASM 바이트코드 적용하기 2 / ASM 라이브러리 이슈

ClassReader / Visiter / Writer를 사용한 값 읽어오기

    public static byte[] addLogging(byte[] classfileBuffer) {

        ClassReader classReader = new ClassReader(classfileBuffer); // 클래스 파일 읽기
        // 클래스 파일 쓰기, COMPUTE_MAXS와 COMPUTE_FRAMES 옵션으로 메서드의 최대 스택 크기와 로컬 변수를 자동 계산
        ClassWriter classWriter = new ClassWriter(classReader, ClassWriter.COMPUTE_MAXS | ClassWriter.COMPUTE_FRAMES);

        // Classvisitor 내부에 MethodVisitor가 있으며, 이를 통해 write를 제어
        ClassVisitor classVisitor = new ClassVisitor(Opcodes.ASM9, classWriter) {
            @Override
            public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) {
                // 기존 MethodVisitor 얻기
                MethodVisitor mv = super.visitMethod(access, name, desc, signature, exceptions);

                // MethodVisitor를 래핑하여 메서드 시작 부분에 로그를 추가하는 AdviceAdapter 사용
                return new AdviceAdapter(Opcodes.ASM9, mv, access, name, desc) {
                    @Override
                    protected void onMethodEnter() {
                        // 메서드 시작 시 로그 출력 코드 삽입
                        mv.visitFieldInsn(GETSTATIC, "java/lang/System", "out", "Ljava/io/PrintStream;");
                        mv.visitLdcInsn("Entering method: " + name);
                        mv.visitMethodInsn(INVOKEVIRTUAL, "java/io/PrintStream", "println", "(Ljava/lang/String;)V", false);
                    }
                };
            }
        };

        // ClassReader로부터 클래스 파일 읽기 시작, ClassVisitor를 통해 변형 로직 적용
        classReader.accept(classVisitor, ClassReader.EXPAND_FRAMES);

        // 변경된 바이트코드를 byte 배열로 반환
        return classWriter.toByteArray();
    }

 

 

ClassReader

클래스 파일의 바이트코드를 읽는다. ClassReader는 주어진 바이트코드 배열로부터 클래스의 정보를 읽어 들이고, 이 정보를 ClassVisitor에 전달하여 처리할 수 있게 한다.

ClassVisitor

클래스의 구조(클래스 자체, 메서드, 필드 등)를 순회하면서 필요한 작업을 수행한다. ClassVisitor는 클래스 레벨의 이벤트(예: 클래스 방문 시작/종료, 메서드 방문, 필드 방문 등)에 대한 콜백 메서드들을 제공한다.

MethodVisitor

ClassVisitor 내에서 특정 메서드를 방문할 때 생성되며, 메서드 내의 바이트코드 명령어들을 순회하고 조작한다. MethodVisitor는 메서드 레벨의 이벤트(예: 메서드 시작/종료, 명령어 방문 등)에 대한 콜백 메서드들을 제공한다.

ClassWriter

변형된 바이트코드를 새로운 클래스 파일로 쓰기 위한 객체이다.

ClassVisitor와 MethodVisitor를 통해 바이트코드를 조작하는 과정에서 발생한 변경 사항들이 ClassWriter에 적용된다.

최종적으로, ClassWriter는 조작된 바이트코드를 바이트 배열로 제공한다.

 

처음 들었던 의문

내가 이해했던 코드의 방향은 이런 식이었다.

1. classreader랑 writer 를 선언한다.

2. 그리고 visitor 역시 선언한다(이 과정에서 Adapter를 Override해서 로깅 기능을 추가한다)

3. accept 메서드를 통해 classvisitor가 reader에 대한 권한을 얻고, reader 정보를 읽어와서 2의 기능을 실행한다.

4. 마지막으로 변조된 코드를 bytecode로 변환해서 내보낸다.

 

ClassReader의 accept 메서드가 어떻게 ClassWriter에게 바이트코드를 변조할 수 있는 권한을 주는지? 에 대한 의문이 있었다.

 

의문의 해결

ClassWriter와 ClassVisitor의 관계

ClassWriter 클래스는 ClassVisitor 추상 클래스를 상속받는다.

 

ClassWriter 내부 implement 구문

 

따라서, ClassWriter는 ClassVisitor의 모든 메서드를 상속받으며, 추가적으로 바이트코드를 생성하고 조작하는 메서드들을 구현한다. 이 구조 덕분에 ClassWriter 객체는 ClassVisitor 타입의 파라미터를 받는 어떤 메서드에도 전달될 수 있다.

 

ClassVisitor 구현체는 생성자에서 ClassWriter 인스턴스를 받아 이를 내부적으로 사용한다.

이때, ClassVisitor의 메서드인 visitMethod은 ClassWriter에 대한 참조를 가지고 있으며, 이 참조를 사용하여 바이트코드 조작 명령을 ClassWriter에게 전달한다.

 

조작 작업은 실제로 MethodVisitor (여기서는 AdviceAdapter를 사용)를 통해 이루어진다.

- MethodVisitor는 ClassVisitor에 의해 생성된다. (바이트코드 조작)

- 이 조작은 내부적으로 ClassWriter에 연결되어 있으며, 조작된 결과는 ClassWriter에 의해 바이트코드로 출력다.

 

결국 visiter 내부의 writer 참조로 인해 writer가 입력받은 값을 토대로 값을 변환할 수 있는 것이다.

 ClassReader -> ClassVisitor -> MethodVisitor의 흐름을 통해 클래스 파일의 내용이 순회되고 조작되며,

그리고 결과는 ClassWriter에 의해 최종 바이트코드로 집계되어 출력된다.

 

조작된(수정한) 바이트코드의 적용

 

ClassWriter를 통해 새로 쓰여진 바이트코드가 JVM의 ClassLoader에 직접 자동으로 들어가지는 않는다.

생성된 바이트코드를 JVM에 로드하기 위해서는 다음과 같은 방식을 적용한다.

 

1. Java Instrumentation을 사용한 바이트코드 조작

Java Instrumentation API를 사용하여, JVM이 클래스를 로드하는 시점에 클래스의 바이트코드를 조작하고, 조작된 바이트코드를 JVM에 제공할 수 있다. (현재 사용하는 방법이다.)

 

이 경우, ClassFileTransformer 인터페이스를 구현한 클래스에서 바이트코드를 조작하고, transform 메서드에서 변경된 바이트코드 배열을 반환한다. 반환된 바이트코드는 JVM에 의해 자동으로 해당 클래스의 정의로 사용된다.

 

public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined,
                        ProtectionDomain protectionDomain, byte[] classfileBuffer) {
    // ASM ClassReader와 ClassWriter를 사용하여 바이트코드 조작
    // 조작된 바이트코드 반환
    return modifiedClassBytes; // 조작된 바이트코드 배열
}

 

실제 나의 경우 이렇게 사용했다.

 

    //이 인터페이스의 구현체(transform)은 JVM이 존재하는 클래스를 로드할 때마다 호출되며, 이 시점에서 바이트코드를 조사하고 변경할 수 있다.
    @Override
    public byte[] transform(ClassLoader loader, String className, Class<?> classBeingRedefined,
                            ProtectionDomain protectionDomain, byte[] classfileBuffer) throws IllegalClassFormatException {
        
        // 바이트코드 변경 로직
        // com/dummy/jdbcserver/restapi/controller/InputController 컨트롤러를 읽을 때만 실행
        if (className.equals("com/dummy/jdbcserver/restapi/controller/InputController")) {
            System.out.println("특정 클래스 : " + className + " 에 대한 로직 수행");
            System.out.println(classfileBuffer);
            ReadClass.read(classfileBuffer); //custom class : 여기서 받은 코드를 Classwriter를 사용해 바이트코드 변형
        }

        return classfileBuffer;
    }

 

2. 사용자 정의 ClassLoader 사용

혹은 사용자 정의 ClassLoader를 구현하여, ClassWriter에서 생성된 바이트코드를 로드하는 방법이 있다.

이 경우, ClassLoader의 defineClass 메서드를 사용하여 바이트 배열로부터 직접 클래스를 정의하고 로드할 수 있다.

 

class MyClassLoader extends ClassLoader {
    public Class<?> defineClass(String name, byte[] b) {
        // defineClass를 사용하여 바이트 배열로부터 클래스를 정의하고 로드
        return super.defineClass(name, b, 0, b.length);
    }
}

// 사용 예
MyClassLoader loader = new MyClassLoader();
Class<?> clazz = loader.defineClass("MyClass", modifiedClassBytes);

 

이 방식을 사용하면, 프로그램 실행 중에 동적으로 바이트코드를 조작하고 해당 클래스를 로드할 수 있다.

하지만, 이미 로드된 클래스를 대체하는 것은 기존 ClassLoader에서는 허용되지 않으므로, 이를 위해서는 Java Instrumentation API와 같은 더 고급 기능이 필요하다.

 

 

 

변수 조작해보기

 

 

 

이슈

NoClassDefFoundError (build.gradle implementation)

ReadClass가 아니라 treansform 내부에 ASM 코드를 심으면 다음과 같은 에러 발생

FATAL ERROR in native method: processing of -javaagent failed, processJavaStart failed
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:560)
	at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:572)
Caused by: java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
	at org.agent.MyAgent.premain(MyAgent.java:31)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	... 3 more
Caused by: java.lang.ClassNotFoundException: org.objectweb.asm.ClassVisitor
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 5 more
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message Outstanding error when calling method in invokeJavaAgentMainMethod at s\open\src\java.instrument\share\native\libinstrument\JPLISAgent.c line: 627
*** java.lang.instrument ASSERTION FAILED ***: "success" with message invokeJavaAgentMainMethod failed at s\open\src\java.instrument\share\native\libinstrument\JPLISAgent.c line: 466
*** java.lang.instrument ASSERTION FAILED ***: "result" with message agent load/premain call failed at s\open\src\java.instrument\share\native\libinstrument\JPLISAgent.c line: 429

Process finished with exit code 1

 

transform 내부에 심지 않는다면 ASM 라이브러리를 사용해도 오류가 나지 않음.

JVM이 에이전트를 로드하려고 할 때, ASM 라이브러리를 찾을 수 없어서 발생하는 문제로 파악된다.

 

에이전트 A 내부에서 ASM 라이브러리를 사용하기 위해서는 에이전트 JAR 파일을 생성할 때 ASM 라이브러리를 포함시켜야 한다.

 

문제의 원인은 implementation 스코프로 선언된 의존성으로, 이는 런타임과 컴파일 시점에는 사용되지만, 기본적으로 생성되는 JAR 파일에는 포함되지 않는다.

 

문제 해결 : shadowJar 플러그인

이를 위해 shadowJar 플러그인을 사용하였다.

 

plugins {
    id 'java'
    id 'com.github.johnrengelman.shadow' version '7.1.2' // Shadow 플러그인 버전은 적절히 선택
}

// 나머지 설정...

// ShadowJar 설정
shadowJar {
    archiveClassifier.set('')
    manifest {
        attributes 'Premain-Class': 'org.agent.MyAgent'
        // 필요한 나머지 매니페스트 속성들...
    }
}

 

이 설정을 추가하고 나면, shadowJar 태스크를 사용하여 JAR 파일을 빌드할 수 있다.

 

gradle shadowJar

 

무한 로드 현상 발생

메서드 단위 파싱 로직을 부트하였을 경우 다음과 같이 동일 메서드를 계속하여 파싱하는 문제가 발생한다.

 

 

해결 : Exception 상황의 경우 Visitor는 해당 내용을 다시 수행하는 것으로 판단된다.

exception count 로직에 예외 처리를 걸자, 문제가 해결되었다.