CrackMe 02 - I need to be honest

source
pipedown's I need to be honest
platform
Linux
architecture
x86
bitness
64-bit
format
ELF64
written in
Assembly
difficulty
very easy
tools
Ghidra
approach
mostly static
date
2026-07-28

First look at the binary

64-bit ELF, not stripped. All symbol names are present.

The strings in .data have no null terminator, so Ghidra did not mark them as strings and left them as raw bytes.

Finding the check

The password check is a loop with a counter.

AL holds the input byte, BL the reference byte, compared directly. The counter runs to 27, then the code jumps to verify_checksum.

Marking the bytes in Ghidra as a string gives SecurePass_2k26_X64_Reverse.

password_verify_loop:
    CMP    RCX, 0x1b                        ; counter against 27
    JGE    verify_checksum
    MOV    AL, byte ptr [RCX + input_buffer] ; byte of user input
    MOV    RBX, actual_password
    MOV    BL, byte ptr [RBX + RCX*0x1]      ; byte of the real password
    CMP    AL, BL
    JNZ    stage_fail
    MOVZX  RAX, AL
    ADD    R8, RAX                           ; accumulate the sum
    INC    RCX
    JMP    password_verify_loop

How the verification works

Two stages: byte-by-byte comparison, then a checksum of the accumulated sum.

The flags are then XOR-decrypted and printed. The keys are hardcoded in the instructions right before each call: 0x47, 0x5A, 0x6C.

Unused parts

I also noticed strange constants magic1, magic2, magic3 (0xDEADBEEFCAFEBABE, 0xFEEDFACEDEADC0DE, 0xACCEFADEDEADBEEF). Nothing references them.

Result

Password: SecurePass_2k26_X64_Reverse

Flags:
CRYPTO_KEY_ALPHA_2026
REVERSE_ENGINEERING_CHALLENGE
MEMORY_HIDDEN_GAMMA_X64
Result in terminal
Result in terminal

Takeaway

I didn't understand why the checksum was needed, since the input is already compared byte by byte.

← all writeups

Written with the help of AI, based on my own analysis and notes.