This article is just for fun, don't take it too serious. Some time ago a friend (Littleluk) asked me if i was interested in helping him with the coding stuff related the unpacking of themida (the commercial successor of xprotector). I agreed. However, i had second thoughts about it. 'Cause, to be sincere, i don't like to waste my time over useless things and themida sure is one of them. For those who still don't know what i'm talking about: themida is a packer, moreover it's a packer who runs partly in kernel-mode. This means: if you try to debug themida with a debugger, it will crash your system. Very unprofessional, i know. And that's mainly the reason i look at themida as a toy for reversers. Lets get this straight, themida will never be used by major companies, nobody would protect a good software with a protector who patches the kernel of windows, patches the SDT, patches the IDT, in certain situations makes you reboot your computer etc etc? This means themida isn't widely used and there's no real interest in unpacking it other than the fun itself. I have no fun doing useless things, but since Littleluk is the reverser, i have just to code some stuff (and using old code snippets i've already coded). And this is what this article is all about, a tool i wrote. It's not a tool to unpack themida (that would be impossible: Littleluk hasn't reversed it yet). The tool makes work some tools you already have on you computer against themida.
A few warnings:
1 - this article is nothing hardcore, don't let you impress by the driver coding stuff, it's ridiculous stuff for a driver writer (and i say that 'cause sometime in the reversing scene it's easy to find people with no knowledge of kernel-mode programming).
2 - the things you're going to read in this article will be obsolete in a few years (as the tricks themida uses).
3 - i never touched themida, i wrote the tool out of my experience and the results i got from Littleluk.
4 - i'm not going to explain what SDT, IDT and other internals relative concepts mean. If you ignore the meaning look on the web. I have no time to explain more than necessary, in fact this is one of the reason i'm releasing this article right now. I just have available a coule of days and then i have to go back to work (real work).
5 - i'm going to explain what i know about themida, or better what you need to know to understand the tool i wrote. I'm not reversing themida, so i don't care about a lot things.
6 - i don't know if there will be another version of the AntiMida, it depends on the information which is given to me by the reverser/s and on how much free time i'll have.
7 - it doesn't work if u're using PAE extension (i was too lazy to add some code).
8 - The way the tool acts wasn't absolutely necessary, there were other ways.
The victim which was used for the tests is nothing else than the themida itself (the demo version i mean). You can download it from the official webpage (current version is 1.0.0.5).
The AntiMida is not a planned tool, everytime there was a problem i tried to code the solution for it. At the moment AntiMida lets you:
1 - use common user-mode applications to dump themida.
2 - use tools like imprec, winhex (to see the proc memory), etc.
3 - monitor file and registry access.
But one thing at a time. The first step was to dump themida. How? First we had to know what themida does to protect itself against dumping. Actually the first idea to dump themida was to use KeAttachProcess, we dumped ntoskrnl (with wark) and saw that the keattachprocess was patched with a jmp to a themida routine. So, to use keattachprocess it was necessary to pacth the ntoskrnl first (i paste later the code). Here's the routine i wrote with KeAttachProcess:
I pasted it just for information, 'cause this code isn't used anymore by the AntiMida. It was obvious that themida was hooking the SDT, so after a scanning with sdtrestore a list of hooked services was given to me:
ZwAllocateVirtualMemory 11 --[hooked by unknown at F5938BC4]--
ZwCreateThread 35 --[hooked by unknown at F5938CBE]--
ZwDebugContinue 3A --[hooked by unknown at F59391A0]--
ZwQueryVirtualMemory B2 --[hooked by unknown at F5938ACA]--
ZwReadVirtualMemory BA --[hooked by unknown at F5938014]--
ZwTerminateProcess 101 --[hooked by unknown at F59389D0]--
ZwWriteVirtualMemory 115 --[hooked by unknown at F5938000]--
Ok ZwAllocateVirtualMemory, ZwQueryVirtualMemory, ZwReadVirtualMemory, ZwWriteVirtualMemory, ZwCreateThread make sense, since we could use all these functions to dump themida. ZwDebugContinue is to avoid debugging, although themida fucks with the IDT as well (so this is way not the only trick against debugging, would be too easy, of course). ZwTerminateProcess is unimportant, i guess it's only hooked to know when a protected process is killed. Of course if you try to restore one of these services themida crashes the system.
The idea i had was to build a tool which would make other already existing tools work. So i organized an interface with a list of the running processes and the possibility of selecting one of those processes and make it AntiMida, this means immune against themida. A brief look at the interface is thousand of words worth.
When the the little wizard is pressed, a dll is injected in the address space of the selected process, the functions themida is protecting itself against are hooked and redirected to the injected dll, each time a hooked function is called, the dll calls a driver which process the operation. Ok, but how does my driver process the requested operation? You'll see that later. Now lets take a look on the injection/hooking routines:
BOOL InjectModule(IN ULONG_PTR ProcessID, IN TCHAR *ModuleName,
OUT ULONG_PTR *BaseAddress OPTIONAL)
{
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE,
ProcessID);
To fill the import table i used no remote getprocaddress since the dll imports just not relocated system dlls, so a locale getprocaddress is enough. Here's the hooking routine:
MessageBox(_T("The process is now AntiMida"), "AntiMida");
}
else
{
MessageBox(_T("Cannot make the process AntiMida"), "AntiMida");
}
}
If you're asking yourself why i hooked the first functions in kernel32 and the remaining in ntdll: there's no reason. I was trying if it was working and hooked kernel32 for no reason, but then i was too lazy to rewrite the code and hook ntdll (you see i'm really lazy). In fact the best way is too hook ntdll, not only because it's the direct way but also the shortest (you'll see). GetExportRva is just a small function i wrote to get the rva of an export:
extern "C" __declspec(dllexport)
NTSTATUS NTAPI FakeNtAllocateVirtualMemory(IN HANDLE ProcessHandle,
IN OUT PVOID *BaseAddress,
IN ULONG_PTR ZeroBits,
IN OUT PSIZE_T RegionSize,
IN ULONG AllocationType,
IN ULONG Protect)
{
Input_ZwAllocateVirtualMemory Input;
extern "C" __declspec(dllexport)
NTSTATUS NTAPI FakeNtCreateThread(OUT PHANDLE ThreadHandle,
IN ACCESS_MASK DesiredAccess,
IN PVOID ObjectAttributes,
IN HANDLE ProcessHandle,
OUT PVOID ClientId,
IN PCONTEXT ThreadContext,
IN PVOID UserStack,
IN BOOLEAN CreateSuspended)
{
Input_ZwCreateThread Input;
I don't think there's something to explain about this code. As i was saying i perform in the driver the requested operations, but how? Just by calling the original service in ntoskrnl. The problem is that ntoskrnl doesn't export in his export table the services in the SDT, how is it then possible to get the right address? There's a little trick. ntoskrnl has a copy of the SDT in itself. So i wrote the code to get the address of the original services:
//
// thanks to 90210 for the code
// http://www.rootkit.com/newsread.php?newsid=176
// u saved some of my time
//
// loop thru relocs to speed up the search
if ((poh->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress) &&
(!((pfh->Characteristics)&IMAGE_FILE_RELOCS_STRIPPED))) {
for (i=0;i<(pbr->SizeOfBlock-sizeof(IMAGE_BASE_RELOCATION))>>1;i++,pfe++) {
if (pfe->type==IMAGE_REL_BASED_HIGHLOW) {
dwFixups++;
dwPointerRva=pbr->VirtualAddress+pfe->offset;
// DONT_RESOLVE_DLL_REFERENCES flag means relocs aren't fixed
dwPointsToRva=*(PDWORD)((DWORD)hModule+dwPointerRva)-(DWORD)poh->ImageBase;
// does this reloc point to KeServiceDescriptorTable.Base?
if (dwPointsToRva==dwKSDT) {
// check for mov [mem32],imm32. we are trying to find
// "mov ds:_KeServiceDescriptorTable.Base, offset _KiServiceTable"
// from the KiInitSystem.
if (*(PWORD)((DWORD)hModule+dwPointerRva-2)==0x05c7) {
// should check for a reloc presence on KiServiceTable here
// but forget it
dwKiServiceTable=*(PDWORD)((DWORD)hModule+dwPointerRva+4)-poh->ImageBase;
return dwKiServiceTable;
}
}
} else
if (pfe->type!=IMAGE_REL_BASED_ABSOLUTE)
{
// should never get here
}
}
*(PDWORD)&pbr+=pbr->SizeOfBlock;
}
}
if (!dwFixups)
{
// should never happen - nt, 2k, xp kernels have relocation data
}
return 0;
}
// get system modules - ntoskrnl is always first there
rc=pNtQuerySystemInformation(SystemModuleInformation,pModules,4,&dwNeededSize);
if (rc==STATUS_INFO_LENGTH_MISMATCH) {
pModules = (PMODULES) GlobalAlloc(GPTR,dwNeededSize);
rc=pNtQuerySystemInformation(SystemModuleInformation,pModules,dwNeededSize,NULL);
} else {
strange:
return FALSE;
}
if (!NT_SUCCESS(rc)) goto strange;
// imagebase
dwKernelBase=(DWORD)pModules->smi.Base;
// filename - it may be renamed in the boot.ini
pKernelName=pModules->smi.ModuleNameOffset+pModules->smi.ImageName;
// map ntoskrnl - hopefully it has relocs
hKernel=LoadLibraryEx(pKernelName,0,DONT_RESOLVE_DLL_REFERENCES);
if (!hKernel) {
return FALSE;
}
GlobalFree(pModules);
// our own export walker is useless here - we have GetProcAddress :)
if (!(dwKSDT=(DWORD)GetProcAddress(hKernel,"KeServiceDescriptorTable"))) {
return FALSE;
}
// get KeServiceDescriptorTable rva
dwKSDT-=(DWORD)hKernel;
// find KiServiceTable
if (!(dwKiServiceTable=FindKiServiceTable(hKernel,dwKSDT))) {
return FALSE;
}
// let's dump KiServiceTable contents
// MAY FAIL!!!
// should get right ServiceLimit here, but this is trivial in the kernel mode
GetHeaders((PBYTE) hKernel,&pfh,&poh,&psh);
The GrabService function is based on another little trick to get the SDT entry. In fact SDT entries change every version of windows, so the best way to get the right entry is read it from the ntdll. Look at the NtReadVirtualMemory:
.text:7C91E2BB public ZwReadVirtualMemory
.text:7C91E2BB B8 BA 00 00 00 mov eax, 0BAh ; this is the SDT entry
.text:7C91E2C0 BA 00 03 FE 7F mov edx, 7FFE0300h
.text:7C91E2C5 FF 12 call dword ptr [edx]
.text:7C91E2C7 C2 14 00 retn 14h
So i wrote this function to get the right SDT entry:
//
// thanks to gareth for the idea
// http://www.rootkit.com/newsread.php?newsid=248
//
So i'm collecting the information i send to the driver (restore info), i also send him the original bytes of KeAttachProcess, i don't use it anymore but it could be useful to have it restored:
And that's all about the SDT. Now lets talk about monitoring, this means: regmon and filemon. TheMida doesn't start if one of these two is open. There are several ways to detect these to drivers, too many i'm afraid. Here are some of them:
1 - look for the process.
2 - look for the window (i found this trick in some packers as well).
3 - look up the drivers in the registry.
4 - look up the drivers in memory.
5 - look up the object table for the device.
6 - look up the SDT (only for regmon).
There are other ways, but these would be the most usual, i think. I tried to solve point 4 and 5 (cause i already had source code available to do that).
NTSTATUS ObOpenObjectByName (IN POBJECT_ATTRIBUTES ObjectAttributes,
IN POBJECT_TYPE ObjectType OPTIONAL, IN KPROCESSOR_MODE AccessMode,
IN OUT PACCESS_STATE AccessState OPTIONAL, IN ACCESS_MASK DesiredAccess OPTIONAL,
IN OUT PVOID ParseContext OPTIONAL, OUT PHANDLE Handle);
// end
NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject,
IN PUNICODE_STRING RegistryPath);
// open driver directory in the object directory
RtlInitUnicodeString(&ucName,L"\\Driver");
InitializeObjectAttributes(&ObjectAttributes,&ucName,OBJ_CASE_INSENSITIVE,NULL,NULL);
Status = ObOpenObjectByName(&ObjectAttributes,NULL,KernelMode,NULL,
0x80000000,NULL,&hDirectory);
if (!NT_SUCCESS (Status))
goto __exit;
// get pointer from handle
Status = ObReferenceObjectByHandle(hDirectory,FILE_ANY_ACCESS,NULL,
KernelMode,&pDirectoryObject, NULL);
if (!NT_SUCCESS (Status))
goto __exit;
// we raise the irql too to protect the list from being accessed by kernel APC
KeRaiseIrql(APC_LEVEL,&OldIrql);
// walk the object directory
for (Bucket=0; Bucket<NUMBER_HASH_BUCKETS; Bucket++)
{
// are we done yet ?
if (found)
break;
DirectoryEntry = pDirectoryObject->HashBuckets[Bucket];
if (!DirectoryEntry)
continue;
// check if we're at the top of a bucket
ObjectHeader = OBJECT_TO_OBJECT_HEADER( DirectoryEntry->Object );
NameInfo = OBJECT_HEADER_TO_NAME_INFO( ObjectHeader );
if (NameInfo != NULL)
{
ObjectName = NameInfo->Name;
// here you compare the name of the object with the one of your driver (ex: ROOTKIT)
// this function is just my extension to wcsstr, just forget about it .......
if (wcscmp(ObjectName.Buffer, L"hide") == 0)
{
// get top and next pointers
DirectoryEntryTop = pDirectoryObject->HashBuckets[Bucket];
DirectoryEntryNext = DirectoryEntryTop->ChainLink;
// substitute top
pDirectoryObject->HashBuckets[Bucket] = DirectoryEntryNext;
DirectoryEntryTop = pDirectoryObject->HashBuckets[Bucket];
// walk the chain and shift back the entries by one place
while (DirectoryEntryNext)
{
DirectoryEntryTop->ChainLink = DirectoryEntryNext->ChainLink;
DirectoryEntryTop = DirectoryEntryTop->ChainLink;
DirectoryEntryNext = DirectoryEntryNext->ChainLink;
}
if (DirectoryEntryTop)
DirectoryEntryTop->ChainLink = NULL;
found = TRUE;
// we can exit safely
break;
}
}
// if we're not at top of a bucket, check the entry->next fields
// for every entry, we check the next
DirectoryEntryNext = DirectoryEntry->ChainLink;
if (NameInfo != NULL)
{
ObjectName = NameInfo->Name;
if (wcscmp(ObjectName.Buffer, L"hide") == 0)
{
// found our object, now we must unlink it, this time is easy
DirectoryEntry->ChainLink = DirectoryEntryNext->ChainLink;
found = TRUE;
// exit
break;
}
}
// walk the next entry if any
if (DirectoryEntry)
{
DirectoryEntry = DirectoryEntry->ChainLink;
DirectoryEntryNext = DirectoryEntry->ChainLink;
}
else
{
DirectoryEntryNext = NULL;
}
}
}
// adjust back the irql
KeLowerIrql(OldIrql);
__exit:
// dereference and cleanup
if (pDirectoryObject)
ObDereferenceObject(pDirectoryObject);
if (hDirectory)
ZwClose (hDirectory);
return;
}
of course it's necessary to replace the hide in the code with the actual names. Anyway it seems that TheMida looks at least in the PsLoadedModuleList, but he checks other things too (i think he looks in the registry). I don't have time to try, i'll find out soon (just hiding the keys). Anyway i tried to see if he checks if the SDT is hooked (using the code of regmon to hook one entry), and apparentely he doesn't, he starts correctly. I could also implement a small monitor of registry and files in my tool (it's a possibility). Of course i wouldn't code a file system filter, just hook the SDT like regmon (it's easier). Lets see. For the moment, here's the driver code (with the SDT hook code, which could be extended to actually monitor things).
NTSTATUS (*pZwReadVirtualMemory)(IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
OUT PVOID Buffer,
IN ULONG BufferLength,
OUT PULONG ReturnLength OPTIONAL);
NTSTATUS (*pZwQueryVirtualMemory)(IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
IN MEMORY_INFORMATION_CLASS MemoryInformationClass,
OUT PVOID MemoryInformation,
IN ULONG MemoryInformationLength,
OUT PULONG ReturnLength OPTIONAL);
NTSTATUS (*pZwWriteVirtualMemory)(IN HANDLE ProcessHandle,
IN PVOID BaseAddress,
IN PVOID Buffer,
IN ULONG BufferLength,
OUT PULONG ReturnLength OPTIONAL);
NTSTATUS (*pZwAllocateVirtualMemory)(IN HANDLE ProcessHandle,
IN OUT PVOID *BaseAddress,
IN ULONG_PTR ZeroBits,
IN OUT PSIZE_T RegionSize,
IN ULONG AllocationType,
IN ULONG Protect);
NTSTATUS (*pZwCreateThread)(OUT PHANDLE ThreadHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
IN HANDLE ProcessHandle,
OUT PCLIENT_ID ClientId,
IN PCONTEXT ThreadContext,
IN PUSER_STACK UserStack,
IN BOOLEAN CreateSuspended);
NTSTATUS (*RealZwCreateFile)(OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN PLARGE_INTEGER AllocationSize OPTIONAL,
IN ULONG FileAttributes,
IN ULONG ShareAccess,
IN ULONG CreateDisposition,
IN ULONG CreateOptions,
IN PVOID EaBuffer OPTIONAL,
IN ULONG EaLength
);
NTSTATUS (*RealZwOpenKey)(OUT PHANDLE, IN ACCESS_MASK, IN POBJECT_ATTRIBUTES);
NTSTATUS HookedZwCreateFile(OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN PLARGE_INTEGER AllocationSize OPTIONAL,
IN ULONG FileAttributes,
IN ULONG ShareAccess,
IN ULONG CreateDisposition,
IN ULONG CreateOptions,
IN PVOID EaBuffer OPTIONAL,
IN ULONG EaLength)
{
DbgPrint("%ws\n", ObjectAttributes->ObjectName->Buffer);
Ok, i'm tired now. There's nothing more to explain, if you have doubts, google is there for you. The continuing of the project depends on the information which is given to me. I have no intent in reversing TheMida.
