[prev in list] [next in list] [prev in thread] [next in thread]
List: strace
Subject: Re: Advanced and improved absolute paths decoding
From: eQuiNoX <equinox.71717171 () gmail ! com>
Date: 2014-02-26 17:47:26
Message-ID: CAA5xPpn7Lxyv+0Oo1gWaEgx7B23QofYR-cRMq+8wREjAfF9Kkg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thank you for your reply, Dmitry!
On Wed, Feb 26, 2014 at 6:58 AM, Dmitry V. Levin <ldv@altlinux.org> wrote:
> Hi,
>
> On Tue, Feb 25, 2014 at 10:27:37PM +0530, Zubin Mithra wrote:
> > Hey all,
> >
> > I'm Zubin and I love low level systems programming! :)
>
> Great! :)
>
> > A little about myself, I program primarily in C and Python, have systems
> > programming experience with Minix(filesystem development) and Linux and
> am
> > a hobbyist reverse engineer(I play CTF security exercises) -- and thats
> > when I use strace the most !
> >
> > I had a look at the ideas list here[1] and found the idea on improved
> path
> > decoding quite interesting and was hoping we could discuss it further on
> > the mailing list.
> >
> > I had a quick look at the implementation of the -y flag and noticed the
> > implementation of getfdpath(where the magic seemed to be happening). It
> > seemed to be trying to read the value of the symbolic link at
> > /proc/<pid>/fd/<fd>.
> >
> > Is my understanding of the following accurate?
>
> Yes, getfdpath() is the single point where strace fetches the path
> corresponding to the given descriptor.
>
> Besides that, printfd() is the single point where this fetched path is
> currently printed. The path fetched by getfdpath() is also used by
> fdmatch() to implement -P option.
>
> > Modifications need to be made such that upon using the "yy" flag:-
> > - Calls to functions that take a path as an argument are displayed with
> the
> > absolute path regardless of the argument that is passed in.
>
> I suppose path arguments should be printed the same way as they are
> printed now, and, in addition, if -yy mode is specified, canonicalized
> paths should be printed in <> form.
>
I see, cool stuff.
>
> > - When calls to functions that return a file descriptor are made, the
> > absolute path to the filename corresponding to the file descriptor needs
> to
> > be printed
>
> I think yes, probably by means of printfd().
>
> > - Same as above for functions that use path/descriptor combos.
>
> Right.
>
> In addition, there are at* functions: to canonicalize their path arguments,
> dirfd argument also has to be taken into account.
>
> > I believe that the first step would be to document and note down the
> system
> > calls that belong to one or more of the above categories and their system
> > call numbers, and if the -yy flag is used, check the tcp->scno against
> > these numbers and act accordingly.
> >
> > Is there something I'm missing? I'd love any kind of feedback!
>
> You probably don't need to care about tcp->scno to implement -yy mode.
>
I should probably go read the source instead -- is there any other way to
get information about an intercepted system call other than from the struct
tcb?
>
> First, since all descriptors (should be) printed using printfd(), you just
> use it to decode returned descriptors.
>
> Second, since all paths are printed using printpath() or printpathn(), it
> should be enough to extend this scheme for decoding path arguments of
> regular and at* functions in -yy mode.
>
> Third, -yy mode should extend -P functionality, this means that path
> arguments matching should work with canonicalized pathnames.
>
> Forth, I think -yy should also "canonicalize" socket descriptors, i.e.
> print their addresses in <> form, resembling lsof(8) output. This would
> be a really nice feature.
>
>
Great stuff, thank you very much !
Also, is there an IRC channel for strace dev?
Cheers,
zm
[Attachment #5 (text/html)]
<div dir="ltr">Thank you for your reply, Dmitry! <br><div \
class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 6:58 AM, \
Dmitry V. Levin <span dir="ltr"><<a href="mailto:ldv@altlinux.org" \
target="_blank">ldv@altlinux.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi,<br> <div><br>
On Tue, Feb 25, 2014 at 10:27:37PM +0530, Zubin Mithra wrote:<br>
> Hey all,<br>
><br>
> I'm Zubin and I love low level systems programming! :)<br>
<br>
</div>Great! :)<br>
<div><br>
> A little about myself, I program primarily in C and Python, have systems<br>
> programming experience with Minix(filesystem development) and Linux and am<br>
> a hobbyist reverse engineer(I play CTF security exercises) -- and thats<br>
> when I use strace the most !<br>
><br>
> I had a look at the ideas list here[1] and found the idea on improved path<br>
> decoding quite interesting and was hoping we could discuss it further on<br>
> the mailing list.<br>
><br>
> I had a quick look at the implementation of the -y flag and noticed the<br>
> implementation of getfdpath(where the magic seemed to be happening). It<br>
> seemed to be trying to read the value of the symbolic link at<br>
> /proc/<pid>/fd/<fd>.<br>
><br>
> Is my understanding of the following accurate?<br>
<br>
</div>Yes, getfdpath() is the single point where strace fetches the path<br>
corresponding to the given descriptor.<br>
<br>
Besides that, printfd() is the single point where this fetched path is<br>
currently printed. The path fetched by getfdpath() is also used by<br>
fdmatch() to implement -P option.<br>
<div><br>
> Modifications need to be made such that upon using the "yy" flag:-<br>
> - Calls to functions that take a path as an argument are displayed with the<br>
> absolute path regardless of the argument that is passed in.<br>
<br>
</div>I suppose path arguments should be printed the same way as they are<br>
printed now, and, in addition, if -yy mode is specified, canonicalized<br>
paths should be printed in <> form.<br></blockquote><div><br></div><div>I see, \
cool stuff.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><br>
> - When calls to functions that return a file descriptor are made, the<br>
> absolute path to the filename corresponding to the file descriptor needs to<br>
> be printed<br>
<br>
</div>I think yes, probably by means of printfd().<br>
<div><br>
> - Same as above for functions that use path/descriptor combos.<br>
<br>
</div>Right.<br>
<br>
In addition, there are at* functions: to canonicalize their path arguments,<br>
dirfd argument also has to be taken into account.<br>
<div><br>
> I believe that the first step would be to document and note down the system<br>
> calls that belong to one or more of the above categories and their system<br>
> call numbers, and if the -yy flag is used, check the tcp->scno against<br>
> these numbers and act accordingly.<br>
><br>
> Is there something I'm missing? I'd love any kind of feedback!<br>
<br>
</div>You probably don't need to care about tcp->scno to implement -yy \
mode.<br></blockquote><div><br></div><div>I should probably go read the source \
instead -- is there any other way to get information about an intercepted system call \
other than from the struct tcb?</div> <div> </div><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
First, since all descriptors (should be) printed using printfd(), you just<br>
use it to decode returned descriptors.<br>
<br>
Second, since all paths are printed using printpath() or printpathn(), it<br>
should be enough to extend this scheme for decoding path arguments of<br>
regular and at* functions in -yy mode.<br>
<br>
Third, -yy mode should extend -P functionality, this means that path<br>
arguments matching should work with canonicalized pathnames.<br>
<br>
Forth, I think -yy should also "canonicalize" socket descriptors, i.e.<br>
print their addresses in <> form, resembling lsof(8) output. This would<br>
be a really nice feature.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>Great \
stuff, thank you very much !</div><div><br></div><div><br></div><div>Also, is there \
an IRC channel for strace dev?</div><div><br></div> \
<div><br></div><div><br></div><div>Cheers,</div><div>zm</div></div></div></div>
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic