[Article]-Intro to C

Viewing 12 reply threads
  • Author
    • #1410
      Don Donzal

      We’re proud to be able to bring you the first article in this great, new column from Craig Heffner. This column is aimed squarely at those in the InfoSec field who are tired of hearing that you truly can’t be a security professional without knowing how to code.

      Permanent Link: [Article]-Intro to C


      Why even learn to program at all?

      Not everyone will have a need to learn programming. I’m sure there are many people who are quite accomplished in the field of computer security and have never written a program. Personally, I constantly find myself modifying programs to add or change their functionality, or just writing my own. And needless to say, if you are going to be doing any type of exploit discovery, you will need some programming knowledge.

      Without raising the “to code or not to code” argument, here is the way I look at it: hacking is about controlling a computer and making it do what you want – often when it is not designed to do so. A computer by itself is nothing but a bunch of silicon, wires, and metal. Software controls the computer, and, if you can control software, well…there ya go. 🙂

      Please be sure to add your comments and suggestions for future articles as Craig is more than willing to please the masses.


    • #13032
      Don Donzal

      Submitted to digg. Please help gets Craig’s new column off to a running start:


      Click on the above link, then click “digg it” under the big yellow number.


    • #13033

      Good refresher, really enjoyed it a lot. Craig explained the basic of C in a clear and concise fashion. I would love to see more related articles and advance C topics  from Craig in the near future.

    • #13034

      Haven’t had a chance to read through the full thing yet, hopefully sometime tonight or definitely tomorrow. Looks like an excellent and very well done tutorial though. Thanks! 🙂

    • #13035


      Nice article, would love to see some articles in basic assembly coding in C


    • #13036

      Hi. You should probably take the time to learn the language before attempting to teach it.

      char a = "a";

      This is not correct and does not do what you want, you end truncating a pointer to 8-bits and the value is stored in the variable a, as “a” denotes a pointer to the string “a”, what you probably meant was:

      char a = 'a';
      void main(int argc, char *argv[]) {

      main never returns void, it always returns int, if you turned on warnings (which you should be doing, especially considering your being unfamiliar with the language), you would get a warning here. int is the only ISO/IEC standards compliant return value.

      char buff1[] = "some long string";
      char buff2[256];

      why the hell are you copying 200 bytes? “some long string” is no where close to 200 bytes regardless of character set. You actually read outside the bounds of buff1, which can have any number of potential implications, most likely that you potentially leak data you didnt mean to (i.e. stack cookie), or potentially crash due this bad read. This code should read:

      unsigned char buff0[] = "some long string";
      unsigned char buff1[256];

      memset(&buf1, 0, sizeof(buff1));
      strncpy(buf1, buf0, (sizeof(buff0) < sizeof(buff1)-1 ? sizeof(buf0) : sizeof(buff1)-1));

            char buff[5];
          //Read the first four bytes. If fgets fails, print a message.

      This actually reads 5 bytes.

      Finally, don’t return 0/-1/et cetera, return EXIT_SUCCESS/EXIT_FAILURE, while it’s likely that these values expand to 0/-1 they don’t necessarily. Please go read the standard and use the language for longer than a week before attempting to teach people C incorrectly. kthx

    • #13037


      Thank you for your corrections; you are correct, void main() is a no-no, and I should have used single quotes for the “char a” declaration. However, I have to disagree with you on your last two corrections:

      why the hell are you copying 200 bytes? “some long string” is no where close to 200 bytes regardless of character set. You actually read outside the bounds of buff1, which can have any number of potential implications, most likely that you potentially leak data you didnt mean to (i.e. stack cookie), or potentially crash due this bad read.

      The strncpy man pages indicate (http://www.opengroup.org/onlinepubs/007908799/xsh/strncpy.html) that strncpy will copy a maximum of 200 bytes from buff1 to buff2. It will stop copying data from buff1 once a null character is encountered (i.e., the end of the source string); if the data copied is less than 200 bytes (which it is here), then strncpy will pad the remaining data with null bytes, so no data beyond the buff1 data will be stored in buff2. Your alternate example is correct as well, but not necessary.

      This actually reads 5 bytes.

      Not according to the fgets man page: “fgets() reads in at most one less than size characters from stream and stores them into the buffer pointed to by s…a ‘’ is stored after the last character in the buffer.” So by telling fgets to read 5 bytes, it will actually read in 4 bytes and set the fifth byte to 0x00. The article actually points this out when describing the fgets() function:

      fgets(buffer_pointer,256, fp); – This reads 255 bytes from the file pointed to by the fp file pointer into the buffer_pointer variable.

      The use of EXIT_SUCCESS and EXIT_FAILURE is also a good suggestion, particularly if you need to write code for multiple platforms.

    • #13038

      In the near future you should write an article just on pointers.

      Nice article, thanks!

    • #13039

      @dd wrote:

      especially when given the proportional size of the article to your post, you have a much higher percentage of error. 🙂

      True and well said.  ;D

    • #13040

      Why do you want to ignore the first byte that is read?

      int main(int argc, char *argv[])
          /*Declare our variables. Data will be read into buff.
          Because we want to ignore the first byte that is read, we set buff_ptr to point one byte
          beyond the beginning of the buff character array.*/
          char buff[5];
          char *buff_ptr = buff+1;

    • #13041


      If I am posting in the worng place I am sorry, I know nothing.

      I am beginning the  tutorial, I have downloaded and installed Dev c++
      I am running winxp Pro SP2 with all the upadates available…

      when I compile and run the first example:

      int main(int argc, char *argv[]){
      printf(“The name of this program is: %sn”,argv[0]);
      return 0;

      a small black system prompt box appears for about 1/4 of a second and then disappears.
      It is gone before I can see if there is even writing in it.

      is there a line I can add to… printf that defines the amount of time the output is displayed? 

      Or is this a setup problem where I need to change something?

      Thank you for any help,

    • #13042


      It sounds as though you are double clicking on the executable.

      Open a command prompt and CD to the directory where you saved the file.

      Run it from the command line: C:>app_name.exe [enter]



    • #13043

      hahahha 🙂

      Thank you for the advice, I wasn’t actually double clicking the .exe but I was compiling and running from within Dev c++…

      when I ran it from the command prompt it worked great.

      Thank you for taking the time.

Viewing 12 reply threads
  • You must be logged in to reply to this topic.

Copyright ©2021 Caendra, Inc.

Contact Us

Thoughts, suggestions, issues? Send us an email, and we'll get back to you.


Sign in with Caendra

Forgot password?Sign up

Forgot your details?