Valhalla Legends Archive

Not the 5x5 Rubik's Cube!

Mmk.

Quote from: Hdx on October 22, 2009, 08:29 PMOdd, didn't think anyone used REALBasic anymore. But if there are any particular aspects of things that you don't understand, ask specific questions, not general ones. Also posting your attempt at converting, and your results/test code would help.

Yeah, not many people do use REALbasic. As I said, many dislike it and for good reason; even I dislike it at times.

Specific questions... How does the code within the For...Next work, what is it doing besides some shuffle? I am having trouble reading lines like c ^= (byte) (hashkey & 7); and why it matters to even use exponents (c ^= (byte)). Now that I look at it, it is mostly the same code I've seen before.
                for (short i = 11; i >= 0; i--) {
                        c = cdkey.charAt(seq[i]);
                        if (c <= '7') {
                                c ^= (byte) (hashkey & 7);
                                hashkey >>>= 3;
                        } else c ^= (byte)(i & 1);
                        key[i] = (char)c;
                }
Here is my understanding of this code:
1. The loop is going backwards (11 to 0), which means it starts from the right of seq and goes to the left (assuming seq is the encoded CD-Key, as seen by humans).
2. It is getting a specific character at index i and length 1, like you are using c = Mid(seq, i, 1).
3. Checks if the value gotten from Mid(), c, is less than or equal to 7:
4-1. If true, it combines 7 using bitwise into the hashkey and then makes it into an exponent <-- confusing.
4-2. It makes hashkey bitwise right and equal 3? <-- confusing. I know it is doing Shift-right in Bitwise, but why equal 3?
5. If false, it does the same thing as 4 but uses i instead of hashkey and adds a bitwise 1 instead of 7.
6. It prepends (because the loop is going backward) to the decoded key value what c now equals.

My project code isn't really complete, right now it uses BNCSutil or BNLS (depending on circumstances and settings). I haven't completed the CD-Key decoding (I have it set everything to zero's) because my bot always fails the version check when using local hashing, BNCSutil, or even the BNLS.

Quote from: Hdx on October 22, 2009, 08:29 PMThat is actually not a valid test. You are not testing the speed of the languages, you are testing the speed of specific implementations. I am pretty sure that SB does about 10x more things then your bot does when it receives a chat event.
It add chats which triggers a change event which re-evaluates the entire RTB for color codes (rather dumb..) it fires off and waits for scripting events to finish, it queues up the raw packets for its logger, it ... you get my point. If you were to strip out all the extra stuff SB does, it'd probably be just as fast, if not the differences would be minute, as your code. But thats neither here not there so meh.

This is how my socket receives its data, in a way that won't ever jumble up a packet and get packet read errors.
1. Data comes in from the server and gets put into an internal buffer ( Buffer = Buffer & NewData ).
2. It checks the length of the buffer if it equals at least 4 ( LenB(Buffer) >= 4 ).
3. If yes ( >= 4 ), it goes ahead and reads the first 4 bytes (the header) for 0xFF, the ID, and the length.
4. If the first byte is not 0xFF, then we disconnect assuming it is not Battle.net. Put the ID and length into a temporary variable and then read length like we did 2 ( LenB(Buffer) >= Length ).
4. If that check also went okay ( LenB(Buffer) >= Length ), then it gives that packet (the two temporary variables ID and length, and then the data it reads as a parameter) to another function which parses it.
5. It removes that entire packet, according to the length specified, from the buffer so it can read the next packet in-line. Then the entire process starts over from 2.
6. It continues reading until a check fails ( LenB(Buffer) < 4; LenB(Buffer) < Length; Connected = False; ).
7. It waits for more data from the server.
As you can see, it is a complicated process, and is probably just easier to show you the code; but even the code is long.
In the parse function, it has four parameters. Packet ID, Packet Length, Packet Data, and then the Full Packet (the packet as pulled from the buffer).
1. Initialization of buffers, variables, and some other junk for packets that may be read later.
2. Look at Packet ID, using a Select Case ( or switch{} ) statement, and see if we find the ID.
3. If yes, do the code associated. If no, cancel out of the parse, and in turn cancelling the read of the buffer or packet, or a disconnect (depends what we were waiting for).
4. The code associated varies a lot from packet to packet, but the concept is the same for most packets. If it has a lot of things associated with it like SID_AUTH_CHECK or SID_CHATEVENT, it gets its own child parse function, otherwise it gets parsed here.

That is how my bot does things from Battle.net. In each child parse function, there is easily double or triple the amount of stuff than there is in the original parse function. As for a chat event, my bot uses the same concept from the original parse function-it reads the event id instead of the packet id, same things happen if it doesn't find the event id.
For a talk/emote/whisper, it prints it out to the chat box then gives it off to yet another function for parsing of any bot commands. That function is very complicated and I'm still working out the kinks, but it works like StealthBot 2.699 Beta does (in the end-user's standpoint and not in code).
For most of the other events, it will do the usual. For an info/error, it will just print it regardless. For channel-specific things like restricted or full, it will display what any other bot does but actually includes the channel name (as seen from Text).

Now that I have that off my chest and hopefully have explained most of how my bot does things (I know I use functions a lot lol, I love using them I guess).

Quote from: Hdx on October 22, 2009, 08:29 PMWhat aspect of the shuffle has you stumped?
I'll see if I can dig out my 'super clean' version of the cdkey decoding (I made it to make things easier to understand), but I forgot where i put it.
But what I would do is not even do the decoding while connected to battle.net
Get a program that you know decodes cdkeys properly, BNCSUtil.dll does a good job
And just start comparing outputs.
EA:
Write a VB6 app that uses BNCSUtill.dll, and does nothing put print out the public private and product values of a cdkey.
Then Output those values from your program, if they match up, it means you did it correctly and will not get IP banned from bnet.

99% of everything about battle.net can be tested OFFLINE with no risks of getting IPBanned.

1. I explained that above.
2. I'd like that if you could, though it is probably like all the others unless you truly added massive comments or easier-to-read code.
3. You would decode after you save the CD-Key, or sometime before connecting? And/or save the decoded version in the settings? That may be an idea. lol
4. BNCSUtil.dll always says fail for me, but yet when I see an example, I don't see what I do wrong. I don't have the code to show you anymore =[
5. I haven't compared outputs yet because I still have yet to even get an output from my own code... or at least an output that makes sense lol.
6. I know lots of stuff can be tested offline, but there comes a time when PvPGN isn't always accurate or my findings contradict what I'm testing and I turn to testing it on actual servers to get a better idea of what happens. One of the quick-add features I made to my bot was the ability to use other bots to get past version check, cd-key, and login. After that, it doesn't need the other bot except for warden bypass. I plan to leave this feature in my bot as an Advanced feature, and I use it for testing some things anyway.

Actually, it would be hard to find one in the language I need. I am using a language like VB.NET, but is a bit different. I am using REALbasic 2009 Release 2 Studio Edition. I've been able to convert most documentation and examples for my bot, from many languages including VB6, Java, C++, and even PHP. Some things still don't make sense to me though.

Believe me, I'm not too relieved that I'm using RB, but for some reason, I can get it to be quicker than VB6 coding can be. I hooked my bot up (after building the parsing functions) to a personally written server, and made it spam the bot like hell. I then did the same thing for two bots made in VB6, FooLOps and StealthBot. My bot was done with 1,000 EID_INFO's in SID_CHATEVENT about the length of 4-10 characters when FO and SB caught up about 4-8 seconds later. So I don't have any plans to switch from a compiler everyone seems to dislike.

I do get what you mean in the code; I can understand lots of languages' code. I am looking at how the shuffling is done, and I'm not completely following how it is done though. Can you further explain the entire process? I want to get a good grasp on this before I implement it into my bot and risk getting a 2-week IP-ban (unless I go on a PvPGN server).

Quote from: Hdx on October 21, 2009, 08:21 AM
Cdkeys that you see on your CD case are in an 'encoded' format. When you decode them they turn into 3 different values, Public, Private and Product. These three values are used in verifying that the cdkey is lagitimate.
If you take a look Here you will see that for the old 13 digit SC cdkeys, the digits are shuffled around a bit, and then after the shuffle you simply extract the 3 values using SubStr() (Mid() if you're using VB6)

Its actually not that difficult to understand, all of the decoding functions are basically the same, except for where exactly they take the valus from the result, and a few index changes.

This didn't make sense until someone else in a different topic said there was 3 DWORD's in a CD-Key. Now it makes sense. But now I'm confused on why the newer CD-Keys have 26 characters and not 12, and why the older CD-Keys have 13 characters instead of 12.

What CD-Keys use what part of the encoding, and how would I go about getting each value? I know that STAR/SEXP uses 13 characters and consists of purely numbers, I know that D2DV/D2XP/W2BN consists of 16 characters (4 DWORD's?) and what appears to be hexadecimal values, and then I know WAR3/W3XP consist of 26 characters that appear just like the D2DV/D2XP/W2BN CD-Keys, but longer.

Quote from: Camel on October 21, 2009, 01:51 PM
The CD key is just 3 DWORDs encoded in to a form a human can type.

Thank you for this bit of information. You just made things a lot easier for me (I'm confused on how CD-Key hashing works). I now have new insight on how to input CD-Key's.

I've tried to understand how CD-Key hashing works, for SID_AUTH_CHECK and the old way using SID_CDKEY2/SID_CDKEY.

The part I'm not understanding is how it is done. What is the "public" key? What is the "product" value?

I assume the Key Length value is the length of the CD-Key, as seen before anything is done to it, for example: Length = 13 for 0123456789012.
I assume the Product value is what Product the key belongs to, for example D2DV or STAR.
I assume the Public value is a special key that is used when hashing the CD-Key.
And then I assume the hashed data is the actual hash of the CD-Key.

I fail to understand how this process works, and looking at many sources didn't help me much. I even looked at the source for BNCSutil and JBLS.

If someone can explain on this, that would be great. I am trying to make my bot independent of BNCSutil, that way I don't have to make sure it is present when someone uses my bot.

Not really on-topic, but I feel it is necessary... BNCSutil fails to version check my bot (and in turn failing the version check for Battle.net), and I don't know why. I can provide packet logs if needed.

I lol'd.

Quote from: Purri on October 14, 2009, 07:10 PM
Hey i dont wanna any help like i said, i know that side and i have build all packets with that side help. :s

Site* A side is a location, a site is short for website; also known as a location on the internet that can be browsed with a web browser.

Quote from: Jailout2000 on October 14, 2009, 06:04 PM
you would familiarize yourself (if you haven't already)

I already guessed that you have probably already used the website, most people do when they are doing anything with Battle.net's packets. If you don't want any help, then I don't see why I should review your bot, because reviewing your bot and critiquing it is helping you.

Also, the link is dead (the website says that the folder is empty or no longer exists).

If you want to make it easy on yourself, you would familiarize yourself (if you haven't already) with the BnetDocs website.

http://www.bnetdocs.org/

Hmmmmm. That is weird. The code doesn't show anything that would do that, so I don't really know what's happening. I'll have to ask the person who coded it (Don Cullen) about it later, and perhaps try and find out other information on my own.

Literally the way it prints that out is by making a query into the database and echoing it out onto a buffer, then giving you the buffer. Unless there is somehow a screw up in the way that it is printing, I don't see how that would happen, so I'll have to look closely in the code when I'm trying to find what's happening.

Back on topic... this plugin is working great. I use it a lot in what I'm doing, and it is very useful. It saves me the hassle of having to read the data for myself (well, mostly anyway, there's still some unfinished packets).

Quote from: nitroxsbnetdocs is fine. (except for the "Download BNETDocs as Text" feature which is missing a lot of packets)

The download BnetDocs as text feature is a caching system.

There is a file on the server that has a last modified date on it, and the generator uses this for caching.

If the file is less than 12 hours old, it gives you the file, if the file is 12 hours or more old, then it'll give you a generated page along with writing to the file (updating it from 12 hours or more old to new). I don't see how this does not contain all of the packets, because I see all the packets in this text that I see on the main page of BnetDocs.

Quote from: nitroxs on August 31, 2009, 04:55 PM
2. Add the field to the tree.

Code Select Expand


-- root is the tree object sent by wireshar to the dissector entry point (dis.dissector)
-- buf is the buffer object sent by wireshar to the dissector entry point (dis.dissector)
-- This adds a field in little endian byte order associated with the given range of the buffer
root:add_le(field, buf(offset, len)
-- This adds a field in little endian byte order associated with the given range of the buffer
root:add_le(field, buf(offset, len))
-- This adds a field in big endian byte order associated with the given range of the buffer
root:add(field, buf(offset, len))


Conclusion: the problem is that dissect_packet function adds every field as little endian because I guessed that wuold be the most frequent order use in the packets and there is yet no way to tell from the packet descriptions what order to use.

If bnetdocs is the problem, you can tell me which packets need to be updated. I have full privileges there, including database, so I can change almost anything there. Tell me which packets don't use Little-endian for everything, and I can note it in the description.

To answer your question in your opening post: Don Cullen (author of BnetDocs: Redux) was going to make an XML-generator for people who wish to use the BnetDocs as a database in their programs, like your describing. The problem is, he hasn't found a standardized version of the XML format he wishes to use, and I haven't spent time on it (he's given me Administrative-privileges). So currently there is no way for that to really work. I think he may have an old thread laying around that discusses the XML format he wanted to use, which had pros and cons about it from him and others. I'd most likely do a Google search, or a forum search.

So I gave this little lua script/plugin a try. I downloaded and saved to bnetp.lua, and edited init.lua to add a dofile and enable lua in wireshark. I told Wireshark to filter to "bnetp && bnetp.pid = 0x0F", which gave me only SID_CHATEVENT's just as I wanted (good work!).

I made a small change to the code however. It appeared that the SID_CHATEVENT packet did not have the Event ID names added to it, so I went ahead and added them. WProtoField.uint32("","Event ID",base.HEX, {
[0x01] = "EID_USERSHOW",
[0x02] = "EID_USERJOIN",
[0x03] = "EID_USERLEAVE",
[0x04] = "EID_WHISPERRECEIVED",
[0x06] = "EID_BROADCAST",
[0x05] = "EID_USERTALK",
[0x07] = "EID_CHANNEL",
[0x09] = "EID_USERUPDATE",
[0x0A] = "EID_WHISPERSENT",
[0x0D] = "EID_CHANNELFULL",
[0x0E] = "EID_CHANNELDOESNOTEXIST",
[0x0F] = "EID_CHANNELRESTRICTED",
[0x12] = "EID_INFO",
[0x13] = "EID_ERROR",
[0x17] = "EID_EMOTE",
}),

You may also want to have the defunct fields be base.HEX, instead of just nothing (or base.DEC as it appears). This would help people see what Battle.net is actually throwing, because for the account number and registration authority, Battle.net throws 0xbaadf00d which would be a large decimal number instead without base.HEX.

Another suggestion, try to make flags like for SID_CHATEVENT and other packets, actually be defined. This would help distinguish between a normal user, an administrator, etc. or in the case of SID_JOINCHANNEL, a forceful join, or a first join. Yes, I admit, most would not need this, especially if they have the knowledge to even use this script, but it would still be useful to those who don't feel like calculating bitwise flags.

Good work, -Jailout2000

I have another link for everyone, since his seems to be broken.
http://www.BnetBeta.com/files/Battle.net/modWARDEN.zip

Edit: His link seems to be working again, oh well.

First thing I would of done is download icons.bni and view it with the IconView program that Skywing made.