Quote from: UserLoser. on July 24, 2004, 11:41 AMQuote from: $t0rm on July 24, 2004, 09:49 AMsemi-OT, but how did you find the offset in battle.snp?
disassembly.
never thought of that :P
But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there?
[Kp edit: no change to the original post, just changed title and an explanation here. This thread was originally a side discussion in z-stars request for assistance. However, the subject matter deserves its own thread free from newbie debugging, and so was split to become this thread.]
Quote from: $t0rm on July 24, 2004, 10:21 PM
Quote from: UserLoser. on July 24, 2004, 11:41 AM
Quote from: $t0rm on July 24, 2004, 09:49 AM
semi-OT, but how did you find the offset in battle.snp?
disassembly.
never thought of that :P
But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there?
For HashData you could find the init values and trace back from there. For the cdkey decode you could find the unique dword is uses (0x13AC9741) and trace back from there.
Quote from: $t0rm on July 24, 2004, 10:21 PM
Quote from: UserLoser. on July 24, 2004, 11:41 AM
Quote from: $t0rm on July 24, 2004, 09:49 AM
semi-OT, but how did you find the offset in battle.snp?
disassembly.
never thought of that :P
But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there?
All starts from send. You find the call to send used for BNCS related packets. You then trace it back to 0x51. Then you go back on each call and see what they do and what's being passed into it. So setting some breakpoints would help. Or, just search for
mov cl and find
mov cl, 51h
I would follow UserLoser's advice and trace from send. I say this because it's a sure-win situation. You might want to bring some popcorn and a coke though, might take you a while :P
Tracing from send works in many cases. By "stepping out", you can do it pretty quickly too.
The wt command in windbg seems useful as well. Does anyone have experience with that?
What are your ways for finding out how you got to a certain place, in greater detail than just function calls (think of a really big function with a lot of jumps) ?
Quote from: Adron on July 25, 2004, 12:39 PM
... What are your ways for finding out how you got to a certain place ...
In IDA, using
jump xref to operandQuote from: Adron on July 25, 2004, 12:39 PM
... in greater detail than just function calls (think of a really big function with a lot of jumps) ?
Take an attempt to figure out what each function does, then give a name or leave comments. Or skip it :)
Quote from: UserLoser. on July 25, 2004, 01:36 PM
Quote from: Adron on July 25, 2004, 12:39 PM
... What are your ways for finding out how you got to a certain place ...
In IDA, using jump xref to operand
Ah, you're working in IDA, not in an actual debugger? I read it as setting a breakpoint on send, waiting for it to be called with the right packet, and then tracing back up. Re-reading your post, I realize that that's probably not what you meant.
Quote from: UserLoser. on July 25, 2004, 01:36 PM
Quote from: Adron on July 25, 2004, 12:39 PM
... in greater detail than just function calls (think of a really big function with a lot of jumps) ?
Take an attempt to figure out what each function does, then give a name or leave comments. Or skip it :)
That works in some cases. The scenario I was thinking of was setting a breakpoint on a messagebox saying "authentication failed" or "insert the correct cd and try again", and then trying to figure out how you got there, particularly if there are many jumps leading to the same point.
Quote from: Adron on July 25, 2004, 01:42 PM
Ah, you're working in IDA, not in an actual debugger?
IDA is a debugger.
Quote from: Maddox on July 25, 2004, 03:42 PM
Quote from: Adron on July 25, 2004, 01:42 PM
Ah, you're working in IDA, not in an actual debugger?
IDA is a debugger.
It's primarily a disassembler though. In the same way as windbg does have a disassembler, but is primarily a debugger. And "jump xref to operand" is a disassembler thing to do, not a debugger thing to do.
Quote from: dxoigmn on July 24, 2004, 11:29 PM
Quote from: $t0rm on July 24, 2004, 10:21 PM
Quote from: UserLoser. on July 24, 2004, 11:41 AM
Quote from: $t0rm on July 24, 2004, 09:49 AM
semi-OT, but how did you find the offset in battle.snp?
disassembly.
never thought of that :P
But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there?
For HashData you could find the init values and trace back from there. For the cdkey decode you could find the unique dword is uses (0x13AC9741) and trace back from there.
And if you didn't know these values to start with?
I found the key in memory and used break on access.
Quote from: Eibro[yL] on July 26, 2004, 12:18 AM
Quote from: dxoigmn on July 24, 2004, 11:29 PM
Quote from: $t0rm on July 24, 2004, 10:21 PM
Quote from: UserLoser. on July 24, 2004, 11:41 AM
Quote from: $t0rm on July 24, 2004, 09:49 AM
semi-OT, but how did you find the offset in battle.snp?
disassembly.
never thought of that :P
But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there?
For HashData you could find the init values and trace back from there. For the cdkey decode you could find the unique dword is uses (0x13AC9741) and trace back from there.
And if you didn't know these values to start with?
Well that's the dilema. I got into all of this after a lot of source was released but before Diablo 2 (SID_AUTH_CHECK/SID_LOGONRESPONSE2) sequence was figured out. Using prior code I figured out a lot of stuff just by comparing the assembly with the c source. For something that you have no knowledge of then you have to fish around looking for strings or other things. It seems most of the people here (except Adron) had prior knowledge of what they were looking for already (i.e. a sha-1 hash function, a cdkey decode routine, a checkrevision rountine, etc). It's much easier to work that way IMO if you do have that resource. I forgot how I stumbled upon the mov cl, SID thing. I think I searched for 51h set a bp then waited it for it to break. Then I noticed this with other packets and from there search for other things because I had some knowledge of the protocol.
How'd you find the cdkey in memory?
Quote from: $t0rm on July 26, 2004, 04:32 PM
How'd you find the cdkey in memory?
Using a program like tsearch or something similar.
Tsearch can be found here (http://fly.to/mtc) for those who want to try it out. :)
I thought it was encrypted in stardat.mpq or what not.
Quote from: $t0rm on July 26, 2004, 09:50 PM
I thought it was encrypted in stardat.mpq or what not.
Right, but as I understand it, when the game is actually running, it's loaded into memory as plaintext. ;)
How does one search fo ra string in tsearch?
Quote from: $t0rm on July 27, 2004, 10:35 PM
How does one search fo ra string in tsearch?
Try CTRL+F in the hex editor.
You could also use S in WinDbg (http://www.microsoft.com/whdc/ddk/debugging).