the-z-labs/bof-launcher

Beacon Object File (BOF) launcher - library for executing BOF files in C/C++/Zig applications

bof-launcher's Issues

wide character support in fasm

bof-launcher/bofs/src/wDirectSyscall.asm

Lines 44 to 48 in 5d33547

	; https://codeverge.com/utf16-encode
	; 'file.txt'
	align 8
	filename dw 0x0066,0x0069,0x006c,0x0065,0x002e,0x0074,0x0078,0x0074
	.SIZE = $ - filename

This is the typical way to generate UTF-16 characters, assuming the source code is utf-8 encoded (in this case it doesn't matter because the filename is ASCII).

include 'encoding/utf8.inc'
align 8
filename du 'file.txt'
    .SIZE = $ - filename

bof-launcher library uses libc on Linux as a workaround for Zig bug

See: ziglang/zig#17062

bofObjectRunAsyncThread() crashes with older GLIBC versions

Calling bofObjectRunAsyncThread() on a system with an older GLIBC versions (prior to 2.34) will cause a segmentation fault due to a NULL pointer dereference. This is because pthread functionality wasn't integrated into libc.so.6 in those GLIBC versions so the pthread_create and pthread_detach function pointers are NULL.

This should be reproducible by modifying the integration-with-c example to use bofObjectRunAsyncThread (demo.patch) and executing it on a system with an older GLIBC. I also have an example fix that patches bof_launcher.zig to load the functions from libpthread.so.0 (fix.patch).

demo.zip

test@test:~$ unzip demo.zip
Archive:  demo.zip
  inflating: demo.sh                 
  inflating: demo.patch              
  inflating: fix.patch
  
# run an example that produces a crash 
test@test:~$ docker run --rm -it --entrypoint bash -v`pwd`:/data oraclelinux:8.9 /data/demo.sh

# run the example with the example fix applied
test@test:~$ docker run --rm -it --entrypoint bash -v`pwd`:/data oraclelinux:8.9 /data/demo.sh 1

I have tested this patch on GLIBC 2.17, 2.28, 2.34, and 2.39 and the patch worked in all cases. However, I have only been able to test x86_64 and not architectures such as arm or aarch64.

I don't know if introducing a reliance on libpthread.so.0 (or the stub provided with modern GLIBC versions) is how you wanted to address this until issue #1 is solved so I didn't want to preemptively make a pull request. Let me know if you would like me to make one though.

Thanks for making and maintaining this project, I've found it to be quite interesting and useful!