How can I know if an ELF file is for Cortex-A or Cortex-M?

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?

Solution

If your binary follows the Arm ELF specification there is an attribute section that contains information on the cpu architecture and (if applicable) the architecture profile. This information can be extracted by readelf. Note that the information is the compiler and linkers view of things and can sometimes be wrong.

The first example below is from a binary built for Cortex-A8 and the second example is a binary built for Cortex-M33. Both are built using the IAR toolchain.

> readelf -A cortex-a8.out                                                       
Attribute Section: aeabi
File Attributes
  Tag_conformance: "2.10"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_PCS_config: Bare platform
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: small
  Tag_ABI_VFP_args: compatible
  Tag_CPU_unaligned_access: v6
  Tag_DIV_use: Not allowed

 > readelf -A cortex-m33.out
Attribute Section: aeabi
File Attributes
  Tag_conformance: "2.10"
  Tag_CPU_arch: v8-M.mainline
  Tag_CPU_arch_profile: Microcontroller
  Tag_THUMB_ISA_use: Yes
  Tag_FP_arch: FPv5/FP-D16 for ARMv8
  Tag_PCS_config: Bare platform
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: forced to int
  Tag_ABI_HardFP_use: SP only
  Tag_ABI_VFP_args: compatible
  Tag_CPU_unaligned_access: v6
  Tag_DIV_use: Not allowed