No, you wouldn't be able to tell just by looking at the file in a hex editor. Unless the codes were discovered by chance, the only real way would be to disassemble the game's code so you can see what's done in relation to button inputs.
While several things like this have been discovered via full disassemblies and even decompilations (
https://gbatemp.net/threads/nintend...-cheat-code-discovered-21-years-later.585818/ ) then I would say you can fairly easily discover these by less involved means than those*, though still going to be some assembly for most things like this. Some of the hidden code stuff can also be extrapolated upon, and often enough they are in plaintext in the memory somewhere so searching for known then allows you to move sideways and try other stuff.
*again I keep threatening a guide but for the sake of something more basic.
Controls operate usually by having a dedicated section of memory once a frame (perhaps more) update to reflect changes. Better coders will copy this to another area (a process called debouncing, this is done mostly as switches are mechanical devices and forcing through that oxide layer and general microscopic deformations means one microsecond it might be one and another the other or even invalid range which could mean a player calls dodgy controls or one operation thinks the button is pressed and another after it does not which leads to odd behaviour in the game -- if doing NES Mario then holding B runs, it is also shoots a fireball and thus forms a basic shield technique for running. Alternatively if you have ever had a mouse start double clicking when you only clicked one then this is switch bounce taken to the point of failure.). Easy enough to detect as it should be the only thing reading the controller states and then you set your break on read to that area it is copied to.
Anyway regardless of what is used then most such cheats are activated in a few ways. Menus being a good bet, though plenty of others happen during play and frankly there are not that many choices in most games (especially of that era). If all you can normally do on a menu is press start and suddenly you have codes checking for odd button combos being pressed (in this case the second player controller is a whole other area of memory that is likely never looked at and thus red flags aplenty) or having said combos/buttons noted down in a list or some kind of series of gates that return to start on "wrong" press then so much the better.
Something similar happens in password entry screens. Your average password might check the hash/checksum (often more complicated but if you add up every byte and get odd or even, or indeed known value then if the addition does not match the baked in hash/check bits then yeah) and then start decoding. Can usually find password entry values via cheat searches as well (indeed might even be considered an excellent candidate if there is a backspace/change value) This is fairly obvious when looking at code even if you don't get down and dirty with figuring out what the hash is and values decode as (though you can have some fun there making overpowered passwords), but whole bunch of IF [value] before that hash gets checked or some point afterwards before returning to the game then you have something to investigate.
That said unless you are
https://prog.world/the-story-of-mel-a-real-programmer/ you are never going to notice such a thing by staring at hex and most of the time you will have to go looking, or maybe have a clue from same devs in different games (see Konami code for possibly the most famous example out there), other regions, hoping some dev/tester reveals something* on social meeja/in an interview... and try it out for your game. That or be very very bored
https://www.wired.com/2015/09/hack-...er-hack-easily-bypasses-android-lock-screens/ . Hopefully however the above shows you can look happily enough with fairly minimal skills, possibly get something and at the very least make a super compelling case for someone with skills to take a look.
In the eventual guide I would probably note hidden flags as well on health, mana and whatnot and work backwards from those (similar idea of finding something that if doing normal optimised every byte and cycle counts code would not want to be there when handling data) but I will skip that one for today.
*speaking to a guy that worked in dead tree game magazines back when (late 16 bit/early PS1 era, he always had the best cheats and games) then it was apparently a mix of devs themselves wanting a few weeks later interest bump, testers passing on info, codes that went out with reviews (don't think we have ever had that here but we have seen plenty of background info sheets and mechanic guides beyond what might be in the game as an aide de reviewer as it were) and everybody being mutually happy with the arrangement (some kids might read it in the newsagent or share in school but still better than nothing). Space being limited though then not everything gets out there and unless it is Goldeneye C button codes nobody is going to print something for a 10 month old game everybody has largely forgotten about, hence discoveries like this.
Thank you.
