DarkBlizz

Vernam7 is the second address we're looking for the second reference to hasvaliddecryptionkey?

Is it the second address mentioning valid decrypt key at 004D037?

Gah, I don't know how to do hex editing.

So vernam7, are those addresses I posted where we should be looking?

I'm beginning to think that memory editing might be easier for this.

Okay, I think I got this guys. At 004CDEF there is a boolean true or false that checks if the authentication key is authentic. If its true it moves onto the EULA and all that stuff. However if FALSE it moves onto location 0044D012 which means that the file never gets decrypted. Which means we need to get validdecryptionkey to come out to true. After looking at this there is two checks, the date check along with valid key check, if the key is invalid it SKIPS decryption.

Cyber we're relatively calm compared to other places. We're not screaming at Vernam7 like some sites to release the crack or claiming he never did it.

Vernam7 should drop us another hint.

Like what tools he used.

Guys. If any of you are using say IDA pro or whatever, if you see jz 006569F8 or that location referenced in any code that is what we are looking for. That goes to CryptCreateHash which I think is what we need.

I give up on this.

.rdata:006569E0 ; char aCryptacquireco[]
.rdata:006569E0 aCryptacquireco db 'CryptAcquireContextA',0 ; DATA XREF: sub_547590+7o
.rdata:006569F5                 align 4
.rdata:006569F8 ; char aCryptcreatehas[]
.rdata:006569F8 aCryptcreatehas db 'CryptCreateHash',0  ; DATA XREF: sub_547590:loc_5475A9o
.rdata:00656A08 ; char aCryptdestroyha[]
.rdata:00656A08 aCryptdestroyha db 'CryptDestroyHash',0 ; DATA XREF: sub_547590+28o
.rdata:00656A19                 align 4
.rdata:00656A1C ; char aCryptdestroyke[]
.rdata:00656A1C aCryptdestroyke db 'CryptDestroyKey',0  ; DATA XREF: sub_547590+37o
.rdata:00656A2C ; char aCrypthashdata[]
.rdata:00656A2C aCrypthashdata  db 'CryptHashData',0    ; DATA XREF: sub_547590+46o
.rdata:00656A3A                 align 4
.rdata:00656A3C ; char aCryptimportkey[]
.rdata:00656A3C aCryptimportkey db 'CryptImportKey',0   ; DATA XREF: sub_547590+55o
.rdata:00656A4B                 align 4
.rdata:00656A4C ; char aCryptreleaseco[]
.rdata:00656A4C aCryptreleaseco db 'CryptReleaseContext',0 ; DATA XREF: sub_547590+64o
.rdata:00656A60 ; char aCryptsignhasha[]
.rdata:00656A60 aCryptsignhasha db 'CryptSignHashA',0   ; DATA XREF: sub_547590+73o
.rdata:00656A6F                 align 10h
.rdata:00656A70 ; char aCryptverifysig[]


Looks to me like the key to decrypt is clientside.

I can also confirm its the beta installer. Beta installer is teal where the retail installer is blue.

After using IDA Pro to look through the second installer I've noticed completely random strings of 64 bits, might have something to do with the key or encryption.

%s I think refers to enUS or enGB and %d I believe refers to sc2-authenticationcode

Perhaps this is the check against the key to test if its real?

esp+0ECh+var_64

If you have the north american version add 127.0.0.1 us.battle.net to your hosts file.