I'm at a point where I can fairly confidently say that I've got the new Warden at a place where it's almost ready to go.  It's unencrypted, downloaded, etc.  For a number of reasons, in order to handle it, I'll need to spawn a surrogate process and interact with it via IPC.  Not a big deal, I've done IPC before, but what I'm most interested in from some of you guys are:

* If I mapped in the whole files of the games (so that it didn't depend, for instance, on the .ini files that have floated around on the forum), I'd need to create separate processes for each game, right?  I'd bet (I haven't checked) that their images overlap in memory.
* Do you recommend hosting my own code in a specific region in memory (i.e. by creating different base addresses for my assemblies)?  Obviously I'll have to avoid the game memory.
* Is it adequate to load the game files using LoadLibraryEx with DONT_RESOLVE_DLL_REFERENCES, or should I plan on loading them manually?
* Is it possible to execute multiple Warden sessions within a single process, or do I need to spawn multiple/recycle processes for each connected client?  I'm assuming it would be possible to execute multiple sessions provided with enough memory.

Thanks!

[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]
For a number of reasons, in order to handle it, I'll need to spawn a surrogate process and interact with it via IPC. [/quote]Whee?
[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]* If I mapped in the whole files of the games, I'd need to create separate processes for each game, right?  I'd bet  that their images overlap in memory.[/quote]You would be correct, each of the main executables share the same base address, and considering that none of them contain Reloc information, and warden uses absolute addresses when dealing with the main executable... It'd be a bitch and a half.
[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]* Do you recommend hosting my own code in a specific region in memory?  Obviously I'll have to avoid the game memory. [/quote] If you figure a way around the hard coded addresses you will prolly figure a way around this.
[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]* Is it adequate to load the game files using LoadLibraryEx with DONT_RESOLVE_DLL_REFERENCES, or should I plan on loading them manually?[/quote]It's possible with some game files, but others (game.dll) I had to resort to loading manually. And again you'll run into issues when loading multiples of the executables.
[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]* Is it possible to execute multiple Warden sessions within a single process, or do I need to spawn multiple/recycle processes for each connected client?  I'm assuming it would be possible to execute multiple sessions provided with enough memory.[/quote] Warden's Initial Init() function returns all the state data Warden needs to be run, so that if you simply pass around the proper information, you can run as many connections as you want off the same 'instance' of the code.

I assume your final intent is to have warden able to run in a 'clean' environment? And let it handle everything raw. I fiddeled with that idea for a while, then figured it'd be better to know what Warden was doing, and have more control over it, and it'd be a bitch to setup an environment that supported all games at all times.

[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]
* If I mapped in the whole files of the games (so that it didn't depend, for instance, on the .ini files that have floated around on the forum), I'd need to create separate processes for each game, right?  I'd bet (I haven't checked) that their images overlap in memory.
[/quote]
You would. For example, Warcraft 3's Storm loads at the exact same base address as Starcraft's, however they different binaries. I reckon that if a module were to request Storm, it'd like the flavor of Storm that client uses.

[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]
* Do you recommend hosting my own code in a specific region in memory (i.e. by creating different base addresses for my assemblies)?  Obviously I'll have to avoid the game memory.
[/quote]
Yes. Pehaps the preferred base address of your module should be 0x70000000, or something like that. Most developers wouldn't dream of putting something there, since it's relatively close to Windows' DLLs.

[quote author=MyndFyre link=topic=18029.msg183166#msg183166 date=1249375869]
* Is it adequate to load the game files using LoadLibraryEx with DONT_RESOLVE_DLL_REFERENCES, or should I plan on loading them manually?
[/quote]
LoadLibraryEx with LOAD_LIBRARY_AS_DATAFILE works fine for me. Just remember, if you're using LoadLibraryEx, to trim off the 2 low bytes. Kernel32 has a penchant for tacking on flags to the address it's loaded to (remember, it's a 'handle' not a 'base address', so they can get away with that....).


Although it is a noble gesture, I don't think it'd be worth all the work to split off a warden worker process and have it handle all the packets on its own. That kind of sounds like the early Warden 'solutions' that'd require Starcraft to be open in order to function. I do realize it seems appealing to have an always-going-to-work-unless-they-break-it-on-purpose solution to Warden, but it's doubtful we'll see any changes in this cheat detection over BNCS for the 'legacy' clients (Warcraft 3, Starcraft, etc.)
I do expect a more integrated anti-cheat solution with StarCraft 2.

Thanks for the responses guys.

[quote author=brew link=topic=18029.msg183169#msg183169 date=1249402036]
Although it is a noble gesture, I don't think it'd be worth all the work to split off a warden worker process and have it handle all the packets on its own. That kind of sounds like the early Warden 'solutions' that'd require Starcraft to be open in order to function. I do realize it seems appealing to have an always-going-to-work-unless-they-break-it-on-purpose solution to Warden, but it's doubtful we'll see any changes in this cheat detection over BNCS for the 'legacy' clients (Warcraft 3, Starcraft, etc.)
I do expect a more integrated anti-cheat solution with StarCraft 2.
[/quote]
The reason I need to split off a separate process is that I'm using C#, and the default compilation target for .NET programs is platform-agnostic (x86 vs. x64).  I'm trying hard to preserve that because of compatibility difficulties on the x64 platform when it comes to plugins and whatnot.  I generally tend to consider it a "best practice" to retain that platform neutrality unless the application specifically requires it.  Here, my client doesn't require it, just a specific feature of the protocol.  I can compile the surrogate process to target x86 and then enable the two to talk, and I get a couple extra benefits: dangling pointers or other C-based language faults just crash the surrogate and not my client, and it seems like I still can offload new/unknown implementations to that.

Again, thanks guys for confirming what I'd suspected about the behavior of the modules.