Invisible Lookup Table Crackme

From UIC

WarrantyVoider's "The secret of the invisible lookup table" crackme

Invisible Lookup Table Crackme
Author:	ZaiRoN
Email:	zaironcrk(at)hotmail(dot)com
Website:	...
Date:	14/06/2006 (dd/mm/yyyy)
Level:
Language:	English
Comments:	...

Video allegato

Introduction

Nice crackme but unfortunately without a tutorial, only a keygen made by jB. The crackme is really nice so a tutorial should be written; that's why I decided to write it. To reverse engineer the crackme you have to use a ring0 debugger because a driver is part of it, this is not totally right because sometimes you can do all the work without a ring0 debugger; I'll show you that a little home made program would suffice. What I'm going to use is one of my personal tool slightly modified for the crackme requirements. The original tool is a system call hook detector (which it simply lists all the system calls trying to figure out which one is hooked or not (nothing special, internet is full of this kind of programs)) added with some features like the possibility to see the disasm of a function (I use my personal disasm engine) and something else you'll see later. Yes, you'll *see* because I decided to explain my work using a video... something unusual but I hope you'll like it.

Tools

• Ring0 debugger

Essay

As always my analysis starts looking at the file using Ida. One of the strings inside 'Strings' window captures my attention: "You rule! Please write a tutorial.". Let's see the code around the string:

Obviously, to find out all the informations I have used a debugger; Ollydbg works fine now. At this point I already have some questions in my mind. Who creates the file? The file named "l00KuPtAbl3" is not on my hard disk but the crackme wants to read something from it. I checked all the crackme trying to find a CreateFile call with CREATE_NEW or CREATE_ALWAYS flag without luck. Maybe there are some crypted parts... Hmmm, let's see the rest of the code, especially what is the value that is compared with CreateFile's return value (Instruction 401310) and where it comes from:

Some basic operations over the username, the value I'm looking for comes from the name's letters. I'm in front of a dilemma: 1. the file doesn't exist but CreateFile returns a handle (don't know if valid or not...) 2. the handle of the opened file should be equal to a value obtained from the name How is it possible??? The rules are pretty clear: "Write a keygen". An impossible crackme? No!

FhF shows me the way
I have to admit I spent some time trying to figure out what's really going on without luck. Only after some tries I came out with a good idea: what about to check if the crackme hooks a function? To find out the trick I used my system call hook detector.

Ok, time to play the video. To *synchronize* the tutorial with the video I'll use a time information, [start_time - end_time]. Below the time information I'll explain what is happened from start_time to end_time.

[00:00 - 00:13]
I always test crackme/worm/malware under a clean virtual machine, it means it's everything normal and untouched but as you can see from the video something is changed, there is a sys file with a suspicous name "ZLFBEQY" which is hooking something. You can read the address of the function, which is FA09C310. I'm almost sure the crackme made the hook but a closer look it's necessary. FhF has a disasm engine inside so the best thing to do is to disasm the function trying to figure out something interesting.

[00:14 - 00:29]
Clicking on the name I can dump the module (a very crude dump...) or disasm it directly from memory. I choose to disasm the module. The program doesn't disasm all the module but only some bytes, at the moment it ends when a 'RET' or an invalid instruction is found. In this case the disasm starts from address FA1C310 and ends at FA09C391 because the next instruction is an invalid instruction. You can disasm any address you like using the 'Disam from' box. The disasm view is the classical view containing informations about address, bytes, instruction and note. The disasm view reveals calls (in this case RtlUnicodeStringToAnsiString and strstr) and strings ("l00KuPtAbl3"). This last string is really interesting because now I'm sure, the crackme made the hook!

Code analysis
[00:30 - 00:46]
For the moment I can skip the first lines focusing on instruction at FA09C32D:

The call is used many times inside the crackme and it's something used for making our stepping session a little bit hard. From the current disasm view I can't see the content of the function because it has not been disasmed yet; a double click over the instruction and the function is disasmed:

As you can see the routine pops the return address from the stack, add 1 to the popped value and jump to the address. The routine forces the ret to return_address+1, and I think it's only used to obfuscate the code. So, I have:

[00:47 - 01:11]
At the beginning of the function (00:22) there's a call to RtlUnicodeStringToAnsiString, I don't know anything about it but if something goes in the wrong way I jump to FA09C44C:

The above code performs some final operations and if I reach this part of code something wrong happened. It's pretty easy to understand what it does and I only made a single comment at FA09C476 because I'll use it later, remember it!

[01:12 - 01:33]
Call FA09C304 is another function used to obfuscate the code:

The routine forces the ret to return_address+2 which is -in this case- FA09C348. As you can see the address is not visible from the disasm view because there is an instruction at FA09C347 and another one at FA09C349; I can make it visible btw. A right-click over an instruction opens a little menu containing the items: - "Copy selected lines": the item speaks itself, it copies the selected line(s) into the clipboard - "Undefine...": make all the instructions, from the selected instruction, undefined showing a single byte for every lines of the disasm view. Ida users should be familiar with this command. - "Disasm...": disasm the undefined instructions. - "Spy stack!": I'll show you later the meaning of this item. To make the instruction visible I need to do an undefine operation followed by a disasm operation. Look at the video, the result is in front of our face:

[01:34 - 01:59]
A check over the RtlUnicodeStringToAnsiString parameter. RtlUnicodeStringToAnsiString converts a unicode string into an ansi string. The destination string has the following structure:

Knowing the structure doesn't help me to much because I can't access the buffer and check what it's hiding. I can only say that the crackme checks the length of the buffer, nothing more. To gain more informations I need to explore the next instructions. Where will the jump bring me? A double click over the 'jb' instruction will lead me to the right place.

ANSI_STRING->Length field should be atleast 0x14 bytes but it's impossible to know what the ANSI_STRING->Buffer contains...

[02:00 - 02:47]
I have to analyse the *good boy* of the conditional jump:

Function strstr scans 1° string for the first occurrence of the 2° string. The 1° string is the one pushed at FA09C375 and for the moment I don't know what is it while the 2° string is "l00KuPtAbl3.". Do you remember the items inside the pop up menu? One of them is named 'Spy stack!' and it's time to use it. This feature is used when you need to know which kind of string is on the top of the stack at a certain address. FhF patches the original code of the program adding a call to DbgPrint which will print out the value I wanted to know. Supposing to insert 12345678 in the serial box here is what Dbgview prints: "Spy: \??\C:\DOCUME~1\massy\IMPOST~1\Temp\l00KuPtAbl3.12345678" The video is self explanatory. I know the string and I can disable the spy feature now. strstr returns a pointer to the serial. I already know the code at FA161442 and I can go on with the normal flow

[02:48 - 04:13]

Damn, another bug in my tool :p. Did you see it? Look at 03:33. It's not a big problem, only a little bug in the undefine function. Bug fixed but I didn't want to record everything once again, sorry. Back to the meaning of the routine. A simple routine used to convert the serial (8 digits at all in 0..9/A..F range) from string to dword saving the result inside the dword pointed by [ebp-4]. Once again the code is obfuscated using the same calls but it's pretty easy to understand it once you have figure out the right sequence of instructions.

[04:14 - 05:02]

I finally understand why the call to CreateFile returns a handle, even if the file doesn't exist. The returned value is obtained by the simple operations:

So, this is the scenario: the name is used to compute a value (call it valueFrom_Name) which is compared with the value returned as a fake file handle (call it valueFromSerial) from the driver; if equals you are registered. All the instructions used to obtain valueFromSerial are reversable so the only thing to do is to compute valueFromName, put it inside the reversed instructions and read the right serial. Valid combination: ZaiRoN - A996DEDB

Cheers, ZaiRoN

Note Finali

Tutorial ends here. You don't have FhF but you can follow the tutorial using a ring0 debugger, I used FhF because sometimes a better approach to a target is given by non standard tools. Yes, you can't write a new program for every crackme but if you have your own tools you can combine them together obtaining something usefull in a very short time. In this case I had the system call hook detector and the disasm engine; putting them together I got FhF. It was born just for joke but I think it might help me sometimes. If you think it can help you in some ways let me know :) Thanks to WarrantyVoider for this nice crackme!

Disclaimer