【问题标题】:Hijacking __NR_read and bash crashes (caf user?)劫持 __NR_read 和 bash 崩溃(caf 用户?)
【发布时间】:2013-07-10 16:05:14
【问题描述】:

我正在劫持__NR_readsys_read 调用),每次我用自己的系统调用劫持原始系统调用时,都会导致 bash 崩溃(在所有打开的 KDE“konsoles”中)(也就是说,尽快当我劫持sys_open)。

我想知道这是我的代码中的错误(可能)还是由于其他原因而发生的。

我的问题是:如果崩溃是由我的代码引起的,究竟是什么原因造成的,我该如何(如果可能)修复它?如果崩溃不是由我的代码引起的,是什么原因造成的?

我的代码在这里:https://github.com/alexandernst/procmon/tree/master/procmon_kmodule

syshijack.c 是我获取系统调用表的位置,hookfns.c 是我劫持系统调用的位置。

PS:我之前在这里Hijacking sys calls 已经问过这个问题,但现在它改变了,因为一旦我劫持系统调用就会发生崩溃。

* 编辑 *

我认为这个错误来自 hook/unhook 调用,所以我创建了一个问题 https://github.com/alexandernst/procmon/issues/7 无论如何,我看不出是什么导致了崩溃/冻结。

【问题讨论】:

    标签: linux linux-kernel kernel-module


    【解决方案1】:

    钩子引擎在我的x86_64 没有IA32 部分和hooked_sys_read 中除了r = real_sys_read() 之外没有你的代码工作正常。挖掘您的代码,我发现 IA32 挂钩可能存在问题:

    #define HOOK(F, RF, FF) RF = sys_call_table[F]; sys_call_table[F] = FF;
    #ifdef CONFIG_IA32_EMULATION
        #define HOOK_IA32(F, RF, FF) ia32_sys_call_table[F] = FF;
    #endif
    

    .. 所以HOOK_IA32 不存储RF 值,因为它在HOOK 宏中实现。看看吧。

    至于其他...path_from_fd 在我看来很丑。

    祝你好运;)

    【讨论】:

    • 抱歉之前没有回答。我在办公室。确实,HOOK IA32 宏中有一个错误。我只是推了一个修复。无论如何,这不是问题。每当我调用 hook/unhook 几次时,我正在测试的虚拟机就会一直冻结。
    • 嘿,你知道VirtualBox(可能是其他VM)不能正确模拟sidt指令吗?我发现 sidt 在我的情况下返回错误值并使用不同的符号查找方法来获取 sys_call_table 条目。看来你也有同样的问题……
    • 哦。所以也许我的模块在真机上工作得很好?我不愿意在我的真机上测试它,但也许我应该。让我试一试
    • 不,错误的决定。它只是冻结了我的整个机器,我不得不将其关闭... :(
    猜你喜欢
    • 2019-08-26
    • 1970-01-01
    • 2016-05-31
    • 1970-01-01
    • 2011-05-15
    • 1970-01-01
    • 1970-01-01
    • 2012-05-16
    相关资源
    最近更新 更多