clsCRDB class for SC/BW lockdown

[Ringo]

Ok this is based on an idea i have had for a long time, and used to use it to stop mass calling of CheckRevision() when loading more than 1 connection.

Anyway, what is CRDB?
CRDB (Check revision database) is a class designed to work with battle.net bots that use BNLS for the latest lockdown version checking.
It works by your bot reporting its successfull CheckRevisions to the CRDB class.

Over the last 24 hours I have ran a test program that connects to all battle.net servers reporting all checkrevisions to CRDB and now have around 400 - 500 checkrevisions stored.
(hdx was talking about 2000 possible values, so if this is the case, not far to go)
Some of you may have noticed before, when you logon a battle.net server, the checkrevision formula doesnt change on that server for some time, so if you were to reconnect in that time, the checkrevision request would be exacly the same as it was before.
Its also the same for 1 file number/formula being used by multiple servers at the same/differnt times.
So once you have the results for a set file/formula, you wont need to use BNLS for it untill next patch.
No point requesting the same version check multiple times

Anyway, the CRDB code is here: Here
And the CRDB file is here: Here

And this is how to use it:

You need Load the CRDB file when your program opens:

Code Select Expand


Call hCRDB.LoadCRDB(App.Path & \CRDB.bin)

You need to save the CRDB file when your program closes:

Code Select Expand


Call hCRDB.SaveCRDB(App.Path & \CRDB.bin)

The CRDB file can be named anything, with any extention and will be created if not present when saving.

Then when it comes to doing a version check, and you have the mpqfile name, filetime and formula string:

Code Select Expand


    Dim lngVersion  As Long
    Dim lngChecksum As Long
    Dim strExeInfo  As String
    Dim strAddTime  As String

    If hCRDB.GetCR(m_ClientID, _
                       m_FileName, _
                       m_FileTime, _
                       m_Formula, _
                       lngVersion, _
                       lngChecksum, _
                       strExeInfo, _
                       strAddTime) = True Then
       
        'Send 0x07/0x51 with lngVersion, lngChecksum and strExeInfo
        'strAddTime is a string containing the time this version check was 1st reported.
       
    Else
       
        'Use BNLS
       
    End If

(Note, the m_ClientID long variable is that of Bnets and not BNLS's)


Then when you successfully pass a checkrevision and have all the values:

Code Select Expand


    Call hCRDB.ReportCR(m_ClientID, m_FileName, m_FileTime, m_Formula, m_Version, m_Checksum, m_EXEinfo)

Now, next time this checkrevision is needed, GetCR() should return it.



Anyway, i dont care about credits or anything like that,  i thought this would be a good addition for bot dev'ers and alot less work for BNLS.
I hope some find it usefull

[Chriso]

Thanks, I wasn't sure if this was possible I thought the values returned might have been different every time. Good job with the work-around.

[Hero]

Very nice. Thanks.

Edit:
Is the product like STAR, or RATS?

[l2k-Shadow]

I made a C++ dll for writing/reading the storage file for the sake of speed if it got big, but I tried to reconnect to the same server and the request was different every time so upon doing this like 100 times I just gave up, I'm interested on seeing how the 2000 possible values thing will go though.

[Ringo]

Is the product like STAR, or RATS?

RATS inthe CRDB.bin, but if you do a new one, it doesnt matter to much

I made a C++ dll for writing/reading the storage file for the sake of speed if it got big, but I tried to reconnect to the same server and the request was different every time so upon doing this like 100 times I just gave up, I'm interested on seeing how the 2000 possible values thing will go though.

Atm, this will logon 20ish% of the time so 2000 does seem around the right number.
The test program i ran yesterday was connecting 0x1E, 0x06, where the version check changing is very very slow, but 0x50 is random and differnt for each login.
Even connecting and useing 0x50, you have 20% chance to login with the CRDB.bin file.
I shoulda ran it on 0x50, but i forgot that 0x50 is the randomized one, and now BNLS is down and im to lazzy to proxy SC

Im currently doing a test BNLS server for some moaning friends ;p so if anyone wants to give it a try: 84.9.66.218
It just accepts SC/BW, 0x10 and 0x1A and runs off of that CRDB file.

Thanks for the thanks all

[l2k-Shadow]

ah yeah see i was using 0x50

EDIT: nice i logged in using your server 3rd try, i guess it really isn't as randomized as i thought 

[warz]

Well, I did notice this, even with the newer logon method. Over periods of days, battlenet will provide a code value that is has provided in the past, and will always request use of the same lockdown file, too. This has entered my mind, once I saw this trend , but is obviously unreliable. I noticed this while debugging several different lockdown files, so I assume it's the same with all of them. Although a poor solution, it's interesting. Just a few questions though - what happens when a patch is released? who's to say there are really "only 2000" code values? you begin to see why this temporary fix is just that, temporary.

[l2k-Shadow]

Well, I did notice this, even with the newer logon method. Over periods of days, battlenet will provide a code value that is has provided in the past, and will always request use of the same lockdown file, too. This has entered my mind, once I saw this trend , but is obviously unreliable. I noticed this while debugging several different lockdown files, so I assume it's the same with all of them. Although a poor solution, it's interesting. Just a few questions though - what happens when a patch is released? who's to say there are really "only 2000" code values? you begin to see why this temporary fix is just that, temporary.

so is reversing lockdown, who knows when they are gonna whip out a new library? 

[Ringo]

Well, I did notice this, even with the newer logon method. Over periods of days, battlenet will provide a code value that is has provided in the past, and will always request use of the same lockdown file, too. This has entered my mind, once I saw this trend , but is obviously unreliable. I noticed this while debugging several different lockdown files, so I assume it's the same with all of them. Although a poor solution, it's interesting. Just a few questions though - what happens when a patch is released? who's to say there are really "only 2000" code values? you begin to see why this temporary fix is just that, temporary.

Well, its not really a fix, its somthing to work with a bot that uses BNLS, so that it can slowly use BNLS less and less, untill over all, the desired goal would be to have all the version check formulas in the data base, and not need BNLS untill the bot sees a new formula.
The theory is an old one, that i was day dreaming about well before lock down, when i was writeing a battle.net server.
How does the battle.net servers manage checkrevision?
After thinking about it for awhile, there is only a few logical ways to do it.
1. The server runs a copy of each client, so that it can do checkrevision.
2. The server always uses a *work around* checkrevision method to mirror its clients version check results -- making a work around method always possible
3. The server has a formula list ready run off of the clients
For my server, i went with the 3rd idea and i figgers so did blizzard.

For this CRDB, the idea i had in mind for when a patch comes out, and BNLS has been updated for the changes, the user (or bot) would just delete the CRDB.bin file, and start again.

Its still a kinda on going test to see if it gets to 100% reliablity, how ever, it should drasticly reduce the connections on BNLS.

[l)ragon]

how large is the file?

[Ringo]

Ah, geocities is dieing
At current, 28kb or somthing around that. Based on 20%, 100% would be about 140kb
Better than the clunky binarys i guess

Edit: Theres also a 8 byte file time structure in each item, so thats gota be around 20 - 30% bigger -- thats not needed, but is handy to know how far back the checkrevision results are going back

[l)ragon]

Ah, geocities is dieing
At current, 28kb or somthing around that. Based on 20%, 100% would be about 140kb
Better than the clunky binarys i guess

Edit: Theres also a 8 byte file time structure in each item, so thats gota be around 20 - 30% bigger -- thats not needed, but is handy to know how far back the checkrevision results are going back

interesting thx.

[l2k-Shadow]

I'm going to leave in about hour and a half for a few hours and I'll proxy up sc and let it make checkrevision requests by itself.

Working with HDX's star.dat file from the other topic, i'll store requests which it doesn't have into it and try to get as many requests into it as possible.

[Newby]

so is reversing lockdown, who knows when they are gonna whip out a new library? 

They are more likely to just be happy and change values if the majority of the kids are bruteforcing like n00bs, as opposed to implementing an entirely new CheckRevision.

[Chriso]

RaidenMZX + Ante have released a Lockdown VB6 OCX file which logs onto StarCraft / Broodwar about 90% of the time.

Read more:
http://miragechat.net/support/index.php?topic=1133.0