05 Feb 2015


First of all I would like to thank to ~200 people (or bots) who still visit this blog! I didn’t post for a long time (again) because I was busy with a project for the university. Right now I had my exams, so I will have a little time to write a new blogpost.


Some people might remember a project I started about a year ago. This project is called TitanHide and it was created to make kernel-mode debugger hiding possible on the x64 versions of Windows. At the time there was no kernel-mode hiding driver that worked on the x64 versions of Windows and that was also open-source. Trusting kernel drivers is really important (especially when they install hooks) because they can do anything with your system they like. TitanHide was meant to be easy to extend and it should work on both x32 and x64 systems.

Debug Detection

Software protection or malware usually doesn’t like being debugged. For this reason they usually insert various debugger checks. There are lots and lots of anti-debug tricks, see this paper for example. Some tricks like IsDebuggerPresent or NtGlobalFlag can be bypassed by changing the PEB in memory of the usermode process. Other detection methods cannot be evaded by a simple memory patch (NtClose for example). These detection methods require hooks. Hooks in user-mode (such as done by ScyllaHide) work in most cases, but more advanced debugger detection systems also detect user-mode hooks. In this case there is need for kernel-mode hooks, which is what TitanHide is using to evade debug detection methods. TitanHide does not patch the PEB or other things that can be done in user-mode, it’s focus lays purely in kernel-mode.


In x32 times patching the kernel was officially unsupported by Microsoft, but there were no countermeasures built into the operating system against it. When Windows x64 came along, Microsoft added Kernel Patch Protection, also referred to as ‘PatchGuard’. PatchGuard prevents modification of critical kernel structures, such as the SSDT, which TitanHide uses to hook kernel functions. There are various methods of disabling PatchGuard, but TitanHide does not implement any of those. The main reason behind this is that TitanHide is purely meant to bypass debugger checks, not as a full-fledged rootkit library. If you want a quick way to disable PatchGuard, simply enable debug mode on your computer. This effectively stops PatchGuard from loading. If you want more information about PatchGuard I recommend reading this article. Everything that happens after this point is with PatchGuard disabled.


This post will mainly be about TitanHide installs it’s hooks. If you want more information about how the functions are modified to make it look like certain processes are not being debugged, you should read the code. I also recommend reading this paper about ScyllaHide. It can help while reading the TitanHide code (since the code itself is not greatly documented).

Many ideas in TitanHide come from different people around the internet, but the code in TitanHide is mostly written by myself. Code I used from the internet usually has a comment explaining where it came from. Some code was also written by cypherpunk. You can see which code specifically in the commit log.

SSDT Hooking

In short the System Service Dispatch Table (SSDT) is used by the operating system to determine which function to call after a transition from user to kernel-mode. The table contains kernel-mode function pointers and when a user-mode program wants to call such a function it provides an index to the function it wants to call in EAX. SSDT Hooking means replacing these kernel-mode function pointers with custom functions that either fully replace the existing function or modify the function behavior.

In x32 mode, replacing SSDT functions is quite straightforward (see this article for more information). Basically what happens is this:

SSDTStruct* SSDT = MmGetSystemRoutineAddress(L"KeServiceDescriptorTable");
SSDT->pServiceTable[FunctionIndex] = NewFunctionPointer;

On x32 versions of the operating system the SSDT structure is exported under the name KeServiceDescriptorTable by ntoskrnl.exe, which makes SSDT hooks really easy to implement.

On x64 versions of the operating system SSDT hooking becomes much harder. There are two reasons for this. The first reason is that the SSDT is no longer exported by ntoskrnl.exe, which means TitanHide must use different ways to find the SSDT. The other reason is that the SSDT no longer uses direct pointers, but offsets relative to the start of the SSDT. This means our hooks cannot be located too far from the ntoskrnl memory region.

Locating the SSDT on x64

After lots of searching around I found someone who discovered a semi-reliable way of locating the SSDT on x64 (I tested this method on Windows XP x64 - Windows 8.1 x64 with success). Read the original post here. For the purpose of this post I will line out the basics here, supported with some code.

An exported function called KeAddSystemServiceTable has a reference to the RVA of the SSDT. To find this RVA, TitanHide uses the following code:

000000014050EA4A 48 C1 E0 05                shl rax, 5
000000014050EA4E 48 83 BC 18 80 3A 36 00 00 cmp qword ptr [rax+rbx+363A80h], 0 <- we are looking for this instruction
000000014050EA57 0F 85 B2 5C 0A 00          jnz loc_1405B470F
000000014050EA5D 48 8D 8B C0 3A 36 00       lea rcx, rva KeServiceDescriptorTableShadow[rbx]
000000014050EA64 48 03 C8                   add rcx, rax
000000014050EA67 48 83 39 00                cmp qword ptr [rcx], 0
int rvaSSDT = 0;
for (unsigned int i = 0; i < function_size; i++)
    if (((*(unsigned int*)(function + i)) & 0x00FFFFF0) == 0xBC8340 && //4?83bc??
        !*(unsigned char*)(function + i + 8)) //???????? 00 
    { //cmp qword ptr [r?+r?+????????h], 0
        rvaSSDT = *(int*)(function + i + 4);
SSDT = (SSDTStruct*)((ULONG_PTR)GetKernelBase() + rvaSSDT);

Locating the SSDT on Windows 10 Technical Preview is a little trickier, but still possible:

Windows 10 Technical Preview:
fffff800e21b30ec 757f             jne nt!KeAddSystemServiceTable+0x91 (fffff800e21b316d)
fffff800e21b30ee 48833deafee4ff00 cmp qword ptr [nt!KeServiceDescriptorTable+0x20 (fffff800e2002fe0)],0 <- we are looking for this instruction
fffff800e21b30f6 7575             jne nt!KeAddSystemServiceTable+0x91 (fffff800e21b316d)
fffff800e21b30f8 48833da0fee4ff00 cmp qword ptr [nt!KeServiceDescriptorTableShadow+0x20 (fffff800e2002fa0)],0
fffff800e21b3100 756b             jne nt!KeAddSystemServiceTable+0x91 (fffff800e21b316d)
int rvaFound = -1;
int rvaSSDT = 0;
for (unsigned int i = 0; i < function_size; i++)
    if (((*(unsigned int*)(function + i)) & 0x00FFFFFF) == 0x3D8348 && //48833d
        !*(unsigned char*)(function + i + 7)) //???????? 00
    { //cmp qword ptr [?],0
        rvaFound = i;
        rvaSSDT = *(int*)(function + i + 3);
//Calculate the actual address (rvaSSDT is a RIP-relative offset)
SSDT = (SSDTStruct*)((ULONG_PTR)KeASST + rvaFound + rvaSSDT + 8 - 0x20);

Hooking the SSDT on x64

In order to make sure the new function pointers ‘fit’ into the SSDT, I created a function called FindCaveAddress. That looks for compiler-generated padding, usually found around functions. It searched for a certain number of padding bytes and when found, a hook stub like this is inserted:

mov rax, NewFunctionPointer
push rax

These stubs redirect the instruction pointer to our hooked function, making things really easy.

SSDT Function Index

Every function in the SSDT has an index, there are websites such as this one that list the all Nt* functions and their index, but hardcoding everything for every possible OS is tedious and error-prone work so I wrote a function to heuristically find an SSDT index for an exported ntdll.dll function. What is does is reading ntdll.dll from disk and then it parses the export table, searching for a function. If the function was found it looks for mov eax, XXXXXXXX, where XXXXXXXX will be the SSDT index. This is based on the fact that the ntdll.dll stubs look pretty much the same on every version of ntdll.dll until Windows 8.1:

0000000077EF0E10 | 4C 8B D1       | mov r10,rcx
0000000077EF0E13 | B8 40 00 00 00 | mov eax,40
0000000077EF0E18 | 0F 05          | syscall
0000000077EF0E1A | C3             | ret

If you are interested in the specifics of this code, take a look at ntdll.cpp.

This is how you hook a function exported by ntdll.dll using the current TitanHide codebase:

HOOK hNtQueryInformationProcess = SSDT::Hook("NtQueryInformationProcess", (void*)HookNtQueryInformationProcess);

That’s right, only one line of code to do any SSDT hook you want!


I hope you found this blogpost interesting, if you have any remarks, feel free to post them in the comments or send them to me.



Leave a comment

Itubes Library Format 2

27 Dec 2014

A few days ago I wrote some things about the iTunes library file format. Today I will try to write the remainder about this subject.

A small recap

In the previous post I discussed the structure of the encrypted file and there should also be enough information for a mediocre programmer to decrypt a .itl file by yourself. In this post I will be using a decrypted .itl file.

The base structure

Every .itl file starts with an hdfm information header. The approximate format of this header block is documented the older file format from iTunes v1.x - v3.x. Basically after this everything is the same as in the older file format, except the header ‘names’. The hdsm now is reversed to msdh. The whole file is basically build of msdh blocks with variable sizes.

Here is a small screenshot that shows the header and the msdh blocks:


Structure of the ‘msdh’ blocks

The msdh blocks contain the headerLength, totalLength and blockType as most important fields. After the msdh header, there is blockData that can contain various other types of structures. These structures very often look similar to this C-style structure:

typedef struct
    char signature[4]; //"mlrh" as signature identification.
    int headerLength; //total length of the header.
    char unknown[headerLength - 8]; //structure-specific data.
} mlrh;

A screenshot of how such a grammar looks:

basic block structure

Content of the ‘msdh’ blocks

The blockType field of the msdh block says something about the contents of the block. The value 4 for example has blockData that contains a path to the music library, /Users/xxxxxx/Music/iTunes/iTunes%20Media in my case. blockData can also contain other blocks. The miah and mith blocks for example both contain mhoh blocks. mhoh blocks are some kind of general-purpose block that can contain a lot of things.


The basic file format was all I needed to continue fixing requiem, so this it all for now. Maybe I will blog more about my progress later. You can find the grammar here, feel free to expand on it and don’t forget to send me the latest version if you do ;)

Merry Christmas,


Leave a comment

X64_dbg From Top To Bottom 1

24 Dec 2014

Hello everyone,

Quite some time ago I started thinking about ways to engage more developers in x64dbg. The main problem new developers (in my view of things) have is that x64dbg is poorly documented. Code documentation is very important in software development but when I started with x64dbg the whole concept of software development was new to me, so I did not document my code. Recently I started documenting the code of x64dbg, but code documentation is very boring, so I decided to spice it up a little (for myself mainly) with a few blog posts.

Before reading

Before you start reading this post, I recommend you read up on Creating a Basic Debugger and you should know a little about threads. You should also know where to find x64dbg’s source code in case you want to see more of the code.

The debug loop

Technically the debug loop is part of TitanEngine, not of x64dbg. The design of the debug loop, however is very important for x64dbg in general, so I will explain it here anyway.

A basic debug loop looks like this:

debug loop

This is also how TitanEngine’s debug loop works. It handles events by calling so-called “Custom Handlers”, which you can register by calling the SetCustomHandler() function. In addition to calling custom handlers TitanEngine does a lot of housekeeping (like storing information about the threads, modules and breakpoints). It also handles certain exceptions like STATUS_SINGLE_STEP for stepping and STATUS_BREAKPOINT for software breakpoints.

The most important point of these custom handlers is the fact that they are part of the debug loop, which means the debug loop won’t continue until the custom handler returns.

Threading of the debug loop

Because the DebugLoop() function of TitanEngine does not return until debugging is finished (debuggee termination), it has to be run on a new thread, so we can continue using the GUI while debugging (which is the whole point of the GUI anyway).

Here is a little image for the overview:

basic threading

  • A block represent a thread;
  • A dashed arrow represents starting a new thread;
  • A red arrow represents thread termination;
  • A circle contains the termination condition.

The Main Thread starts the Command Thread. The Command Thread has an architecture similar to the debug loop; it waits for a command, calls a command handler and then starts waiting again.

When an InitDebug command is encountered (see help), information is obtained about the executable to debug and a Debug Thread is started. This Debug Thread contains the debug loop we discussed above.

Syncing the threads

The Debug Thread has to wait in custom handlers until the user tells it to continue (by pressing the run button in the GUI). This is done by a very simple locking system that has three main functions: lock(), unlock() and wait(). The wait() function simply waits while the lock is locked and it works across threads, so when the Debug Thread is waiting and the Command Thread calls unlock(), the Debug Thread will continue execution. You can find all this code here.

To provide thread-safe access to certain global variables (like breakpoint/comment/bookmark lists), x64dbg uses a class called CriticalSectionLocker. This class can be found in the same file as locking system above.


That’s all for now, I hope you enjoyed reading this and I will continue to cover various aspects of x64dbg, from the bigger picture, to small interesting details.


Leave a comment

Itunes Library Format 1

16 Dec 2014

Hello everyone,

More than a month ago I posted about some code I had to write for a project, today it will be about exploring the iTunes Library file format.


“Why reverse the iTunes Library format?” you might ask, well it all started with a university project. Basically we’re developing an app for Android/iOS using Xamarin and since Apple doesn’t like Windows, it is impossible to create/compile/test iOS apps without having access to Mac OS X. I installed a hackintosh distribution to start developing the app.

One time, when I was browsing iTunes I saw I had 15 euros left on my account, so I decided to buy an eBook I saw on TV. But Apple still hates Windows/Android/Whatever and after I spent my money I discovered it was impossible to read books bought in the iBooks store on a non-iDevice. I tried searching for some DRM removal tools, but there was only one and it didn’t work (it’s called requiem by the way).

Since I like reversing I decided to take on FairPlay (Apple’s DRM) in order to unlock the .epub file so I can read it on my Sony eReader.

In the process of checking out the old sources I discovered that the iTunes Library was read and decrypted, but after that the file format did not match the code anymore. Since the code was made for iTunes v10.x, not v12.x I had to figure out the new library file format.

The past

In the past people tried to reverse the iTunes Library file format, the more notable document is this one. It’s for iTunes v1.x - v3.x, but it was still useful for me now. Another resource is the previously mentioned requiem source code.

Getting started

Before we get started I’d like to introduce a very good tool called Synalyze It! Pro. Basically it’s a hex editor, but it’s main feature (for us at least) is the ‘Grammars’ option. Grammers are XML files that describe data structures and when a structure matches with a file, you can see the structure contents and highlight/manipulate the bytes they are mapped to. Reading the documentation is recommended before you continue.

It might also be useful to note I’m doing everything on Mac OS X (probably iTunes for Windows has the same format, but I didn’t check).

Now copy the iTunes Library file called iTunes Library.itl from ~/Music/iTunes/ to your documents folder or something and open it up in Synalyze It to start working with it.

Encryption + ZLIB

In the requiem source code, you can see in ModifyLib.loadLibrary() that the iTunes file from v10.x used AES/ECB/NoPadding with the key BHUILuilfghuila3:


// decrypt all full blocks in the body
Key key = new SecretKeySpec("BHUILuilfghuila3".getBytes(), "AES");
Cipher cipher = Cipher.getInstance("AES/ECB/NoPadding");
cipher.init(Cipher.DECRYPT_MODE, key);
int crypt_size = (data.length - header_size) & ~0xf;
int max_crypt_size = read32(data, 0x5C);
if (max_crypt_size != 0)
    crypt_size = Math.min(crypt_size, max_crypt_size);
cipher.doFinal(data, header_size, crypt_size, data, header_size);

// un-zip body (ZLIB)
Inflater inflater = new Inflater();
inflater.setInput(data, header_size, data.length - header_size);
byte[] clear_data = new byte[65536];
while (!inflater.finished())
    int n = inflater.inflate(clear_data);
    o.write(clear_data, 0, n);


After reading the older file format from iTunes v1.x - v3.x and the requiem source it is quite easy to create a Grammar for the encrypted file format:

Encrypted iTunes Library

Conclusion (for now)

Hopefully this was an interesting start. Unfortunately I don’t have enough time to post the full story, but there will be a next post soon (I hope). In the meantime, try modifying the requiem source to output a decrypted iTunes library of your own. This will be required for the next post. Another thing you might want to do it setting up Eclipse with the Makefile included in the requiem source. This will make dumping the decrypted library a lot easier.

Till next time,


Leave a comment


01 Nov 2014

It’s been two months, but I finally found some time to post something in this blog :)


As a programming exercise for the University we have to create a simple Paint-like program in C#. It has some tools (lines, rectangles, ellipses, text), it must be able to save/load to a custom format that represents the current drawing and it must be able to export to common image formats.

As representation of the current sketch I use a List<T> structure. The objects that were last added to the list are draw ‘above’ objects added previously. A bonus task was to add an Undo/Redo functionality, which I will explain in this post.


What I wanted to create was a transparent data structure that could just replace the existing List<T> structure, without having to add additional statements to keep the Undo/Redo state. Furthermore the structure should be usable in a wide variety of cases.

What I did (summary)

First I created a class that represents the List<T> functionality called UndoList<T>. This class has a private class called UndoAction<U>, which represents something that happened to the original list. The UndoList<T> class has a List<UndoAction<T>> member that represents the stack of changes. To be able to provide a Redo functionality, there is a pointer member that points to the last change (I will come to this later).


This class is very simple. It contains the action performed (ActionType) and the actual object that was Added/Removed:

private class UndoAction<U>
    public ActionType Type { get; private set; }
    public U Value { get; private set; }

    public UndoAction(ActionType type, U value)
        this.Type = type;
        this.Value = value;


This class has to be able to do the simple list operations: list[i], list.Add(), list.RemoveAt() and List.Clear(). These functionalities are very easy to implement:

public void Add(T value)
    list.Add(value); //add the value to the actual list
    addUndoAction(new UndoAction<T>(ActionType.Add, value)); //add an entry to the Undo list

public void RemoveAt(int index)
    addUndoAction(new UndoAction<T>(ActionType.Remove, list[index]));

public void Clear()
    foreach (T value in list)
        addUndoAction(new UndoAction<T>(ActionType.Remove, value));

public T this[int index]
        return list[index];
        list[index] = value;

To provide the functionality of the foreach loop, UndoList<T> needs to be a subclass of System.Collections.IEnumerable. Implementing this interface is really easy for us: we simply return the Enumerator of the actual List<T> member which contains the representation of the sketch.

Implementing the IEnumerable interface goes like this:

public class UndoList<T> : IEnumerable
    private List<T> list; //the actual list with data

    public IEnumerator GetEnumerator()
        return list.GetEnumerator();

    //other members

The pointer member

If we were only required to provide an Undo functionality, we could just use a list with UndoAction<U> entries. When the Undo() function is called, undo the action and remove the last entry of the list. For Redo() to work, we either need to keep track of the Undo’s we did (which comes down to keeping track of a list that is used to keep track of another list) or we need to use a pointer. The pointer member of the UndoList<T> class points to the last action that was added to the List<UndoAction<T>> list. When Undo() is called, the action will be undone and after that the pointer is decreased. We can do this until the pointer equals -1, which means there is no action left to undo. After you called Undo() a few times and you then call Redo(), the pointer will be increased and after that, the action will be applied to the list with data (see Undo() and Redo() functions for code).

Final words

This class is a good example of how templates can be used in a meaningful way and I learned quite some things from it. I made the source available under the MIT License, you can get it here.

This class has very minimal functionality of the List<T> class. Sorting has no Undo/Redo and Clear() makes it look like every element was removed one-by-one. Feel free to improve on this :)


Leave a comment