How to interpret disassembled MIPS code?

Question

I have disassembled MIPS binary with raw opcodes. How to interpret, for example, these lines:

Disassembly of section .data:

00000000 <.data>:
    ... ...
    f864:   30a5ffff    sd  ra,-23248(ra)
    f868:   00804021    addi    zero,t2,-32768
    f86c:   10a00017    bnez    t8,0xffff78b0
    f870:   00004821    addi    t0,t2,0

and these 3 lines:

25b8:   8c670000    syscall 0x19e
25bc:   8c680004    bltz    zero,0x1c7f0
25c0:   8c690008    j   0x1a630

what mean data in each column?

Edit: The files are contents of memory (in hex) of SPI Flash regions, converted to binary form (.bin) use xxd -r. The file command determines the file type of file.bin as data file type.

I tried transform binary into ELF:

mips-linux-gnu-objcopy -I binary -O elf32-little --rename-section .data=.text --change-address +0x80000000 file.bin file.elf

then to disassemble an ELF file:

mips-linux-gnu-objdump -m mips -D file.elf

Answer 1

The .data section is mapped to the data segment which is not executable. This is because it does not contain executable code; rather, it contains data (hence the name). As a result, when this data is treated as code and disassembled, the results will not be meaningful.

Answer 2

The columns are like follows:

  address| bytes     | disassembly
---------|-----------|--------------------------
    f864:|  30a5ffff |  sd  ra,-23248(ra)

Address usually corresponds to the execution address for structured file formats (e.g. ELF), but for raw binary it matches the plain file offset (i.e. the file is assumed to be loaded at 0). If you want to pretend that your file is loaded at another address, you can pass the --adjust-vma=OFFSET flag to objdump.

You don't see .text in the output because the raw binary has no section headers to describe its structure, so objdump makes up a pseudo-section .data to represent the file's contents. Normally data sections are not disassembled, so you need to use -D instead of -d to force its disassembly.

The disassembly you quote looks quite nonsensical, so probably you either have data intermixed with code (a common situation in embedded firmwares), or the binary is not MIPS code but some other architecture.

8c670000, 8c670004 and 8c670008 in the second snippet actually looks like a table of addresses to me, so probably it's data. You'll need to look through disassembly and sort out data from code.