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]

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.

 

[Harald van Dijk]

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]

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_return_address intrinsic), on others you may
have to resort inline assembler.

 

[santosh]

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]

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.

 

[Walter Roberson]

jacob navia wrote:

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.

 

[santosh]

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.

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]

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]

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.

 

[Bartc]

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...

 

[Harold Aptroot]

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
_AddressOfReturnAddress() ) 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]

news:[email protected]...

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
_AddressOfReturnAddress() ) 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]

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

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

Regards,
Johannes

 

[MisterE]

Is it possible to access this value..??

No.

 

[Harold Aptroot]

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

And the OP still wouldn't know anything
Which is great, because most people in clc are just here to flame people who
ask questions that in their opinion don't belong there - without answering
them first.

Which compiler has the latter function (just curious)?

Some versions of MSVC

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

It's very bad
I've seen it work though, and that's all that really matters (most virusses
are platform specific anyway)

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.

Or just assume it'll be the most common implementation and let the OP
complain when that assumption turns out to be false?

An other solution that will not sit well with C-purists but should work:
inline assembly!

 

[Harold Aptroot]

No.

Of course it is
The OP did not request a standard compliant way to do it after all

 

[Keith Thompson]

Harold Aptroot wrote: [...]

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.

And the OP still wouldn't know anything

[...]

Nonsense. The OP has already gotten the best answer we can give him
with regard to the C language, that it provides no portable way to get
the return address. He's far more likely to get a *useful* answer
that will help him do what he wants to do by posting to a more
suitable forum.

As for the multiplicity of answers saying essentially the same thing,
that's a consequence of the fact that Usenet is asynchronous; several
people post answers before seeing the others. There's no easy
solution to this in an unmoderated newsgroup. (I note that
comp.lang.c.moderated has even more of a problem with multiple similar
answers than comp.lang.c does, because of long latency and the
moderator's choice not to reject duplicate answers.)

 

[CBFalconer]

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..??

In a machine that can execute the standard C language, there is no
need for a stack. This makes it hard to access a return address
(of unknown form) stored in a non-existant stack.

 

[CBFalconer]

Of course it is. The OP did not request a standard compliant
way to do it after all

On this newsgroup, there are no non-standard compliant ways to do
anything. Anything of that nature is off=topic, and may be found
on specialized news-groups dealing with the authors system.