Differences

This shows you the differences between two versions of the page.

--- reverse_engineering:ghidra:create_a_project [2022/03/12 11:34] – kitor
+++ reverse_engineering:ghidra:create_a_project [2022/04/01 17:46] (current) – [Initial analysis] kitor
@@ Line 33: / Line 33: @@
 Close by clicking OK on all dialogs, and then acknowledge the import result. File will appear in a project.
-===== Initial analysis =====
+===== Project preparation =====
 Click twice on newly imported file. It will bring up "Code Browser" window.
 Ghidra will ask if you want to perform auto analysis now - select **No**.
+=== Load 2nd ROM file (where applicable) ===
+Go to ''File -> Add to program''. Select second ROM file. Import dialog will appear, but this time it will have language settings already in place.
+Open ''Options'', set Block name to something meaningful and Base Address to ''0xF0000000'' for Digic 7,8,X
 === Fix memory map ===
-Navigate to ''Window -> Memory Map''. In the only existing row (representing loaded ROM image) __uncheck__ tick in "W" (writable) column. This may affect analysis, and affects decompiler results.
+Navigate to ''Window -> Memory Map''. In rows representing loaded ROM images __uncheck__ tick in "W" (writable) column. This may affect analysis, and affects decompiler results.
 === Add other memory regions ===
-Skip this step if you don't have a list of romcopy regions. It will result in incomplete project that may be missing important pieces (especially on Digic 6).
+This topic has a separate Wiki section: [[reverse_engineering:ghidra:memory_map|Defining memory map in Ghidra project]]
-You can obtain it from QEMU (see: [[reverse_engineering:qemu:run_firmware|Running firmware in QEMU]]).
+== Result ==
-It can be also obtained by reading decompiled code, that will be available in incomplete project.
+Complete memory map for EOS R 1.8.0 (internal 7.3.9) firmware:
-=== Run disassembly ===
+{{ :reverse_engineering:ghidra:ghidra_r180_memory.jpg|}}
-Jump to second level (DryOS) bootloader address (press 'G' in Listing window):
+===== Initial analysis =====
-^ CPU       ^ Address        ^
+Project is now ready to start disassembling.
-| Digic 6   | ''0xFE0A0000'' |
-| Digic 7,8 | ''0xE0040000'' |
-| Digic X   | ''0xE0100000'' |
-Press F12 to disassemble in Thumb mode. Wait for Ghidra to finish a task - it will discover a lot of functions so it will take some time.
+=== Configure auto analysis ===
-After it is done, we name that function ''firmware_entry''
-=== Run auto analysis ===
 Navigate to ''Analysis -> Auto analysis "<file_name>"''.
@@ Line 74: / Line 73: @@
   * Disable "Create Address Tables". In worst cases this option exhausts system memory and crashes Ghidra.
-Run the analysis - it will take a long time. After it is done, you may want to run "one shot" analysis for Embedded media and for Create Address Tables - but YMMV.
+Click ''Apply'' (do not click ''Analyze''!). Close the window.
+=== Run disassembly ===
-===== ROMCOPY regions from static analysis =====
+Jump to second level (DryOS) bootloader address (press 'G' in Listing window):
-While qemu ''-d romcpy'' is (arguably) the easiest way to obtain list of all chunks moved from ROM to RAM, it is imperfect.
+^ CPU       ^ Address        ^
+| Digic 6   | ''0xFE0A0000'' |
+| Digic 7,8 | ''0xE0040000'' |
+| Digic X   | ''0xE0100000'' |
-First of all, it includes all things - including bootloader FROMUTIL that is not needed and may mess up analysis ( it is not available after DryOS boots anyway). 2nd, it just tries to detect bulk memory moves - so a lot of "small regions" are false positives, and sometimes it misses other bits.
+Press F12 to disassemble in Thumb mode. Wait for Ghidra to finish a task - it will discover a lot of functions so it will take some time.
-QEMU result might be slightly off as compared to code, as reads/writes are often aligned to bigger chunks.
+After it is done, we name that function ''firmware_entry''
-=== Obtaining list of ROMCOPY regions from DryOS (2nd stage) bootloader ===
+=== Run auto analysis ===
-Navigate to ''firmware_entry''. Look in the decompiled code for ''for'' loops. Some will just write zeroes (we are not interested in those), other read from one address (in code rom range) and write to another address.
+Go back to ''Analysis -> Auto analysis "<file_name>"''.
-Read the code, note down each source address, destination start address and destination end address. Calculate region sizes.
+Run the analysis - it will take a long time. After it is done, you may want to run "one shot" analysis for Embedded media and for Create Address Tables - but YMMV.
-In disassembled code those may look like:
-<code>
-src = &DAT_e101ced8;
-for (dst = &DAT_00004000; dst < &DAT_00023770; dst = dst + 1) {
-  *dst = *src;
-  src = src + 1;
-}
-</code>
-Example, from SX740.102:
-^ source     ^ to:start              ^ to:end                ^ size                 ^
-| 0xe101ced8 | 0x4000                | 0x23770               | 0x1F770              |
-| 0xe103c648 | 0x23770               | 0x59f14               | 0x367A4              |
-| -          | <del>0x59f14</del>    | <del>0xddd1c</del>    | <del>ram erase</del> |
-| 0xe1072dec | 0xdf002800            | 0xdf00339c            | 0xB9C                |
-| -          | <del>0xdf00339c</del> | <del>0xdf0033a8</del> | <del>ram erase</del> |