Morse {}#

Morse code is a method of encoding text characters (letters, numbers, punctuation) using sequences of dots (·) and dashes (-).

It was invented by Samuel Morse in the 1830s for long-distance telegraph communication.

first download the given wav file,

decode the file using morse code audio decoder (Morse Code Adaptive Audio Decoder | Morse Code World)

after uploading the file in the decoder it decodes the audio,

I’ve copied the url which i got by decoding the wav file and converted the whole url to lowercase using a simple python code.

then i got this output, https://gist.github.com/zeroxdtd/29980e99f188f3f7a27289cb26a16788

i’ve got this github page which has flag in morse format,

now, i will convert this morse code using Morse code translator: Encode and convert online - cryptii

which is the required flag which is not in format, we can format it as

flag{tods_m0rs3_cod3_aud10}

The Internal Monitor#

Server-side request forgery (SSRF) is a web security vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location

I’ve used the following URL to confirm SSRF requests if needed

https://webhook.site

from the following webiste, we can see different cloud metadata services https://github.com/Prinzhorn/cloud-metadata-services

i’ve used the following URL’s because when u read description of the challenge it’s pointing towards possibility of having mock service

http://169.254.169.254/latest/meta-data/iam/security-credentials/root

http://169.254.169.254/latest/meta-data/iam/security-credentials/admin

then i used nmap to scan the open ports of the webiste, the result was as follows,

we can see that port 4890 is open and unknown, so i use it in the above links

http://169.254.169.254:4890/latest/meta-data/iam/security-credentials/admin

But this did not return data, indicating the metadata service wasn’t bound directly to the link-local IP on that port.

so we use localhost or any localhost payloads which can be the following to access as a admin

from the following only few will work because there is a blacklist blocking some of the localhost

1
__Basic localhost Payloads:__
2
http://127.0.0.1:port
3
http://localhost:port
4
https://127.0.0.1:port
5
https://localhost:port
6
http://[::]:port
7
http://0000::1:port
8
http://[0:0:0:0:0:ffff:127.0.0.1]
9
http://0/
10
http://127.1
11
http://127.0.1

0.0.0.0:4890/latest/meta-data/iam/security-credentials/admin i’ve used the above URL and got the flag

FLAG{TODS_Cl0ud_Ct4_D0n3_r8_w0ah!}

The Forbidden Wiki#

The challenge presents a mysterious “Forbidden Wiki,” hinting that important files like keys and flags might be hidden inside the application’s backend or container environment. The goal was to explore the system, find the encryption key, and decrypt the hidden flag.

firstly i downloaded the app.zip and extracted the files in it

in app.py we can see that key is open

so I did docker exec to get into containers

so now i’ve got the key which i wrote in key.txt a1Q4cEV3OTFRWng0blI3YlYyc0xtSDN5Q2FGZEdqMEs=

Accessing the file via the challenge’s view?file= endpoint allowed reading the key:

the-forbidden-wiki.tods.community/view?file=../../../../../../proc/1/fd/3

From this, I obtained the encryption key:

key = FYpw5BJyH7ekWHpSK_y8TVcdwaFASURCsr-EnOLTSA8=

I saved this in a key.txt.

The challenge had a /flag endpoint which returned the encrypted flag

I copied that encrypted output into a Python script.

Once executed, the script successfully revealed the final flag.

FLAG{TODS_wh0_put_4ll_th3se_curs3d_Art1cl3s_h3rE}

The Forever Gallery#

The challenge provided a Astro.js application (“Forever Gallery”).

A quick npm audit showed multiple known high-severity vulnerabilities in Astro, including reflected and stored XSS issues related to the server islands feature.

Astro vulnerable to reflected XSS via the server islands feature - https://github.com/advisories/GHSA-wrwg-2hg8-v723

This hinted that the challenge revolved around client-side injection.

While exploring the app, the endpoint:

1
/_server-islands/<Component>?e=file&p=&s=<json>

accepted arbitrary JSON input through the s= parameter.

This value was rendered back into the page without sanitization, allowing reflected script execution.

This matched the public advisories linked in the challenge description.

After confirming that injected payloads executed in the browser, the next step was to use JavaScript to read client-side accessible cookies and send them to a controlled endpoint for inspection.

The application stored challenge-specific data inside a non-HTTPOnly cookie, so it was intentionally accessible to JavaScript.

Once the browser sent the relevant cookie value, the challenge backend accepted the authenticated request and returned the final flag: FLAG{TODS_pls_upd4t3_Astr0_js}