Function pointer results in segmentation fault.

[Chris Van Extergem]

Hi all,

I'm just trying some examples from a book I'm reading and I just keep
getting these seg faults.

Below is the smallest possible program that still exhibits this
behaviour. The full program is written as a means to
'inject' assembly code into a running program and would, among other
things, malloc enough memory, read the 'code'
from a file ,then point the function pointer fptr to it and call it.

The hardcoded bytes in this example are the equivalent of the following
assemly lines:

xoreax,eax
moval,1
int0x80

which basically translates to exit() in C.


This is the program:

#include <stdio.h>

int main(int argc,char **argv)
{
void*code="\x66\x31\xc0\xb0\x01\xcd\x80";
void(*fptr)(void);

printf("Calling code...\n");
fptr=(void(*)(void))code;
(*fptr)();

return 0;
}

And this is the output:

Calling code...
Segmentation fault

I'm pretty sure the problem lies with the way fptr is declared/assigned a
value/called but I don't have any
experience with this particular use of function pointers so I would
appreciate your input.

Oh, and I don't know if this is relevant, I'm doing this on a RedHat 9 box.

 

[Thomas Lumley]

Hi all,

I'm just trying some examples from a book I'm reading and I just keep
getting these seg faults.

Below is the smallest possible program that still exhibits this
behaviour. The full program is written as a means to
'inject' assembly code into a running program and would, among other
things, malloc enough memory, read the 'code'
from a file ,then point the function pointer fptr to it and call it.

If you are using the same system and compiler as the book then you
should probably ask in a newsgroup relevant to that compiler.
Otherwise you shouldn't expect it to work.

This is the program:

#include <stdio.h>

int main(int argc,char **argv)
{
void*code="\x66\x31\xc0\xb0\x01\xcd\x80";
void(*fptr)(void);

printf("Calling code...\n");
fptr=(void(*)(void))code;
(*fptr)();

return 0;
}

It might be helpful for you to look at assembly code produced by your
compiler when you actually call a void function with no arguments. It
could be that the calling is more complicated that your book suggests.

Oh, and I don't know if this is relevant, I'm doing this on a RedHat 9 box.

If it is relevant then the question is off-topic in this group.

-thomas

 

[Herbert Rosenau]

Hi all,

I'm just trying some examples from a book I'm reading and I just keep
getting these seg faults.

Below is the smallest possible program that still exhibits this
behaviour. The full program is written as a means to
'inject' assembly code into a running program and would, among other
things, malloc enough memory, read the 'code'
from a file ,then point the function pointer fptr to it and call it.

The hardcoded bytes in this example are the equivalent of the following
assemly lines:

xoreax,eax
moval,1
int0x80

which basically translates to exit() in C.

Ask in a linux group. This has nothing to do with standard C.

Hint: The OS is catiching you to call code you not allow to execute.
To learn to write a virus you have to learn something more than to
copy illegal code from a book you've found somewhere.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Rod Pemberton]

Hi all,

I'm just trying some examples from a book I'm reading and I just keep
getting these seg faults.

xoreax,eax
moval,1
int0x80

This question comes up in a number of assembly language groups. I'm not
sure if the following is the correct answer. You said you're using Linux
and not FreeBSD, so your 'int 0x80' kernel interface may have been replaced
by a 'syscall' wrapper. The first suggests you can use 'call 0xFFFFF000'
instead of 'int 0x80'.

http://lkml.org/lkml/2002/12/17/5
http://lkml.org/lkml/2002/12/18/218


Rod Pemberton

 

[Keith Thompson]

Ask in a linux group. This has nothing to do with standard C.
Agreed.

Hint: The OS is catiching you to call code you not allow to execute.

Perhaps.

The original code declares a void* pointer to what is supposed to be
some machine code, then converts the void* to a pointer-to-function.
This assumes that such a conversion is meaningful *and* that an actual
function pointer simply points to the first byte of the function's
code. That may or may not be the case.

That's just one of a number of reasons why this might not work.

Someone suggested looking at the code generated by your compiler for a
function call. Instead, it would be more useful to look at the code
generated for an *indirect* call (a call through a function pointer
object.

To learn to write a virus you have to learn something more than to
copy illegal code from a book you've found somewhere.

I'm sure that writing a virus is one possible use for this technique.
I see no basis for assuming that that's what the OP is trying to do.

 

[Chris Van Extergem]

[problem with C program calling assembly]

It might be helpful for you to look at assembly code produced by your
compiler when you actually call a void function with no arguments. It
could be that the calling is more complicated that your book suggests.

I did that and as it turns out the problem is not in the C program,
apparently the string \x66\x31\xc0 translates to xor ax,ax instead of xor
eax,eax
How this happened is something I am trying to figure out right now but I
guess that's a question better asked in one of the assembly groups...

Anyway, thanks to you and all the others for your help.