[Bob789]

Hello all,

I've been searching through a ROM to try and find specific bytes but I was wondering, when searching through a ROM, do you really have to change every couple bytes and see what they did? Because that would be a huge pain in the butt.

Thanks,
Bob789

[Psyklax]

I don't really follow you. Emulators have debugging tools that mean you don't have to go through a ROM changing bytes randomly forever. Maybe people had to do that in the old days, but not any more.

Then again, I don't know what system you're working on. If it's the NES, for example, FCEUX has a wonderful set of tools. Once you learn a thing or two about assembly and using the debugger, it will tell you the bytes you need very easily. But as I said, you should give more information before you can get help.

[Zynk]

You can try this tool - https://www.romhacking.net/utilities/2/

You can corrupt a specific line then press restore the ROM with less hassle.

[KingMike]

I have never used random ROM corruption and I cannot imagine it being a very productive means to find stuff versus trying to track it down the "smarter" way.

But maybe in the days before good debuggers, it was a means of tracking data (such as level data). Obviously just to get a foothold in the game.

[nesrocks]

The only hack I've done for atari 2600 was a test by blind hex editing. The rom is so small, I opened it on a HEX editor, looked for a $A9 byte and edited the following byte. Result, the igloo in frostbite was now brown. I don't think it is too impossible to imagine an atari rom being disassembled with this method, but there are much better ways using proper debuggers indeed.

[KingMike]

I'd image 2600 games being easier to disassemble, being typically like 4KB, right?

But it sounds like ASM hacking on it would be harder as timing was a far bigger deal from what I've read.
Whereas with NES, code timing isn't usually a big deal unless you're dealing with like NMI/IRQ stuff.

[BlackDog61]

There are different methods and tools for different purposes. I'm sure if you tell more about what you are trying to achieve on which console, then people here can help, advice and sympathize better.
Have you checked Fast's guide for romhacking?

[Bob789]

Sorry for the ambiguity, I wrote the original post quickly.

To clarify, I am using FCEUX and I am trying to look through the original Legend of Zelda.
I have no experience with Assembly, but I plan on changing that.

EDIT: I am not trying to change anything specifically, just trying to see what does what to see what I have available to do.

Hope that clarified!

[NERV Agent]

What exactly are you trying to change? It would help out everyone else here if they knew what you need help with.

Anyway, maybe this will give you some clues?

http://www.romhacking.net/documents/87/

http://www.romhacking.net/documents/90/

http://www.romhacking.net/documents/91/

http://www.romhacking.net/documents/385/

https://github.com/camthesaxman/zeldasource

The Legend of Zelda is obviously a popular game, so it is very possible that someone has figured out the source code. I mean, that's what happened with Metroid.

[BlackDog61]

I guess we can say that it's, in general, indeed a very long process if you're trying to find what every single little byte does in a ROM (even with some other methods / tools).
The NES has some of the better emulators for that, still, since a lot of memory is explained by graphics / whatever-since-I-don't-focus-on-NES. 
But yeah - you could spend a decade figuring out everything in, say, a PSP game.

[ShadyRounds]

As what I would consider to be a successful newbie, "changing values randomly" only works with "controlled randomness".

I could not make much progress in Megaman Legends romhacking, if I searched single bytes. 56k matches.

However, it is successful when deployed in the following scenarios:

1) Using a real debugger, to trace a function to a location in ram, and copying the entire 16 byte line it sits on to search the rom for. I find plenty of values, even values referenced in 2 separate locations within the same rom, by searching longer strings in what appears to be a part of ram loaded from game start or that's always actively loaded.

2) Finding a location in ram/rom, and then searching for similar value bytes in the nearby neighborhood. For instance, I can change what item is given AND which is equipped, by searching a location I found, and checking for any similar values located fairly close in proximity. However, recently, I found 7 references of a equipment byte, and changing all of them severely broke the character and crashed the game, but changing JUST THE 1 THAT WAS POINTED TO, worked fine. So sometimes precision is better than carpetbomb-swapping.

As far as platform-specific tips, I only know what I've read and have no hands-on experience. However, I started from knowing literally nothing about assembly, to knowing still almost nothing about assembly, and I can literally build an item randomizer now, so there's always hope. Just focus on finding debug-tracing and the tools/emulator to use for the task, and study all the documentation you can about the tools and/or the various games people have used the tools on. When you need assembly, you'll need a lot less of it than you probably think.