November 2014 - Darwin-kernel

Re: accessing argv on exec
by Peter Moody 13 Nov '14

13 Nov '14

On Thu, Nov 13 2014 at 01:33, Quinn \"The Eskimo!\" wrote: > No it is not. The kernel does not keep a copy of the arguments passed to the process. Hey Quinn, So is there a way to get access to the process' memory from a kext (eg, reading p->user_stack seems like it would get me what I want)? Or is the suggested approach to use a userland daemon with kqueue() listener listing for NOTE_EXEC and then use libproc or sysctl KERN_PROCARGS to access argv? I 'spose I'll go try to hack this up. Cheers, peter _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: accessing argv on exec
by Quinn "The Eskimo!" 13 Nov '14

13 Nov '14

On 13 Nov 2014, at 08:51, James C <james.from.wellington(a)gmail.com> wrote: > I'm used to thinking that ps reads from a process's private memory in > order to get the command arguments. You are, in fact, correct [1]. The problem here is that you're not testing this correctly. Consider the following: --------------------------------------------------------------------------- $ cat hackArgv.c #include <stdio.h> #include <stdlib.h> #include <unistd.h> int main(int argc, char *argv[]) { int argIndex; for (argIndex = 0; argIndex < argc; argIndex++) { if (argIndex % 2) { if (argv[argIndex][0] != 0) { argv[argIndex][0] = 'X'; } } } fprintf(stderr, "Stopping ...\n"); pause(); return EXIT_SUCCESS; } $ cc hackArgv.c -o hackArgv $ ./hackArgv hello cruel world Stopping ... ^Z [1]+ Stopped ./hackArgv hello cruel world $ ps | grep hackArgv 34719 ttys000 0:00.00 ./hackArgv Xello cruel Xorld 34721 ttys000 0:00.00 grep hackArgv $ --------------------------------------------------------------------------- > That suggest that ps -f is reading from somewhere in the kernel. No it is not. The kernel does not keep a copy of the arguments passed to the process. Share and Enjoy -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware [1] Actually, modern versions of ps use libproc, but that in turn just grovels around in the process's address space. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

accessing argv on exec
by James C 13 Nov '14

13 Nov '14

I'm used to thinking that ps reads from a process's private memory in order to get the command arguments. Using the code below, I think that I have proved that this is false on OSX 10.6.8. That suggest that ps -f is reading from somewhere in the kernel. Would that be easy to walk down? Regards, James. ================ #include <stdio.h> #include <signal.h> int main(int argc, char *argv[]) /* hack every other argument into a pointer into unreadable low memory, * then sigstop myself */ { int i; for (i = argc; --i;) if (i%2) argv[i] = (char *)i; printf("Stopping ...\n"); kill(getpid(), SIGSTOP); return 0; } ================ $ make cc -g -g hackArgv.c -o hackArgv hackArgv.c: In function ‘main’: hackArgv.c:12: warning: cast to pointer from integer of different size $ ./hackArgv this that the other etc Stopping ... [1]+ Stopped ./hackArgv this that the other etc $ ps | fgrep hackArgv 82712 ttys002 0:00.00 ./hackArgv this that the other etc 82716 ttys002 0:00.00 fgrep hackArgv $ fg ./hackArgv this that the other etc $ ======================= On 11/13/14, darwin-kernel-request(a)lists.apple.com <darwin-kernel-request(a)lists.apple.com> wrote: <snip> Message: 7 > Date: Wed, 12 Nov 2014 10:45:41 -0800 > From: Peter Moody <pmoody(a)google.com> > To: "Manu ." <gnork99(a)hotmail.com> > Cc: darwin-kernel(a)lists.apple.com, markg(a)garetech.com.au > Subject: Re: accessing argv on exec > Message-ID: <r3nlhng1cmi.fsf(a)perdido.sfo.corp.google.com> > Content-Type: text/plain > > > On Tue, Nov 11 2014 at 22:52, Manu . wrote: >> You may also want to look at task_info. While it only gives you the all >> loaded images list, there is some code that >> you can find which can use task_info or get the offset of the structure in >> memory. There is a gContext variable in >> dyld that contains argv[] so if one can retrieve the loaded modules >> structure address, it should be possible to get >> the rest. Kind of wish that the arguments would be kept in the proc_t and >> made available (like on Windows EPROCESS >> -> PEB -> command line), alas it's not the case. > > Hey Manu, > > I'm probably missing something super obvious, but task_info() doesn't > appear to be resolvable from a kext. Were you suggesting doing this from > userspace? > >> Date: Tue, 11 Nov 2014 16:25:46 -0800 >> Subject: Re: accessing argv on exec >> From: meklort(a)gmail.com >> To: pmoody(a)google.com >> CC: darwin-kernel(a)lists.apple.com; markg(a)garetech.com.au > > >> Hi Peter,Here's some simple code form the days of 10.6. I expect it should >> still work with minor tweaks (and >> commenting the printfs). > > This is awesome! Thanks, Evan. > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

RE: accessing argv on exec
by Manu . 12 Nov '14

12 Nov '14

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: accessing argv on exec
by Peter Moody 12 Nov '14

12 Nov '14

On Tue, Nov 11 2014 at 22:52, Manu . wrote: > You may also want to look at task_info. While it only gives you the all loaded images list, there is some code that > you can find which can use task_info or get the offset of the structure in memory. There is a gContext variable in > dyld that contains argv[] so if one can retrieve the loaded modules structure address, it should be possible to get > the rest. Kind of wish that the arguments would be kept in the proc_t and made available (like on Windows EPROCESS > -> PEB -> command line), alas it's not the case. Hey Manu, I'm probably missing something super obvious, but task_info() doesn't appear to be resolvable from a kext. Were you suggesting doing this from userspace? > Date: Tue, 11 Nov 2014 16:25:46 -0800 > Subject: Re: accessing argv on exec > From: meklort(a)gmail.com > To: pmoody(a)google.com > CC: darwin-kernel(a)lists.apple.com; markg(a)garetech.com.au > Hi Peter,Here's some simple code form the days of 10.6. I expect it should still work with minor tweaks (and > commenting the printfs). This is awesome! Thanks, Evan. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: KPI: socket filter’s sf_data_in not called for data over IPSec VPN
by Vincent Habchi 12 Nov '14

12 Nov '14

Karl, > A kernel extension that uses sflt_register to register a socket filter that has the socket filter’s sf_data_in callback set usually works fine. But on OS X Yosemite, as soon as an IPSec VPN connection is established (using OS X’s built–in client configured via System Preferences > Network), data transmitted via the VPN does not cause that sf_data_in function to be called on OS X Yosemite. This problem applies to incoming packages of any protocol: TCP, UDP, ICMP, … > > Everything works fine on OS X Mavericks and earlier, but OS X Yosemite has that problem. Has anybody else encountered this problem and is there any known workaround? I can’t specifically answer but 10.10 has several bugs related to VPN. For example, it is impossible to open a PPTP VPN if your computer has a fixed IP address. It only works when DHCP is on. I think it might be worth filing a radar, so that all VPN related issues get worked on at the same time. Viel Grüß and Spaß! Vincent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

KPI: socket filter’s sf_data_in not called for data over IPSec VPN
by Karl Schwarzott 12 Nov '14

12 Nov '14

A kernel extension that uses sflt_register to register a socket filter that has the socket filter’s sf_data_in callback set usually works fine. But on OS X Yosemite, as soon as an IPSec VPN connection is established (using OS X’s built–in client configured via System Preferences > Network), data transmitted via the VPN does not cause that sf_data_in function to be called on OS X Yosemite. This problem applies to incoming packages of any protocol: TCP, UDP, ICMP, … Everything works fine on OS X Mavericks and earlier, but OS X Yosemite has that problem. Has anybody else encountered this problem and is there any known workaround? Cheers, Karl _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

RE: accessing argv on exec
by Manu . 12 Nov '14

12 Nov '14

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: accessing argv on exec
by Evan Lojewski 12 Nov '14

12 Nov '14

_______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0

Re: accessing argv on exec
by Peter Moody 11 Nov '14

11 Nov '14

On Tue, Nov 11 2014 at 13:11, Jay O'Conor wrote: > Hi Peter, > > Is this something that DTrace could handle instead of a custom kext? I’m curious if you’ve looked at the newproc.d > command (dtrace script)? > > Regards, > > — Jay Hi Jay, Maybe ..? It looks like newproc.d more or less has what I want, but it looks like running it full time incurs a fairly heavy performance penalty.. >> On Nov 10, 2014, at 3:02 PM, Peter Moody <pmoody(a)google.com> wrote: >> >> Hey folks, >> >> apologies for what will likely be a noobish question, I'm just getting >> acquainted with xnu and kexts and all that. >> >> I'm interested in monitoring process creation (and termination) on the >> mac. It looks like I can use a kext that registers a listener for >> kauth_fileop_exec to be notified of an exec, and the callback is: >> >> a) given a char* of the path the binary. >> b) run in the context of the newly executing binary (so proc_self() >> and the like work for getting pid/ppid, etc). >> >> but is there anyway that I can actually access the argv that was passed >> to the execve call? >> >> I'm trying to do this to help our incident response capabilities, where >> obviously just seeing that 'wget' was called is a lot less informative >> than seeing 'wget http://malware.badguy/rookkit.tgz' >> >> Cheers, >> peter >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/darwin-kernel/joconor%40fastmail.fm >> >> This email sent to joconor(a)fastmail.fm _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists… This email sent to site_archiver(a)lists.apple.com

1 0