| Assembler Crackme |
2:27 AM 12/21/2025 |
x86 assembler crackme. Traced the password path from `ReadConsoleA` into the validation routine and identified an 8-byte memcmp-style loop against a static byte table. The correct password is the exact 8-byte sequence `@CBEDGFI` |
| Roullete Simulator |
9:21 AM 12/20/2025 |
Java roulette simulator. Decompiled with JADX and recovered a custom 16-bit PRNG used for win/loss. Brute-forced the PRNG seed from observed outcomes to predict future rounds, then used a betting strategy to grow balance until a 32-bit signed integer overflow flips it negative, satisfying the “win” condition. |
| Easiest |
6:01 AM 12/19/2025 |
Windows x86-64 crackme. Traced string references (e.g., `"Enter PIN:"`) in x64dbg back into `main`, identified the numeric PIN check, and patched/bypassed the failure path to reach the success branch and recover the correct input - 8569. |
| Easy crackme |
5:01 PM 12/17/2025 |
Java `.jar` crackme. Using JADX, I recovered `checkValidity()` which scores the 10-character key by counting how many characters satisfy `(ch & 3) == 0` (i.e., ASCII divisible by 4). A key is valid if the score is exactly 4. I also wrote a small Python keygen to generate valid keys. |
| crack the points |
11:54 AM 12/17/2025 |
Patch/trainer-style challenge: the program prints "Your count points is %d" with a hard-coded zeroed value. I located the call site in x64dbg/Ghidra and wrote a Python trainer that launches the process suspended, computes moduleBase + RVA, and patches the code to load a user-chosen value into EDX before the printf call. To make the patch robust, I used a trampoline and an allocated code cave (VirtualAllocEx) instead of guessing free space in .text. |
| puzzle |
1:48 AM 12/12/2025 |
Command-line crackme that hides both its console strings and password check behind a simple XOR-0x9F encoding layer. Using CFF Explorer and Detect It Easy (DIE) for static recon plus x64dbg breakpoints on WriteFile/ReadFile, I traced the input path to a 9-character length check and a character-by-character comparison against an XOR-decoded constant. By NOP-ing the failure branch and single-stepping the comparison loop, I recovered the cleartext password MYPASS123 and confirmed the same XOR-0x9F scheme is used to decode the “Hello World!”, “Enter password:” and “Access Granted/Denied!” strings at runtime. |
| KeyGenMeV3 |
2:14 AM 12/08/2025 |
My first keygen; Win32 GUI crackme with Name + Key validation. Used CFF Explorer for static analysis and x64dbg for dynamic analysis to trace the key validation algorithm. The program processes the name input through a semi-complex encoding function that uses different mixing operations for even/odd characters, involving ROL operations, XOR, and addition with constants. Reversed the algorithm and implemented a Python keygen that generates valid keys for any given name. |
| decode me |
4:43 PM 12/01/2025 |
Used x64dbg to analyze the main function, bypass a simple IsDebuggerPresent anti-debug check, and follow the calls that read, encode, and compare the user input. The program converts each character to a \xHH form using the format string "\\x%02X" and compares against a stored constant, revealing the correct password. |
| Ez Crackme |
10:50 PM 11/30/2025 |
Simple .NET console crackme. I used dnSpy to inspect Main, where the program compares Console.ReadLine() directly against a hard-coded string. The correct password is stored in plaintext, so no encoding or transformation was involved. |
| simple crackme |
9:02 AM 11/30/2025 |
A few months ago I decided to delve into the land of RE. This weekend I decided to put my big boi pants on, take what I've learned thus far, and endure the challenge of my first CTF.
Any constructive criticism on the writeup/solution, different approaches, and/or what I could have done better/differently would be greatly appreciated as I am still a scrub and have plenty to learn. :) |