Author | Message | Time |
---|---|---|
St0rm.iD | [quote author=UserLoser. link=board=17;threadid=7821;start=30#msg72205 date=1090687296][quote author=$t0rm link=board=17;threadid=7821;start=30#msg72179 date=1090680576]semi-OT, but how did you find the offset in battle.snp? [/quote]disassembly.[/quote] 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.] | July 25, 2004, 3:21 AM |
kamakazie | [quote author=$t0rm link=board=17;threadid=7821;start=45#msg72360 date=1090725687] [quote author=UserLoser. link=board=17;threadid=7821;start=30#msg72205 date=1090687296] [quote author=$t0rm link=board=17;threadid=7821;start=30#msg72179 date=1090680576] semi-OT, but how did you find the offset in battle.snp? [/quote] disassembly. [/quote] never thought of that :P But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there? [/quote] 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. | July 25, 2004, 4:29 AM |
UserLoser. | [quote author=$t0rm link=board=17;threadid=7821;start=45#msg72360 date=1090725687] [quote author=UserLoser. link=board=17;threadid=7821;start=30#msg72205 date=1090687296] [quote author=$t0rm link=board=17;threadid=7821;start=30#msg72179 date=1090680576] semi-OT, but how did you find the offset in battle.snp? [/quote] disassembly. [/quote] never thought of that :P But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there? [/quote] 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 | July 25, 2004, 4:57 AM |
TheMinistered | 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 | July 25, 2004, 4:45 PM |
Adron | 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) ? | July 25, 2004, 5:39 PM |
UserLoser. | [quote author=Adron link=board=23;threadid=7873;start=0#msg72446 date=1090777162] ... What are your ways for finding out how you got to a certain place ... [/quote] In IDA, using jump xref to operand [quote author=Adron link=board=23;threadid=7873;start=0#msg72446 date=1090777162] ... in greater detail than just function calls (think of a really big function with a lot of jumps) ? [/quote] Take an attempt to figure out what each function does, then give a name or leave comments. Or skip it :) | July 25, 2004, 6:36 PM |
Adron | [quote author=UserLoser. link=board=23;threadid=7873;start=0#msg72458 date=1090780593] [quote author=Adron link=board=23;threadid=7873;start=0#msg72446 date=1090777162] ... What are your ways for finding out how you got to a certain place ... [/quote] In IDA, using jump xref to operand [/quote] 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 author=UserLoser. link=board=23;threadid=7873;start=0#msg72458 date=1090780593] [quote author=Adron link=board=23;threadid=7873;start=0#msg72446 date=1090777162] ... in greater detail than just function calls (think of a really big function with a lot of jumps) ? [/quote] Take an attempt to figure out what each function does, then give a name or leave comments. Or skip it :) [/quote] 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. | July 25, 2004, 6:42 PM |
Maddox | [quote author=Adron link=board=23;threadid=7873;start=0#msg72460 date=1090780979] Ah, you're working in IDA, not in an actual debugger? [/quote] IDA is a debugger. | July 25, 2004, 8:42 PM |
Adron | [quote author=Maddox link=board=23;threadid=7873;start=0#msg72491 date=1090788166] [quote author=Adron link=board=23;threadid=7873;start=0#msg72460 date=1090780979] Ah, you're working in IDA, not in an actual debugger? [/quote] IDA is a debugger. [/quote] 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. | July 25, 2004, 9:23 PM |
Eibro | [quote author=dxoigmn link=board=23;threadid=7873;start=0#msg72368 date=1090729761] [quote author=$t0rm link=board=17;threadid=7821;start=45#msg72360 date=1090725687] [quote author=UserLoser. link=board=17;threadid=7821;start=30#msg72205 date=1090687296] [quote author=$t0rm link=board=17;threadid=7821;start=30#msg72179 date=1090680576] semi-OT, but how did you find the offset in battle.snp? [/quote] disassembly. [/quote] never thought of that :P But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there? [/quote] 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]And if you didn't know these values to start with? | July 26, 2004, 5:18 AM |
Arta | I found the key in memory and used break on access. | July 26, 2004, 1:45 PM |
kamakazie | [quote author=Eibro[yL] link=board=23;threadid=7873;start=0#msg72618 date=1090819114] [quote author=dxoigmn link=board=23;threadid=7873;start=0#msg72368 date=1090729761] [quote author=$t0rm link=board=17;threadid=7821;start=45#msg72360 date=1090725687] [quote author=UserLoser. link=board=17;threadid=7821;start=30#msg72205 date=1090687296] [quote author=$t0rm link=board=17;threadid=7821;start=30#msg72179 date=1090680576] semi-OT, but how did you find the offset in battle.snp? [/quote] disassembly. [/quote] never thought of that :P But seriously, what tools did you use? Did you just breakpoint CreateFile on stardat.mpq and trace from there? [/quote] 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]And if you didn't know these values to start with? [/quote] 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. | July 26, 2004, 5:41 PM |
St0rm.iD | How'd you find the cdkey in memory? | July 26, 2004, 9:32 PM |
Maddox | [quote author=$t0rm link=board=23;threadid=7873;start=0#msg72729 date=1090877528] How'd you find the cdkey in memory? [/quote] Using a program like tsearch or something similar. | July 26, 2004, 10:07 PM |
Newby | Tsearch can be found here for those who want to try it out. :) | July 27, 2004, 2:29 AM |
St0rm.iD | I thought it was encrypted in stardat.mpq or what not. | July 27, 2004, 2:50 AM |
Myndfyr | [quote author=$t0rm link=board=23;threadid=7873;start=15#msg72793 date=1090896633] I thought it was encrypted in stardat.mpq or what not. [/quote] Right, but as I understand it, when the game is actually running, it's loaded into memory as plaintext. ;) | July 27, 2004, 2:51 AM |
St0rm.iD | How does one search fo ra string in tsearch? | July 28, 2004, 3:35 AM |
Maddox | [quote author=$t0rm link=board=23;threadid=7873;start=15#msg73075 date=1090985727] How does one search fo ra string in tsearch? [/quote] Try CTRL+F in the hex editor. | July 28, 2004, 5:53 AM |
Skywing | You could also use S in WinDbg. | July 28, 2004, 7:26 PM |