I came across this piece of code in a article while trying to understand what was causing segmentation faults and other problems in my program, and the help article puts this code as a challenge and if I can't figure out whats worng in this code , I definately can't understand further discussion.
Can i get any help..

#include <stdio.h>
int main(int argc, char **argv)
{
char *buf1, *buf2, *buf3;
if(argc == 1) {
printf("\nThis program takes a string as an arguement.\n");
return(0);
}
buf1 = (char *) malloc(56);
buf2 = (char *) malloc(56);
buf3 = (char *) malloc(56);

strcpy(buf2,"CCCCCCCCCCCCCCCC");
strcpy(buf1, argv[1]);

printf("\n%s\n", buf1);

free(buf2);
free(buf1);

strcpy(buf3, "END OF PROGRAM");
printf("\n%s\n", buf3);

free(buf3);
return(0);
}

When you post code, you should use code tags to make the code more readable.

If you are asking a question about something you read online, please post the URL of the original. Otherwise we are left guessing about what you might have quoted out of context.

In the code you posted, I noticed only the lack of defensive programming. The code could seg fault if the size of the input (the command line argument) is larger than expected.

strcpy(buf1, argv[1]);

./myprog anargwithmorethan56charswillcauseasegmentationfaultbecauseitistolongforbuf1soyoubettercheckthis

or use strncpy(buf1, argv[1], 56);

Firstly, post code in code blocks to retain indentation.
The c library functions have their own manpages. At the top, the header files are listed.
Entering the program and trying to compile it would have provided enough feedback to
know that you didn't include needed include files.

This will get you started. Do you see any more problems?

Thanks to you all for the suggestions.Notes taken for clear and properly indentated questions from next time .

That page was teaching about buffer overflow exploits, not about buffer overflow.

So obviously it needed to assume an audience that fully understands the buffer overflow itself, so the focus could be on how to construct the input ascii data that would exploit the overflow to gain control of the program rather than to seg fault.

I'm sure there are better pages you might find if you are looking for explained examples of common programming errors that lead to seg faults for accidentally out of range input (and may lead to security holes if someone hostile understands your bug well enough to exploit it).

I read the article from which you got that code. It is self explanatory. It is also an article about how to take advantage of a broken program to execute arbitrary code. In his example, the author shows how to start an instance of "/bin/sh" with the privileges of the broken program.

The article in your link is about cracking. According to the letter of the law, your post violates this forum rule:
Please ask one of the site moderators to help you delete your post.

You could just edit your own post to take the link out, assuming you see this before a moderator takes any action.

When I asked you to post that link, I didn't guess that the link would violate forum policy. But sorry about my role in getting you to violate the rules.

I still think it is a generally a good idea to post URL's when asking questions about things you read online. But there are exceptions.

There isn't a big difference between a general discussion of how to exploit bugs (to crack security) vs. how to understand security flaws in order to identify and correct them. Since that was a generic lesson (not an exploit of a specific existing bug), I think that link ought to be OK at LQ in an appropriate context. But since security wasn't the point of the OP's question, it may be better to delete the link.

I was totally unaware of that.I will delete the URL ..