pinheads : Message: RE: [pinheads] self-modifying code

Note that the requirement that you execute a taken branch (or serializing instruction) before you execute newly modified code is not just a Pin restriction, it’s also an IA architectural restriction. So the code as written could fail even without Pin present.

See Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide available from here http://www.intel.com/products/processor/manuals/ :

7.1.3 Handling Self- and Cross-Modifying Code

The act of a processor writing data into a currently executing code segment with the intent of executing that data as code is called self-modifying code. IA-32 processors exhibit model-specific behavior when executing self-modified code, depending upon how far ahead of the current execution pointer the code has been modified.

As processor microarchitectures become more complex and start to speculatively execute code ahead of the retirement point (as in P6 and more recent processor families), the rules regarding which code should execute, pre- or post-modification, become blurred. To write self-modifying code and ensure that it is compliant with current and future versions of the IA-32 architectures, use one of the following coding options:

(* OPTION 1 *)

Store modified code (as data) into code segment;

Jump to new code or an intermediate location;

Execute new code;

(* OPTION 2 *)

Store modified code (as data) into code segment;

Execute a serializing instruction; (* For example, CPUID instruction *)

Execute new code;

The use of one of these options is not required for programs intended to run on the Pentium or Intel486 processors, but are recommended to insure compatibility with the P6 and more recent processor families.

-- Jim

James Cownie <james.h.cownie@...>
SSG/DPD/PAT
Tel: +44 117 9071438

From: pinheads@yahoogroups.com [mailto:pinheads@yahoogroups.com] On Behalf Of Cohn, Robert S
Sent: 19 January 2009 23:12
To: pinheads@yahoogroups.com
Subject: RE: [pinheads] self-modifying code

To reduce the cost for handling smc, pin assumes that there will be a taken branch between the code modification and execution of modified code. Your example violates the assumption. Please try:

pin –smc_strict -- ./escape2

This should work, but may run slower.

From: pinheads@yahoogroups.com [mailto:pinheads@yahoogroups.com] On Behalf Of reynaudd@ymail.com
Sent: Monday, January 19, 2009 3:50 PM
To: pinheads@yahoogroups.com
Subject: [pinheads] self-modifying code

Hello,

I've been testing the behavior of PIN against self-checking and
self-modifying code. Dynamically generated code is handled well but I
found at least a case of self-modifying code that doesn't cause a
cache invalidation:

#include <stdio.h>

void foo() {
int var = -1;

asm ("call bar\n\t"
"bar: pop %%rax\n\t"
"movl $0xcafebabe, 10(%%eax)\n\t" // overwrite 0xffffffff in the
next mov with 0xcafebabe
"movl $0xffffffff,%%eax\n\t"
: "=rax"(var));
printf("0x%x\n", var);
}

int main() {
foo();
}

Compile and make the .text section and the program headers writable,
and I got the following behaviors:

reynaudd@lhs-2:~/test/packed$ ./smhello
0xcafebabe

reynaudd@lhs-2:~/test/packed$ pin -t
./pin-2.5-24110-gcc.4.0.0-ia32_intel64-linux/source/tools/ManualExamples/obj-intel64/itrace.so
-- ./smhello
0xffffffff

This can be exploited to escape instrumentation by patching a mov and
then jumping to the address contained in the register:

#include <stdio.h>
main() {
asm("call foo\n\t"
"foo: pop %rax\n\t"
"movl $0x4004e7, 10(%eax)\n\t" // put @nottraced() in the next mov
"movl $0x4004fb, %eax\n\t" // @traced(), will be overwritten
// by @nottraced() if not
instrumented
"call *%rax\n\t");
}

// we don't want PIN to analyse this
nottraced() {
printf("trace me if you can!\n");
}

// we want PIN to analyse this, a dummy function
traced() {
printf("you're not supposed to get here\n");
}

Here is the result:

reynaudd@lhs-2:~/test/packed$ ./escape2
trace me if you can!

reynaudd@lhs-2:~/test/packed$ pin -t
./pin-2.5-24110-gcc.4.0.0-ia32_intel64-linux/source/tools/ManualExamples/obj-intel64/inscount0.so
-- ./escape2
you're not supposed to get here

And finally, some configuration information (as you could see, I use
the kit 24110 for gcc 4.0):
reynaudd@lhs-2:~/test/packed$ gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2

reynaudd@lhs-2:~/test/packed$ uname -a
Linux lhs-2 2.6.26-1-amd64 #1 SMP Sat Jan 10 17:57:00 UTC 2009 x86_64
GNU/Linux

I posted some details here:
http://indefinitestudies.org/2009/01/12/pin-versus-self-checking-and-self-modifying-code/
http://indefinitestudies.org/2009/01/19/pin-me-if-you-can/

Regards,
Daniel

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Yahoo! Groups

Group Information

Yahoo! Groups Tips

Did you know...

Messages