Here's a sample hexdump, produced by xxd: $ cat > /tmp/encoded <<EOF 00000000: 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f ................ 00000010: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................ 00000020: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f !"#$%&'()*+,-./ 00000030: 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f 0123456789:;<=>? 00000040: 40 @ EOF If I run `xxd -r`, I expect to get back the original, 65-byte binary file represented by this hex dump. In other words, `xxd -r /tmp/encoded | xxd` should produce exactly the same encoded representation. It doesn't - `xxd -r` produces a *70*-byte file; 5 bytes have been added after the 64th bit. Here's the full output: $ /bin/busybox xxd -r /tmp/encoded | xxd 00000000: 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f ................ 00000010: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................ 00000020: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f !"#$%&'()*+,-./ 00000030: 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f 0123456789:;<=>? 00000040: 0123 4567 8940 .#Eg.@ ^^^^^^^^^^^^ extra bytes
After further testing, I've found that BusyBox's xxd is copying the first leading hex numerals out of the ASCII column. And it may be doing this because it is not taking the value of the -c option into account - or that may be a separate bug. Here's another example, contrasted with the output of the stand-alone xxd package. $ cat > sample << EOF 00000000: 0100 0000 0000 0000 0000 0000 0000 00ff deadbeef........ EOF BusyBox's reversed interpretation: $ /bin/busybox xxd -r -c2 sample | xxd 00000000: 0100 0000 0000 0000 0000 0000 0000 00ff ................ 00000010: dead beef .... Details of stand-alone package, and how it handles input by default: $ /usr/bin/xxd -v xxd 2022-01-14 by Juergen Weigert et al. $ /usr/bin/xxd -r sample | xxd 00000000: 0100 0000 0000 0000 0000 0000 0000 00ff ................ And how stand-alone package interprets the -c option: $ /usr/bin/xxd -r -c2 sample | xxd 00000000: 0100 ..
Fixed in git