SoylentNews is people
SoylentNews
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
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
It's raisins that make Post Raisin Bran so raisiny ...
(Score: 2, Informative) by jackb_guppy on Monday March 24 2014, @11:10PM
I have hand edit binary for years, Also hand coded (also built Z-80) and inputted the binary into machines. Yeah that was 1970's and 80's. Needed a dup-char in a promotable field of screen object... Code an artistic then hand edit the code to be the dup-char. That was because the dup-char was control character that could not include in source. Especially in screen source of the source editor.
IBM assembler in those days did not have a stack, so when you wrote a subroutine, you would write the first line to Store the return register value into the 3rd and 4th byte of the Load program register. This allowed the return to calling routine. There was no call instruction just branch. If variables where passed, their address followed the branch, so you had to increment that stored value by the number of items, address and field lengths that were past. You need to move a field passed to assembler that is can be different for per each call? Change the 2nd byte of Move instruction to be size of the data to move 00 (1byte) through FF (256 bytes).
Once you get good at this, writing dis-assembler is quite fun!
(Score: 2) by Snotnose on Monday March 24 2014, @11:56PM
Exactly. In the early 80's I worked on an 8086 based system that had a CRT and a keyboard, with an OS that allowed you to poke to memory. A co-worker and I wrote Space Invaders in assembly, hand-encoded the instructions, and punched them into memory. Run it, try to guess why it died, recode, repeat.
Marketing found out about it, grabbed our version before we added having the aliens drop bombs, and it turned into one of their favorite demos at trade shows.
More recently, I worked on a project where a full build took 5-6 hours; if you knew what you were doing you could compile just a couple files in a few seconds, but you still had a 25 minute link to look forward to. I started to put dead code into my file, then when I saw a bug I would hand assemble ARM instructions and use the debugger to poke the new code into memory.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by Reziac on Tuesday March 25 2014, @02:52AM
How do you know when a programmer is really good? He starts with:
COPY CON PROGRAM.ZIP
And there is no Alkibiades to come back and save us from ourselves.