BNLS help (0x0F)

[FuZe]

I downloaded the BNLSChecksum functions.  When I send my username, it gives me the server code, but when I put that  and my password into the checksum function and send it (with I think the right format), it discs me.  I tried packetlogging cleanslatebot:
If I set the password to be "asdf" and the servercode it sent me was F4DF6A24
The output csb sent was F8EC1593

Then I do
Debug.Print Hex(BNLSChecksum("asdf", &HF4DF6A24))

And I get C0EFC128, so basicllay i'm wondering what I'm doing wrong.. any help would be appreciated

[Maddox]

If you are going to put it back in the equation after looking at the value from a packet log then you will need to reverse it.

F4DF6A24 becomes 246ADFF4

If you plug that hex value back in with a password of "asdf" it gives you 9315ECF8  or F8EC1593 reversed.

[FuZe]

If you are going to put it back in the equation after looking at the value from a packet log then you will need to reverse it.

F4DF6A24 becomes 246ADFF4

If you plug that hex value back in with a password of "asdf" it gives you 9315ECF8  or F8EC1593 reversed.

It works.  Thx man.  Where did it say to reverse the data recieved when putting it into the checksum function and then reverse it again when you send it in the BNLS documentation?

[FuZe]

If you are going to put it back in the equation after looking at the value from a packet log then you will need to reverse it.

F4DF6A24 becomes 246ADFF4

If you plug that hex value back in with a password of "asdf" it gives you 9315ECF8  or F8EC1593 reversed.

It works.  Thx man.  Where did it say to reverse the data recieved when putting it into the checksum function and then reverse it again when you send it in the BNLS documentation?

OH is this why it is reversed? * There may be fields that appear to be 4-char strings, but are actually DWORDs.
For example, the DWORD 'IX86' looks like the string "68XI" without a null-terminator.

[Soul Taker]

DWORDs are little endian, hence use reverse byte ordering.