| ASGARD-5877: Cryptographic 128-Bit ARX-Sponge VM Vault |
KEY: ASGARD-9A4BC3D2E1F07856-5877BEEFC001CAFE
FLAG: FLAG{128BIT_WIDE_ARX_SPONGE_UNBRUTEFORCEABLE_2026}
|
2026-09-06 00:54 |
| Dying To Code |
[Click to reveal]C4tCh_m3=_1F_y0U_c4N
key = tqm4uzdnxvsspypq94326tm56
I solved it by reversing the DTC VM dynamically: first I recovered the required environment value (C4tCh_m3=_1F_y0U_c4N), then I reconstructed the custom base32-like alphabet and derived the valid key tqm4uzdnxvsspypq94326tm56. I also found that the original binary leaves an internal context field uninitialized (ctx+0x40 == 25), so the VM accepts the real solution, but the normal program path blocks it because of that detail.
|
2026-03-31 19:41 |
| KeyGenMe! |
[Click to reveal]import argparse
import ctypes
import hashlib
from ctypes import wintypes
def current_windows_user() -> str:
get_user_name = ctypes.windll.advapi32.GetUserNameA
get_user_name.argtypes = [wintypes.LPSTR, ctypes.POINTER(wintypes.DWORD)]
size = wintypes.DWORD(256)
buffer = ctypes.create_string_buffer(size.value)
if not get_user_name(buffer, ctypes.byref(size)):
raise ctypes.WinError()
return buffer.value.decode("ascii")
def build_key(username: str) -> str:
digest = hashlib.sha256(username.encode("utf-8")).hexdigest()
return "".join(
chr(ord("a") + ((ord(ch) - ord("a")) // 2))
for ch in digest
if not ch.isdigit()
)
def main() -> None:
parser = argparse.ArgumentParser(description="Keygen for KeyGenMe.exe")
parser.add_argument(
"username",
nargs="?",
help="Windows username to generate the key for (defaults to current user)",
)
args = parser.parse_args()
username = args.username or current_windows_user()
print(f"Username: {username}")
print(f"Key: {build_key(username)}")
if __name__ == "__main__":
main()
|
2026-03-31 16:56 |
| Gate (BMI1/BMI2) |
orchid-vector-42
|
2026-03-26 14:42 |
| Crackmes.one RE CTF 2026 - FlipVM |
Good crackme. password:
$?$__LeT_Th#_h@ck!ng_b3g1n__$?$
|
2026-03-12 21:56 |
| my first simple crack me by whekkees |
0x6b656877 + 0x7365656b -> whekkees
0x72657771 + 0x74 -> qwert
login: whekkees
password: qwert
|
2026-03-12 05:32 |
| Boring |
[Click to reveal]Nice one. The binary is a Rust ELF with several fake flags in .rodata, so `strings` is a trap exactly as advertised.
The solve path for me was static analysis plus controlled emulation of the real validation routine. The program reads 38 bytes, then builds the expected flag through multiple stages: there is an anti-debug/anti-analysis layer first, and after that a chain of transformations that includes TEA-style rounds, an RC4-like stage, a ChaCha/Salsa-like mixing stage, and an AES-based final step. The important trick is that the anti-debug logic flips a global sabotage byte; once that happens, the generated buffer is intentionally corrupted and you always end up at “Access denied”, even if you are tracing.
So the practical solve was:
1. Locate the real `main` and the final byte-by-byte comparison.
2. Identify the anti-debug checks (`cpuid`/hypervisor, timing with `rdtsc`, `ptrace`-style logic, `/proc` checks).
3. Emulate the clean path with those checks neutralized.
4. Dump the expected 38-byte buffer right before the final compare.
No brute force needed, just untangling the anti-analysis and letting the crypto pipeline reconstruct the flag.
FLAG{d34d_c0d3_w4lk5_4m0ng_u5_1n_rust}
|
2026-03-11 17:45 |
| Nebula |
Nice crackme. I solved it by locating the real validation routine after the anti-debug checks (IsDebuggerPresent / CheckRemoteDebuggerPresent). The strings were only XOR-obfuscated with 0x5A, so decrypting them quickly revealed the prompt and success/fail paths. From there, the key check was straightforward: exact length 14, dashes at positions 4 and 9, a per-character transform whose total must be 0x539, plus a few direct relations between characters. I just rewrote that logic in a small script and generated a valid key without brute force.
KEY: ADBC-PLZR-6YZR
|
2026-03-11 17:17 |
| Simple Crackme 3 |
The key point is that there is no single static password: the program generates a new 12-character password on each run from a custom charset, keeps it in memory XOR-obfuscated, and only checks the FNV-1a hash of the user input. The easiest solve path was to attach to the running process, recover the stack-resident std::string, decrypt it with the stored XOR byte, and use that value as the password for that execution.
|
2026-03-07 05:41 |
| Fatmike's Crackme #9 (crackmes.one CTF 2026) |
Serial: D3FE-A7ED-BAAD-C0D3
Flag: CMO{byp4ss3d_f4tm1k3_2o26}
|
2026-03-07 05:38 |
| Chamber of Reflections |
[Click to reveal]FLAG-JSVM-1337
|
2026-03-07 05:10 |
| Silent Lock |
AaaA0Zpl
|
2026-03-07 05:03 |
| Pwn Flick |
The arithmetic obfuscation in Func 0 looked complex, but black-box analysis revealed it collapsed to a simple linear equation: 3 - input = target. Key found: 18446438094414070465
|
2026-01-09 02:00 |
| Modified Bessel |
The crackme tries to load a DLL named mandel.dll that exports a function named
function
. The key detail is that the executable is 32-bit, so the DLL must also be compiled for x86 (32-bit) architecture. Once the DLL is placed in the same directory, the program loads it and displays the success message.
|
2026-01-09 01:13 |
| ZEXOR-v0.1 |
[Click to reveal]AEXORRBSHA36325S33
|
2025-12-31 05:15 |