Im trying to connect bnet using your bot but it prompts different errors for w3 or TFT.
-- for TFT: [18:25:21.134] CRITICAL: Unable to connect due to exception: exceptions.InvalidVersion: Game not found - warcraft iii: tft
[18:25:21.166] CRITICAL: Please correct and try again.
-- for w3; [18:26:38.219] exceptions.InvalidVersion: Old game version (it wants you to download WAR3_IX86_120E_121A_enUS.mpq)
[18:26:38.224] Login.getLogin(Login.java:183)
[18:26:38.227] PluginMain.processedPacket(PluginMain.java:333)
[18:26:38.229] pluginmanagers.PluginRegistration.processedIncomingPacket(PluginRegistration.java:722)
[18:26:38.231] bot.PacketThread.run(PacketThread.java:179)
Whats going on?
Thx
I get the same Error :).
Make sure you are useing a JBLS server for WC3 BNLS isn't updated.
(Hdx.JBLS.org or JBLS.org)
~Hdx
Oh God, why did I add BNLS? Now Hdx is spreading JBLS around again. :P
Note that JBLS should only be used for WarCraft III and/or Diablo II, as the others use a new CheckRevision method that it doesn't support yet. I should make a sticky about this.. I think I will!
Actually hdx.jbls.org is working with starcraft and warcraft II..
This may not be officially supported "yet" but it is working just logged in.
I havent heard or seen any official info from hdx on this yet.
And JBLS supports DRTL and a few other clients that BNLS doesn't support and probably wont ever support.
JBLS DOES NOT support lockdown yet.
You have a SMALL chance of logging in correctly because I have a cache of values.
Asides from that sorry, someone reverse lockdown!
As for DRTL/DSHR/SSHR yes those are supported by JBLS, but, they also use lockdown so...
At worst I'l have it reversed by the end of the summer.
But sorry guys I have to teach myself ASM first -.-
~Hdx
Ron's guide to Assembly (http://www.skullsecurity.org/wiki/index.php/Main_Page) is your bible, especially this page (http://www.skullsecurity.org/wiki/index.php/Simple_Instructions).
I'm at home increasingly less often, but when I am, I can try to lend you a hand. It's not the code itself that's complicated -- any idiot can port it back to C, it's the fact that you've got to figure out from a series of calculations what's going on.
Prime example:
.text:004014AC cmp [esi], bl ; BL is 0 -- we're looking for a null char
.text:004014AE mov eax, esi
.text:004014B0 jz short loc_4014B7 ; if(*esi == bl) { jmp loc_4014B7; }
.text:004014B2
.text:004014B2 loc_4014B2: ; CODE XREF: CheckRevision+45j
.text:004014B2 inc eax ; We're searching for the first null character on the stack
.text:004014B2 ;
.text:004014B2 ; C++:
.text:004014B2 ; while(*(++eax) != (int)0)
.text:004014B3 cmp [eax], bl
.text:004014B5 jnz short loc_4014B2 ;
.text:004014B5 ; Eventually, we've ended up with the length of the EXE string
.text:004014B5 ; I don't have a clue why they don't just take this argument in
.text:004014B7
.text:004014B7 loc_4014B7: ; CODE XREF: CheckRevision+40j
.text:004014B7 sub eax, esi
.text:004014B9 push eax ; dwBytes
.text:004014BA mov [esp+1A4h+var_194], eax
.text:004014BE call HeapAllocWrapper ; This alloc's a chunk of memory the size of the EXE path
From my comments, you should be able to tell pretty easily what it does, but if it weren't commented it'd be tough. Keep in mind that they don't actually get the three paths as arguments, but skip to -0x0C on the stack, so this is actually reading from the pointer on the stack, not the argument. Not that it makes that much of a difference, but it's another complication you should be aware of.
int16 bl = 0;
if(*esi = bl)
{
jump nullExePath;
}
else
{
intptr32 &eax = esi;
do
{
&eax++;
} while(*eax != 0)
eax -= esi;
*(&var+194+0x1A4) = eax; // this is obviously not going to work, but you get the idea
eax = HeapAllocWrapper(eax);
// ...
}
Basically, it's calling strlen on EXE Path. I'm willing to bet var_194 is the EXE statstring, but I don't know.