stack

[jt]

hello everyone..

int fun()
{
/* anything */
}
int main(void)
{
fun();
}

in this program, when the control is transferred to function fun()..
the return address is pushed to the stack..
Is it possible to access this value..??

[jacob navia]

Re: stack

jt wrote:

hello everyone..
>
int fun()
{
/* anything */
}
int main(void)
{
fun();
}
>
in this program, when the control is transferred to function fun()..
the return address is pushed to the stack..
Is it possible to access this value..??

Of course it is. Most viruses do.
But we will not tell you how.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: stack

On Sun, 03 Aug 2008 09:32:16 -0700, jt wrote:

hello everyone..
>
int fun()
{
/* anything */
}
int main(void)
{
fun();
}
>
in this program, when the control is transferred to function fun().. the
return address is pushed to the stack..

(I'll pretend you just wrote "the return address is saved" instead.)

Not on my system, and if it is on yours, consider getting a better
compiler. It's possible for the compiler to either see that fun has no
side effects and eliminate the call, or to inline fun. The former probably
won't happen if you make fun actually do something, but the latter quite
possibly will. If it is, there is no return address, so there is no
location holding the return address.

Is it possible to access this value..??

If the value exists at all, there is no standard way to access it. Some
implementations have options for this; check the documentation. But even
if you find it, what could you sensibly do with it?

[santosh]

Re: stack

jt wrote:

hello everyone..
>
int fun()
{
/* anything */
}
int main(void)
{
fun();
}
>
in this program, when the control is transferred to function fun()..
the return address is pushed to the stack..

This needn't be so. The compiler could inline fun, eliminate it
altogether, store the "return address" on a different stack etc. IOW,
this is a detail of your implementation and it can vary in seemingly
unpredictable ways.

Is it possible to access this value..??

Not from portable C code. You'll need to know in fair detail the calling
conventions for your implementation, and make sure that optimisations
like inlining are not in effect for this function. Practically
speaking, you'll have to learn the internals of your implementation and
the assembly language that is used on your system.

Some implementations provide convenient extensions for this purpose
(example, gcc's __builtin_retur n_address intrinsic), on others you may
have to resort inline assembler.

[santosh]

Re: stack

jacob navia wrote:

jt wrote:

>hello everyone..
>>
>int fun()
>{
>/* anything */
>}
>int main(void)
>{
> fun();
>}
>>
>in this program, when the control is transferred to function fun()..
>the return address is pushed to the stack..
>Is it possible to access this value..??

>
Of course it is. Most viruses do.
But we will not tell you how.

A truly determined and talented virus writer isn't going to be put off
by your answer. In fact, such persons probably won't post in this
group, in the first place. It's probable that curiosity is what's
motivating the OP to ask this question.

[Keith Thompson]

Re: stack

jt <karthiks.840@g mail.comwrites:

int fun()
{
/* anything */
}
int main(void)
{
fun();
}
>
in this program, when the control is transferred to function fun()..
the return address is pushed to the stack..

Maybe, maybe not. The language says only that after the function
finishes, execution continues after the call. It says nothing about
how this is accomplished. The C standard doesn't even mention a
"stack", and yes, there really are C implementations that don't use a
contiguously allocated hardware stack.

Is it possible to access this value..??

It's not possible to access this value portably given the code you've
presented.

If you like, you can maintain your own stack of function addresses.
For example, on entry to each function, you can push the address of
the current function onto a stack (a data structure you can implement
in any of a variety of ways) of function pointers. But this only
gives you the address of each *function*; it doesn't tell you where
within a function a call occurred.

Assuming the call to fun() isn't inlined, there's probably some
information somewhere in memory that's a close approximation of what
you're looking for. As I said, there's no portable way to get at that
information. A debugger (such as gdb) does maintain such information
and lets you display it as the program runs under its control, but it
uses an intimate knowledge of the particular system to do so.

If you have some real reason to access that kind of information
yourself, you'll have to ask in a forum that discusses the particular
system you're using -- and any information you get is likely to be
inapplicable to other systems.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Walter Roberson]

Re: stack

In article <g74rjg$o0p$2@r egistered.motza rella.org>,
santosh <santosh.k83@gm ail.comwrote:

>jacob navia wrote:

>jt wrote:

>>in this program, when the control is transferred to function fun()..
>>the return address is pushed to the stack..
>>Is it possible to access this value..??

>Of course it is. Most viruses do.
>But we will not tell you how.

>A truly determined and talented virus writer isn't going to be put off
>by your answer. In fact, such persons probably won't post in this
>group, in the first place. It's probable that curiosity is what's
>motivating the OP to ask this question.

Why do you lock your car? A truly determined and talented car thief
isn't going to be put off by the car door locks, and probably
wouldn't post about car door locks in public the first place.
It's probable that curiosity is what is motivating anyone asking
about car door locks -- so why not just leave your doors unlocked
or tell everyone where you hide the spare key?

I don't know about where you live, but where I live, there is a
serious problem with what are referred to as "joy riders" --
children 12 to 17 who wander around and when they see an
unprotected car, steal it and race around in it, abandoning
it somewhere else, usually after having banged up the car a bit
either through carelessness or as part of the "fun". This isn't just a
problem of a little bit of vandalism and "redistribution " of property:
there have been a number of high-speed police chases, and there have
been people killed by the crashes (these theives often don't
respect red lights.)

Is there a problem with professional car theives in this city? Yes.
But the professionals usually drive carefully, because they don't
want to attract attention to themselves. There is a bigger problem
with the unprofessional joy riders. How do the joy-riders decide
what to steal? Answer: what-ever is most convenient. Left
your car running for 3 minutes while you dashed into a convenience
store to get a package of cigarettes? Good-bye car... Secured
your steering wheel with a locking device ("a club") while your
neighbour didn't bother? Good-bye your -neighbour's- car, yours
wasn't worth the bother to a joy rider.

Moral: If someone is determined to write a virus or similar,
at least make them *work* for it. Don't make it easy for people
to go joy-hacking: there are a lot of people who can't be bothered
to get serious about such things, but will do it if it is easy.
--
"The quirks and arbitrariness we observe force us to the
conclusion that ours is not the only universe." -- Walter Kistler

[santosh]

Re: stack

Walter Roberson wrote:

In article <g74rjg$o0p$2@r egistered.motza rella.org>,
santosh <santosh.k83@gm ail.comwrote:

>>jacob navia wrote:

>

>>jt wrote:

>

>>>in this program, when the control is transferred to function
>>>fun().. the return address is pushed to the stack..
>>>Is it possible to access this value..??

>

>>Of course it is. Most viruses do.
>>But we will not tell you how.

>

>>A truly determined and talented virus writer isn't going to be put off
>>by your answer. In fact, such persons probably won't post in this
>>group, in the first place. It's probable that curiosity is what's
>>motivating the OP to ask this question.

>
Why do you lock your car? A truly determined and talented car thief
isn't going to be put off by the car door locks, and probably
wouldn't post about car door locks in public the first place.
It's probable that curiosity is what is motivating anyone asking
about car door locks -- so why not just leave your doors unlocked
or tell everyone where you hide the spare key?

I hope you can see the difference between securing property and refusing
to answer a rather commonly asked question based on unwarranted
assumptions. Even if the OP were not given a single useful answer here,
it's still *trivially* easy to find out the details for his system.
Such information is available all over the Net. Besides getting at the
return address is only the first step to writing really good viruses -
they aren't as easy anymore as they once were. OTOH a locked car is
very difficult to steal, thus the precaution makes a great deal of
sense.

<snip>

Moral: If someone is determined to write a virus or similar,
at least make them *work* for it. Don't make it easy for people
to go joy-hacking: there are a lot of people who can't be bothered
to get serious about such things, but will do it if it is easy.

I think we differ as to whether the OP's question has a hidden agenda to
it or not. I took it at face value, as I myself have once considered
such matters out of sheer curiosity.

[John Floren]

Re: stack

On 2008-08-03, Walter Roberson <roberson@ibd.n rc-cnrc.gc.cawrote :

In article <g74rjg$o0p$2@r egistered.motza rella.org>,
santosh <santosh.k83@gm ail.comwrote:

>>jacob navia wrote:

>

>>jt wrote:

>

>>>in this program, when the control is transferred to function fun()..
>>>the return address is pushed to the stack..
>>>Is it possible to access this value..??

>

>>Of course it is. Most viruses do.
>>But we will not tell you how.

>

>>A truly determined and talented virus writer isn't going to be put off
>>by your answer. In fact, such persons probably won't post in this
>>group, in the first place. It's probable that curiosity is what's
>>motivating the OP to ask this question.

>
Why do you lock your car? A truly determined and talented car thief
isn't going to be put off by the car door locks, and probably
wouldn't post about car door locks in public the first place.
It's probable that curiosity is what is motivating anyone asking
about car door locks -- so why not just leave your doors unlocked
or tell everyone where you hide the spare key?
>
I don't know about where you live, but where I live, there is a
serious problem with what are referred to as "joy riders" --
children 12 to 17 who wander around and when they see an
unprotected car, steal it and race around in it, abandoning
it somewhere else, usually after having banged up the car a bit
either through carelessness or as part of the "fun". This isn't just a
problem of a little bit of vandalism and "redistribution " of property:
there have been a number of high-speed police chases, and there have
been people killed by the crashes (these theives often don't
respect red lights.)
>
Is there a problem with professional car theives in this city? Yes.
But the professionals usually drive carefully, because they don't
want to attract attention to themselves. There is a bigger problem
with the unprofessional joy riders. How do the joy-riders decide
what to steal? Answer: what-ever is most convenient. Left
your car running for 3 minutes while you dashed into a convenience
store to get a package of cigarettes? Good-bye car... Secured
your steering wheel with a locking device ("a club") while your
neighbour didn't bother? Good-bye your -neighbour's- car, yours
wasn't worth the bother to a joy rider.
>
Moral: If someone is determined to write a virus or similar,
at least make them *work* for it. Don't make it easy for people
to go joy-hacking: there are a lot of people who can't be bothered
to get serious about such things, but will do it if it is easy.

My last job (hacking Plan 9 kernel stuff) involved essentially this
same problem. I ended up diddling the stack in assembly to save time,
but I spent quite a while researching what happens to the stack
when you call functions; the original plan was to mess with the
stack from within a C function, making the entire thing portable.
(We were writing a kernel tracing/profiling device that did some
stuff whenever a function was called or exited).

It's not all about viruses.

John

[Chris Torek]

Re: stack

In article <3865df3f-4d18-4e8e-ad74-7c2884491890@v1 g2000pra.google groups.com>
jt <karthiks.840@g mail.comwrote:

>hello everyone..
>
>int fun()
>{
>/* anything */
>}
>int main(void)
>{
fun();
>}
>
>in this program, when the control is transferred to function fun()..
>the return address is pushed to the stack..

Actually, it is put in the register "lr" (PPC), "ra" (MIPS), "%o7"
(SPARC), or 14 (IBM S/390; spelled %r14 in GNU assembler). As
others have noted, if fun() is expanded in line, there is no control
transfer at all. But on the VAX and PDP-11, it is indeed placed
on the (hardware) stack.

>Is it possible to access this value..??

Clearly, if it is accessible at all, the method will vary, since
it is in different places on each of these architectures.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html

[Bartc]

Re: stack

"Chris Torek" <nospam@torek.n etwrote in message
news:g75g800g5p @news3.newsguy. com...

In article
<3865df3f-4d18-4e8e-ad74-7c2884491890@v1 g2000pra.google groups.com>
jt <karthiks.840@g mail.comwrote:

>>hello everyone..
>>
>>int fun()
>>{
>>/* anything */
>>}
>>int main(void)
>>{
> fun();
>>}
>>
>>in this program, when the control is transferred to function fun()..
>>the return address is pushed to the stack..

>
Actually, it is put in the register "lr" (PPC), "ra" (MIPS), "%o7"
(SPARC), or 14 (IBM S/390; spelled %r14 in GNU assembler). As
others have noted, if fun() is expanded in line, there is no control
transfer at all. But on the VAX and PDP-11, it is indeed placed
on the (hardware) stack.

You left out x86-32. A little-used processor, I know...

--
Bartc

[Harold Aptroot]

Re: stack

"jt" <karthiks.840@g mail.comwrote in message
news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1 g2000pra.google groups.com...

hello everyone..
>
int fun()
{
/* anything */
}
int main(void)
{
fun();
}
>
in this program, when the control is transferred to function fun()..
the return address is pushed to the stack..
Is it possible to access this value..??

We've had a lot of "not in standard C" responses now.. what use are they?

Your compiler may have the intrinsic function _ReturnAddress( ) (and/or
_AddressOfRetur nAddress() ) available
You can also try to access 'the address of the last argument + its size' as
though it was a pointer-sized thing but that's less stable and very
implementation dependand

[santosh]

Re: stack

Harold Aptroot wrote:

"jt" <karthiks.840@g mail.comwrote in message
>

news:3865df3f-4d18-4e8e-ad74-7c2884491890@v1 g2000pra.google groups.com...

>hello everyone..
>>
>int fun()
>{
>/* anything */
>}
>int main(void)
>{
> fun();
>}
>>
>in this program, when the control is transferred to function fun()..
>the return address is pushed to the stack..
>Is it possible to access this value..??

>
We've had a lot of "not in standard C" responses now.. what use are
they?

If they manage to redirect the OP to a more suitable forum, then IMO,
they served their purpose.

Your compiler may have the intrinsic function _ReturnAddress( ) (and/or
_AddressOfRetur nAddress() ) available

Which compiler has the latter function (just curious)?

You can also try to access 'the address of the last argument + its
size' as though it was a pointer-sized thing but that's less stable
and very implementation dependand

This is probably the worst method (if once could call it that) that I've
seen so far.

The return address is a feature of the *implementation * , which in the
vast majority of cases uses features of the underlying processor to
accomplish this. Thus for a robust solution to the OP's problem, one
needs to determine the details of the implementation and the underlying
hardware.

[Johannes Bauer]

Re: stack

jacob navia schrieb:

Of course it is. Most viruses do.
But we will not tell you how.

No. Most viruses don't. Many worms do.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47fa8447$0$115 45$9b622d9e@new s.freenet.de>

[MisterE]

Re: stack

Is it possible to access this value..??

No.