Sorry guys, I'm VERY rusty on my Assembler, haven't been here for a long time!
Tried searching for my answers, but didn't find anything useful quickly and easily!
I'm working in OpenGL (and C/C++, Win32), for some performance reasons, I want to find a more direct approach to certain function calls.
Background: OpenGL32.dll has loads of functions. Many functions accept a different data type, handled by a different function, but accomplish the same thing. eg. glTexCoord2f and glTexCoord2d are identical except the one accepts a float (function ends with f) and the other a double (function ends with d). But one function will likely call the other, or they might both jump and call some other function. I want to know where they go, what is the final function, so I can skip a few jumps etc. Also, I know these are implementation specific, so ATI drivers might map differently than nVidia. And Win32 might be different to linux. But Imight be able to find a trend and I just want to know!
So, I disassembled OpenGL32.dll, but since I'm rusty, I'm kinda lost a bit.
Using dumppe I get to:
5ED02BD8 glTexCoord2d:
5ED02BD8 64A118000000 mov eax,fs:[18h]
5ED02BDE FFA0C4080000 jmp dword ptr
5ED02BF0 glTexCoord2f:
5ED02BF0 64A118000000 mov eax,fs:[18h]
5ED02BF6 FFA0CC080000 jmp dword ptr
Obviously a lookup table! Where to now?
Thanx!
Tried searching for my answers, but didn't find anything useful quickly and easily!
I'm working in OpenGL (and C/C++, Win32), for some performance reasons, I want to find a more direct approach to certain function calls.
Background: OpenGL32.dll has loads of functions. Many functions accept a different data type, handled by a different function, but accomplish the same thing. eg. glTexCoord2f and glTexCoord2d are identical except the one accepts a float (function ends with f) and the other a double (function ends with d). But one function will likely call the other, or they might both jump and call some other function. I want to know where they go, what is the final function, so I can skip a few jumps etc. Also, I know these are implementation specific, so ATI drivers might map differently than nVidia. And Win32 might be different to linux. But Imight be able to find a trend and I just want to know!
So, I disassembled OpenGL32.dll, but since I'm rusty, I'm kinda lost a bit.
Using dumppe I get to:
5ED02BD8 glTexCoord2d:
5ED02BD8 64A118000000 mov eax,fs:[18h]
5ED02BDE FFA0C4080000 jmp dword ptr
5ED02BF0 glTexCoord2f:
5ED02BF0 64A118000000 mov eax,fs:[18h]
5ED02BF6 FFA0CC080000 jmp dword ptr
Obviously a lookup table! Where to now?
Thanx!
Dump the data at fs:[18h] and see where does eax+8CCh and eax+8C4h points to.
Obviously a lookup table! Where to now?
Accept that a lookup table is being used and that you can't do anything about it :)
The implementations can change from driver to driver, from version to version. You're optimizing at a wrong level; premature optimization is the root of all evil.
fs:[18] isnt it nt_tib ??
!strct nt_tib on windbg used to show its size as 28 as far as i can remember
where does this 8cc and 8ch pop up from ?? :(
as far asi remember mattpietreks show tib also shows around 28
!strct nt_tib on windbg used to show its size as 28 as far as i can remember
where does this 8cc and 8ch pop up from ?? :(
as far asi remember mattpietreks show tib also shows around 28
well obvioulsy some other problems :(
i googled downlaoded the 300 kb odd opengl32.dll and disassembled it to find it entirely different :(
well that constant there for vftable gets filled here
so its pretty straight forward it seems
i googled downlaoded the 300 kb odd opengl32.dll and disassembled it to find it entirely different :(
7D11FED4 glTexCoord2dv MOV EAX,DWORD PTR FS:[18]
7D11FEDA MOV EDX,EAX
7D11FEDC ADD EDX,DWORD PTR DS:[7D1A4D70]
7D11FEE2 MOV EDX,DWORD PTR DS:
7D11FEE4 JMP DWORD PTR DS:
7D11FEEA MOV EAX,EAX
7D11FEEC glTexCoord2f MOV EAX,DWORD PTR FS:[18]
7D11FEF2 MOV EDX,EAX
7D11FEF4 ADD EDX,DWORD PTR DS:[7D1A4D70]
7D11FEFA MOV EDX,DWORD PTR DS:
7D11FEFC JMP DWORD PTR DS: ; OPENGL32.7D11F388
7D11FF02 MOV EAX,EAX
7D11FF04 glTexCoord2fv MOV EAX,DWORD PTR FS:[18]
7D11FF0A MOV EDX,EAX
7D11FF0C ADD EDX,DWORD PTR DS:[7D1A4D70]
7D11FF12 MOV EDX,DWORD PTR DS:
7D11FF14 JMP DWORD PTR DS:
7D11FF1A MOV EAX,EAX
7D11FF1C glTexCoord2i MOV EAX,DWORD PTR FS:[18]
00460078 88 F3 11 7D 80 F3 11 7D 83 F3 11 7D 8D F3 11 7D ??}??}??}??}
00460088 88 F3 11 7D 83 F3 11 7D 83 F3 11 7D 83 F3 11 7D ??}??}??}??}
00460098 A1 F3 11 7D 8D F3 11 7D 83 F3 11 7D 9C F3 11 7D ??}??}??}??}
004600A8 83 F3 11 7D 8D F3 11 7D 83 F3 11 7D 8D F3 11 7D ??}??}??}??}
004600B8 83 F3 11 7D 8D F3 11 7D 83 F3 11 7D 8D F3 11 7D ??}??}??}??}
004600C8 83 F3 11 7D 8D F3 11 7D 83 F3 11 7D 8D F3 11 7D ??}??}??}??}
004600D8 83 F3 11 7D 92 F3 11 7D 83 F3 11 7D A6 F3 11 7D ??}??}??}??}
7D11F388 XOR EAX,EAX
7D11F38A RETN 8
well that constant there for vftable gets filled here
7D1120D9 LEA ECX,DWORD PTR DS: <-----
7D1120E0 PUSH 4 ; /Protect = PAGE_READWRITE
7D1120E2 ---->MOV DWORD PTR DS:[7D1A4D70],ECX ; |
7D1120E8 PUSH 102000 ; |AllocationType = MEM_RESERVE|MEM_TOP_DOWN
7D1120ED PUSH 5FA00 ; |Size = 5FA00 (391680.)
7D1120F2 PUSH 0 ; |Address = NULL
7D1120F4 CALL DWORD PTR DS:[<&KERNEL32.VirtualAll>; \VirtualAlloc
so its pretty straight forward it seems
its 8c not 8cc? or 8c4 :(
thats available i was thinking how come some one can chage it so drastically
and i look at the
i saw it is 1 in eax so its 8c
so actually in teb there is pointers to gl
from undocumented ntinternals teb struct
PVOID? ? ? ? ? ? ? ? ? ?GlDispatchTable[0x118];
? ULONG? ? ? ? ? ? ? ? ? ?GlReserved1[0x1A];
? PVOID? ? ? ? ? ? ? ? ? ?GlReserved2;
? PVOID? ? ? ? ? ? ? ? ? ?GlSectionInfo;
? PVOID? ? ? ? ? ? ? ? ? ?GlSection;
? PVOID? ? ? ? ? ? ? ? ? ?GlTable;
? PVOID? ? ? ? ? ? ? ? ? ?GlCurrentRC;
? PVOID? ? ? ? ? ? ? ? ? ?GlContext;
and those reactos ppl have created some beautifull documentation which i havent seen yet
i mostly look at undocumented_ntinternals but during the googling i catched some
pretty good links from reactos documentation?
http://reactos.geldorp.nl/de/dd0/struct__TEB.html
from above articles deep link
typedef struct _TEB
00006 {
00007 char blah[0x7C4];
00008 PVOID glDispatchTable[0xA3]; /* 7C4h */
00009 PVOID glReserved1[0xA3]; /* A50h */
00010 PVOID glReserved2; /* BDCh */
00011 PVOID glSectionInfo; /* BE0h */
00012 PVOID glSection; /* BE4h */
00013 PVOID glTable; /* BE8h */
00014 PVOID glCurrentRC; /* BECh */
00015 PVOID glContext; /* BF0h */
00016 } TEB, *PTEB;
thats available i was thinking how come some one can chage it so drastically
and i look at the
7D1120D9? ? ? ? ? ? ? ? ? ? ? ? ?LEA ECX,DWORD PTR DS: <-----
i saw it is 1 in eax so its 8c
so actually in teb there is pointers to gl
from undocumented ntinternals teb struct
PVOID? ? ? ? ? ? ? ? ? ?GlDispatchTable[0x118];
? ULONG? ? ? ? ? ? ? ? ? ?GlReserved1[0x1A];
? PVOID? ? ? ? ? ? ? ? ? ?GlReserved2;
? PVOID? ? ? ? ? ? ? ? ? ?GlSectionInfo;
? PVOID? ? ? ? ? ? ? ? ? ?GlSection;
? PVOID? ? ? ? ? ? ? ? ? ?GlTable;
? PVOID? ? ? ? ? ? ? ? ? ?GlCurrentRC;
? PVOID? ? ? ? ? ? ? ? ? ?GlContext;
and those reactos ppl have created some beautifull documentation which i havent seen yet
i mostly look at undocumented_ntinternals but during the googling i catched some
pretty good links from reactos documentation?
http://reactos.geldorp.nl/de/dd0/struct__TEB.html
from above articles deep link
typedef struct _TEB
00006 {
00007 char blah[0x7C4];
00008 PVOID glDispatchTable[0xA3]; /* 7C4h */
00009 PVOID glReserved1[0xA3]; /* A50h */
00010 PVOID glReserved2; /* BDCh */
00011 PVOID glSectionInfo; /* BE0h */
00012 PVOID glSection; /* BE4h */
00013 PVOID glTable; /* BE8h */
00014 PVOID glCurrentRC; /* BECh */
00015 PVOID glContext; /* BF0h */
00016 } TEB, *PTEB;