"refresh" feature for ROM area of Flash memory - page 2 - General Discussion and Assistance - CHDK Forum supplierdeeply

"refresh" feature for ROM area of Flash memory

  • 14 Replies
  • 408 Views
*

Offline reyalp

  • ******
  • 12309
Re: "refresh" feature for ROM area of Flash memory
« Reply #10 on: 24 / December / 2019, 16:11:24 »
Advertisements
Q: If one has two FW dunps, how to best compare the static areas of the two to see if a bit has flipped by comparing the dumps?
I'm not aware of anyone having mapped this out in detail. See also "essentially unlimited list of things that would be interesting to investigate"  :haha

One approach would be to compare dumps from multiple, known working examples of the same model, or the same camera over time. Note that aside from stuff that changes routinely (like settings and crash logs) there's camera specific calibration data that isn't expected to change of the life of the camera, and cannot be easily re-created without Canon's calibration tools.

In general, the writable regions would be expected to be aligned some relatively large size (erase block size or larger), and runs of 0xff would be expected in unused space in between. So you should be able to do a fair job of identifying regions of interest with just a diff capable hex editor.

Another approach would be to to attempt to specifically identify the parts change from reverse engineer. Many of these like the romlog, adjustment table and flash params could likely be added to the sig finders without huge effort. This would be useful for other reasons, and could be scaled to cover the whole suite of cameras.

A third approach would be just worry about the known constant parts, i.e. the main firmware code and the data immediately after it. How to identify this varies by camera generation.
Don't forget what the H stands for.

*

Offline koshy

  • *****
  • 1030
Re: "refresh" feature for ROM area of Flash memory
« Reply #11 on: 25 / December / 2019, 19:52:08 »
;) How about treating them as RAW and marking bad pixels?  :haha
Sure... Only because we have a hammer all of a sudden every problem looks like a nail  :o
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

*

Offline koshy

  • *****
  • 1030
Re: "refresh" feature for ROM area of Flash memory
« Reply #12 on: 25 / December / 2019, 20:03:50 »
Q: If one has two FW dunps, how to best compare the static areas of the two to see if a bit has flipped by comparing the dumps?
I'm not aware of anyone having mapped this out in detail. See also "essentially unlimited list of things that would be interesting to investigate"  :haha
Right...

A third approach would be just worry about the known constant parts, i.e. the main firmware code and the data immediately after it. How to identify this varies by camera generation.
I think that was actually what I had in mind with the question at the time of writing. "identifying known constant parts". So that given a bunch of FW dumps one could tell if they match as far as can easily be said.

The other things you write about were pretty interesting, too. I might have a dozen cameras of each of a few models - I90, I95, I100, I970, I980 maybe something I forgot - If a group of dumps would be interesting I can make one or several one day.

"Specifically identifying the parts that change from reverse engineer" seems like something worthwhile at some point, if I can help with it le me know.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

*

Offline reyalp

  • ******
  • 12309
Re: "refresh" feature for ROM area of Flash memory
« Reply #13 on: 26 / December / 2019, 15:37:03 »
Quote
A third approach would be just worry about the known constant parts, i.e. the main firmware code and the data immediately after it. How to identify this varies by camera generation.
I think that was actually what I had in mind with the question at the time of writing. "identifying known constant parts".
Generally speaking, we already know where the main code and copied code and data blobs are. This can be extracted from information the sig finders put in stubs_entry.S. I'm actually almost done writing ghidra python script which uses stubs information to set up the memory map. Now thinking about making it usable from regular python, to bulk generate memory maps as CSV or something.

This wouldn't cover the whole firmware, but it's a decent fraction.

Quote
So that given a bunch of FW dumps one could tell if they match as far as can easily be said.
My impression is that most or all the writable data toward the end of the firmware. It's likely that everything between stuff identified in the previous item is also constant. If that were confirmed, it would give you a bigger chunk. You might also find that the modified data is always after some other recognizable point in the firmware.

Quote
"Specifically identifying the parts that change from reverse engineer" seems like something worthwhile at some point, if I can help with it le me know.
What I had in mind is looking at the disassembly for functions that reference writable data, and adding code to the sig finders to identify them (e.g. the ROMLOG sector is easy to find from known functions)
Don't forget what the H stands for.


*

Offline koshy

  • *****
  • 1030
Re: "refresh" feature for ROM area of Flash memory
« Reply #14 on: 06 / January / 2020, 19:50:58 »
I'm actually almost done writing ghidra python script which uses stubs information to set up the memory map.
I used it in Ghidra, pretty cool.
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)

 

Related Topics