Quantcast

Gambas binary to ELF?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Gambas binary to ELF?

alexchernoff
Good day all,

anyone know of a way to make an ELF format file from Gambas executable?

I try a "software protection" system (WIBU KEY), to protect a Gambas project from unwanted copying, but it can only protect ELF binaries and doesn't recognize a Gambas executable.

Cheers!

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gambas binary to ELF?

Tobias Boege-2
On Thu, 04 May 2017, alexchernoff wrote:

> Good day all,
>
> anyone know of a way to make an ELF format file from Gambas executable?
>
> I try a "software protection" system (WIBU KEY), to protect a Gambas project
> from unwanted copying, but it can only protect ELF binaries and doesn't
> recognize a Gambas executable.
>
> Cheers!
>

The, AFAIK, only Gambas compiler, gbc3, produces Gambas bytecode files which
are not ELF, as you know. There is a gb.jit component with an LLVM-based JIT
compiler. Maybe this contains all the necessary gears already to compile a
Gambas project's instructions to host system opcodes. But then you would
still have to take care of linking, especially interfacing with components
written in Gambas. It sounds like some work.

This may look like a trivial answer, but if you can protect absolutely every
ELF file as long as it's in the ELF format, just pack an archive of the
Gambas bytecode together with a copy of the interpreter executable inside
an ELF executable. That outer executable works like a self-extracting
archive: it extracts the Gambas bytecode and the interpreter and runs the
interpreter on the bytecode. Voila, the working Gambas program inside ELF.

You can easily achieve this by writing some template code for the self-
extracting archive and then embedding the compiler and the archive into
its .data section.

Regards,
Tobi

--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gambas binary to ELF?

alexchernoff
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!
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Gambas binary to ELF?

Tobias Boege-2
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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gambas-user mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gambas-user

gambaself.tar.gz (20K) Download Attachment
Loading...