Hello,
I have a question when doing the binary analysis. For a given ELF file (hello.elf) that has already been identified for the ARM architecture, how can I quickly know if this ELF is for Cortex-A or Cortex-M? More specifically, I'm trying to identify the whole bare-metal images (or RTOS images like FreeRTOS) for the Cortex-M.
From the result of "file hello.elf":
% file hello.elf hello.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
We can only see that this ELF is for ARM.
And from the result of "readelf -h ./hello.elf":
% readelf -h ./hello.elf ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: ARM Version: 0x1 Entry point address: 0xcb5 Start of program headers: 52 (bytes into file) Start of section headers: 150896 (bytes into file) Flags: 0x5000200, Version5 EABI, soft-float ABI Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 5 Size of section headers: 40 (bytes) Number of section headers: 19 Section header string table index: 17
It's also only showing this file is for the ARM architecture.
So are there any other approaches that can quickly identify the target architecture of an ELF file?
Thank you for your time!
Maybe check out the section addresses? Cortex-M has (flash) code usually in 0-1fffffff, with RAM at 2000000-3fffffff or (external) 60000000-9fffffff, while don't most Cortex-A chips typically have all-ram architectures without the explicit "banks" of memory. (OTOH, Cortex-A will also have an MMU can I guess they could put their section starts whereever they want, including at Cortex-M-compatible locations?)
Not sure if this is what you are looking for:
$ readelf -A test.elf Attribute Section: aeabi File Attributes Tag_CPU_name: "7E-M" Tag_CPU_arch: v7E-M Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv4-D16 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_enum_size: small Tag_ABI_HardFP_use: SP only Tag_ABI_VFP_args: VFP registers Tag_CPU_unaligned_access: v6
Thank you for your reply! Yes, that's exactly what I'm looking for. However, this -A argument only works for those bare-mental applications. For the multi-world projects that are compiled into two executables (e.g, FreeRTOSDemo_s.axf, and FreeRTOSDemo_ns.axf), this argument does not give any output.
So do you have any suggestions to identify those executables mentioned above? Thank you for your time!
Interesting. The ELF I showed you was actually generated from an AzureRTOS project. So it is not bare-metal and -A still works.
For your multi-world project which seems to be MDK-based FreeRTOS one, I currently do not have similar setup to play with so am not able to provide further suggestion you need. Will try to look into this later.