Before you attack anything, you need to map the target. Every command the server exposes is part of its attack surface.

Your Mission:

1. Connect to the chat server on port 12345 using netcat.
2. When prompted, choose any username and press Enter.
3. At the > prompt, send /help to list every available command.
4. Note the banner and version string. They tell you what you are dealing with.

Hint: Connect with nc chatserver 12345. After entering a username, type /help and watch which commands the server advertises. Two of them, /date and /ping, run something on the host itself. Keep that in mind for later.

Fuzzing means throwing oversized and malformed input at each field to see which ones are handled safely and which ones break. Start with the username.

Your Mission:

1. Generate a username made of 8192 'A' characters.
2. Pipe it into the server through netcat as the username.
3. Watch how the server reacts. Does it accept, truncate, or reject it?

Hint: python3 -c "print('A' * 8192)" | nc chatserver 12345
The username field has a length check, so the server should refuse the oversized name and drop the connection. That is actually a useful result: it tells you this input is guarded, so you move on to the next one.

The username was protected. Now try the message field, which is a completely separate code path. This is where the real bug lives.

Your Mission:

1. Connect and log in with any short, valid username.
2. Once you reach the > prompt, copy/paste and send more and more characters until the server does not answer with a > character.
3. You made the server crash! That's a great first step towards exploitation!
Move on to the next challenge once the server crashed.

Hint: You can also chain the login and the payload in one shot:
python3 -c "print('Test'); print('A' * 8192)" | nc chatserver 12345
The first line logs you in as 'Test'. The second line is the oversized message. The message buffer is far smaller than what you are sending, so (you don't know it just yet, but) writing past its end corrupts the stack and the server falls over.
Being disconnected without apparent reason or suddently getting no response from the server is exactly what you are looking for.

Crashing the server is easy. Controlling it means knowing exactly how many bytes it takes to reach the fragile part of the stack. First, understand why it breaks. Here is the vulnerable read inside the chat loop:
char buffer[BUFFER_SIZE]; // BUFFER_SIZE is 1024 ... bytes_received = read(client_socket, buffer, 2048); // reads up to 2048 bytesThe buffer holds 1024 bytes, but the read is told it may pull in 2048. Anything past byte 1024 spills into whatever the compiler placed next on the stack. Push far enough and you corrupt something the function depends on, and the server process dies. From your side that shows up only as your connection (and everyone else's) being dropped, because the crash happens server side, not in your terminal.

Your Mission:

1. Send messages of increasing length and find the point where the connection stops surviving.
2. Using the 'A' character repeated multiple times as a payload, work out the threshold: the buffer is 1024 bytes, plus an X byte offset before the crash triggers.
3. Confirm the total bytes you can work with before the server crashes: BYTES_TO_CRASH - 1024 = Y bytes available.

Hint: Doing this by hand is slow, so automate it. The pieces you need: seq produces a range of numbers, a shell for loop lets you reuse each value, python3 -c runs a one line script where 'A'*n repeats a character n times, and a pipe into nc delivers it. Chain those so each iteration prints its length and then sends a slightly longer payload, and watch which length is the last one your session survives. Make sure your range reaches past where you expect the break, or you will never see it.

A crash proves the bug exists. Now, let's turn it into actual exploitation.
On this chat server, the username Admin is reserved: the server refuses it at login, so you cannot simply type it. You HAVE to really be the admin of the server to use it... Or do you?
I'll tell you a secret that will make your life easier: the message you send and the username value are contiguous in memory. They are stored right next to each other on the server's RAM. What I mean by that is that if you overflow the message buffer that we've seen in the last challenge, the extra bytes will end up directly in the username value.
Using the information you have now, find a way to bypass this check and make your username Admin.

Your Mission:

1. Log in with any allowed username (Admin, in any case, is blocked).
2. Build a payloads that will fill the message buffer and overwrite the word Admin to the username.
3. Send it as a message and watch the server treat you as Admin.

Hint: python3 -c "print('guest'); print('A'*256 + 'Admin')" will print 256 times the A character and then Admin.
Here, I used 256 as an example.
With the right payload, logging in as guest passes the reserved-name filter.
The A bytes then fill the message buffer to its edge, and the trailing Admin lands directly in the username field, overwriting guest.
The reserved-name check already ran at login, so nothing stops you now.
The server echoes message sent as: Admin, and /whoami will confirm it. You did not bypass the filter, you wrote straight past it.

This is the real prize: turning memory corruption into command execution. The command handler copies your input with no bounds check, and the shell string it relies on sits right beside that buffer:
char *handle_command(char *buffer) { char shell[64] = "bash -c "; char command[1024]; strcpy(command, buffer); // no length check ... else if (strncmp(command, "/ping", 5) == 0) { return exec_linux(shell, "ping -c 1 2>&1 127.0.0.1"); }And here is what exec_linux does with that shell string:
char *exec_linux(char *shell, char *command) { char cmd[512]; sprintf(cmd, "%s '%s' ", shell, command); fp = popen(cmd, "r"); ... }The /ping handler feeds shell straight into the line that gets executed. If your overflow reaches shell and rewrites it, you decide what actually runs on the host.

Your Mission:

1. Send a /ping message whose overflow overwrites the adjacent shell string.
2. Make the executed line start with cat flag.txt.
3. Read the contents of the flag.txt file stored on the server.

Hint: Three things have to be true at once. The message must still begin with /ping, or the vulnerable branch never runs. You need enough padding after that to reach shell, and you can find that offset the same way you measured the buffer earlier. Finally, whatever you place into shell becomes the front of the command, so the leftover 'ping ...' text has to be neutralised: a # inside a shell command starts a comment and swallows everything after it. Picture how the prefix, the padding, your command, and that # join into one single line.