Hello forks,

Could anyone tell me if one run the code which is copied from .CODE to .TEXT area?
I tried to run a code shown below, and the code terminated without any error, superficially.

Is is dangerous? or, completely safe?

Thank you.

//---------------------------

static unsigned int fbody(void)
{
    // some code

    return 0x12345678;
}

int main(void)
{
    char buff[1024];
    char *psrc = (char *)fbody;
    memcpy(buff, psrc, sizeof_func);

    // modify some part of the buff adequately here
    // ...

    unsigned int (__cdecl *p_entry)(void) = (unsigned int (__cdecl *)(void))buff;

    unsigned int ret = p_entry();
    ASSERT( ret = 0x12345678 );

    return 0;
}
Posted on 2006-03-19 07:39:14 by uwata
Use this forum for your general Windows assembly programming related questions and answers


This is an assembly language forum, further posts that are simply general programming questions and written in a language that is not assemlby will be moved to the Heap or a more appropriate forum.

No, code in the data (or text) area will not run unless it is marked PAGE_EXECUTE, I believe that XPSP2 will not let it run even then because of PAE mode restrictions.
Posted on 2006-03-19 08:10:47 by donkey
if the page is marked as read/write/execute via virtualalloc etc.. it'll work fine on xp sp2, even works on xp64 sp1
Posted on 2006-03-19 09:11:35 by evlncrn8
Believe it or not, when I first moved over to MASM32, that was the first time I had ever heard of a .CODE section. I think you should consider the .CODE section as being synonymous to the .TEXT section. Usually it depends on what system you are coding under. On linux/bsd systems it's common practice to name your sections like so:

.TEXT - Code Section
.DATA - Initialize Data Section
.BSS - Uninitialized Data Section | Stack Section

Where as under windows it's common to use the terms.

.CODE - Code Section
.DATA - Initialized Data Section
.DATA? - Unitialized Data Section | Stack Section

Are they any diffent? Nope, system doesn't care what you name them as long as their attributes are the same. In fact, some assemblers will group sections that have the same permissions into a single larger section so things aren't scattered all over the place. So long as the PE Header on Windows has a pointer to the entry point within your section and the section is marked Readable and Executable, you could name it .SYNFIRE for all the system cares. .TEXT and .CODE are just common naming conventions.

Regards,
Bryant Keller
Posted on 2006-03-19 15:45:47 by Synfire
Bryant,

I will have to try that one to see if it further confuses many of the PE manipulation tools around. I wonder how they will respond the the .SYNFIRE section and what category they will try and put it in ?  :mrgreen:
Posted on 2006-03-19 19:07:04 by hutch--
Thank you everyone,

My final purpose is to see if one can veil a portion of code for self-code-modification. If there is a portion of code calling VirtualProtect or VirtualAlloc, these are clue to find out the portion of code for self-code-modification. And even INT2E would be a clue.

Is there any good idea?
Posted on 2006-03-19 23:12:26 by uwata

Ultimately, your code will always be insecure.
Building a mess of self-modifying code only serves to obscure the code, not secure it.. if someone wants to take the time to analyse the flow of execution, they will, and there's nothing you can do about that.
Posted on 2006-03-20 05:46:19 by Homer
To Homer,

Thank you for your comment.

I also think that any code could NOT be protected perfectly, in the strict sense.

But I think this is the matter of a valance between time cost and worth of the code.

If some method of self-code-modification is complex enough to prevent someone from analyzing, I think it is meaningfull.  :D
Posted on 2006-03-20 08:07:40 by uwata

No, code in the data (or text) area will not run unless it is marked PAGE_EXECUTE, I believe that XPSP2 will not let it run even then because of PAE mode restrictions.

Actually it's not until XP SP2 that PAGE_EXECUTE is enforced, which is why you used to be able to execute code from the stack, heap, et cetera until the "NX bit" was introduced (and emulated for CPUs that don't support it, which is basically any x86 older than Athlon64 and late model Pentium4).

The main two issues are that the your destination memory must be both writable and executable, and that you need to write to-be-copied code in a position-independant way. This basically means no access to global variables and external functions (including APIs), unless you do some by indirect ways. This is basically a bit hard to do with C code, but it can be done especially if your compiler supports something like GCC's "-fPIC" switch. Lots easier to do in assembly, though.

synfire, the common code section name for windows is .text as well - mostly borland tools iirc insist on .code... I think .code is the most logical name, but oh well :)


I will have to try that one to see if it further confuses many of the PE manipulation tools around. I wonder how they will respond the the .SYNFIRE section and what category they will try and put it in ?

Only really poor tools would be confused by this - anything of interest can be reached through the PE directory table. One notable exception is ".rsrc" which, for some reason, a lot of applications have hardcoded instead of checking the directory table. There's rumor that even some old windows components depended on this, but I'm not sure if that's true or not.

Uwata, any self-modification done "by hand" will buy you absolutely nothing. You'll need automated tools generating a couple thousands of unrelated checks etc. before it buys you ANY form of security. Unless you have/write tools like that, "writing code on the fly" is mostly useful for JIT'ing scripted languages and similar.
Posted on 2006-03-21 08:14:55 by f0dder