One of the most important skills hacker can have is the ability to read code. Exploit code, specifically. Understand it and have the ability to tinker with it. One great resource for such endeavors is www.exploit-db.com. Go there, try to read their code. You don’t have to understand every single bit and byte of it, just have to have that ability to see the code and get the general sense of it. Almost intuitive. From there you will know where are the important parts to focus on.

As a fairly simple example, lets look at https://www.exploit-db.com/exploits/51887.

The key to quickly and efficiently navigating through text, especially code, lies in the ability to differentiate the important elements from the peripheral ones. Let’s dissect the code piece by piece.

This is the first part. Is there anything important here?

Not really. The mind should immediately ignore this part. Moving next:

Right away, our attention zooms in on the “send_post_request” part. This tells us there’s a program getting HTTP POST requests. Next, we look at the parts it needs: target_ip, command, target_port. Now, we quickly sort out what’s familiar and what’s not. Target_ip and target_port are easy; every app uses a port and an IP. But what about “command“? That’s the mystery. It becomes our first piece of the puzzle to remember. We’re not sure if it’s crucial yet, but it’s worth noting down.

Next, we look at the payload. There’s not much to see here, but we notice that the “command” is used in the “ipaddr” part, like this: (“ipaddr”: f”1;{command}”). If we’re beginners, we mark down f”1; as something new to us. We figure out that the {command} part is probably where our command in inserted.

So, to recap, here are our unknowns so far: the command and f”1;{command}.

Moving on to the rest of the function, it’s straightforward — it sends a request and shows the results. What’s next? We get to the main() function. We go over it quickly, figuring out what we already know and what we don’t. For someone just starting out, “argparse” might be a question mark — it has something to do with arguments. Another note we make is on action=”store_true” — also something unfamiliar for a novice.

So lets sum up our unknown parts we collected so far: command, f”1;{command}, argparse, add_argument, action=”store_true”.

Here, the “if” statement is checking if args.creds is true. This is how “if” statements function: IF something is TRUE, then do one thing; otherwise, do something else. Immediately, we link this to one of our unknowns – action=”store_true”. We guess that this probably means the “–creds” argument turns TRUE if it’s used. We also figure out that the parts with “add_argument” were just adding options to the args object. The names of these options are what we see after the “–“, but without the dashes.

Our assumption is that when the –creds parameter is activated, the exploit reveals the fixed (hardcoded) passwords of the app that’s open to attack. If the –creds option isn’t used, it then sets up the values for the ip, port, and command fields.

The last part:

Now we’re left scratching our heads over two ingredients: the mysterious command and this funky f"1;{command}" syntax. At first glance, command seems straightforward — it’s just the action we want our target device to perform, like the toaster popping the bread. But what’s with the f"1;{...}" garnish?

A bit of digging reveals that the f is actually an ingredient from Python-land, introduced in version 3.6. It stands for “formatted string literals,” making it easier to sprinkle variables (like our command) into strings without the mess.

And what about the semicolon ;? In the world of command-line interfaces, it’s like saying, “Once you’re done with this, do that.” It separates our benign 1 from the more exciting {command}, letting us slip in an extra action that gets carried out on the target device, no questions asked. This mechanism underlies the exploit’s operation.

This was a very simple exploit. Next time we will go over a more difficult one. But the point of the article was about how one should approach the mix of known & unknowns, and knit a story out of it by honing the skills of educated guesses, a bit of intuition and ability to discern the important from the less important. Very important skills for a hacker, and not only.