[Gambas-user] Gambas binary to ELF?

[Tobias Boege]

On Fri, 05 May 2017, alexchernoff wrote:
> Well thanks Tobias, that's a great idea. 
> 
> The "AXprotector" ELF protector encrypts the executable so it should be
> safe. 
> 
> Any suggestions how to build such a self-extractor ELF? 
> 
> thanks!
> 

Try the attached archive. It contains 3 things:

  * a simple Gambas project called gbdigest: it uses gb.openssl to hash
    its input using a digest algorithm that is installed on your system.
    It also uses gb.args to let you specify the digest algorithm through
    its -m command-line switch and the output format through the -o switch.
    The string to hash is the list of all the non-options you specify
    on the command-line or, if that list is empty, it reads each line
    from stdin.

    These mechanics serve to demonstrate a lot of things: the ELF wrapper
    allows you to execute a Gambas program that was compiled into it.
    Loading Gambas components written in C (gb.openssl) and in Gambas (gb.args)
    works. The command-line arguments and standard file descriptors are
    properly passed from the ELF wrapper to the Gambas process.

  * mkelf-template.c: template C code for the ELF wrapper.

  * mkelf.sh: uses the xxd utility (included in the vim package) and
    mkelf-template.c to compile an ELF program which executes a given
    Gambas program. The executable Gambas archive (.gambas file) is
    embedded into the ELF file.

Here is an example usage:

  ## Unpack the archive
  [~]$ tar -zxf gambaself.tar.gz
  [~]$ cd gambaself

  ## Create an ELF wrapper "mydigest" for the Gambas program "gbdigest.gambas"
  [gambaself]$ ./mkelf.sh gbdigest.gambas mydigest
  [gambaself]$ file mydigest
  mydigest: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, [...]

  ## Start the program, request its --help. As you can see the program name is set to "gbdigest.gambas"
  [gambaself]$ ./mydigest --help
  Usage: gbdigest.gambas <options> <arguments>

  Options:
   -m --method <NAME>                     Digest method
   -o --outformat <FORMAT>                Output format of digest: raw|hex|base64
   -V --version                           Display version
   -h --help                              Display this help

  ## You can verify its output by using md5sum from coreutils
  [gambaself]$ ./mydigest -o hex abc           # Arguments passing test
  900150983cd24fb0d6963f7d28e17f72
  [gambaself]$ echo "abc" | ./mydigest -o hex  # Reading from stdin test
  900150983cd24fb0d6963f7d28e17f72
  [gambaself]$ echo -n "abc" | md5sum
  900150983cd24fb0d6963f7d28e17f72  -

  ## Again with sha256sum
  [gambaself]$ ./mydigest -m sha256 -o hex abc
  ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad
  [gambaself]$ echo -n abc | sha256sum
  ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad  -

There is one big problem though. The Gambas interpreter (gbr3 for .gambas
files) requires, AFAIK, a real file as input. I included a long comment in
the mkelf-template.c file about that, but I might as well parrot its
contents here. I think this is because the interpreter, when loading an
archive file, uses mmap() on it. This is probably what makes it impossible
to use a FIFO to pass the Gambas archive file, which resides in memory
in the "mydigest" process, on to the gbr3 process to have it executed.

Currently the template takes the Gambas archive and puts it into a temporary
file which is then read by a gbr3 process and after that the temporary file
is removed. But there is a very long window where the Gambas executable is
somewhere on disk, which makes all your protection of the ELF file useless.

I bet you can change the interpreter into accepting Gambas executables
from FIFOs, but you have to decide for yourself if you want to do that.
It may just be that you have to replace that particular mmap() call in
main/share/gb_arch_temp.h:load_arch() with a read() or so, but it could
also require much more effort -- I haven't look into it. Or you get
another idea for avoiding the temporary file. But this has reached a
point of hackiness where I should probably stop giving you ideas.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gambaself.tar.gz
Type: application/octet-stream
Size: 15005 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20170505/89b7895e/attachment.obj>