oracle — UMDCTF

Description

No separate organizer description was present in the provided workspace files.

English summary: the challenge ships a stripped ELF named oracle plus an encrypted feed.bin. The binary behaves like a market-settlement verifier: it reads a base64 ticket from ticket.txt, validates the decoded 32-byte body with a custom VM, derives 32 bytes of key material on success, and uses that material to decrypt the final archive record containing the flag.

Challenge overview

At a high level, the solve path was:

1. Decrypt the hidden .xtext code that main unseals at runtime.
2. Decode the runtime strings to understand the file format and execution flow.
3. Reverse feed.bin, which needs two outer decrypt passes before an ARC\x01 archive decode with a rolling XOR stage.
4. Reconstruct the VM semantics from record b and fix the critical misunderstanding about where the 32-byte ticket body is actually read from.
5. Solve the eight 32-bit constraints with Z3.
6. Use the VM output as AES-128 key || IV to decrypt record g.

The useful local artifacts created during solving were:

• decrypt_xtext.py
• patch_oracle.py
• decode_strings.py
• decode_feed.py
• emulate_crypto.py
• run_vm.py
• solve_ticket.py

Recon and hidden code decryption

The ELF is a stripped PIE x86-64 binary with a hidden encrypted section named .xtext. The visible main function is mostly a loader:

• it hashes the chk section with seed 0xc0def1ab
• derives four TEA key words from .rodata
• builds an IV from .rodata
• decrypts .xtext
• jumps into the now-decrypted logic

The important detail is that the hidden section is not plain AES or TEA-CBC. It is a TEA-based CFB-like stream mode:

...