Emulate Battle.net

[stormbreaker]

not that hard, the same type of verification has been done before. i don't see how this is the stumbling point of anyone, since it's not obfuscated at all.
also, what you send for the 0x02 password module response is the key you both use to decrypt/encrypt packets, FYI.

Which one and how did you get this information? Is it confirmed?
Perhaps you know why we all get "bad server" error when sending the rights (we think) data.

[usmc23]

In the general interest of "sharing info", here is where im at.  The ProofRequest packet sends TWO auth modules, one is password.dll the other is thumbprint.dll.  ThumbPrint.dll recieves a 16byte IP address of the server if it doesn't match the hardcoded vals in ThumPrint.dll it fails(aka WoW).  Now the catch 22 is we can't modify that dll because teh b.net.dll does a integrity check, if it fails you get the same "bad server" error message.

My thought was doing a EAT patch on LoadLibrary and intercept the LoadLibrary calls to the auth modules, the hook works just fine but there isnt a direct call to those dll's.

[stormbreaker]

In the general interest of "sharing info", here is where im at.  The ProofRequest packet sends TWO auth modules, one is password.dll the other is thumbprint.dll.  ThumbPrint.dll recieves a 16byte IP address of the server if it doesn't match the hardcoded vals in ThumPrint.dll it fails(aka WoW).  Now the catch 22 is we can't modify that dll because teh b.net.dll does a integrity check, if it fails you get the same "bad server" error message.

My thought was doing a EAT patch on LoadLibrary and intercept the LoadLibrary calls to the auth modules, the hook works just fine but there isnt a direct call to those dll's.

I found out that, too. I managed to work around the second module easily.
It seems that the client uses it, but it doesn't REQUIRE it.


So by sending only the first auth module:



EDIT: I'm going to mess around with the next packets tomorrow.

[usmc23]

Thats some good stuff, you should come into IRC : ), but right now im having trouble writing two bytes before the "auth" module struct.  Right now i have to force the two bytes to be "42 10", I thought it was just supposed to be int:3 numModules?

[usmc23]

We got passed the ProofRequest packet and we sent both auth dll's : ).

[Draugur]

We got passed the ProofRequest packet and we sent both auth dll's : ).

congratulations

[Fedoranimus]

We got passed the ProofRequest packet and we sent both auth dll's : ).

Awesome, great job.

[stormbreaker]

We got passed the ProofRequest packet and we sent both auth dll's : ).

GJ. But what is the point in sending both packets if it doesn't need it?
Anyway, did you modify the dll or hack through it?

[stormbreaker]

Thats some good stuff, you should come into IRC : ), but right now im having trouble writing two bytes before the "auth" module struct.  Right now i have to force the two bytes to be "42 10", I thought it was just supposed to be int:3 numModules?

Are you putting there the header bytes?

int:6 PacketID; // The packet id of this packet.bool:1 HasChannel // Boolean value specifying whether or not the channel id is included in the header.

int:4 ChannelID; // The channel id of this packet.

I can't join the IRC because my ISP is redirecting all the IRC traffic to their server... And I never was a mirc fan.


OOps sorry for double posting....

[2g4u]

It might be a lil old, but if it helps you its all good: http://0x1337.org/index.html?page=sciidbg

[usmc23]

It might be a lil old, but if it helps you its all good: http://0x1337.org/index.html?page=sciidbg

Does that work on the b.net screen?

We just got it so when you type the password in the client it sends out the next packet(Thanks Tom), you can't just not send the thumbprint.dll you have to make it return one when it tests against the hash in the dll vs ur servers IP. 

[usmc23]

This was a combined effort of the entire Starcrack team, but here is what we have as of now:

[Draugur]

This was a combined effort of the entire Starcrack team, but here is what we have as of now:

Have you done some research on the packet encryption after login?

[masky007]

human language please

actually how far is this? how much long.. CANT WAIT ))

[usmc23]

is the password, session keys transmitted in the 2nd packet from the c -> s and vice versa?