Unrecognized BNCS packet SID_005E received

[Rob]

0x51 is sent @ 19036560.   The client token is set @ 19036400.

[Ringo]

thanks, Im having a problem opening the bw's process with PROCESS_ALL_ACCESS, so im having trubble viewing them address's (This kinda stuff isnt my strong point)
Anyone know what access flag BW can be opened with, for read/write, or what im doing wrong?

Code Select Expand


    Dim tmpData As String
    Dim hThread As Long
    Dim hProcess As Long
    Dim lProcessId As Long
   
    Const STANDARD_RIGHTS_REQUIRED As Long = &HF0000
    Const PROCESS_ALL_ACCESS As Long = (STANDARD_RIGHTS_REQUIRED Or SYNCHRONIZE Or &HFFF)
    hThread = GetWindowThreadProcessId(m_Handle, lProcessId)
    hProcess = OpenProcess(SYNCHRONIZE, 0&, lProcessId)
    If hProcess = 0 Then
        Debug.Print "Failed to get process handle"
        Exit Function
    End If
    tmpData = String(lngDataToCopy, 0)
    lngReturn = ReadProcessMemory(hProcess, lngAddress, ByVal tmpData, lngDataToCopy, 0&)
    If lngReturn = 0 Then
        Debug.Print "Failed Read At Address 0x" & Right(String(8, &H30) & Hex(lngAddress), 8)
    End If


[l2k-Shadow]

if you're on 2000/XP/Vista, you're gonna have to rewrite sc's ACL to grant you access. it's easier to just open it in a disassembler like ollydbg

[Ringo]

ah. Im kinda out of my depth with this stuff, can anyone modify a bw exe so that its possible to read/write to it? (dont care that it will fail lockdown)

edit: n/m <3 iago's x86-loader source

[iago]

You can use my loader: http://www.javaop.com/~ron/x86-loader.exe (note: not a permanent link).

Run "x86-loader -s1 Starcraft.exe"

Should disable the ACLs.

[UserLoser]

IIRC, according to my old notes, 0x5e is Warden

Funny that people release working versioncheck then this is enabled?

[Ringo]

You can use my loader: http://www.javaop.com/~ron/x86-loader.exe (note: not a permanent link).

Run "x86-loader -s1 Starcraft.exe"

Should disable the ACLs.

Thanks
Hdx was trying to send this to me yesterday and I was like "hax hax", but I later noticed it in the lockdown source you released, so I was like "oh oh"
Shadow modifyed a BW exe but I was unable to read memory with it but this loader works perfectly
After talking to shadow for awhile on MSN and getting a better insight into memory/asm/C, but refuseing to DL and use ollydbg, I found the offsets with good old vb instr()
Client Token address = Battle.snp + 0x00047017
Server Token address = Battle.snp + 0x000446DB
Im not 100% sure if there static, if not I need to instr there adderss's to get the adress to the variables, but those were the ones I was after
Hopfully they are not computed to gether and I can finish this up

Thanks for the help!

[Joe[x86]]

Funny that people release working versioncheck then this is enabled?

Thank you. You do not know how happy I am to know I'm not the only one in the world to make that connection. Until this, apparently I was.

[Ringo]

x86] link=topic=16758.msg169998#msg169998 date=1181577661]

Funny that people release working versioncheck then this is enabled?

Thank you. You do not know how happy I am to know I'm not the only one in the world to make that connection. Until this, apparently I was.

That kind of goes with out saying?

Anyway, it seems that the encrption key for warden, is computed, not only with the client and maybe the server token, but 1 or all of the lockdown results as well. (seems to all be happening in 0x51 builder)
This is causeing me alot of problems, because it seems, if im to have access to read/write to SC's memory space, then SC will fail lockdown.
But when i modify the results so they are correct (client and server see differnt results) then warden brakes.
At the moment im unable to logon battle.net with out warden been broke on the client, so its impossible for me to then try brake it.

I wrote a little vb tool to detect changes in memory, and used it right before and right after the client built and sent 0x51.
These are the address that interest me, but cant test on a working warden:

Code Select Expand


0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit

Could anyone poke them, or know what variables they are for?
Im 99% sure one of them is the warden encryption key

Aside, if this is going to off-bot-dev topic, what forum should I start a topic in for this?

[iago]

x86] link=topic=16758.msg169998#msg169998 date=1181577661]

Funny that people release working versioncheck then this is enabled?

Thank you. You do not know how happy I am to know I'm not the only one in the world to make that connection. Until this, apparently I was.

No, a lot of people have said it. But I'm reasonably sure that it was just lucky timing, though, since the code for Warden was in place a long time ago. They wouldn't have put the code in there without a plan to enable it.

[UserLoser]

x86] link=topic=16758.msg169998#msg169998 date=1181577661]

Funny that people release working versioncheck then this is enabled?

Thank you. You do not know how happy I am to know I'm not the only one in the world to make that connection. Until this, apparently I was.

No, a lot of people have said it. But I'm reasonably sure that it was just lucky timing, though, since the code for Warden was in place a long time ago. They wouldn't have put the code in there without a plan to enable it.

I'm not saying that is the reason.  Yes, the code for Warden has been there for quite a long time, then again, so has the NLS stuff .  My original thought was testing stuff on B.net for SC2 since SC's Warden is different than W3's and I believe D2's (as far as how the client interacts with it, SC uses it over B.net, W3 through War3 game servers, D2 through D2 game servers, etc etc)

[herzog_zwei]

According to Saren, from bwhacks.com:

This is a very lite-version of warden that actually reports (believe it not) the vm memory size of Starcraft along with some other data (version number, operating system, etc tied to your cd key + account) whenever you log into battle.net. It's been known for a while.

It has really nothing to do with preventing hacks at all. They added a separate 'protection' for that.

He doesn't know what he's talking about.  What he's describing is more like the system info extrawork.  The warden mods being used are the latest or near latest full blown ones; they're the same ones (in functionality) as WoW.  There are thousands of warden mods and from what I've seen, none give the same hash, even though some are completely functionally the same as another mod.

x86] link=topic=16758.msg169998#msg169998 date=1181577661]

Funny that people release working versioncheck then this is enabled?

Thank you. You do not know how happy I am to know I'm not the only one in the world to make that connection. Until this, apparently I was.

I didn't want to say "I told you so". But I did, and I'm sorry I insulted you, iago, but I ended up being right anyway...

Before you go on blaming people and making accusations without much evidence, consider these:

1. Currently, Warden is checking for at least 3 public hacks.  It is not some "lite" warden mod enabled just to thwart bots.  Those hacks were released a few weeks before Warden was enabled.  A hack with a release date very near the date that rob/warz released their code isn't detected.

2. Blizzard needs sufficient time to figure out how to detect the hacks, create/run it through their warden mod polymorpher (to generate thousands more warden mods that are functionally similar), and test it to make sure the hacks in question are detected and doesn't give false positives.

3. Warden is supposedly made by a third party, not Blizzard.  If the warden mods and detection queries are still outsourced, it'll delay it even further.  rob/warz released their lockdown workaround around June 2nd.  Warden was enabled on June 5th.

4. Usually it takes weeks to months after a certain hack is released before they even get Warden to detect it.

IMO, it was just coincidental, as iago said.  Even though it'd only take a few minutes to figure out how they can use Warden to detect those hacks, it'd probably take longer to sign off on the paperworks so they can do it and put it up on the servers (the Warden mods can contain arbitrary code that can make it do anything so they'll need someone to review it to make sure a disgruntled employee doesn't put in anything bad).  A two day emergency Warden response is possible but I don't think it's likely (unless it's for WoW and they can't get an emergency server patch ready).

Generally, new Warden detections only flag people and they'll ban them later (few weeks or a month later).  They've skewed from their norm lately for D2 and now SC.  They've yet to ban the people they've flagged in D2 for over 3 months and now with SC, they're notifying people right away by giving them losses.  Bannings for SC may come later but I suppose they're relying on the element of surprise/inexperience right now and giving near immediate feedback on what hacks are detected.

I already have a working D2WS, so a BNWS should be just as easy, altho im still having afew problems with warden over bnet
When finished it should beable to support up to 80+ clients

You're playing with fire here, as it's easily detectable and I'm surprised they haven't taken action yet.  Even if they don't specifically target it soon, there are other hacks they could target that'd hit this in the crossfire.

[Rob]

Code Select Expand


0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit


These are the closest values I could find.

0x19042168 = Unsure.  IDA states that this is FileTime.dwHighDateTime.  I did not debug to verify.

0x19043F60 = ValueString from 0x50

0x190467C8 = return of a call to GetTickCount

0x19046FF5 = a FileTime struct

[Ringo]

Code Select Expand


0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit


These are the closest values I could find.

0x19042168 = Unsure.  IDA states that this is FileTime.dwHighDateTime.  I did not debug to verify.

0x19043F60 = ValueString from 0x50

0x190467C8 = return of a call to GetTickCount

0x19046FF5 = a FileTime struct

Great, thanks
I just went back to test somthing, and it seems SC is passing lockdown on its own, so I was able to make warden die.
It looks like the 1st dword of the key hash comes into play (that could explain the client/server token) because when SC was out putting the correct lockdown results, and I modifyed the cdkey, SC wouldnt respond to warden.
I did a quick search of memory, and it seems to store the 1st dword of the key hash at 0x19042168.
This also would explain why the server's encryption key only changes every hour or so on a 0x06, 0x07 logon, because the server only computes the key out of the lockdown values (because the keyhash is in 0x36 I guess)

This sort of leaves me stuck, even if I can find where the encryption key is stored
Unless somone wants to post documentation on how to compute it

Greatfull for the help btw.

[Skywing]

3. Warden is supposedly made by a third party, not Blizzard.  If the warden mods and detection queries are still outsourced, it'll delay it even further.  rob/warz released their lockdown workaround around June 2nd.  Warden was enabled on June 5th.

Interesting that Blizzard went that route [of having the detection modules developed by a third party].  I noticed they had some job offers up awhile ago for for such a position, that mentioned experience with various (in my opinion) sucky ways to do anti-hack stuff.  For instance, asking for people with experience doing stuff like system service table hooking in kernel mode and the like - blech.  Given the warden of today, it seems they were fortunately smart enough to recognize that an anti-hack driver that compromises the kernel wasn't too wonderful an idea after all.

On the other hand, it would have been a fairly amusing thing to write about if Blizzard had an antihack system that ran afoul of PatchGuard...