Starts at 190333C9 in battle.snp, after some weak-as-hell static string encryption. Discuss.
My guess: The last name of the blizzard employee who implemented it?
Isn't Maiev a warcraft III character?
Quote from: FrostWraith on February 08, 2008, 10:57 PM
Isn't Maiev a warcraft III character?
Yes. Big surprise that Blizzard named something after a character that they created. PsiStorm.dll was a Starcraft activity. Woo. Who cares?
thought this was figured out years and years back that maiev.mod is the always running warden module ?
Quote from: UserLoser on February 09, 2008, 04:22 AM
thought this was figured out years and years back that maiev.mod is the always running warden module ?
eh? the always running one? is this warcraft 3 specific? 'cause if it is, i'm wasting a shitload of time ;P
@FrostWraith: according to WoWWiki it's Maiev Shadowsong, a priestest of Elune during the War of the Ancients.
One of 'her' aliases is the "Hand of Justice"... oooo
EDIT**
I was reading that wiki arcticle a bit more and here's what i found:
Quote
The "death" originates from the mission, The Search for Illidan, in which the mission objective is to slay the guardians of the cage, the Watchers, carrying Illidan to the Sentinels base. There were four guardians included Maeiv;
Lord Illidan has been captured by the cunning Warden in a cage of magical enchantments. Slay the guardians of the cage and take it from the Night Elves before they reach safety the safety of their base.
yes war3 specific
I believe that Maive.mod is initially loaded, before a new one is downloaded/run. The code/decryption key are stored as constants, and it's decrypted before receiving any "warden" packets.
Constant decryption key? Might it be "WBc+8F%R" by any chance?
It's 16 bytes, but yeah, it starts with that.
Hmm, does anyone have a copy of the mac storm.dll handy?
You can extract the Mac version from Install.exe if you're stuck. But it's version 1.04, so it isn't especially useful. It's the only version I've ever used, though.
And incidentally, I was making breakfast when I realized that I was wrong -- that WBc+.. string isn't the key, that's the encrypted module. The key used is referenced right above it.
Heh, i realized that it couldn't have been the key. What the 3rd parameter's offset is pointing to, is exactly 16 bytes. It's 57 42 63 C9 38 46 25 52 00 71 E4 47 00 40 DD 84. Just curious, why 16 bytes? Is starcraft's the same len? Please don't tell me it's md5...
Quote from: brew on February 10, 2008, 01:13 PM
Heh, i realized that it couldn't have been the key. What the 3rd parameter's offset is pointing to, is exactly 16 bytes. It's 57 42 63 C9 38 46 25 52 00 71 E4 47 00 40 DD 84. Just curious, why 16 bytes? Is starcraft's the same len? Please don't tell me it's md5...
MD5 isn't an encryption algorithm, it's a hashing algorithm.
Quote from: brew on February 10, 2008, 01:13 PM
Heh, i realized that it couldn't have been the key. What the 3rd parameter's offset is pointing to, is exactly 16 bytes. It's 57 42 63 C9 38 46 25 52 00 71 E4 47 00 40 DD 84. Just curious, why 16 bytes? Is starcraft's the same len? Please don't tell me it's md5...
The third parameter is the decryption key.
.text:19033697 push offset default_warden_key ; KeyString
.text:1903369C push 12B3h ; EncryptedSize
.text:190336A1 push offset default_warden_module ; "WBc+8F%RqSG@¦ärBµs}\x11\"-<+\x02±ç¦y+\x168µ3+ûxŪ"...
.text:190336A6 call sub_190333C0
And yes, there is some MD5 involved, but not here.
Quote from: MyndFyre[vL] on February 10, 2008, 01:58 PM
Quote from: brew on February 10, 2008, 01:13 PM
Heh, i realized that it couldn't have been the key. What the 3rd parameter's offset is pointing to, is exactly 16 bytes. It's 57 42 63 C9 38 46 25 52 00 71 E4 47 00 40 DD 84. Just curious, why 16 bytes? Is starcraft's the same len? Please don't tell me it's md5...
MD5 isn't an encryption algorithm, it's a hashing algorithm.
was talking about the key generation.
@iago: thanks! You're good :P
Also, how often do the modules update? I was able to convert it from the hex view in ollydbg to binary data, then disassemble with ndisasm, but then when i go back to check it again (3 days later), my addresses aren't valid! :(
Quote from: brew on February 10, 2008, 02:35 PM
Also, how often do the modules update?
About every hour or so. How ever it doesnt update once your connected, you would only notice it on a new connection.
It might/can update in the middle of an idle connection, but i have never seen it do so.
I have found module updates to be the biggest pain in the ass :(
Aside, good work brew, sounds like your getting somwhere! :)
At 19032FED, esi == the address of the encryption key, amirite?
And edi would sensibly be the size of it ;) exactly as i first suspected, it's 24 bytes. The other param is just the address of the wardendata arg to parse0x5e (modifies byref to make some kind of numerical number). I'll look into it more tomorrow.
Quote from: brew on February 11, 2008, 09:51 PM
At 19032FED, esi == the address of the encryption key, amirite?
And edi would sensibly be the size of it ;) exactly as i first suspected, it's 24 bytes. The other param is just the address of the wardendata arg to parse0x5e (modifies byref to make some kind of numerical number). I'll look into it more tomorrow.
What encryption algorithm uses a 192-bit key?
Quote from: brew on February 11, 2008, 09:51 PM
At 19032FED, esi == the address of the encryption key, amirite?
And edi would sensibly be the size of it ;) exactly as i first suspected, it's 24 bytes. The other param is just the address of the wardendata arg to parse0x5e (modifies byref to make some kind of numerical number). I'll look into it more tomorrow.
Nope and nope.
Try again next time!
Quote from: MyndFyre[vL] on February 11, 2008, 10:35 PM
What encryption algorithm uses a 192-bit key?
IIRC RC4 can use any sized key.