Read/copy/call a functions machine code?

[Bartc]

What I am trying to do is embed encrypted machine code into the source
file, then during run-time the program decrypts its own functions and runs
them. Currently its all done in assembly but I would like to move to C as
much as possible. Its seems I can indeed simply cast as unsigned char and
read the source code, so the answer is yes. I will try copying that data
to memory and trying to execute later.

If you're encrypting then you've got a headstart using ARM..

If that uses fixed size instructions then some of the comments here don't
apply and you should be able to step through instructions more easily.

Most likely you have a C compiler that can link to assembly routines so I
don't foresee many problems, and it looks like you know what you are doing.

 

[CBFalconer]

I take it you've never actually tried this?

Here we go

int compstr(const void *e1, const void *e2) {
const char * const *str1 = e1;
const char * const *str2 = e2;

return (int) strcmp(*str1, *str2);
}

int main(void) {
int i;
unsigned char *fptr;

fptr = (unsigned char *) compstr;
for(i=0;i<10;i++)
printf("%d, ", fptr);
printf("\n");
return 0;
}

I get the output 139, 68, 36, 8, 139, 76, 36, 4, 139, 16

It seems to me that it's reading the machine code of the
function OK. What I haven't done is tried to disassemble.

How does it do run on a C interpreter?

 

[Jack Klein]

Currently I do it all in assembly (this is on an ARM processor), but I was
just wondering what could be done with C. I can assemble the functions so
that operate independant of their position and only use pop/pushes off the
stack, and they run from any location we put them. I was just trying to
write a C interface to this instead of assembly.

This is seriously off-topic here, and you really need to ask in either
or both of or
There you can learn about features in the tool sets for most embedded
microcontrollers and DSPs, including ARM, that provide features for
building code to be moved from flash to RAM for execution.

But it is way beyond the scope of standard C, where there are only two
things you can do with a function, call it or take its address. And
the only thing you can do with its address, after taking it, is use it
to call the function.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

 

[Flash Gordon]

Jack Klein wrote, On 19/02/08 03:35:

But it is way beyond the scope of standard C, where there are only two
things you can do with a function, call it or take its address. And
the only thing you can do with its address, after taking it, is use it
to call the function.

You can also store it for later use ;-)

 

[Bart van Ingen Schenau]

What I am trying to do is embed encrypted machine code into the source file,
then during run-time the program decrypts its own functions and runs them.
Currently its all done in assembly but I would like to move to C as much as
possible. Its seems I can indeed simply cast as unsigned char and read the
source code, so the answer is yes. I will try copying that data to memory
and trying to execute later.

As far as the compiler is concerned, the encrypted instructions would
just be a bunch of bytes, just like some other binary data set.
The decryption routine would just work on these bytes without knowing
that the clear-text actually represents executable instructions.
The only non-portable thing that remains is the actual call to the
decrypted 'function'.

In pseudo-code this would look like:

unsigned char encrypted_foo[] = {
/* Encrypted code goed here */
};
unsigned int foo_size = 42;

void foo()
{
unsigned char* cleartext = malloc(foo_size);
decrypt(cleartext, encrypted_foo, sizeof(encrypted_foo));
void (*decrypted_foo)(void) = (void (*)(void))cleartext;
decrypted_foo();
free(cleartext);
}

For generating the encrypted function, you would use a separate
program that reads the code from a file (for example an object file)
and encrypts the part that you want.

Bart v Ingen Schenau

 

[Kenneth Brody]

If you cast the function pointer to an unsigned char *, then most
compilers will allow you to read the instructions until you hit upon a
return instruction, which will be the end of the function.
I take it you've never actually tried this?

[...]

I get the output 139, 68, 36, 8, 139, 76, 36, 4, 139, 16

It seems to me that it's reading the machine code of the function OK. What I
haven't done is tried to disassemble.

Well, it's reading *something*.

I think the objection was to the idea that you can tell the end of the
function by looking for a return instruction. There may be multiple
return instructions; the code might not end with one (it might end
with a backwards jump); and there may be embedded data that looks like
a return instruction.

It's even possible (though unlikely) that the code for one function is
mixed up with the code for another.[/QUOTE]

It's also possible that converting a function pointer to a char *
will cause the result to point elsewhere. (Consider segmented
memory architecture, where the data segment is not the same as the
code segment.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>