Introduction[edit | edit source]
The Ghidra Version Tracking tool is a powerful tool for identifying equivalent code in different programs. It can be helpful for CHDK porting.
Additional details about the version tracking tool can be found in the Version Tracking section of the Ghidra help. The workflow described on this page is very loosely adapted from from the workflow section.
Prerequisites[edit | edit source]
Firmware dumps for the camera to be ported, and an already ported reference port, loaded and analyzed in Ghidra as described in Firmware analysis with Ghidra.
The reference and unported firmware should be the same CPU architecture (Ghidra "language"), and a similar model. For model similarity, being released close to the same time or having closer DryOS versions is often a better indicator than the being the same form factor or model line.
Workflow[edit | edit source]
Loading stubs[edit | edit source]
As described in Firmware analysis with Ghidra, the ImportCHDKStubs script should have been run on each firmware as part of the initial analysis. For the unported camera, exclude stubs_min.S and stubs_entry_2.s. For the ported camera, include all.
Version tracking works better if both programs are well analyzed, so some time spent cleaning up bad disassembly be worth while.
Create a version tracking session[edit | edit source]
- Close any source tool(s) and open the version tool by clicking the footprint icon in the main Ghidra window Tool Chest area.
- Start a new session, picking the ported cam as a source, new cam as destination.
- Click through the wizard interface. Warnings in the precondition checks can be ignored, but addressing them may give better results.
- Click the + in the toolbar, select the "exact symbol name" correlator and run by clicking next through the dialogs.
- In the list view, click the lightbulb to filter.
- Uncheck implied matches.
- Uncheck all sources except Imported and User Defined.
- Select all matches in the list view and click accept (flag icon in the toolbar). Good accepted matches theoretically help identify other matches. There might be a few bad stubs, but the vast majority should be good.
- Reset filters to default.
- Click the + again, select "exact function mnemonic" match. You can set minimum length to something longer (Suggested: 20) since many very short functions are nearly identical. Run.
- The mnemonic matches should also be fairly safe to accept in bulk, especially with a longer minimum length, although there are some larger functions duplicated in multiple locations.
Using the matches[edit | edit source]
Once the "exact function mnemonic" correlator completes, you can use the search bar on functions not found by the sig finder. If there's a match, it will be shown in the list. This includes not just the exact mnemonic matches, but also implied matches, where Ghidra identifies likely equivalent function by which functions and data they reference or are referenced by.
You can use the code browser of the ported firmware to jump to missing functions / variables and check whether there is a match. Clicking on a match in the main version tracking window or either source browser will jump both code browsers to the match.
In some cases, Ghidra will automatically identify the a match for a needed function or variable. Do not trust this blindly, you should examine the code and references to make sure it makes sense.
In cases where Ghidra does not identify a match, examining the references in the ported program source browser will often lead quickly to the equivalent function, or the conclusion that a direct equivalent no longer exists.
You can use do normal Ghidra operations like disassembly, adding comments, naming things etc in either code browser. Changes saved in the version tracking tools will remain in the programs the next time you open them in the regular code browser.