Valhalla Legends Archive

You can use my code here http://www.onlythechosen.com/lockdown-src.zip.  This is based from the original post by iago.

Quote from: Andy on November 10, 2008, 10:13 PM
Ya, I know. That's why it's always my stuff that ends up getting used.

Battle.net is a better place without a public warden implementation.  You should really rethink the implications of your release before doing it again.

Quote from: Andy on November 10, 2008, 09:34 PM
So you're letting Maiev handle everything for you... not quite a redistributable solution...

Redistribution was never my intention.

Quote from: brew on November 10, 2008, 09:10 PM
Yeah, Rob is using the same method to respond to the requests as Ringo right now. It's not by any means solved, though.

My method differs from Ringo's as it does not require the game to be loaded.  I patch required memory addresses within battle.snp and call the functions directly to handle warden in the same method that the game would.  This method has worked since first developing it, even when modules have changed.

Quote from: Hdx on March 10, 2008, 08:58 PM
Unless I was mistaken while reading Maiev.mod [SC's warden loader] only packets 0-2 are supported. It simply ignores other opcodes.

You are correct.  Maiev.mod only has handling for 0x00, 0x01, and 0x02.  Once the new module is prepared, Maive is unloaded and the new module is loaded in its place.  The new module takes over for Maive to handle packets, crypto, etc.

The current warden modules will handle packets 0x00, 0x01, 0x02, 0x03, 0x04.

For 0x02, there appear to be multiple 'commands' that the server could request.  These also differ per module.

The solutions for 0x02 in this thread should be considered temporary at best.  Blizzard could activate any of these other packets/commands at any given time.

Quote from: Ringo on March 03, 2008, 12:44 PM
Anyone wanna explain to me the update routine of that SHA1?

When I originally looked at lockdown, I used standard sha1 code and roughly modified the sha1_final routine.

http://www.onlythechosen.com/sha1_ld.zip if you want to take a look

Quote from: brew on November 10, 2007, 04:08 PM
I was looking into warden a bit more, and the send function is called by 03820078. Well, it's not called by that, but called a few bytes before that. That's just the ESI at the time of calling. I'm not exactly sure what module this thread is from, and nor does my debugger. It seems like this might be warden being executed? Am I on the right track, at least? And I'm still not able to find where it's being parsed at on receive :/... But I'm pretty sure it's not battle.snp anymore.

19019D90 is the warden handler function.  Its called from the function @ 190200D0 which is responsible for receiving the data and dispatching each packet.

In your case, 03820078 would be the address space of the loaded warden module.

There was an issue with the original dll that has been fixed.

http://www.onlythechosen.com/CheckRevision.zip

I also Included the bin files in the zip. 
STAR.bin Starcraft/Starcraft Broodwar/Starcraft Shareware/Starcraft Japan
DRTL.bin Diablo I/Diablo Shareware
W2BN.bin  Warcraft II BNE

Based from the code that iago released.

This should work on any x86 system.  Tested on windows/linux/freebsd.

http://www.onlythechosen.com/lockdown-src.zip

Quote from: Ringo on June 11, 2007, 11:50 AM

Code Select Expand


0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit


These are the closest values I could find.

0x19042168 = Unsure.  IDA states that this is FileTime.dwHighDateTime.  I did not debug to verify.

0x19043F60 = ValueString from 0x50

0x190467C8 = return of a call to GetTickCount

0x19046FF5 = a FileTime struct

I am unable to replicate your return values.

[ 6:51:08 AM ] [BNET] MPQName: lockdown-IX86-06.mpq
[ 6:51:08 AM ] [BNET] ValueString:  86 7F 36 E7 5B D2 19 73 50 14 4A 21 C9 84 15 0D

[ 6:50:45 AM ] [BNLS] Version: 10F0001
[ 6:50:45 AM ] [BNLS] Checksum: 3CF76238
[ 6:50:45 AM ] [BNLS] Digest:  57 A7 15 A6 71 8C 64 FD 1C 2B DA 35 6B 4B F6 78

[ 6:51:08 AM ] [LOCKDOWN] Version: 10F0001
[ 6:51:08 AM ] [LOCKDOWN] Checksum: 3CF76238
[ 6:51:08 AM ] [LOCKDOWN] Digest:  57 A7 15 A6 71 8C 64 FD 1C 2B DA 35 6B 4B F6 78

0x51 is sent @ 19036560.   The client token is set @ 19036400.

I would use a buffer larger than 16.  The return digest is variable length.  I have seen 16 and 17 digits.

While investigating, I ran across 2 other packets in battle.snp that I have never encountered.  They seem to be undocumented on bnetdocs as well.

0x17 and 0x24

I didn't examine them close enough to find their purpose.