Cheat making works the same regardless of system.
Ignoring the higher end assembly methods (which usually still start with what is to follow) then most will spend their days fiddling with data in memory. This data includes stats, health, ammo counts, mana counts, inventory and whatever else that the game will need to have to operate with while it is running but not necessarily be baked into the code, or indeed unable to be baked into the code.
You usually do this with an emulator, which hopefully will have a cheat search.
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial being for the GBA but works much the same for any system.
Some use an emulator but then wind in an external program to search the emulator's memory (which naturally includes the console's) and prior to the development of emulators suitable for cheat finding (which need not be the same as playing -- you generally don't care if the game runs at 50% speed and with all the graphical glitches you like for the purpose of fiddling with data) then there are those that would use hardware methods. What these methods are varies by system though and today emulation is where most would start.
Some will also use save hacks (edit the save to change data in the inventory and you can follow it back into memory).
Savestates are also a thing you can use, and work better with some hardware things. A savestate after all is just a snapshot of the memory.
A note on pointers. Hopefully you won't have to deal with them but for now. More modern systems will use these more extensively. A pointer is a concept in coding that notes where something else is, points the way if you will. For probably 99.99% of NES games then everything will be in the same part of RAM in every run ever done and ever likely to be done of a stock game. Coding like this can be tedious though so newer programming languages can say get me a slice of memory this big and I will return it when I am done. This way if someone instead of say starting a game went and fiddled in the options menu first then if the options menu failed to return memory, or return it in time (routinely failing to return memory is the basis of "memory leaks" by the way), or maybe they did a level select and first then the "give me a slice of memory" bit might have got somewhere else compared to the previous boot. As the code written potentially years ago and obviously with no knowledge of that particular boot will not know where it is then there will be a pointer it does know the location of saying where it is found this boot or at this point in time. Yes you can have a pointer to a pointer (to a pointer to a pointer...), indeed nested pointers are often an exam question when people are being taught coding. You find pointers by taking one boot of a game, finding the values you want and where they are that boot and then taking a savestate. Repeat when it is in another location and take another savestate. Obviously note where the values you want are and keep them with their respective savestates. You then get to compare them to figure out what values are noting their locations in memory (or that of the host structure)
For moon jump then it is a bit different to the boring and basic infinite health/ammo/money/lives/magic points/max experience/.... you have two usual approaches, maybe three.
1) If the game has a double jump feature then somewhere will be a little variable, indeed if it is on or off most would know it as a flag, saying "double jump has happened". Your cheat would keep this "double jump has happened" flag as no jump yet. Now you can double jump endlessly and fly away into the sky.
This is more tedious to find than the infinite potions or health thing where you can spend all day decreasing it by just a few until you find the location doing a "changed since last time" search, however it works in much the same way. That is to say find a location where nothing else is happening (no enemies, preferably few other animations...) stand still if you can and jump. Before you double jump press the cheat search and then you can start searching. Double jump and search for anything that changed. There will probably still be a lot (probably music going on in the background, timers happening in the game, location changing...), land and search for anything that changed, repeat that process until you narrow it down, while you are on the ground though you might want to do a search for things remaining the same and hopefully then eliminate some of said timers and music and whatever.
2) If there is a stat governing jump height then edit the stat if you can. Might be easier to change a nearby stat you can more readily change by levelling up, equips or maybe an existing one.
2a) If the game has an item with a percentage jump height increase (rare but not unheard of, most usually look at this sort of thing for speed based hacks. I usually see this most in dungeon crawlers with randomly generated weapons that do stat boosts) then see about making such a thing with hacks, or maybe triggering the effect as an added perk if it is itself an extra flag or percentage boost in memory.
3) You find the gravity part of the game's equations and edit those to halve the gravity or double the initial jump height. If there is a cheat or a level with altered gravity then see what goes for that if you want. This tends to find you leaning more into the assembly stuff above -- track where the character is in either the 3d world if it is a 3d game or a 2d one if it is that (usually using something called OAM/object area memory, which is what governs the location of sprites on screen) and you can fiddle with the things changing that.
There are more easy assembly methods if you learn some assembly -- jump happens as a result of a button push, double jump does too. Follow through what happens from button pushes (or their debounced locations) and part of that will be a flag, and also everything else with regards to gravity and stat based whatevers.
