"refresh" feature for ROM area of Flash memory - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2]   Go Down

"refresh" feature for ROM area of Flash memory

  • 14 Replies
  • 8389 Views
*

Offline reyalp

  • ******
  • 14140
Re: "refresh" feature for ROM area of Flash memory
« Reply #10 on: 24 / December / 2019, 16:11:24 »
Advertisements
Quote from: koshy on 23 / December / 2019, 19:57:09
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.
Logged
Don't forget what the H stands for.
*

Offline koshy

  • *****
  • 1096
Re: "refresh" feature for ROM area of Flash memory
« Reply #11 on: 25 / December / 2019, 19:52:08 »
Quote from: Caefix on 24 / December / 2019, 10:46:02
;) 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
Logged
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

  • *****
  • 1096
Re: "refresh" feature for ROM area of Flash memory
« Reply #12 on: 25 / December / 2019, 20:03:50 »
Quote from: reyalp on 24 / December / 2019, 16:11:24
Quote from: koshy on 23 / December / 2019, 19:57:09
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...

Quote from: reyalp on 24 / December / 2019, 16:11:24
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.
Logged
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

  • ******
  • 14140
Re: "refresh" feature for ROM area of Flash memory
« Reply #13 on: 26 / December / 2019, 15:37:03 »
Quote from: koshy on 25 / December / 2019, 20:03:50
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)
Logged
Don't forget what the H stands for.
*

Offline koshy

  • *****
  • 1096
Re: "refresh" feature for ROM area of Flash memory
« Reply #14 on: 06 / January / 2020, 19:50:58 »
Quote from: reyalp on 26 / December / 2019, 15:37:03
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.
Logged
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...)
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal