libddwaf VS purego

Even in C there can be issues. the nokigiri ruby gem builds (or used to build) libxml and libxslt (which are pure C) and has to make effort remove a couple of GNUisms.

For C++ we were faced with some issues, so the process we ended up with is:

- build musl, install it in some location

- inject a few GCC libs and linux headers required for C runtime to have the above location be a proper sysroot for clang to use

- build LLVM libc++ and a few libs (e.g libunwind) as static libs against that sysroot using clang, and inject them into the sysroot

- build whatever C++ final product we want against the sysroot using clang, statically linking libc++ in

- for a dynamic lib, remove dynamic reference to some shared libs (can't recall if it's libc.so or ld.so). also, hide all symbols from libc++ and load with bind local so that when loaded the shared lib prefers its internal symbols (which would make it crash if it jumps to another libc++) and does not pollute the symbol namespace with its internal ones (which would make another lib crash if it jumps to the internal libc++)

- for an executable binary instead of a lib, dynamic reference would instead need to be altered so that it works for both

It all hinges on musl being a subset of glibc, which is not entirely true either (see the musl website for differences in behaviour, which may or may not matter depending on the piece of software)

https://github.com/DataDog/libddwaf/blob/c6a90d39d93f04ebb5e...

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Click here to view the commit: https://github.com/ebitengine/purego/commit/1a4ea678b5a7598275a28e787179da1b7a058b11

Maybe interesting for you: https://github.com/ebitengine/purego

most X11 functionality can be accessed via xgb|xgbutil (jezek has a current fork). nucular makes use of it via shiny. OpenGL and such libraries can be assumed to exist on those systems, so directly calling those c libraries without cgo is a possibility. Ebiten is currently working on it: purego.

In the malware reverse engineering scene, there are a lot of forks of the upstream "debug" go library, because it allows loading, parsing, compiling and executing libraries from disk (rather than in-kernel or in-userspace).

And there's also "purego" as an implementation that directly generates shellcode.

Maybe those will help you, too?

I am just mentioning these because for my use cases those approaches worked perfectly, CGO free.

[1] https://github.com/Binject/debug

[2] https://github.com/ebitengine/purego

https://github.com/ebitengine/purego Instead of Go using C toolchain, purego bypass it for already (should I say compiled or object-compiled)

You could use https://github.com/ebitengine/purego which would not require a C compiler to build