Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Dynamic (as in Reflective) Programming in C?

Reply
Thread Tools

Dynamic (as in Reflective) Programming in C?

 
 
Edoules
Guest
Posts: n/a
 
      03-19-2008
Dear All,

I'm curious to know if there has been any efforts to allow for the
byte-order run-time editing of compiled C code.

This request is informational only, sparked by curiousity.

Hypothetical solutions I've discussed with my colleagues include
casting a function pointer to a void or unsigned char pointer
(illegal, but oddly allowed by most compilers), then buffering all the
bytes up to a known return value-- although how to write back onto the
protected page of code has yet to be solved by us, and is likely
something requiring an "unsafe"/"custom" kernel.

This is clearly a system specific problem, though an abstract overview
of how this was approached in the past would be nice.


Thanks,
Eddie Ma
B.Sc. University of Guelph
 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      03-19-2008
Edoules wrote:
> Dear All,
>
> I'm curious to know if there has been any efforts to allow for the
> byte-order run-time editing of compiled C code.
>
> This request is informational only, sparked by curiousity.
>
> Hypothetical solutions I've discussed with my colleagues include
> casting a function pointer to a void or unsigned char pointer
> (illegal, but oddly allowed by most compilers), then buffering all the
> bytes up to a known return value-- although how to write back onto the
> protected page of code has yet to be solved by us, and is likely
> something requiring an "unsafe"/"custom" kernel.
>
> This is clearly a system specific problem, though an abstract overview
> of how this was approached in the past would be nice.


Others' experiences may differ, but I myself haven't run
across a C program that modifies its own code in this way.
I've run across one that treated its code as read-only data,
checksumming it periodically to detect whether someone was
running it under a debugger and had inserted breakpoints to
try to defeat the licensing, but even that's fairly rare.

A much more common practice is to deposit some bytes in
an array, convert the array pointer to a function pointer, and
call via the pointer, thus running the array's bytes as code.
Even this usually requires system-specific help beyond just
knowing the instruction set and calling conventions and so on:
you may need to synchronize instruction and data caches, change
memory access permission bits, and the like. All of this is
well outside the realm of C -- C doesn't even guarantee that
you can convert between data and function pointers meaningfully.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      03-19-2008
Edoules wrote:
> Dear All,
>
> I'm curious to know if there has been any efforts to allow for the
> byte-order run-time editing of compiled C code.
>


I would understand the above sentence if the "byte order" term was
absent.

You want to change the "byte order" or you want to edit/run
the code?

> This request is informational only, sparked by curiousity.
>
> Hypothetical solutions I've discussed with my colleagues include
> casting a function pointer to a void or unsigned char pointer
> (illegal, but oddly allowed by most compilers), then buffering all the
> bytes up to a known return value-- although how to write back onto the
> protected page of code has yet to be solved by us, and is likely
> something requiring an "unsafe"/"custom" kernel.
>


I have written a module that takes an obj file and loads
it, links it with the running program, and then it runs it.

If interested answer by email to me.

> This is clearly a system specific problem, though an abstract overview
> of how this was approached in the past would be nice.
>
>
> Thanks,
> Eddie Ma
> B.Sc. University of Guelph



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Anonymous
Guest
Posts: n/a
 
      03-20-2008
On Wed, 19 Mar 2008 11:54:59 -0400, Eric Sosman wrote:

> C doesn't even
> guarantee that you can convert between data and function pointers
> meaningfully.


[Slightly OT]
And on modern systems, it will likely not work, since the sections of
memory where the data is stored are typically marked non-executable by
the OS for security reasons
 
Reply With Quote
 
santosh
Guest
Posts: n/a
 
      03-20-2008
Anonymous wrote:

> On Wed, 19 Mar 2008 11:54:59 -0400, Eric Sosman wrote:
>
>> C doesn't even
>> guarantee that you can convert between data and function pointers
>> meaningfully.

>
> [Slightly OT]
> And on modern systems, it will likely not work, since the sections of
> memory where the data is stored are typically marked non-executable by
> the OS for security reasons


What wouldn't work? I suspect that on many modern systems the pointer
conversion itself will succeed, but as you say, the code may not be
writable.

 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      03-20-2008
In article <CRlEj.30533$(E-Mail Removed)>,
Anonymous <(E-Mail Removed)> wrote:

>And on modern systems, it will likely not work, since the sections of
>memory where the data is stored are typically marked non-executable by
>the OS for security reasons


On such modern operating systems there is bound to be a way to change
that protection. By definition no general-purpose operating system
would make it impossible to generate code on the fly.

-- Richard
--
:wq
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      03-20-2008
(E-Mail Removed) (Richard Tobin) writes:

> In article <CRlEj.30533$(E-Mail Removed)>,
> Anonymous <(E-Mail Removed)> wrote:
>
>>And on modern systems, it will likely not work, since the sections of
>>memory where the data is stored are typically marked non-executable by
>>the OS for security reasons

>
> On such modern operating systems there is bound to be a way to change
> that protection. By definition no general-purpose operating system
> would make it impossible to generate code on the fly.
>
> -- Richard


Even something as base as exec'ing a system call which calls a newly
generated bash script which compiles and executes a new executable!
 
Reply With Quote
 
George Peter Staplin
Guest
Posts: n/a
 
      03-20-2008
Edoules wrote:
> Dear All,
>
> I'm curious to know if there has been any efforts to allow for the
> byte-order run-time editing of compiled C code.
>
> This request is informational only, sparked by curiousity.
>
> Hypothetical solutions I've discussed with my colleagues include
> casting a function pointer to a void or unsigned char pointer
> (illegal, but oddly allowed by most compilers), then buffering all the
> bytes up to a known return value-- although how to write back onto the
> protected page of code has yet to be solved by us, and is likely
> something requiring an "unsafe"/"custom" kernel.


I don't see why you need an "unsafe"/"custom" kernel. Some programmers
do things like this often. I have done this several times for a runtime
assembler, and a compiler.

It goes something like this (assuming you're using Windows or a
Unix-like system):

In Windows:

1. VirtualAlloc() the required number of executable pages you will
need for the function's instructions.
2. generate the CPU instructions for that executable memory.
3. flush any CPU caches if needed. This is very important with some
processors.
4. if say you have void *p which points to the start of the
VirtualAlloc memory you just convert it like:
void (*myfunc) (void); myfunc = p;
Note: IIRC ANSI-C doesn't allow casting a void * to a function type,
but POSIX and other standards do.
5. use myfunc() somewhere.

In Unix-like systems:
1. mmap with PROT_EXEC the required executable pages.
steps 2-5 are the same as with Windows.

If you really want to edit live code I would suggest allocating your own
pages like I suggested. However you can change the executable
permissions with mprotect() of the existing functions in most cases,
though I'm not sure if Windows has an equivalent.

Self-modifying code can be difficult to debug, especially if you're not
familiar with the assembly language of the processor.

This is something I wrote mostly in C that generates C functions from
machine code for the x86: http://wiki.tcl.tk/20273

Here is a more generic scripted assembler I wrote in Tcl and C that
produces C functions at runtime: http://wiki.tcl.tk/20286

> This is clearly a system specific problem, though an abstract overview
> of how this was approached in the past would be nice.


I hope this makes the system specifics more clear.


Have fun,

George
 
Reply With Quote
 
Edoules
Guest
Posts: n/a
 
      03-29-2008
Dear all,

Sorry for taking so long to reply, but all of your insights are very
interesting indeed.

I'm going to take a look at the posted code.

Thanks,
Eddie Ma.
 
Reply With Quote
 
Tomás Ó hÉilidhe
Guest
Posts: n/a
 
      03-29-2008
On Mar 19, 3:54*pm, Eric Sosman <(E-Mail Removed)> wrote:
> All of this is
> well outside the realm of C -- C doesn't even guarantee that
> you can convert between data and function pointers meaningfully.


extern void Func(void);
void (*pFunc)(void) = Func;

char unsigned buf[sizeof pFunc];
memcpy(buf,&pFunc,sizeof pFunc);

/* And then back again */

memcpy(&pFunc,buf,sizeof pFunc);

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C (functional programming) VS C++ (object oriented programming) Joe Mayo C Programming 168 10-22-2007 01:00 AM
Can Your Programming Language Do This? Joel on functional programming and briefly on anonymous functions! Casey Hawthorne Python 4 08-04-2006 05:23 AM
generic programming and dynamic polymorphism Leslaw Bieniasz C++ 4 10-21-2004 10:07 AM
systems programming versus application programming Matt Java 35 07-22-2004 08:10 AM
C++ and dynamic programming The Directive C++ 8 01-21-2004 07:35 AM



Advertisments