0

assume that I have a tar.gz archive that contains 1 shared library. My intention, is to untar it "on-the-fly" and the .so (that is extracted), put it on LD_PRELOAD and the run my code.

So, I made a script:

#!/bin/bash

myTarLib=$1
tar -zxf $myTarLib --to-command "export LD_PRELOAD="

./run_the_func

The execution of the run_the_exec didn't use the .so from the tar. I have the impression that the "--to-command" option creates another shell; is it correct?

Do you have any suggestion on how I could do it? The important part, is that i don't want to have the .so on the disk.

Thanks in advance!

Vangelis
  • 33
  • 4
  • You could use /dev/shm (RAM) if available. – Cyrus Oct 22 '20 at 10:14
  • Even if it does create a shell, that shell would not run the command in the next line of your script. I'm afraid I really don't understand what you expect to happen here, but probably see https://stackoverflow.com/questions/37586811/pass-commands-as-input-to-another-command-su-ssh-sh-etc – tripleee Oct 22 '20 at 10:31
  • `LD_PRELOAD` needs to point to a disk location so I don't think you can do what you seem to be asking, at least not easily. You could perhaps hack `ld.so` to support loading binaries from memory but it really sounds like a malware accident waiting to happen rather than useful functionality. – tripleee Oct 22 '20 at 10:34
  • Thank you for your comments guys. Indeed what I am looking for, is a way to load it from RAM instead of putting it to hard disk. Cyrus thanks for the tip. I will look for it. tripleee I also agree that hacking the ld.so is not a good idea. Maybe a C code that performs the untar and then loads it via the dlsym (but again I am not sure). – Vangelis Oct 22 '20 at 12:12

1 Answers1

0

I found a solution to the problem... The use of memfd_create

The memfd_create creates a file descriptor. Then this can be used to store any data in it. The manpage is here.

In order to use it, you need to create a C-Wrapper that takes care of the untar (in my case). The code is:

#include <linux/memfd.h>
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>

int main()
{
    int fd = memfd_create("my_test", MFD_CLOEXEC);
    if (fd == -1)
    {
        fprintf(stderr, "Creation failed\n");
    }


    char command_1[128];
    char *path="hiddenLibrary/libmy_func_real.tgz";
    //feel free to modify it to the path of your encrypted library
    sprintf(command_1, "tar -zxf %s --to-stdout > /proc/%ld/fd/%d", path, (long) getpid(), fd);

    printf("Running decrypt command\n");
    system(command_1);

    printf("The untar-ed library is located at:/proc/%ld/fd/%d\nOnce you finished type a number and hit enter\n",(long) getpid(), fd);
    float temp;
    scanf("%f", &temp);

return 0;
}

Now the idea is that the C code above, will run the untar and will store the result to the fd. Once you have finished using it, you simply hit a number and the C code exits. During the exit, all the fds are released, so the untar-ed library is "gone".

Vangelis
  • 33
  • 4
  • It is a fancy idea. So, you have a shared library available in memory that can be dynamically linked with any program which needs it through LD_PRELOAD. To make it more presentable, you can make a symbolic link on the "fd" file: ln -s /proc/%ld/fd/%d /somepath/mylib.so – Rachid K. Oct 28 '20 at 11:55
  • @RachidK. you can even provide the fd to the LD_PRELOAD. So, `LD_PRELOAD=/proc/$pid/fd/$fd` works fine! – Vangelis Oct 29 '20 at 16:00
  • Yes for sure. I just wanted to give it a "standard" name with the .so suffix. – Rachid K. Oct 29 '20 at 16:56