/vr/ - Retro Games

>>901818
It's hard, but not impossible. It would take a pro months or more to completely reverse engineer a complex game, but not nearly as long if they just need to reverse a certain portion of it (like text display routines for translation hacks). Also, you don't have to read raw machine code, you can use a program to disassemble it into assembly language first. Most emulators with debugging features have a disassembler built in.

Being able to apply this skill to video games is obscure, but it has very useful (and lucrative) applications in some related fields...
https://en.wikipedia.org/wiki/Software_security_assurance
https://en.wikipedia.org/wiki/Reverse_engineering

Not pretending to be a reverse engineering expert or assembly language god or anything, but I know 6502 assembly, have written simple programs in it, and have messed around a bit in debugging emulators. Most interesting (but still boring) thing I did was, without prior knowledge of how NES text display routines work, figure out how Zelda's end credits were being displayed, and then overwriting them with stupid shit with a friend (pic related)

>>901830
Minor nitpick: Assembly is not exactly 1:1 to machine code, because of the convenience that labels (automatically calculating addresses while assembling) and macros (like copy-pasting code in the simplest case, but macros can get considerably more complex and interesting than that) provide.

Also, people really did enter programs in hex at some point. Before assemblers were available and when memory was scarce, people would write programs out on paper in an assembly-like language and assemble by hand. They would then enter the binary by hand, with punched cards, a hex numpad, or toggle switches. Thankfully, no one has had to do that for decades.