• Welcome to Valhalla Legends Archive.
 

SID_SYSTEMINFO (0x2B)

Started by Barabajagal, February 06, 2007, 02:11 PM

Previous topic - Next topic

Barabajagal

Anyone happen to know how all these values are gathered? a packet log of SSHR returns:


Processors:   01 00 00 00
Architecture: 00 00 00 00
Level:        06 00 00 00
Timing:       00 05 00 00
Phys Mem:     00 04 00 00
Page Mem:     FF 0F 00 00
Free Disk:    17 0F 00 00


I've used a few API calls, but I can't get all the data to show up the same. Using GetSystemInfo, I can get the processor count, what i think is the architecture (dwOemID), and nothing else. using GetDiskFreeSpaceExA gets me nothing, since my free disk space is too big for a long to handle. Physical and page file memory much the same. Anybody got a clue as to how to get this data?

MyndFyre

Page Mem is 4095, which suggests to me that it's telling Blizzard your process memory, 4gb.

Free Disk is 3863.  Does your disk have a 1024-multiple of that available?
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Barabajagal

#2
I have 53,062,500,352 bytes free on my primary hard drive. Not divisible by 3863 evenly. My page file is set to 4095 megs, and I apparently can get that through dwPageSize with GetSystemInfo. I can also get the RAM size. Any idea about the other values?

Edit: Ran it again and got a Timing of B8 0B 00 00 this time.

So, to make it more clear, I still need to determine the Level, Timing, and Disk space.

TheMinistered

Isn't this what msdn is for?  All of this data should be easily available through some api call, which I dunno off the top of my head except the ones you listed.  BUT YOU SHOULD BE ABLE TO FIND THIS SHIT ;)

UserLoser

GetSystemInfo, GlobalMemoryStatus, GetDiskFreeSpace should be sufficient enough to build the packet.

Barabajagal

You'd think it would. But like I said, the client returns 3863 for the hard drive free space when it was 53,062,500,352 bytes, and I can't find any divisors to get that result reliably. There's also no Processor Level or Timing variables in any APIs I can find.

Skywing

Quote from: [RealityRipple] on February 07, 2007, 06:24 PM
You'd think it would. But like I said, the client returns 3863 for the hard drive free space when it was 53,062,500,352 bytes, and I can't find any divisors to get that result reliably. There's also no Processor Level or Timing variables in any APIs I can find.
Perhaps it might be more productive to analyze how an actual game client builds this message?

Barabajagal

How would I go about doing that? I have no knowledge in current day assembly (I only know MONITOR for the Commodore 64 and 128). If I did, I'd be working on Lockdown, not a packet that only one ancient client uses.

UserLoser

#8
Quote from: [RealityRipple] on February 07, 2007, 07:59 PM
How would I go about doing that? I have no knowledge in current day assembly (I only know MONITOR for the Commodore 64 and 128). If I did, I'd be working on Lockdown, not a packet that only one ancient client uses.

Then perhaps you should be spending your time on something else, but like I said, GetDiskFreeSpace will give you what you need for the last part of that message.

Skywing

#9
Quote from: [RealityRipple] on February 07, 2007, 07:59 PM
How would I go about doing that? I have no knowledge in current day assembly (I only know MONITOR for the Commodore 64 and 128). If I did, I'd be working on Lockdown, not a packet that only one ancient client uses.
There is no time like the present to learn.

I would recommend getting yourself a diassembler, a debugger (includes extensive documentation and some tutorials and walkthroughs on various real world debugging scenarios), and some x86 assembly language documentation.  Some documentation on Win32 calling conventions would additionally be useful, as you're likely just going to need to figure out some simple calls to standard Win32 functions.  You can find information on Win32 APIs online at MSDN.

All of the above are freely available, and spending a short time learning how to use them will be the start of building some valuable skills for a software development job to boot.

Barabajagal

Thank you for the links Sky, I'll check em out when my computer isn't being such a little bitch and I can replace the RAM that's been corrupted.
UserLoser, GetDiskFreeSpace returns: 8 sectors per cluster , 512 bytes per sector , 16038174 free clusters , 29302552 total clusters, and SSHR now gives me 1F 0F 00 00 (I reformatted completely last night, so the numbers are a bit different now). 1F 0F 00 00 means 3871, right? I still don't see how it gets the value...

Barabajagal

Well that's nice... I now get DF 05 00 00 (1503) for a page file size, since I set my page file to be anywhere from 1024 megs to 4095 megs. The GetSystemInfo API returns 4096, though. Guess I'll have to wait till I can disassemble it myself.

UserLoser

IIRC, performs math on sectors per cluster, bytes per sector, and free clusters, not sure though.

Barabajagal

I've tried  bytes per sector * sectors per cluster * free clusters, which gives me 65692360704 free bytes total. Divide that by 3871 to see if there's any multiple there, and you get 16970385.095324205631619736502196. Definitely not an even multiple. I've tried other such combinations of the values, and gotten nothing that links 3871. If I'm doing something wrong, I'd really like to know.

Barabajagal

#14
Well, if i use the non-standard SYSTEM_INFO definition, I can get the Processor Level, but I still can't figure out the timing or how to get the correct hard drive info. The disassembler is too big for me to download on dial up, so that's not really an option for me at the moment.

I've tried a few logs to figure out what the timing is, and it started at 2840, went up to 2850 the next time, then 2860, 2870, and back down to 2850. I'm a bit confused as to what it is...