You are in the right and... at the same time things are more complex.
You are right that whatever reaches RAM was written there by the program; And the program has its instructions (executable) and data read from the ROM.
The data you see in RAM can be the result of a long calculation from base things written in ROM. Let's take an example:
An RPG stores monsters info in its ROM "as is", among which base HP.
But it also has "golden monsters", which have 20% improvement in all characteristics over the generic version. Maybe the programmer stored the raw info with 20% increase already calculated. Maybe instead there is a flag that says that you encounter a normal or a golden monster, and calculations are made when the monsters' "form" is created in memory?
This is a simple example. There can be tons of things in the middle between "loading raw data from the ROM" and "writing something in the RAM".
In the end, the only reliable method is for you to use a debugger, breakpoints on RAM memory access to where you see the data, and execute "backwards" the code to see where that data comes from. Executing backwards is not possible, so this means a lot of assembly reading, interpreting, setting new breakpoints, etc, until you reach your goal.
So it's not like you'll find a "one-fit-them-all" tool for that...
I'd be glad if someone told me otherwise.
I hope this helps!
Actually... Going back in time (and in the program's execution flow) should in theory be possible IF (big uppercase not-yet-realistic "if"
) you asked the debugger to trace each and every instruction it executes until it reaches the breakpoint.
This kind of detailed tracing would make your computer run like a tortoise trying to haul a lorry full of bricks up the road to Grand Canyon, but... it would be nice. And the debugger's user interface could have a "back one instruction" button, all integrated in the user interface. Man, I would love this!!
Note: I hereby copyright the concept of backward breakpoint!!!
Now back to real life...
Tracing is somewhat present in some emulators / debuggers. But it is kind of tough to interpret, and may not contain all that you need. So I am not sure this is "the most efficient way" forward. (Or backward... Err...)
With any luck, I brought you light until my signature and more confusion later. If that's the case, then you can just ignore the confusion all together.