top of page

Demystifying Debunked: Exploit This CTF Writeup

Demystifying Debunked

Our EXPLOIT THIS CTF is tailored to those hackers and enthusiasts alike, that share a passion for all things embedded, IoT or hardware related.

Debunked is another 50 point CTF challenge brought to you by Exploit Security. This and other CTF challenges can be found

In our last blog we stepped through "The Elves Magic" challenge, now we will take a look at another simple challenge using the same approach. It is our belief that using a systematic methodology, this helps to build better technical capability when applying such knowledge to real-world technical challenges.

Task: This challenge calls for the participant to examine the given binary and reverse it for the win !

Let's start by first examining the binary using the *nix FILE utility. As shown in our previous blog post the FILE utility can be used to ascertain the file type. As seen below we are dealing with another ELF binary and in this case we are running on an ARM64 architecture.

Enter GDB (GNU Debugger). GDB is a native *nix debugger that is used to look under the hood of a *nix binary in order to see how it operates upon execution. It allows its user to examine binary functions, registers, stack and assembly.

At its most basic level of usage GDB merely takes the binary as an argument, after which the user will be "dropped" into a GDB command interface.

Let's run GDB using our binary as an argument

Issuing the info functions command prior to executing the binary will display a list of all the user defined functions that exist within the binary prior to its execution. NOTE: Dynamically linked libraries and their associated functions are loaded at runtime, this helps to reduce the size of the binary.

Using this information we can look to further determine what each of these functions is responsible for and thus simplifying where we should hone our sights.


  1. _init - The dynamic loader executes the (INIT) function before control is passed _start function and executes the (FINI) function just before control is passed back to the OS kernel.

  2. _fini - The dynamic loader executes the (FINI) function just before control is passed back to the OS kernel.

  3. main - This function marks the beginning of any program in C. The main function in C is the first function to be executed by the Operating System.

  4. frame_dummy - This function lives in the .init section. It is defined as void frame_dummy ( void ) and its whole point in life is to call __register_frame_info_bases which has arguments.

  5. strlen@plt - Calculates the length of a string and is apart of the standard C library.

  6. abort@plt - This function handles abnormal process terminations and is apart of the standard C library.

  7. strcpy@plt - This function handles copying of a string and is apart of the standard C library.

  8. printf@plt - This function handles the formatting and printing of data and is apart of the standard C library.

  9. _start - This function, is used to navigate to the "entry point" of the program or binary. It holds the address that is jumped to at program start.

  10. deregister_tm_clones/register_tm_clones - These are standard C library functions used for transactional memory model operations. These are normally called by the __do_global_dtors_aux function.

  11. obfs_decode - This function is used to deobfuscate strings in a binary file.

  12. debug_f - This function is somewhat unknown, which for us must lead to further examination !

Let's dump the disassembly for function debug_f to look into what it may be used for. We can use the GDB command line disassemble debug_f for this. This allows us to examine the assembly instructions used by the function debug_f

Without delving into the ARM64 architecture instruction set to deeply, we can look to make inferences about what this function might be used for at a high level, that is to de-obfuscation, as shown by the use of the obfs_decode "branch with link" instruction at address 0*0000000000000954.

With this in mind lets see if we can manually invoke this function whilst debugging the binary within GDB. We will load the binary into GDB, then we will set a breakpoint at main.

After setting the above break point, we use the RUN command to execute the program from within GDB.

Another GDB command that can be useful when debugging is the JUMP command, lets use this to attempt to jump to the debug_f function.

W00t !

The Security Team at Exploit Security hope that this simple walk-through has illuminated some concepts that will be useful for you !


Commenting has been turned off.
bottom of page