Update on current issues
I encountered a fatal panic when running VMPacker on an ARM64 JNI library compiled with modern Android NDK (Clang).
The Error Log:
[ERROR] [arm64-v8a] VMPacker gagal! Log:
panic: runtime error: slice bounds out of range [876163685:376128]
goroutine 1 [running]:
[github.com/vmpacker/pkg/binary/elf.(*Packer).injectVMPBatch(0x7a3a8e4000](https://github.com/vmpacker/pkg/binary/elf.(*Packer).injectVMPBatch(0x7a3a8e4000), {0x7a3a764140, 0x7, 0x1f?})
/data/data/com.termux/files/home/release/VMPacker/pkg/binary/elf/packer.go:862 +0x1ab8
Technical Analysis:
The panic occurs because the index 876163685 is vastly larger than the actual library size (376128 bytes). This suggests that the ELF parser/packer is misinterpreting data as a memory offset.
This behavior is likely caused by Packed Relocations (RELR) introduced in modern Android NDK/Clang. It seems the current Go-based ELF parser in VMPacker does not yet support the RELR relocation format, causing it to read "garbage" values when traversing the relocation tables, leading to an out-of-bounds crash during the VMP injection phase.
Update on current issues
I encountered a fatal panic when running VMPacker on an ARM64 JNI library compiled with modern Android NDK (Clang).
The Error Log:
Technical Analysis:
The panic occurs because the index 876163685 is vastly larger than the actual library size (376128 bytes). This suggests that the ELF parser/packer is misinterpreting data as a memory offset.
This behavior is likely caused by Packed Relocations (RELR) introduced in modern Android NDK/Clang. It seems the current Go-based ELF parser in VMPacker does not yet support the RELR relocation format, causing it to read "garbage" values when traversing the relocation tables, leading to an out-of-bounds crash during the VMP injection phase.