I'm kind of disappointed the author didn't dive further into this and find the exact part where the input is processed to activate the cheat normally. Then they might actually be able to implement a konami code cheat on PC.
I realize they're a beginner and probably thought that recreating the PS1 functionality on PC would be near-impossible, but they might be surprised that reverse engineering isn't as complicated as it seems. Especially given how many times they mention they've been lucky that it's an old PS1-era program, when in reality not much has changed and the basic techniques they're using here still apply to modern programs. (With the exception of intentionally obfuscated programs)
Note that there is a hell of a difference between changing existing instructions or even managing to squeeze a minor fix into some broken logic, and implementing new logic entirely.
There's a whole lot more reverse-engineering required to understand the working input handling, followed by more reverse-engineering to understand the broken input handling. The code might also be missing altogether if it was just ifdef'd out at compile-time or lacked initialization against the Windows input handling.
Trying to extend the input handling that never had this handling, unless the original is 50% NOPs, mean writing a new implementation at the end, and having the old implementation jump out and back.
Sure, it's possible, but on an entirely different level than patching conditions in place like done here. I feel like being disappointed at this is like going through a hello-world tutorial for a language and end up disappointed that it didn't teach you to write a fully functioning game.
> Trying to extend the input handling that never had this handling, unless the original is 50% NOPs, mean writing a new implementation at the end, and having the old implementation jump out and back.
While traditional in-place binary patching does require contorting the modifications within the original program's memory layout, it's not the only option. If you have the ability to make the program's code and data relocatable again, you can leave out the parts that you want to modify, write replacements in source code form and let the toolchain mend everything back together.
That technique has a higher upfront cost (the reverse-engineering work still has to be done on top of this), but it's far less finicky to perform. Personally, I've developed this capability with a Ghidra extension that exports object files, but that patching technique is so esoteric I don't even know if it has a name.
I remember being completely clueless as to where/how input is handled in the code (or how I would even start to grasp it). It would be nice to see someone actually do this and explain their thought process though.
Regardless of difficulty, reverse-engineering is time-consuming. The author achieved their stated objective with the least amount of effort applied, which is how binary patching (at least the traditional kind) tends to go.
reply