| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| projects:3dprinting:flashforge_creator_3_pro_fan_fix [2025/05/02 22:03] – [System Software Details] admin | projects:3dprinting:flashforge_creator_3_pro_fan_fix [2025/05/02 22:57] (current) – [Examining the main application creator3-arm] admin |
|---|
| Please click on [[projects:3dprinting:flashforge_creator_3_pro_fan_fix:dropbear|this link]] for more information about how to build dropbear and install it to get ssh working. | Please click on [[projects:3dprinting:flashforge_creator_3_pro_fan_fix:dropbear|this link]] for more information about how to build dropbear and install it to get ssh working. |
| |
| Once a terminal connection is made to the printer, serious reverse engineering can start. There are several great tools for reverse engineering. I highly recommend [[https://ghidra-sre.org/|Ghidra]]. It is an open-source disassembler and can do a few things which make it so much easier to understand what is going on. It is able to create from the raw binary ELF file an abstract kind of C code. It automatically adds labels to variables and memory locations, is able to create function graphs which shows the flow of the code and much more. | Once a terminal connection is made to the printer, and we have a chance to look at the start-up procedure and system setup, more serious reverse engineering can start. There are several great tools for reverse engineering. I highly recommend [[https://ghidra-sre.org/|Ghidra]]. It is an open-source disassembler and can do a few things which make it so much easier to understand what is going on. It is able to create from the raw binary ELF file an abstract kind of C code. It automatically adds labels to variables and memory locations, is able to create function graphs which shows the flow of the code and much more. |
| |
| ==== Reverse engineering - I ==== | ==== Reverse engineering - I ==== |
| * PHDR program header, which contains the program header table and its concerning metadata. | * PHDR program header, which contains the program header table and its concerning metadata. |
| * INTERP program header, which tells the kernel that the file depends on an external loader file (/lib/ld-linux.so.3) to bring itself into memory. The other important task of the loader is that if dynamically linked libraries are used, a relocation process is done, using the global symbol table. | * INTERP program header, which tells the kernel that the file depends on an external loader file (/lib/ld-linux.so.3) to bring itself into memory. The other important task of the loader is that if dynamically linked libraries are used, a relocation process is done, using the global symbol table. |
| * LOAD program headers, tells the kernel and the loader how to get the program's data into memory. Each LOAD header directs the loader to create a region of memory with a given size, memory permissions, and alignment criteria, and tells the loader which bytes in the file to place in that region. The first LOAD header region is 0x330a88 bytes long and occupies the same size in memory, placed at virtual address 0x10000 with 64KB alignment and read + executable permissions. Given the large size, it is expected to find here the executable code which needs to be examined. As we will see later on, the size is not using a full 64K alignment boundary, which means, that if we would need some extra space for additional code, we could increase the size until it aligns without the necessity to relocate higher adjacent regions. | * LOAD program headers, tell the kernel and the loader how to get the program's data into memory. Each LOAD header directs the loader to create a region of memory with a given size, memory permissions, and alignment criteria, and tells the loader which bytes in the file to place in that region. The first LOAD header region is 0x330a88 bytes long and occupies the same size in memory, placed at virtual address 0x10000 with 64KB alignment and read + executable permissions. Given the large size, it is expected to find here the executable code which needs to be examined. Luckily, as we will see later on, the size is not using a full 64K alignment boundary, which means, that if we would need some extra space for additional code, we could increase the size until it aligns without the necessity to relocate higher adjacent regions. |
| * DYNAMIC program header, which is used by the loader to create dynamically links to their shared library dependencies. It is also used by the loader to fix relocations for program code and pointers, if the program resides at a different place in memory than it expects based on its virtual address. | * DYNAMIC program header, which is used by the loader to create links to their shared library dependencies. It is also used by the loader to fix relocations for program code and pointers, if the program resides at a different place in memory than it expects based on its virtual address. |
| * NOTE program header potentially contains vendor-specific metadata about the program itself, describing a table of key-value pairs where each entry has a string name mapped to a sequence of bytes that describe the entry. | * NOTE program header potentially contains vendor-specific metadata about the program itself, describing a table of key-value pairs where each entry has a string name mapped to a sequence of bytes that describe the entry. |
| * GNU_STACK program header defining memory regions where the stack is marked with a no-execute flag. With this flag code cannot be executed if it is on the stack. | * GNU_STACK program header defining memory regions where the stack is marked with a no-execute flag. With this flag code cannot be executed if it is on the stack. |
| \\ | \\ |
| which outputs the following:\\ | which outputs the following:\\ |
| |There are 29 section headers, starting at offset 0x332934: ||||||||||| | <code bash> |
| ^ Section Headers: ^^^^^^^^^^^ | There are 29 section headers, starting at offset 0x332934: |
| ^ [Nr] ^ Name ^ Type ^ Addr ^ Off ^ Size ^ ES ^ Flg ^ Lk ^ Inf ^ Al ^ | Section Headers: |
| | [ 0] | | NULL | 00000000 | 000000 | 000000 | 00 | | 0 | 0 | 0 | | [Nr] Name Type Addr Off Size ES Flg Lk Inf Al |
| | [ 1] | .interp | PROGBITS | 00010134 | 000134 | 000013 | 00 | A | 0 | 0 | 1 | | [ 0] NULL 00000000 000000 000000 00 0 0 0 |
| | ... | ... | ... | ... | ... | ... | .. | .. | . | . | . | | [ 1] .interp PROGBITS 00010134 000134 000013 00 A 0 0 1 |
| | [ 5] | .dynsym | DYNSYM | 00012338 | 002338 | 004830 | 10 | A | 6 | 1 | 4 | | [ 2] .note.ABI-tag NOTE 00010148 000148 000020 00 A 0 0 4 |
| | [ 6] | .dynstr | STRTAB | 00016b68 | 006b68 | 0081ae | 00 | A | 0 | 0 | 1 | | [ 3] .note.gnu.build-i NOTE 00010168 000168 000024 00 A 0 0 4 |
| | ... | ... | ... | ... | ... | ... | .. | .. | . | . | . | | [ 4] .hash HASH 0001018c 00018c 0021ac 04 A 5 0 4 |
| | [ 9] | .rel.dyn | REL | 0001f74c | 00f74c | 000160 | 08 | A | 5 | 0 | 4 | | [ 5] .dynsym DYNSYM 00012338 002338 004830 10 A 6 1 4 |
| | [10] | .rel.plt | REL | 0001f8ac | 00f8ac | 001fe8 | 08 | A | 5 | 12 | 4 | | [ 6] .dynstr STRTAB 00016b68 006b68 0081ae 00 A 0 0 1 |
| | ... | ... | ... | ... | ... | ... | .. | .. | . | . | . | | [ 7] .gnu.version VERSYM 0001ed16 00ed16 000906 02 A 5 0 2 |
| | [13] | .text | PROGBITS | 00024938 | 014938 | 1a863c | 00 | AX | 0 | 0 | 8 | | [ 8] .gnu.version_r VERNEED 0001f61c 00f61c 000130 00 A 6 5 4 |
| | [14] | .fini | PROGBITS | 001ccf74 | 1bcf74 | 000008 | 00 | AX | 0 | 0 | 4 | | [ 9] .rel.dyn REL 0001f74c 00f74c 000160 08 A 5 0 4 |
| | [15] | .rodata | PROGBITS | 001ccf80 | 1bcf80 | 13b5d4 | 00 | A | 0 | 0 | 8 | | [10] .rel.plt REL 0001f8ac 00f8ac 001fe8 08 A 5 12 4 |
| | ... | ... | ... | ... | ... | ... | .. | .. | . | . | . | | [11] .init PROGBITS 00021894 011894 00000c 00 AX 0 0 4 |
| | [24] | .data | PROGBITS | 0035232c | 33232c | 00046c | 00 | WA | 0 | 0 | 4 | | [12] .plt PROGBITS 000218a0 0118a0 003098 04 AX 0 0 4 |
| | [25] | .bss | NOBITS | 00352798 | 332798 | 003044 | 00 | WA | 0 | 0 | 8 | | [13] .text PROGBITS 00024938 014938 1a863c 00 AX 0 0 8 |
| | ... | ... | ... | ... | ... | ... | .. | .. | . | . | . | | [14] .fini PROGBITS 001ccf74 1bcf74 000008 00 AX 0 0 4 |
| | [28] | .shstrtab | STRTAB | 00000000 | 332833 | 000101 | 00 | | 0 | 0 | 1 | | [15] .rodata PROGBITS 001ccf80 1bcf80 13b5d4 00 A 0 0 8 |
| | Key to Flags:\\ W (write), A (alloc), X (execute) ||||||||||| | [16] .ARM.extab PROGBITS 00308554 2f8554 02f408 00 A 0 0 4 |
| | [17] .ARM.exidx ARM_EXIDX 0033795c 32795c 009128 00 AL 13 0 4 |
| | [18] .eh_frame PROGBITS 00340a84 330a84 000004 00 A 0 0 4 |
| | [19] .init_array INIT_ARRAY 00351000 331000 0001d4 00 WA 0 0 4 |
| | [20] .fini_array FINI_ARRAY 003511d4 3311d4 000004 00 WA 0 0 4 |
| | [21] .jcr PROGBITS 003511d8 3311d8 000004 00 WA 0 0 4 |
| | [22] .dynamic DYNAMIC 003511dc 3311dc 000148 08 WA 6 0 4 |
| | [23] .got PROGBITS 00351324 331324 001008 04 WA 0 0 4 |
| | [24] .data PROGBITS 0035232c 33232c 00046c 00 WA 0 0 4 |
| | [25] .bss NOBITS 00352798 332798 003044 00 WA 0 0 8 |
| | [26] .comment PROGBITS 00000000 332798 00006a 01 MS 0 0 1 |
| | [27] .ARM.attributes ARM_ATTRIBUTES 00000000 332802 000031 00 0 0 1 |
| | [28] .shstrtab STRTAB 00000000 332833 000101 00 0 0 1 |
| | Key to Flags: |
| | W (write), A (alloc), X (execute), M (merge), S (strings), I (info), |
| | L (link order), O (extra OS processing required), G (group), T (TLS), |
| | C (compressed), x (unknown), o (OS specific), E (exclude), |
| | y (purecode), p (processor specific) |
| | </code> |
| |
| For clarity some sections have been left out. Most of the time the following sections are interesting for reverse engineering: | For clarity some sections have been left out. Most of the time the following sections are interesting for reverse engineering: |
