Themida Attack

I'll contat you no probs , but why no share knowledge with other people ?

Yado Of Lockless.

becouse its too precious

hey .:hack3r2k , i've contact you but i got no reply.

Btw , i've finished to add to my sys the anti drx & anti int3
probably in next day i'll be able to run it with sice so i'll start to
debug it.

When i've the full working .sys i'll post here.

Yado of Lockless.

[LordGarfio]

Hi, Themida is used in Total Multiserver v1.45 software

cheers.

Btw , i've finished to add to my sys the anti drx & anti int3
probably in next day i'll be able to run it with sice so i'll start to
debug it.

You already know what the sys does? I already traced the first ioctl
message sended to the device (ioctl code = 1800h).
It gets some procedures addresses from ntoskrnl:
-PsGetCurrentProcessId
-IoGetCurrentProcess
-Ke386IoSetAccessProcess
-ObReferenceObjectByHandle
-PsProcessType
-Ke386SetIoAccessMap

Saves vector 1 and 3 of IDT. Changes the access flags of
some blocks of memory allocated at runtime and IDT page from
super-visor to user-mode.

The ioctl 1800h returns some data in the 50h chars long buffer,
including locations of those allocated memory blocks.
Besides of other to-study-or-not-facts....

There are other ioctls parsed with id: 1801,1802,1A00.

Making some memory shared between the device and the exe
is an open door to lotsa things I guess...

gotta do more tracing

later

[niom]

Originally Posted by jemos

Saves vector 1 and 3 of IDT. Changes the access flags of
some blocks of memory allocated at runtime and IDT page from
super-visor to user-mode.

hm

kd> !descriptor idt 1
------------------- Interrupt Gate Descriptor --------------------
IDT base = 0x8003F400, Index = 0x01, Descriptor @ 0x8003f408
8003f408 6f ad 08 00 00 8e 4d 80 
Segment is present, DPL = 0, System segment, 32-bit descriptor
Target code segment selector = 0x0008 (GDT Index = 1, RPL = 0)
Target code segment offset = 0x804dad6f
[....]
kd> g
Winlicense driver loaded in memory
kd> !descriptor idt 1
------------------- Interrupt Gate Descriptor --------------------
IDT base = 0x8003F400, Index = 0x01, Descriptor @ 0x8003f408
8003f408 6f ad 08 00 00 ee 4d 80 
Segment is present, DPL = 3, System segment, 32-bit descriptor
Target code segment selector = 0x0008 (GDT Index = 1, RPL = 0)
Target code segment offset = 0x804dad6f

it seems that they change the dpl of int1 from 0 to 3. this makes some sense because they are using some int1 instructions in their usermode code.
and why is there almost no communication between the app and the driver?
do they use the driver only for the handling of exceptions that are generated by their usermode code?
and how the hell do they detect vmware? (they are not using the 'documented' backdoor IO port)

I'm assuming it changes the idt dpl in usermode...
If u have vmware, can u try:
mov ax,ds
test ax,4
jnz ...
And tell me if there's any difference? (in normal NT, bit 100b of ds = 0).
I havent traced much after the ioctl 1800, probably later I might be able to
answer some of those questions
laters

EDIT: according to the thread replies I've received on the other thread,
it seems to be a 9x\NT detection code...
thread link is:
hxxp://www.exetools.com/forum/showthread.php?t=6427

Originally Posted by niom

and why is there almost no communication between the app and the driver?
do they use the driver only for the handling of exceptions that are generated by their usermode code?

This information I got from xprotector. I'm sure it is still relevant today.
The driver is used to elevate privileges of the usermode application. After the first IO control calls (jemos correctly identified the key elements in it), the application has full read/write access to the driver's memory.
It uses it to do synchronization (ex: wait until some dword in driver = 1) - probably due to the multi-threaded nature of the protection.
I'm not sure if this is still done, but the xprot driver used to give read/write access on the IDT as well; so the user-mode application was able to dynamically change the int1/int3 descriptors.
Another thing which the usermode application has access to is some privileged instructions; mostly for interrupt handling & direct debug register access, like iretd; mov dr0, eax, ...

and how the hell do they detect vmware? (they are not using the 'documented' backdoor IO port)

by detect, do you mean crash? that's what it does here under vmware 4.0.x with windows 2k running on it.