no.. hex?
i thought that... you know all those pages that like...
with those 8 character long hex codes, i thought...?
similar to gameshark?
damn, ok then... maybe it shant be hard at all.
Most of the "hex codes" you see when it comes to reverse engineering or ROM hacking are just memory offsets where code and data is stored. Reverse engineering data formats also requires recognizing data structures based on what they look like in a hex editor a lot of the time, but that's a totally separate skill from modifying a program's code.
Instead, when modifying machine code or interpreted bytecode (the "coding" aspect of reverse engineering), rather than edit the binary opcodes in a hex editor, it's better to disassemble the binary opcodes into human readable form (that is, to turn them into plain text assembly language opcodes).
Probably the best tool to use is a debugger with a disassembler that let's you modify the program on the fly, mostly because you don't have to try and figure out what's code and what's data (it'll be obvious when you trace functions in the debugger), but also because then you don't have to mess with reassembling the assembly language code and overwriting the old binary with the newly assembled binary code and you can test the modified code immediately.
The only real reason to ever do any binary hacking of executable code by hand (in hexadecimal) is because you don't have any tools available yet or you don't have the time to make your own tools.
So really, it's no more difficult than regular assembly language programming, if not easier.
