Hi Dave, yes, i know that. I was just updating the info for BASE_STATIC_SERVER_DATA. :t
Btw...concening retrieving the Service Pack. In fact, the GetversionEx Api (and others), calls other functions inside ntdll that will have access to the PE info structure PEB.OSMajorVersionDis etc.
GetVersionEx call RtlGetVersion that uses the PEB addressing.
Also, if i recall well, RTlGetVersion also have acess to ntoskrnl.exe when the retrieved data from PEB fails.
In C, this small code can be done to access ServicePack info without using getversionEx
///////////////////////////////////////////////////////////////////////
// Kernel01.cpp : Call the RtlGetVersion from native API
// © by Thiseas 2011 for www.p0wnbox.com
//
#include "stdafx.h"
#include <Windows.h>
typedef void (WINAPI *pwinapi)(PRTL_OSVERSIONINFOW); //http://www.osronline.com/ddkx/kmarch/k109_452q.htm
int _tmain(int argc, _TCHAR* argv[])
{
RTL_OSVERSIONINFOW info;
pwinapi p_pwinapi;
ZeroMemory(&info, sizeof(RTL_OSVERSIONINFOW));
p_pwinapi = (pwinapi) GetProcAddress(GetModuleHandle(TEXT("ntdll.dll")), "RtlGetVersion");
p_pwinapi(&info);
return(0);
}
Reference above
http://0x191unauthorized.blogspot.com.br/2011/04/debugging-native-windows-api.htmlWhy not simply using GetVersionEx ?
Well there is nothing against it, but, if you are coding for WinNT family and above, and need some fast access to data, why use an Apis that may contains internally several uneeded lines of code, instead simply doing the direct way, that , in general is faster ?
Kernel32.dll was compiled probably with Frame Point omission activated. So there are several "bogus" code inside of it.
One example of a bad coding inside kernel32 is what i´m finding inside CreateToolhelp32Snapshot. I´m at the 4th day rebuilding this function and it supposedly just have to contains 3 major functions
Not to mention that i´m finding some bad usage of the stack for the local variables inside of some of them. (No wonder i was finding some left overs of some structure that was supposedly to be only a handle and vice-versa we talked about earlier)
