Stories
Slash Boxes
Comments

SoylentNews is people

Editing Binaries: Easier Than It Sounds

posted by janrinok on Monday March 24 2014, @08:51PM   Printer-friendly
from the not-for-the-faint-hearted dept.

Anonymous Coward writes:

"Dan Luu, in his blog, suggests that editing binaries is something that we should consider from time to time. From that blog:

Editing binaries is a trick that comes in handy a few times a year. You don't often need to, but when you do, there's no alternative. When I mention patching binaries, I get one of two reactions: complete shock or no reaction at all. As far as I can tell, this is because most people have one of these two models of the world:

  • There exists source code. Compilers do something to source code to make it runnable. If you change the source code, different things happen.
  • There exists a processor. The processor takes some bits and decodes them to make things happen. If you change the bits, different things happen.

If you have the first view, breaking out a hex editor to modify a program is the action of a deranged lunatic. If you have the second view, editing binaries is the most natural thing in the world. Why wouldn't you just edit the binary?"

 
This discussion has been archived. No new comments can be posted.
Editing Binaries: Easier Than It Sounds | Log In/Create an Account | Top | 37 comments | Search Discussion
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

  • (Score: 1) by iWantToKeepAnon on Tuesday March 25 2014, @04:27PM

    by iWantToKeepAnon (686) on Tuesday March 25 2014, @04:27PM (#21036) Homepage Journal

    In college we had a COBOL compiler that must've been left over from DOSv1. It would only use disk drive A: and no subdirectories allowed. It would error out on our "newer" IBM PCs that had more than 128k of RAM; it would say insufficient memory. It must have been retrieving RAM size into a 1 byte signed int (after all, who needs more than 127k?!). And there was no exit status just an onscreen message w/# of errors (it always returned 0 to DOS). So all of these make me think it must've been a DOSv1 "stack".

    The only way to complete your COBOL assignments was to queue up for 1 of the 2 "old" PCs w/ limited RAM. That lost time plus the time swapping out a code disk w/ a compiler disk, then the linker disk was ridiculous.

    I hex edited the EXE to short jump over the memory check call. I loaded some of our "ample" memory into a RAM DISK and used ASSIGN to make the RAM DISK the A: drive. I copied the COBOL compiler disk and the linker disk into the RAM DISK. I wrote a small program to read the line above the cursor and ascertain the number of errors and then abend or exit success. Now I could write a Makefile to compile and link our COBOL assignments. What took 15+ minutes could be done in under a minute (maybe under 30 seconds). The last command of the Makefile was to copy the COBOL source back to the hard drive.

    This was before any FOSS COBOL compiler was available and there was no budget to replace the old clunker. What time I spent on hacking was quickly recovered from having a descent development environment. Good times :))

    --
    "Happy families are all alike; every unhappy family is unhappy in its own way." -- Anna Karenina by Leo Tolstoy