The challenge is writing a shellcode that a) doesn't contain nulls when encrypted (in order to get past the strncpy) b) doesn't contain nulls when decrypted (to get past the strlen(buf) test in the loop) and c) still does something interesting.
That's invalid code, because you disaassembled it without decrypting it. I attempted decrypting it, but it just doesn't seem like valid code at all. Nevermind, I take that back, the junk actually is valid code:
In the end, it just manually pushes the strings and their offsets into the stack, and sets eax to 0xB:
0012FE5E 0012FE6E ASCII "/bin/sh"
0012FE62 0012FE76 ASCII "-c"
0012FE66 0012FEB3 RETURN to 0012FEB3 from 0012FEC0
and then calls int80 (lunix syscall). eax=0xB indicates an "execve" syscall, thus it should basically just run:
/bin/sh -c rm -rf /home
How cute.
Too bad I ran this under a Windows debugger, and I only stepped through the code until the int 80 (which wouldn't work in Windows anyway), and even if I were to have debugged this under Linux, I wouldn't have stepped through that int 80 anyway.
>>21
That (2) might not work in all systems. As the shellcode is self-modifying. Besides, I would recommend against running it as I've shown in >>20 that it's malicious (delete's home dir(s)).
>>23
If a normal user runs it, and \home is readable, it would probably delete the user's own files and other user's files which are writable to anyone (**7).