selfkey: the password that XORs to itself

A 14 KB stripped PIE from crackmes.one whose author promised "no plaintext passwords, no easy strings." The whole binary boils down to one strcmp(input, transform(input)) — the password is a fixed point of its own check, and once you see the XOR identity that makes that possible, the binary hands you not one valid password but two hundred and fifty-six.

The target

The challenge is selfkey by oqra1, uploaded 2026-06-02 to crackmes.one (C/C++, x86-64, Unix/Linux, community difficulty 3.0, 0 writeups at the time of writing). The author's blurb sets the tone:

a simple crackme with a twist. no plaintext passwords, no easy strings. figure out the algorithm and find the input that satisfies it. your objective is to find the correct password and trigger this message: You cracked the password

The artefact:

$ sha256sum selfkey
a72548568e0634d3e148eec7d3fe98f9d65476e942996054323f3096955abbbc  selfkey
$ file selfkey
selfkey: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
  dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
  BuildID[sha1]=7e45a81f631305d844fa74475f17b2a1a7ab3637,
  for GNU/Linux 3.2.0, stripped
$ wc -c selfkey
14520 selfkey

A position-independent, dynamically-linked, stripped x86-64 ELF. 14520 bytes — almost all of which is the standard CRT scaffolding glibc bolts onto any C program. The actual logic, as we'll see, is two functions totalling about 270 bytes of machine code.

The first 64 bytes are an unremarkable ELF header — e_type = 0x0003 (ET_DYN, i.e. PIE), entry at 0x1130:

00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
00000010: 0300 3e00 0100 0000 3011 0000 0000 0000  ..>.....0.......
00000020: 4000 0000 0000 0000 7831 0000 0000 0000  @.......x1......
00000030: 0000 0000 4000 3800 0e00 4000 1d00 1c00  [email protected]...@.....

First impressions

Run it cold to learn the I/O contract:

$ ./selfkey
usage: ./selfkey <password>
$ ./selfkey test
Wrong password
$ ./selfkey hello123
Wrong password

One command-line argument, a binary accept/reject. No file reads, no network, no environment variables — strace shows nothing but the loader bringing in libc and a single write of "Wrong password". So everything that matters is computed in-process from argv[1].

The author claimed "no easy strings," but strings -n4 is still the fastest orientation tool we have:

usage: %s <password>
Wrong password
You cracked the password
Great job!!
yGn}jaGkljwv
Ghyjwv
Ghykkowj|-(/
;*3$"

The three prompt strings are exactly what you'd expect. The interesting part is the four-line block of garbage that follows — yGn}jaGkljwv, Ghyjwv, Ghykkowj|-(/. That's the author's "twist": the answer is in the binary, but it's been smeared so that strings (and a naive strcmp hunt) won't recognise it. Those lines are not three separate strings — they're one 25-ish byte blob that strings chopped at the bytes that happen to be non-printable (0x7f DEL, 0x01, 0x1b ESC). Hold that thought.

The dynamic imports tell us the shape of the check before we read a single instruction:

$ r2 -qc 'aaa; afl' selfkey
0x00001030  sym.imp.free
0x00001040  sym.imp.puts
0x00001050  sym.imp.strlen
0x00001060  sym.imp.printf
0x00001070  sym.imp.strcmp
0x00001080  sym.imp.malloc
0x00001090  sym.imp.exit
0x000010b0  main
0x00001220  fcn.00001220

malloc + strlen + strcmp + free, and exactly two non-library functions: main (0x10b0) and an unnamed helper at 0x1220. The hypothesis writes itself: main calls the helper to derive something from the input, then strcmps the input against it. Let's confirm.

Static pass: main

Here is main in full, disassembled with radare2 5.x (pdf @ main), annotated block by block. I've stripped the ANSI colour and the raw opcode columns for readability; every address is real.

;-- main (0x000010b0), 115 bytes
push  rbp
push  rbx
sub   rsp, 8
cmp   edi, 2                 ; argc == 2 ?
jne   0x1108                 ; no  -> print usage, exit(1)
mov   rbp, [rsi + 8]         ; rbp = argv[1]   (the password)
mov   rdi, rbp               ; arg = argv[1]
call  fcn.00001220           ; rax = transform(argv[1])   <-- the helper
mov   rdi, rbp               ; s1 = argv[1]
mov   rsi, rax               ; s2 = transform(argv[1])
mov   rbx, rax               ; keep the malloc'd pointer for free()
call  sym.imp.strcmp         ; strcmp(argv[1], transform(argv[1]))
mov   rdi, rbx
mov   ebp, eax               ; ebp = strcmp result
call  sym.imp.free           ; free(transform result)
test  ebp, ebp               ; strcmp == 0 ?
je    0x10f8                 ; equal -> success
lea   rdi, str.Wrong_password ; 0x201a "Wrong password"
call  sym.imp.puts
; ---- 0x10ef: common tail ----
add   rsp, 8
xor   eax, eax
pop   rbx
pop   rbp
ret
; ---- 0x10f8: success ----
lea   rdi, str.You_cracked_the_password...  ; 0x2030
xor   eax, eax
call  sym.imp.printf
jmp   0x10ef
; ---- 0x1108: argc != 2 ----
mov   rsi, [rsi]             ; argv[0]
lea   rdi, str.usage:__s__password__n       ; 0x2004 "usage: %s <password>\n"
xor   eax, eax
call  sym.imp.printf
mov   edi, 1
call  sym.imp.exit           ; exit(1)

The control flow is exactly the hypothesis, and it tells us the entire win condition in one line:

if (strcmp(argv[1], transform(argv[1])) == 0)  // <-- you win

The password P is accepted iff transform(P) == P — iff P is a fixed point of transform. That's the meaning of the name selfkey: the key is whatever value maps to itself under the transform. There's no stored "correct password" to compare against; the binary derives its expectation from your own input. So the whole game is: understand transform, then solve transform(P) = P.

The dispatch / the algorithm: transform() at 0x1220

This is the heart of the binary. 156 bytes. Disassembly via r2 -qc 'aaa; s 0x1220; pdf', annotated:

;-- fcn.00001220 (transform), 156 bytes.  rdi = input string
push  rbp
push  rbx
mov   rbx, rdi               ; rbx = input
mov   edi, 0x1a              ; 26
sub   rsp, 8
call  sym.imp.malloc         ; rax = malloc(26)   -> result buffer
movdqa xmm0, [0x2060]        ; load 16 const bytes  (block A)
mov   rdi, rbx               ; rdi = input  (for strlen below)
mov   byte [rax + 0x19], 0   ; result[25] = '\0'   (NUL terminator)
mov   rbp, rax               ; rbp = result
movups [rax], xmm0           ; result[0..15]  = block A
movdqa xmm0, [0x2070]        ; load 16 const bytes  (block B)
movups [rax + 9], xmm0       ; result[9..24]  = block B  (overwrites 9..15)
call  sym.imp.strlen         ; rax = strlen(input)
test  rax, rax
je    0x12b8                 ; empty input -> dl = 0
mov   rdi, rbx               ; rdi = input
lea   rcx, [rbx + rax]       ; rcx = input + len  (end pointer)
xor   edx, edx               ; dl  = 0     (accumulator)
test  al, 1                  ; len odd?
je    0x1280                 ; even -> straight to pair loop
add   rdi, 1
movzx edx, byte [rbx]        ; dl = input[0]   (seed for odd length)
cmp   rdi, rcx
je    0x128e                 ; len == 1 -> done accumulating
; ---- 0x1280: XOR every byte into dl, two at a time ----
xor   dl, byte [rdi]         ; dl ^= input[i]
add   rdi, 2
xor   dl, byte [rdi - 1]     ; dl ^= input[i+1]
cmp   rdi, rcx
jne   0x1280
; ---- 0x128e: fold dl into the whole result buffer ----
xor   byte [rbp], dl         ; result[0] ^= dl
lea   rcx, [rbp + 0x19]      ; end = result + 25
lea   rax, [rbp + 1]         ; p   = result + 1
; ---- 0x12a0: result[1..24] ^= dl, two at a time ----
xor   byte [rax], dl
xor   byte [rax + 1], dl
add   rax, 2
cmp   rax, rcx
jne   0x12a0
add   rsp, 8
mov   rax, rbp               ; return result
pop   rbx
pop   rbp
ret
; ---- 0x12b8: empty-input branch ----
xor   edx, edx               ; dl = 0
jmp   0x128e

Three phases, and each one is simple once you isolate it.

Phase 1 — build a 25-byte constant C. It mallocs 26 bytes, NUL-terminates index 25, then splats a fixed constant into result[0..24] using two overlapping 16-byte SSE stores:

• movups [rax] writes bytes 0..15 from the 16-byte block at 0x2060.
• movups [rax+9] writes bytes 9..24 from the 16-byte block at 0x2070.

The second store overwrites result[9..15]. That's only safe because the author arranged the two source blocks so the overlap is byte-identical — and indeed it is (see the table below). The net result is a deterministic 25-byte constant I'll call C.

Phase 2 — fold the input into one byte dl. The loop at 0x1280 walks the input and XORs every byte into dl. The odd-length preamble seeds dl = input[0] and then the pair loop chews through the rest two at a time; the even-length path starts from dl = 0. Either way the post-condition is the same:

dl = input[0] ^ input[1] ^ ... ^ input[len-1]    (XOR of all input bytes)

The two-at-a-time unrolling is just the compiler (GCC 14.2.0, per the .comment section) being clever; semantically it's a plain XOR-reduce.

Phase 3 — XOR the constant with dl. result[0] ^= dl followed by the loop at 0x12a0 doing result[1..24] ^= dl means every byte of C gets XORed with the single byte dl. Then it returns the buffer.

So, in one line:

transform(input) = C ^ XOR_reduce(input)      (byte-wise broadcast XOR)

where C is the 25-byte embedded constant and XOR_reduce collapses the whole input to one byte.

The data table: the constant C

The two SSE source blocks live in .rodata at file offsets 0x2060 and 0x2070 (the .rodata segment is mapped 1:1, so vaddr == file offset here):

00002060: 7947 6e7d 6a61 476b 6c6a 7776 7f47 6879  yGn}jaGkljwv.Ghy   <- block A
00002070: 6a77 767f 4768 796b 6b6f 776a 7c2d 282f  jwv.Ghykkowj|-(/   <- block B

Reassembling per the store layout — C[0..8] from block A, C[9..24] from block B — gives the full 25-byte constant. Here it is byte-by-byte, which is also the "smeared" blob strings showed us:

idx	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24
hex	79	47	6e	7d	6a	61	47	6b	6c	6a	77	76	7f	47	68	79	6b	6b	6f	77	6a	7c	2d	28	2f
chr	y	G	n	}	j	a	G	k	l	j	w	v	DEL	G	h	y	k	k	o	w	j	|	-	(	/

A sanity check on the overlap: block A's bytes 9–15 are 6a 77 76 7f 47 68 79, and block B's bytes 0–6 are 6a 77 76 7f 47 68 79. Identical — so the overlapping movups is well-defined, exactly as the author intended.

C = 79 47 6e 7d 6a 61 47 6b 6c 6a 77 76 7f 47 68 79 6b 6b 6f 77 6a 7c 2d 28 2f (hex), 25 bytes.

The identity that breaks it

We need P with transform(P) = P, i.e.

P[i] = C[i] ^ k   for all i,   where  k = XOR_reduce(P)

Substitute P[i] = C[i] ^ k back into the definition of k. XOR is associative and commutative, so XORing 25 bytes that each equal C[i] ^ k gives:

k = ⊕_{i=0}^{24} (C[i] ^ k)
  = (⊕_i C[i]) ^ (k XORed 25 times)
  = (⊕C) ^ k          because 25 is odd, so k folds in once

Cancel k from both sides:

⊕C = 0

That's the punchline. The self-consistency condition is a property of the constant, not of k. If the XOR of all 25 constant bytes is zero, then the equation k = (⊕C) ⊕ k is satisfied for every value of k — meaning every byte value 0..255 you pick gives a valid password P = C ^ k, as long as C ^ k contains no NUL (a NUL would truncate argv[1] and break the length match).

So: does ⊕C = 0? Let me fold the table:

79^47^6e^7d^6a^61^47^6b^6c^6a^77^76^7f^47^68^79^6b^6b^6f^77^6a^7c^2d^28^2f
= 0x00

It is zero. The author built C precisely so that it XOR-reduces to zero, which is what guarantees the fixed point exists in the first place — and, as a side effect, hands the cracker a 256-strong family of valid passwords. The graph below is the whole computation; the loop from dl back into the comparison is the fixed-point knot.

A worked example, traced live in gdb

Among the 256 candidates, one is obviously the author's intended answer because it's human-readable. Solving P = C ^ k for the k that yields ASCII gives k = 0x18, and:

P = a_very_strong_password507

Count the characters: a_very_strong_password507 is 25 bytes — matching the 25-byte constant exactly. And the XOR of its bytes is 0x18, which is the very k we used to derive it. It's self-consistent by construction.

Rather than take the algebra's word for it, here's the binary computing dl and the transform result under gdb. The harness can't disable ASLR (no CAP_SYS_ADMIN in the sandbox), and run re-randomises the PIE base, so the trick is to launch with starti <arg>, read the load base from /proc/<pid>/maps, set breakpoints relative to that base, and continue — never calling run again. The script:

set pagination off
starti a_very_strong_password507
python
inf = gdb.selected_inferior()
base = None
with open(f"/proc/{inf.pid}/maps") as f:
    for line in f:
        if "selfkey" in line and base is None:
            base = int(line.split('-')[0], 16)
gdb.execute(f"set $base = {base}")
end
break *($base + 0x128e)   # just after dl is fully accumulated
break *($base + 0x10d0)   # the strcmp call in main
continue
printf "dl = 0x%x\n", (unsigned char)$rdx
continue
printf "s1 (input)  = %s\n", $rdi
printf "s2 (result) = %s\n", $rsi
x/25xb $rdi
x/25xb $rsi
continue
quit

And the output:

BASE = 0x5d8f882f9000
Breakpoint 1, 0x00005d8f882fa28e in ?? ()
==> at 0x128e: dl (XOR of all input bytes) = 0x18
    rbp (result buffer ptr) = 0x5d8f8d0fd310

Breakpoint 2, 0x00005d8f882fa0d0 in ?? ()
==> at strcmp call:
    s1 rdi (input)            = a_very_strong_password507
    s2 rsi (transform result) = a_very_strong_password507
input  bytes:
0x7ffd5d7c8d9c: 0x61 0x5f 0x76 0x65 0x72 0x79 0x5f 0x73
0x7ffd5d7c8da4: 0x74 0x72 0x6f 0x6e 0x67 0x5f 0x70 0x61
0x7ffd5d7c8dac: 0x73 0x73 0x77 0x6f 0x72 0x64 0x35 0x30
0x7ffd5d7c8db4: 0x37
result bytes:
0x5d8f8d0fd310: 0x61 0x5f 0x76 0x65 0x72 0x79 0x5f 0x73
0x5d8f8d0fd318: 0x74 0x72 0x6f 0x6e 0x67 0x5f 0x70 0x61
0x5d8f8d0fd320: 0x73 0x73 0x77 0x6f 0x72 0x64 0x35 0x30
0x5d8f8d0fd328: 0x37
You cracked the password
Great job!!

Phase 2 produced dl = 0x18 exactly as predicted. Phase 3 turned the constant C into C ^ 0x18, which is byte-for-byte the input. strcmp returns 0; main takes the success branch. Let me trace a single byte by hand to nail it down:

• C[0] = 0x79 ('y'), k = 0x18 → 0x79 ^ 0x18 = 0x61 = 'a'. ✓ (first byte of a_very_...)
• C[2] = 0x6e ('n'), → 0x6e ^ 0x18 = 0x76 = 'v'. ✓
• C[12] = 0x7f (DEL), → 0x7f ^ 0x18 = 0x67 = 'g'. ✓ (the byte that made strings flinch becomes the 'g' in "strong")

The "no easy strings" claim was true only because each constant byte was pre-XORed by 0x18; recover k and the plaintext falls out.

And the live binary agrees on both the intended key and an arbitrary alternate from the family (k = 0x04):

$ ./selfkey 'a_very_strong_password507'
You cracked the password
Great job!!
$ ./selfkey '}CjyneCohnsr{Cl}ooksnx),+'    # k = 0x04
You cracked the password
Great job!!
$ ./selfkey 'a_very_strong_password508'    # one byte off
Wrong password

The keygen (Python re-implementation)

This is the ground-truth port. It rebuilds C exactly the way fcn.00001220 does (overlapping stores included), proves ⊕C = 0, enumerates the entire valid-password family, and live-tests against the binary. It's the whole solver, and it's short because the algorithm is:

#!/usr/bin/env python3
# selfkey keygen / analysis
# Reconstructs the 25-byte constant C exactly as fcn.00001220 builds it:
#   result[0..15]  = mem[0x2060..0x206F]   (movups [rax],   xmm0)
#   result[9..24]  = mem[0x2070..0x207F]   (movups [rax+9], xmm0)  (overwrites 9..15)
import subprocess, functools

load1 = bytes([0x79,0x47,0x6e,0x7d,0x6a,0x61,0x47,0x6b,0x6c,0x6a,0x77,0x76,0x7f,0x47,0x68,0x79]) # 0x2060
load2 = bytes([0x6a,0x77,0x76,0x7f,0x47,0x68,0x79,0x6b,0x6b,0x6f,0x77,0x6a,0x7c,0x2d,0x28,0x2f]) # 0x2070

res = bytearray(25)
res[0:16]   = load1          # write 0..15
res[9:9+16] = load2          # write 9..24 (overlap is identical by design)
C = bytes(res)

x = functools.reduce(lambda a, b: a ^ b, C, 0)
print("C (25 bytes) hex:", C.hex())
print("C repr        :", repr(C))
print("XOR of all C  :", hex(x), "(0 => C is a self-key)")

def transform(inp: bytes) -> bytes:
    dl = functools.reduce(lambda a, b: a ^ b, inp, 0)   # phase 2: XOR-reduce
    return bytes(c ^ dl for c in C)                     # phase 3: broadcast XOR

# Keygen: for every k that yields no NUL byte, P = C ^ k is a valid password.
print("\nValid passwords P = C ^ k  (k = XOR of P):")
for k in range(256):
    P = bytes(c ^ k for c in C)
    if 0 in P:                       # NUL would truncate argv -> skip
        continue
    if transform(P) == P:            # fixed-point check
        printable = all(32 <= b < 127 for b in P)
        if k == 0 or printable:
            tag = "  <-- fully printable" if printable else ""
            ascii_ = ''.join(chr(b) if 32 <= b < 127 else '.' for b in P)
            print(f"  k={k:#04x}  P={P.hex()}  ascii={ascii_}{tag}")

print("\n--- live test against ./selfkey ---")
r = subprocess.run(["./selfkey", C], capture_output=True, cwd="/labs-output")
print(f"k=0x00 (C itself): stdout={r.stdout!r} rc={r.returncode}")

Running it prints the constant, confirms the XOR identity, and dumps the family. An excerpt of the printable members:

C (25 bytes) hex: 79476e7d6a61476b6c6a77767f4768796b6b6f776a7c2d282f
C repr        : b'yGn}jaGkljwv\x7fGhykkowj|-(/'
XOR of all C  : 0x0 (0 => C is a self-key)

Valid passwords P = C ^ k  (k = XOR of P):
  k=0x00  P=...  ascii=yGn}jaGkljwv.Ghykkowj|-(/
  k=0x04  P=...  ascii=}CjyneCohnsr{Cl}ooksnx),+  <-- fully printable
  k=0x05  P=...  ascii=|BkxodBniorszBm|nnjroy(-*  <-- fully printable
  ...
  k=0x18  P=...  ascii=a_very_strong_password507  <-- fully printable
  k=0x19  P=...  ascii=`^wdsx^rusnof^q`rrvnse416  <-- fully printable
  ...
--- live test against ./selfkey ---
k=0x00 (C itself): stdout=b'You cracked the password\nGreat job!!\n\x07' rc=0

Two facts worth dwelling on. First, k = 0x00 works — meaning C itself, the raw constant straight out of .rodata (yGn}jaGkljwv\x7fGhykkowj|-(/, DEL byte and all), is a valid password. It's annoying to type because of the control byte, but it proves the fixed point isn't a fluke: the constant maps to itself because ⊕C = 0, and the binary literally ships its own answer in cleartext if you know to read those "garbage" strings as the password. Second, the human-readable a_very_strong_password507 at k = 0x18 is clearly the intended solution — but the math never singled it out. The XOR-reduce design accidentally turned a single-password crackme into a 256-password one.

An alternate bypass: the one-byte patch

Recovering the password is the clean win, but the brief also accepts a patched binary, and selfkey makes that a one-byte edit. In main, the decision is:

0x000010df  test ebp, ebp        ; strcmp result
0x000010e1  je   0x10f8          ; 74 15  -> jump to success if equal

74 is JE (jump if zero). Change it to EB (JMP, unconditional) and the success branch is taken regardless of the comparison:

$ printf '\xeb' | dd of=selfkey.patched bs=1 seek=$((0x10e1)) count=1 conv=notrunc
$ xxd -s 0x10e1 -l 2 selfkey.patched     # was 7415
000010e1: eb15
$ ./selfkey.patched anything_at_all
You cracked the password
Great job!!
$ ./selfkey.patched x
You cracked the password
Great job!!

74 → eb at file offset 0x10e1. Any input now passes. (Inverting the test instead — je → jne — would reject everything, which is the opposite of what we want; the unconditional jmp is the right edit.)

Things that didn't pan out

A couple of dead ends, for honesty's sake:

• r2's Ghidra decompiler. I reached for pdg (the r2ghidra plugin) to get a C-level view of transform to cross-check my read of the SSE stores. It isn't installed in this image: both pdg @ 0x1220 and pdg @ main returned NO_PDG. Fell back to the native pdf disassembly above, which is the citation for every asm block in this post.
• Ghidra headless. I then tried the real thing — analyzeHeadless with a DecompInterface post-script targeting 0x1220 and main. It ran past the 10-minute tool timeout without emitting any decompilation (import/analysis on this image is slow under the sandbox), so I killed it. Not a blocker: the function is 156 bytes and the three-phase structure is unambiguous from the disassembly plus the gdb trace, and the Python port reproduces the binary's output byte-for-byte, which is the real proof.
• Hunting for a stored password string. The obvious first move on any crackme is strings | grep-ing for the answer. Here it genuinely fails — the closest thing to a password is yGn}jaGkljwv..., which is the XOR-masked constant, not plaintext. The author earned the "no easy strings" claim; you have to recover k to see the cleartext. That ruled out a pure-strings solution and pointed straight at the transform.

What the author says

There is no official solution shipped with this crackme and 0 community writeups existed when I solved it, so there's nothing to compare against beyond the author's one-line description. Measured against that description — "figure out the algorithm and find the input that satisfies it" — the reconstruction matches the design intent exactly: the algorithm is transform(P) = C ^ XOR_reduce(P), the input that satisfies transform(P) = P is a_very_strong_password507, and the structural reason it exists is ⊕C = 0.

If anything, the independent analysis surfaced a subtlety the author may not have advertised: because the fixed-point condition collapses to a property of the constant (⊕C = 0) rather than of the key, every byte mask k produces a valid password. The intended a_very_strong_password507 is just the one member of a 256-element solution set that happens to spell something. A stricter design would have compared against a stored H(P) so that only one preimage works; tying the expected value to XOR_reduce(input) over an odd-length, zero-summing constant is what opens the floodgate.

References

• Target: selfkey by oqra1 — https://crackmes.one/crackme/6a1f01752b3df128c1df5d6e (SHA-256 a72548568e0634d3e148eec7d3fe98f9d65476e942996054323f3096955abbbc)
• radare2 (aaa, pdf, px) for disassembly and the constant dump
• gdb with starti-relative breakpoints to read dl and the transform buffer under ASLR
• GCC 14.2.0 (Debian 14.2.0-19) — per the binary's .comment section — is what unrolled the XOR-reduce into the two-at-a-time loops

Artefacts

The download tarball contains the original selfkey binary, the selfkey.patched one-byte bypass, keygen.py (the full solver/keygen above), and trace.gdb (the live tracer). Everything needed to reproduce the analysis is inline in this post.