objdump

[Liyang131313]

'/home/qdb/hdfi-master/hdfi-master/install/riscv64-unknown-linux-gnu/bin/objdump' -S '/home/qdb/hdfi-master/hdfi-master/toolchain/gcc/build_linux/build-glibc-linux64/libc.so.6'

Hello, I would like to ask which libraries can be disassembled in addition to being able to disassemble libc.so.6. I want to use these libraries to complete an attack.

wish your best life！

[jim-wilson]

RISC-V objdump will work on any binary that contains RISC-V code. That includes executables, object files, and shared libraries. I generally use objdump -dr for object files and objdump -dR for shared libraries. objdump -S requires that the file was compiled with debug info, and may give confusing results at high optimization levels due to code reordering by the compiler.

[Liyang131313]

@jim-wilson

Thank you for your quick reply. I still can't disassemble other .so files except libc.so.6

For example: For extraction of a Turing-complete gadget set we inspected libc.so and libwebcore.so libraries of an Android 2.0 platform. Android's libc version is very compact, hence, we included Android's Web Browser library libwebcore.so to enlarge the code base Both of the libraries (by default) are linked into the memory space of an application to fixed addresses (ie, no ASLR 4 is used).

Is there a library file like libc.so and libwebcore.so of an Android 2.0 platform in RISC-V?

[jim-wilson]

If you are using glibc, libc.so is a linker script, a text file, that refers to libc.so.6, which is an actual shared library. So, no, you can't disassemble libc.so as there is no code in it. But you can disassemble libc.so.6. Try using the "file" program to see what kind of file you have.

I don't think there is any Android port to RISC-V yet, and I don't know what libwebcore.so is, so I can't comment on that.

Otherwise, as I said before, objdump will work on any shared library. I can't say anymore because you haven't reported any actual bug here, i.e. you haven't shown any command or the error from that command.

[Liyang131313]

@jim-wilson thank you for your reply. I understand that libc.so and libc.so.6 have soft links. The following command is executable：：： '/home/qdb/hdfi-master/hdfi-master/install/riscv64-unknown-linux-gnu/bin/objdump' -S '/home/qdb/hdfi-master/hdfi-master/toolchain/gcc/build_linux/ Build-glibc-linux64/libc.so.6'

But I also want to disassemble the shared libraries in the directory ：：： /home/qdb/hdfi-master/hdfi-master/install/lib: libcc1.so, libfesvr.so, libriscv.so, libspike_main.so. Excuting an order：：： '/home/qdb/hdfi-master/hdfi-master/install/riscv64-unknown-linux-gnu/bin/objdump' -S '/home/qdb/hdfi-master/hdfi-master/install/lib/libriscv. So'

The following error message will appear:：：： /home/qdb/hdfi-master/hdfi-master/install/lib/libriscv.so: file format elf64-little

/home/qdb/hdfi-master/hdfi-master/install/riscv64-unknown-linux-gnu/bin/objdump: can't disassemble for architecture UNKNOWN!

[jim-wilson]

Those look like native (x86?) libraries for the simulator, compiler, etc. A RISC-V objdump won't be able to disassemble them because they don't have RISC-V instructions in them.

Use the "file" command to see what kind of files they are.

gamma05:2060$ file libfesvr.so libfesvr.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7531fef03b49d596d0838d84ccd0b78f4bdffcbf, not stripped

[Liyang131313]

@jim-wilson Thank you very much for your patience. I found that the “”“”“”“/home/qdb/hdfi-master/hdfi-master/install/sysroot/usr/lib/”“”“”“”“ directory can be disassembled. Which of these libraries are shared in the RISC architecture and are standard as Representative, and what is the function of the library in ”“”“”“”/home/qdb/hdfi-master/hdfi-master/install/sysroot/usr/lib/gconv and the audit”“”“” folder?

[jim-wilson]

The sysroot dir is the target / dir, so yes, those are RISC-V libraries.

Gconv is part of glibc. It supports conversion from one character encoding to another. Try "man iconv" and "man 3 iconv" on a linux system with manual pages installed for more info.

audit I'm less familiar with, but it appears to be part of the glibc sotruss program. Try "man sotruss" to learn more about it.

[chlizheng]

@jim-wilson When I use gcc command to compile .c file, I get the direct instruction. But now,I want to get source instruction, how can I do it? best regards!

[jim-wilson]

What exactly do you mean by "source instruction"? Gcc -S gives you assembly code, gcc -c gives you an object file. Objdump -dr on an object file gives you assembly code with relocations. gcc -g -c will give an object file with debug info. Objdump -Sr on an object file with debug info will give you assembly code with relocations intermixed with the original source code. The more you optimize, the less sense the objdump -S output will make, because the compiler may move code around so much that objdump can't produce good output for -S. Objdump -S is unlikely to be very useful at -O2.

[RojasMilo]

Hello @jim-wilson I would like to ask, how can I get instructions from a bin file with:

• -march=rv32i

• -mabi=ilp32

• no compress

• no floating point

• no pseudo-instructions

  I am trying with:

• riscv32-unknown-elf-objdump -D -b binary -m riscv:rv32 -M no-aliases file.mem > file.s

As I understand the default option is floating and compress instructions :(

Hope you can help me.

[jim-wilson]

Disassembler reports whatever is in there. If you don't want F and C in the code, then you have to compile without them, e.g. use -march=-rv32i -mabi=ilp32 when compiling, and then objdump will show no F and C code in the result. If you still see F and C code in the result, then you could have source code that expliciyly uses them. E.g. an asm file can use ".option rvc" to enable C support, emit a C instruction, and then use ".option norvc" to disable C support again. There is noithing that the compiler or objdump can do about that. You need to fix the source code. Or alternatively, you could be linking with the wrong libraries, and the libraries have F and/or C code in them. The disassembler will give function names, so if you see F or C code then using the furnction name search backward to find out where they came from.

[RojasMilo]

@jim-wilson Thank you for the fast replay.

I already use -march=rv32i and -mabi=ilp32 when compiling, the program compile and execute in the processor perfectly (the processor doesn't support compress or floating point instructions).

In the asm file I do not see any ".option rvc" or ".option norvc".

Compress instructions only appears when use -M no-aliases

Disassembly of section .data:

00000000 <.data>:
       0:   3020                    c.fld   fs0,96(s0)
       2:   3030                    c.fld   fa2,96(s0)
       4:   3030                    c.fld   fa2,96(s0)
       6:   3930                    c.fld   fa2,112(a0)
       8:   30200a33            0x30200a33
       c:   3030                    c.fld   fa2,96(s0)
       e:   3030                    c.fld   fa2,96(s0)
      10:   3131                    c.jal   0xfffffc1c
      12:   30200a33            0x30200a33

With no -M option:

Disassembly of section .data:

00000000 <.data>:
       0:   3020                    fld fs0,96(s0)
       2:   3030                    fld fa2,96(s0)
       4:   3030                    fld fa2,96(s0)
       6:   3930                    fld fa2,112(a0)
       8:   30200a33            0x30200a33
       c:   3030                    fld fa2,96(s0)
       e:   3030                    fld fa2,96(s0)
      10:   3131                    jal 0xfffffc1c
      12:   30200a33            0x30200a33

How can I check the libraries? to see if I have F or C code in them. Is related to the riscv-gnu-toolchain installation options?

regards!

[jim-wilson]

Stop using -D. This is almost always a mistake. If you see docs that recommend use of -D file a bug report against them. use -d instead.

You have 00000000 <.data>: 0: 3020 c.fld fs0,96(s0)

This is not a compressed instruction. This is data that just accidentally happens to look like a compressed instruction. The solution is to stop trying to disassemble data. You won't find instructions in there except in very rare circumstances, e.g. a compiler might have instruction templates in data, but disassembling them is unlikely to be useful to anyone other than the person writing the compiler, and then only to verify that the templates are correct.

[RojasMilo]

@jim-wilson

Thank you for the help, sadly I couldn't disassembly from .mem file.

Disassembly from elf (-D and -d) or bin (only with -D) works fine.

I think something is missing for objdump to go back to asm, I use:

riscv32-unknown-elf-objcopy -O binary ./dumped_files/boot.elf ./dumped_files/boot.bin

od -t x4 -An -w4 -v ./dumped_files/boot.bin > boot.mem

[jim-wilson]

Only disassembly of ELF files is expected to work. bin and mem files don't have the info necessary for the disassebler to give correct results.