My experiences and workarounds for mt6762 4.9 kernel

Hi,

thank you for this great tool! In the end I was able to get it working with my boot image: boot.zip

However, I needed some hacks I at least wanted to document here. I am not knowledgeable enough to properly fix those issues, but these should give at least some hints.

First of all, I was affected by #54 (my boot.img has ikconfig and it shows that it is definitely not using relative base), so I used a quick & dirty patch to get my boot image to parse without negative offsets:

diff --git a/vmlinux_to_elf/kallsyms_finder.py b/vmlinux_to_elf/kallsyms_finder.py
index 5279192..8bbc3ae 100755
--- a/vmlinux_to_elf/kallsyms_finder.py
+++ b/vmlinux_to_elf/kallsyms_finder.py
@@ -853,7 +853,7 @@ class KallsymsFinder:
             and 'ia64' not in self.version_string.lower()
             and 'itanium' not in self.version_string.lower()):
             
-            likely_has_base_relative = True
+            likely_has_base_relative = False
         
         # Does the system seem to be 64-bits?

After that, I had a valid ELF file that Ghidra was importing just fine, however all symbols were garbled, some examples:

I was able to fix that by following a quick procedure:

Call kallsyms-finder (with applied relative fix) and save the first line of actual output (ffffff8008080800 T do_undefinstr)
Mask last 3 bits (idea from

vmlinux-to-elf/vmlinux_to_elf/elf_symbolizer.py

Line 83 in fa5c930

progbits.section_header.sh_addr = first_symbol_virtual_address & 0xfffffffffffff000

)
Run vmlinux-to-elf with that base address:
./vmlinux-to-elf --base-address 0xffffff8008080000 boot.img new2.elf
Import resulting file into Ghidra

Now the symbols resolve properly:

I hope this information aids you in resolving the issues in the script.

Regards,
Nick

On another note, interestingly, /proc/kallsyms on the device has different offsets:
ffffff9887480800 T do_undefinstr
However, this does not seem to impact disassembling software.

Thank you, I ran into this issue while analysing the Rabbit R1's firmware, and your solution works

On another note, interestingly, /proc/kallsyms on the device has different offsets: ffffff9887480800 T do_undefinstr However, this does not seem to impact disassembling software.

btw I think this difference is because the ones you dump from /proc/kallsyms have been subjected to ASLR

glad to hear it was helpful :D I was reverse engineering a smartwatch kernel, funny to see how many form factors mt6765 family is used in