vmlinux-to-elf

تتيح هذه الأداة الحصول على ملف .ELF قابل للتحليل الكامل من صورة نواة vmlinux/vmlinuz/bzImage/zImage (سواء كانت كتلة ثنائية خام أو ملف .ELF موجودًا مسبقًا لكنه مجرّد من الرموز)، مع استعادة رموز الدوال والمتغيرات.

للقيام بذلك، تقوم بفحص النواة بحثًا عن جدول رموز النواة (kallsyms)، وهو جدول رموز مضغوط موجود في كل نواة تقريبًا، وبشكل شبه غير معدَّل.

نظرًا لأن جدول الرموز المعنيّ مضغوط في الأصل، فإنه يستعيد سلاسل نصية غير مرئية في الملف الثنائي الأصلي.

ينتج ملف .ELF يمكنك تحليله باستخدام IDA Pro وGhidra. لذلك تُعد هذه الأداة مفيدة للهندسة العكسية للأنظمة المدمجة.

الاستخدام:

# Command line:
vmlinux-to-elf <input_kernel.bin> <output_kernel.elf>

# Command line, list symbol addresses only:
kallsyms-finder <input_kernel.bin> # If installed with uv
vmlinux-to-elf.kallsyms-finder # If installed with snap

# Command line, just decompress the kernel:
vmlinuz-decompressor <input_kernel.bin> <output_kernel.bin> # If installed with uv
vmlinux-to-elf.vmlinuz-decompressor # If installed with snap

# Graphical:
vmlinux-to-elf-gui # If installed with uv
vmlinux-to-elf.gui # If installed with snap
flatpak run re.fossplant.vmlinux-to-elf # If installed with flatpak

التثبيت:

# Install CLI+GUI with Snap (recommended on Ubuntu)
sudo snap install vmlinux-to-elf

# Install CLI+GUI with yay (recommended on Arch, Manjaro)
yay -S vmlinux-to-elf libadwaita python-gobject

# Install CLI+GUI with uv (example with Fedora)
sudo dnf install -y uv glib2-devel libadwaita-devel gtk4-devel \
    gobject-introspection-devel python3-gobject-devel \
    python3-devel cairo-devel @development-tools
uv tool install vmlinux-to-elf[gui]
vmlinux-to-elf-gui --install-metadata # Install .desktop file

# Install CLI with uv and GUI with Flatpak (recommended on
# distributions with libadwaita < 1.6)
sudo dnf install -y uv flatpak @development-tools
uv tool install vmlinux-to-elf

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak install re.fossplant.vmlinux-to-elf

إعداد بيئة التطوير المحلية:

sudo snap install --classic astral-uv
sudo apt install git
git clone [email protected]:marin-m/vmlinux-to-elf.git

# Dependencies for the GTK-4 GUI
sudo apt install libgirepository-2.0-dev libadwaita-1-dev \
    gir1.2-adw-1 gir1.2-gtk-4.0 python3-dev blueprint-compiler

cd vmlinux-to-elf
cp -a .github/hooks/* .git/hooks/
# Download Python modules and initialize virtualenv (creates ".venv",
# call "source .venv/bin/activate" to set up)
uv sync --extra gui
# Add vmlinux-to-elf to $PATH, so that the commands are callable
# system-wide (creates a symlink to the source in "~/.local/bin")
uv tool install -e .[gui]

الميزات

• قبول كتلة ثنائية خام أو ملف نواة بصيغة ELF كمدخل [OK]
• كشف وفك ضغط تنسيقات الضغط الرئيسية المستخدمة في نواة لينكس تلقائيًا [OK]
• العثور على جدول رموز النواة المضمّن (kallsyms) واستخراجه من ملف الإدخال [OK]
• استنتاج بنية مجموعة التعليمات وترتيب البايتات وحجم البت، بالاعتماد من بين أمور أخرى على تواقيع مقدمات الدوال الشائعة [OK]
• استنتاج نقطة دخول النواة من الرموز الموجودة في جدول kallsyms [OK]
• توفير استنتاج أساسي لعنوان قاعدة النواة [OK] (في الوقت الحالي، اعتبر أنه عنوان أول رمز "TEXT" في الملف الثنائي مع مسح البتات السفلية 0xfff - يبدو أنه يعمل جيدًا بما يكفي)
• فك ضغط أنواع معينة من ملفات boot.img الخاصة بأندرويد، التي تبدأ بتوقيع سحري ANDROID! أو UNCOMPRESSED_IMG [OK]
• إنتاج ملف .ELF قابل للتحليل الكامل باستخدام IDA Pro أو Ghidra كمخرج [OK]

كيف يعمل حقًا؟

يمكن العثور على نبذة تاريخية مختصرة عن جدول رموز "kallsyms" في أعلى ملف "kallsyms.py". باختصار، أُدخل هذا الجدول في نواة لينكس حوالي عام 2004 بشكله الحالي، ويُستخدم لطباعة رسائل "Kernel oops"، من بين أمور أخرى.

يحتوي على مجموعات من "اسم الرمز" و"عنوان الرمز" و"نوع الرمز" (حيث تُعيَّن أنواع الرموز بحرف واحد بطريقة مشابهة لأداة nm)، وتكون هذه المعلومات معبأة بإحكام باستخدام خوارزمية ضغط بسيطة.

يوضح المخطط أدناه كيفية تسلسل هذه المعلومات داخل النواة، حيث يتم اكتشاف إزاحة كل بنية من البنى المعنية بواسطة vmlinux-to-elf من خلال الاستدلالات:

هذه الحقول ذات محاذاة وأحجام متغيرة، وقد تختلف أحجام الحقول باختلاف البنية وإصدار النواة أيضًا. لهذا السبب، خضعت vmlinux-to-elf للاختبار على مجموعة متنوعة من الحالات.

لدى OpenWRT منذ 2013 تصحيح يزيل الضغط عن جدول kallsyms افتراضيًا (عندما يكون بناء kallsyms قد مُكِّن من قبل المستخدم). يفعلون ذلك لتوفير المساحة عند إعادة الضغط فوق النواة باستخدام LZMA.

هذا يعني أن إدخالات kallsyms_token_table وkallsyms_token_address تختفي، وأن أسماء الرموز تستخدم نص ASCII عادي بدلًا من ذلك. هذه الحالة مدعومة أيضًا.

في نوى لينكس 6.2 القياسية، تُرمَّز مصفوفات kallsyms بالترتيب التالي:

1. kallsyms_addresses (أو kallsyms_offsets + kallsyms_relative_base)
2. kallsyms_num_syms
3. kallsyms_names
4. kallsyms_markers
5. kallsyms_seqs_of_names (6.2+ فقط)
6. kallsyms_token_table
7. kallsyms_token_index

بالنسبة لنوى لينكس 6.4+، يتغير هذا التخطيط إلى:

1. kallsyms_num_syms
2. kallsyms_names
3. kallsyms_markers
4. kallsyms_token_table
5. kallsyms_token_index
6. kallsyms_addresses (أو kallsyms_offsets + kallsyms_relative_base)
7. kallsyms_seqs_of_names

بينما تُحلَّل هذه العناصر بالترتيب التالي بواسطة خوارزمية التحليل الخاصة بـ vmlinux-to-elf:

1. kallsyms_token_table (البنية قبل الأخيرة)
2. kallsyms_token_index (البنية الأخيرة، بالاتجاه الأمامي)
3. kallsyms_markers (بالاتجاه الخلفي)
4. kallsyms_names (بالاتجاه الخلفي مجددًا)
5. kallsyms_num_syms (بالاتجاه الخلفي مجددًا)
6. kallsyms_addresses (أو kallsyms_offsets + kallsyms_relative_base) (بالاتجاه الخلفي مجددًا)

دعم النوى

يجب أن تدعم النوى من الإصدار 2.6.10 (ديسمبر 2004) حتى الإصدار الحالي 6.4 (اعتبارًا من أغسطس 2023). النوى الوحيدة غير المدعومة هي تلك التي تم تكوينها صراحةً بدون CONFIG_KALLSYMS. إذا لم يتم تعيين متغير تكوين النواة هذا أثناء البناء، فستحصل على: KallsymsNotFoundException: No embedded symbol table found in this kernel.

بالنسبة للنوى الخام، يمكن اكتشاف البنى التالية (باستخدام التواقيع السحرية من binwalk): MIPSEL, MIPSEB, ARMEL, ARMEB, PowerPC, SPARC, x86, x86-64, ARM64, MIPS64, SuperH, ARC.

يمكن اكتشاف تنسيقات ضغط النواة التالية تلقائيًا: XZ, LZMA, GZip, BZ2, LZ4, LZO وZstd.

الاستخدام المتقدم

يمكنك أيضًا الحصول على مخرج نصي فقط لأسماء رموز النواة وعناوينها وأنواعها باستخدام أداة kallsyms-finder، المرفقة أيضًا مع هذه الأداة. سيكون تنسيق مخرجاتها مشابهًا لملف procfs /proc/kallsyms.

يمكن تجاوز بعض المعاملات التي يُفترض أن تُستنتج تلقائيًا بواسطة الأداة (مثل مجموعة التعليمات أو عنوان القاعدة) في حال حدوث مشكلة. المواصفات الكاملة للمعاملات التي تتيح القيام بذلك معروضة أدناه:

$ vmlinux-to-elf -h
usage: vmlinux-to-elf [-h] [--e-machine DECIMAL_NUMBER] [--bit-size BIT_SIZE]
                      [--file-offset HEX_NUMBER] [--base-address HEX_NUMBER]
                      [--bss-size BSS_SIZE] [--use-absolute]
                      input_file output_file

Turn a raw or compressed kernel binary, or a kernel ELF without symbols, into a fully analyzable ELF whose symbols were extracted from the kernel symbol table

positional arguments:
  input_file            Path to the vmlinux/vmlinuz/zImage/bzImage/kernel.bin/kernel.elf file to make into an analyzable .ELF
  output_file           Path to the analyzable .ELF to output

options:
  -h, --help            show this help message and exit
  --e-machine DECIMAL_NUMBER
                        Force overriding the output ELF "e_machine" field with this integer value (rather than auto-detect)
  --bit-size BIT_SIZE   Force overriding the input kernel bit size, providing 32 or 64 bit (rather than auto-detect)
  --file-offset HEX_NUMBER
                        Consider that the raw kernel starts at this offset of the provided raw file or compressed stream (rather than 0, or the beginning of the ELF
                        sections if an ELF header was present in the input)
  --base-address HEX_NUMBER
                        Force overriding the output ELF base address field with this integer value (rather than auto-detect)
  --bss-size BSS_SIZE   Size in megabytes of the .bss section in the binary
  --use-absolute        Assume kallsyms offsets are absolute addresses

كيف يتم تنظيم الكود المصدري؟

إصلاحات الأخطاء والتحسينات، إلخ.

لا تتردد في فتح issue لأي اقتراح تحسين.

يُرجى إعطاء الأولوية للقضايا (issues) وطلبات السحب (pull requests) في مستودع Github الحالي عند الإبلاغ عن الأخطاء أو طرح الأسئلة، إلخ.

بدلًا من ذلك، يمكنك استخدام قناة الماتريكس هذه إذا كنت بحاجة إلى التواصل المباشر مع مؤلف المشروع، لكن يُرجى اعتبارها قناة ثانوية، مثلًا لإرسال عينات النوى؛ فما يُرسل هنا في غير ذلك يُرجَّح أن يضيع.