33

I have read this quote (below) several times, most recently here, and am continually puzzled at how dd can be used to patch anything let alone a compiler:

The Unix system I used at school, 30 years ago, was very limited in RAM and Disk space. Especially, the /usr/tmp file system was very small, which led to problems when someone tried to compile a large program. Of course, students weren't supposed to write "large programs" anyway; large programs were typically source codes copied from "somewhere". Many of us copied /usr/bin/cc to /home/<myname>/cc, and used dd to patch the binary to use /tmp instead of /usr/tmp, which was bigger. Of course, this just made the problem worse - the disk space occupied by these copies did matter those days, and now /tmp filled up regularly, preventing other users from even editing their files. After they found out what happened, the sysadmins did a chmod go-r /bin/* /usr/bin/* which "fixed" the problem, and deleted all our copies of the C compiler.

(Emphasis mine)

The dd man-page says nothing about patching and a don't think it could be re-purposed to do this anyway.

Could binaries really be patched with dd? Is there any historical significance to this?

Community
  • 1
amziraro
  • 467
  • 1
  • 4
  • 8
  • 3
    Sure - just `od` a file for the byte hex codes, find the offset you need, decide on your edit, and `bs=$patchsize count=1 seek=$((offset/bs)) conv=notrunc` your patch right on in. – mikeserv Jul 09 '15 at 09:32
  • 3
    Someone's never overwritten a boot sector. ;) – Parthian Shot Jul 10 '15 at 01:05
  • @ParthianShot Actually I overwrote the first ~260MB of my boot drive (+ root) with part of a Debian LiveCD once. O_o But I don't think that is really patching, hehehe... – amziraro Jul 10 '15 at 02:01
  • 1
    Or rather, that is the expected and totally normal behaviour of the Disk Destroyer :D – amziraro Jul 10 '15 at 02:07

3 Answers3

83

Let's try it. Here's a trivial C program:

#include <stdio.h>
int main(int argc, char **argv) {
    puts("/usr/tmp");
}

We'll build that into test:

$ cc -o test test.c

If we run it, it prints "/usr/tmp".

Let's find out where "/usr/tmp" is in the binary:

$ strings -t d test | grep /usr/tmp
1460 /usr/tmp

-t d prints the offset in decimal into the file of each string it finds.

Now let's make a temporary file with just "/tmp\0" in it:

$ printf "/tmp\x00" > tmp

So now we have the binary, we know where the string we want to change is, and we have a file with the replacement string in it.

Now we can use dd:

$ dd if=tmp of=test obs=1 seek=1460 conv=notrunc

This reads data from tmp (our "/tmp\0" file), writing it into our binary, using an output block size of 1 byte, skipping to the offset we found earlier before it writes anything, and explicitly not truncating the file when it's done.

We can run the patched executable:

$ ./test
/tmp

The string literal the program prints out has been changed, so it now contains "/tmp\0tmp\0", but the string functions stop as soon as they see the first null byte. This patching only allows making the string shorter or the same length, and not longer, but it's adequate for these purposes.

So not only can we patch things using dd, we've just done it.

Michael Homer
  • 74,824
  • 17
  • 212
  • 233
  • 3
    This is excellent... and something I strongly hope I never encounter in a production environment! I have used similar methods in the past to get serial numbers into hex images for microcontrollers, it's far too easy to shoot yourself in the foot though. – Michael Shaw Jul 09 '15 at 13:36
  • If i wanted to give written instructions to someone how to patch a particular binary, i'd rather give them a command line to copy/paste than tell them "open the file in a hex editor, find the `/usr/tmp` string, replace it with `/tmp`, don't forget the trailing `\0` byte, save the file, and cross your fingers". Or, even better, a shell script that does some sanity checking first, then calls `dd`. Unfortunately, the need for stuff like this arises frequently when an old piece of software by a now-defunct vendor just *has* to be migrated to a new system. – Guntram Blohm Jul 09 '15 at 16:21
  • Yeah, sed's better for this kind of thing. But you're not completely right about the whole "This patching only allows making the string shorter or the same length, and not longer". You're assuming that you care about the data immediately following the string you want to modify, or that you can't have the next string simply be a substring of the original string. In other words, if you're in the .strings section of memory, and you've got "/usr\0/bin/bash\0", you can turn that into /usr/bin/bash by simply changing that first null byte and making it "/usr//bin/bash" (for example). – Parthian Shot Jul 10 '15 at 01:04
  • 3
    @ParthianShot - `sed`'s *not* better for this kind of thing - you cannot so expliciltly and precisely limit `sed`'s read/write buffers in the way you might with `dd` - which is the whole reason it was ever used for this in the first place. With `dd` you can arbitrarily place an arbitrary count of arbitrary bytes. This cannot also be said of `sed`. If `dd` is used like a scalpel here, you would apply `sed` like a wrecking ball. – mikeserv Jul 10 '15 at 02:21
  • That's a fair (albeit fairly rare!) point - there will be occasions when you can make the string longer by not caring about either the result or another arbitrary, but specific, piece of data. I'll stand by the general statement, though. – Michael Homer Jul 10 '15 at 02:23
  • Very nice example. I think in early Unix releases with memory image binaries and no shared libraries it was easy to increase the length of the string as you were certain that was what was in the executable would be loaded into memory as-is. – mjturner Jul 10 '15 at 09:13
  • @mikeserv Well, you make a valid point about being exact with memory locations, but it's often easier and more readable (if you know a string only appears once) to use sed. Usually I'm patching long enough / specific enough sequences of bytes that there's no ambiguity. So, it's only a wrecking ball if you don't run `grep -o my_string | wc -l` first. If I'm trying to alter a timestamp or cryptographic signature in a binary, for example, that's usually an int / array that's only going to appear once. – Parthian Shot Jul 10 '15 at 15:09
  • @ParthianShot - well, that's not what I meant exactly - `sed` is blocked. It's builtin - it works on lines *(though w/ GNU you can use `-z` to swap that delimiter for NULs)*. So you don't get to aim, really. It's ok for a static binary file - like in your filesystem, but patching the memory - a moving target *(which I think is the more interesting application, here)* - is not a thing you'd want to do with any but `dd` or some specially written tool. It should be *atomic* - a single write exactly where you want it, and nowhere else. That's why I would do the math first, and do `bs=... count=1`. – mikeserv Jul 10 '15 at 16:36
  • @mikeserv Good point. Hadn't considered someone would want to patch `/dev/mem` directly. – Parthian Shot Jul 10 '15 at 17:23
  • This was just brilliant! This was super useful! – William Martens Jul 14 '23 at 11:31
10

It depends on what you mean by "patch the binary".

I change binaries using dd sometimes. Of course there is no such feature in dd, but it can open files, and read and write things at specific offsets, so if you know what to write where, voila there is your patch.

For example I had this binary that contained some PNG data. Use binwalk to find the offset, dd to extract it (usually binwalk also extracts things but my copy was buggy), edit it with gimp, make sure the edited file is same size or smaller than the original one (changing offsets is not something you can do easily), and then use dd to put the changed image back in place.

$ binwalk thebinary
[…]
4194643    0x400153     PNG image, 800 x 160, 8-bit/color RGB, non-interlaced
[…]
$ dd if=nickel bs=1 skip=4194641 count=2 conv=swab | od -i
21869 # file size in this case - depends on the binary format
$ dd if=thebinary bs=1 skip=4194643 count=21869 of=theimage.png
$ gimp theimage.png
$ pngcrush myimage.png myimage.crush.png
# make sure myimage.crush.png is smaller than the original
$ dd if=myimage.crush.png of=thebinary bs=1 seek=4194643 conv=notrunc

Sometimes I also wish to replace strings in binaries (such as path or variable names). While this could also be done using dd, it is simpler to do so using sed. You just have to make sure the string you replace with has the same length as the original string so you don't end up changing offsets.

sed -e s@/the/old/save/path@/the/new/save/path@ -i thebinary

or to pick up @MichaelHomer's example with a 0-byte added in:

sed -e 's@/usr/tmp@/tmp\x00tmp@' -i test

Of course you have to verify whether it actually works afterwards.

frostschutz
  • 47,228
  • 5
  • 112
  • 159
  • ... assuming you have a `sed` that handles binary files well, which seems to be the case with gnu `sed`, but not with many of the older `sed`s which worked on ascii files only, got confused with anything else (especially `\0`s in the input), *and* had restrictions on maximum line length. – Guntram Blohm Jul 09 '15 at 16:12
  • 1
    busybox `sed` seems to be able to change binary files fine but it does not understand `\x00` in the replacement string the way GNU `sed` does. It requires testing but even so I think it's worth mentioning since it's so much simpler than `dd` - for some cases. Patching binaries is a flakey business either way. – frostschutz Jul 09 '15 at 16:44
  • patching seems to mean overwriting existing binary data in a file (which may even change the file size) – Zimba Jan 28 '21 at 14:02
1

Yes, binaries can be patched with dd.

To patch a file with data from stdin:

dd of=file.bin bs=1 count=2 conv=notrunc

Then enter the (text) data to be patched with. The above only patches 2 bytes (from file beginning), even if more than 2 characters are entered at prompt.
To patch middle of file, supply position (address) of file data via seek to begin patching. eg.

dd of=file.out bs=1 count=2 seek=2 conv=notrunc

or

echo "<address: data>" | xxd -r - file.out

If patching non-printable characters, make a binary temp file with data to be patched. eg.

dd if=file.in of=file.out bs=1 count=2 seek=2 conv=notrunc

or

xxd -r hexoffsets.in file.out

or supply hex data with offset on stdin

echo "<address: hex-data>" | xxd -r - file.out

Definition:
Patch means to convert hexdump into binary (from xxd manpage)

Tested on Ubuntu 16.04.7

Zimba
  • 141
  • 3