获取objdump以反汇编原始x64代码的正确架构是什么？你会认为-m x86-64应该通过阅读帮助来工作,但事实并非如此.我尝试了两个cygwin64版本:
$ objdump --version
GNU objdump (GNU Binutils) 2.23.52.20130604
以及我的Fedora 18 x64 install(2.23.51.0.1-3.fc18 20120806)中的版本,但我只能得到can't use supplied machine x86-64.也试过amd64和x64,但没有任何工作.
该命令基本上是 objdump -b binary -D -m ??? file
[深呼吸.]我们有一个使用WxMotif 2.6.3弹出窗口的应用程序(GUI库不是 - 而不是 - 我的选择).它在32位ix86系统上运行良好.我的任务是将其转换为64位应用程序.它始终是错误的.我在RHEL 6上,所以我使用gcc 4.4.7编译.在咬牙切齿之后,问题显而易见:在wxFrame :: DoCreate中,m_mainWidget被设置(正确); 在wxFrame :: GetMainWidget中,它作为空指针返回.空指针导致崩溃.使用gdb,设置m_mainWidget的指令是
mov %rax,0x1e0(%rdx) # $rdx = 0x68b2f0
而获取m_mainWidget的代码是
mov 0x1f0(%rax),%rax # $rax = 0x68b2f0
在gdb中,我可以检查内存并看到0x68b4d0处的指针是正确的.为什么偏移不正确？
为了使事情更加混乱,当我使用objdump来反汇编libwx_motifd_core-2.6.so.0.3.1时,"get"程序集是
mov 0x1e0(%rax),%rax
在objdump中,get和set都使用0x1e0作为偏移量.到底是怎么回事？
我在这里上传了一些相关信息: GitHub
我已经包含了一个小程序,可以在我的系统上复制问题.
进一步研究,我在wxFrame :: DoCreate的反汇编中看到,进一步使用m_mainWidget使用0x1e0作为偏移量检索值(反汇编是在我使用-O0的编译中,所以代码必须返回内存每一次)."Just for Fun",我向wxFrame添加了一个新的成员变量 - m_myMainWidget - 并在设置m_mainWidget后立即设置它.然后我让wxFrame :: GetMainWidget()返回本地值(m_myMainWidget).你不知道吗:崩溃仍然发生,当我从gdb中反汇编时,GetMainWidget包含相同的+16偏移量.(偏移不在那里我使用objdump进行反汇编.)
我正在尝试构建一个通过调用objdump -d返回的汇编结果的控制流图.目前我提出的最好的方法是将结果的每一行放入链表中,并将每行的内存地址,操作码和操作数分开.我依靠objdump结果的常规性质将它们分开(内存地址是字符串2到字符串中代表每一行的字符7).
完成后,我启动实际的CFG指令.CFG中的每个节点都包含一个起始和结束内存地址,一个指向前一个基本块的指针,以及指向任何子基本块的指针.然后我将浏览objdump结果并将操作码与x86_64中所有控制流操作码的数组进行比较.如果操作码是控制流操作码,我将地址记录为基本块的末尾,并根据操作码添加两个子指针(条件操作码)或一个(调用或返回).
我正在用C实现这个过程,看起来它会起作用但感觉非常脆弱.有没有人有任何建议,或者我没有考虑的任何事情？
感谢您抽时间阅读!
编辑:
我的想法是使用它来比较DynamoRIO生成的系统调用的堆栈跟踪与目标二进制文件的预期CFG,我希望像这样构建它会促进这一点.我没有重复使用可用的东西,因为A)我真的没有关于它和B)我需要将图形转换为可用的数据结构,以便我可以进行路径比较.我将看一下您排行的页面上的一些实用程序,感谢您指出我正确的方向.感谢您的评论,我真的很感激!
我使用objdump来分析共享对象的内存使用情况.与.data和.rodata部分一起,我看到.data.rel.ro部分.
有谁知道这用了什么？
例:
$ objdump Logger.cpp.o -t
00000000 g F .text 00000000 .hidden __sti___10_Logger_cpp_0b2ae32b
我一直在深入研究Linux和C,我很好奇函数是如何存储在内存中的.我有以下功能:
void test(){
printf( "test\n" );
}
很简单.当我在具有此功能的可执行文件上运行objdump时,我得到以下内容:
08048464 <test>:
8048464: 55 push %ebp
8048465: 89 e5 mov %esp,%ebp
8048467: 83 ec 18 sub $0x18,%esp
804846a: b8 20 86 04 08 mov $0x8048620,%eax
804846f: 89 04 24 mov %eax,(%esp)
8048472: e8 11 ff ff ff call 8048388 <printf@plt>
8048477: c9 leave
8048478: c3 ret
一切看起来都正确.有趣的是,当我运行以下代码时:
int main( void ) {
char data[20];
int i;
memset( data, 0, sizeof( data ) );
memcpy( data, test, 20 * sizeof( char ) ); …我正在尝试用gcc反汇编为ARM构建的对象.不幸的是,objdump试图猜测代码是否是ARM和Thumb,并且错了:它认为我的代码是Thumb,而它实际上是ARM.
我看到objdump有一个选项可以强制它将所有指令解释为Thumb(-Mforce-thumb),但它没有强制ARM模式!
这对我来说似乎是一个非常奇怪的遗漏,它严重妨碍了我完成工作的能力(我在嵌入式设备上,我唯一的调试方法是查看反汇编).我尝试了各种方法,包括尝试告诉objdump使用不支持Thumb的ARM架构,但似乎没有任何工作.有任何想法吗？
(是的,我知道指令真的是 ARM ...)
我正在使用 ARM-GCC 4.7.4 为 Cortex-M4 编译代码。对于我们的调试工具，我需要有关人类可读格式（例如 .txt）的所有变量的名称、类型和地址的知识。地图文件提供了大部分信息，遗憾的是没有提供如下结构内容：
typedef struct { float32_t Ref; // Input: Reference Value
float32_t Fdb; // Variable: Feedback Value
float32_t Err; // Input: Control Error
float32_t Kp; // Parameter: Gain of the Proportional Part
float32_t Up; // Output: Output of Proportional Part
float32_t Ki; // Parameter: Gain of the Integral Part
float32_t Ui; // Output: Output of the Integral Part
float32_t OutPreSat; // Output: Not saturated Output
float32_t OutMax; // Parameter: Maximum Output
float32_t OutMin; // Parameter: …这是一个简单的程序：
void __attribute__ ((constructor)) dumb_constructor(){}
void __attribute__ ((destructor)) dumb_destructor(){}
int main() {}
我用以下标志编译它：
g++ -O0 -fverbose-asm -no-pie -g -o main main.cpp
我检查与gdb那个__libc_csu_init呼唤我标记瓦特/构造函数：
Breakpoint 1, dumb_constructor () at main.cpp:1
1 void __attribute__ ((constructor)) dumb_constructor(){}
(gdb) bt
#0 dumb_constructor () at main.cpp:1
#1 0x000000000040116d in __libc_csu_init ()
#2 0x00007ffff7abcfb0 in __libc_start_main () from /usr/lib/libc.so.6
#3 0x000000000040104e in _start ()
我认为该destructor属性意味着dumb_destructor()将在 期间调用__libc_csu_fini，但这并没有发生：
Breakpoint 1, dumb_destructor () at main.cpp:3
3 void __attribute__ ((destructor)) dumb_destructor(){} …我的目标是将 Rust 程序编译为尽可能小的二进制文件并提取机器代码。我编写了一个非常简单的程序来测试。
.cargo/配置
[target.x86_64-pc-windows-gnu]
rustflags = ["-C", "link-args=-e _start -static -nostartfiles"]
Cargo.toml
[package]
name = "r"
version = "0.1.0"
edition = "2021"
[profile.release]
panic = "abort"
opt-level = "z"
lto = true
codegen-units = 1
主程序.rs
#![no_std]
#![no_main]
#[panic_handler]
fn panic(_: &core::panic::PanicInfo) -> ! {
loop {}
}
#[no_mangle]
unsafe fn _start() -> isize {
42
}
我编译cargo build --target x86_64-pc-windows-gnu --release并提取该.text部分objcopy -j .text -O binary target/x86_64-pc-windows-gnu/release/r.exe r.bin，但是当我显示机器代码时，我得到的比我预期的要多：
% objdump -D -b binary …