|
Luigi Auriemmaaluigi.org (ARCHIVE-ONLY FORUM!) |
|
It is currently 19 Jul 2012 11:51
|
View unanswered posts | View active topics
|
Page 1 of 1
|
[ 12 posts ] |
|
Author |
Message |
n00b
|
Post subject: Packet's help Posted: 20 Aug 2007 20:54 |
|
Joined: 14 Aug 2007 13:32 Posts: 71
|
Hi well i thought i might as well expand my knowledge and what a good opertutnity.Ok well i did what you said before luigi i download the WPE PRO application,But im wondering surly there has to be a better way of sending the packet's back to the server or client,For instance when i've captured the file's i would like to step through the packet's sending them back to the server or client to see haw the program react's,But i normally copy all the hex code down by hand it takes so damn long,Do you have any better ideas which could speed up the process luigi.
|
|
Top |
|
|
|
|
|
|
|
aluigi
|
Post subject: Posted: 20 Aug 2007 21:08 |
|
Joined: 13 Aug 2007 21:44 Posts: 4068 Location: http://aluigi.org
|
ih ih ih we have the same ideas and needs
I had in mind a packets replay tool from many time but it would be useless in many applications since many of them use challenge-response techniques which make a similar tool useless.
For the moment I do two things, the manual sending as you do and the writing of a compatible client (just like I'm doing in this exact moment).
|
|
Top |
|
|
n00b
|
Post subject: Posted: 28 Aug 2007 23:08 |
|
Joined: 14 Aug 2007 13:32 Posts: 71
|
luigi i had an idea i was wondering if you would write a small tutorial on haw we would go about testing the protocols of a application.I mean the coding of a fake client is easy enough but building the packet's and sending and receiving is well a little confusing with different applications using different methods of sending and receiving may be a little tutorial so we can get to grips with it.With some sort of easy protocol may be a game or some thing any thing just to show how you go about the whole thing it would be great.
Of course only if you have the time i think it would be brilliant to learn more about how and understanding about applications work with packet's the packet malnipulation on the other hand ,I already have some ideas of implementing some thing into a project im working on..
Would love to see a real life example how you your self go about building packets.Even a little video or hand wrote tutorial.Im hoping to put as much input into the forum as possible as soon as i get my driving test over with in 7 day's.
:D
|
|
Top |
|
|
JD
|
Post subject: Re: Packet's help Posted: 28 Feb 2009 00:07 |
|
Joined: 08 Jun 2008 07:17 Posts: 92
|
I agree you should write a tutorial on how you figure out how the protocols work.
I've been looking around for tutorials like that but I have yet to find any. D:
|
|
Top |
|
|
Sethioz
|
Post subject: Re: Packet's help Posted: 28 Feb 2009 13:10 |
|
Joined: 24 Sep 2007 02:12 Posts: 1114 Location: http://sethioz.co.uk
|
Finding out about program's protocol is very simple. well wpe pro kind a sucks, it has only one good feature and that is: it can attach itself to a process, instead of capturing all packets. I'm using CommView instead. so far i haven't found any other program tht has similiar functions. it allows you to change filters while capturing and they take effect right after you change them, so you do not have to stop capture. also it allows process based capturing, which makes it even more easier.
How to find out about program's protocol ? well you simply look at the packets. look what they contain..etc. packets are quite easy to read actually, ofcourse if it is not gzipped or encrypted (SSL ..etc). that will become a problem with commview. commview also has a packet generator, which allows you to make your own packet from scratch (ip, port, data..etc) also if you want to resend a packet, then challenge response becomes a problem, which Luigi already mentioned. only way is to build a client for that.
One thing i haven't figured out exactly. here's few things i do know for sure: 1. MSN does not use challenge response 2. WPE pro CAN send packets into msn 3. commview (and all other packets editors whcih dont attach themselves) can NOT send packets into msn
im wondering why wpe pro can send packets and commview cant..uh somebody told me that MSN has some kind of order so you can't send packet with same id (number) again, but it makes no sence, msn packets doesn't have that kind of id.
|
|
Top |
|
|
aluigi
|
Post subject: Re: Packet's help Posted: 28 Feb 2009 14:09 |
|
Joined: 13 Aug 2007 21:44 Posts: 4068 Location: http://aluigi.org
|
WPE pro can because it's a hooker (program->wpe->sockets) and so it has control over the send/sendto functions in which case it can send anything it wants without touching the low level tcp protocol (syn/ack/id and so on).
commview can't because it's only a sniffer so it can only view and probably edit the packets, because if it modifies something in the ip/tcp packet it makes a chaos
|
|
Top |
|
|
Sethioz
|
Post subject: Re: Packet's help Posted: 28 Feb 2009 18:15 |
|
Joined: 24 Sep 2007 02:12 Posts: 1114 Location: http://sethioz.co.uk
|
Well actually commview CAN send packets into msn if you know what to modify, but its too annoying. and yes its because of the socket too, msn closes the socket if there is no activity for 30 secs or so. however WPE pro sucks when it comes to protocol research or anything like this, also proxocket can totally replace wpe pro now.
i prefer to use commview to do research on protocols (in what form it sends packets, what commands its using..etc) and then i use proxocket if i need to modify anything.
|
|
Top |
|
|
JD
|
Post subject: Re: Packet's help Posted: 28 Feb 2009 18:27 |
|
Joined: 08 Jun 2008 07:17 Posts: 92
|
How do I go about packets with challenge response systems built in them? How do I figure out the decryption process?
EG... Ventrilo proxy can decrypt the packets, how did you figure out how the decryption process works?
I know it's all ready done on ventrilo but I would still like to know how it was done or can be done.
|
|
Top |
|
|
aluigi
|
Post subject: Re: Packet's help Posted: 28 Feb 2009 22:31 |
|
Joined: 13 Aug 2007 21:44 Posts: 4068 Location: http://aluigi.org
|
in that case the only way is debugging the program, which means that is needed to follow all the instructions performed on the input data.
a practical example with ollydbg attached to the process can be: - set a breakpoint on recv for tcp data or recvfrom for udp packets: . bp recv (some programs are linked to wsock32, bp wsock32.recv) . bp recvfrom (or bp wsock32.recvfrom) . (in some rare occasions the program could use WSARecv or WSARecvFrom for receiving the data) - when the data is received and the debugger breaks choose the "Buffer" field visible in the stack window and select "Follow in Dump" which will point the left-down window to that memory zone - press CTRL-F9 for executing the recv* function so that the buffer will be filled with the received data - set a "hardware, on access" breakpoint on the received data (if you are in a virtual machine use "memory, on access") - now use the other breakpoints to follow the "flow" of the data, so if there is a "rep movsd" set a breakpoint in the data in EDI because it's where the data has been copied, if there is a "rep stosd" remove the breakpoint because that memory has been cleaned and so on (obviously is needed to know a bit of x86 assembly)
any compression and encryption function has ever an input and an output so they are easy to recognize.
anyway this is the fastest step-by-step which came in my mind so hope it helps for giving a general idea of how following the instructions performed on the input data.
if the input is not a network packet but a file the thing is exactly the same except that is needed to put the first breakpoint on ReadFile (it's good to set first the breakpoint on CreateFileW and when we see that the file we want to monitor has been "opened" setting the breakpoint on ReadFile)
|
|
Top |
|
|
Sethioz
|
Post subject: Re: Packet's help Posted: 01 Mar 2009 13:06 |
|
Joined: 24 Sep 2007 02:12 Posts: 1114 Location: http://sethioz.co.uk
|
challenge response is not a encryption process, it means that if you send a packet then server checks if it is valid packet. if server sends you packet then it wants a VALID response, so any packet won't do or resent packet.
|
|
Top |
|
|
aluigi
|
Post subject: Re: Packet's help Posted: 02 Mar 2009 01:17 |
|
Joined: 13 Aug 2007 21:44 Posts: 4068 Location: http://aluigi.org
|
uhmmm I think you refer to the checksum which is sometimes used in some protocols (like TeamSpeak), the challenge response is when the other endpoint (like the server) expects a specific number/ID derived by another one sent previously by it, this can be the same number (like in Quake 3) or the result of an algorithm (like some games in the Unreal engine, watch calc_authresp in unrealfp.c)
|
|
Top |
|
|
Sethioz
|
Post subject: Re: Packet's help Posted: 02 Mar 2009 16:51 |
|
Joined: 24 Sep 2007 02:12 Posts: 1114 Location: http://sethioz.co.uk
|
yeah Luigi thats what i meant. you know that i don't debug programs like this, i just tried to describe it in basic level. thats what i meant that server expects a VALID packet. either is it ID or just packet number..etc.
also checksum can become a problem sometimes if you EDIT the packet manually, commview has a checksum generator, so you can use that or use proxocket (like i did) to make an automatic checksum filter, but it would only work on specific packet/s.
|
|
Top |
|
|
|
Page 1 of 1
|
[ 12 posts ] |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|