Rudimentary Warden information

I know what's throwing me off (not really, but I'd rather have a viable reason to complain about it)... typos.

On Starcraft, the first 4 bytes of the CDKey hash are used. That's the actual CDKey has that's sent over the wire as part of SID_AUTH_CHECK.

Hash?
And unimportant, but, spot what's not a byte:

00 a2 d4 d6 4c 46 8e 56 4f 42 c6 s4 68 e4 5d 6a 46 5f 46 b4 5c 24 d5 46 e4 56 a6 4d 75 2d 21 f8 79 05 0b 00 00

As for Myst, I'm afraid I have no clue what you're talking about... Have fun whoever's gonna reverse 0x02, and good job iago (as if you need more congrats).

Very interesting, great job on this iago, doesn't seem as complicated as everyone once thought!

Just two problems I am encountering while trying to compile this in Java, 1 you haven't included the util.Buffer source code; and 2 WardenSHA1 is missing...

Very interesting, great job on this iago, doesn't seem as complicated as everyone once thought!

Just two problems I am encountering while trying to compile this in Java, 1 you haven't included the util.Buffer source code; and 2 WardenSHA1 is missing...

The Java version of SHA1 is already there:
http://www.skullsecurity.org/wiki/index.php/SHA1_in_Java

For some reason I didn't think you needed util.Buffer (do you?), but in any case, here it is:
http://www.skullsecurity.org/wiki/index.php/Util.Buffer

I know what's throwing me off (not really, but I'd rather have a viable reason to complain about it)... typos.

On Starcraft, the first 4 bytes of the CDKey hash are used. That's the actual CDKey has that's sent over the wire as part of SID_AUTH_CHECK.

Hash?
And unimportant, but, spot what's not a byte:

00 a2 d4 d6 4c 46 8e 56 4f 42 c6 s4 68 e4 5d 6a 46 5f 46 b4 5c 24 d5 46 e4 56 a6 4d 75 2d 21 f8 79 05 0b 00 00

As for Myst, I'm afraid I have no clue what you're talking about... Have fun whoever's gonna reverse 0x02, and good job iago (as if you need more congrats).

Why are you looking for things to complain about? Mr I dont care about SC but i care about typo's.
What species of retard are you?
You should be extremely greatfull iago shared this infomation with the botdev community, not complaining about anything you find mistyped!
Anyone would think your getting annoyed because you cant just implement this into a vb6 OCX in 5mins.

Aside, if anyone is trying to implement this in vb6, these links may be helpfull:
VB6 RSA encryption:
http://www.cryptosys.net/pki/rsa_encrypt_ex.html
VB6 MD5 hashing:
http://www.vbforums.com/showthread.php?s=&threadid=232284
And i think warden uses the same SHA1 function used for BNCS cdkey/password hashing(?)
I have only flicked through it, but i remember iago saying somthing about the only differnce is the data in, is more big-endian-like.
iago, Is there any other difernces to bnets broken SHA1 function other than that?
I persionaly let Starcraft do almost all the hard word for me, then built a DB that i have been useing for ages now with constant success, so i dont have much experiance with the inner workings of warden.

Aside, if anyone is trying to implement this in vb6, these links may be helpfull:
VB6 RSA encryption:
http://www.cryptosys.net/pki/rsa_encrypt_ex.html
VB6 MD5 hashing:
http://www.vbforums.com/showthread.php?s=&threadid=232284

Strictly speaking, you don't NEED the MD5 or RSA, they're just for verification. They do, however, tell you that you're on the right track, which is always nice.

And i think warden uses the same SHA1 function used for BNCS cdkey/password hashing(?)
I have only flicked through it, but i remember iago saying somthing about the only differnce is the data in, is more big-endian-like.
iago, Is there any other difernces to bnets broken SHA1 function other than that?

I couldn't say, I haven't compared it to the broken SHA1 function.

I CAN tell you, however, that it's almost identical to the SHA1 implementation used in Lockdown, except with Endianness reversed in some key places. That, I can verify.

The implementation used in Lockdown, I'm told, is almost identical to standard SHA1, except with some extra padding in SHA1-final. That, I haven't verified.

ah
I decided to have ago at implementing this, just for a better understanding of it.
But im really struggleing with this modifyed SHA1 function (plus im not native to C)
Im trying to do this padding, but im a little unsure what and how much needs to get padded.
Im guessing its somthing to do with the chunks of data that get hashed in 0x40 chunks -- is it the end chunk that gets padded to 0x40 bytes?
Im not so worryed about inverting the byte order just yet, but its hard as i have no test hash to compare with (only the ones you have provided with inverted byte order as well as padding)
Is there any chance you could explain what and where gets padded?
thanks in advance

ah
I decided to have ago at implementing this, just for a better understanding of it.
But im really struggleing with this modifyed SHA1 function (plus im not native to C)
Im trying to do this padding, but im a little unsure what and how much needs to get padded.
Im guessing its somthing to do with the chunks of data that get hashed in 0x40 chunks -- is it the end chunk that gets padded to 0x40 bytes?
Im not so worryed about inverting the byte order just yet, but its hard as i have no test hash to compare with (only the ones you have provided with inverted byte order as well as padding)
Is there any chance you could explain what and where gets padded?
thanks in advance

Search for old information on lockdown, posted by, iirc, warz or rob.

As far as I know, the padding is done in SHA1_final(), and is the "80 00 00 00 00,....." string. But don't quote me on that.

IIRC, that is in C or C++ as well, so its the same problem -- the vb6 port of broken SHA1 i have studyed in the past has them bound into one.
Where it transforms the data in blocks of 0x40 im guessing is where the padding comes into play.
Is it transformed before the end block, or before each block?
THe final function im sturggling to understand where it comes into play

aye, a mod finally split the shit from this thread.
say, iago, did you find your warden_sha1_update at 19010dd0? Am I nuts, or is it the only sha1-updateish-function with a right 0x1D bitshift ....?

I'm guessing that post got trashed because of the first line. Whatever the case, I got rid of the crap and fixed it, who says having mod in the trash is silly?

Anyway, that function that you indicate, I have marked as standard SHA1. It's used by the generate_x() (190116B0) function in NLS, and NLS uses standard SHA1. The Warden one is within the module, In the default module, the function at +0x1112 calls the warden_sha1_init(), warden_sha1_update(), and warden_sha1_final() functions.

Anyway, that function that you indicate, I have marked as standard SHA1. It's used by the generate_x() (190116B0) function in NLS, and NLS uses standard SHA1. The Warden one is within the module, In the default module, the function at +0x1112 calls the warden_sha1_init(), warden_sha1_update(), and warden_sha1_final() functions.

ah i had it marked as standard at first too. dunno why but i never bothered to check where it's refrenced. Not to mention that it's about 0x20kb below where the rest of warden is. Went right over my head.

meh.
If somone wants to explain to me how this padding takes effect, that would be great.
I dont want to just be directed to some open source code, since that doesnt answer my question.
I could just compile iagos C source into a dll, or spend a whole day porting it to VB, but indoing that, I would learn nothing.
All the other broken SHA1 i seem to come across in this forum have 2 functions, CalcHashBuf() and DataHash() making it very hard to pick apart what iagos code is doing.
But as im seeing it, the update brakes the data into blocks of 64 bytes (from end to start), padds it will null bytes and then hash's it into 5 dwords against the last chunk/seeds.
But when I look at iago's hash function:

Code: [Select]

void warden_sha1_hash(int buffer[5], unsigned char *data, int length)
{
    SHA1_CTX ctx;
               
    //Inits the 1st 5 dwords in the ctx structure with the seeds
    warden_sha1_init(&ctx);

    //hashs the in-data in blocks of 64 bytes a time
    warden_sha1_update(&ctx, data, length);

    //then does some final stuff?
    warden_sha1_final(&ctx, buffer);
}
Its double updateing/hashing, 2nd hash being the MysteryBuffer?

Code: [Select]

    //unless im reading this wrong, wouldnt this be a negative number?
    //Doesnt seem so important since blocks that are not 64 bytes are padded?
    len = ((-9 - (ctx->bitlen[0] >> 3)) & 0x3F) + 1;

    //hashs the "MysteryBuffer" into the existing 5 dword hash
    warden_sha1_update(ctx, MysteryBuffer, len);

    //hashs the 8 bytes from the start of the structure into the existing 5 dword hash? (byte order switched)
    warden_sha1_update(ctx, (char *)vars, 8);
So, orginal broken SHA1 didnt need/have a final function?
I have already tryed this a few ways, and thought for awhile that the lengh of the MysteryBuffer hashed was important, but its padded with nulls anyway, and mostly consists of null bytes (x80, x00, x00 etc), so that doesnt seem so important.
Im still alittle unsure what this bitlen is all about (I have not yet traced it all the way around the code tho) but it seems to be hashed as well, so im guessing its important.
Im guessing that the bitlen is unique to warden/lockdown SHA1, as I dont see its relation in the main broken SHA1.
Would somone mind explaing to me whats going on here?
Im not botherd if i can get working or not (thats not important) i just want to understand what and why is differnt to the orgianl broken SHA1.

Sorry if i come across all newbie, thats because i am
And sorry for my lack of grammer skills -- no bodys perfect
Altho i expect i have gotten this right a few times, but i dont have a raw hash to compare with, so i dont think i would know -- i dont want to do the byte switching untill i know i have understod this bit, other wise 2 problems could create a bottomless pit.
Its really not a language specific problem, its more of an explanation problem, altho im sure im missing somthing blatently oveous, but eh, i have about 10 other things on the go as well

Thanks in advance to anyone who can explain this!

I think maybe the best thing would be a description of the differences between each version of SHA-1 used, compared to Standard SHA, referencing no particular implementation...

Standard vs Broken: Switch RoL arguments, buffer input to 0x40 bytes with null bytes... uh.. what else?
Standard vs Lockdown: I dunno.
Standard vs Warden: Lockdown + I dunno even more.

It'd prolly be good to have such a list in the bot development references subforum...? Perhaps with the C code for each or something?

hmm, having another poke at this today, starting to become abit more clear, but my vision is still a little blured.
After having a 2nd think about it, my main problem is the update function. (asuming the transform/hashing algorithm remains constant)

For example, the orginal broken SHA1 function does as follows:
Lets say we are hashing the string 0x00 to 0x64 (x00, x01, x02, x03 etc)
We initialize the hash buffer with the seeds: (lets call this H for now)

Code: [Select]

0123456789ABCDEFFEDCBA9876543210F0E1D2C3
Then we make sure are buffer-to-be-hash is divisible by 64, in this case, the 0x65 byte data would be padded with about 27 null bytes (x01, x02.... x63, x64, x00, x00, x00 etc) resulting in 128 byte of data to be hashed:

Code: [Select]

Before:
000102030405060708090A0B0C0D0E0F
101112131415161718191A1B1C1D1E1F
202122232425262728292A2B2C2D2E2F
303132333435363738393A3B3C3D3E3F
404142434445464748494A4B4C4D4E4F
505152535455565758595A5B5C5D5E5F
6061626364

After:
000102030405060708090A0B0C0D0E0F
101112131415161718191A1B1C1D1E1F
202122232425262728292A2B2C2D2E2F
303132333435363738393A3B3C3D3E3F
404142434445464748494A4B4C4D4E4F
505152535455565758595A5B5C5D5E5F
60616263640000000000000000000000
00000000000000000000000000000000
Then we hash/transform a block of the raw 128 byte buffer (orginaly 0x65 bytes) with are Hash buffer (H) by appending a block of raw data to H.
Each block of raw data is appended to H and then hashed/transformed in 64 byte chunks at a time:

0123456789ABCDEFFEDCBA9876543210
F0E1D2C3000102030405060708090A0B
0C0D0E0F101112131415161718191A1B
1C1D1E1F202122232425262728292A2B
2C2D2E2F303132333435363738393A3B
3C3D3E3F

Now, after hashing/transforming this H+chunk buffer into H, the H buffer becomes:

Code: [Select]

CC2B23B6A048E79466583D880065D36B53AD3A94
We then take the 2nd chunk of the orginal raw buffer and repeat:

CC2B23B6A048E79466583D880065D36B
53AD3A94404142434445464748494A4B
4C4D4E4F505152535455565758595A5B
5C5D5E5F606162636400000000000000
00000000000000000000000000000000
00000000

H then becomes:

Code: [Select]

2298255598EFA4E655ABAF9C21806AFC85FEB4B7
And in this case, we have no more chunks of raw data to process, so we return H, and that is the resulting broken SHA1 hash.
That is the standard out line of the orginal broken SHA1 used for cdkey and password hashing for BNCS logons.

How ever, in this lockdown/warden version of broken SHA1, the update process seems a bit more complicated.
Lets forget about byte order switching for the moment.
Its doesnt look like the data is broken up into chunks the same way as above or appended to H in the same manner (unless im missing somthing), for one, there is a 64bit int (known as bitlen in iagos code) that is computed apon each update cycle.
It looks as if the pre-calculation on this 64bit int dictates the next arrangement of the H+raw data block.
And after the updating process of the raw data, the MysteryBuffer (see below) is updated into H as well, which the lengh is dictated by that 64bit int, then the 64bit int is also updated into H, then the resulting H is returned as the resulting SHA1 hash.

Code: [Select]

80000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00000000000000000000000000000000
00
This is the 64bit int part im talking about:

Code: [Select]

/* The next two lines multiply len by 8. */
c = len >> 29;
b = len << 3;

a = (bitlen[0] / 8) & 0x3F;

/* Check for overflow. */
if(bitlen[0] + b < bitlen[0] || bitlen[0] + b < b)
bitlen[1]++;
bitlen[0] = bitlen[0] + b;
bitlen[1] = bitlen[1] + c;

len = len + a;
data = data - a;
I would guess below that, is where the padding of non-divisible by 64 blocks takes place, but im struggleing to understand what the code is fully doing as it lacks any comments.
Asuming the transform/hashing algorithm is the same, could somone please explain how this update process is working in the warden/lockdown version of SHA1?
Im struggleing to understand the way its broken up into 64 byte blocks/being padded.

If anyone could explain in a similar fashion as i explained the standard broken SHA1 above, that would be great.
thanks in advance.

Well one thing that I found weird (although it could be a mistake on my part) is that i can now decode the 0x00 request of is your module here, and the response packet fine, then I can decode the 1st 0x02 warden request and it's response, but the 2nd 0x02 warden request comes out funky after being decoded. Is this supposed to happen?

Personally, I've never looked past the first packet, so I couldn't say. It's possible that it saves the state of the encryption key before the 0x02 packet, and uses the encryption routine in the same state for every request (it does have functionality for saving/loading the encryption key).