In a hex dump, each byte (8 bits) is represented as a two-digit hexadecimal number. Hex dumps are commonly organized into rows of 8 or 16 bytes, sometimes separated by whitespaces. Some hex dumps have the hexadecimal memory address at the beginning.
Hexdump is a utility that displays the contents of binary files in hexadecimal, decimal, octal, or ASCII. It's a utility for inspection and can be used for data recovery, reverse engineering, and programming.
The address of a hex dump counts tracks the number of bytes in the data and offsets each line by that number. So the first line starts at offset 0, and the second line represents the number 16, which is how many bytes precede the current line. 10 is 16 in hexadecimal, which we'll go into farther along in this article.
xxd -p file
Or if you want it all on a single line:
xxd -p file | tr -d '\n'
Format strings can make hexdump behave exactly as you want it to (no whitespace at all, byte by byte):
hexdump -ve '1/1 "%.2x"'
1/1
means "each format is applied once and takes one byte", and "%.2x"
is the actual format string, like in printf. In this case: 2-character hexadecimal number, leading zeros if shorter.
It seems to depend on the details of the version of od
. On OSX, use this:
od -t x1 -An file |tr -d '\n '
(That's print as type hex bytes, with no address. And whitespace deleted afterwards, of course.)
Perl one-liner:
perl -e 'local $/; print unpack "H*", <>' file
The other answers are preferable, but for a pure Bash solution, I've modified the script in my answer here to be able to output a continuous stream of hex characters representing the contents of a file. (Its normal mode is to emulate hexdump -C
.)
I think this is the most widely supported version (requiring only POSIX defined tr
and od
behavior):
cat "$file" | od -v -t x1 -A n | tr -d ' \n'
This uses od
to print each byte as hex without address without skipping repeated bytes and tr
to delete all spaces and linefeeds in the output. Note that not even the trailing linefeed is emitted here. (The cat
is intentional to allow multicore processing where cat
can wait for filesystem while od
is still processing previously read part. Single core users may want replace that with < "$file" od ...
to save starting one additional process.)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With