32

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?

  • 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 9 '15 at 9:32
  • 3
    Someone's never overwritten a boot sector. ;) – Parthian Shot Jul 10 '15 at 1: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 2:01
  • 1
    Or rather, that is the expected and totally normal behaviour of the Disk Destroyer :D – Amziraro Jul 10 '15 at 2:07
72

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.

  • 1
    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 9 '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 9 '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 1:04
  • 2
    @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 2: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 2:23
9

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.

  • ... 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 seds which worked on ascii files only, got confused with anything else (especially \0s in the input), and had restrictions on maximum line length. – Guntram Blohm Jul 9 '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 9 '15 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.