DarkBlizz

gzxaaa. The installer validates the authentication key, which means that there's something in the installer that checks the authentication key, if you find this you can narrow down the possible authentication keys than that makes brute forcing it easier as you remove a bunch of invalid keys.

Quote from: obliviron on July 19, 2010, 09:21:54 PM

Quote from: darkrei9n on July 19, 2010, 08:57:09 PM
The 256 bit key I believe is retrieved somehow by the Authentication code for sure than. The Authentication Code and the Decryption code are the one and the same. As proof I present that there is no storage space for authentication code, however when you change a jump address from jz to jnz it opens a screen where you manually enter the authentication code, this than goes directly down to a section of code containing hasValidDecryptionKey.

This means that the authentication key is also checked. Then there are 3 characters that are restricted. So that narrows down the decryption key further.

Yeah, it's the auth code. Now all you gotta do is guess a 10 - 20 digit & alphanumerical number.

30 digits. Its a 30 digit number. Also, the code is validated. So we can make a keygen based off of what is found acceptable and try all those.

The 256 bit key I believe is retrieved somehow by the Authentication code for sure than. The Authentication Code and the Decryption code are the one and the same. As proof I present that there is no storage space for authentication code, however when you change a jump address from jz to jnz it opens a screen where you manually enter the authentication code, this than goes directly down to a section of code containing hasValidDecryptionKey.

This means that the authentication key is also checked. Then there are 3 characters that are restricted. So that narrows down the decryption key further.

Everything that I've seen points them out to be one of the same.

Quote from: 7H3LaughingMan on July 19, 2010, 02:29:43 PM

Quote from: darkrei9n on July 19, 2010, 02:04:22 PM
This is where the authentication key is checked, if anyone can do anything with this.

Code Select Expand

cé


; int __stdcall sub_4447E0(HINSTANCE hInstance, HWND hWndParent, int, char, int, int)
sub_4447E0 proc near

hInstance= dword ptr  4
hWndParent= dword ptr  8
arg_8= dword ptr  0Ch
arg_C= byte ptr  10h
arg_10= dword ptr  14h
arg_14= dword ptr  18h

mov     eax, [esp+arg_8]
mov     edx, [esp+arg_10]
push    ebx
mov     [ecx], eax
mov     al, [esp+4+arg_C]
xor     ebx, ebx
push    ebx             ; dwInitParam
mov     [ecx+26h], al
mov     eax, [esp+8+hWndParent]
push    offset sub_4440A0 ; lpDialogFunc
mov     [ecx+4], edx
mov     edx, [esp+0Ch+arg_14]
push    eax             ; hWndParent
mov     [ecx+24h], bl
mov     [ecx+25h], bl
mov     [ecx+28h], edx
mov     ecx, [esp+10h+hInstance]
push    87h             ; lpTemplateName
push    ecx             ; hInstance
call    ds:DialogBoxParamW
cmp     eax, 1
mov     al, 1
jz      short loc_444828


There is nothing to do here, if the authentication code is a valid format then it moves on and tries to decrypt the files using it. There is only 1 valid code that will decrypt the files, it is only stored on the blizzard servers.

When you provide me proof is when I will listen to people like you. All you have to back you up are your claims.

This is where the authentication key is checked, if anyone can do anything with this.

cé


; int __stdcall sub_4447E0(HINSTANCE hInstance, HWND hWndParent, int, char, int, int)
sub_4447E0 proc near

hInstance= dword ptr  4
hWndParent= dword ptr  8
arg_8= dword ptr  0Ch
arg_C= byte ptr  10h
arg_10= dword ptr  14h
arg_14= dword ptr  18h

mov     eax, [esp+arg_8]
mov     edx, [esp+arg_10]
push    ebx
mov     [ecx], eax
mov     al, [esp+4+arg_C]
xor     ebx, ebx
push    ebx             ; dwInitParam
mov     [ecx+26h], al
mov     eax, [esp+8+hWndParent]
push    offset sub_4440A0 ; lpDialogFunc
mov     [ecx+4], edx
mov     edx, [esp+0Ch+arg_14]
push    eax             ; hWndParent
mov     [ecx+24h], bl
mov     [ecx+25h], bl
mov     [ecx+28h], edx
mov     ecx, [esp+10h+hInstance]
push    87h             ; lpTemplateName
push    ecx             ; hInstance
call    ds:DialogBoxParamW
cmp     eax, 1
mov     al, 1
jz      short loc_444828


I found a second reference to MPQE, think I found where it does decryption.

Update. After some careful hex editing we have no bypassed the first error achieved, FAILURE TO OPEN <EULA>, it now opens the eula window properly and goes onto install WITHOUT any XML editing. We need to get it to decrypt however still.

I just need a bit more info until I get this cracked. I just need to know what kind of changes Im making, am I changing where the jumps jump to or changing the type of jumps.

Okay, this is what I'm gonna try, I'm gonna open the thing in IDA pro, change the jump address on where it goes to validate the key to where I think it decrypts.

Jibs Im opening the installer in temp, its basically the same thing but does the actual work.

Anyone else looking at the spot I was looking at? Because after the first validdecrypt key it is DOOMED to fail. Completely. No way around. Along that path is a call to play install failed and no way around it.

Okay, think I have a break through again. I think Blizzard put in a trick path into something that will purposely fail.

In proof one we see along the red path it goes STRAIGHT into loading the MPQE file, without any decryption or anything. However when we move along the green path we end up at some more stuff however they lead to proof 2, the second hasvaliddecryptionkey. This one along its red path ends up doing some stuff BEFORE loading the MPQE and getting EULA.html, which I think is decryption. I also think that's why there are two websites, one has a invalid authentication key to skip the part that fails, and the other has a valid one that is valid.

Okay, I'm gonna try to change the address from the jump location to the other direction, the default I believe skips a bunch of stuff, while the other one goes to Eula and stuff. I broke my xampp though.

I'm facing my kryptonite here. I am not good with hex editing a executable. Last time I just tried it messed it up bad.

Please people, stop the damn arguing, we have bigger things to worry about than whether the crack vernam has is real.