edit 12/30/2019 - Current information is in the Wiki
https://chdk.fandom.com/wiki/Firmware_analysis_with_Ghidra----
Wondering if anyone is familiar with Ghidra, a recently opensourced disassembly tool, that might complement some of the other tools we use?
Merged topics.
I tried it briefly on windows. It's straightforward to set up and looks quite good. Java based UI is ugly as sin. Analyzing a full firmware takes a long time.
Some scripts / extensions would probably be helpful, for example to name functions based on funcs_by_*.csv.
I haven't explored this aspect, but it's supposed to be quite extensible. see below
Install / setup:
* Download and unzip file from
https://www.ghidra-sre.org/* Download and unzip current JDK
https://jdk.java.net/11/* Run ghidraRun.bat - it will prompt for JDK location if needed
Loading a dump
* New project, not shared (shared could be interesting...)
** Note: You need a project, but you can have many firmwares in a project, allowing use of the version control tool and having them open in the code viewer at the same time.
* Pick a directory. It will use significant diskspace (e.g ~500mb after initial analsys)
* With the project selected, choose file, import file, select primary.bin. I'm using sx710 here. Creating a folder in the project tree is a good idea if loading multiple firmwares. You can also name the "program" something other than PRIMARY.BIN
* Format - raw binary
* Language ARM v7t 32 bit little endian default (Digic 6 is v7, earlier should be v5t)
* Options - Block name ROM, Base address = ROMBASADDR (0xfc000000) File offset 0
* Double click on primary bin to open in default tool (code browser)
* It will prompt you to analyze. I clicked NO because I want to add additional copied code first.
* File -> Add to Program. PRIMARY.BIN again
* Options - Name RAMCODE, values from stubs entry: Base 0x010e1000, offset 0xd4742c (copied from adr - base), length 158672 (dec!)
* File -> Add to Program. PRIMARY.BIN again
* Options - Name BTCMCODE, values from stubs entry: Base 0xbfe10800, offset 0xd6dffc (copied from adr - base), length 27674 (dec, rounded up)
* File -> Add to Program. PRIMARY.BIN again
* Options - Name RAMDATA, values from stubs entry: Base 0x8000, offset 0xd1e5d4 (copied from adr - base), length 167512 (dec) - This helps seeing references to initialized RAM variables
* Tools - Window, memory map, uncheck X on RAMDATA
* Save
* Analysis - auto-analyze. I left the options at default, but just disassembling rather than decompiling might be a better initial choice.
* Go get a $beverage (like IDA, you can do stuff while it's analyzing, and it seems to prioritize what you have in view)
edit 12 06 2019
As of Ghidra 9.1, you can add file initialized data that uses the original file directly in the memory map, rather than using add to program again.
You can also split memory blocks which have initialized data. This allows you to split the executable and non-executable portions of the ROM code, which significantly speeds up analysis and leads to bad disassembly. The end of main ROM code can be found from the dryos version string associated with that ROM (referenced from early in the code) but beware there are multiple dryos instances in the ROM.
One particularly interesting, potentially CHDK relevant thing in the docs is the "version tracking" section:
Version Tracking refers to the process used by reverse engineers to identify matching code or data between different software binaries. One common use case is to version track two different versions of the same binary. Alternatively, version tracking techniques can be used to check for the presence of of a particular piece of code within a given binary of interest.
edit:
Screenshot
