Hello!

I would like to ask you if it is possible to detect (somehow) how many
parameters called function is accepting? I know that this is probably
silly (please read: hard) question because solution seems to me to be
connected with stack management on destination machine (do I need to
analyze stack management code in investigated function?).

Problem: I have plenty of "core", "undocumented", compiled C functions
that are defined in one shared library. An application (sourcecode
unavailable too) is working and using these functions (defined in
mentioned shared library). Fortunately all functions have common
structure. They always take one or more parameters (number of
parameters is always stricly defined - there is no function which was
defined as taking unknown number of parameters (...)). All parameters
are _always_ pointers to some structures (first one is _always_ (char
*)).
So, having this knowledge, can I determine (guess) somehow the number
of parameters the function is accepting? How decompilers are
"guessing" function definitions? Do you know any good decompiler for
AIX 5.1 (powerpc)?

I need to: override ("shadow" is better verb?) all "core" functions to
log invocation sequence and input/output parameters of called
functions.

Please include my email when replying. Thanks in advance.

Regards
Pawel

PS. My machine is RS/6000 (64bit powerpc) and OS is AIX 5.1.
PS2. Of course I will try to "google" more  Any hints highly
welcome.

[ Post a follow-up to this message ]

Pawel Piaskowy <pprivately@wp.pl> wrote:
> I would like to ask you if it is possible to detect (somehow) how many
> parameters called function is accepting? I know that this is probably
> silly (please read: hard) question because solution seems to me to be
> connected with stack management on destination machine (do I need to
> analyze stack management code in investigated function?).

Probably yes. There's no requirement in the C standard how arguments
get passed to a function - not even if they get passed via the stack
or in which sequence. Often some of the arguments are passed via some
registers of the CPU and when there are too many the rest gets send
via the stack. But each compiler can do this differently...

> Problem: I have plenty of "core", "undocumented", compiled C functions
> that are defined in one shared library. An application (sourcecode
> unavailable too) is working and using these functions (defined in
> mentioned shared library). Fortunately all functions have common
> structure. They always take one or more parameters (number of
> parameters is always stricly defined - there is no function which was
> defined as taking unknown number of parameters (...)). All parameters
> are _always_ pointers to some structures (first one is _always_ (char
> *)).
> So, having this knowledge, can I determine (guess) somehow the number
> of parameters the function is accepting?

Probably the simplest way is to have a look at the assembler code of
the functions in your debugger. If I had to I probably would start
with writing a few functions with a similar signature as the functions
you are interested in and try to figure out how these arguments are
passed to the functions by checking the assembler code of these
function. That way you should get quite a good idea how it's done.
Unless the compiler is doing some hyper-clever optimization the
created assembler code will show lots of similarities at the start
of the functions. From this you then can guess the number of para-
meters of the unknown functions, maybe even without really under-
standing what that assembler code is doing if you're lucky. The
regularity of the type of arguments you have to expect should help
a lot.
Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

Jens.Toerring@physik.fu-berlin.de wrote:
> Pawel Piaskowy <pprivately@wp.pl> wrote:
> 
>
>
> Probably yes. There's no requirement in the C standard how arguments
> get passed to a function - not even if they get passed via the stack
> or in which sequence. Often some of the arguments are passed via some
> registers of the CPU and when there are too many the rest gets send
> via the stack. But each compiler can do this differently...
>
> 
>
>
> Probably the simplest way is to have a look at the assembler code of
> the functions in your debugger. If I had to I probably would start
> with writing a few functions with a similar signature as the functions
> you are interested in and try to figure out how these arguments are
> passed to the functions by checking the assembler code of these
> function. That way you should get quite a good idea how it's done.
> Unless the compiler is doing some hyper-clever optimization the
> created assembler code will show lots of similarities at the start
> of the functions. From this you then can guess the number of para-
> meters of the unknown functions, maybe even without really under-
> standing what that assembler code is doing if you're lucky. The
> regularity of the type of arguments you have to expect should help
> a lot.

It would also be good to look at the instructions just
before the call to each function of interest.  There are no
guarantees, of course, but you'll often find that the call
is immediately preceded by a "marshalling" of the arguments.
The called function's "unmarshalling" may be scrambled in
idiosyncratic ways having to do with the function's logic.

--
Eric.Sosman@sun.com

[ Post a follow-up to this message ]

Pawel Piaskowy wrote:
> Hello!
>
> I would like to ask you if it is possible to detect (somehow) how many
> parameters called function is accepting? I know that this is probably
> silly (please read: hard) question because solution seems to me to be
> connected with stack management on destination machine (do I need to
> analyze stack management code in investigated function?).
>
> Problem: I have plenty of "core", "undocumented", compiled C functions
> that are defined in one shared library. An application (sourcecode
> unavailable too) is working and using these functions (defined in
> mentioned shared library). Fortunately all functions have common
> structure. They always take one or more parameters (number of
> parameters is always stricly defined - there is no function which was
> defined as taking unknown number of parameters (...)). All parameters
> are _always_ pointers to some structures (first one is _always_ (char
> *)).
> So, having this knowledge, can I determine (guess) somehow the number
> of parameters the function is accepting? How decompilers are
> "guessing" function definitions? Do you know any good decompiler for
> AIX 5.1 (powerpc)?
>
> I need to: override ("shadow" is better verb?) all "core" functions to
> log invocation sequence and input/output parameters of called
> functions.
>
> Please include my email when replying. Thanks in advance.
>
> Regards
> Pawel
>
> PS. My machine is RS/6000 (64bit powerpc) and OS is AIX 5.1.
> PS2. Of course I will try to "google" more  Any hints highly
> welcome.


Please use __builtin_apply_args(), __builtin_apply(), __builtin_return()
functions of your GCC compiler. This way, you don't even have to guess
the number of arguments in order to forward them into other function,
doing logging in passing.

This may not be portable accross compiler, but at least afair it is
portable across platform if you are using GCC.

--
Lev Walkin
vlm@lionet.info

[ Post a follow-up to this message ]

Lev Walkin <vlm@lionet.info> wrote:
> Pawel Piaskowy wrote: 

[vbcol=seagreen]
> Please use __builtin_apply_args(), __builtin_apply(), __builtin_return()
> functions of your GCC compiler. This way, you don't even have to guess
> the number of arguments in order to forward them into other function,
> doing logging in passing.

> This may not be portable accross compiler, but at least afair it is
> portable across platform if you are using GCC.

I have been looking at the description of these functions but I wasn't
able yet to figure out how to use them for Pawels purposes. As far
as I understand he's planing to try to insert some code that "catches"
calls from the (binary only) application, print out the which function
has been called plus all the arguments and then call the original
function in the (binary only) library.

I guess that the first hurdle is going to get in between the application
and the library. Without actually trying it I would guess that he has to
write his own library, containing stubs for all the functions (hopefully
there aren't any other symbols in the library that also are required) and
try to get the original application to accept this new library instead
of the original one. From within this library he then dlopens() the old
library and uses the function defined there whenever the stub functions
get called. For that he needs to know the number of arguments (plus their
types, but, luckily, that doesn't seem to be a problem here.)

Can you tell how the GCC functions (assuming that Pawel can use GCC) you
mentioned help him to find out how _many_ arguments there are and how to
get at them?
Regards, Jens
--
\   Jens Thoms Toerring  ___  Jens.Toerring@physik.fu-berlin.de
\__________________________  http://www.toerring.de

[ Post a follow-up to this message ]

Jens.Toerring@physik.fu-berlin.de wrote:
> Lev Walkin <vlm@lionet.info> wrote:
> 
>
>
> 
>
> 
>
>
> I have been looking at the description of these functions but I wasn't
> able yet to figure out how to use them for Pawels purposes. As far
> as I understand he's planing to try to insert some code that "catches"
> calls from the (binary only) application, print out the which function
> has been called plus all the arguments and then call the original
> function in the (binary only) library.
>
> I guess that the first hurdle is going to get in between the application
> and the library. Without actually trying it I would guess that he has to
> write his own library, containing stubs for all the functions (hopefully
> there aren't any other symbols in the library that also are required) and
> try to get the original application to accept this new library instead
> of the original one. From within this library he then dlopens() the old
> library and uses the function defined there whenever the stub functions
> get called. For that he needs to know the number of arguments (plus their
> types, but, luckily, that doesn't seem to be a problem here.)
>
> Can you tell how the GCC functions (assuming that Pawel can use GCC) you
> mentioned help him to find out how _many_ arguments there are and how to
> get at them?

You don't need to know the number of arguments in order to print it
for debugging purposes. Suppose, the function is being called with
3 or 4 arguments. If you print 4 values down the stack, it might still
be okay, 'cause for human eye the fourth argument's value will likely be
easily distinguishable.

Yes, it does not give you precise answer, but this is probably the closest
thing to the high level C programming. Other methods require
a fair platform knowledge and are much less portable.

--
Lev Walkin
vlm@lionet.info

[ Post a follow-up to this message ]

In article <2kbidpFfpdqU1@uni-berlin.de>, Lev Walkin <vlm@lionet.info>
wrote:

> You don't need to know the number of arguments in order to print it
> for debugging purposes. Suppose, the function is being called with
> 3 or 4 arguments. If you print 4 values down the stack, it might still
> be okay, 'cause for human eye the fourth argument's value will likely be
> easily distinguishable.
>
> Yes, it does not give you precise answer, but this is probably the closest
> thing to the high level C programming. Other methods require
> a fair platform knowledge and are much less portable.

In fact, this is what many Unix debuggers do when they're asked to work
on a program that doesn't have a symbol table available.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]

Barry Margolin <barmar@alum.mit.edu> wrote: 
[vbcol=seagreen]
> In fact, this is what many Unix debuggers do when they're asked to work
> on a program that doesn't have a symbol table available.

I am curious to understand better - could you please explain a bit more on t
he above procedure?

Thanks,
Ognen
--
Digital Biology Laboratory
University of Missouri-Columbia
--

[ Post a follow-up to this message ]

Welcome again!

First I would like to thank you for all answers.

It is good to know about __ functions (I have never heard about them
before). I am not sure if I can use them, but I will try  It is
because, I think (almost sure) this application and shared library
were compiled by xlc (AIX C compiler). I am using gcc (3.3.2), so it
is no problem to try (I am curious of results).

Unfortunately I do not know powerpc assembler at all - so
investigating assembler code may be hard for me (I know x86 assembler
well so maybe it will not be so painfull, but... see below ).

Lev described my intentions perfectly (new library, new function
definition, dlopen()ing old lib, logging parameters, calling orginal
function). Currently I did new library and defined in it one stub
function (because I knew the number of its arguments before). And this
works! (what makes me really, really happy ) The only thing that
scares me is the number of functions to override - exactly 7156.

Regards
Pawel

[ Post a follow-up to this message ]

Hello again 

Specyfing: original library and application were compiled by "C for
AIX Compiler Version 5.0.1.0" (xlc 5.0.1.0?).

Regards
Pawel

[ Post a follow-up to this message ]