Valhalla Legends Archive

There's nothing hard to trace about it... The message ID is always the second byte, and seeing the flow from there should be a simple matter.

Alright, I've just updated this to add backward compatibility with classic D1 players using a second D1 connection. Works pretty well, I must say.

And the LORD did grin. And the PEOPLE did FEAST upon the lambs, and sloths, and carp, and orangutans, and breakfast cereals, and fruit bats, and large chunks of pineapple.

Quote from: MysT_DooM on April 29, 2012, 08:13 PM

Quote from: RealityRipple on April 28, 2012, 04:13 PM
I sent Invert a link to a DRTL iso.

I've also successfully completed this project's goal, and learned some fun things about the way the client works.

what did you learn

Let's see...

The client is intelligent enough to know what device the bnet server it's connecting to is on, and only listens for peer UDP connections over that device. The result of this being that using localhost for a server renders UDP useless unless proxied. However, Storm seems to not like localhost communications, so the only thing that gets proxied is SID_CLIENTREQ. This does have the upshot of my allowing to choose a device by local IP address and d1 will follow.

The client id (statstring) sent from the server in SID_ENTERCHAT is stored in the client and compared to game lists to determine if the game is for the client. I had to read D1's sent statstring, store it, and replace BNet's response statstring with the one D1 supplied in order to join D1 games without using the ol D1 ignore invalid character hack. The rest of the statstring is used to determine which product-specific channels it can enter, for example Rogues Gallery.

Warcraft II won't show any details about D1 games, but D1 will show the W2 map name as the char name for W2 games. It's sort of amusing.

I sent Invert a link to a DRTL iso.

I've also successfully completed this project's goal, and learned some fun things about the way the client works.

Quote from: MysT_DooM on April 27, 2012, 06:59 PM
woulda been cooler if d1 icon showed up on chanlist.  not since you went through war2, and I cant think of any hacky way to make it happen atm; cool though
ktbpa

It'd be locally possible, and your D1 char icon shows up for games you create to other D1onW2'ers... But the only clients that can edit their statstrings and possibly spoof d1 chars are non-cdkey'd clients that would defeat the purpose of this experiment. @.@

Yeah... I even threw in the ol d1 bypass legit char check hack so d1 users can join d1 games through the w2 game list. I'm still working on getting UDP to function accurately, but all SID communication is perfect. D1 even makes operators white-named.

If anyone's interested in messing around with it, you can grab it at http://uploads.realityripple.com/Projects/D1toW2.zip . Be warned, it has bugs and I don't think UDP works right at all right now.

For shits and giggles, I created a client proxy for Diablo 1 that turns its packets into W2BN (really easy since they're identical except for SID_CDKEY2).



Currently, it can enter private channels, host and join D1 games seamlessly, and all that jazz.

That's a... very strange packet buffering method. And your Key Length, Product, Public, and key data should all be grabbed from a cdkey decoder, not hardcoded. 0x06 and 0x0A would only allow 16-digit D2 keys... The EXE Version should also not be hardcoded to 0x01000001.

That reminds me, I should get back to work on sc2 packet documenting... Anyone else wanna do it for me? I'll give you all the resources and current docs you need XD

No, I don't think I missed anything. I wrote a key tester so long ago I don't even have the hard drive the source code for it was on anymore, and it used an active BNFTP connection ready to shorten bans... It had to have been one of the first things after a fully functioning bot that I'd created.

That's practically exactly how this song starts off...

This isn't common knowledge?

I can't give you HDX's... But I can upload mine if you really want. None of the programs touch any sockets in any way. It's just a hassle for me to upload things, being on Satellite.

Also, for anyone interested in future releases, I'm adding packet parsing to BitSnoopy, so you can parse packets to a text-readable format, if I know them... Otherwise it just says Unknown Packet and stops reading... The packet length can't exactly be programmatically determined...

I've been doing some documentation of SC2's protocol with help from HDX and a few other resources, which I'll release when I have more, clearer information, but for now, here's some tools that may help you, if you'd care:

http://uploads.realityripple.com/BN2%20Packet%20Tools.7z

Descriptions:
BitSnoopy = A tool I wrote to help analyze BNet2 protocol packets. It will display a packet log as bits, and lets you select some of those bits and displays their decimal, hexadecimal, and textual value.
sc2ldr/sc2hook = HDX wrote this nifty little tool to launch SC2 and hook a couple functions so you can print out the Session Key for decoding the encrypted part of packet logs.
ArrC4 = Another tool I wrote, this time to convert encrypted packets to their decrypted value given the Session Key.

All three have bugs, and only some of BitSnoopy's searching features work.
Happy logging.