Эксперт
Профиль
Группа: Участник Клуба
Сообщений: 1232
Регистрация: 25.3.2002
Где: Москва
Репутация: нет
Всего: 18
|
Ниже теория. Смысл в том, что win9x дает модифицировать/читать gdt и ldt, и создавать еще свои элементы с любыми правами. Если надо, подкину что-то еще. | Цитата |
Obtaining the GDT and LDT
Anyone who wants to use the LDT or GDT in Windows must have a very good reason. If you're looking to code a virus, or other destructive software, go somewhere else. Using the trick below, it's impossible to effectively edit the GDT or LDT. You can do it if you're good, and have a very good knowledge of the CPU, but it's a tad bit advanced for this topic...and it's best to write a VxD to do that job.
However, if you're looking to add descriptor identification to debuggers, or write directly to other threads or processes, this may be what you're looking for. First, though, I'll take you through a basic tour of the CPU in protected mode.
Protected Mode Basics
If you're programming in Windows, then you probably already understand the fundamentals of protected mode, but there's a lot that goes on without your knowledge (or consent). While most of it is good, and irrelevant to the programmer, some of it can in fact hinder a program's flexibility. One of these hinderances, in my opinnion, is the unavailability of the LDT. In Windows 95, there is only one LDT for every program running in protected (and real) mode. This is completely opposite to Windows NT, which creates new LDTs specifically for each new process (and possibly even thread). However, in both cases, accessing the LDT and GDT is almost unheard of. Well, it can be done, and quite easily in fact.
First, the registers. In order to enter protected mode, a number of resgiters must be used. First, the most important register, is the GDTR (or Global Descriptor Table Register). This register contains a limit, and an offset in physical memory. The limit, although useful, will serve us little purpose right now, so let's focus on the offset. This base address as it's called gives us a location in memory where the CPU must look to find it's look up table, or descriptor table. The problem comes in when we don't have a selector which has a base of 0, and an 4 GB limit...or do we?
In actuality, Windows gives every application's CS register a base of 0 (which explains the starting point of 400000h), and a limit of 0FFFFFh. But don't we need a limit of 0FFFFFFFFh? Yes, we do, but that limit is an impossibility due to the 8 byte limit of the descriptors. So, a flag called the granularity flag is set, to indicate that our limit is in 4KB chunks instead of bytes. However, 0FFFFFh * 4KB still doesn't equal 0FFFFFFFFh. So, there must be something else. In fact, the limit is calculated as such when the granularity bit is set: ((Limit+1)*4 KB)-1 This equation will give us a limit of 4 GB, and this means we have read access to every point in memory. Every point! The draw back is that no code segment can ever have write access in protected mode. This is probably why the code segments are given unlimited access in Windows.
(NOTE: Future versions of Windows may remove this advantage, thus making it impossible to access the GDT/LDT from Ring 3, even for read only. Do not assume the above to be 100% for every 32 bit program running in Windows. Always check before you read, and double check before you write!)
Now, this will give us the GDT, but what about the LDT? Well, the LDTR (Local Descriptor Table Register) will help us there. However, it's format is only 16 bits, not 64 bits like the GDTR. This is because the LDTR is really a selector which points into the GDT for the limit, base, etc. of the LDT. In fact, throughout your struggles in true Protected Mode, you'll find there are a lot of descriptors in the GDT which aren't used for selectors, but really have other purposes. Since that's an advanced topic, we'll stick to the LDT and the GDT.
Now, the LDTR points to a selector in the GDT, and has very much the same format as a normal descriptor. It has a 32 bit base address, 20 bit limit, granularity bit, and a few more flags including privilage level. Only the base address (and eventually the limit) will be of interest to us, so just ignore the rest.
Loading the GDTR
So, let's begin the examples. The first we must do is obtain the GDTR. No problem. The GDTR is a 64 bit register, with a 32 bit address, a 16 bit limit, and a reserved 16 bits, but how do they fit together? Well, I use the below 'structure' but you can use whatever system you like, so long as it matches up:
GDTR equ this qword
GDTLimit dw 0
GDTBase dd 0
dw 0
With that out of the way, how do we obtain the register? Again, this is pretty much cake. There is a very useful instruction called SGDT, or Store Global Descriptor Table Register. This will retrieve the value of the GDTR into any QWORD PTR we give it. Ie:
SGDT GDTR
works great, and now we have the GDTR in memory. So how do we use it? Well, that's a bit more tricky. Remember what I said about CS? We must use that idea combined with the base address of the GDT. So, it should look something like this:
; accessing the null descriptor, or GDT 0
mov eax,GDTBase
mov ecx,cs:[eax]
mov edx,cs:[eax+4]
In ECX:EDX we have an entire descriptor (for GDT 0). We can use this same idea for our selectors as well. But be careful! A selector is not as simple as it seems. The lowest 3 bits of the selector are actually not a part of the selector at all, but are in fact privilage level information, and table infomation (GDT/LDT). So we use the same system that the processor performs:
xor eax,eax
mov ax,cs
AND EAX,0FFF8h ; 1111111111111000 <-- Always mask out these bits
add eax,GDTBase
mov ecx,cs:[eax]
mov edx,cs:[eax+4]
This will give us the GDT value which has the same index as our CS (but, because our CS in located in the LDT, this will not be the same descriptor). You may be thinking you caught a bug. I masked out the bits but never performed multiplication to determine the exact offset of the selector. Well, actually, I did. Each descriptor is 8 bytes long, and multiplying any number by 8 is the same as shifting to the left 3 bits. Hence, masking out the lower three bits also serves the double-action function of multiplying the index by 8.
Now that you've gotten your first taste of power in Ring 3, let's load up the LDT. This will require the intricate knowledge of the descriptors, so I'll start there. There's more than one kind of descriptor. Most of them, however, have very similar structures, and the ones that don't, we don't really care about. So, how does the descriptor structure look? Take a peak:
Descriptor equ this qword
DLimitLow dw 0
DBaseLow dw 0
DBaseMid db 0
DAccess db 0
DLimitHigh db 0
DBaseHigh db 0
DBase dd 0
DLimit dd 0
Now, I added DBase and DLimit because I use them a lot, and it makes it easier to directly reference the selector through CS (or reading through the LDT without having to parse the base address every time). The structure may look simple, but I can assure there's more than meets the eye. Only the low 4 bits of DLimitHigh are used for the high limit. The other 4 bits are flags for granularity, register size, and two other, OS defined flags. But even all this still leaves the matter of what selector does the LDT use? Well, again, there's another register, the LDTR, which much like it's older brother (GDTR), has a specific instruction designated to it: SLDT (or Store Local Descriptor Table Register). However, since the LDTR is only a 16 bit register, we can use either a 16 bit pointer, or a 16 bit register. So, let's show an example:
.data
LDTR dw 0
...
; assuming we've already gotten the base address of the GDT
xor eax,eax
sldt ax
mov LDTR,ax
AND EAX,0FFF8h ; 1111111111111000 <-- Always do this!
add eax,GDTBase
mov ecx,cs:[eax]
mov edx,cs:[eax+4]
And now, much like before, we have a descriptor in ECX:EDX...but not just any descriptor. This is the LDT. So now, we must calculate at least the base address.
mov dword ptr [Descriptor],ecx
mov dword ptr [Descriptor+4],edx
mov al,DBaseMid
mov ah,DBaseHigh
shl eax,16
mov ax,DBaseLow
mov DBase,eax
And it's just that simple. Now, we have the base addresses for both the GDT and the LDT, and so we can read any descriptor value out of those two tables, including ours:
xor eax,eax
mov ax,cs
AND EAX,0FFF8h
add eax,LDTBase
mov ecx,cs:[eax]
mov edx,cs:[eax+4]
Viola! Reading the LDT and GDT is really quite simple, so long as you understand the registers and the structures involved, as well as the instructions. Now, writing to it is another matter entirely, and well beyond the scope of this tutorial. Hope you enjoyed this fast tour through the GDT and the LDT. Because my DLL supports a vast number of functions, a skipped over a lot, but since it is an open source project, feel free to add to it. I only ask for one stipulation: do not add code to create, destroy, or modify descriptors. You can do this in your own copy of the DLL, but I do not wish to become indirectly involved in programming a virus or other such destructive software.
|
--------------------
I don't like the drugs (but the drugs like me). M.Manson. |
переход в ring0, методом callgate 
Загрузка ...
