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.
TOO BAD YOU CAN'T BUY a voodoo globe so that you could make the earth spin
real fast and freak everybody out.
-- Jack Handey, The New Mexican, 1988.
(Score: 3, Funny) by crutchy on Monday March 24 2014, @08:55PM
you forgot the 3rd reaction: wtf is a binary?
(Score: 0) by Anonymous Coward on Monday March 24 2014, @09:01PM
While the summary mentions "a binary," and by that they're usually talking with respect to compiled executable, but another field that hex/binary editing comes in handy is data-recovery.
If you have a set of data and know the specific format of that data, then you can find errors and manually edit to partially or completely recover the pieces of lost data. I've had to do that a couple times with a not well-known but still industry-standard format, and it worked wonders.
If you want to get into stuff like NES/SNES ROM hacking, strong hex-editing skills are mandatory.
(Score: 2) by mhajicek on Tuesday March 25 2014, @03:22AM
there are 10 kinds of people...
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 3, Interesting) by Nerdfest on Monday March 24 2014, @09:00PM
You certainly wouldn't edit binary unless you absolutely had to. Do you store changes to your binary in source control? How do you integrate edits into a repeatable build process? Editing the binary when you have the source code seems like something you'd do when you couldn't figure out how to achieve your goal through maintainable means.
(Score: 3, Interesting) by The Mighty Buzzard on Monday March 24 2014, @09:15PM
My rights don't end where your fear begins.
(Score: 2) by edIII on Monday March 24 2014, @10:45PM
What I take away from this is a very simplistic view of altering binaries and a complete disconnect with the realities of the world.
At a high level altering binaries makes the most sense and ostensibly seems to be the easiest and most effective.
I completely agree. From a purely user centric point of view that is. As a user I only care about the function of the binary in my own "ecosystem". Concerns the rest of the world have collectively don't mean anything to me. It's my network. If I want the user interface pink, then pink it will be.
Pirates operate this way. Specifically, crackers that only care about altering the function. They can create a patch and get more complicated later. Source? Pirates rarely if ever get to work with source.
In the real world though you have plenty of considerations:
- Development and Production. It's much better to build the entire project all over, test it, and push out an incremental patch than it is to isolate sections and patch production files.
- Updates. I can alter a binary but I lose update capabilities that will swap out binaries and eliminate my work.
- SKILL. I need to actually know how to perform this magic of editing a binary. That's not a regular skill. It requires a fairly sophisticated understanding of the processors, assembly, optimization patterns (??), and the ability to read code like that, and then abstract all of the structures in your head.
It really doesn't matter that this guy is correct about editing binaries in his point of view, the rest of the world barely lacks the capabilities of doing so. That includes a fairly large portion of IT, the force wielding wizards as the rest of world sees them.
I can't edit my own binaries like that. Not even close. I understand it to the extent I know all the different parts of a combustion vehicle, but that doesn't mean I can rebuild my engine. I might be pretty average in that I am capable of writing native code and compiling it. I've altered source and recompiled in Asterisk a few times that's it. I don't qualify for hex editing native binaries and I know first hand only 1 or 2 that do. They might have been full of it.
Most likely it's a skill that few people undertake to develop because corporations don't sponsor that kind of dev/prod environment. So how is it practical to advise the rest of the world to just edit binaries when less than 1% know how?
Technically, lunchtime is at any moment. It's just a wave function.
(Score: 3, Interesting) by The Mighty Buzzard on Tuesday March 25 2014, @12:03AM
Turns out he wasn't talking about directly editing the binaries anyway. He was disassembling them and reassembling them after he made changes. God awful though it may be (worse than perl written by a regex guru), assembly is still source.
I'd thought he was talking directly hex editing them. I've done that to games before but that was way back in the day and I will not be doing it again.
My rights don't end where your fear begins.
(Score: 2) by Snotnose on Monday March 24 2014, @11:59PM
You figure out what in the source code needs to change, fix the source, then edit the binary while you wait for the source to build (or test the change before starting a new build).
Some builds take a while. Some of us prefer to be productive with our time, as opposed to reading Soylent News and Fark during a 30 minute build.
When the dust settled America realized it was saved by a porn star.
(Score: 2) by tangomargarine on Tuesday March 25 2014, @02:36PM
I know that the online community made a patch for Sid Meier's Alpha Centauri to fix a few slightly crippling (for competitive play) bugs, and since the game is closed-source, I can only assume somebody went in with a hex editor. So yeah, in that case it's because they didn't have any choice.
Those two viewpoints are mutually exclusive, either. I'm so glad I had to take that assembly course in college, as it really made the connection between what we do in C-like languages and how that ends up being bits. Not that I could translate compiled machine code even with a code table without going insane, but hey...
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by tangomargarine on Tuesday March 25 2014, @02:39PM
*aren't mutually exclusive. Whoops.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by hybristic on Monday March 24 2014, @09:06PM
I used to do this so I could hack games all the time. after I got to a certain point in most games I found the repetitive parts to be tedious, like collecting currency or travel speeds and I would simply open a hex editor, find the appropriate value and boom done. I also used to play an MMO where you could edit a lot of their files and get things like God Mode or increase monster spawn rates.
I agree with this article though, I have talked about editing binaries with some moderately tech savvy friends, and they get nervous. I think to them its more of the idea that they will change something and then break everything, and have no clue how to fix it. I remember I once had a Linux USB plugged in, and I was editing some files just to see what would happen. Well I ended up not editing the usb but my computers actual root directory and got myself stuck in a boot loop. I imagine that they expect something similar to happen when they deal with the mysterious binaries.
(Score: 3, Interesting) by internetguy on Monday March 24 2014, @09:11PM
When I was in 4th grade my very first hack was to the game "Pitfall". I found the variable "lives" and I changed it to 1000. That's when I decided that I wanted to be a computer programmer.
Sig: I must be new here.
(Score: 4, Interesting) by hybristic on Monday March 24 2014, @10:59PM
That sounds very similar to how I got started. I remember watching my dad play Star Control 2, and I thought it was the coolest thing ever (to be fair it is a great game). So when I picked up a copy off a warez site it came with its own editor. That was the first time I realized that there was code that powered computers, my life was changed forever. For years after that the first thing I would do when I installed a new game was look at the associated files and try to make changes. Modding code eventually turned into writing code. Funny how something so small can change the way you look at the world.
(Score: 3, Interesting) by mhajicek on Tuesday March 25 2014, @03:19AM
In an older version of Moria I found how to set the stats of my equipment in a hex editor. I had a dagger with 99d9.
The spacelike surfaces of time foliations can have a cusp at the surface of discontinuity. - P. Hajicek
(Score: 2) by stormwyrm on Tuesday March 25 2014, @05:51AM
When I was around the same age I did that to Ultima III. DEBUG.COM was all I had, and it sufficed to trace into the copy protection code enough that I could patch it to remove it permanently. I later did the same thing to all the Bard's Tales (neutering the code wheel checks on BT3), and I even traced Wasteland skill usage rolls to force them to succeed.
Numquam ponenda est pluralitas sine necessitate.
(Score: 0) by Anonymous Coward on Tuesday March 25 2014, @07:21PM
That's how I got started hacking assembly, but I'd nop out the decrement instead.
(Score: 2) by sjames on Tuesday March 25 2014, @07:08AM
I did a lot of that on C64 and Apple][. At some point, hacking the game became more fun than playing the game. While the developers intended for the player to eventually win the game, the challenge I enjoyed was one they intended me to lose. That made it way better when I won and the game did what I wanted.
I learned a lot about the PC architecture by boot code tracing games.
(Score: 2) by Random2 on Monday March 24 2014, @09:14PM
One exercise I greatly appreciated in college was the week we spent writing in machine language for a processor. We broke out the instruction codes and put them in sequence to have the processor do stuff.
We even had a test on it. Know how many students answered stupidly simple questions incorrectly because they missed a single bit in their 100's of bit-long strings? Hint: most of the class.
So yes, outside of unusual debugging cases, only a lunatic would consider doing something like editing the binary files. This is the reason we came up with higher-level languages so you don't have to hunt through kilobytes of binary to find the one damn bit flipped to the wrong state or the accidental bit-shift from pressing the key the wrong number of times.
It's something useful to know for those absolutely bizarre cases where a compiler breaks a build, but 99.99999999% of the time the faster, and far more sane, option is to look at something other than the binaries.
If only I registered 3 users earlier....
(Score: 1, Insightful) by crutchy on Monday March 24 2014, @09:29PM
i remember reading the art of assembly, which had a section on opcodes.
looked really interesting but would be more fun on a simple uc set up with blinkenlights. i reckon programming uc's with asm is definitely more fun than higher level languages like C or basic but i haven't tried writing the opcodes in hex directly.
(Score: 4, Interesting) by VLM on Monday March 24 2014, @09:43PM
You'd probably get a kick out of this
http://www.retrotechnology.com/memship/memship.htm l [retrotechnology.com]
which is a 1802 programmed from a binary front panel
Or this
http://www.brielcomputers.com/wordpress/?cat=24 [brielcomputers.com]
which is a 6502 programmed in hex.
I have both. Its hard to say which is better for new guy. The 1802 is certainly a simpler system but the binary coding is maddening. On the other hand 6502 is more complicated but the UI is far better. Probably better off with the KIM-1 6502 board.
I also owned one of these in the late 80s somewhat soon after it became obsolete but before it became a classic:
http://en.wikipedia.org/wiki/Heathkit_H8 [wikipedia.org]
which is a 8080 programmed in octal, although you could upgrade it to a Z80 unfortunately still programmed in octal. It was an interesting experience.
Although if you feel the need for octal, this architecture is dramatically superior to the 8080:
http://en.wikipedia.org/wiki/PDP-8 [wikipedia.org]
And no I never owned one but fooled around extensively with emulation. They sell on ebay for about the price of a used car now in the 2010s.
(Score: 2) by Koen on Tuesday March 25 2014, @01:25AM
Sir, thanks!, *this* is why I read SoylentNews.
Now where is my credit card, I'm gonna order a 1802 memship at once.
May the Forth be with you.
/. refugees on Usenet: comp.misc [comp.misc]
(Score: 0) by crutchy on Tuesday March 25 2014, @06:34AM
thanks for links... lead me to this http://www.brielcomputers.com/wordpress/?cat=18 [brielcomputers.com]
not a *real* altair, but would be just about worthy of programming while wearing a stormtrooper outfit
(Score: 2, Interesting) by Beukenbosje on Monday March 24 2014, @09:14PM
Oh please, this sounds as a retro-discovery. Binary editing is as old as can be. Most useful nowadays:
- modify the regkeys in cmd.exe to be able to run it on a 'managed' winstation.
- change a product id / vendor id to make stuff compatible
- change strings to make usb-string matching stuff compatible with OEM-variants
Years ago I changed binaries on my Z80 by hex-sight only. IDA and companions made it easier.
Now, get off my lawn.
(Score: 2) by Reziac on Tuesday March 25 2014, @02:49AM
DOOM and DEHacked. ;)
I've assaulted a binary with a hex editor a few times myself. I'm not a coder but sometimes it's not rocket science to figure out what part you want to change or do away with. I recall a BBS utility that insisted on calling a bunch of crappy external .COMs that were actually an early form of adware, and the util would bitch and moan if they weren't there. I rooted around in it til I found the filenames, killed all the strings, and the problem went away.
And I made my copy of Blue Wave call itself variously Cold Wave and CrimeWave. :)
Then again, I think it's perfectly normal to view binaries with Vern Buerg's LIST.
And there is no Alkibiades to come back and save us from ourselves.
(Score: 2) by Blackmoore on Tuesday March 25 2014, @01:50PM
And some of us were doing this on the old 8-bit systems in the 80's. It is a rather lost art.
i dont even think you can buy an assembly program for an Intel/win setup since Borland dropped that product; not to discount any open source solutions (that i havent bothered with since i have no need to play with assembly or disassembers since we left the 80s)
I was chatting about just this with a friend who's just out of college; and he never had to work with his arms that deep into the system - and it makes me wonder both what we are losing, and what mischief that the commercial compilers are doing to our software where nobody is looking.
(Score: 2) by tangomargarine on Tuesday March 25 2014, @02:50PM
NASM [www.nasm.us] is available in the Linux package repos, if that helps at all.
The textbook they taught me assembly out of is available online [drpaulcarter.com] as a PDF, too, which I would recommend for those already acquainted with programming but not assembly.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2, Interesting) by Adrian Harvey on Monday March 24 2014, @09:18PM
On the fly, automated editing of the binaries as they load into memory was basically how VMWare got around the old Intel instruction set's limitations that prevented proper virtualisation.
Direct editing in the binary tends to have two issues these days 1: automated system updates change the binary back without telling you, and 2: integrity checks/ signed binaries / IDPS systems don't like binaries being changed without their consent.
(Score: 5, Funny) by Sir Garlon on Monday March 24 2014, @09:24PM
Sure, editing binaries is a piece of cake. Getting them to do what you want *after* editing, though ... not so easy! ;-)
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
(Score: 3, Insightful) by Sir Garlon on Monday March 24 2014, @09:30PM
OK, now that I read TFA, what the author is talking about is changing the value of a constant, or something simple like that. In which case he actually has a point, kind of. Though I am not convinced that hacking a binary is quicker than updating the source code, if you then have to explain the binary hack to people like QA, your boss, or Legal. ;-)
[Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
(Score: 3, Informative) by Zoot on Monday March 24 2014, @09:49PM
With just a global change of literal text. It's a little harder in the era of Unicode etc., but about half the things I ever wanted to do to executables could be achieved by opening up the program file in a text editor and changing one literal string to another equal sized string. Not only message text, but constants for comparison, external function references, and other things could often be changed this way.
Most of the other things I needed to do to executables were simply a matter of figuring out which single instruction to NOP or which single branch to make unconditional.
There's hardly ever a need to insert or change a large amount of code. So probably 90%+ of things you want to do to a program are very simple changes.
Z.
(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.
(Score: 2) by martyb on Monday March 24 2014, @11:21PM
Heard this one from a co-worker @ IBM when I worked testing their VM operating system back in the early '80s. Seems he was at a customer site dealing with a major issue. System crashes on multi-million dollar mainframes are Not Good. Could not isolate the problem. System kept crashing. Problem severity was raised and escalated into upper management. More resources were sent in. Still no joy.
At one point, my co-worker complained that something just didn't look right... Wished he could take a look at things at a certain point. His co-worker said to hold on a couple minutes. Then he said to try again. The system promptly stopped just where my friend wanted it to.
He had gone in and edited the CPU's microcode!
Wit is intellect, dancing.
(Score: 3, Interesting) by Koen on Tuesday March 25 2014, @12:30AM
This reminds me of the days of the Motorola MEK-6802-D5 [old-computers.com] and the Multitech Microprofessor μP-1/MPF-1 [wikipedia.org]: 16 hexadecimal keys and a couple of keys to start/stop programs, place breakpoints, single-step and reset.
I learned machine code on the MEK-6802. It was mounted on a wooden board and had a sheet of plexi on top with a cut-out for the keys. During school holidays, I would draw flow-charts and write the Mnemonics (i.e. assembly language without an assembler) in the day time and then hand-assemble it to Hex using opcode-tables during the night - that's where my insomnia I still suffer from at this very moment started (well, that and hormones I guess, I was 12 to 15 years old).
After that, I used a MicroProfessor: it had a Z80 processor and it came in a case that looked like a plastic book [dyndns.org]. Closed it looked like any ordinary book, I'll never forget the surprized look of my friends when I took it of the book shelve and opened it. The MPF-1-Plus [oldcomputers.net] even had a QWERTY keyboard and an Assembler - what a luxury!
The Multitech company still exists, they changed their name to Acer [wikipedia.org].
/. refugees on Usenet: comp.misc [comp.misc]
(Score: 3, Insightful) by istartedi on Tuesday March 25 2014, @02:22AM
Thanks for the memories. C=64 stuff where you input the code from Compute! Magazine. Microsoft's brief partnership with Apple during the 90s. You could tell it influenced their devs because for a while (IIRC, in Windows 98) they made it easy to find things in DLLs. You could explore the MS equivalent of a "resource fork" in Windows system files. I changed the error message dialog boxes a few times just for the heck of it. It was fun to do it on a co-worker's machine and have it say something like, "Rufus, you doofus".
Appended to the end of comments you post. Max: 120 chars.
(Score: 1) by iWantToKeepAnon on Tuesday March 25 2014, @04:27PM
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