| Very easy disassembly execise |
Static analysis of the main function shows a simple hardcoded comparison with value 124816. Password = 124816. |
| emulation loader |
# 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
|