Re: c00l hack
Article: 7591 of alt.hackers From: cjfred@clark.net (Chris Frederick) Newsgroups: alt.hackers Subject: Re: c00l hack Date: 4 Apr 1995 00:58:26 -0400 Organization: Clark Internet Services, Ellicott City, MD Lines: 31 Approved: abundy@shoestore.chicago.il.us Message-ID: 3lqjli$kgg@clark.net NNTP-Posting-Host: clark.net Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Status: RO
In article <3lqcbn$h6h@case.cyberspace.com>, Wes Santee <wsantee@cyberspace.com> wrote: > Hmmmm, while we're on the data recovery motif, I remember when I had > to talk a guy through a complete drive rebuild over the phone. Ugh. I do phone support at work, and holding the user's hand through recovering a drive from scratch doesn't sound like much fun. ObTechSupportHack: A user reported that the print-screen capability of my company's Unix software package didn't work in the online help utility. The user urgently needed to print out some help pages, so I looked at the source code and discovered that a programmer had accidentally used '%d' rather than '%s' in a sprintf() format string. This caused the Unix "lp" command to be called with a number instead of a filename as an argument. Rather than rebuild the (rather large) program and upload it over a slow modem connection, I hoped to patch the single byte in question. I located the offset of the byte in the executable via "strings", but the computer had no C compiler, which shot down my plan of using a program to simply seek to the byte and overwrite it with a new one. Instead, I used two "dd" commands to extract the data leading up to the byte and the data after the byte into separate files, and then concatenated the two with the new byte in between. The new executable worked like a charm. -- It is hard to be religious when certain | Chris Frederick (cjfred@clark.net) people fail to be incinerated by bolts | FTP : ftp.clark.net:/pub/cjfred of lightning. - Calvin | URL : http://www.clark.net/pub/cjfred