Fatal Error Occurred

[EarzuChan]

The issue occurs on Windows 11 across OpenJDK 11, 17, and 21, with the native library (built via CMake/MinGW-w64) loading successfully.

Starting Gradle Daemon...
Gradle Daemon started in 3 s 791 ms
Type-safe project accessors is an incubating feature.
> Task :jvm:xposed:processResources NO-SOURCE
> Task :jvm:test:processResources NO-SOURCE
> Task :jvm:test:processTestResources NO-SOURCE
> Task :jvm:core:compileJava
> Task :jvm:core:processResources NO-SOURCE
> Task :jvm:core:classes
> Task :jvm:core:jar
> Task :jvm:xposed:compileJava
> Task :jvm:xposed:classes
> Task :jvm:test:compileJava NO-SOURCE
> Task :jvm:test:classes UP-TO-DATE
> Task :jvm:xposed:jar
> Task :jvm:test:compileTestJava
> Task :jvm:test:testClasses
Native Lib Path: D:\A Sources\JvmXposed-main\native\build-windows\jvmplant.dll
LOG: Performing to UNSAFE GETLONG
LOG: To see the Stack
	at dev.tmpfs.jvmplant.impl.HotSpotClassFileVerifyBypass.symbol(HotSpotClassFileVerifyBypass.java:290)
	at dev.tmpfs.jvmplant.impl.HotSpotClassFileVerifyBypass.getStructs(HotSpotClassFileVerifyBypass.java:260)
	at dev.tmpfs.jvmplant.impl.HotSpotClassFileVerifyBypass.findBytecodeVerificationFlagAddress(HotSpotClassFileVerifyBypass.java:334)
LOG: findNative: gHotSpotVMStructs -> 0 // I think it
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by dev.tmpfs.jvmplant.impl.ReflectHelper (file:/D:/A%20Sources/JvmXposed-main/jvm/core/build/libs/core-1.0-SNAPSHOT.jar) to method java.lang.ClassLoader.findNative(java.lang.ClassLoader,java.lang.String)
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000002c1e9373fcf, pid=29396, tid=32556
#
# JRE version: OpenJDK Runtime Environment Temurin-11.0.25+9 (11.0.25+9) (build 11.0.25+9)
WARNING: Please consider reporting this to the maintainers of dev.tmpfs.jvmplant.impl.ReflectHelper
# Java VM: OpenJDK 64-Bit Server VM Temurin-11.0.25+9 (11.0.25+9, mixed mode, tiered, compressed oops, g1 gc, windows-amd64)
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
# Problematic frame:
# J 973 c2 jdk.internal.misc.Unsafe.getLong(J)J java.base@11.0.25 (7 bytes) @ 0x000002c1e9373fcf [0x000002c1e9373fa0+0x000000000000002f]
#
# No core dump will be written. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# D:\A Sources\JvmXposed-main\jvm\test\hs_err_pid29396.log
Compiled method (c2)    1291  973       4       jdk.internal.misc.Unsafe::getLong (7 bytes)
 total in heap  [0x000002c1e9373e10,0x000002c1e9374048] = 568
 relocation     [0x000002c1e9373f88,0x000002c1e9373f98] = 16
 main code      [0x000002c1e9373fa0,0x000002c1e9374000] = 96
 stub code      [0x000002c1e9374000,0x000002c1e9374018] = 24
 scopes data    [0x000002c1e9374018,0x000002c1e9374020] = 8
 scopes pcs     [0x000002c1e9374020,0x000002c1e9374040] = 32
 dependencies   [0x000002c1e9374040,0x000002c1e9374048] = 8
Compiled method (c2)    1294  973       4       jdk.internal.misc.Unsafe::getLong (7 bytes)
 total in heap  [0x000002c1e9373e10,0x000002c1e9374048] = 568
 relocation     [0x000002c1e9373f88,0x000002c1e9373f98] = 16
 main code      [0x000002c1e9373fa0,0x000002c1e9374000] = 96
 stub code      [0x000002c1e9374000,0x000002c1e9374018] = 24
 scopes data    [0x000002c1e9374018,0x000002c1e9374020] = 8
 scopes pcs     [0x000002c1e9374020,0x000002c1e9374040] = 32
 dependencies   [0x000002c1e9374040,0x000002c1e9374048] = 8
Could not load hsdis-amd64.dll; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
#   https://github.com/adoptium/adoptium-support/issues
#
Unexpected exception thrown.
org.gradle.internal.remote.internal.MessageIOException: Could not read message from '/127.0.0.1:64557'.
	at org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:94)
	at org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:270)
	at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
	at org.gradle.internal.concurrent.AbstractManagedExecutor$1.run(AbstractManagedExecutor.java:47)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: com.esotericsoftware.kryo.KryoException: java.io.IOException: Remote host forced close a active connection.
	at com.esotericsoftware.kryo.io.Input.fill(Input.java:148)
	at com.esotericsoftware.kryo.io.Input.require(Input.java:178)
	at com.esotericsoftware.kryo.io.Input.readByte(Input.java:295)
	at org.gradle.internal.serialize.kryo.KryoBackedDecoder.readByte(KryoBackedDecoder.java:88)
	at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:64)
	at org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52)
	at org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:81)
	... 6 more
> Task :jvm:test:test FAILED
HookTests > returnTypeTests() SKIPPED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':jvm:test:test'.
> Process 'Gradle Test Executor 1' finished with non-zero exit value 1
  This problem might be caused by incorrect test process configuration.
  For more on test execution, please refer to https://docs.gradle.org/8.8/userguide/java_testing.html#sec:test_execution in the Gradle documentation.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.

Deprecated Gradle features were used in this build, making it incompatible with Gradle 9.0.

You can use '--warning-mode all' to show the individual deprecation warnings and determine if they come from your own scripts or plugins.

For more on this, please refer to https://docs.gradle.org/8.8/userguide/command_line_interface.html#sec:command_line_warnings in the Gradle documentation.
BUILD FAILED in 27s
6 actionable tasks: 6 executed

hs_err_pid29396.log

[cinit]

Hi @EarzuChan ,

It seems that there is something wrong with HotSpotClassFileVerifyBypass.java (for finding the address of BytecodeVerification* to bypass the JVM bytecode verifier) on Windows (while I have only tested it on Linux x86_64).
Bypassing the JVM bytecode verifier is necessary in order to access the "this" object before super.<init> (the super constructor) is called in a hooked constructor, which is required to implement the Xposed API by design.
I will try to fix the BytecodeVerification or re-implement it in a safer way when I have spare time.

Thanks.

[EarzuChan]

好的bro，原来搞这个字节码校验绕过是为了hook constructor！我那个报找不到jvm内部地址，在我的windows openjdk上运行，会在getaddress那里返回0，然后就会触发读写0处地址的错误。
btw，我在我自己的项目中也遇到过关于字节码检验类似的问题，也就是如果向构造器的开头（call super之前）织入字节码，然后加载这个类，就会报错。
另外哥们对类似于lsplant或者是frida-java-bridge（的jvm部分）那种修改内存搞跳板的hook方式感兴趣吗？我正想以后自己试着用kt和rust（jni）做一个。

[cinit]

@EarzuChan 无论是 LSPlant 还是 frida-java-bridge 都高度依赖 ART/JVM 的调试符号（ .symtab 而不是 .dynsym ）。然而在实际环境中，用户在 Windows/Linux 下载的 JVM 基本是不带调试符号的。Android 的 ART 是自带了几乎完整的调试符号，因此 LSPlant 使用 ART 中的符号表去 hook 或者调用 ART 未导出函数是个很好的选择。在大多数情况下都没有符号的 JVM 上依赖内部符号去 hook 相较于不需要内部符号的 JVMTI 而言，实现类似 LSPlant 的功能，可能工作量就比较大了。

[EarzuChan]

谢谢。btw，佬的修复做得如何了？

[cinit]

@EarzuChan 修改了一下 bypass verifier 的代码，请 git pull 后再试一下

[EarzuChan]

@EarzuChan 修改了一下 bypass verifier 的代码，请 git pull 后再试一下

@cinit ，感谢大佬的辛勤工作

我通过 msvc 编译了，windows 上 pass 了，mac 上 pass 了很多（但是可能 jdk 太新，字节码校验没 bypass 成功；旧的 open jdk 二进制（比如 21）在 mac 上没私密符号，会报找不到符号），linux 想必也能 apss

我仔细读了一下你的源码，认为你的实现实在是巧妙：那个织入代码和 threadlocal 的配合实现了 call hook 调度还是 call 原始逻辑，真的牛批，省去了我本来认为的需要把原始逻辑迁移到一个 backup 方法。
不过有一个点我实在没完全理解：为什么在初始化时，要构建一个随机类来存放跳板方法呢，而不是直接让织入的代码访问跳板。这是为了防止目标 app 检测/防止多 jvmxposed 实例冲突/防止 jvmxposed 自身类污染目标 app 类路径吗？

[cinit]

Hi @EarzuChan ,

但是可能 jdk 太新，字节码校验没 bypass 成功；旧的 open jdk 二进制（比如 21）在 mac 上没私密符号，会报找不到符号

很抱歉，我没 mac 环境测试，只测了 windows 和 linux，x86_64 和 arm64。

为什么在初始化时，要构建一个随机类来存放跳板方法呢，而不是直接让织入的代码访问跳板。这是为了防止目标 app 检测/防止多 jvmxposed 实例冲突/防止 jvmxposed 自身类污染目标 app 类路径吗？

并非为了防检测/防冲突。绝大多数情况下，有 (被 hook 的 class).getClassLoader() != JvmXposed.class.getClassLoader(), 两者位于不同的类加载器，这意味着被 hook class 无法直接访问 JvmXposed 的 class；考虑到在实际使用中应该避免直接对被 hook 的类的 classloader 做太多注入操作（不然容易出玄学兼容性问题），只能手动构造跳板。目前 JvmXposed 的随机跳板类是注入 BootstrapClassLoader 的，这意味着整个 JVM 内的任何 class 都可以访问它，随后随机跳板类再使用反射机制访问 JvmXposed 的处理函数。

[EarzuChan]

@cinit
非常感谢您这个库，让我学到了些骚操作，我把您的Jvm Hook思路用Kotlin和Kotlin/Native复刻了下，放进了我的Kotlin多平台Hook框架
EarzuChan/Sakiko
大佬可以赏脸看看

目前JVM的Hook实现是基本按您这个思路，然后安卓我是想未来用Kotlin/Native对接LSPlant（当前直接借用了AliuHook），然后整套Hook和模块Api，我是借鉴的YukiHook