Read-protected memory--how to deal with it?

[Stwong]

So I'm attempting to "debug" Starcraft.  You all know what I mean

Apparantly, it has certain blocks of read-protected memory that I can't really read.  I don't know much about the protection and stuff, but I'm an administrator and can't search it with tsearch, or windbg--even if windbg is the process that created the SC process.

Is there some kind of easy technique to unprotect it that I don't know of, or is there nothing I can do? (Other than install softICE)

edit:  Windows 2000 has this problem, any searches on Windows 98 conveniently seem to work.  Also, there ARE specific areas of memory that are protected each time.

When talking to iago about this problem a few months ago, he seemed to imply that his XP installation experienced the problem, and something randomly fixed the problem.

Next issue: I'm talking about specific areas of the memory, not an entire process's memory.  I can find the unit structures, but not the structures loaded from the .bin files--even when I know exactly how to find them from experiences on Win98.

I'm not sure if SoftICE would work, being a kernel level debugger, but if I remember correctly, there's no real ways to do progressive searches in it, or uncertain searches, so getting it working with TSearch would be the best solution--eg, with any old memory searcher.

Installing Win98 is an option, of course, but it would be much preferred to be able to find a decent solution under Win2k.

I have a feeling that whatever memory allocation functions Windows uses could be breakpointed, modified to remove the read-protection or whatever it is, which would be a solution.  Anyone have any leads on this?  (I, as of yet, have yet to see an alloc() / malloc() fxn in Windows...)

edit #2: even acknowledgement of the problem on Windows 2000 would be a decent reply.  I'm interested in seeing if this problem affects ALL win2k systems, or if there are exceptions.  And if there are exceptions, potentially what may have caused them.

A while back I was distributing a program that, oddly enough, caused you to not be able to log on to battle.net when run.  The same program, when ported from VB to C, worked perfectly.  I'm pretty sure there's a LOT in the picture that I'm accidentally not taking into account.  (The program just createprocess()'ed SC.exe suspended and resumed it.  If you want source--pm me.  It'd be totally off topic now.)

The point I'm getting at is that there's something that's radically different about how Win9x handles memory and how Win2k handles memory, and insight on it would be appreciated.  Seeing as 2k = NT-based, and 9x = it's own branch, the fact that there are differences is understandable.  It's just that I can't seem to figure out how to compensate for them.

[Skywing]

I'm not sure what you're referring to.  Maybe you're trying to access some memory that hasn't been allocated yet?  For instance, battle.snp is loaded dynamically, so you can't expect to write to it if you create the process suspended and don't run it before you start poking at it.

[Stwong]

First off: Not poking anything at the moment.  Just trying to read.  As in, search through it, whatever.

I don't know how exactly to put it, but there's certain parts of SC that I can access under certain conditions under Win98, but not on Win2k.

The chat box is a good example, since it's so easily changable and searchable.  Win98, I load up Starcraft, load up Tsearch, set Tsearch to open Starcraft.exe, start a game, type 'asDF' in the chat box, leave it hanging.  I then do a hex search, with case-matching on, for 'asDF', and instantly find one value.  Bingo.  Then I'd go on and search for the pointer, since I know it's dynamically allocated.

Do the same on Windows 2k, and nothing comes up on the hex search.  Not in TSearch, not in WinDBG, and not in Magic Trainer Creator.  None of the tools people have reccommended found it in that case.

I'm assuming that it's read-protected or something since it simply hides from me, even though I know it's there.  (Orlphar suggested searching for it in Unicode, which failed as well, unless it's reverse or something.  Which wouldn't make any sense at all, since switching OS shouldn't reverse a string, last I checked.)

Thanks for the response.

[Skywing]

The edit control doesn't necessarily store it's text in a place that you could easily access.  In particular, I don't think it's going to be visible in your address space unless you've already requested it once with GetWindowText, causing it to be cached...

Regardless, that's an operating system thing you're messing with, and not Starcraft, so it shouldn't be surprising that it works differently on Win2K than Win9x.

[MyndFyre]

Out of curiousity, is it possible that between the two programs there's a difference in storing Unicode vs. ANSI because of the difference between Windows 98 (using the XxxA functions) and NT (using the XxxW functions)?

[Adron]

Yes, give us another example because the chat box is a bad one.

[Skywing]

Out of curiousity, is it possible that between the two programs there's a difference in storing Unicode vs. ANSI because of the difference between Windows 98 (using the XxxA functions) and NT (using the XxxW functions)?

NT always stores the Unicode form, no matter which function you use.

The difference here is probably that Win98 stores the memory containing the edit box's text somewhere accessible by the process, and NT stores it in kernel mode-only memory.

[Stwong]

The difference here is probably that Win98 stores the memory containing the edit box's text somewhere accessible by the process, and NT stores it in kernel mode-only memory.

That sounds like a dead accurate description of the problem...

@ the unicode: tried it at the suggestion of Orlphar between #1 and #2 posts... didn't work.

Adron: Eh, I should find one, but it seems like the chat related stuff is the brunt of it.

[iago]

When you say "edit-box", do you mean the in-game text where you hit enter and type, or the channel one where you type.  They're handled very differently.

[Stwong]

in-game text, in this case.

I do believe I have notes on the offsets of the channel one which I found a while ago on 2k.  Not sure if I found the pointer, but I know I found it and modified it more than once.

[Magickian]

I've had no problem searching for pregamechat and ingamechat text on win2k SP4.  My results were not in unicode and I used both windbg and one of my own personal utilities for searching.  I don't see any reason why the process would hide its memory from you.  You may want to login as admin if you aren't already.

A quick check leads me to believe that the pregamechat pointer can be obtained by first dereferencing storm.dll offset 0x15042F96, adding 0x52DA to it, then dereferencing again, then adding 0x94 should put you at the text.  For ingame, I believe it is: Dereference at 0x15049CD0, then dereference again (no adding involved), then add 0x94. 

Although I only tried both of these once, I believe that is the proper way to reach em. 

in-game text, in this case.

I do believe I have notes on the offsets of the channel one which I found a while ago on 2k.  Not sure if I found the pointer, but I know I found it and modified it more than once.

[iago]

I couldn't find it, then I reinstalled and I could.  It's kinda weird.

[Stwong]

Bizarre.  I guess I'll back up all of my stuff and reinstall sometime, then get back to you all.

[Adron]

Bizarre.  I guess I'll back up all of my stuff and reinstall sometime, then get back to you all.

I'd like to just point out that as we have said, there is no read-protected memory that Starcraft uses. There is kernel memory, available only to drivers, but it's not something the game can ever allocate or use directly.