After running the program initially, we received no response, prompting us to realize that it required input. Upon providing the input, we observed that it simply echoed it back. To understand the mechanics further, we investigated the included vuln.c file, revealing that this challenge involved a buffer overflow.
The initial step involved disassembling the file to identify the reference address.
Subsequently, we converted the obtained address to ASCII format, yielding the string '.com'.
Using Python, we efficiently and dynamically filled in the buffer while actively monitoring the system logs (dmesg > dmesg | tail) for any relevant information.
Upon completing these steps, we utilized the provided nc command to run the input.
We kicked off this challenge by inspecting the file type, and it turned out to be a Matroska file. Given my knowledge of Matroska as Russian Nesting Dolls, I pondered how this association might be relevant and proceeded to examine the file using ffmpeg.
Bingo! The analysis revealed the presence of more than one font embedded in the file. Resolving this was straightforward – just change the font.
Instantly, having a grasp of how an oscilloscope functions proved invaluable. For those unfamiliar, an oscilloscope enables us to examine electricity at microscopic levels. Initially, we needed to dissect the information represented by all three lines.
The problem statement indicated the presence of 8 LEDs, and by correlating them with the 8 mini-spikes at the bottom of the screen, we inferred that each rise represented an 'event'—signifying either a high or low state on the LEDs. The middle row exhibited a change from low to high right at the end of these 8 mini-pulses, leading us to assume it was a reset and unnecessary for our application.
Upon revising the image for better clarity, we recorded all the 1s and 0s, but unfortunately, they didn't yield any usable information. However, a breakthrough occurred when we realized that the LEDs could be read forward or backward!
Reversing our input string, decoding it to ASCII, resolved the issue, and we successfully obtained our flag.
Challenge description...
Interestingly, our approach to this problem took a reverse turn. While investigating Iris for the next challenge, we stumbled upon Michelangelo's presence in the form of comments on her posts. Leveraging this lead, we successfully identified Michelangelo's Instagram account.
A brief perusal of Michelangelo's Instagram posts unveiled our solution discreetly embedded in the caption of one of his posts.
In our initial search, we located Iris Stein's LinkedIn profile, which provided details about the location of the company she works for. This valuable information allowed us to further investigate Iris on Instagram.
While perusing her Instagram page, a significant discovery unfolded – Iris had her mother's name mentioned. Armed with this new lead, we proceeded to search for Iris's mother on Facebook and successfully found her profile.
Upon exploring her mother's Facebook posts, we came across a noteworthy post about Iris's birth, complete with an image of the hospital. A swift reverse image search on the hospital photo yielded the specific hospital where Iris was born.
With these details in hand, we entered the information into the designated site and successfully obtained the flag
With only an image at our disposal, our initial approach was to perform a reverse image search using Google.
The first result appeared promising. Upon visiting the corresponding website, we observed that it was in Japanese. Leveraging translation plugins, we were able to translate the site and noticed a nearby church mentioned on the page. Subsequently, searching for 'Czech Wooden Products' on Google Maps led us to a single location near the identified church.
Interestingly, we stumbled upon the solution to this challenge quite accidentally. Knowing it involved a radio reading, we decided to leverage URH (Universal Radio Hacker) and uploaded the provided files.
While demonstrating the software to some teammates, guiding them on how to assist me, we made a serendipitous discovery. By switching the 'signal view' from analog to spectrogram, there it was – our flag. Nice!
We initiated the challenge by running the program to understand its requirements. Immediately, it requested a color, and not all colors were accepted.
Assuming string comparison, our first step involved running the strings command to identify potential colors. During this investigation, we noticed that the program also asked for foods. We identified a grouping of colors and foods, including 'Blue', 'Green', 'Yellow', 'Pizza', 'Pasta', 'Steak', and 'Chicken'.
However, we were still missing one color. To address this gap, we decided to analyze the program using Radare2, leveraging our understanding of assembly. By debugging the program at a series of compares, we quickly identified 'Red' as the missing color.
With all the colors in mind, we sought to examine the logic. While the flow chart feature of Radare2 left us somewhat confused, we turned to Ghidra for a clearer understanding.
Utilizing Cutter, which incorporates the Ghidra decompiler, we found a method called 'Check' and thoroughly inspected it.
Upon examination, we discovered that this project follows a unique logic. Working backward from Radare2's output, we deduced that 1,3,4,2 corresponds to red,yellow,green,blue.
It appears that this logic prints our flag! (Input in order: red, yellow, green, blue, chicken, pasta, steak, pizza)