Yeah, so I'm not going to post the contents of the message, but it was 37 bytes of unrecognizable data

what client and when during the connection?

Currently only on Starcraft and Brood War, and consistently 4 seconds after logging on / entering "chat environment"

Also worth noting (probably related) that that Battle.net is now dropping connection about 2 minutes after log on

[quote author=Spht link=topic=16758.msg169761#msg169761 date=1181072361]Also worth noting (probably related) that that Battle.net is now dropping connection about 2 minutes after log on[/quote]

Doesn't appear to be dropping my connection - you on a bot, or the client? I'm using the client. Perhaps the client handles this properly, and already knows the purpose of this?

you're right.. it appears like this:

S->C 0x5E 41 bytes (random number i guess)
C->S 0x5E 1 byte (i got 0x8D)

S->C Mass of data (thousands of bytes) some packets have 0x5E header, some don't - sending a file perhaps? - although it doesn't use the FTP connection
C->S 0x51 1 byte (i got 0x78)

(few seconds later)
S->C 0x5E 28 bytes
C->S 0x5E 43 bytes

[quote author=betawarz link=topic=16758.msg169763#msg169763 date=1181072989]
[quote author=Spht link=topic=16758.msg169761#msg169761 date=1181072361]Also worth noting (probably related) that that Battle.net is now dropping connection about 2 minutes after log on[/quote]

Doesn't appear to be dropping my connection - you on a bot, or the client? I'm using the client. Perhaps the client handles this properly, and already knows the purpose of this?
[/quote]

Well I just assume that, doubt Blizzard would do something that breaks their own client ...

[quote]
[3:55:03 PM] FF 5E 29 00 1D 59 BC 8E FC B0 0F B9 DF 2B A3 80  ÿ^)..Y¼Žü°.¹ß+£€
EC EC 94 69 1E 8C C3 6F E0 2C 55 09 41 35 D0 1F  ìì”i.ŒÃoà,U.A5Ð.
60 5B 6E 9A 47 CE 9E 60 CF                        `[nšGΞ`Ï.......
[/quote]

[quote author=l2k-Shadow link=topic=16758.msg169764#msg169764 date=1181073140]
you're right.. it appears like this:

S->C 0x5E 41 bytes (random number i guess)
C->S 0x5E 1 byte (i got 0x8D)

S->C Mass of data (thousands of bytes) some packets have 0x5E header, some don't - sending a file perhaps? - although it doesn't use the FTP connection
C->S 0x51 1 byte (i got 0x78)

(few seconds later)
S->C 0x5E 28 bytes
C->S 0x5E 43 bytes


[/quote]
Sounds like warden! woohoo :P

[quote author=l2k-Shadow link=topic=16758.msg169764#msg169764 date=1181073140]
you're right.. it appears like this:

S->C 0x5E 41 bytes (random number i guess)
C->S 0x5E 1 byte (i got 0x8D)

S->C Mass of data (thousands of bytes) some packets have 0x5E header, some don't - sending a file perhaps? - although it doesn't use the FTP connection
C->S 0x51 1 byte (i got 0x78)

(few seconds later)
S->C 0x5E 28 bytes
C->S 0x5E 43 bytes
[/quote]

Careful, there. Are you sure you're not just receiving a file still? I have received 5Eh numerous times in a simple recv/reply fashion. No additional data.

[quote author=betawarz link=topic=16758.msg169769#msg169769 date=1181073984]
[quote author=l2k-Shadow link=topic=16758.msg169764#msg169764 date=1181073140]
you're right.. it appears like this:

S->C 0x5E 41 bytes (random number i guess)
C->S 0x5E 1 byte (i got 0x8D)

S->C Mass of data (thousands of bytes) some packets have 0x5E header, some don't - sending a file perhaps? - although it doesn't use the FTP connection
C->S 0x51 1 byte (i got 0x78)

(few seconds later)
S->C 0x5E 28 bytes
C->S 0x5E 43 bytes
[/quote]

Careful, there. Are you sure you're not just receiving a file still? I have received 5Eh numerous times in a simple recv/reply fashion. No additional data.
[/quote]

i think so because all the packets have ff 5E fb 01 in the front, and the client doesn't ask for any file before starting to receive the ones without the header.

[quote author=betawarz link=topic=16758.msg169769#msg169769 date=1181073984]
[quote author=l2k-Shadow link=topic=16758.msg169764#msg169764 date=1181073140]
you're right.. it appears like this:

S->C 0x5E 41 bytes (random number i guess)
C->S 0x5E 1 byte (i got 0x8D)

S->C Mass of data (thousands of bytes) some packets have 0x5E header, some don't - sending a file perhaps? - although it doesn't use the FTP connection
C->S 0x51 1 byte (i got 0x78)

(few seconds later)
S->C 0x5E 28 bytes
C->S 0x5E 43 bytes
[/quote]

Careful, there. Are you sure you're not just receiving a file still? I have received 5Eh numerous times in a simple recv/reply fashion. No additional data.
[/quote]
You would only get the large amount of data 1st logon with the client, after that, its uptodate.
Im 99.9999% sure this is warden :P
After the warden version check, the client is requested a new check every 15seconds.
It looks almost like (from a few dumps) it works in almost/exacly the same way as d2 warden client.

check out bncache.dat:
[quote]
67d66f46a09ac454b61d980c0820ba0d.mod
[/quote]

great file name - md5 hash of something?, the data i guess?

[quote author=l2k-Shadow link=topic=16758.msg169772#msg169772 date=1181075225]
check out bncache.dat:
[quote]
67d66f46a09ac454b61d980c0820ba0d.mod
[/quote]

great file name - md5 hash of something?, the data i guess?
[/quote]
Hmm, if d2 warden client is anything to go by, the packet payloads are encrypted both ways (I think d2 uses a RC4 encryption), and one of the tokens (server/client/udp most likely for sc/bw) is used as the encrption key.
The 67d66f46a09ac454b61d980c0820ba0d.mod should be a module of asm code, that the client uses to make the result out of the request. Blizzard can and normaly do update that anti hack code at anytime on d2.
Im no expert on the warden client tho, but if d2 warden client is anything to go by, bnet warden client will be the same if not a slightly modify version of the one wow,w3,d2 uses.
Now we know the BNCS warden packet, im now interested to know what other clients have warden installed and enabled, but switched off :P

According to Saren, from bwhacks.com:

[quote]
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.
[/quote]

Someone just reported this packet to me also...

[1:36:29 PM] Unhandled packet: 0x5E
[1:36:29 PM] FF 5E 29 00 39 C2 59 F4 13 53 67 F3 D2 E6 18 B2 ÿ^).9ÂYô.SgóÒæ.²
[1:36:29 PM] 98 51 2B E3 F2 06 4E 75 31 C2 A9 8E 00 32 53 45 ˜Q+ãò.Nu1©Ž.2SE
[1:36:29 PM] D9 5C 56 6D 18 46 C3 0F 74 Ù\Vm.FÃ.t.......


[1:45:42 PM] Unhandled packet: 0x5E
[1:45:42 PM] FF 5E 29 00 05 44 A9 B9 E5 66 E7 6D 45 97 D6 AA ÿ^)..D©¹åfçmE—Öª
[1:45:42 PM] B9 EE 07 56 E6 0F 99 A1 C4 ED ED 32 5C 66 B7 F5 ¹î.Væ.™¡Äíí2\f·õ
[1:45:42 PM] 8B F2 3F 2E D6 86 AF A7 09 ‹ò?.Ö†¯§........


That is more than 15 seconds, this bot is not responding though...

[quote author=betawarz link=topic=16758.msg169774#msg169774 date=1181078278]
According to Saren, from bwhacks.com:

[quote]
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.
[/quote]
[/quote]
Nice, that sounds pretty mild, any idea if that is what the current module is doing?
I get the feeling blizzard would change that if needed :(

Also does anyone know the process memory offset for 1.15 sc/bw's storm.dll and battle.snp?

[quote author=Ringo link=topic=16758.msg169780#msg169780 date=1181081015]
[quote author=betawarz link=topic=16758.msg169774#msg169774 date=1181078278]
According to Saren, from bwhacks.com:

[quote]
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.
[/quote]
[/quote]
Nice, that sounds pretty mild, any idea if that is what the current module is doing?
I get the feeling blizzard would change that if needed :(

Also does anyone know the process memory offset for 1.15 sc/bw's storm.dll and battle.snp?
[/quote]

0x15000000 storm
0x19000000 battle

i think

Intresting Seems they are already modifying it So iago what might say you?

I say it was lucky timing. I'm told that they use Warden for all the other clients, it was just a matter of time before they used it for Starcraft.

I think we should stick with 1 thread to post iago you choose :).

[quote author=iago link=topic=16758.msg169803#msg169803 date=1181106009]
I say it was lucky timing. I'm told that they use Warden for all the other clients, it was just a matter of time before they used it for Starcraft.
[/quote]
I heard warden disconnects you if you don't reply to it... Is this true?

It disconnects you after about roughly 2 minutes when you don't respond to it. I havent done much research so if you respond to it every 110 seconds wouldn't you be fine?

[quote author=l2k-Shadow link=topic=16758.msg169785#msg169785 date=1181088609]
0x15000000 storm
0x19000000 battle

i think
[/quote]

Thanks, im gonner need them abit later :P


[quote author=Denial link=topic=16694.msg169805#msg169805 date=1181106281]
Lockdown 2 = Warden :) But this isnt the end of it wait until later this week.
[/quote]
[quote author=Denial link=topic=16758.msg169802#msg169802 date=1181105293]
Intresting Seems they are already modifying it So iago what might say you?
[/quote]
[quote author=Denial link=topic=16758.msg169806#msg169806 date=1181106343]
I think we should stick with 1 thread to post iago you choose :).
[/quote]
Lockdown = lockdown, warden = warden, they are not the same thing, and have little, if any thing to do with each other :)
And I maybe wrong, but I havent noticed any changes to the lockdown dlls, and the warden client that is built into sc/bw has been present, but unactive since 1.13 I think :P
They just switched it on as a last resort.

[quote author=Denial link=topic=16758.msg169810#msg169810 date=1181126056]
It disconnects you after about roughly 2 minutes when you don't respond to it. I havent done much research so if you respond to it every 110 seconds wouldn't you be fine?
[/quote]
Yes :P this will sort of be the princibles that my BNWS (battle net warden server) will work on, when Its finished later today.
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 :)

Ringo, The lockdown 2 is a joke which was started a few days before this came out it started when iago posted his code for lockdown. We weren't being serious about them two actually being related. Also the exact time is between 2 minutes and 2 minutes and 12 seconds is when you get disconnected from broodwar.

According to StarCrap's post on bwhacks you only have to reply to this packet with 1 byte, I haven't been able to get a packet log (of what byte is being returned) as yet since I don't have a StarCraft cd-key. According to him it updates your bncache.dat with some asm which is responsible for creating the appropriate hash to respond to the server with.

[quote author=Denial link=topic=16758.msg169813#msg169813 date=1181133176]
Ringo, The lockdown 2 is a joke which was started a few days before this came out it started when iago posted his code for lockdown. We weren't being serious about them two actually being related. Also the exact time is between 2 minutes and 2 minutes and 12 seconds is when you get disconnected from broodwar.
[/quote]

It'll give you 2 minutes to respond after you log on, then after that you're dropped (how quickly depends on how your client handles connection)

[quote author=Denial link=topic=16758.msg169813#msg169813 date=1181133176]
Ringo, The lockdown 2 is a joke which was started a few days before this came out it started when iago posted his code for lockdown. We weren't being serious about them two actually being related.
[/quote]
Oh :)

I have ran out of time again, and still havent found the encryption key :(
I have done a fair bit of testing so far, and im pretty sure the encryption key is computed from a few logon values and not like D2, where the game hash is used as the encryption key. I have a hunch it is the server and client token used to make the key.
Also i dont know if this is 0x3A vs 0x29 related or 0x06, 0x07, 0x36 vs 0x50, 0x51 (I didnt get time to check) but when you logon starcraft/broodwar with 0x06, 0x07, 0x36, 0x29, the warden version check is pretty much static across all the battle.net realms/address's, meaning the encrytion key is static. That makes me think, the encrytion key is unique to one or two packet handlers server side. (0x51 or 0x29/0x3A)
However, every hour or so, it seems to change, leaving me puzzled  :-\

Has anyone looked into the encryption key yet?

While investigating, I ran across 2 other packets in battle.snp that I have never encountered.  They seem to be undocumented on bnetdocs as well.

0x17 and 0x24

I didn't examine them close enough to find their purpose.

youll find plenty of interesting things while reversing blizzard games, heh.

Im just wundering if and how anyone is coming along with this?

I came back to it yesterday/today and I have a good idea what needs to be done.
Does anyone know the offset to 0x50 handler/0x51 builder, in battle.snp? or better still, know how I would go about setting Starcrafts clienttoken to zero when its building 0x51, rather than the tickcount of the cpu?
I think this is all I need to do to get warden to chase its tail, can anyone help here?

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

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]
    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
[/code]

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

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 :D

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.

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

Funny that people release working versioncheck then this is enabled? ::)

[quote author=iago link=topic=16758.msg169962#msg169962 date=1181435303]
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.

[/quote]
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 :D
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() :P
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 :P

Thanks for the help!

[quote author=UserLoser link=topic=16758.msg169977#msg169977 date=1181498057]
Funny that people release working versioncheck then this is enabled? ::)
[/quote]

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.

[quote author=Joe[x86] link=topic=16758.msg169998#msg169998 date=1181577661]
[quote author=UserLoser link=topic=16758.msg169977#msg169977 date=1181498057]
Funny that people release working versioncheck then this is enabled? ::)
[/quote]

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.
[/quote]
That kind of goes with out saying? :P

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]
0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit
[/code]
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?

[quote author=Joe[x86] link=topic=16758.msg169998#msg169998 date=1181577661]
[quote author=UserLoser link=topic=16758.msg169977#msg169977 date=1181498057]
Funny that people release working versioncheck then this is enabled? ::)
[/quote]

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.
[/quote]
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.

[quote author=iago link=topic=16758.msg170004#msg170004 date=1181581503]
[quote author=Joe[x86] link=topic=16758.msg169998#msg169998 date=1181577661]
[quote author=UserLoser link=topic=16758.msg169977#msg169977 date=1181498057]
Funny that people release working versioncheck then this is enabled? ::)
[/quote]

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.
[/quote]
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.
[/quote]

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 :P.  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)

[quote author=betawarz link=topic=16758.msg169774#msg169774 date=1181078278]
According to Saren, from bwhacks.com:

[quote]
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.
[/quote]
[/quote]

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.

[quote author=Joe[x86] link=topic=16758.msg169998#msg169998 date=1181577661]
[quote author=UserLoser link=topic=16758.msg169977#msg169977 date=1181498057]
Funny that people release working versioncheck then this is enabled? ::)
[/quote]

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.
[/quote]

[quote author=·RealityRipple· link=topic=16758.msg170006#msg170006 date=1181588054]
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...
[/quote]

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.

[quote author=Ringo link=topic=16758.msg169812#msg169812 date=1181129732]
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 :)
[/quote]

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.

[quote author=Ringo link=topic=16758.msg170001#msg170001 date=1181580648]

[code]
0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit
[/code]
[/quote]


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

[quote author=Rob link=topic=16758.msg170018#msg170018 date=1181611701]
[quote author=Ringo link=topic=16758.msg170001#msg170001 date=1181580648]

[code]
0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit
[/code]
[/quote]


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
[/quote]
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. :P
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.

[quote author=herzog_zwei link=topic=16758.msg170013#msg170013 date=1181594498]
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.
[/quote]

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

[quote author=Rob link=topic=16758.msg170018#msg170018 date=1181611701]
[quote author=Ringo link=topic=16758.msg170001#msg170001 date=1181580648]

[code]
0x1904216A -> 32bit
0x19043F61 -> 128bit hash
0x190467CA -> 32bit
0x19046FF5 -> 32bit
[/code]
[/quote]


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
[/quote]

0x19042168 = Unsure.  IDA states that this is FileTime.dwHighDateTime.  I did not debug to verify.
This seems to be the first 4 bytes of the CDKey value hash. The variable its set from is also the mpq's high filetime, the cdkey public value, and blank for awhile. It really gets around :)

0x19046FF5 = a FileTime struct
Specifically, it seems to be a FileTime struct whose value is the current system time.

http://www.bwhacks.com/forums/showthread.php?t=24708