Compiling statically causes core dump related to 'getaddrinfo'

[MrBruz]

/usr/bin/ld: /usr/local/lib/libtoxcore.a(network.c.o): in function `addr_resolve':
network.c:(.text+0x2aa3): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[0x4meliorate]

Have you installed the dependencies correctly? libsodium-dev and libtoxcore-dev?
Is this also when using -t linux flag with Toxnet to generate the payload?

Check if you have the static binaries by running this command:
test -f /usr/lib/x86_64-linux-gnu/libtoxcore.a && echo "OK: Tox" || echo "ERR: Tox" && test -f /usr/lib/x86_64-linux-gnu/libsodium.a && echo "OK: Sod" || echo "ERR: Sod" && uname -a.

Then if you could reply with the response, that would be amazing, thank you.

As we can see: network.c within toxcore. It should take in a hostname and then return addrinfo structures.

[0x4meliorate]

/usr/bin/ld: /usr/local/lib/libtoxcore.a(network.c.o): in function `addr_resolve':

I managed to replicate what I assume has happened here:
gcc -o payload payload.c -static -ltoxcore -lsodium -lpthread -lutil

 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libtoxcore.a(network.c.o): in function `addr_resolve.part.0':
(.text+0x97): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

It appears that you have tried using the following flags to compile the payload.
Have a look inside of net/generate.go.
Use go run main.go -t linux.

[MrBruz]

Have you installed the dependencies correctly? libsodium-dev and libtoxcore-dev? Is this also when using -t linux flag with Toxnet to generate the payload?

Check if you have the static binaries by running this command: test -f /usr/lib/x86_64-linux-gnu/libtoxcore.a && echo "OK: Tox" || echo "ERR: Tox" && test -f /usr/lib/x86_64-linux-gnu/libsodium.a && echo "OK: Sod" || echo "ERR: Sod" && uname -a.

Then if you could reply with the response, that would be amazing, thank you.

As we can see: network.c within toxcore. It should take in a hostname and then return addrinfo structures.

I am using arch linux so I installed c-toxcore manually and community/toxcore. Once I had done that I also manually build libsodium to get the .a file, after that I changed the paths it references for the .a files to /usr/local/lib/libtoxcore.a and ../libsodium-stable/src/libsodium/.libs/libsodium.a

[MrBruz]

test -f /usr/local/lib/libtoxcore.a && echo "OK: Tox" || echo "ERR: Tox" && test -f ../libsodium-stable/src/libsodium/.libs/libsodium.a && echo "OK: Sod" || echo "ERR: Sod" && uname -a

OK: Tox
OK: Sod
Linux Laptop 5.15.60-1-lts #1 SMP Thu, 11 Aug 2022 14:09:59 +0000 x86_64 GNU/Linux

[MrBruz]

/usr/bin/ld: /usr/local/lib/libtoxcore.a(network.c.o): in function `addr_resolve':

I managed to replicate what I assume has happened here: gcc -o payload payload.c -static -ltoxcore -lsodium -lpthread -lutil

 /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libtoxcore.a(network.c.o): in function `addr_resolve.part.0':
(.text+0x97): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

It appears that you have tried using the following flags to compile the payload. Have a look inside of net/generate.go. Use go run main.go -t linux.

All I did to get it building statically was to add -static to the start of generate.go's build command (apart from changing the library locations for toxcore and libsodium). Once I had done that I just ran it again (with go run main.go -t linux) and got that error.

[0x4meliorate]

Adding -static as a gcc compiler flag within net/generate.go has now fixed the issue?

Or have you compiled it yourself because net/generate.go wasn’t working?

Also, be sure too pull the latest code, this is being cleaned up actively.

Check if the latest gcc command within generate works 😁
(There is a new command to compile, not sure if it works on Arch)

-llibrary
-l library

Search the library named library when linking. (The second alternative with the library as a separate argument is only for POSIX compliance and is not recommended.)
The -l option is passed directly to the linker by GCC. Refer to your linker documentation for exact details. The general description below applies to the GNU linker.
The linker searches a standard list of directories for the library. The directories searched include several standard system directories plus any that you specify with -L.
Static libraries are archives of object files, and have file names like liblibrary.a. Some targets also support shared libraries, which typically have names like liblibrary.so. If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used.
It makes a difference where in the command you write this option; the linker searches and processes libraries and object files in the order they are specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’ after file foo.o but before bar.o. If bar.o refers to functions in ‘z’, those functions may not be loaded.

[MrBruz]

No no no lol. The issue hasn't gone away. But yes I have been editing generate.go directly. Will try the new update asap and get back to you. Do you know how this issue with static linking could be fixed potentially?

[MrBruz]

New compiler options work perfectly although we still have the issue of it having issues because of getaddrinfo.

 /usr/bin/ld: /usr/local/lib/libtoxcore.a(network.c.o): in function `addr_resolve':
network.c:(.text+0x2aa3): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[+] Generated C2 address: <redacted>
[+] Compiled Linux payload: /home/<redacted>/temp/toxnet/linux_payload
[+] Successfully removed: temp_linux_stub.c

[0x4meliorate]

New compiler options work perfectly although we still have the issue of it having issues because of getaddrinfo.

 /usr/bin/ld: /usr/local/lib/libtoxcore.a(network.c.o): in function `addr_resolve':
network.c:(.text+0x2aa3): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

[+] Generated C2 address: <redacted>
[+] Compiled Linux payload: /home/<redacted>/temp/toxnet/linux_payload
[+] Successfully removed: temp_linux_stub.c

Do you have Discord? If so, it would be an enormous help, so people do not run into this issue and I can implement a solution for Arch users: https://discord.gg/pentest

You had mentioned that you managed to compile the payload previously:

• "All I did to get it building statically was to add -static to the start of generate.go's".
  If you have that command, it would be appreciated if you could post it.

As for the getaddrinfo error, it is not statically linking other libraries libc depends on.
It dynamically calls specific libraries associated with things like getaddrinfo, a lot of people are having similar issues.

Some features in glibc relies on beeing able to dynamically
load libraries (using the dynamic linker). dlopen, naturally.
And all functions using the NSS, such as gethostbyname, and various others.

• "The standard C library provides an API to perform name resolution: getaddrinfo(), formerly gethostbyname(). However, for DNS resolution as well as implementation in the libc, this interface is very impractical, to the point of being unusable. Here are a few reasons why."
• "I explained this point in a message to the Busybox mailing-list.There is a mistake in that post about /etc/nsswitch.conf and /etc/host.conf."
• TLDR: depending on the machine configuration, it is possible that getaddrinfo() will not use DNS at all."

It is a problem with libc... 😕
on this line here: network.c

I will see and look into solutions.
Someone mentioned that this had helped:

* It could be that the glibc installation is missing the corresponding object file necessary for static compilation. If that is the case, create the corresponding object file and link it at compilation.
* Try EGLIBC instead of glibc.
* I succesfully compiled my program with dietlibc which compiled without any errors plus the resulting binary was much smaller than what glibc makes.

However, I will test other operating systems and distros at some point.
An easy fix for the time being would be too spin up a Debian based distribution, either in a virtual machine or docker container.
I may integrate docker container support within net/generate.go.