Is there a standard way to embed resources in an executable Linux image?

Question

Embedding binary resources in PE images (EXE, DLL) using the Windows API is quite simple: (see http://msdn.microsoft.com/en-us/library/ms648008(v=VS.85).aspx ).

Is there a similar standard API on Linux?

or perhaps some de facto approach to embedding resources?

The goal is to embed some static binary and / or text data into an executable, for example. photos, HTML, etc., so the binary distribution of the program is as simple as making one copy of the file? (assuming all library dependencies are fine)

Update:

The following bdk suggestion, I tried the solution described in Embedding binary blobs using gcc mingw , and it worked for me, Although, there are some problems worth mentioning: my project (in Code :: Blocks) consists of several C + files + and adding binary data to any of the corresponding object files, which they are useless for hacking. objdump -x will show that most of the characters have passed since the injection (and I have not found how to fix this). To overcome this problem, I added an empty .cpp file to the project for the sole purpose of providing an object file for playback and wrote the next custom build step for this file, which did the job nicely (for example, uses the Code :: Blocks macros):

 $compiler $options $includes -c $file -o $object ld -Ur -b binary -o $object <binary payload path> 

Answer 1

Make yourself an assembler file, blob.S:

  .global blob .global blob_size .section .rodata blob: .incbin "blob.bin" 1: blob_size: .int 1b - blob 

Compile with gcc -c blob.S -o blob.o Now the block can be accessed from your C program:

 extern uint8_t blob[]; extern int blob_size; 

Using bin2c converter usually works fine, but if blob is big, incbin solution is much faster and uses much less memory (compilation time)

Answer 2

objcopy --add-section allows you to add an arbitrary file as a section to the ELF executable. (user help page). However, this is only half the solution, because I have not yet found a way to access this data from within C, except by downloading and analyzing the ELF binary using the ELF library.

Change Additional Information:

If you have a compiled program MyProgram and a resource file MyResource.dat that you want to embed in MyProgram, you can use the objcopy command as follows:

 objcopy MyProgram --add-section MyResource=MyResource.dat 

Now, if you look at your program using the objdump -x MyProgram command

You will see the MyResource section, which contains the contents of MyResource.dat. The file is now embedded in the executable file.

The trick now is how you access data from your program. My instinct tells me that the bootloader must put the file in memory somewhere, and you can get a pointer to it, but I'm not sure how easy it is. Ideally, I would like to be able to expand my exeutable and dlsym section, but this does not work because its section is not a symbol.

The only alternative I know to access the section from within the program is to use the libelf library or something similar, which is a bit like using a sledgehammer to knock on a nail. You can use it in your application to download yourself as an ELF resource and get partitions. The documentation is sparse, but here is an example

http://em386.blogspot.com/2007/03/quick-libelf-guide.html

I would really like it if someone could listen to an easier way to access data from the -add section.

Edit 2 In my research, I included this question: Embedding binary drops using gcc mingw

Which should work for both gcc and mingw and shows a way to use ld instead of objcopy to add data and access it as a symbol. It looks promising

Answer 3

Sure. Try something like a Bin2Hex converter . Convert the binary data into a C ++ char array, and then paste it into your code as a constant variable.

Answer 4

how about makeself

he will make a tar archive from a directory in which your entire program, resource files into a shell executable. And when the user launches the executable file, he will extract the files and run an arbitrary command (there may be the main executable file of the program). There is a drawback that every time the user launches an executable file, you will first need to download / extract the files before starting the real program.