Can i use javaOp to connect w3/TFT ?

[comedido]

Im trying to connect bnet using your bot but it prompts different errors for w3 or TFT.

-- for TFT:

Code Select Expand

[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;

Code Select Expand

[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

[Hendricius]

I get the same Error :).

[Hdx]

Make sure you are useing a JBLS server for WC3 BNLS isn't updated.
(Hdx.JBLS.org or JBLS.org)
~Hdx

[Joe]

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!

[LordVader]

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.

[Hdx]

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

[Joe]

Ron's guide to Assembly is your bible, especially this page.

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:

Code Select Expand

.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.

Code Select Expand

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.