Profile of RageWithTheMachine

UPDATE: The top post now links to the new file.

I don't check on it so often, since I don't actually play the eastern front version.

Replay Manager is a program that can sort out some information from COH2 replay files.

Some technical notes for people who are interested in making a COH2 replay analyzer.

In closed beta I reversed the savefile protocol. There've been only minor
changes in release. There are 3 layers of packets within packets with their own
headers. It's very much like analyzing a stack of IP protocols in Wireshark. I
made a console app that breaks it down and dumps out messages that are strings
of bytes; there is one message for every command or every thing that every
player does, with a timestamp. Like Dyxtra's 'COHRA Helper' which is still
available from http://dyxtra.com/coh.

Before it's useful, somebody would need to do the slightly autistic job of
mapping specific numbers to all specific units and commands. Staring at the
strings you can see that a certain column has the 'command' byte where one
number should be 'move' and another 'build' etc. For 'build', another column has
specific numbers for grenadier, mg42 etc.

The file header contains players' name and faction. As far as I can tell, the
actual messages in the replay file link to specific map positions (0-7), rather
than specific players. It's a separate problem to link players to map positions.

You could see this problem when trying to use Dyxtra's pretty titties program on
a 4-8 player COH1 game with random positions turned on; he interpreted the
command logs right, but they could be randomly assigned to the wrong player. He
used a partial hack; if you typed a chat message during the game, he'd obtain
the player ID from that. Chat messages are not stored in COH2 replays.
Furthermore, all COH2 games are random position.

In your user directory there's a subdirectory 'LogFiles', and inside there's a
number called 'RandomStreamSeed' for each game. You find that 32-bit integer in
the replay file header. If you modify it with a hex editor, you'll see that the
players map positions are swapped around before the replay goes OOS. This means
the same RNG stream that determines whether a grenadier hits, misses or crits is
also used for mapping the players. Unless I missed some data in the header, you
can't make a working replay analyzer for 4-8 player games without disassembly.
I'd have to beat the program into submission for running under debugger and
trace the code that seeds the RNG and produces something to map the players.
Essentially the same treatment administered by 'crackers' and other hostiles.

Alternatively one could use the 'social' kind of engineering instead of
'reverse', like, just ask relic to put the numbers in the header. For 1v1 games
there should be no problem, as you can just see which log produces
german/russian units and figure the correct player.

I was kinda half done with the other thing in beta but had a hardware failure,
it was time to buy new comp anyway and it takes me several weeks to install and
configure a new workstation with vsice and the whole circus. Also, I loose
interest in hacking during summer, so the protocol analyzer's been sitting on my
drive for 2 months and isn't going anywhere until winter. And now that I've seen
the released game, I'm starting to ask 'why bother?'. Where the hell is the
leaderboard and the ELO rating system. All I see is xp rewards for playing, not
winning. Who are these people who require virtual rewards every 40 minutes, even
when loosing, and why would I want to play a game with them? You'd think a real
person could go for a couple days without a reward.

If somebody else is into hexadecimal and C coding in summer, I could possibly
send over the source code for the protocol analyzer app. It currently just organizes
the data into strings with no interpretation of specific units, commands.

Administrators should be aware that posts of this nature constitute a probe of
the attack surface of the application.

Code injection is an invasive modification or addition to the application's
private program space. Once inside the target process, injected code will
already have bypassed walls against external threats. It will have full access
to all internal information, and could easily transfer that to any device, the
existence of which the sorry 'Screenshotter' program is not even aware.

The idea that such extreme measures should be needed to mess with simple
graphics settings, is madness. By gaining acceptance for injectors, you open the
floodgates for all the evils in the universe. It is highly unlikely that anyone
pushing this subject has any interest in small insignificant graphics settings.
If you believe in that, go play with the nvidia control panel for two hours to
make your game look "better".

If Relic under Sega aims to be serious about competitive multiplayer, they
should care about their application's integrity. External programs can detect
specific threats, like anti-virus do. But as any CoH strategist would know, you
don't want to be in a position where you are reacting to the enemy's moves. A
new threat comes out, and works until it is identified. Hostile buys a new game
key once they go cheap, and makes a slightly modified version. Endless pain.

The people who are best positioned to verify the integrity of the application's
internal space, are the people who made it. They know what's supposed to be in
there, and not. If they didn't already do so, Relic can protect CoH2 against
entire categories of threats by studying and implementing application security and
integrity. Like Microsoft did with Patchguard.

An absolute ban on injected code goes without saying, but it takes some effort
to detect it. Not that much effort really, once you know the APIs.

Obviously, some programs like Steam, and certain advanced firewalls, may need to
inject, but in those cases the DLLs will be digitally signed by a serious
company.