How to debug a raw binary with gdb

Question

I have a executable for an embedded device.
It does not have header information that gdb recognizes, but instead uses a proprietary header specified by the vendor.

I can analyse the file just fine using IDA-pro, but I'd like to run some code to see what it does.

The executable is loaded at address 0x52000000

However if I just load the file using

exec-file myfile

I get

"myfile": not in executable format: File format not recognized

And if I restore the memory at the correct location using:

restore myfile 52000000

I get:

You can't do that without a process to debug.

How do I get out of this chicken-and-egg problem?

I just want to jump in the middle of the code, set some registers to predetermined values and run some code to see what happens.
Note that I'm using the gdb ARM toolchain from ARM itself.

Note that I'm not interested in symbol tables, link to source code etc. I can read the ARM assembly just fine, I just want to run a section of code. — Johan, Mar 04 '14 at 16:44
Extract the binary only portion (strip proprietary header). You can use `objcopy` to create an object file from a binary; especially `-O binary` and `-j section`. Link with the object and use Linux `mmap` and `memcpy` (flush with `dsb`, `dmb`, `isb`, etc) and jump to the code at *0x52000000*, where you set the breakpoint. There are probably many other ways to do this. It is not clear what environment you wish to host *gdb* and the code with? — artless noise, Mar 04 '14 at 17:57
Actually, you maybe able to avoid `memcpy()` and `mmap` altogether by using a linker file which places the binary at *0x52000000*. Did you only want this to work with `gdb` alone or do you want to use other tools? — artless noise, Mar 04 '14 at 19:00

score 3 · Accepted Answer · answered Mar 05 '14 at 12:23

As per @artless_noise suggestion I did the following:

objcopy.exe 
--output-target=elf32-bigarm 
--input-target=binary 
--change-start=0x52000000 
INPUTFILE OUTPUTFILE

This adds an elf header to the file.
However it does not fix the whole problem.
The output of

readelf.exe -a OUTPUTFILE

gives:

ELF Header:
  Magic:   7f 45 4c 46 01 02 01 61 00 00 00 00 00 00 00 00
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            ARM
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           ARM
  Version:                           0x1
  Entry point address:               0x52000000
  Start of program headers:          0 (bytes into file)
  Start of section headers:          57316 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           40 (bytes)
  Number of section headers:         5
  Section header string table index: 2

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      0   0  0
  [ 1] .data             PROGBITS        00000000 000034 00df8c 00  WA  0   0  1
.....

Note that the .data section still has an address of 0x00000000. This should be 0x52000000.
To fix this I opened up a hex editor at address 0xdf8c.
This is close the where the section headers are. The structure of the section headers is as follows, along with the data I expect to be there.

typedef struct {
  Elf32_Word sh_name;    
  Elf32_Word sh_type;    = 1 {.data}
  Elf32_Word sh_flags;   = ?
  Elf32_Addr sh_addr;    = 0x00000000
  Elf32_Off sh_offset;   = 0x00000034
  Elf32_Word sh_size;    = 0x0000df8c
  Elf32_Word sh_link;
  Elf32_Word sh_info;
  Elf32_Word sh_addralign;
  Elf32_Word sh_entsize;
} Elf32_Shdr;

The first header is always all zeros, the second header is the .data section. So I look for the magic numbers and fill in the starting address, save the file and reload it into gdb.

Now it works

How to debug a raw binary with gdb

1 Answers1