These are writeups for BSides Brisbane, which happened on July 4th! I hoped to get this out earlier, but I was flying out of the country right after the conference, and then life happened.

This was my first time on the other end of a CTF, making challenges instead of solving them. I started to think about making these in 2025 after Crikeycon, as there were not many crypto challenges.

As small conference CTFs like this one tend to cater towards beginner players, I wanted to make some challenges that were related to what drew me to cryptography when I was first starting - a lot of real-world exploits on game consoles.

Starlet

Challenge Solution

On a quick read through of the code, the program gives you the SHA-256 hash of a flag in hex, asks you what the flag is, and only gives you the flag if the hash of the two flags match.

However, the function being used to compare the two hashes is strncmp. The man page for this function mentions that the function is equivalent to:

memcmp(s1, s2, MIN(MIN(strnlen(s1,n),strnlen(s2,n))+1, n))

If you have ever worked with C before, you know that a string contains the characters in the string, then a null byte to show the string is finished. Looking at the output of the program:

I will only show the flag to people who already know it!
The hash of the flag is: 816f0095a0d01aaf28541b830ac4ee0ef97d340e18c2611c6e60fe0ba8598df3

In C, this will be read as 0x81 0x6f 0x00… or a 2 character string! This means that instead of finding a full hash collision, you only need to find a collision of the first 3 bytes.

i = 0
while True:
    false_flag = hex(i)[2:]
    hash = sha256(false_flag.encode()).digest()
    if hash[:3] == hash_bytes[:3]:
        break
    i += 1
print(false_flag)

Once you have a flag that matches the first 3 bytes of the hash, the program will happily send you the flag you definitely already know :)

Real-world inspiration

This is based of of Trucha, the or signing bug, in the Nintendo Wii! It would verify the hash used in the signature of a disc or program, but used strncmp instead of memcmp, the same as this program. This made it quite easy to fake a signature. The Wiibrew wiki has a good article about it here.

Playshell

Challenge Solution

The core of this challenge is a nonce-reuse attack for ECDSA. The code used to generate a new signature is:

def sign(message, key, k = randrange(int(curve.p()))):
    hash = int.from_bytes(sha256(message.encode()).digest())
    signature = key.sign(hash, k)
    return (int(signature.r), int(signature.s))

Since the random value is generated in the function header, the same value is used every time. You can also notice this by getting the signature for several different commands - the \(r\) value will always be the same.

If you aren’t familiar with how ECDSA works - the signer takes \(G\), the generator part of the public key, and multiplies the point by \(k\). the \(x\) value of this point \(kG\) becomes the \(r\) value, and \(s\) is calculated as \(k^{-1}(z+rd)\), where \(d\) is the private key.

However, when two of the same keys are used, the \(r\) value will be the same, and when the value of \(k\) and \(x\) is the same for both messages, you can recover the \(k\) value used with a bit of rearranging. Using that, you can recover the private key.

After you have the private key, you can sign and register any command you want… for example, cat flag.txt :)

Real-world inspiration

This exploit was used to reveal the private key used to sign software on the Playstation 3! The PS3 used ECDSA internally to verify that software was legitimate and official - but they reused the same value of k, and in 2010 fail0verflow did a CCC talk on the vulnerability. You can watch the talk here or look at the slides here.

Tegra

Challenge Solution

Although the program doesn’t let you decrypt any text, the way that it replaces the key is vulnerable! When you provide a new key to encrypt things with, if the key is shorter than 16 bytes, then it keeps the rest of the old key:

def replace_key(old: bytes, new: bytes) -> bytes:
    return (old[len(new):] + new).ljust(16, b"\x00")[:16]

Because of this, you can send a 1 byte key and keep 15 bytes of the old key, a 2 byte key and keep 14 bytes… If you send something to encrypt before you overwrite the key each time, once you replace all but one of the bytes, you can try to find what the last byte is by brute forcing that byte until you get a key that decrypts your text.

Repeat this process with the unknown byte for every key, and once you’re finished, you can recover the full key - with a computational complexity of \(2^{12}\), instead of having to brute force the entire 256 bits.

Real-world Inspiration

When writing to the security engine of the Tegra X1 on the Switch, the AES keytable is written to 4 bytes at a time and immediately flushed. This has been used in the past to recover keys from the console. There is a little more information about it on the SwitchBrew wiki, and a paper about the attack here.

Final notes

BSides Brisbane had an AI category and a non-AI category, so my main goal in making these challenges is to get at least one person to try a challenge and become excited about cryptography. This was a massive success - I had a few people come tell me they thought my challenges were cool after the CTF, and one of them has been doing more crypto after that.

As long as people keep learning from my challenges and having fun solving them, I’ll keep writing them - that’s the whole point of CTFs to me :)

It’s been a while since I’ve written on this blog! Since I last posted, I’ve gotten better at crypto challenges, and was able to solve one for the Team Oceania Qualifiers this year.

The Challenge

from fastecdsa import curve, ecdsa, keys
import ast, os

FLAG = os.getenv('FLAG', 'oiccflag{?????????????????????????????????????}')

p = (3<<256) - (3<<128) + 1
EC = curve.Curve("BabyShark258", p, 0, 22, p, 3, 7)
priv, pub = keys.gen_keypair(EC)

msgs = ['Baby shark', 'Doo doo doo doo doo doo']
for msg in msgs:
    print(f'{msg}: {ecdsa.sign(msg, priv, EC)}')
sig = ast.literal_eval(input('Combined signature: '))
print(all(ecdsa.verify(sig, msg, pub, EC) for msg in msgs) and FLAG)

First thing I notice - we aren’t given the public key, but with either one of the signatures, it’s possible to recover. I used some of the code from the recover_public_keys function in the python ecdsa library, modified to work with the custom curve.

from ecdsa import numbertheory
from hashlib import sha256

def msg_bytes(msg) -> bytes:
    if isinstance(msg, bytes):
        return msg
    elif isinstance(msg, str):
        return msg.encode()
    elif isinstance(msg, bytearray):
        return bytes(msg)

def recover_pubkey(r, s, msg):
    x = r
    e = int(sha256(msg_bytes(msg)).hexdigest(), 16)

    alpha = (pow(x, 3, p) + (a * x) + b) % p
    beta = numbertheory.square_root_mod_prime(alpha, p)
    y = beta if beta % 2 == 0 else p - beta

    # Compute the public key
    R1 = E(x, y)
    Q1 = pow(r, -1, n) * (s * R1 + (-e % n) * G)
    Pk1 = Q1

    # And the second solution
    R2 = E(x, -y)
    Q2 = pow(r, -1, n) * (s * R2 + (-e % n) * G)
    Pk2 = Q2

    return [Pk1, Pk2]

For both signatures, one of the valid public keys was shared, and that is the public key we need.

Second thing to notice - this curve is anomolous! This means that the order of the generator point is the same as the curve order, and it is possible to use Smart’s Attack. This means that the points on the elliptic curve can be “lifted” to a curve defined over p-adic numbers, and you can then recover the private key. This github page has a good example of the attack, which I used.

def lift(P, E, p):
    # lift point P from old curve to a new curve
    Px, Py = map(ZZ, P.xy())
    for point in E.lift_x(Px, all=True):
         # take the matching one of the 2 points corresponding to this x on the p-adic curve
        _, y = map(ZZ, point.xy())
        if y % p == Py:
            return point

P = pubkey
E_adic = EllipticCurve(Qp(p), [a+p*13, b+p*37])
newG = p * lift(G, E_adic, p)
P = p * lift(P, E_adic, p)

# Calculate discrete log
Gx, Gy = newG.xy()
Px, Py = P.xy()
d = int(GF(p)((Px / Py) / (Gx / Gy)))
assert pubkey == d * G

After getting the private key, the last challenge is making a signature using a chosen value \(k\) - instead of a random one - where \((r, s)\) is the same for the hashes of both messages, denoted \(z_1\) and \(z_2\).

As \(k=z+r\cdot d\), when using \(k_2=k_1^{-1}\), it is possible to force the same value of $r$ by solving for \(r\) when \(\frac{k_1}{k_2} = \frac{z_1 + r\cdot d}{z_2 + r\cdot d}\). After re-arranging, you find \(k_1\) (and \(k_2\), as it is the inverse of \(k_1\)) by lifting \(r\) to the p-adic curve - finding \(k_1\) the same way as the private key. With this crafted value of \(k\), you can calculate \(s\) as normal, and it will a valid signature for both \(z_1\) and \(z_2\).

msgs = ["Baby shark", "Doo doo doo doo doo doo"]

z1 = int(sha256(msg_bytes(msgs[0])).hexdigest(), 16)
z2 = int(sha256(msg_bytes(msgs[1])).hexdigest(), 16)

r = -(z1 + z2) * pow(2 * d, -1, p) % p
R = E.lift_x(r)
Rx, Ry = (p * lift(R, E_adic, p)).xy()
k1 = ZZ(-(Rx / Ry) / -(Gx / Gy)) % p

r1 = (k1 * G).xy()[0] % p
s = pow(k1, -1, p) * (z1 + r1 * d) % p

print("(" + str(r1) + ", " + str(s) + ")")

As the signature is valid for both messages, submitting the signature to the server will result in a flag :)

The full code can be found on this gist.

Category: Crypto
Points: 100
Solves: 3

Prove you are timk:

I’ve chosen a Pokemon and encrypted it using timk’s public key.

To prove you are timk, use your private key to decrypt the ciphertext which will tell you the Pokemon to select.

I know timk has lots of keypairs so I’ve supplied the public key for him to know which private key to use.

To ensure things stay safe, I’ll rotate the Pokemon and key every 5 minutes.

Don’t bother trying to guess as I will block you for 30 seconds on an incorrect attempt!

The go plan - and where I mess things up

Upon inspecting the website, this comment is also revealed:

<!-- TODO: Look into newer padding schemes. For now I have just padded PT to the key size using leading null bytes, but it should be pretty solid. -->

Pretty solid… of an attack strategy :)

The TL;DR of what needs to be done is:

• Take the public key provided and the list of all 808 Pokemon.
• Pad the Pokemon with leading null bytes, and then encrypt that string with the public key provided.
• Compare this ciphertext with the encrypted Pokemon provided. If you find a match, then you have the Pokemon!

Pretty easy! First problem I run into… parsing the .pem key to an RSA public key. I opt to pass this to openssl:

def pad_with_null_bytes(pokemon):
    max_data_size = 244 # This was first done by trial and error...
    # I found out there was a reason why this was 244 and not 256 later, which was why my code was failing. :P
    padding_length = max_data_size - len(pokemon)
    padded = b"\x00" * padding_length + pokemon
    return padded

with open('character.enc', 'rb') as file:
    encrypted_solution = file.read().strip()

pokemon = open("pokemon_list.txt", "r")

for p in pokemon:
    p = pad_with_null_bytes(p.strip())
    with open('current.txt', 'w') as current:
        current.write(p)
    
    os.system('cat current.txt | openssl pkeyutl -encrypt -pubin -inkey public.pem > text.enc')
    # This was a lot messier and had full paths, but I'm shortening it for privacy and to make it easier to read

    with open('text.enc', 'rb') as c:
        pokemon_encrypted = c.read()

    if pokemon_encrypted == encrypted_solution:
        print(p)

Great! Code to encrypt Pokemon done! And yet… I wasn’t getting any matches.

A bit of hindsight, and more mistakes

I think that a common theme of write-ups on this blog so far has been “I spend too long barking up the wrong tree, and I should have figured out what was going on earlier”.

What was actually happening was I was double-padding the text! Most libraries that encrypt things using RSA public keys hope that you use sane and secure padding, which is fantastic for IRL implementations, however for this CTF challenge it wasn’t what I wanted.

This is also why I couldn’t encrypt things when the plaintext was longer than 244 bytes, instead of the 256 byte key length I expected - it’s because of PKCS#1 v1.5 padding overhead.

I unfortunately didn’t realize this, and spent more time writing incorrect code, and a LOT of time debugging it.

from cryptography.hazmat.primitives.asymmetric import padding
from cryptography.hazmat.primitives import serialization

def load_public_key(pem_path):
    with open(pem_path, "rb") as key_file:
        return serialization.load_pem_public_key(key_file.read())
    # It was good to find a library that let me load a public key in Python, but for future reference I should understand it more before using it. :)

def pad_with_null_bytes(pokemon):
    max_data_size = 244
    padding_length = max_data_size - len(pokemon)
    padded = b"\x00" * padding_length + pokemon
    return padded

def encrypt_pokemon(public_key, pokemon):
    key_size = public_key.key_size // 8  
    # Converting the RSA key size from bits to bytes.
    padded = pad_with_null_bytes(pokemon)

    encrypted = public_key.encrypt(
        padded,
        padding.PKCS1v15()
        # I definitely knew that it was double padding at this point, but I didn't know how the library worked so trying to not pad this threw errors.
        # At some point, I even had the comment of "how do I get rid of this shit"...
    )
    return encrypted

pubkey = load_public_key("public.pem")

with open('character.enc', 'rb') as file:
    encrypted_solution = file.read().strip()
pokemon = open("pokemon_list.txt", "r")

for p in pokemon:
    p = pad_with_null_bytes(p.strip())
    pokemon_encrypted = encrypt_pokemon(pubkey, p.encode())
    if pokemon_encrypted == encrypted_solution:
        print(p)

The solution, finally

Partially because I was running around the con and talking to people as well as doing the CTF, I only got the solution 10 minutes before the CTF ended.

from cryptography.hazmat.primitives import serialization

def load_public_key(pem_path):
    with open(pem_path, "rb") as key_file:
        return serialization.load_pem_public_key(key_file.read())

def encrypt_pokemon(public_key, pokemon):
    key_size = public_key.key_size // 8
    # Converting the RSA key size from bits to bytes.
    encrypted = public_key.public_numbers().n.to_bytes(key_size, 'big')
    encrypted = pow(int.from_bytes(pokemon, 'big'), public_key.public_numbers().e, public_key.public_numbers().n)
    return encrypted.to_bytes(key_size, 'big')

pubkey = load_public_key("i_choose_you/public.pem")

with open('i_choose_you/character.enc', 'rb') as file:
    encrypted_solution = file.read().strip()
pokemon = open("i_choose_you/pokemon_list.txt", "r")

for p in pokemon:
    p = p.strip()
    tst = encrypt_pokemon(pubkey, p.encode())
    if tst == encrypted_solution:
        print(p)

And then…

# python3 ./final.py
Chimecho

Finally! I’m able to submit the Pokemon with 10 minutes left in the CTF.

Well done! flag{                  }

Finishing notes and self reflection

I actually wasn’t planning on taking part in this CTF, however I got a text from one of the members from my uni society asking me to join the team as they need someone who understands crypto. I know I’ve always said that crypto doesn’t like me, but it turns out that kind of half understanding crypto is a pretty high bar. We ended up coming third in the CTF as well, which is incredible!

On the flip side, I ended up meeting the crypto player of the winning team, as well. He ended up getting over half the points for his team, and he was pretty incredible…. I may have gotten a bit of a case of impostor syndrome after the CTF. I think that this is definitely going to encourage me to work harder on training for CTFs in the future, although this motivation may be killed by university work in the near future.

(also, you should check this guy out. he’s pretty cool.)

Overall, I think that what I need to get better at is being able to script well, and knowing the libraries and ins and outs of the tools I use for CTFs. Unfortunately this is something where the solution is “just play more”, but I think that’s life.

One of the first things I learnt when I started learning to hack was linux. It was fun until I hit a ceiling of understanding about the differences in Operating Systems, what’s a Shell, Kernel, etc.

But once I got better I started developing a liking towards the terminal and how the Linux operating system is better than say Windows, or worse in some cases. How none of them is superior, nor the other inferior. We shall find out with this challenge.

Be careful, a lot of fake galfs around.

For the challenge you were given an unmarked file named challenge. Upon running file challenge, you see that it is a Windows file system.

I change the file to challenge.iso and I mount it. Naively, I try to strings and grep for the flag:

for i in *; do strings "$i" | grep -e ACECTF; done

With this I am rewarded with…

ACECTF{50_much_f0r_50_l177l3}
<x:xmpmeta xmlns:x="adobe:ns:meta/"><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:title><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li xml:lang="x-default">ACECTF{50_much_f0r_50_l177l3}</rdf:li></rdf:Alt>
</dc:title></rdf:Description><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:description><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li xml:lang="x-default">ACECTF{50_much_f0r_50_l177l3}</rdf:li></rdf:Alt>
ACECTF{50_much_f0r_50_l177l3}
<x:xmpmeta xmlns:x="adobe:ns:meta/"><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:title><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li xml:lang="x-default">ACECTF{50_much_f0r_50_l177l3}</rdf:li></rdf:Alt>
</dc:title></rdf:Description><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:description><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li xml:lang="x-default">ACECTF{50_much_f0r_50_l177l3}</rdf:li></rdf:Alt>
ACECTF{What are you looking at?}
<x:xmpmeta xmlns:x="adobe:ns:meta/"><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:title><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li xml:lang="x-default">ACECTF{What are you looking at?}</rdf:li></rdf:Alt>
</dc:title></rdf:Description><rdf:Description rdf:about="uuid:faf5bdd5-ba3d-11da-ad31-d33d75182f1b" xmlns:dc="http://purl.org/dc/elements/1.1/"><dc:description><rdf:Alt xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"><rdf:li xml:lang="x-default">ACECTF{What are you looking at?}</rdf:li></rdf:Alt>
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}
ACECTF{4ll_7h47_ju57_70_g37_f4k3_64lf}

…And so on. Overall, 1830 lines of fake “galf”s and no real flag. Clearly, I need a different approach - and I hopefully have learned my lesson that if I get a bunch of fake flags while using grep, I probably have the wrong approach.

A new approach, and a bit of hindsight

If you have ever worked with NTFS before, you may have heard of Alternate Data Streams - ADS - on Windows. The TLDR of it is that more than one data stream can be associated with one file, with the format filename.extention:streamname. This can hold metadata, malware, or… flags.

On Linux, you can use testdisk to look at these alternate data streams. On selecting the mounted disk image, selecting Advanced, and then List, I can look at what files are on the disk - and what data streams exist on the files. Lo and behold…

The file 666c61672e747874.jpg has a flag and key! The data stream 666c61672e747874.jpg:Flag has the string CTCHHW{7t3_h1hw3p3sq3_s37i33r_a0l_4li_a3}, and 666c61672e747874.jpg:Key has the string cryforme. After this, it’s a simple Vigenère decode:

This gets the flag: ACECTF{7h3_d1ff3r3nc3_b37w33n_y0u_4nd_m3}