News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Getting started hacking  (Read 600 times)

mcoorlim

  • Newbie
  • *
  • Posts: 4
    • View Profile
    • Author Page
Getting started hacking
« on: July 20, 2019, 07:28:59 pm »
I have some experience as a game dev hobbyist, but I haven't done any rom hacking. I'd like to get into it, but there's a lot of options out there.

What's the best way to get started? What's a good learning curve to follow in terms of simple->difficult when it comes to types of hacks, systems, games, etc? I've got some ideas for what I'd like to eventually do, but right now I just want to learn the basics.

I've taken a look a the documents and it seems like there's a lot of resources available, but I'm really looking for a pointer to get started. Thanks in advance for any advice.
Author Page - Blown Cartridges retrogaming channel

FAST6191

  • Hero Member
  • *****
  • Posts: 2554
    • View Profile
Re: Getting started hacking
« Reply #1 on: July 21, 2019, 10:08:49 am »
There are many answers and things to ponder, though above it all "thing which gives you the desire/determination to continue" will probably be looming -- not many people are about learning for the sake of learning, and while I might say I am then I would still not have got far if all I had to look forward to was a sports game at the end of it.

Barring the really old stuff then I would not say any mainstream 8 bit or newer system is really all that much easier or harder than any other. If you can find a decent debugger for it then even better (for a rule of thumb then Nintendo systems usually have the best ones outside PC, though PS1 is not bad and Sega stuff is far from absent. Arcade stuff can be harder, as might older and more obscure systems. Sometimes you will have to go looking at the tool assisted speedrun crowd to find a debugger, or a better one than mainline emulators will afford you). A system that uses a filesystem (floppy discs, things on CD/DVD, Nintendo DS commercial games and beyond) can make life easier by virtue of having file/directory/extension/file size to look at and eliminate with (to say nothing of making certain pointer issues all but absent), and it can also complicate basic tracing that things with the ROM visible in memory ( https://www.romhacking.net/documents/361/ ) have an easier time with.

We can loosely categorise types of hacks into difficulty ranges but there are all sorts of other things which can modify this, to say nothing of one particular game maybe just being really difficult in this one regard. Said categories common around here are probably

text hacks
graphical hacks
level hacks
game logic (sometimes bundled with level stuff)
multimedia (sound and video)

People looking at translation* will usually immediately find themselves thrown into text stuff. Others might wander in and find graphics are their intro to it all (and translation can, usually does, involve some amount of graphical work as well). Both have many many examples of quite easy things when all is said and done, but at the same time there are nightmare ROMs that even veterans have to plan a means to contend with.
Music is traditionally seen as hard, mainly because it is, but get into systems with simple CD audio, or known formats common to 90%+ of games (the GBA sappy format for example) or even near universal (the DS SDAT format) and you can be composing whatever you like in very short order (and possibly even just sticking in wave files in the case of the DS).
We don't tend to see videos much in the sorts of systems popular around here, and even then all most would want to do is replace with another region (so much copy and paste, maybe with a minute to tweak pointers) or subtitle them (either done as soft subs or by finding an existing encoder, rarely by making their own encoder).

*the other categorisation is probably translation, game improvement (bug fixing, text tweaks, difficulty changing, censorship related stuff), game modification (new levels, new enemies, new items, unlock everything from the start....), total conversion (basically a game engine is reused to tell a whole different game, not common as it is hard and likely easier to just code your own new game). There are overlaps between them all but you can discover the literal, liberal, pizza cats debate on your own time.

Another way people look at things is everything eventually ends in assembly language fiddling, and those that can do the assembly language dance often have an easier time of things elsewhere; no need to open a ROM in a tile editor and press page down a lot if you can follow it back to the source by watching what the machine does to land it in VRAM before going backwards from there.
Assembly language is unique to a given console, especially if you consider its unique arrangement beyond the CPU (the Master system uses a Z80, as does the sound for the megadrive, and it is not so far to the GB/GBC's quasi Z80 CPU either, but all use different memory layouts, approaches to graphics, have different hardware available to them...). At the same time though learn 2 assembly languages and your third is not likely going to be too difficult, especially if you got a bit of an idea into general computer architecture throughout it all. To say nothing of the same core concepts getting you pretty far wherever you go -- instructions tending to be split into CPU/memory management type instructions (shuffling things between registers, grabbing things from or stuffing it in memory, push and pop...), basic arithmetic (many will not have divide, much less divide with a remainder, some will not even have arbitrary subtract) and electronics operations (shifts, rotates, ceiling, floor, boolean stuff...), and comparative operations to decide if conditions have been met and tell things to jump around accordingly aka program flow.
Go another way. Without assembly then whether you make much headway with a given ROM is up in the air -- most ROMS are fairly amenable to most things, however there are bad ones. With assembly then you can reasonably rock up to any ROM on a system you know (and many you don't) and be assured you will make headway in fairly short order, said headway might only be learning exactly how annoying it is going to be (there have been Japanese games with all vertical text, and said text is all graphics, or things which change encoding every screen) but you will know.

Most don't find themselves reverse engineering level formats right away, but they could easily enough -- levels are usually quite simple as it is painted or coordinate system based affairs. Whether they get right away into making a graphical level editor will likely depend upon general programming skill. 3d levels can be a bit different here (some will do collisions based on the models, most though will have a separate file/section to handle what interacts with what -- for a fairly nice intro to such things maybe look up the 3d mario karts as they have some good stuff here).

Game logic is often assembly in the end but cheats are a part of this.
For example one time someone asked for a one hit kill mod for Sonic. A hack that dealt with hit detection was eventually made but before that I just made a cheat that held the number of rings at zero (the same 5 minute search procedure ( https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ) that gives you infinite lives, time, points, ammo... can also be used to find ring count, and set the value at 0) and turned the game into that. For some cheats are not as satisfying as being able to have a custom tweaked ROM (by the way you can hardcode cheats on a lot of systems from about the N64 on upwards, and the methods such tools use also work pretty well and are pretty easy as these things for older systems if you go manual) but in terms of end results they can have some profound effects. If you have some self control then start with 10 lives rather than 3 type things also easy to make from infinite lives cheats most of the time.
Other times if RPG balance is your thing then the game might have a nice stats table for players or enemies that the devs maybe did not fine tune. Find where this is and what it says (maybe someone came before you and figured it out) and it is so much spreadsheet editing from then on.
Choice link at this point for cheats https://doc.kodewerx.org/ . Cheats are more than infinite or setting a value that would be infinite in an easy mode style cheat so I also find getting people to ponder moon jump cheats is also good -- is there a gravity stat, can you stick a silly number in a jump stat, if the game has double jump/air jump can you find the "has done second jump" flag and set it to not jumped?
Where text and graphics can be counted on to be fairly sedate and only have compression, variable tables and the occasional dev making life difficult then game logic is as varied as the games themselves -- you say you are a dev already so I usually go with "what would I do to solve this problem"/"what could have been done to solve this problem". Game devs are not always great coders, nor overly concerned with adaptability, so keep that in mind during all this.
Start going beyond things that are basic stats, able to be handled by simple cheats to nerf or boost certain mechanics, like fiddling with fundamental aspects of 2d cameras ( https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true and http://hciweb.usask.ca/uploads/332-aim-assist-cameraReady-v8-final.pdf for nice links) and you are not getting out of there without assembly.


Suppose I had better plug my own docs http://www.romhacking.net/forum/index.php?topic=14708 as they are largely aimed at getting new hackers, or new hackers to the GBA and DS. While they are aimed primarily at the GBA/DS (pretty much all the examples are built around them) but again it tends not to be all that different between systems.

mcoorlim

  • Newbie
  • *
  • Posts: 4
    • View Profile
    • Author Page
Re: Getting started hacking
« Reply #2 on: July 21, 2019, 11:03:22 am »
Wow, thank you for the comprehensive and detailed reply, as well as the link to various docs. That all makes perfect sense, and you've given me a bit to think about.
Author Page - Blown Cartridges retrogaming channel

Psyklax

  • Hero Member
  • *****
  • Posts: 1030
    • View Profile
    • Psyklax Translations
Re: Getting started hacking
« Reply #3 on: July 22, 2019, 01:19:03 am »
I can say my very brief thoughts which echo what FAST6191 says.

In my experience, the NES is the easiest console to hack for a number of reasons. There's usually no graphics compression, 6502 assembly is the easiest assembly language to follow (imho), games are smaller and simpler than other systems, it's the most popular system to hack so there's tons of resources and other hacks out there... so yeah, just get the basics of 6502 assembly, read how the NES works on NESdev, and have a play.

I started by translating a Game Boy Color game from Japanese to English, which was easy because I didn't have to learn assembly to do everything I wanted, but in hindsight I recommend learning assembly because it feels like you're doing it properly, not feeling around in the dark. :)

FAST6191

  • Hero Member
  • *****
  • Posts: 2554
    • View Profile
Re: Getting started hacking
« Reply #4 on: July 22, 2019, 02:10:07 am »
In my experience, the NES is the easiest console to hack for a number of reasons. There's usually no graphics compression, 6502 assembly is the easiest assembly language to follow (imho), games are smaller and simpler than other systems, it's the most popular system to hack so there's tons of resources and other hacks out there... so yeah, just get the basics of 6502 assembly, read how the NES works on NESdev, and have a play.

I started by translating a Game Boy Color game from Japanese to English, which was easy because I didn't have to learn assembly to do everything I wanted, but in hindsight I recommend learning assembly because it feels like you're doing it properly, not feeling around in the dark. :)

I don't know I can get there for 6502. It is not like teaching someone one of the university style simplified Y86 and then throwing them in, and expecting them to swim, in hardcore modern X64 SIMD extensions + all the cache timing and security features, however at the same time I find it a bit too simplified for my taste. Other than divide (which the BIOS kind of has) and minimal float options the GBA (nowadays older ARM) can do most arbitrary arithmetic (and pretty fast) to sensible numbers (8 bit is limiting in some regards) with registers enough to afford some overhead (personal stylistic thing but I do like to view registers as almost arbitrary rather the 6502 and many older things approach of it almost making sense to consider instructions as unique per register even if their action was functionally so) as well as jumping wherever it needs again arbitrarily (recalling the conversation the other week on blind jumps and you opting for abusing a jump with flag that is terribly unlikely to be set... workable but I don't like uncertainty here, even if it arguably is practical to test for* in a given instance).

*for all people like to note games as being rather random pieces of code as far as program flow when compared to file format conversion and all the other stuff like "how would you code a FPS without OOP" they really aren't, especially not the NES -- how many times can you even get back to the title screen in a NES game without a reset or game over? Nowadays it is nothing but consider how radical some view megaman's choose your own order approach.

On compression then once compression started landing in SDKs and BIOS level features if it even is custom it is almost invariably only going to be a minor variation -- different flags, different split between the number of bytes to read and the number of bytes to look back. If you are going from the no compression other than the occasional RLE and palette swaps (the ever fun NES mario clouds and bushes thing - https://facts.zone/archives/4000 ) to the weirdness of the 16 bit era then yeah I can see it being something of a shock. Playing on the GBA and DS (and being aware of other systems) then it is usually a bit of tedium as I can't doodle over it in a tile editor or if I have a typo in the script then I have to decompress, edit and recompress.

This is not to say I don't recommend the NES -- between the tools available (FCEUX is the reference standard for debugging emulators outside PC for a reason), docs available, general understanding within the world at large, massive game library covering most bases, said relative simplicity of a lot of things (in addition to enough complexity to challenge you enough to think when some dev doing something strange finally happens to a game you are looking at, or not be left wanting if you do branch out into other systems), and lack of true weirdness like is in a lot of the "minicomputers" and proto PCs that preceded it then it is a fine choice.

As far as learning assembly then I have toyed with reformatting my docs a bit to push it harder throughout -- I don't expect a new hacker to be able to look at some code over a few hours and suggest an optimisation to gain a few bytes somewhere for another purpose, however I am leaning towards basic tracing, being able to hardcode cheats, being able to figure out equations for mechanics, and so forth in the earlier stages.

When it comes to fumbling in the dark. While I agree assembly almost feels like turning on a light, and being able to rock up to anything and make progress, or having said progress come far more quickly or with knowledge of what is happening is wonderful then I don't like to downplay how much can be done with tile editors, text editing techniques, cheat making beyond basic infinite blah and format level tools.

mcoorlim

  • Newbie
  • *
  • Posts: 4
    • View Profile
    • Author Page
Re: Getting started hacking
« Reply #5 on: July 22, 2019, 07:16:09 am »
Yeah, I'm definitely interested in learning assembly, even if I end up making heavy use of editors.
Author Page - Blown Cartridges retrogaming channel

Psyklax

  • Hero Member
  • *****
  • Posts: 1030
    • View Profile
    • Psyklax Translations
Re: Getting started hacking
« Reply #6 on: July 22, 2019, 07:59:27 am »
I don't know I can get there for 6502. It is not like teaching someone one of the university style simplified Y86 and then throwing them in

I think the thing is that you might be seeing it from a programming perspective, while I look at it from a hacking perspective, as someone who still knows very little about higher-level programming. Compare NES to GBA, for example. On the 6502, everything arithmetic goes through the Accumulator, or otherwise you use zero page. This makes it very easy to follow where everything is going. Then the only other registers to worry about are X and Y, which don't do much. So if you know nothing about assembly, I think it's pretty easy to get to grips with 6502 - again, from a hacking perspective, looking at existing games and seeing how they work, rather than making your own.

The GBA, on the other hand, has two different instruction sets to figure out, both of which are much more complex. I also forgot to mention that the NES CPU has no direct access to VRAM, and can't mess around with the graphics without a specialised mapper. Add to that all the other reasons I mentioned and yeah, NES is the easiest option for learning hacking. Game development is another thing entirely.

I don't like to downplay how much can be done with tile editors, text editing techniques, cheat making beyond basic infinite blah and format level tools.

Sure, you can get pretty far - I mentioned that I did a complete translation by just using a tile editor and text editing, with no real understanding of assembly at all. But once I cracked assembly, it was like the end scene in The Matrix. :D

goldenband

  • Sr. Member
  • ****
  • Posts: 296
    • View Profile
Re: Getting started hacking
« Reply #7 on: July 22, 2019, 09:46:15 am »
My programming skills are strictly bush-league and my understanding of assembly language close to nil, but I was able to translate two Sega SG-1000 games on my own, and one of them even came out looking quite professional (if I do say so myself  ;D ).

I think the SG-1000 may be even easier to understand than the NES, because it's that much simpler of a platform.

Aquova

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Re: Getting started hacking
« Reply #8 on: July 22, 2019, 10:07:32 pm »
I'm going to hijack this thread, as I've been messing around with hacking for a bit, but I'm still finding myself coming up with a somewhat fundamental issue. I can sit around all day and learn about different regions of a game's RAM, but at the end of the day, I don't understand how to turn what I've learned into what to change in the ROM. If I see a sprite I want to edit loaded into a specific address in RAM, how do I find that in the ROM? Or if there is an enemy whose attributes I want to edit, or one of many different scenarios. So far, my approach has been to make changes in the ROM, load the game, and see what happened. It's very inefficient, and I know there must be a better way. I'd love to be able to make some discovery with the debugging tools, and do some quick operation to find out where to edit in the ROM, but I don't understand how this is done.

FAST6191

  • Hero Member
  • *****
  • Posts: 2554
    • View Profile
Re: Getting started hacking
« Reply #9 on: July 23, 2019, 01:56:54 pm »
I think the thing is that you might be seeing it from a programming perspective, while I look at it from a hacking perspective, as someone who still knows very little about higher-level programming. Compare NES to GBA, for example. On the 6502, everything arithmetic goes through the Accumulator, or otherwise you use zero page. This makes it very easy to follow where everything is going. Then the only other registers to worry about are X and Y, which don't do much. So if you know nothing about assembly, I think it's pretty easy to get to grips with 6502 - again, from a hacking perspective, looking at existing games and seeing how they work, rather than making your own.

The GBA, on the other hand, has two different instruction sets to figure out, both of which are much more complex. I also forgot to mention that the NES CPU has no direct access to VRAM, and can't mess around with the graphics without a specialised mapper. Add to that all the other reasons I mentioned and yeah, NES is the easiest option for learning hacking. Game development is another thing entirely.

Sure, you can get pretty far - I mentioned that I did a complete translation by just using a tile editor and text editing, with no real understanding of assembly at all. But once I cracked assembly, it was like the end scene in The Matrix. :D
I come more from a electronics side of things where I can casually chuck as many operations together as I like. To that end I like having if not infinite then enough tonot have to worry about too often.

As far as "with no real understanding of assembly at all" was that with no understanding of any assembly or just the GB/GBC's? Rocking up and knowing the NES' VRAM location is not going to do you much good but knowing that a console uses VRAM, handles it with another section (commonly called OAM), and general things like that leaving you to look up where it is such that you just have to look up what goes on pandocs or something to fumble your way through things.



I'm going to hijack this thread, as I've been messing around with hacking for a bit, but I'm still finding myself coming up with a somewhat fundamental issue. I can sit around all day and learn about different regions of a game's RAM, but at the end of the day, I don't understand how to turn what I've learned into what to change in the ROM. If I see a sprite I want to edit loaded into a specific address in RAM, how do I find that in the ROM? Or if there is an enemy whose attributes I want to edit, or one of many different scenarios. So far, my approach has been to make changes in the ROM, load the game, and see what happened. It's very inefficient, and I know there must be a better way. I'd love to be able to make some discovery with the debugging tools, and do some quick operation to find out where to edit in the ROM, but I don't understand how this is done.

Sometimes people skip RAM entirely. Some systems have a fairly direct link between the RAM and the ROM in some regard but many won't and the VRAM is the final result without an immediate trail leading to it if you merely pop open a memory viewer at some arbitrary point.
Open up the ROM in a tile editor. Set the settings to be something useful for what you want* (if you want to try to use VRAM or OAM contents, or indeed general appearances, to inform your choices then that is OK) and press page down a lot until you see something you are interested in. Repeat for a few modes if the system in question has that.
*sadly the default palettes of many tile editors don't work for me so do go find one that works for you. Sometimes shades of black and grey work for me quite well where colours do not. You can also rip a palette from an emulator when the data is on screen and import it into many tile editors to use.

If your system of choice is a file system based one then you can also make some guesses based on file names, directory names, file extensions/magic stamps, collections (tiles, palettes and animations tending to go hand in hand so find one...), file sizes, to say nothing of eliminating based on those (the giant 20 meg video file is probably not going to be the stat table).


For the GBA and DS then there are compression searching tools. You know what is compressed? Good stuff usually. Find the compressed area, force a decompression and try to interpret the results.

Said compression is also the main thing that changes the contents of the ROM between it and the VRAM and it is not always used. To that end taking the data as it is in VRAM and searching the ROM for it can yield things. Even if it is compressed then the more common family of RLE/LZ works such that the start of things will tend to be there and get more and more messed up as things go on so searching for early parts of the tile also can get things.

Corruption because why not. Some don't like it but it is a thing. Alter parts of the ROM and run it. Whatever changes in the game (assuming it runs) you know is related to your changes. If you have a file system based thing you can also replace files, or build a version of the ROM without many files and see what changes.

If those are proving too annoying then you do have tracing as well. This is why we learn assembly and place such an emphasis on it. https://www.romhacking.net/documents/361/ is for a command line GBA debugger (at one time the main one available for free) but the concept applies to any system, any debugger (graphical or command based) and any data you can find in RAM. For something like the DS it will end with a command being issued to the fetch command (the B7 one in the cart handling) but most file system based things will be like this rather than being a simple address (or bank) within RAM.
With the exception of corruption I still commonly go for the methods I detailed at least as a quick pass as they often yield interesting things, and also are some of the main ways to find things https://tcrf.net/The_Cutting_Room_Floor enjoys.

Stats tables can be a bit harder, or at least don't have as many nice methods, without tracing. Assuming you are not better served by save editing then you can do things like find the stats in RAM and search the ROM for level 1 stats. You can aid your searching along a bit if you have some kind of item that levels you up, or have a cheat that gives you 99999.....999/8x experience each time, as well as things to never lose HP or whatever else matters here.

For both VRAM and stats (and just about everything else) then once you have found one then you have probably found most of them, or have an idea on where to get them. Most times devs will group like types of data together, and if not then it will be more of a like uses in game grouping -- think character portrait, character stats, character text backstory... similar to how you would write a summary file of it all in the real world.

It gets a bit easier once you have done a few, or indeed read a few guides to it all (if I am not in front of my machine I will read a gamefaqs guide or watch a longplay to find out what the devs likely did and formulate an approach there -- if something looks like it could only reasonably have been done using 3d hardware then I will look at 3d models and textures rather than messing with 2d methods) and understand why devs limit stats to 255 or something and can start to make guesses at what you would do if you were the dev, what the dev likely did here.