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

  • 1
    This looks like objdump, it's a linear sweep so data will be interpreted as instructions but it's data. Look for .text seciton if you want code. This looks meaningless. – yaspr Aug 4 '18 at 20:25
  • resources.infosecinstitute.com/… – yaspr Aug 4 '18 at 20:25
  • @yaspr Yes, it's from objdump, but there is no .text section produced in the output. I used command mips-linux-gnu-objdump -D -b binary -m mips file.bin – minto Aug 4 '18 at 21:25
  • Use -d rather than -D – julian Aug 5 '18 at 0:37

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.

| improve this answer | |
  • The other files I disassembled also start from <.data> section, it's present in all files (bootloader, Image, Perm.nonvol, Dyn.nonvol) – minto Aug 4 '18 at 20:00
  • @minto are these ELF binaries? You need to determine their format and structure prior to disassembly – julian Aug 5 '18 at 2:05
  • These 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. – minto Aug 5 '18 at 12:01
  • @minto this is important information that should have been included in the question. Please edit your question. – julian Aug 5 '18 at 12:32
  • I'm inclined to think that the memory addresses I used to extract memory areas are incorrect, most likely they just don't match the real location of memory regions. – minto Aug 10 '18 at 19:02

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.

| improve this answer | |
  • Thanks for pointing to this. Really, .bin and .hex files do not have sections; they just have addresses which are equal to the byte index. I have to convert binary file to ELF file format at MIPS32 boot address for disassemble. – minto Aug 7 '18 at 12:23
  • I updated topic and have added new details. – minto Aug 7 '18 at 19:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.