CDKey hashing

[Yegg]

Well for one, you have

unsigned long *lpdwBuffer = (unsigned long *) bBuffer;

this wont compile in C since you have to declare all variables before you do any real work. In other news, warden decryption iz a beotch.

You're implying that there is more than one reason why my code is C++. What are the others ones?

[devcode]

Didn't mean to add the "Well, for one". One of the most common windows compilers, MSVC6 does enforce that rule and it's a good rule to follow.

[rabbit]

IIRC, GCC says something about it as well.  I'm not sure if it's an error or a warning, but it still doesn't like unpredeclared variables.

[Yegg]

IIRC, GCC says something about it as well.  I'm not sure if it's an error or a warning, but it still doesn't like unpredeclared variables.

I assume it depends on the mode GCC is set to. Whatever the default mode is, it does not give any kind of warning for that kind of code.

[K]

Well for one, you have

unsigned long *lpdwBuffer = (unsigned long *) bBuffer;

this wont compile in C since you have to declare all variables before you do any real work.

If you're going to be picky, you might as well be right.

This is only an issue if you're using a compiler that adheres to the C89 standard; the C99 standard allows you to define variables wherever you want.

You can test this with gcc:

Code Select Expand


#include <stdio.h>

int main(void)
{
   int i = 3;
   printf("i = %d\n", i);
   int j = 4;
   printf("j = %d\n", j);
   return 0;
}


Code Select Expand


$ gcc -Wall foo.c -o foo --std=c99 --pedantic && ./foo
i = 3
j = 4
$ gcc -Wall foo.c -o foo --std=c89 --pedantic && ./foo
foo.c: In function 'main':
foo.c:7: warning: ISO C90 forbids mixed declarations and code
i = 3
j = 4


[devcode]

I don't use free compilers like gcc. I mentioned it because VC6/IntelC++ compilers do give errors and these are the compilers I use.

Well for one, you have

unsigned long *lpdwBuffer = (unsigned long *) bBuffer;

this wont compile in C since you have to declare all variables before you do any real work.

If you're going to be picky, you might as well be right.

This is only an issue if you're using a compiler that adheres to the C89 standard; the C99 standard allows you to define variables wherever you want.

You can test this with gcc:

Code Select Expand


#include <stdio.h>

int main(void)
{
   int i = 3;
   printf("i = %d\n", i);
   int j = 4;
   printf("j = %d\n", j);
   return 0;
}


Code Select Expand


$ gcc -Wall foo.c -o foo --std=c99 --pedantic && ./foo
i = 3
j = 4
$ gcc -Wall foo.c -o foo --std=c89 --pedantic && ./foo
foo.c: In function 'main':
foo.c:7: warning: ISO C90 forbids mixed declarations and code
i = 3
j = 4


[Yegg]

Isn't C99 still C though?

[Don Cullen]

In other news, warden decryption iz a beotch.

Devcode-

You know, if you were to post your progress so far, what you've figured out, etc, etc, etc, perhaps others who are also working on the 0x5E problem-- thanks to your notes and data-- will be able to manage to figure out how to reverse it, or at the very least will be able to contribute fresh outlooks on solutions for it.

[devcode]

I don't quite know if I should post it, I mean I'd be breeding all these Starcraft b0t warrers

In other news, warden decryption iz a beotch.

Devcode-

You know, if you were to post your progress so far, what you've figured out, etc, etc, etc, perhaps others who are also working on the 0x5E problem-- thanks to your notes and data-- will be able to manage to figure out how to reverse it, or at the very least will be able to contribute fresh outlooks on solutions for it.

[Barabajagal]

Actually... I don't think warden stopped them, since they can log in and out really quick anyway.

[devcode]

Yes, but they'd rather have bots that stay l0gged in

Actually... I don't think warden stopped them, since they can log in and out really quick anyway.

[Don Cullen]

Yes, but they'd rather have bots that stay l0gged in

Actually... I don't think warden stopped them, since they can log in and out really quick anyway.

Actually, no they don't for obvious reasons (ease of ipban via squelch, or via Blizzard staff). And secondly, all they have to do is emulate the other game clients and they can stay on. "Warring" refers to flooding and loading, and those can be easily done with other game clients, and also mainly relies on rapid cycling of reconnects to avoid ipbans from squelching.

If you're referring to hacking (use of software to cheat in games), the current hacks don't even care about 0x5E, they completely bypass it. They allow StarCraft to deal with the packet on its own.

In conclusion, your concerns are essentially moot.

I'm happy to see you have that high of an opinion of yourself. Do you plan on sharing what you've found with the community, or do you plan on withholding it?

Your response:

I promote open sourcing of details and snippets of code.

I rest my case.

[devcode]

So since there are other clients to choose from to login a bot, why worry about a SC/BW bot?

[Barabajagal]

I don't. I use war2.

[Don Cullen]

So since there are other clients to choose from to login a bot, why worry about a SC/BW bot?

Simply because people prefer bots to have full functionality and to allow them full choice of which game client to emulate.

I also am the administrator of BNETDocs Redux, and am interested in this purely for documentation purposes.

Either stand by your word and contribute, or don't. That's entirely your choice. I'm finished trying to encourage you to contribute.

If you prefer to keep your research to yourself, and would prefer to contribute absolutely nothing to the community, even if it means completely destroying any creditability you had in the first place in regards to your claims, that's your choice. Good luck with the venue.