[insidious]

Hey all,

I've been working on an encrypted TCP/IP chat client in order to learn more about networking (I knew shitall about networking before I started this project), hence why it's in C. C, imo, is great to learn about the low-level functions of protocols and such.

It uses these macros in order to monitor socket activity and manage multiple conn

Code:

FD_ZERO - Clear an fd_set FD_ISSET - Check if a descriptor is in an fd_set FD_SET - Add a descriptor to an fd_set FD_CLR - Remove a descriptor from an fd_set

This code should work with both IPv4 and IPv6, too.

The code in and of itself is not complete, still ironing out a few things (like host disconnects) but i'm taking suggestions for anyone who wants to rip on my code. It would be helpful

I'll update the code once it's more complete.

(SL's security functions kicked in when i tried to post the thread with the code in code tags, so here's the gist)

https://gist.github.com/InsidiousMind/b4...c69a302d4e

UPDATE:
Fixed Host Disconnects and some other bugs

[Xiledcore]

Ooh, this looks interesting. I was actually thinking of making something like this myself, but I haven't gotten to it yet. I'll stay updated.

[insidious]

Ooh, this looks interesting. I was actually thinking of making something like this myself, but I haven't gotten to it yet. I'll stay updated.

Thanks man! The whole github repository is publically available here if you are interested.

PM me if you want to work on something like this together, too. Would be cool to make something with some other members with similiar interests

[Xiledcore]

Ooh, this looks interesting. I was actually thinking of making something like this myself, but I haven't gotten to it yet. I'll stay updated.

Thanks man! The whole github repository is publically available here if you are interested.

PM me if you want to work on something like this together, too. Would be cool to make something with some other members with similiar interests

It's looking good so far! And yes, I'll definitely do that. I find networking very fascinating myself.

[BORW3]

Using C? which is good book to learn C?

[insidious]

Using C?  which is good book to learn C?

The C Programming Language by Kernighan and Ritchie is how I learned,
also Learn C The Hard Way

[0xDEAD10CC]

You've got a ton of hardcoded stuff and the structure isn't really great. For instance, I don't know why fatal() and malloc() wrappers and such should belong in your 'chat' source file... But:

Code:

void fatal(char *message){  char error_message[100];  strcpy(error_message, "[!!] Fatal Error ");  strncat(error_message, message, 83);  perror(error_message);  exit(-1); }

- You've hardcoded the strncat property based on the length of a random hardcoded string in the previous call to strcpy.
- strncat is not guaranteed to append a null terminator, and you don't set it manually, nor do you zero-fill the 'error_message' buffer.
- if strncat were to copy 83 characters out exactly, that would be the 17 chars, plus those 83 chars, which is 100, meaning that there is no room in the buffer left for a null terminator, and subsequent calls to functions which rely on a null terminator would result in a buffer overrun.

The rest of your code is a bunch of other issues similar to these...


In your 'addchar' function there is a buffer-overflow possibility. Also it should be noted that casting the return of malloc() is not required in C because the prototype specifies that the return is a (void *), which is entirely capable of being implicitly casted to any other pointer type by C standard. Furthermore, it's actually more safe to not cast this because as malloc() is properly prototyped in <stdlib.h> as returning a void pointer, it will warn you if the compiler decides to revert to int in the case that you haven't included all the proper headers, whereas the cast that you've got there completely nullifies that because you're telling the compiler that you know better.

[insidious]

You've got a ton of hardcoded stuff and the structure isn't really great. For instance, I don't know why fatal() and malloc() wrappers and such should belong in your 'chat' source file... But:

Code:

void fatal(char *message){  char error_message[100];  strcpy(error_message, "[!!] Fatal Error ");  strncat(error_message, message, 83);  perror(error_message);  exit(-1); }

- You've hardcoded the strncat property based on the length of a random hardcoded string in the previous call to strcpy.
- strncat is not guaranteed to append a null terminator, and you don't set it manually, nor do you zero-fill the 'error_message' buffer.
- if strncat were to copy 83 characters out exactly, that would be the 17 chars, plus those 83 chars, which is 100, meaning that there is no room in the buffer left for a null terminator, and subsequent calls to functions which rely on a null terminator would result in a buffer overrun.

The rest of your code is a bunch of other issues similar to these...


In your 'addchar' function there is a buffer-overflow possibility. Also it should be noted that casting the return of malloc() is not required in C because the prototype specifies that the return is a (void *), which is entirely capable of being implicitly casted to any other pointer type by C standard. Furthermore, it's actually more safe to not cast this because as malloc() is properly prototyped in <stdlib.h> as returning a void pointer, it will warn you if the compiler decides to revert to int in the case that you haven't included all the proper headers, whereas the cast that you've got there completely nullifies that because you're telling the compiler that you know better.

Thanks, I was hoping someone would come accross and tell me what I did wrong hah.

Will fix these problems