I'd follow the suggestions above and do a rewrite instead of patching up the broken program. But even if I were to patch it up, here's my approach (free, and thus, worth its price) :

1. First, make a backup of all files that seem remotely interesting, and store that backup on a CD, on a directory of the same machine, and possibly in your personal workspace somewhere.
2. Set up your modified version, be it the patch or the rewrite, in a different directory than the original file. Use symlinks for data files if necessary, or better, use copies.
3. Test your program in parallel to the original - check that the output of your new program is identical to the output of the original. You will face interesting challenges if the original modifies the input data - then you might have to isolate/rewrite the input and output routines to create a copy of the input and output, praying that the original program still works (You did make the backups, right ?).
4. In each development step, compare your output against the original output (Perl can do this for you). Thus, you will end up with a program that is not as broken as the original, but works the same.
5. At some time, you will decide that the original produces wrong data. Ask another, non-technical, person who should know what they're doing, if your data seems more correct than the original data. If the modification is OK, adapt your test result routine to accomodate for the difference in output, and go on.

This strategy will keep you close to the original, whatever way you chose to implement the functionality of the original. But by forcing your input/output to be the same, you are also bounded by those design decisions and miss the chance to refactor the whole process. But as the whole process seems to be lost in the winds of time, first trying a local fix seems much more manageable.