[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20020919165114.A4435@hamsec.aurora.sfo.interquest.net>
From: silvio at big.net.au (silvio@....net.au)
Subject: ltrace, was Re: RE: Administrivia
On Thu, Sep 19, 2002 at 03:07:51PM -0700, winterslip@...hmail.com wrote:
>
> Like the rest of the people on this list I am still sub'd to bugtraq and
> it's still pounding out vulnerabilities (including symantec ones..) and
> all your doomsaying has come to naught. Outside of the playschool
> environment here being highly entertaining you've done nothing, status quo for you of course.
doomsaying?
I can't talk about doomsaying very well..
so perhaps something on topic.
---->
some interesting ltrace behaviour..
i've never seen anyone mention it before (i did talk about it a little at
cansecwest, heh), so i guess it wont hurt here.
ltrace works by basically looking at the dynamic symbol table and getting
the st_value from the dynamic symbols, and then setting a breakpoint
where that address is.
however, if we look at linux, then st_value is not used for dynamic
linking, and hence can be arbitrarily modified without changing
execution behaviour.
thus you can use this to
a) have ltrace produce no results
b) have ltrace produce incorrect results
c) have ltrace poke 0xC3 (x86) to where you want in memory, when being traced
how to do all this -->
a) set all st_value to 0
b) try swapping some symbols' st_value and have ltrace show u different calls
c) change st_value to whatever you want
solution -->
there are other ways to determine where a plt entry is, without looking
at a symbol st_value obviously.
> The no moderation call was very obviously a stellar judgment call. Hey,
> you have a server I can store some documents on by any chance????
i'll put them up on www.big.net.au if you want?
if anyone wants stuff up at www.big.net.au, i'll be open to suggestions
or linking, hosting content etc.
--
Silvio
Powered by blists - more mailing lists