Differences

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

--- reverse_engineering:ghidra:create_a_project [2022/03/12 12:00] – kitor
+++ reverse_engineering:ghidra:create_a_project [2022/04/01 17:46] (current) – [Initial analysis] kitor
@@ Line 51: / Line 51: @@
 === 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]]
-== Obtaining list of rom copy regions ==
+== Result ==
-You can obtain it from QEMU (see: [[reverse_engineering:qemu:run_firmware|Running firmware in QEMU]]).
-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:
-== Obtaining list of other regions ==
+{{ :reverse_engineering:ghidra:ghidra_r180_memory.jpg|}}
-As a rule of thumb:
+===== Initial analysis =====
-  * RAM starts at 0x40000000
-  * There's a mirror of RAM available at 0x00000000
-  * Size of RAM depends on model.
-  * 0xCxxxxxxx and 0xDxxxxxxx are ranges where most devices live
-Memory map for [[https://www.magiclantern.fm/forum/index.php?topic=19737.msg212603#msg212603|Digic 7]] [[https://www.magiclantern.fm/forum/index.php?topic=22770.msg212090#msg212090|Digic 8]] [[https://www.magiclantern.fm/forum/index.php?topic=24827.msg230859#msg230859|Digic X]]
+Project is now ready to start disassembling.
-== Defining ROMCOPY regions ==
+=== Configure auto analysis ===
-__Option a, via Memory map:__
+Navigate to ''Analysis -> Auto analysis "<file_name>"''.
-In ''Window -> Memory Map'' click green "+" symbol. This will open ''Add Memory Block'' panel.
+There's no good answer on what should be selected here (some tools may even crash Ghidra), but as a rule of thumb:
-  * Block Types: select "Byte mapped"
+  * Disable "Non-returning functions - discovered"
-  * Source address: self explanatory
+  * Disable "Embedded Media".
-  * Start address: start of "destination" block"
+  * Disable "Create Address Tables". In worst cases this option exhausts system memory and crashes Ghidra.
-  * Length: length of a block (note: it will accept input as decimal if you don't use ''0x'' prefix
-  * Block name: Something meaningful, like a memory address
-  * Select Read,Write,Execute flags.
-__Option B, via "Add to program":__
+Click ''Apply'' (do not click ''Analyze''!). Close the window.
-Go to ''File -> Add to program''. Select file extracted from ROM (eg with ''romcpy.sh''). Proceed like in case of adding 2nd ROM.
-Repeat for all regions.
-== Defining other regions ==
-Other regions (notably: RAM) will overlap with ROMCOPY regions defined earlier. Unfortunately that is not possible ("overlay" option does not apply for that case), so you will need to split continous blocks to fill around romcpy ones.
-In ''Window -> Memory Map'' click green "+" symbol. This will open ''Add Memory Block'' panel.
-  * Block Types: leave "Default"
-  * Start address: start of memory block
-  * Length: length of a block (note: it will accept input as decimal if you don't use ''0x'' prefix
-  * Block name: Something meaningful, like a memory address
-  * Select Read,Write flags
-  * Leave "Uninitialized"
-== Result ==
-Complete memory map for EOS R 1.8.0 (internal 7.3.9) firmware:
-{{ :reverse_engineering:ghidra:ghidra_r180_memory.jpg|}}
-===== Initial analysis =====
-Project is now ready to start disassembling.
 === Run disassembly ===
@@ Line 125: / Line 90: @@
 === Run auto analysis ===
-Navigate to ''Analysis -> Auto analysis "<file_name>"''.
+Go back to ''Analysis -> Auto analysis "<file_name>"''.
-There's no good answer on what should be selected here (some tools may even crash Ghidra), but as a rule of thumb:
-  * Disable "Non-returning functions - discovered"
-  * Disable "Embedded Media".
-  * 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.
-===== ROMCOPY regions from static analysis =====
-//this may want moving to a separate wiki entry later//
-While qemu ''-d romcpy'' is (arguably) the easiest way to obtain list of all chunks moved from ROM to RAM, it is imperfect.
-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.
-QEMU result might be slightly off as compared to code, as reads/writes are often aligned to bigger chunks.
-=== Obtaining list of ROMCOPY regions from DryOS (2nd stage) bootloader ===
-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.
-Read the code, note down each source address, destination start address and destination end address. Calculate region sizes.
-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> |