profile generate new -f shared -o lin failure to create .so

[kernelzeroday]

Describe the bug
profile generate new -f shared -o lin failure to create .so
changing the os param to windows makes a .dll

To Reproduce
sliver > profiles new beacon -a amd64 -Z r -o lin -b https://1.2.3.4 -k 1234 -j 12 -f shared name1_shared

[*] Saved new implant profile (beacon) name1_shared

sliver > profiles generate name1_shared

[] Generating new linux/amd64 beacon implant binary (1m0s)
[] Symbol obfuscation is enabled
[!] rpc error: code = Unknown desc = exit status 1

sliver > update

[*] Client v1.5.41 - f2a3915 - darwin/amd64
Compiled at 2023-07-11 14:35:13 -0700 PDT
Compiled with go version go1.20.5 darwin/amd64

[*] Server v1.5.41 - f2a3915 - darwin/amd64
Compiled at 2023-07-11 14:35:13 -0700 PDT

Checking for updates ... done!

[*] No new releases.

Expected behavior
sliver > profiles generate name2_shared

[] Generating new linux/amd64 beacon implant binary (1m0s)
[] Symbol obfuscation is enabled
[] Build completed in 26s
[] Implant saved to /FILE/PATH/WORKING_LIBFILE.so

Desktop (please complete the following information):

[*] Client v1.5.41 - f2a3915 - darwin/amd64
Compiled at 2023-07-11 14:35:13 -0700 PDT
Compiled with go version go1.20.5 darwin/amd64

[*] Server v1.5.41 - f2a3915 - darwin/amd64
Compiled at 2023-07-11 14:35:13 -0700 PDT

Additional context
windows works

[moloch--]

Can you pull the errors from ~/.sliver/logs/sliver.log cross-compiling to Linux from MacOS is always a bit of a pain because you need a C compiler and to link against musl.

For better stability, I'd recommend setting up an external builder.

[kernelzeroday]

Thanks moloch, i will try to get some logs for you ASAP.

[kernelzeroday]

It looks like it did need or want an external musl gcc, let me see if i can brew install that and get a shared beacon compiled...

cgo: C compiler "/opt/homebrew/bin/x86_64-linux-musl-gcc" not found: exec: "/opt/homebrew/bin/x86_64-linux-musl-gcc": stat /opt/homebrew/bin/x86_64-linux-musl-gcc: no such file or directory

[kernelzeroday]

OK back with a solution

in os:
brew install filosottile/musl-cross/musl-cross # https://github.com/FiloSottile/homebrew-musl-cross

sliver:

sliver > profiles generate name1_shared

[*] Generating new linux/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
[*] Build completed in 23s
[*] Implant saved to /Users/name/HELPFUL_ANSWER.so

back to os to verify:

$ file HELPFUL_ANSWER.so
HELPFUL_ANSWER.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

So it looks like we have this external dependency outside of the official brew tree to build shared linux libs on macos arm64, at least for now. Leave this open, or document it and close?

Either way thanks, but let me confirm the compiled .so actually works aswell, I can do that later today.

Thanks,
-Kelsey

[kernelzeroday]

Also i actually am rereading this, i did not even notice the generated beacon name lmaooooooooo

[kernelzeroday]

i cant help it this is too amazingly funny not to post the screenshot of

[rkervella]

Just tried this again and the result is the same as I remembered: cross-compiled Linux shared libraries built from MacOS (at least with an ARM64 processor) targeting an amd64 architecture don't work:

$ LD_PRELOAD=./test.so id
id: error while loading shared libraries: /lib/x86_64-linux-gnu/libc.so: invalid ELF header

[rkervella]

Ok found a workaround, it's just musl-cross setting the wrong libc path in DT_NEED:

$ readelf -d test.so

Dynamic section at offset 0xf12e10 contains 23 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000010 (SYMBOLIC)           0x0
 0x000000000000000c (INIT)               0x1ad188
 0x000000000000000d (FINI)               0x9f9591
 0x0000000000000019 (INIT_ARRAY)         0xcc23d0
 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
 0x0000000000000004 (HASH)               0x1200000
 0x000000006ffffef5 (GNU_HASH)           0x4f0
 0x0000000000000005 (STRTAB)             0x1200360
 0x0000000000000006 (SYMTAB)             0x6c8
 0x000000000000000a (STRSZ)              1735 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x1113000
 0x0000000000000002 (PLTRELSZ)           1176 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x1accf0
 0x0000000000000007 (RELA)               0x1868
 0x0000000000000008 (RELASZ)             1750152 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000000000001e (FLAGS)              SYMBOLIC STATIC_TLS
 0x000000006ffffffb (FLAGS_1)            Flags: NODELETE
 0x000000006ffffff9 (RELACOUNT)          72916
 0x0000000000000000 (NULL)               0x0

The good thing is you can just use patchelf to patch that:

$ patchelf --replace-needed libc.so libc.so.6 test.so

The annoying part is you'll need to know beforehand what name to put in there (might not be libc.so.6 on all systems).