objdump

问题 Is there a reference to the source file in the binary? I tried running strings on the binary and couldn't find any reference to the source file listed... 回答1: objdump uses the DWARF debugging information compiled into the binary, which references the source file name. If the binary isn't compiled with debugging information, or objdump can't find the source file, then you don't get source code in your output - only assembly. You don't see the source file name when you use strings on the binary

问题 I have an object file and am trying to disassemble it. When I use: objdump -d example.o I get an assembly in code in the file format of elf64-x86-64 . I am trying to disassemble this into ARM, how do I go about doing this? 回答1: If you want to do disassemble of ARM code, you'd better have an ARM tool chain, this is what I got: http://bb.osmocom.org/trac/wiki/toolchain After you have this, you can use arm-elf-objdump instead of objdump. The command I used is arm-elf-objdump -D -b binary -marm

问题 If I run objdump -d on a (linux amd64) .o file, function calls show up without the link time resolution done. Example: 90: 66 89 44 24 1c mov %ax,0x1c(%rsp) 95: 44 89 74 24 10 mov %r14d,0x10(%rsp) 9a: e8 00 00 00 00 callq 9f <foo+0x9f> 9f: 83 f8 ff cmp $0xffffffffffffffff,%eax a2: 74 5e je 102 <foo+0x102> A branch within the function shows up properly, but the callq is just the stub put in for the linker (with four bytes of zeros available for the linker to put a proper address into). Is

问题 I'm trying to make a script or program that will take given bytes (given in hexadecimal), and convert them into a x86 instructions (For example c3 -> retq) I've tried doing it by calling gcc -c on an assembly file just containing retq retq and then using a script to insert bytes where it says "c3 c3", then using objdump -d to see what it says now. But it seems that it messes up the format of the file unless I only pass an instruction of the same size as the original instruction bytes. I'm

问题 Can I disassemble a flat binary file using objdump? I'm familiar with disassembling a structured binary executable such as an ELF file using: objdump -d file.elf But if I have a flat binary file that I know is supposed to be loaded at, e.g., address 0xabcd1000, can I ask objdump to disassemble it? I tried supplying options such as '--start-address=0xabcd1000' but objdump just states that it doesn't recognize the format. I have other ideas about how to disassemble the file but I wanted to know

问题 I need to get the information about global variables from a compiled c program. I asked a similar question in here. The problem that I have now is that the program where I am trying to extract the variables info is very big and it takes 4 seconds just to get the tree in text ( readelf -w[i] file.out ). Then I have to parse the tree jumping back and forth in order to get to the place that I need. For example if a variable is of type const unsigned char * volatile MyVariable then I will have to

问题 I have code as follow: #include <stdio.h> int g_a; int g_b; int g_c; int main() { printf("Hello world\n"); return 0; } And build it with gcc gcc -o global global.c Finally, I use objdump to see address of global variables objdump -t global And see the result: 00004020 g_b 00004024 g_a 00004028 g_c Why are global variables stored in addresses like above? I mean global variables should be stored in order g_a, g_b, g_c 回答1: global variables should be stored in order g_a, g_b, g_c No, the order

问题 I am using, arm-linux-gnueabi-gcc to compile C programs for ARM processor in Linux. However, I am not sure what is the default ARM mode for which it compiles. For example, for the C code: test.c unsigned int main() { return 0x1ffff; } arm-linux-gnueabi-gcc -o test test.c now, when I look at the disassembly of main() function with objdump, I can see: arm-linux-gnueabi-objdump -d test <main>: push {r7} add r7, sp, #0 movw r3, #65535 ; 0xffff movt r3, #1 mov r0, r3 mov sp, r7 pop {r7} bx lr it

问题 I am reading the book Hacking, the art of exploitation. In the book there is a section that explain the use of .dtors and .ctors . I'm trying to reproduce one of the exercises of the book but in my executable I do not have this sections. At first I thought the problem was that I was compiling for 64-bit, but now I'm compiling for 32-bit and .dtors and .ctors are still not appearing in the section table. Here is the code: #include <stdio.h> #include <stdlib.h> static void miConstructor(void) _