CodeGate CTF 2014 - Reverse 250 Clone Technique Write-up

Hi,
The concept of this Crackme is really simple but reaching the right Track took me hours and hours because I was looking deeper into it and the answer was right in front of me :) ...
The challenge is named "Clone Technique" used in Naruto Manga ,  the process creates many instances of it (using CreateProcessW) with different command line arguments (3 values).
Example :
2nd process : clone_technique.exe 3026539702 3580248161 2
3rd process : clone_technique.exe 466510610 2867152813 3
4th process : clone_technique.exe 2580226910 609694577 4

The wrong way that I took was fortunately of some benefit because what I did is analyze how the values are generated and I also simulated the algorithm in ASM (check links below).
In the first place I didn't know how the flag would be and I couldn't get any hints so I tried to look and look until I found this weird string in the .data section :

I've put a breakpoint on access to this string and ran the program, then the debugger breaks at a function at : 00401070 (you can also check all the references to this string and you'll find the "push 00407030" to our function).
This function takes 3 arguments : - the first value in the cmdline , the second value and a pointer to the string.
The function will use both values in a loop to decrypt each byte alone of the string and store it in a seperated memory location pointed by EDX using the instruction :
004010E8  |. 8802           |MOV BYTE PTR DS:[EDX],AL
The function returns a pointer to the decrypted string in EAX (the decryption result will be non-ASCII until the used values -keys- are right).

If you have a clear idea now , you will notice that each process will be created with its own cmd line arguments , thus different keys to decrypt the string , thus different result. So we'll need to show the final decrypted string for each process until finding a readable ASCII string.
We'll need to patch the executable and create a code cave which will pop up a MessageBox whenever the string is decrypted (we can also display only the ASCII compatible string which will only be the flag) . I was lazy and tired so , I just put a MessageBox call and kept pressing enter until seeing the flag :

Jump to code cave

 

 We don't have to forget to NOP a "REP STOS" instruction that will cause an access violation after redirecting the execution to our cave code.

Now save the executable , run it and you should see MessageBoxes with total gibberish (invalid key decrypting the string) , keep clicking and clicking and clicking until this will popup :

The Flag.

Script which will generate the same values passed in the command line (complete waste of time :) ) : http://pastebin.com/tcRdpEKF

Crackme Download : https://www.mediafire.com/?bbqubxv3maev71x

Regards.

Anti-debugging trick - Checking for the Low Fragmentation Heap

Hi everyone,

I'll introduce you today a Anti-debugging trick which the idea came across my mind while debugging Windows Heap, I don't know if it was used before anywhere but here I am showing it today.

Check the C/C++ source code : http://pastebin.com/pacrKh0z

Short introduction to the Windows front end allocator :

Yesterday I promised writing something related to the windows heap manager and an opportunity came now to discuss some of the front end allocator aspects.
First of all let me define what a LFH (low fragmentation heap) is :
The LFH was introduced in Windows XP and Windows Server 2003 but it wasn't used as a default front end allocator until Windows Vista. The default front end allocator were the lookaside lists (LAL) , each of these 2 is a singly linked list with 128 lists.

The LFH as its name describes is implemented to guarantee that heap fragmentation will be reduced and it's strongly recommended to use for application that allocate a big number of small size blocks.
When the LFH is created first, predetermined sizes of memory will be allocated and put into buckets (LFH lists), when the application will call for an allocation the LFH will provide the smallest available block to satisfy the allocation , otherwise the request will be passed into the heap manager then to the Freelists (check explanation later).

When LAL is used as a front end allocator, a block won't reside in a list of its list until it was allocated either from the FreeLists or by committing memory then freed. All that won't apply until a list of the lookaside table can handle the freed block otherwise it will passed to the Heap manager to perform coalescing if two adjacent blocks are free, update the FreeList bitmap values (if necessary), invalidate coalesced blocks entries then insert the coalesced block into its valid list in the FreeLists. If no block coalescing is possible the block is inserted directly in the FreeLists.

Anti-Debugging Trick :

I noticed that when the executable is run under a debugger no Low Fragmentation Heap (LFH) is created for it so the pointer to the LFH equals NULL.
So we'll just have to check if the pointer to LFH is null to detect if the process was created inside a debugger.
I tried after to run the process outside the debugger then attach it and I noticed that a LFH is created for the heap and the pointer to the LFH is valid.
 The pointer to the LFH is located at "heap_handle+0xd4" under Windows 7 for WOW64 executables and at "heap_handle+0x178" for 64-bit executable.

I attached the debugger to the process :
0:001> dt _HEAP 00460000
ntdll!_HEAP
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 SegmentSignature : 0xffeeffee
   +0x00c SegmentFlags     : 0
[...]
   +0x0d0 CommitRoutine    : 0x5b16148e
   +0x0d4 FrontEndHeap     : 0x00468cf0 Void
   +0x0d8 FrontHeapLockCount : 0
   +0x0da FrontEndHeapType : 0x2 <-- Type : LFH
   +0x0dc Counters         : _HEAP_COUNTERS
   +0x130 TuningParameters : _HEAP_TUNING_PARAMETERS

When running the process from the debugger LFH won't be enabled :
0:001> dt _HEAP 00320000
ntdll!_HEAP
   +0x000 Entry            : _HEAP_ENTRY
   +0x008 SegmentSignature : 0xffeeffee
   +0x00c SegmentFlags     : 0
[...] 
   +0x0cc LockVariable     : 0x00320138 _HEAP_LOCK
   +0x0d0 CommitRoutine    : 0x6d58ec0e     long  +6d58ec0e
   +0x0d4 FrontEndHeap     : (null)
   +0x0d8 FrontHeapLockCount : 0
   +0x0da FrontEndHeapType : 0
   +0x0dc Counters         : _HEAP_COUNTERS
   +0x130 TuningParameters : _HEAP_TUNING_PARAMETERS

Remember that, The LFH isn't used by default until Windows Vista and posterior versions , so to implement the anti-debugging technique under Windows XP we'll need to enable the LFH as it's not used by default, to do so you'll simply need to call HeapSetInformation with the HEAP_INFORMATION_CLASS set to 0 and with the pointer to the information buffer pointing to "0x2" which will enable the LFH for the heap passed as the first argument.

A simple way to bypass this technique is simply by attaching the debugger to the application instead of running it from a debugger :) .

More details on the LFH : here

Thanks for your time :)
Souhail Hammou. @Dark_Puzzle