Monday, 23 October 2017

CTF Writeup - Flare-On 2017 - 06: payload.dll

  • Name - payload.dll
  • Category - Reverse Engineering
  • Points - 1
  • Binary - Download here

The next challenge on the list is a 64-bit windows DLL. We create a small 64-bit program that loads the DLL and calls the only exported function by its ordinal number:

#include <windows.h>
#include <stdio.h>

int main(int argc, char* argv[])
    FARPROC func;

    HINSTANCE dllHandle = LoadLibraryA("payload.dll");

    if (dllHandle == NULL)
        return 0;

    printf("Loading payload.dll\n");
    func = GetProcAddress(dllHandle, 1);

    printf("Press Any Key to Continue\n");
    return 0;

Running the binary we get the following message box:

Interesting. It tells us to insert a clever message, yet the exported function doesn't accept any parameters. Let's take a look at function sub_7FEFAB95A50() which has an xref to this message:

If we put a break point on the JNZ instruction in the basic block at the top and manually alter the execution flow to the yellow basic blocks by flipping the Zero Flag, we reveal a single character from the key:

As already annotated in the previous image, the yellow basic blocks set a region as RWX, decrypt the memory region with key orphanedirreproducibleconfidences and call it to reveal a single of the character of the key.

The question now is, how do we force the DLL into revealing the other characters of the key when it doesn't accept any input? The answer lies in function sub_7FEFAA24710():

__int64 sub_7FEFAA24710()
    struct _SYSTEMTIME SystemTime; // [rsp+20h] [rbp-28h]

    return (unsigned int)((SystemTime.wYear + SystemTime.wMonth) % 26);

If this function returns 0x19 (25), as it does in this case, it will use the 25th key to decrypt the 25th region and reveals the 25th character of the key. Manually setting the output of this function between 0 and 13, and manually forcing the execution to the yellow blocks as we have done before, we reveal the first 14 characters:

  • key[0] = 0x77
  • key[1] = 0x75
  • key[2] = 0x75
  • key[3] = 0x75
  • key[4] = 0x74
  • key[5] = 0x2d
  • key[6] = 0x65
  • key[7] = 0x78
  • key[8] = 0x79
  • key[9] = 0x30
  • key[10] = 0x72
  • key[11] = 0x74
  • key[12] = 0x73
  • key[13] = 0x40

As we reach the '@' character we can stop since we know that the email has to end with

The final key is therefore

No comments:

Post a comment