TCS HackQuest Round1

Solution

The challenge name “AREA64” strongly hints at Base64 encoding. Interpreting “64” as a reference to Base64, I attempted to decode the given data using Base64, and the decoding was successful, confirming the assumption.

Solution

The code looks like an RSA low-exponent attack, which means we can reverse it to recover the flag.

Solution

The image appeared to involve a steganography-related issue. A basic automated scan was performed using a reliable online steganography analysis platform, AperiSolve (outhorseyourstego.com).

Solution

The challenge included a Base64-encoded string. After decoding it, I found the encoding code that was used to create the flag.

By reversing the code and using the encrypted output as the input file, we can decode it and print the flag.

Solution

The given file was an .ico file. Running file file.ico showed that it was actually a 7zip archive. So I renamed it to .7z and tried extracting it, but it turned out to be password-protected

Next, I used zip2john to crack the password. The recovered password was “tifanny”. After unzipping, there was a file containing some random-looking text

That text was Base64-encoded. Decoding it produced an image, which turned out to be a QR code. Scanning the QR code finally gave the flag

Solution

Since the challenge mentions logs, it felt like working with an incident report. The task was to validate IPv4 and IPv6 addresses. Only IPs matching the patterns 92.7.X.Y and 2510:a1:X::Y were considered valid, where X represents the index and Y represents the value.

We can take the log file as input, validate each IP address, and extract the index–value pairs from the valid ones. Finally, sorting the values by their index and joining them together reveals the flag.

Solution

The challenge description mentioned that a Tomcat port was open. Also, the provided challenge link was accepting URLs as input and displaying their contents on the page. Seeing this behavior immediately made me think that the challenge was based on SSRF.

To test this, I tried accessing http://0.0.0.0:8080, since 8080 is the default port used by Apache Tomcat. This request worked and loaded the same website again, but this time there were tags and indicators showing that it was dev access, which confirmed that internal services were reachable.

After that, I started poking around the internal site and tried visiting the /admin path. The page responded with a message saying that the admin section was under development and not accessible to the public.

However, when I inspected the response, there was additional information that wasn’t visible on the page itself. It referenced another internal API endpoint (something like /api/...).

Trying that API path directly finally revealed the flag