crackmes.one

Writeup for emulation loader

Author: karabatik
Date: 2025-08-18 10:29
Summary: # CrackM Writeup - karabatik ## Overview This writeup details the solution for the `crackmemain.exe` CrackMe challenge. The binary implements function pointer obfuscation and anti-debugging techniques, making it an interesting reverse engineering exercise. ## Initial Analysis ### File Information - **Filename**: crackmemain.exe - **Size**: 0xCE00 (52,736 bytes) - **MD5**: 592f7a190c872f6091dfad0e4fb9ee61 - **Architecture**: x64 Windows PE - **Base Address**: 0x140000000 - **Entry Point**: 0x14000a280 ### Runtime Behavior Running the executable shows a simple login prompt: ``` **********Welcome to CrackMe Loader..... Enter Login: test Enter Password: password Fail! Total pause: 0ms Press Enter to exit... ``` ## Static Analysis with IDA Pro ### Main Function Analysis The main function is located at `0x140001ab0` and contains several interesting features: 1. **Function Pointer Obfuscation**: All function calls are obfuscated using a magic number `0x2CC634AC8CA6AD95` 2. **Anti-Debug Protection**: Multiple conditional checks against global variables 3. **String Encryption**: All strings are encrypted and decrypted at runtime ### Key Functions Identified - `0x140001ab0` - Main function (1466 bytes) - `0x140002070` - Dynamic API loading - `0x140002600` - Anti-debug mechanism with 5x500ms delays - `0x140002d30` - **Validation function (TARGET)** - `0x140001230` - String processing utilities ### Deobfuscating Function Pointers The obfuscated function pointers follow this pattern: ```c ((void (*)(void))((char *)off_14000D150 - 0x2CC634AC8CA6AD95LL))() ``` To deobfuscate: `real_address = obfuscated_pointer - 0x2CC634AC8CA6AD95` ## Deep Dive: Validation Function ### Function Analysis The critical validation logic resides in `sub_140002D30`. After decompiling, the function reveals: ```c strcpy(v43, "panhauzer"); // Expected login strcpy(v42, "2digboob"); // Expected password ``` The function performs complex string comparison using regex-like pattern matching, but ultimately returns: - `1` for successful authentication - `0` for failed authentication ### Hardcoded Credentials Through static analysis, I discovered the valid credentials: - **Login**: `panhauzer` - **Password**: `2digboob` However, testing these credentials would be the "intended" solution. Instead, I chose a more elegant approach. ## Solution: Binary Patching ### Approach Rather than finding the exact password, I decided to patch the validation function to always return success. This demonstrates a common real-world attack vector. ### Patch Implementation **Target Address**: `0x140002d30` (start of validation function) **Original bytes**: ``` 41 57 41 56 56 57 ... (complex validation logic) ``` **Patched bytes**: ``` B8 01 00 00 00 C3 ``` **Assembly equivalent**: ```assembly mov eax, 1 ; Return success (1) ret ; Exit function immediately ``` ### Patching Process 1. Navigate to address `0x140002d30` in IDA Pro 2. Switch to Hex View 3. Press `F2` to enter edit mode 4. Replace the first 6 bytes: `41 57 41 56 56 57` → `B8 01 00 00 00 C3` 5. Press `F2` to exit edit mode 6. Save the patched binary ## Results After applying the patch, any login/password combination is accepted: ``` **********Welcome to CrackMe Loader..... Enter Login: anything Enter Password: whatever DLL Inject Success! [EMU] Total pause: 0ms Press Enter to exit... ``` The success message "DLL Inject Success! [EMU]" confirms the bypass worked perfectly. ## Alternative Solutions ### Method 1: Using Hardcoded Credentials The "intended" solution would be using the discovered credentials: - Login: `panhauzer` - Password: `2digboob` ### Method 2: Runtime Patching Instead of modifying the binary, one could: - Use a debugger to set breakpoint at `0x140002d30` - Modify the EAX register to return 1 - Continue execution ### Method 3: DLL Injection Advanced users could inject a DLL to hook the validation function and force it to return success. ## Technical Insights ### Anti-Analysis Techniques Observed 1. **Function Pointer Obfuscation**: Makes static analysis more difficult 2. **String Encryption**: Hides meaningful strings from basic analysis 3. **Anti-Debug Delays**: 5x500ms delays slow down dynamic analysis 4. **Complex Control Flow**: Multiple nested loops and conditions ## Tools Used - **IDA Pro 9.0**: Static analysis and disassembly - **Hex Editor**: Binary modification --- **Author**: karabatik **Date**: 08/18/2025 **Difficulty**: 4/10 **Primary Technique**: Binary Patching

Loading writeup...