ptrace mprotect调试麻烦

发布于 2024-12-10 01:28:56 字数 515 浏览 0 评论 0原文

我在一个研究项目上遇到了麻烦。 我正在尝试使用 ptrace 来观察目标进程的执行情况。 在 ptrace 的帮助下,我将 mprotect 系统调用注入到目标代码段(类似于断点)并将堆栈保护设置为 PROT_NONE。 之后我恢复原来的指令并让目标继续。 当我得到无效的许可段错误时,我再次注入系统调用以再次取消保护堆栈,然后我执行导致段错误的指令并再次保护堆栈。

(这确实适用于简单的程序。)

我现在的问题是,通过这种设置,目标(相当)在库函数调用中随机崩溃(无论我使用动态链接还是静态链接)。 我所说的崩溃是指,它要么尝试访问由于某种原因未映射的内存,要么只是一直挂在函数 __lll_lock_wait_private 中(在 malloc 调用之后)。

让我再次强调,崩溃并不总是发生,也不总是发生在相同的位置。

这听起来像是一个同步问题,但据我所知(这意味着我查看了 /proc/pid/tasks/),只有一个线程在运行。

那么您知道这可能是什么原因吗? 即使您不确定,也请告诉我您的建议,我在这里没有想法了......

I'm having trouble with an research project.
What i am trying to is to use ptrace to watch the execution of a target process.
With the help of ptrace i am injecting a mprotect syscall into the targets code segment (similar to a breakpoint) and set the stack protection to PROT_NONE.
After that i restore the original instructions and let the target continue.
When i get an invalid permisson segfault i again inject the syscall to unprotect the stack again and afterwards i execute the instruction which caused the segfault and protect the stack again.

(This does indeed work for simple programs.)

My problem now is, that with this setup the target (pretty) randomly crashes in library function calls (no matter whether i use dynamic or static linking).
By crashing i mean, it either tries to access memory which for some reason is not mapped, or it just keeps hanging in the function __lll_lock_wait_private (that was following a malloc call).

Let me emphasis again, that the crashes don't always happen and don't always happen at the same positions.

It kind of sounds like an synchronisation problem but as far as i can tell (meaning i looked into /proc/pid/tasks/) there is only one thread running.

So do you have any clue what could be the reason for this?
Please tell me your suggestions even if you are not sure, i am running out of ideas here ...

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

路弥 2024-12-17 01:28:56

不确定性也可能是由地址空间随机化造成的。
您可能想要禁用它来尝试使问题更具确定性。

编辑:

鉴于关闭 ASR 可以“修复”问题,那么潜在的问题可能是:

  1. 在应该有效的情况下认为 0 无效,反之亦然。 (我有什么)。
  2. 使用一次运行中的地址来对抗另一次运行?

It's also possible the non-determinism is created by address space randomization.
You may want to disable that to try and make the problem more deterministic.

EDIT:

Given that turning ASR off 'fixes' the problem then maybe the under-lying problem might be:

  1. Somewhere thinking 0 is invalid when it should be valid, or visaversa. (What I had).
  2. Using addresses from one run against a different run?
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文