Hurry up! Wait!
is a Reverse Engineering challenge worth 100 points.
This challenge lacks a description and simply provides a file named svchost.exe
with a SHA256 hash of f77b5f60dc93a4262fd64fd689a9c343679e27975319e369e471fe8a1a92babd
.
This file has an extension of .exe
, but it is really an ELF:
svchost.exe: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=0fb3d2b7a4d900676962a927b8181c15a8efbf0c, stripped
I opened this file with Ghidra and noticed that there was no main
function and this program looks like it may have been written in something other than C.
Looking for additional clues, I ran strings
on this file and noticed the string GNAT Version: 7.5.0
. I searched Google for this string and quickly found out that this is likely written in the Ada programming language.
I noticed that there was an entry
function. Viewing this in the disassembler shows that this is probably the entry point for the program:

Following through to FUN_0010fcc
, I see a call to __gnat_initialize
, followed by three unknown functions FUN_00101d7c
, FUN_0010298a
, and FUN_00101d52
, and finally __gnat_finalize
. Searching Google for gnat_initialize
reinforces the previous assertion that this is an Ada program:

FUN_00101d7c
appeared to perform initialization for the software and did not show anything which I felt was worth exploring further. Skipping ahead to FUN_0010298a
, I see a call to ada__calendar__delays__delay_for
, with an absurdly long value, followed by several calls to unknown functions.
The challenge name Hurry up! Wait!
makes sense now. We likely need to bypass this long delay somehow:

Each of these functions are similar, calling ada__text_io__put__4
. Reading Ada documentation, I figured out that Put
writes a single character. Each of these calls has a second parameter which pointed to a location in memory with 1
, which is stdout
:

Observing the addresses passed as the first parameter of these functions starts spelling out pico
, which means this is very likely the flag. Looking at the last function call ends with }
, which is the end of the flag format picoCTF{flag}
. Repeating this process for each function call, I was able to determine the flag. In the next picture, you can see that DAT_00102cd8
equals p
:

As I worked through this, I renamed the functions to their respective letters. Strangely enough, there were repeated functions, which made it so I didn’t have to do as much work. Notice the reuse of 5
and 1
:

Pingback: picoCTF Writeups – DMFR SECURITY