I'm not very familiar with 'relative' address. I just usually don't know what it's 'relative to'! Anyway, not sure if this is a 'relative' address, I'm assuming it is! I disassembled a dll (opengl32.dll), and the functions point to what I assume is some kind of jump table. Anyway, an example is:
PS: What the hell is fs??? (MASM Reference says it's an 'extra segment'???) File Segment??? Is it relative to the file entry point? .code entry point? .data entry point? Data segment? Or what? I've seen this used in a few of the 'secrets', how do I find it in a DumpPE generated file?
Regards
5ED0289C glColor3f:
5ED0289C 64A118000000 mov eax,fs:[18h]
5ED028A2 FFA0E0070000 jmp dword ptr [eax+7E0h]PS: What the hell is fs??? (MASM Reference says it's an 'extra segment'???) File Segment??? Is it relative to the file entry point? .code entry point? .data entry point? Data segment? Or what? I've seen this used in a few of the 'secrets', how do I find it in a DumpPE generated file?
Regards
FS is a segment register, like the CS, DS, ES, SS and GS.
The Windows NT maintains a structure called as the Thread Environment Block (TEB) for every thread running in the system. The FS segment register is always set such that the address FS:0 points to the TEB of the thread being executed.
Read the Intel Developers Manual volume I - Section 3.4 for more details.
Regards,
Opcode
The Windows NT maintains a structure called as the Thread Environment Block (TEB) for every thread running in the system. The FS segment register is always set such that the address FS:0 points to the TEB of the thread being executed.
Read the Intel Developers Manual volume I - Section 3.4 for more details.
Regards,
Opcode
fs:[18h] points to TIB or TEB IIRC. Take a look at http://www.asmcommunity.net/board/index.php?topic=18797&pagenumber=1
Hi SubEvil,
That's a bizarre jump, in a single threaded application it will probably be 0 at that address. However since the TIB is an array of structures at some point if you have enough threads running it will eventually be written over with something. Since there is no documentation at all that I could find on the NT extensions to the TEB (NT version of TIB) I cannot say what it might be. However in NT the base address of the TEB is constant so you can use ReadProcessMemory to find the value at that location. There is no way I can see that this DLL is meant to run on 9x and NT unless they are writing into the TEB themselves in an effort to obfuscate the calls.
That's a bizarre jump, in a single threaded application it will probably be 0 at that address. However since the TIB is an array of structures at some point if you have enough threads running it will eventually be written over with something. Since there is no documentation at all that I could find on the NT extensions to the TEB (NT version of TIB) I cannot say what it might be. However in NT the base address of the TEB is constant so you can use ReadProcessMemory to find the value at that location. There is no way I can see that this DLL is meant to run on 9x and NT unless they are writing into the TEB themselves in an effort to obfuscate the calls.
May this helps too:
http://www.assembly-journal.com/include/getdoc.php?id=230&article=144&mode=pdf
w2k_mem output:
Regards,
Opcode
http://www.assembly-journal.com/include/getdoc.php?id=230&article=144&mode=pdf
w2k_mem output:
Microsoft Windows XP [vers?o 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
F:>w2k_mem +c
// w2k_mem.exe
// SBS Windows 2000 Memory Spy V1.00
// 08-27-2000 Sven B. Schreiber
//[imgmail]http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=a554abb99171394dae85da4176e938e3[/imgmail]
Loading "SBS Windows 2000 Spy Device" (w2k_spy) ...
Driver: "C:WINDOWSsystem32w2k_spy.sys"
Opening "\.w2k_spy" ...
SBS Windows 2000 Spy Device V1.00 ready
CPU information:
----------------
User mode segments:
CS : Selector = 001B, Base = 00000000, Limit = FFFFFFFF, DPL3, Type = CODE -ra
DS : Selector = 0023, Base = 00000000, Limit = FFFFFFFF, DPL3, Type = DATA -wa
ES : Selector = 0023, Base = 00000000, Limit = FFFFFFFF, DPL3, Type = DATA -wa
FS : Selector = 0038, Base = 7FFDE000, Limit = 00000FFF, DPL3, Type = DATA -wa
SS : Selector = 0023, Base = 00000000, Limit = FFFFFFFF, DPL3, Type = DATA -wa
TSS : Selector = 0028, Base = 80042000, Limit = 000020AB, DPL0, Type = TSS32 b
Kernel mode segments:
CS : Selector = 0008, Base = 00000000, Limit = FFFFFFFF, DPL0, Type = CODE -ra
DS : Selector = 0023, Base = 00000000, Limit = FFFFFFFF, DPL3, Type = DATA -wa
ES : Selector = 0023, Base = 00000000, Limit = FFFFFFFF, DPL3, Type = DATA -wa
FS : Selector = 0030, Base = FFDFF000, Limit = 00001FFF, DPL0, Type = DATA -wa
SS : Selector = 0010, Base = 00000000, Limit = FFFFFFFF, DPL0, Type = DATA -wa
TSS : Selector = 0028, Base = 80042000, Limit = 000020AB, DPL0, Type = TSS32 b
IDT : Limit = 07FF, Base = 8003F400
GDT : Limit = 03FF, Base = 8003F000
LDT : Selector = 0000
CR0 : Contents = 8001003B
CR2 : Contents = 7FFD3012
CR3 : Contents = 0F25F000
Closing the spy device ...
F:>
Regards,
Opcode
There is no way I can see that this DLL is meant to run on 9x and NT unless they are writing into the TEB themselves in an effort to obfuscate the calls.
It is not to obfuscate !
In WinDBG we have:
lkd> dt _TEB
+0x000 NtTib : _NT_TIB
+0x01c EnvironmentPointer : Ptr32 Void
+0x020 ClientId : _CLIENT_ID
+0x028 ActiveRpcHandle : Ptr32 Void
.......
.......
+0x7c4 glDispatchTable : [233] Ptr32 Void [B]<---- Is a dispatch table !!![/B]
+0xb68 glReserved1 : [29] Uint4B
+0xbdc glReserved2 : Ptr32 Void
+0xbe0 glSectionInfo : Ptr32 Void
+0xbe4 glSection : Ptr32 Void
+0xbe8 glTable : Ptr32 Void
+0xbec glCurrentRC : Ptr32 Void
+0xbf0 glContext : Ptr32 Void
+0xbf4 LastStatusValue : Uint4B
+0xbf8 StaticUnicodeString : _UNICODE_STRING
....
Regards,
Opcode
Hi Opcode,
That's what I meant actually, it appears that the DLL is writing to the fs segment as it is certain that it will be different under NT and 9x. Do you know whether that is in the specification for the TEB (or x86 OpenGL) or something that they decided on their own ? If it was an arbitrary descision it seems to have been made to obfuscate the call as they could have put the dispatch table anywhere they wanted for example in the DS segment where it would be expected.
That's what I meant actually, it appears that the DLL is writing to the fs segment as it is certain that it will be different under NT and 9x. Do you know whether that is in the specification for the TEB (or x86 OpenGL) or something that they decided on their own ? If it was an arbitrary descision it seems to have been made to obfuscate the call as they could have put the dispatch table anywhere they wanted for example in the DS segment where it would be expected.