Sysdm.cpl

[betamaster]

What file is responsible for the fact that in the sysdm.cpl file we have written such a number build. I know that the sysdm.cpl file isn't generating it build. So please say which file is responsible for it.

[empireum]

Maybe it's reading the build number from the kernel...

[betamaster]

Maybe it's reading the build number from the kernel...

OK, i check this later.

[Luckie]

if you mean the Year by Version 2002 for example, this is a string in the sysdm.cpl

[empireum]

I think he means the actual build number which is shown in the system properties in all versions prior to XP. Like this:

[Vista Ultimate R2]

The string in sysdm.cpl for Version 2002 doesn't actually have any text in it though, so I think it must be getting the value from somewhere else. The build number isn't in sysdm.cpl at all - it is in winver.exe but again isn't actually in the program itself. It seems likely what was said about it checking the kernel's version number.

[empireum]

Yeah, I think it is because in NT 3.51 and 4.0, you could manipulate the kernel's version using imagecfg and then winver et al would also be fooled.

[Luckie]

The string in sysdm.cpl for Version 2002 doesn't actually have any text in it though, so I think it must be getting the value from somewhere else.

Nope. Open the file and goto String-Table-13 and look at the Value 195

The Numbers 5.00.2195 are easy to detect.

Code: Select all

// Try calling GetVersionEx using the OSVERSIONINFOEX structure.
  // If that fails, try using the OSVERSIONINFO structure.
  ZeroMemory(@osvi,sizeof(TOSVersionInfo));
  osvi.dwOSVersionInfoSize := sizeof(TOSVersionInfo);

  bOsVersionInfoEx := GetVersionEx(osvi);
  if(not bOsVersionInfoEx) then begin
    osvi.dwOSVersionInfoSize := VERSIONINFOSIZE;

    if(not GetVersionEx(osvi)) then begin
      Result := 'Fehler bei der Ermittlung der Windows-Version';
      exit;
    end;
  end;

Now you can get the Values with:

Code: Select all

osvi.dwMajorVersion (Majorversion 6 = WIndows Vista, osvi.dwMinorVersion and Buildnumber by using LOWORD(osvi.dwBuildNumber)

[betamaster]

When I open sysdm.cpl from neptune in XP i see number build from XP

[empireum]

Yes, of course, because it's reading from the kernel...

[betamaster]

Yes, of course, because it's reading from the kernel...

Ok, thank you

[ppc_digger]

Code: Select all

// Try calling GetVersionEx using the OSVERSIONINFOEX structure.
  // If that fails, try using the OSVERSIONINFO structure.
  ZeroMemory(@osvi,sizeof(TOSVersionInfo));
  osvi.dwOSVersionInfoSize := sizeof(TOSVersionInfo);

  bOsVersionInfoEx := GetVersionEx(osvi);
  if(not bOsVersionInfoEx) then begin
    osvi.dwOSVersionInfoSize := VERSIONINFOSIZE;

    if(not GetVersionEx(osvi)) then begin
      Result := 'Fehler bei der Ermittlung der Windows-Version';
      exit;
    end;
  end;

What language is that? It looks like a hybrid between Pascal and REXX.

[rawr]

Short of disassembling and/or debugging symdm.cpl, there's no way to really know. But empireum seems correct; take a look at the imports for sysdm.cpl:



Now maybe somebody can explain this to me:



In a search, 050301-1519 (unicode) is found in user32.dll.. which hasn't been updated since 2 March 2005, even though kernel32.dll dates to 5 July 2006. I guess winver wants to report on the client side of Windows, but still seems odd. Which build number is the 'correct' one, or can such questions only be answered for a given release, not a system that has had patches applied?

[betamaster]

And where i find this file

[empireum]

And where i find this file

Both kernel32.dll and user32.dll are very probably in the system32 dir.

[betamaster]

And where i find this file

Both kernel32.dll and user32.dll are very probably in the system32 dir.

Yeah, but in system32 is too many files

[empireum]

And where i find this file

Both kernel32.dll and user32.dll are very probably in the system32 dir.

Yeah, but in system32 is too many files

Are you kidding me or what??? I gave you the name of the file and the directory where it is most likely in. What else do you need to find a file???

[betamaster]

And where i find this file

Both kernel32.dll and user32.dll are very probably in the system32 dir.

Yeah, but in system32 is too many files

Are you kidding me or what??? I gave you the name of the file and the directory where it is most likely in. What else do you need to find a file???

Sorry

[empireum]

Please think before you type, okay?

[betamaster]

Please think before you type, okay?

OK. I edit kernel32.dll and user32.dll version and i not have change in sysdm.cpl I try to edit sysdm.cpl

[Battler]

I think the Windows dialog boxes read the version strings from NTLDR, and related files in the root directory of the boot drive.

I know this, because I have tried to fool Windows 2000 to become version 5.5.3295 instead of 5.0.2195, and no matter, what file I modified, Windows was still reporting version 5.0.2195 - then I found out, that it's one of those root directory files, that Windows gets the version from, so I tried to modify those, but then NTLDR started giving problems.

[empireum]

Which of the root directory files was the one you modified?

[betamaster]

OK. I check this ntldr file.

[jimmsta]

I think the Windows dialog boxes read the version strings from NTLDR, and related files in the root directory of the boot drive.

I know this, because I have tried to fool Windows 2000 to become version 5.5.3295 instead of 5.0.2195, and no matter, what file I modified, Windows was still reporting version 5.0.2195 - then I found out, that it's one of those root directory files, that Windows gets the version from, so I tried to modify those, but then NTLDR started giving problems.

NTLDR is version-less. Sure, there's multiple versions of it, and it has been superceeded by vista's Bootmanager, but it does not contain OS version information.

Running Windows 2000 SP4's sysdm.cpl file on XP, shows that the data is indeed found within the system - The function in kernel32.dll only gets the major and minor versions out of another file.

If you run Sysinternals' tool "filemon", or "processmon", you can watch the sysdm file query data through kernel32, and find out exactly where the values are coming from, instead of searching for a needle in a haystack.

edit: it seems to be located within ntdll.dll, which might be a bad idea to hack into a different version, especially if you're dealing with WPA (Windows Activation).

[Battler]

- empireum: I modified NTOSKRNL, I think.

- jimmsta: It's not in NTDLL.DLL. I did hack that, but Windows was still reporting 5.0.2195.