Discussion Forum


Perils of Hacking the Executable


This topic covers the perils of hacking an executable file instead of changing metadata associated with a program.

So you want to make a total conversion of a pre-existing game. Why should it make a difference which component of that game you ultimately decide to change?

This is why: Banana Quest.

As of this writing, I haven't been able to support Banana Quest within ZZT Ultra. But boy, do I have good reasons to hold off on this one. Banana Quest is a very special total conversion of ZZT: it enhances the original program in addition to providing .ZZT data files.

Supporting the data files is relatively easy, because so many other games require the same level of support. But supporting a hacked executable? How does one even do this?

Let's talk about what it means to hack the "executable" in a different sense than a 16-bit DOS executable. We will come back to this subject eventually, but first, we should focus on ROM hacking.

If you have never gone to www.romhacking.net, I highly suggest paying it a visit. You would be amazed at the types of hacks and the depths to which people have gone to change ROM images of classic games.

The www.romhacking.net website attempts to distinguish between the elements of a ROM image that are hacked by the hosted patch content. For example, graphics, text, sound, music, map, and gameplay all have their own separate categories. This is a higher-level abstraction of what is really going on with patching the ROM, of course. The ROM image, as a singular entity, doesn't really distinguish which parts are "code" to execute and which parts are "data" that can be referenced. It's just a bunch of bytes.

Generally speaking, text and graphics are much more commonly hacked than any other type of material. This is because hacking the code (i.e. the executable portions of the ROM image) requires a lot more knowledge and understanding. The machine language must be properly understood in order to hack the gameplay itself. Furthermore, even a slight misunderstanding can break the game outright, if the hacker overlooks something.

So most hacks will treat their target delicately, modifying only a few things and leaving the rest intact, with the code being the most likely part to remain untouched.

But there are always people who go the extra mile, and make the original into something significantly greater than what it was about before. Two Super Mario Bros. 3 hacks immediately come to mind: Mario Adventure, released in 2004, and SMB 3-Mix, released in 2014.

These hacks add more levels, more graphics, more characters, and even a more involved set of gameplay mechanics. Truly incredible things have been done, such as re-instating sparsely-used or totally absent characters from the original ROM, PRE-instating features that would only first appear on the SNES and not the NES, and even adding battery backup emulation where it never was before. The creators of these hacks went out of their way to reverse-engineer the original machine code so that they could re-assemble the components into something just as awesome, if not more so, than the original game.

To quote Robert De Niro from The Score: "If somebody built it, somebody can unbuild it."

So why is this perilous?

Well, for one, it's hard. It takes a lot of commitment. But there is another issue: once the code is hacked, it's usually a dead-end in terms of effort. Data hacks can set a template for others to do work in similar memory locations. Code hacks, on the other hand, are changes that others normally find difficult to build on.

Only experts need apply when it comes to code hacks. And even experts find another expert's work hard to digest.

Going back to ZZT and Banana Quest. Part of Banana Quest's hacked content is actually an external mod established from BQUEST.COM, which composes the game's launch program. This acts as a font-generator with replaced ASCII characters, and it also acts as a TSR program for the duration of Banana Quest's run, intercepting certain video services.

With character generation, there is not much to support. I have already gotten some pressure to have ZZT Ultra let the user modify the character set in a similar way that MegaZeux had done from the very beginning. This feature wouldn't be hard; it just means I'd need to make the renderer a bit more involved.

What really worries me are the code hacks of ZZT.EXE itself. Many text descriptions, messages, etc. were changed in the executable. But unlike many of the ROM images I talked about above, these hacks were not simple address patches. ZZT.EXE employs something that hackers dread: code obfuscation.

In theory, I shouldn't be all that intimidated. I've done a total conversion of Metroid (called Metroid Master) so I know my way around the science. I've even written my own 16-bit code obfuscation program (TripWire) that I've successfully employed for my early work in DOS. Shouldn't I just be able to roll up my sleeves, get to work, and reverse-engineer the code obfuscation until I get a clean version of the ZZT.EXE binary?

Here's where the perils come in. I can definitely do all of this. The question, though, is why. Consider what the end result should be, reversing code obfuscation for the purpose of discerning which parts of the original binary were hacked. How do I test this against the original program, unless I reverse-engineer that version, too?

Furthermore, this is a ton of work just to support a single game. One. There is no modularity advantage to this work.

Rooting through assembly code can be a massive time suck. As you get older, time becomes more valuable. Part of you tolerates these frustrations more, since you've become used to it. Other parts of you say there is a far better use of your time.

How far do you want to go? Hacking the executable is not a bridge of eternal peril.

It's just a really, really long bridge that you have to build over peril.




Comments


There are no comments for this topic.

To enter a comment, log in using the



This page is Copyright © 2016 Christopher Allen.