

Embedding Blobs in Binaries - nkurz
http://gareus.org/wiki/embedding_resources_in_executables

======
skrebbel
I'm personally very fond of the decade-old no-brainer solution that is
bin2c[0]: convert a binary to a humongous .c file with an array literal. It's
inefficient, and a bit stupid with source control, but it's entirely fool
proof. Every compiler eats it. It just works. You compile it just once to a .o
and then it doesn't slow down your build anymore.

If you just want the damn file in your executable and then move on with the
stuff that actually matters, bin2c is a godsend.

[0] one of the many implementations appears to be on
[https://github.com/gwilymk/bin2c](https://github.com/gwilymk/bin2c)

------
Narishma
From the C Include method part: " On the downside, it requires at least five
times the size of the original data (” 0xNN,” for every original data-byte) "

Can anyone explain this? In the example he shows, the tool produces an array
of 12 bytes, the exact same size as the input file.

~~~
xioxox
Perhaps he means encoding the data as ascii in the source is 5 times bigger
than the original (i.e. 0xNN,), though I don't see why you have to write the
data in the form 0xNN. Presumably you could just use a giant string, encoding
non-ASCII characters.

~~~
plorkyeran
You then need to escape characters that aren't legal in C string literals
(such as double quotes, newlines and nul), and that's a lot more work than
just converting the whole string. Also, string literals add a trailing nul
byte, which is easy enough to deal with, but is also easy to forget about.

~~~
MagicWishMonkey
I'm lazy and typically just base64 it ;)

------
lelf
char data[] __attribute__((section(".my1337hax0r.hidden.section")));

~~~
jesuslop
Nice, thanks.

