I am don't understand when your parsing certain things you need to use code like:
Val("&h" & HexConverter(StrReverse(Data)))
Quote from: BaDDBLooD on August 29, 2004, 11:31 PMI am don't understand when your parsing certain things you need to use code like:
Val("&h" & HexConverter(StrReverse(Data)))
I'm not sure what HexConverter is, but this is how you turn hexadecimal strings, e.g. AF, into actual numbers. For example, this is how my bot gets the version byte for a product:
Public Function GetVersionByte(Product As bnProduct) As Long
GetVersionByte = CLng("&H" & GetSetting("VerByte", ClientKeyToStr(Product)))
End Function(bnProduct is an Enum of Battle.Net products, ClientKeyToStr turns one of those values into a stat code.)This gets the version byte from the configuration file, which will be a 2-character string, such as C9. &H is prepended to that, which makes VB evaluate is as &HC9.
I mean like, in lot's of bots
People use the function strToHex
Public Function StrToHex(ByVal String1 As String) As String
Dim strTemp As String, strReturn As String, i As Long
For i = 1 To Len(String1)
strTemp = Hex(Asc(Mid(String1, i, 1)))
If Len(strTemp) = 1 Then strTemp = "0" & strTemp
strReturn = strReturn & strTemp
Next i
StrToHex = strReturn
End Function
To get the ServerKey from 0x50
Why?
Quote from: BaDDBLooD on August 30, 2004, 12:21 AM
I mean like, in lot's of bots
People use the function strToHex
{code removed}
To get the ServerKey from 0x50
Why?
You might use that to
display the server key, but I can't think of any good reason why you need it to
get the key. Unless they do something truly insane and stupid like:
Dim ServerKey As Long
[...]
ServerKey = Val("&H" & StrToHex(Mid(PacketData, 9, 4)))If you're seeing that in "lot's of bots", well, IMO, that's a ridiculously stupid way to get an integer value out of a packet.
If you're not using an incoming packet parser (I do, so I'm just making this up, it's not tested code), something like this is more efficient:
Dim ServerKey As Long
[...]
CopyMemory ServerKey, ByVal Mid(PacketData, 9, 4), 4Or even better, if you store packet data in a byte array instead of a string:
Dim ServerKey As Long
[...]
CopyMemory ServerKey, PacketData(8), 4
Actually in the bot i am looking at:
ServerToken = Val("&h" & StrToHex(StrReverse(Mid(Data, 9, 4))))
That makes no Sence to me. Why don't you just use GetDWORD
Quote from: BaDDBLooD on August 30, 2004, 01:00 AMThat makes no Sence to me. Why don't you just use GetDWORD
You should just use GetDWORD. It doesn't make any sense to you because it's a very stupid way of doing it.
Could you explain it in more detail?
EDIT: I'd like to learn =)
Quote from: BaDDBLooD on August 30, 2004, 01:03 AMCould you explain it in more detail?
Explain what in more detail?
Explain How that works. Even if it is Stupid.
EDIT: Could we talk on aim?
Quote from: BaDDBLooD on August 30, 2004, 01:07 AMExplain How that works. Even if it is Stupid.
Oh. Sure. I'll break it down, moving from the inside out.
ServerToken = Val("&h" & StrToHex(StrReverse(Mid(Data, 9, 4))))Mid(Data, 9, 4) - Extracts the raw bytes of the server token from the packet.
StrReverse() - Reverses the byte order.
StrToHex() - Gets the hex string from the raw bytes. So, if the actual bytes (in hex) of the server token were CC 5B 58 30, StrToHex() will generate a string containing the characters "30585BCC". (Remember, it was reversed.)
"&H" & - Adds the &H hex-delimiter to the beginning of the string. Now the string would read "&H30585BCC"
Val() - Val reads a string that contains a number and returns the value of the number inside the string. In this case, it reads the string and recognizes it as a number in base-16 (hexadecimal). It then returns the actual value of the number. So before you had the string "&H30585BCC", now you have the number &H30585BCC, which is the server token.
All these steps for just one value. That's what makes it stupid. Hopefully my explanation made sense. ;)
This is what Copy Memory Does?
Quote from: BaDDBLooD on August 30, 2004, 01:27 AMThis is what Copy Memory Does?
No. Copy memory just, well, copies the memory.
Quote from: shadypalm88 on August 30, 2004, 12:57 AMDim ServerKey As Long
[...]
CopyMemory ServerKey, ByVal Mid(PacketData, 9, 4), 4
This takes the 4 bytes from the packet that represent the server token, and copies it to the variable called ServerKey. No conversion takes place, as opposed to the "stupid" method where the server token is extracted, reversed, converted to human-readable format, and then converted back into machine-readable format.
Ok. Still a little shady on how copy memory works. Why you have to use it to "Copy" the memory. I Don't see why you can't do Variable = Data.
EDIT: I heard from UserLoser that Copy Memory "Reverse's"?
Quote from: BaDDBLooD on August 30, 2004, 01:37 AMOk. Still a little shady on how copy memory works. Why you have to use it to "Copy" the memory. I Don't see why you can't do Variable = Data.
While this is possible in other languages, it is not directly possible in Visual Basic. Other languages support "typecasts". If this were possible in VB you could do something like:
Dim ServerToken As Long
[...]
ServerToken = (Long) Mid$(PacketData, 9, 4)That code means "Take 4 bytes out of string PacketData starting with byte # 9, treat it as a Long and store it in ServerToken." But like I said, this isn't possible in VB. Using CopyMemory is a
workaround for this problem. Using the other, "stupid" method is another workaround, although it's slower, longer, and messier.
Quote from: BaDDBLooD on August 30, 2004, 01:37 AMEDIT: I heard from UserLoser that Copy Memory "Reverse's"?
I don't think so. If it did, the value that ended up in ServerToken would be incorrect.
Well like when relating to Clan packets.
I was sending my Tag as NonNTSTring StrReverse(Tag)
i than realized that it said "dword" so my tag was 3 bytes.. He said use Copy memory to make it Four, you don't need to have strReverse.
If you do that, make sure the spare bytes (not being used for the tag) are null. If you don't, you might end up with junk memory being sent as part of the clan tag. I'm not sure how VB stores strings so it might not be an issue but in a real language it certainly would ;)
Why didn't i need to reverse it? =|
Quote from: BaDDBLooD on August 30, 2004, 01:00 AM
Actually in the bot i am looking at:
ServerToken = Val("&h" & StrToHex(StrReverse(Mid(Data, 9, 4))))
That makes no Sence to me. Why don't you just use GetDWORD
wth... that StrToHex function looks weird. Yeah it doesn't make sense to me either... "0" & strTemp
And what is this GetDWORD function? ^_^
Quote from: BaDDBLooD on August 30, 2004, 02:39 AMWhy didn't i need to reverse it? =|
I'm not sure; I think you actually
did need to at some point.
The reason you were having to reverse it in the first place is because of differences in the way your computer stores strings and DWORDS (or any integers that take up more than one byte).
Let's look at my "clan"'s tag, then, SO. In hex, those 2 characters are:
53 4F53 = S, 4F = 0
Now SO is only 2 characters (bytes) long, but the DWORD field it will be going into is 4. So, it must be padded with null characters. (In VB, "SO" & vbNullChar & vbNullChar.) Now we have:
53 4F 00 00So far, so good. You have a 4-character string representing "SO". But if you send this to Battle.Net in one of the clan packets, it won't work. This is due to a subtle difference in the way strings and numbers (i.e. DWORD's) are stored and interpreted by your computer: byte order.
All WORD's and DWORD's sent between you and Battle.Net are in
little-endian order, which is the native order of Intel (x86) systems. In this order, the least-significant byte comes first. This can be a hard concept to wrap your head around, so instead think of the number 123,456,789. If you used little-endian order, you would write it as 789,456,123. Instead of writing the most-significant group (123) first, you write the least-significant group (789) first. (The 123 group is more significant because it is the millions group, i.e. changing it to 124 changes the number as a whole by 1
million, but changing the 789 group to 790 only changes the number by 1.)
Only, instead of talking about groups of thousands, we're talking about bytes. Strings are not stored in the same way. Remember, you're the only one who's thinking of it as a string. Battle.Net will interpret it as a DWORD. Also remember that DWORD's are stored in the order opposite to what you would expect. It expects to get the
last "character"
first, which is why you have to reverse it.
Indeed, when Battle.Net reports my clan to me, it appears like this (in hex):
00 00 4F 53Doing CopyMemory, however, will NOT reverse it, and as you hopefully should understand by now, you have to.
(If anyone can explain this better, please do ::))
Quote from: Kp on August 28, 2004, 04:26 PM
Quote from: MindArchon on August 28, 2004, 04:13 PMWhy is his IX68 reversed?
Intel chips are little endian.
Should answer your questions about it being "reversed".
VB ex: CopyMemory(ReturnVal, ByVal "STAR", 4) will put 0x52415453 into ReturnVal. That converted from hex to a readable string is "RATS"
Quote from: UserLoser. on August 30, 2004, 01:51 PMVB ex: CopyMemory(ReturnVal, ByVal "STAR", 4) will put 0x52415453 into ReturnVal. That converted from hex to a readable string is "RATS"
strTest = "STAR"
CopyMemory lngTest, ByVal strTest, 4
Debug.Print Hex(lngTest) 'outputs 52415453
Debug.Print lngTest 'outputs 1380013139
Debug.Print Hex(1398030674) 'outputs 535441520x52415453 = "RATS" = (LSB order) 1398030674
0x53544152 = "STAR" = (LSB order) 1380013139
I must be missing something here, because I still don't understand how that works out.
Ok... so if you have a String of 3 characters, and when you put them in order from least significant to most significant. Wouldn't, at some point in time, Battle.net NOT be able to see what tag your sending?