在Mac OS下,是否可以将数据发送到另一个进程的标准输入? [英] Is there a way to send data to another process's standard input under Mac OS?

查看:118
本文介绍了在Mac OS下,是否可以将数据发送到另一个进程的标准输入?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想知道是否有一个API,无论它多么晦涩,它是否允许某人在Mac OS X下将数据发送到另一个进程的stdin流.在Linux下,如果我没记错的话,可以使用文件系统在/proc中访问这些流(当然具有正确的权限).

I was wondering if there was an API, however obscure it would be, that would allow someone to send data to another process's stdin stream under Mac OS X. Under Linux, if I remember correctly, you can use the filesystem in /proc to access these streams (with the correct permissions, of course).

我不知道.马赫港口,有人吗?

I dunno. Mach ports, anyone?

推荐答案

不幸的是,我不相信您可以做到-MacPorts都是用户级用户,并且您需要进行操作(要么很麻烦,要么请参见下文) ,或)内核合作,但我认为这种合作不会进行.例如,,有关文件描述符传递的部分说,

Unfortunately, I don't believe you can do that -- MacPorts are all userland, and the operation you require needs (either a lot of trickery, see below, or) kernel cooperation, which, I believe, isn't forthcoming. For example, Mac OSX Internals, a System Approach in the section on file-descriptor passing, says

描述符是进程本地的 因为只有在 获得了 通过打开一个文件来进行描述符描述.在 特别是,进程A无法访问 在另一个进程中打开的文件 B只需使用 表示文件的描述符 B.

The descriptor is local to the process in that it is meaningful only in the process that acquired the descriptorsay, by opening a file. In particular, a process A cannot access a file that is open in another process B by simply using the value of the descriptor representing that file in B.

然后继续描述FD的发送方式.

and then goes on to describe how FDs are sent.

棘手"部分将要求您获得一些代码才能在其他进程中运行(在用户区或作为内核的一部分).

The "trickery" part would require you getting some code of yours to run (either in userland or as part of the kernel) within the other process.

例如,您可以在用户区中通过修补可执行文件的二进制文件来执行此操作-在其启动路径的尽头找到可以执行的任何指令,然后跳转到您自己的代码,该代码将FD进入您的监视守护进程,执行修补指令,然后跳回到另一个进程的正常顺序流程.

For example, you could do it in userland by patching the binary file that's their executable -- find any instruction early in its startup path that's sure to be executed, and put in its stead a jump to your own code which sends the FD to your watching daemon process, executes the patched-away instruction, then jumps back to the other process's normal sequential flow.

要在内核级别执行此操作,将需要与内核代码本身或内核加载的代码类似的补丁,并且以完全未经验证的信任运行 (因此,它们可以劫持不相关进程的文件描述符表条目)-我肯定希望Mac OS X中没有这样的代码路径(因为它们的主要用途无疑是病毒,特洛伊木马和其他各种恶意软件的使用),但是如果存在,您可以找到它们,这可能是比修补每个感兴趣的二进制可执行文件更通用的解决方案.

To do it at kernel level would require similar patches to either the kernel code itself, or to code which the kernel loads and runs with entire, unverified trust (so they can hijack an unrelated process's file descriptor table entries) -- I sure hope there are no such code paths left in Mac OS X (since their main use would no doubt be by viruses, trojan horses, and other malware of all kinds) but, if there are and you can find them, this might be a more general solution than patching every single binary executable of interest.

回到用户领域,另一种相当通用的方法可能是修补所有感兴趣的进程都加载的动态加载的库,而不是修补各个进程的几个可执行文件.

Back to userland, another fairly general approach might be to patch dynamically loaded libraries that all processes of interest load, instead of patching the various processes' several executables.

这篇关于在Mac OS下,是否可以将数据发送到另一个进程的标准输入?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆