What Is This?

Platform: hackerlab | Category: Reversing | Type: Challenge | Difficulty: Medium | OS: Windows | Author: XESXOR | Date: 2026-04-05 | Status: Solved Techniques: dynamic_api_resolution_analysis, registry_artifact_extraction, runtime_stub_emulation, string_decoder_recovery

Summary

Task: a PE32+ Windows x64 executable dynamically resolves registry APIs and jumps into runtime-generated RWX code. Solution: dump or emulate the generated stub, recover its byte-minus-0x41 string decoder, and extract the flag written into HKCU\SOFTWARE\TASK_CODEBY.

What Is This? — Hackerlab

Description

Что это такое? Сможешь ли ты узнать, что делает этот файл? Да причём так, чтобы получить флаг :)

English summary: we are given a Windows executable and need to determine what it really does, then recover a CODEBY{...} flag from that behavior.

Challenge Summary

The challenge is a PE32+ Windows x64 console executable. At first glance it looks like a small loader with a suspicious data blob and dynamic API resolution. The key trick is that it does not print the flag. Instead, it builds a second-stage x64 stub in memory, executes it, and that stub writes the flag into the Windows registry. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Recon Observations

Initial reconnaissance quickly showed the interesting parts:

• The file is a PE32+ x64 console program.
• Imports of interest include VirtualAlloc, VirtualFree, LoadLibraryW, and GetProcAddress.
• The program dynamically resolves these advapi32.dll functions:
  • RegCreateKeyExA
  • RegSetValueExA
  • RegCloseKey
• The binary contains the hint string:
  • CODEBY <- remember, this is where the flag starts :)
• There is also a large blob in .data, which strongly suggests hidden runtime data or generated code. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

These signs point away from a normal string-checking crackme and toward runtime code generation plus hidden side effects.

Reverse Engineering Path

The main function does not directly contain the flag logic. Instead, it:

1. Builds two local obfuscated byte arrays.
2. Runs helper logic that prepares a generated buffer.
3. Resolves registry-related APIs dynamically from advapi32.dll.
4. Allocates RWX memory with VirtualAlloc.
5. Copies the generated code into that region.
6. Executes the generated stub.
7. Frees the memory with VirtualFree. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

This means the real logic lives in the runtime-generated x64 code, not in the visible high-level control flow.

To inspect that second stage safely, I used emulation. The helper script emulate_main.py runs the initializer and main, intercepts the jump into heap memory, and dumps the generated code to generated.bin.

How the Runtime-Generated Code Works

Static inspection of the dumped stub, together with emulation, showed that it contains three embedded byte arrays. Each one is decoded with the same rule: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 python read-only • copy allowed Copy
decoded[i] = encoded[i] - 0x41

Decoding continues until a terminal byte 0x41 is reached.

That produces these strings:

• Registry key path: SOFTWARE\\TASK_CODEBY
• Value name: GALF
• Value data: CODEBY{REDACTED}

After decoding them, the generated stub performs exactly this logic:

1. RegCreateKeyExA(HKEY_CURRENT_USER, "SOFTWARE\\TASK_CODEBY", ..., KEY_SET_VALUE | KEY_CREATE_SUB_KEY, ..., &hKey, ...)
2. If successful, RegSetValueExA(hKey, "GALF", 0, REG_SZ, "CODEBY{REDACTED}", 0x22)
3. RegCloseKey(hKey) ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

So the payload is simple: create a registry key under HKCU, write a string value, and exit.

How the Flag Was Recovered

The important insight is that the flag is not printed to stdout and is not meant to be recovered by normal execution output.

Instead, the flag is the decoded registry value written by the generated stub:

• Key: HKCU\\SOFTWARE\\TASK_CODEBY
• Value: GALF
• Data: CODEBY{REDACTED}

Once the generated code was dumped and its string decoder was understood, the flag became visible immediately. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Solution

Below is a minimal reconstruction script that demonstrates the recovered decoder rule and the final registry-writing payload:

 python read-only • copy allowed Copy
#!/usr/bin/env python3

def encode_for_stub(s: str) -> bytes:
    return bytes((ord(ch) + 0x41) & 0xFF for ch in s) + b"\x41"


def decode_stub_string(buf: bytes) -> str:
    out = []
    for b in buf:
        if b == 0x41:
            break
        out.append(chr((b - 0x41) & 0xFF))
    return "".join(out)


# Recovered from reversing the generated x64 stub
encoded_key = encode_for_stub(r"SOFTWARE\TASK_CODEBY")
encoded_name = encode_for_stub("GALF")
encoded_flag = encode_for_stub("CODEBY{REDACTED}")
‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

key_path = decode_stub_string(encoded_key)
value_name = decode_stub_string(encoded_name)
flag = decode_stub_string(encoded_flag)

print(f"Registry key : HKCU\\{key_path}")
print(f"Value name   : {value_name}")
print(f"Value data   : {flag}")

Expected output:

 text read-only • copy allowed Copy
Registry key : HKCU\SOFTWARE\TASK_CODEBY
Value name   : GALF
Value data   : CODEBY{REDACTED}

Optional Reproduction Notes

If you want to reproduce the runtime analysis from the original binary:

1. Run the helper emulator:

 bash read-only • copy allowed Copy
python3 tasks/hackerlab/what_is_this/emulate_main.py

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

1. This executes the initializer and main, intercepts the jump into heap memory, and saves the generated stub to:

 text read-only • copy allowed Copy
tasks/hackerlab/what_is_this/generated.bin

1. From there, inspect the x64 stub and recover the embedded strings using the byte - 0x41 decoding rule until the 0x41 terminator. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍