Tag: flare-on

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

Starting off the 5 series of challenges we have a very simple password challenge, when extracting the archive you have one file extracted.

MinesweeperChampionshipRegistration.jar: Java archive data (JAR)

When running the file, you are prompted for an invitation code. I unzipped the jar file finding the metadata and a class file. I ran strings on the class file and was able to see the flag in plain text in the file.

After entering the flag shown in strings into the prompt it is validated!

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

This challenge is like a lot of the first levels is a password challenge decoding challenges. In the next screenshot, you can see what happens when you run the executable.

I opened the binary up in IDA and found the main function. The Main function starts off setting up handles to read input and loading a string from the .rdata section to a local variable.

Taking a look at the string that is loaded, it looks like to be some encoded text. I guess that it is more than likely the password.

Back to the main function, after collecting the inputted password guess from the command line, it takes the inputted string and runs a function to encode it.

Looking at the encoder function I found what looks like a non-standard Base64 character set.

I took the custom Base64, the encoded string I found earlier, and entered them into CyberChef to decode the string. It returns what looks to be the flag.

To be sure I re-ran the challenge and enter the output and bingo it validates the flag!

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

The first challenge in the 2015 season on Flare On was a pretty easy enter the password type of challenge. I started off by opening the extracted file in IDA and running it in the debugger. I stepped to the section of code that evaluates the input versus the input

I extracted the encoded key from memory

Then I re-implemented the XOR encryption in python and generated the key from the data.

Which successfully worked!

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

Challenge 5 brings us a DLL file, I mainly used Ghidra to statically analyze this file.

5get_it: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

After Ghidra loaded and analyzed the file, I found this function at 0x1000a680 that does a few things, first to Reads and writes the Run key to setup persistence for this DLL file, and it also copies itself to the C:\windows\system32 directory as svchost.dll to look like a legitimate DLL file. Next, it executes a function that looks to act as a key logger.

This function sets up a buffer to store keystrokes into them write them out to a file named svchost.log. Looking at the mw_key_press_handler function we see how it handles the key presses.

This function has various handler function for each ASCII value for most upper case letters, lower case letter, number, and some other characters. However not all have handler functions, so I took a closer look at the functions.

Below are three examples of functions, some of the functions would set a global variable to 1 or 0 depending on if another variable was set, and/or call another function that sets a group of global variables to 0. Not all of the functions returned the same letter that was pressed. As shown below “`” returns the number “0”.

Taking a closer look at the global variables that are manipulated I could see a pattern of them being written or read depending on the keypress handler functions.

Went through the listing of functions and created a list of the key presses and the return values and saw what looks like the key.

But this table does not include the letter “m” at the end of “com” the handler for “M” has an extra function that it calls.

This function that the handler calls has a large number of local variables and makes Ghidra very sad, but its main function shows a message box with the flag: l0gging.ur.5trok5@flare-on.com

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

We start off with a PDF file in Challenge 4, I start off by dumping the contents of the streams using pdf-parser from Didier Stevens PDF-tools

pdf-parser.py -f APT9001.orig.pdf > apt5.txt

Looking through the content I find a block of Javascript code that looks interesting

After copying it out and some manual de-obfuscation I find a block of what looks to be hex-encoded shellcode. I grabbed a script to decode it into a binary file to run and debug.

from binascii import unhexlify as unhx

#encoded = open('encoded.txt').read() # The shellcode dump
out = open('shellcode.bin', 'wb')

encoded ="%u72f9%u4649%u1525%u7f0d%u3d3c%ue084%ud62a%ue139%ua84a%u76b9%u9824%u7378%u7d71%u757f%u2076%u96d4%uba91%u1970%ub8f9%ue232%u467b%u-SNIP-%u2454%u5740%ud0ff"

for s in encoded.split('%'):
    if len(s) == 5:
        HI_BYTE = s[3:]
        LO_BYTE = s[1:3]
        out.write(unhx(HI_BYTE))
        out.write(unhx(LO_BYTE))
out.close()

I took the binary code and loaded it in BlobRunner and attached x64dbg to it.

The first instruction sets the carry flag to 1, the following instruction JMPs to end the code if the CF flag is set, the JB instruction needs to be patched to a NOP or the CF set to 0 to keep running the code.

The code can be walked through until it loads the flag into the stack around offsec of +0x3c1 and it shows up in the register of ECX.

However, if you run the code until completion it shows up as junk in the message box that is displayed.

To get the flag to show up in the message box you need to NOP the look starting at +0x3ce before the CALL to EAX.

Now the flag shows up in the message box!

This is a post in a series where I complete every Flare-on challenge. The landing page for all of these posts can be found here

Challenge 3 brings a PE executable file to take a look at.

such_evil: PE32 executable (console) Intel 80386 (stripped to external PDB), for MS Windows

I loaded the file up in x64dbg and after navigating to the main function it looks to load a whole lot of data onto the stack then CALL into the loaded code.

I continued to step through the program monitoring and watching the memory region pointed to be ESI.

The shell code (not pictured) is decoded and over written in multiple stages leaving these messages at ESI

Finally revealing the flag

There are more elaborate ways to reveal the flag, the official write up uses IDAPython scripting to manually decode the messages.