【问题标题】:strace output questionstrace 输出问题
【发布时间】:2011-08-16 05:12:42
【问题描述】:

我在 CentOS 和 Debian 上运行一个程序。输出完全相同,但在 Centos 中我得到了 3 行粗体,而在 Debian 中我没有。这 3 行是关于什么的,我怎样才能在 Debian 中获得它们?

execve("./z1", ["./z1"], [/* 31 vars */]) = 0 brk(0) = 0x8458000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (没有那个文件或目录) mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f41000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (没有这样的文件或目录) 打开(“/home/myuser/public_html/libs/libmudflap.so.0”,O_RDONLY)= 3 读(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0PJ\0\ 0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=105432, ...}) = 0 mmap2(NULL, 943136, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xd89000 mmap2(0xda2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19) = 0xda2000 mmap2(0xda3000, 836640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xda3000 关闭(3)= 0 打开(“/home/myuser/public_html/libs/libc.so.6”,O_RDONLY)= 3 读(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320m\ 1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1327556, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f40000 mmap2(NULL, 1337704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x891000 mprotect(0x9d1000, 4096, PROT_NONE) = 0 mmap2(0x9d2000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x140) = 0x9d2000 mmap2(0x9d5000, 10600, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x9d5000 关闭(3)= 0 打开(“/home/myuser/public_html/libs/libdl.so.2”,O_RDONLY)= 3 读(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\n \0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=9736, ...}) = 0 mmap2(NULL, 12408, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x74e000 mmap2(0x750000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x750000 关闭(3)= 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f3f000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7f3f6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 open("/dev/urandom", O_RDONLY) = 3 读取(3, "\f\233\37", 3) = 3 关闭(3) = 0 mprotect(0x750000, 4096, PROT_READ) = 0

【问题讨论】:

  • 如果您不知道它们是做什么的,为什么还要在 Debian 中使用它们?您要解决的实际问题是什么?
  • 你可以随时连接 gdb,在 open 上设置断点,为文件名添加条件 /dev/urandom 并运行...你会看到它到底叫什么

标签: c linux binary centos strace


【解决方案1】:

我认为这与 strace 无关。我不确定,但这可能与记忆中事物的排列方式有关。我知道一些系统将二进制文件的一部分放在内存中的随机位置,以防止恶意活动。这称为Address Space Layout Randomization (ASLR)。我猜当时 CentOS 正在使用它,而 Debian 没有。有关在 CentOS 中禁用 ASLR 的信息,请参阅 this post。试试看 strace 是否仍然显示 /dev/urandom 正在打开。

所以关键是它可能是您的系统,而不是 strace 或导致差异的程序。

-- 编辑--

所以我上面可能错了。我对这个问题进行了大量研究,并设法缩小范围。我发现它很可能是一个库进行这些调用。我使用的方法有点复杂,但可行。 See this post 如果您仍然好奇,它是如何完成的。

我使用 gnome 之眼 (eog) 进行了此调试,因为我编写的简单测试程序没有触发 urandom 的读取。事实证明,Gkt+ 是我的罪魁祸首,它使用随机数为某些对象创建唯一 ID。我很想知道您的程序正在使用什么来进行这些调用。在这一点上,我怀疑它是 ASLR。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2023-03-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-09-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多