Assembly injection via python

Question

I am trying to use python to write out some assembly code to redirect the flow of a binary. This is for school. I am coming along pretty well, but I am stuck, alas. I have determined a list of assembly code ops that I need to execute, and the trouble is in a movl call. I need this to look like movl 0ドルx0, add(%ebp). I am using python to store these hex values in an env variable and planning to jump to that env variables location. So, I do something like

export CODE=`python -c 'print "somehex...\xc7\x45\xfc\x00\x00\x00\x00...morehex"'`

This stores this in the env just fine, and when I jump to it in gdb, I can x/i the assembly code. Everything looks good except for this movl call. Rather than reading the \x00's as the argument (supposed to be 0ドルx0), it takes the next 4 hex values as the argument for the source. I cannot find any other way of writing 0ドルx0 into the src argument of movl in the python fashion I have chosen.

Any help would be GREATLY appreciated. Been working on this for quite some time.

• Keith Randall: what is add? Just a symbolic constant?
• phihag: +1 for a great homework question. Those are rare. Have a look into the lecture materials, it should be explained in there ;)
• Jay Elrod: ahh. sorry. no, it is just some arbitrary address in hex format. wherever %ebp happens to be. in an actual disas it would look like 0x3b45fc00(%ebp) or like -0x4(%ebp). you can just ignore that. it is only the location of the ebp reg.
• Jay Elrod: unfortunately, there are no lecture materials stored on the web anywhere. i saw my prof do something similar with shellcode injection the other day (blew my mind), but didn't pay attention to how or whether he even was actually printing out the \x00 from his python script. it appears to not print anything. at the moment, i have filled the \x00 with \x90 (nop) and am just using the gdb set command to do it on the fly. still seg faulting when i jump to the env addresses.. :(

Answer 1

Environment variables are C strings, and those cannot hold 0円 bytes. Instead, you must write the shellcode in a way so that it does not contain any 0円 bytes. You must construct 0 values with other instructions such as sub, xor, or by moving an existing 0 value to the desired register/memory location.

By the way, instead of Python, you can simply use the shorter and more portable /bin/echo -e 'somehex\x00\x00more'.

• Jay Elrod: i will try it now. why can env variables not hold 0円 chars? i'm assuming if i were to python some argument for a program it would be able to contain those though, correct?
• phihag: Environment variables are a null-terminated list of pointers into C strings (see the execle man page, for example). As you may remember, C string is a fancy way of saying '0円'-terminated list of characters.
• Jay Elrod: AHHHHHHHH I have wasted sooo much time... Thank you.. Hopefully I will be able to figure out another way of doing all of this.
• phihag: Have a close look at the answer, it probably contains more hints than I should give. ( I sincerely hope my students don't find this question before we show them how to do it ;) )
• Jay Elrod: moving an existing 0 value? i can get the instructions to correctly represent the ones i need by using set *addr = 0x00, but is there no other way to do it? what do you teach? this is for a security course. nothing but binary analysis so far. VERY cool, but VERY dense, esp if you don't know any assembly before hand like me....

Answer 2

Looks like something is stripping the null bytes. The python works fine:

$ python -c 'print "somehex...\xc7\x45\xfc\x00\x00\x00\x00...morehex"' | hexdump
0000000 73 6f 6d 65 68 65 78 2e 2e 2e c7 45 fc 00 00 00
0000010 00 2e 2e 2e 6d 6f 72 65 68 65 78 0a 
000001c

But write it to an environment variable and read it back, and the nulls get stripped:

$ export CODE=`python -c 'print "somehex...\xc7\x45\xfc\x00\x00\x00\x00...morehex"'`
$ printenv CODE | hexdump
0000000 73 6f 6d 65 68 65 78 2e 2e 2e c7 45 fc 2e 2e 2e
0000010 6d 6f 72 65 68 65 78 0a 
0000018

• Jay Elrod: blast. i have wasted hours trying to figure this out. i guess i will just put it in as an arg and read it from there. unfortunate though. an environment variable would've been a pretty stable place to store some code