I'm a newb, to this stuff atleast. I'm trying to teach my self, like I teach my self many other things, along with some minor help & explainations Arta gave me the other day. Anyways, so far I've established that usually when you see "mov cl, SomeNumericValueh", it's setting the packet id for a BNCS packet (as you can see in the picture below, my genious findings)

[img]http://darknet.darktech.org/files/bsnp.PNG[/img]

From going to the locations of those, i've been able to see how some packets are built, example:
[code]
.text:19016D74 loc_19016D74: ; CODE XREF: sub_19016810+415j
.text:19016D74 push offset aGetLatestBattl ; "Get latest battle.net icons"
.text:19016D79 call sub_190023C0
.text:19016D7E add esp, 4
.text:19016D81 xor edx, edx
.text:19016D83 mov cl, 2Dh
.text:19016D85 push ebx
.text:19016D86 call sub_19015A60
.text:19016D8B test eax, eax
.text:19016D8D jz loc_19016EB8
.text:19016D93 mov ebp, [ebp+0Ch]
.text:19016D96 cmp ebp, 53544152h
.text:19016D9C jz short loc_19016DA6
.text:19016D9E cmp ebp, 53455850h
.text:19016DA4 jnz short loc_19016DCE
[/code]

(Thanks to Blizzard for the comments.)

I know I should be learning what push, test, mov, jz, jnz, ect all mean first before asking questions, but maybe by posting and asking here, I can get a quicker explanation from the more advanced users. I believe [code]add esp, 4[/code] sets the packet length, [code]mov cl, 2Dh[/code] sets the packet ID, and maybe [code]call sub_19015A60[/code] is the sub to send the packet, but in that sub I don't really see it being sent.

Was going to post more, but have to go now, so I'll end this here...

My goal someday, no matter how long it takes (even a few years) is to reverse joining games, or War3 logon. :P

Any comments, hints, or help appreciated :)

[code]
.text:19016D74 loc_19016D74: ; CODE XREF: sub_19016810+415j
.text:19016D74 push offset aGetLatestBattl ; "Get latest battle.net icons"
.text:19016D79 call sub_190023C0
.text:19016D7E add esp, 4
[/code]
I think the add esp, 4 is to recover the stack.

I have a great 100+ page pfd on reverse engineering. Its basically a course in computer architecture and assembly language.

message me on aim: dev INVISIBLE
make sure you mention where your from or i'll ignore you.

[quote author=Etheran link=board=7;threadid=4271;start=0#msg35643 date=1071544237]
[code]
.text:19016D74 loc_19016D74: ; CODE XREF: sub_19016810+415j
.text:19016D74 push offset aGetLatestBattl ; "Get latest battle.net icons"
.text:19016D79 call sub_190023C0
.text:19016D7E add esp, 4
[/code]
I think the add esp, 4 is to recover the stack.
[/quote]

in a _cdecl function, the stack pointer from the arguments being pushed isn't restored within the function, and must be done after the function is called, by adding to the stack pointer. In a __stdcall function, that would be done inside.

[quote author=iago link=board=7;threadid=4271;start=0#msg35668 date=1071552530]
[quote author=Etheran link=board=7;threadid=4271;start=0#msg35643 date=1071544237]
[code]
.text:19016D74 loc_19016D74: ; CODE XREF: sub_19016810+415j
.text:19016D74 push offset aGetLatestBattl ; "Get latest battle.net icons"
.text:19016D79 call sub_190023C0
.text:19016D7E add esp, 4
[/code]
I think the add esp, 4 is to recover the stack.
[/quote]

in a _cdecl function, the stack pointer from the arguments being pushed isn't restored within the function, and must be done after the function is called, by adding to the stack pointer. In a __stdcall function, that would be done inside.
[/quote]
Note that this need not be done with the add instruction; sometimes, the compiler will optimize it into something like pop ecx.

IIRC, cl holds the packet ID, edx holds the offset of the packet data, and the first dword on the stack holds the length of the packet data.

You (and Adron) are right about that sub:
[code].text:19015A60 ; ecx = char PacketCode
.text:19015A60 ; edx = char *Packet
.text:19015A60
.text:19015A60 ; void __stdcall SendOutTCPPacket(DWORD dwLength)[/code]

I know it's not actually __stdcall, it's __fastcall, but IDA doesn't like __fastcall.

The packet is actually sent here:
[code].text:19015AEC 06C 8B+ mov edx, ds:TCPSocket
.text:19015AF2 06C 6A+ push 0 ; flags
.text:19015AF4 070 57 push edi ; len
.text:19015AF5 074 56 push esi ; buf
.text:19015AF6 078 52 push edx ; s
.text:19015AF7 07C FF+ call ds:send
[/code]

[quote author=iago link=board=7;threadid=4271;start=0#msg35691 date=1071570610]
I know it's not actually __stdcall, it's __fastcall, but IDA doesn't like __fastcall.[/quote]

As I recall (no pun intended), _fastcall implies _stdcall for the arguments after the first two. At least for MSVC code, I doubt you'll ever see a function which takes two arguments in registers, then treats its stack arguments as _cdecl.

So does
[code]
.text:19016D8B test eax, eax
.text:19016D8D jz loc_19016EB8
.text:19016D93 mov ebp, [ebp+0Ch]
.text:19016D96 cmp ebp, 53544152h
.text:19016D9C jz short loc_19016DA6
.text:19016D9E cmp ebp, 53455850h
.text:19016DA4 jnz short loc_19016DCE
[/code]

Have anything to do with sending the packet?

[code].text:19016D8B 230 85+ test eax, eax ; test the return value
.text:19016D8D 230 0F+ jz LoginFailure ; Jump if the send failed

[/code]

not sure about the rest, and I'm busy right now

At a totally unresearched guess, I'd say it's putting the dword at offset 0x0C in an incoming packet into EBP and comparing that to 2 Product IDs.

hmm:

[code].text:19016D86 234 E8+ call SendOutTCPPacket ; ecx = char PacketCode
.text:19016D86 234 D5+ ; edx = char *Packet
.text:19016D8B 230 85+ test eax, eax ; test the return value
.text:19016D8D 230 0F+ jz LoginFailure ; Jump if the send failed
.text:19016D93 230 8B+ mov ebp, [ebp+0Ch]
.text:19016D96 230 81+ cmp ebp, 'STAR'
.text:19016D9C 230 74+ jz short loc_19016DA6
.text:19016D9E 230 81+ cmp ebp, 'SEXP'
.text:19016DA4 230 75+ jnz short loc_19016DCE
[/code]

bleh, never thought of converting the hex to a string!

[quote author=UserLoser. link=board=7;threadid=4271;start=0#msg35994 date=1071678663]
bleh, never thought of converting the hex to a string!
[/quote]

Poor unexperienced reverse engineer....

With experience, those values are obvious candidates for turning into strings. You'll learn many such things with practise.

[quote author=Adron link=board=7;threadid=4271;start=0#msg36021 date=1071686956]
Poor unexperienced reverse engineer....

With experience, those values are obvious candidates for turning into strings. You'll learn many such things with practise.
[/quote]

Not poor, but yes unexperienced :P

Yeah, DWORD's or just plain memory where everything is between 0x40 and 0x80 tends to stand out to me :)

don't forget 0x30-0x39 for numbers

ya those are great because they are such an easy conversion...

0x30 = 0
0x31 = 1
blah blah