How to dump a binary file as a C/C++ string literal?
I have a binary file I would like to include in my C source code (temporarily, for testing purposes) so I would like to obtain the file contents as a C string, something like this:
x01x02x03x04
Is this possible, perhaps by using the od or hexdump utilities? While not necessary, if the string can wrap to the next line every 16 input bytes, and include double-quotes at the start and end of each line, that would be even nicer!
I am aware that the string will have embedded nulls (x00) so I will need to specify the length of the string in the code, to prevent these bytes from terminating the string early.
c hexdump xxd
add a comment |
I have a binary file I would like to include in my C source code (temporarily, for testing purposes) so I would like to obtain the file contents as a C string, something like this:
x01x02x03x04
Is this possible, perhaps by using the od or hexdump utilities? While not necessary, if the string can wrap to the next line every 16 input bytes, and include double-quotes at the start and end of each line, that would be even nicer!
I am aware that the string will have embedded nulls (x00) so I will need to specify the length of the string in the code, to prevent these bytes from terminating the string early.
c hexdump xxd
stackoverflow.com/q/13856930/560648
– Lightness Races in Orbit
Dec 28 '14 at 0:53
add a comment |
I have a binary file I would like to include in my C source code (temporarily, for testing purposes) so I would like to obtain the file contents as a C string, something like this:
x01x02x03x04
Is this possible, perhaps by using the od or hexdump utilities? While not necessary, if the string can wrap to the next line every 16 input bytes, and include double-quotes at the start and end of each line, that would be even nicer!
I am aware that the string will have embedded nulls (x00) so I will need to specify the length of the string in the code, to prevent these bytes from terminating the string early.
c hexdump xxd
I have a binary file I would like to include in my C source code (temporarily, for testing purposes) so I would like to obtain the file contents as a C string, something like this:
x01x02x03x04
Is this possible, perhaps by using the od or hexdump utilities? While not necessary, if the string can wrap to the next line every 16 input bytes, and include double-quotes at the start and end of each line, that would be even nicer!
I am aware that the string will have embedded nulls (x00) so I will need to specify the length of the string in the code, to prevent these bytes from terminating the string early.
c hexdump xxd
c hexdump xxd
edited Dec 27 '14 at 6:40
Michael Homer
47.1k8124162
47.1k8124162
asked Dec 27 '14 at 6:11
MalvineousMalvineous
1,95511835
1,95511835
stackoverflow.com/q/13856930/560648
– Lightness Races in Orbit
Dec 28 '14 at 0:53
add a comment |
stackoverflow.com/q/13856930/560648
– Lightness Races in Orbit
Dec 28 '14 at 0:53
stackoverflow.com/q/13856930/560648
– Lightness Races in Orbit
Dec 28 '14 at 0:53
stackoverflow.com/q/13856930/560648
– Lightness Races in Orbit
Dec 28 '14 at 0:53
add a comment |
6 Answers
6
active
oldest
votes
You can almost do what you want with hexdump, but I can't figure out how to get quotes & single backslashes into the format string. So I do a little post-processing with sed. As a bonus, I've also indented each line by 4 spaces. :)
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/.*/ "&"/'
Edit
As Cengiz Can pointed out, the above command line doesn't cope well with short data lines. So here's a new improved version:
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
As Malvineous mentions in the comments, we also need to pass the -v verbose option to hexdump to prevent it from abbreviating long runs of identical bytes to *.
hexdump -v -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
This produces redundant and invalid elements if input is shorter than 16 bytes.
– Cengiz Can
Dec 27 '14 at 10:03
@CengizCan: :oops:! Is that better?
– PM 2Ring
Dec 27 '14 at 10:38
1
Need to add the-voption tohexdump, otherwise long runs of the same input byte cause output lines that say"*".
– Malvineous
Dec 21 '16 at 3:45
@Malvineous Good point! I've amended my answer. Thanks for the heads-up (and thanks for accepting my answer).
– PM 2Ring
Dec 21 '16 at 5:21
add a comment |
xxd has a mode for this. The -i/--include option will:
output in C include file style. A complete static array definition is written (named after the input file), unless xxd reads from stdin.
You can dump that into a file to be #included, and then just access foo like any other character array (or link it in). It also includes a declaration of the length of the array.
The output is wrapped to 80 bytes and looks essentially like what you might write by hand:
$ xxd --include foo
unsigned char foo = {
0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64,
0x21, 0x0a, 0x0a, 0x59, 0x6f, 0x75, 0x27, 0x72, 0x65, 0x20, 0x76, 0x65,
0x72, 0x79, 0x20, 0x63, 0x75, 0x72, 0x69, 0x6f, 0x75, 0x73, 0x21, 0x20,
0x57, 0x65, 0x6c, 0x6c, 0x20, 0x64, 0x6f, 0x6e, 0x65, 0x2e, 0x0a
};
unsigned int foo_len = 47;
xxd is, somewhat oddly, part of the vim distribution, so you likely have it already. If not, that's where you get it — you can also build the tool on its own out of the vim source.
Nice! I didn't even know I had xxd. Now I just have to remember it exists next time I need it... or I'll probably just replicate the required functionality in Python. :)
– PM 2Ring
Dec 27 '14 at 7:01
objcopywould be better
– Lightness Races in Orbit
Dec 28 '14 at 0:55
@LightnessRacesinOrbitobjcopywould allow OP to link the binary data with the executable as an object file, which is useful but not exactly what's being asked here.
– Wander Nauta
Dec 28 '14 at 13:38
1
@WanderNauta: You would access it in pretty much the same way as you'd accessfoo/foo_lenhere, and you wouldn't be vastly wasting storage space. I am convinced that the OP would be better off withobjcopyand that it suits his or her requirements.
– Lightness Races in Orbit
Dec 28 '14 at 13:49
1
objcopyis fine when it's around, but it's not portable and the output even less so. It can certainly be part of a good permanent solution, but that isn't the question here.
– Michael Homer
Dec 28 '14 at 18:15
add a comment |
xxd is good but the result is highly verbose and takes a lot of storage space.
You can achieve practically the same thing using objcopy; e.g.
objcopy --input binary
--output elf32-i386
--binary-architecture i386 foo foo.o
Then link foo.o to your program and simply use the following symbols:
00000550 D _binary_foo_end
00000550 A _binary_foo_size
00000000 D _binary_foo_start
This is not a string literal, but it's essentially the same thing as what a string literal turns into during compilation (consider that string literals do not in fact exist at run-time; indeed, none of the other answers actually give you a string literal even at compile-time) and can be accessed in largely the same way:
unsigned char* ptr = _binary_foo_start;
int i;
for (i = 0; i < _binary_foo_size; i++, ptr++)
putc(*ptr);
The downside is that you need to specify your target architecture to make the object file compatible, and this may not be trivial in your build system.
add a comment |
Should be exactly what you asked for:
hexdump -v -e '"\" "x" 1/1 "%02X"' file.bin ; echo
add a comment |
This is a short utility I wrote that essentially does the same thing (originally posted on Stack Overflow):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_LENGTH 80
int main(void)
{
FILE *fout = fopen("out.txt", "w");
if(ferror(fout))
{
fprintf(stderr, "Error opening output file");
return 1;
}
char init_line = {"char hex_array = { "};
const int offset_length = strlen(init_line);
char offset_spc[offset_length];
unsigned char buff[1024];
char curr_out[64];
int count, i;
int line_length = 0;
memset((void*)offset_spc, (char)32, sizeof(char) * offset_length - 1);
offset_spc[offset_length - 1] = '';
fprintf(fout, "%s", init_line);
while(!feof(stdin))
{
count = fread(buff, sizeof(char), sizeof(buff) / sizeof(char), stdin);
for(i = 0; i < count; i++)
{
line_length += sprintf(curr_out, "%#x, ", buff[i]);
fprintf(fout, "%s", curr_out);
if(line_length >= MAX_LENGTH - offset_length)
{
fprintf(fout, "n%s", offset_spc);
line_length = 0;
}
}
}
fseek(fout, -2, SEEK_CUR);
fprintf(fout, " };");
fclose(fout);
return EXIT_SUCCESS;
}
1
Your answer would be more useful if you also provided the input and output examples with it.
– not2qubit
Mar 7 '15 at 13:43
add a comment |
If you are into python, load it into a variable "buff" and use something like this:
buff2 = buff.encode("hex")
print ("0x"+", 0x".join([buff2[i:i+2] for i in range(0,len(buff2),2)]))
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f176111%2fhow-to-dump-a-binary-file-as-a-c-c-string-literal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
You can almost do what you want with hexdump, but I can't figure out how to get quotes & single backslashes into the format string. So I do a little post-processing with sed. As a bonus, I've also indented each line by 4 spaces. :)
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/.*/ "&"/'
Edit
As Cengiz Can pointed out, the above command line doesn't cope well with short data lines. So here's a new improved version:
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
As Malvineous mentions in the comments, we also need to pass the -v verbose option to hexdump to prevent it from abbreviating long runs of identical bytes to *.
hexdump -v -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
This produces redundant and invalid elements if input is shorter than 16 bytes.
– Cengiz Can
Dec 27 '14 at 10:03
@CengizCan: :oops:! Is that better?
– PM 2Ring
Dec 27 '14 at 10:38
1
Need to add the-voption tohexdump, otherwise long runs of the same input byte cause output lines that say"*".
– Malvineous
Dec 21 '16 at 3:45
@Malvineous Good point! I've amended my answer. Thanks for the heads-up (and thanks for accepting my answer).
– PM 2Ring
Dec 21 '16 at 5:21
add a comment |
You can almost do what you want with hexdump, but I can't figure out how to get quotes & single backslashes into the format string. So I do a little post-processing with sed. As a bonus, I've also indented each line by 4 spaces. :)
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/.*/ "&"/'
Edit
As Cengiz Can pointed out, the above command line doesn't cope well with short data lines. So here's a new improved version:
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
As Malvineous mentions in the comments, we also need to pass the -v verbose option to hexdump to prevent it from abbreviating long runs of identical bytes to *.
hexdump -v -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
This produces redundant and invalid elements if input is shorter than 16 bytes.
– Cengiz Can
Dec 27 '14 at 10:03
@CengizCan: :oops:! Is that better?
– PM 2Ring
Dec 27 '14 at 10:38
1
Need to add the-voption tohexdump, otherwise long runs of the same input byte cause output lines that say"*".
– Malvineous
Dec 21 '16 at 3:45
@Malvineous Good point! I've amended my answer. Thanks for the heads-up (and thanks for accepting my answer).
– PM 2Ring
Dec 21 '16 at 5:21
add a comment |
You can almost do what you want with hexdump, but I can't figure out how to get quotes & single backslashes into the format string. So I do a little post-processing with sed. As a bonus, I've also indented each line by 4 spaces. :)
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/.*/ "&"/'
Edit
As Cengiz Can pointed out, the above command line doesn't cope well with short data lines. So here's a new improved version:
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
As Malvineous mentions in the comments, we also need to pass the -v verbose option to hexdump to prevent it from abbreviating long runs of identical bytes to *.
hexdump -v -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
You can almost do what you want with hexdump, but I can't figure out how to get quotes & single backslashes into the format string. So I do a little post-processing with sed. As a bonus, I've also indented each line by 4 spaces. :)
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/.*/ "&"/'
Edit
As Cengiz Can pointed out, the above command line doesn't cope well with short data lines. So here's a new improved version:
hexdump -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
As Malvineous mentions in the comments, we also need to pass the -v verbose option to hexdump to prevent it from abbreviating long runs of identical bytes to *.
hexdump -v -e '16/1 "_x%02X" "n"' filename | sed 's/_/\/g; s/\x //g; s/.*/ "&"/'
edited 1 hour ago
answered Dec 27 '14 at 7:04
PM 2RingPM 2Ring
4,96811424
4,96811424
This produces redundant and invalid elements if input is shorter than 16 bytes.
– Cengiz Can
Dec 27 '14 at 10:03
@CengizCan: :oops:! Is that better?
– PM 2Ring
Dec 27 '14 at 10:38
1
Need to add the-voption tohexdump, otherwise long runs of the same input byte cause output lines that say"*".
– Malvineous
Dec 21 '16 at 3:45
@Malvineous Good point! I've amended my answer. Thanks for the heads-up (and thanks for accepting my answer).
– PM 2Ring
Dec 21 '16 at 5:21
add a comment |
This produces redundant and invalid elements if input is shorter than 16 bytes.
– Cengiz Can
Dec 27 '14 at 10:03
@CengizCan: :oops:! Is that better?
– PM 2Ring
Dec 27 '14 at 10:38
1
Need to add the-voption tohexdump, otherwise long runs of the same input byte cause output lines that say"*".
– Malvineous
Dec 21 '16 at 3:45
@Malvineous Good point! I've amended my answer. Thanks for the heads-up (and thanks for accepting my answer).
– PM 2Ring
Dec 21 '16 at 5:21
This produces redundant and invalid elements if input is shorter than 16 bytes.
– Cengiz Can
Dec 27 '14 at 10:03
This produces redundant and invalid elements if input is shorter than 16 bytes.
– Cengiz Can
Dec 27 '14 at 10:03
@CengizCan: :oops:! Is that better?
– PM 2Ring
Dec 27 '14 at 10:38
@CengizCan: :oops:! Is that better?
– PM 2Ring
Dec 27 '14 at 10:38
1
1
Need to add the
-v option to hexdump, otherwise long runs of the same input byte cause output lines that say "*".– Malvineous
Dec 21 '16 at 3:45
Need to add the
-v option to hexdump, otherwise long runs of the same input byte cause output lines that say "*".– Malvineous
Dec 21 '16 at 3:45
@Malvineous Good point! I've amended my answer. Thanks for the heads-up (and thanks for accepting my answer).
– PM 2Ring
Dec 21 '16 at 5:21
@Malvineous Good point! I've amended my answer. Thanks for the heads-up (and thanks for accepting my answer).
– PM 2Ring
Dec 21 '16 at 5:21
add a comment |
xxd has a mode for this. The -i/--include option will:
output in C include file style. A complete static array definition is written (named after the input file), unless xxd reads from stdin.
You can dump that into a file to be #included, and then just access foo like any other character array (or link it in). It also includes a declaration of the length of the array.
The output is wrapped to 80 bytes and looks essentially like what you might write by hand:
$ xxd --include foo
unsigned char foo = {
0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64,
0x21, 0x0a, 0x0a, 0x59, 0x6f, 0x75, 0x27, 0x72, 0x65, 0x20, 0x76, 0x65,
0x72, 0x79, 0x20, 0x63, 0x75, 0x72, 0x69, 0x6f, 0x75, 0x73, 0x21, 0x20,
0x57, 0x65, 0x6c, 0x6c, 0x20, 0x64, 0x6f, 0x6e, 0x65, 0x2e, 0x0a
};
unsigned int foo_len = 47;
xxd is, somewhat oddly, part of the vim distribution, so you likely have it already. If not, that's where you get it — you can also build the tool on its own out of the vim source.
Nice! I didn't even know I had xxd. Now I just have to remember it exists next time I need it... or I'll probably just replicate the required functionality in Python. :)
– PM 2Ring
Dec 27 '14 at 7:01
objcopywould be better
– Lightness Races in Orbit
Dec 28 '14 at 0:55
@LightnessRacesinOrbitobjcopywould allow OP to link the binary data with the executable as an object file, which is useful but not exactly what's being asked here.
– Wander Nauta
Dec 28 '14 at 13:38
1
@WanderNauta: You would access it in pretty much the same way as you'd accessfoo/foo_lenhere, and you wouldn't be vastly wasting storage space. I am convinced that the OP would be better off withobjcopyand that it suits his or her requirements.
– Lightness Races in Orbit
Dec 28 '14 at 13:49
1
objcopyis fine when it's around, but it's not portable and the output even less so. It can certainly be part of a good permanent solution, but that isn't the question here.
– Michael Homer
Dec 28 '14 at 18:15
add a comment |
xxd has a mode for this. The -i/--include option will:
output in C include file style. A complete static array definition is written (named after the input file), unless xxd reads from stdin.
You can dump that into a file to be #included, and then just access foo like any other character array (or link it in). It also includes a declaration of the length of the array.
The output is wrapped to 80 bytes and looks essentially like what you might write by hand:
$ xxd --include foo
unsigned char foo = {
0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64,
0x21, 0x0a, 0x0a, 0x59, 0x6f, 0x75, 0x27, 0x72, 0x65, 0x20, 0x76, 0x65,
0x72, 0x79, 0x20, 0x63, 0x75, 0x72, 0x69, 0x6f, 0x75, 0x73, 0x21, 0x20,
0x57, 0x65, 0x6c, 0x6c, 0x20, 0x64, 0x6f, 0x6e, 0x65, 0x2e, 0x0a
};
unsigned int foo_len = 47;
xxd is, somewhat oddly, part of the vim distribution, so you likely have it already. If not, that's where you get it — you can also build the tool on its own out of the vim source.
Nice! I didn't even know I had xxd. Now I just have to remember it exists next time I need it... or I'll probably just replicate the required functionality in Python. :)
– PM 2Ring
Dec 27 '14 at 7:01
objcopywould be better
– Lightness Races in Orbit
Dec 28 '14 at 0:55
@LightnessRacesinOrbitobjcopywould allow OP to link the binary data with the executable as an object file, which is useful but not exactly what's being asked here.
– Wander Nauta
Dec 28 '14 at 13:38
1
@WanderNauta: You would access it in pretty much the same way as you'd accessfoo/foo_lenhere, and you wouldn't be vastly wasting storage space. I am convinced that the OP would be better off withobjcopyand that it suits his or her requirements.
– Lightness Races in Orbit
Dec 28 '14 at 13:49
1
objcopyis fine when it's around, but it's not portable and the output even less so. It can certainly be part of a good permanent solution, but that isn't the question here.
– Michael Homer
Dec 28 '14 at 18:15
add a comment |
xxd has a mode for this. The -i/--include option will:
output in C include file style. A complete static array definition is written (named after the input file), unless xxd reads from stdin.
You can dump that into a file to be #included, and then just access foo like any other character array (or link it in). It also includes a declaration of the length of the array.
The output is wrapped to 80 bytes and looks essentially like what you might write by hand:
$ xxd --include foo
unsigned char foo = {
0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64,
0x21, 0x0a, 0x0a, 0x59, 0x6f, 0x75, 0x27, 0x72, 0x65, 0x20, 0x76, 0x65,
0x72, 0x79, 0x20, 0x63, 0x75, 0x72, 0x69, 0x6f, 0x75, 0x73, 0x21, 0x20,
0x57, 0x65, 0x6c, 0x6c, 0x20, 0x64, 0x6f, 0x6e, 0x65, 0x2e, 0x0a
};
unsigned int foo_len = 47;
xxd is, somewhat oddly, part of the vim distribution, so you likely have it already. If not, that's where you get it — you can also build the tool on its own out of the vim source.
xxd has a mode for this. The -i/--include option will:
output in C include file style. A complete static array definition is written (named after the input file), unless xxd reads from stdin.
You can dump that into a file to be #included, and then just access foo like any other character array (or link it in). It also includes a declaration of the length of the array.
The output is wrapped to 80 bytes and looks essentially like what you might write by hand:
$ xxd --include foo
unsigned char foo = {
0x48, 0x65, 0x6c, 0x6c, 0x6f, 0x2c, 0x20, 0x77, 0x6f, 0x72, 0x6c, 0x64,
0x21, 0x0a, 0x0a, 0x59, 0x6f, 0x75, 0x27, 0x72, 0x65, 0x20, 0x76, 0x65,
0x72, 0x79, 0x20, 0x63, 0x75, 0x72, 0x69, 0x6f, 0x75, 0x73, 0x21, 0x20,
0x57, 0x65, 0x6c, 0x6c, 0x20, 0x64, 0x6f, 0x6e, 0x65, 0x2e, 0x0a
};
unsigned int foo_len = 47;
xxd is, somewhat oddly, part of the vim distribution, so you likely have it already. If not, that's where you get it — you can also build the tool on its own out of the vim source.
edited Dec 27 '14 at 6:44
answered Dec 27 '14 at 6:38
Michael HomerMichael Homer
47.1k8124162
47.1k8124162
Nice! I didn't even know I had xxd. Now I just have to remember it exists next time I need it... or I'll probably just replicate the required functionality in Python. :)
– PM 2Ring
Dec 27 '14 at 7:01
objcopywould be better
– Lightness Races in Orbit
Dec 28 '14 at 0:55
@LightnessRacesinOrbitobjcopywould allow OP to link the binary data with the executable as an object file, which is useful but not exactly what's being asked here.
– Wander Nauta
Dec 28 '14 at 13:38
1
@WanderNauta: You would access it in pretty much the same way as you'd accessfoo/foo_lenhere, and you wouldn't be vastly wasting storage space. I am convinced that the OP would be better off withobjcopyand that it suits his or her requirements.
– Lightness Races in Orbit
Dec 28 '14 at 13:49
1
objcopyis fine when it's around, but it's not portable and the output even less so. It can certainly be part of a good permanent solution, but that isn't the question here.
– Michael Homer
Dec 28 '14 at 18:15
add a comment |
Nice! I didn't even know I had xxd. Now I just have to remember it exists next time I need it... or I'll probably just replicate the required functionality in Python. :)
– PM 2Ring
Dec 27 '14 at 7:01
objcopywould be better
– Lightness Races in Orbit
Dec 28 '14 at 0:55
@LightnessRacesinOrbitobjcopywould allow OP to link the binary data with the executable as an object file, which is useful but not exactly what's being asked here.
– Wander Nauta
Dec 28 '14 at 13:38
1
@WanderNauta: You would access it in pretty much the same way as you'd accessfoo/foo_lenhere, and you wouldn't be vastly wasting storage space. I am convinced that the OP would be better off withobjcopyand that it suits his or her requirements.
– Lightness Races in Orbit
Dec 28 '14 at 13:49
1
objcopyis fine when it's around, but it's not portable and the output even less so. It can certainly be part of a good permanent solution, but that isn't the question here.
– Michael Homer
Dec 28 '14 at 18:15
Nice! I didn't even know I had xxd. Now I just have to remember it exists next time I need it... or I'll probably just replicate the required functionality in Python. :)
– PM 2Ring
Dec 27 '14 at 7:01
Nice! I didn't even know I had xxd. Now I just have to remember it exists next time I need it... or I'll probably just replicate the required functionality in Python. :)
– PM 2Ring
Dec 27 '14 at 7:01
objcopy would be better– Lightness Races in Orbit
Dec 28 '14 at 0:55
objcopy would be better– Lightness Races in Orbit
Dec 28 '14 at 0:55
@LightnessRacesinOrbit
objcopy would allow OP to link the binary data with the executable as an object file, which is useful but not exactly what's being asked here.– Wander Nauta
Dec 28 '14 at 13:38
@LightnessRacesinOrbit
objcopy would allow OP to link the binary data with the executable as an object file, which is useful but not exactly what's being asked here.– Wander Nauta
Dec 28 '14 at 13:38
1
1
@WanderNauta: You would access it in pretty much the same way as you'd access
foo/foo_len here, and you wouldn't be vastly wasting storage space. I am convinced that the OP would be better off with objcopy and that it suits his or her requirements.– Lightness Races in Orbit
Dec 28 '14 at 13:49
@WanderNauta: You would access it in pretty much the same way as you'd access
foo/foo_len here, and you wouldn't be vastly wasting storage space. I am convinced that the OP would be better off with objcopy and that it suits his or her requirements.– Lightness Races in Orbit
Dec 28 '14 at 13:49
1
1
objcopy is fine when it's around, but it's not portable and the output even less so. It can certainly be part of a good permanent solution, but that isn't the question here.– Michael Homer
Dec 28 '14 at 18:15
objcopy is fine when it's around, but it's not portable and the output even less so. It can certainly be part of a good permanent solution, but that isn't the question here.– Michael Homer
Dec 28 '14 at 18:15
add a comment |
xxd is good but the result is highly verbose and takes a lot of storage space.
You can achieve practically the same thing using objcopy; e.g.
objcopy --input binary
--output elf32-i386
--binary-architecture i386 foo foo.o
Then link foo.o to your program and simply use the following symbols:
00000550 D _binary_foo_end
00000550 A _binary_foo_size
00000000 D _binary_foo_start
This is not a string literal, but it's essentially the same thing as what a string literal turns into during compilation (consider that string literals do not in fact exist at run-time; indeed, none of the other answers actually give you a string literal even at compile-time) and can be accessed in largely the same way:
unsigned char* ptr = _binary_foo_start;
int i;
for (i = 0; i < _binary_foo_size; i++, ptr++)
putc(*ptr);
The downside is that you need to specify your target architecture to make the object file compatible, and this may not be trivial in your build system.
add a comment |
xxd is good but the result is highly verbose and takes a lot of storage space.
You can achieve practically the same thing using objcopy; e.g.
objcopy --input binary
--output elf32-i386
--binary-architecture i386 foo foo.o
Then link foo.o to your program and simply use the following symbols:
00000550 D _binary_foo_end
00000550 A _binary_foo_size
00000000 D _binary_foo_start
This is not a string literal, but it's essentially the same thing as what a string literal turns into during compilation (consider that string literals do not in fact exist at run-time; indeed, none of the other answers actually give you a string literal even at compile-time) and can be accessed in largely the same way:
unsigned char* ptr = _binary_foo_start;
int i;
for (i = 0; i < _binary_foo_size; i++, ptr++)
putc(*ptr);
The downside is that you need to specify your target architecture to make the object file compatible, and this may not be trivial in your build system.
add a comment |
xxd is good but the result is highly verbose and takes a lot of storage space.
You can achieve practically the same thing using objcopy; e.g.
objcopy --input binary
--output elf32-i386
--binary-architecture i386 foo foo.o
Then link foo.o to your program and simply use the following symbols:
00000550 D _binary_foo_end
00000550 A _binary_foo_size
00000000 D _binary_foo_start
This is not a string literal, but it's essentially the same thing as what a string literal turns into during compilation (consider that string literals do not in fact exist at run-time; indeed, none of the other answers actually give you a string literal even at compile-time) and can be accessed in largely the same way:
unsigned char* ptr = _binary_foo_start;
int i;
for (i = 0; i < _binary_foo_size; i++, ptr++)
putc(*ptr);
The downside is that you need to specify your target architecture to make the object file compatible, and this may not be trivial in your build system.
xxd is good but the result is highly verbose and takes a lot of storage space.
You can achieve practically the same thing using objcopy; e.g.
objcopy --input binary
--output elf32-i386
--binary-architecture i386 foo foo.o
Then link foo.o to your program and simply use the following symbols:
00000550 D _binary_foo_end
00000550 A _binary_foo_size
00000000 D _binary_foo_start
This is not a string literal, but it's essentially the same thing as what a string literal turns into during compilation (consider that string literals do not in fact exist at run-time; indeed, none of the other answers actually give you a string literal even at compile-time) and can be accessed in largely the same way:
unsigned char* ptr = _binary_foo_start;
int i;
for (i = 0; i < _binary_foo_size; i++, ptr++)
putc(*ptr);
The downside is that you need to specify your target architecture to make the object file compatible, and this may not be trivial in your build system.
answered Dec 28 '14 at 13:57
Lightness Races in OrbitLightness Races in Orbit
285211
285211
add a comment |
add a comment |
Should be exactly what you asked for:
hexdump -v -e '"\" "x" 1/1 "%02X"' file.bin ; echo
add a comment |
Should be exactly what you asked for:
hexdump -v -e '"\" "x" 1/1 "%02X"' file.bin ; echo
add a comment |
Should be exactly what you asked for:
hexdump -v -e '"\" "x" 1/1 "%02X"' file.bin ; echo
Should be exactly what you asked for:
hexdump -v -e '"\" "x" 1/1 "%02X"' file.bin ; echo
answered Sep 14 '16 at 10:00
SchtrudelSchtrudel
211
211
add a comment |
add a comment |
This is a short utility I wrote that essentially does the same thing (originally posted on Stack Overflow):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_LENGTH 80
int main(void)
{
FILE *fout = fopen("out.txt", "w");
if(ferror(fout))
{
fprintf(stderr, "Error opening output file");
return 1;
}
char init_line = {"char hex_array = { "};
const int offset_length = strlen(init_line);
char offset_spc[offset_length];
unsigned char buff[1024];
char curr_out[64];
int count, i;
int line_length = 0;
memset((void*)offset_spc, (char)32, sizeof(char) * offset_length - 1);
offset_spc[offset_length - 1] = '';
fprintf(fout, "%s", init_line);
while(!feof(stdin))
{
count = fread(buff, sizeof(char), sizeof(buff) / sizeof(char), stdin);
for(i = 0; i < count; i++)
{
line_length += sprintf(curr_out, "%#x, ", buff[i]);
fprintf(fout, "%s", curr_out);
if(line_length >= MAX_LENGTH - offset_length)
{
fprintf(fout, "n%s", offset_spc);
line_length = 0;
}
}
}
fseek(fout, -2, SEEK_CUR);
fprintf(fout, " };");
fclose(fout);
return EXIT_SUCCESS;
}
1
Your answer would be more useful if you also provided the input and output examples with it.
– not2qubit
Mar 7 '15 at 13:43
add a comment |
This is a short utility I wrote that essentially does the same thing (originally posted on Stack Overflow):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_LENGTH 80
int main(void)
{
FILE *fout = fopen("out.txt", "w");
if(ferror(fout))
{
fprintf(stderr, "Error opening output file");
return 1;
}
char init_line = {"char hex_array = { "};
const int offset_length = strlen(init_line);
char offset_spc[offset_length];
unsigned char buff[1024];
char curr_out[64];
int count, i;
int line_length = 0;
memset((void*)offset_spc, (char)32, sizeof(char) * offset_length - 1);
offset_spc[offset_length - 1] = '';
fprintf(fout, "%s", init_line);
while(!feof(stdin))
{
count = fread(buff, sizeof(char), sizeof(buff) / sizeof(char), stdin);
for(i = 0; i < count; i++)
{
line_length += sprintf(curr_out, "%#x, ", buff[i]);
fprintf(fout, "%s", curr_out);
if(line_length >= MAX_LENGTH - offset_length)
{
fprintf(fout, "n%s", offset_spc);
line_length = 0;
}
}
}
fseek(fout, -2, SEEK_CUR);
fprintf(fout, " };");
fclose(fout);
return EXIT_SUCCESS;
}
1
Your answer would be more useful if you also provided the input and output examples with it.
– not2qubit
Mar 7 '15 at 13:43
add a comment |
This is a short utility I wrote that essentially does the same thing (originally posted on Stack Overflow):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_LENGTH 80
int main(void)
{
FILE *fout = fopen("out.txt", "w");
if(ferror(fout))
{
fprintf(stderr, "Error opening output file");
return 1;
}
char init_line = {"char hex_array = { "};
const int offset_length = strlen(init_line);
char offset_spc[offset_length];
unsigned char buff[1024];
char curr_out[64];
int count, i;
int line_length = 0;
memset((void*)offset_spc, (char)32, sizeof(char) * offset_length - 1);
offset_spc[offset_length - 1] = '';
fprintf(fout, "%s", init_line);
while(!feof(stdin))
{
count = fread(buff, sizeof(char), sizeof(buff) / sizeof(char), stdin);
for(i = 0; i < count; i++)
{
line_length += sprintf(curr_out, "%#x, ", buff[i]);
fprintf(fout, "%s", curr_out);
if(line_length >= MAX_LENGTH - offset_length)
{
fprintf(fout, "n%s", offset_spc);
line_length = 0;
}
}
}
fseek(fout, -2, SEEK_CUR);
fprintf(fout, " };");
fclose(fout);
return EXIT_SUCCESS;
}
This is a short utility I wrote that essentially does the same thing (originally posted on Stack Overflow):
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define MAX_LENGTH 80
int main(void)
{
FILE *fout = fopen("out.txt", "w");
if(ferror(fout))
{
fprintf(stderr, "Error opening output file");
return 1;
}
char init_line = {"char hex_array = { "};
const int offset_length = strlen(init_line);
char offset_spc[offset_length];
unsigned char buff[1024];
char curr_out[64];
int count, i;
int line_length = 0;
memset((void*)offset_spc, (char)32, sizeof(char) * offset_length - 1);
offset_spc[offset_length - 1] = '';
fprintf(fout, "%s", init_line);
while(!feof(stdin))
{
count = fread(buff, sizeof(char), sizeof(buff) / sizeof(char), stdin);
for(i = 0; i < count; i++)
{
line_length += sprintf(curr_out, "%#x, ", buff[i]);
fprintf(fout, "%s", curr_out);
if(line_length >= MAX_LENGTH - offset_length)
{
fprintf(fout, "n%s", offset_spc);
line_length = 0;
}
}
}
fseek(fout, -2, SEEK_CUR);
fprintf(fout, " };");
fclose(fout);
return EXIT_SUCCESS;
}
edited May 23 '17 at 12:39
Community♦
1
1
answered Dec 27 '14 at 22:21
TannerTanner
1011
1011
1
Your answer would be more useful if you also provided the input and output examples with it.
– not2qubit
Mar 7 '15 at 13:43
add a comment |
1
Your answer would be more useful if you also provided the input and output examples with it.
– not2qubit
Mar 7 '15 at 13:43
1
1
Your answer would be more useful if you also provided the input and output examples with it.
– not2qubit
Mar 7 '15 at 13:43
Your answer would be more useful if you also provided the input and output examples with it.
– not2qubit
Mar 7 '15 at 13:43
add a comment |
If you are into python, load it into a variable "buff" and use something like this:
buff2 = buff.encode("hex")
print ("0x"+", 0x".join([buff2[i:i+2] for i in range(0,len(buff2),2)]))
add a comment |
If you are into python, load it into a variable "buff" and use something like this:
buff2 = buff.encode("hex")
print ("0x"+", 0x".join([buff2[i:i+2] for i in range(0,len(buff2),2)]))
add a comment |
If you are into python, load it into a variable "buff" and use something like this:
buff2 = buff.encode("hex")
print ("0x"+", 0x".join([buff2[i:i+2] for i in range(0,len(buff2),2)]))
If you are into python, load it into a variable "buff" and use something like this:
buff2 = buff.encode("hex")
print ("0x"+", 0x".join([buff2[i:i+2] for i in range(0,len(buff2),2)]))
answered Sep 29 '16 at 0:14
TimSCTimSC
1412
1412
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f176111%2fhow-to-dump-a-binary-file-as-a-c-c-string-literal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
stackoverflow.com/q/13856930/560648
– Lightness Races in Orbit
Dec 28 '14 at 0:53